If you’ll cast your mind back to 1998 for a moment and remember your days at University House, yes it’s Malcolm Phillips from room AL.01 here.

Just writing to say Hi, and that I saw you on the cover of a Computer World the other day (nice glasses). It’s good to see that you’re doing well, some 10 years furthur on. I can’t think of anyone more qualified to be representing NZ’s views on OOXML.

btw, my own website is a bit prehistoric (though at least I have one now).

Not having to author input for a particular output format is nice in practice too, I assure you (yes, there’s working software already). Of course this isn’t just about abstracting “templates”: it’s content, forms, menus, tabs, and every part of the output that has previously been hard-coded and inflexible.

Some of your questions would be better answered by going into great detail about the similarities and dissimilarities between these formats. Contrasting the different table models, image models, etc., would surely take more than a blog comment, however I’ll just say for now that the majority of semantics available in DocBook5 and HTML5 could not be easily encoded in the @class and @id attributes of HTML4. The exact choice of semantics will come out as we go through the tag mappings, which may help justify a new abstraction rather than a naming convention in HTML4.

Speaking more generally about “better choices for more complex or dynamic UI’s”. I would like to see HTML5 become the future of the web more than I would XAML, Flash/Flex, or XUL because HTML5 truly is an open standard. The other platforms are advancing quickly… to paraphrase Brendan Eich “the obvious conflict of interest between the standards-based web and proprietary platforms advanced by Microsoft, and the rationales for keeping the web’s language small while the proprietary platforms rapidly evolve support for large languages, does not help maintain the fiction that only clashing high-level philosophies are involved here.” –Source

An abstraction of the authoring format in order to support multiple output formats would encourage HTML5 without losing the HTML4 audience. I see this as necessary for HTML5, but there are many ways of achieving this abstraction and I imagine that this project will just be one of many.

I still don’t quite understand why you would *need* to have a site outputting a UI in both HTML5 and HTML4 and other formats all at once… Surely, HTML4 is good for a certain limited range of content and hypertext stuff, but there are other better choices for more complex or dynamic UI’s. I would expect it to be more of an either/or proposition in most cases.

It may be a restrictive convention, but surely, you can derive most of the transforms you mention from just ‘id’ and ‘class’ attributes?