During processing, HaXtatic may generate (when so set up and fresh content changes indicate the need) additional XML output files of 2 kinds: sitemap.xml and *.atom feeds.
uses a trivial format, is cheap to generate and written to /sitemap.xml during processing by default:
|C|_hax_relpath_sitemap: *.haxproj directive.loc value is required (needlessly and wastefully so, but that's the format) to include a full domain-name and unless a custom |C|_hax_domainname: *.haxproj directive was explicitly declared, HaXtatic falls back on the project-directory's name for that.priority value is guesstimated by a naive heuristic based loosely on page path length/depth/complexity and not currently user-customizable.lastmod value refers to the custom-set page date only if that was explicitly encoded in the content source file's name, otherwise it falls back to the content source file's currently set "last modified" timestamp.
Whether and where these are written is specified in a |B| directive's atomFile property. Every page associated with the Blok is (during generation of its corresponding *.atom feed) translated in its entirety into one equivalent <entry> (of course sans the outer template). To not reprocess all haXtags for each, a cached (already-processed and thus haXtag-free) in-memory version of the page content is used for that. However, that in turn forced HaXtatic to reprocess and re-generate (prior to generating any *.atoms) any and all pages that will end up in any *.atom feed determined to need re-generation during this run. This behavior will be improved in the future.
These are not by default generated unless a |C|_hax_relpath_postatoms: *.haxproj directive explicitly specifies a site-root-relative (aka. build-directory-relative) path to the location they should be written to (can be / too). One such output file is then generated there per every "feed" (auto-named <feed-name>.atom). All the content/meta-data for each "post" belonging to the "feed" is translated into one equivalent <entry>.