I wouldn't bother with HTML or any of the site-specific mutant HTMLs, I'd just code the entries in XML and have stylesheets to whack it into all the target dialects.
The one big advantage to site-specific mutant HTML is the automagic fixup when a target renames hir journal. Going to XML ... I'd have to get around to learning enough XML to understand how much work it'd be to learn how to do that (right now I get the general gist of XML but not how to write DTDs and how to use stylesheets to whack it into HTML as needed -- so far I've done all my "turn XML into HTML" using 'sed'). Got a good really-quick-intro web site to suggest that isn't "magazine article 'wow golly lookitthat'" shallow (i.e. overview but still enough detail to get me started)?
If I were using (writing) a GUI client, it would make even more sense to have the front-end tool create XML as an intermediate product. But I've been writing my entries in HTML by hand in 'vi', and I'm comfortable with that, and I get the impression that (in general) XML is more useful as a language for two programs to use share data with each other, than as something humans type. Am I wrong about that? (Admittedly, my impression is gleaned partly by looking at MusicXML and comparing it to ABC and Lillypond.)
Actually, I find the level of effort for XML about equivalent to HTML for the sorts of things I do with it (probably similar to the things you do). The more I tweak and customize the HTML, the better XML looks, as I can apply the tweaks automatically and uniformly by simply reprocessing the XML originals (I edit mine with vi for the most part).
However, transforming XML with stylesheets can quickly get into deep magic if you want to get creative (which I'll take as a given). Personally, I have a great deal of fun making stylesheets do intricate things (e.g. stylesheets generating stylesheets, stylesheets transforming XML into troff), but "normal" people try to avoid such things. I even have stylesheets that take parameters from the command line, do I18N on the fly, and call Java for various tasks.
(no subject)
the entries in XML and have stylesheets to whack it into all the target dialects.
(no subject)
If I were using (writing) a GUI client, it would make even more sense to have the front-end tool create XML as an intermediate product. But I've been writing my entries in HTML by hand in 'vi', and I'm comfortable with that, and I get the impression that (in general) XML is more useful as a language for two programs to use share data with each other, than as something humans type. Am I wrong about that? (Admittedly, my impression is gleaned partly by looking at MusicXML and comparing it to ABC and Lillypond.)
(no subject)
I do with it (probably similar to the things you do). The more I tweak and customize the
HTML, the better XML looks, as I can apply the tweaks automatically and uniformly by
simply reprocessing the XML originals (I edit mine with vi for the most part).
However, transforming XML with stylesheets can quickly get into deep magic if you
want to get creative (which I'll take as a given). Personally, I have a great deal of
fun making stylesheets do intricate things (e.g. stylesheets generating stylesheets,
stylesheets transforming XML into troff), but "normal" people try to avoid such things.
I even have stylesheets that take parameters from the command line, do I18N on the
fly, and call Java for various tasks.