That's what I was thinking in general terms, earlier on: write tools that revolve around an XML representation, and as another step have a human-markup translator that only has to translate it to XML. Writing the XML by hand can be done now before that other part is ready.

But, if it's only the "body" or paragraph narrative part that I'm worried about, a few simple things like the @ for code will get me most of the way there with very little work. Internally, I'm transforming @word into <xref> first, then passing it on for further processing. The step that actually figures out the cross references will see xref tags that were generated from @-notation and those that were typed out the long way with no distinction between how they were originally typed.

I could do these kinds of things with one program, write out another file, and then feed that to another program. But it's easy to do that same pipeline one "twig" at a time under one program.

But you do inspire me to add an attribute to the document that specifies whether it is strict XML or contains the hybrid extensions. That way the straight form can be saved with the same file extension, and if they don't process out unless enabled, will provide backward compatibility when I come up with new markup extensions. That is, documents written without X in mind will not have their meanings altered.

—John