I'm coming around to the idea that we can't handle all of the dependency tracking with a specialized map. But, I'm wondering if we can come up with an approach that still leverages maps for the dependencies they express and supports the continuum of approaches.

Proposal: We introduce a new kind of XML document that identifies the source files belonging to an information set. The basic structure is very simple:

The <data> element would be the same as DITA 1.1 for cognitive reuse if nothing else.

So far, this representation could be used in the same way as the existing build list. The representation is just more processable because it is XML, so you could retain this artifact for later processing.

For the next level of use, the <source> element can not only refer to the source file but store a snapshot of the source file or some subset. We can also specialize the elements so we can have clarity and extensibility and can validate (if desired).

By pulling in the map and a subset of the topic, we have a complete declaration of the dependencies within the information set:

Note that external objects such as images are identified.

Capturing this information in the <infoset> gives us everything we need for incremental builds. When a file changes, we only have to update the <infoset> and the output files for the changed file and any files with dependencies on the changed file.

The process that updates the infoset would probably normalize the class attributes so we don't have to validate.

Variation 1: We could pull in the entire topic instead of just the elements that are the source or target of dependencies.

For someone who doesn't mind keys in their XSLT, that could meet the same requirements as a merged map but without duplicate topics.

Effectively, this populated infoset document provides the poor man's portable CMS.

You could run an XML Diff on the old and new infoset to capture the deltas for efficient propagation of updates to another site.

If you really had to, you could even pull in encoded external binaries and pipe the entire infoset as a single stream.

Variation 2: You could have <source> elements that refer to Ant build targets or even contain snapshots of the Ant build files. Interesting things become much easier to understand, like running an Ant build on the infoset and using XSLT to convert an Ant template into a subordinate Ant file out of the infoset and then executing it in the continuation of the Ant build.

Footnote: Probably, we should call them something other than infosets to avoid confusion with the XML infoset.