If you’re going to define a generic layout container format (and this might be the most useful way to go), then all I would suggest is being clear up front about that aspect. One of our partners has put some work into using the ePub (http://en.wikipedia.org/wiki/Epub#IDPF / http://www.idpf.org/specs.htm) format for exactly this purpose, although I haven’t yet had a chance to evaluate its suitability. There seem to be at least a few competing standards, which might be the way to go rather than inventing another one from scratch.

@MJ: Heh, that’s ok — just fixed it.

I think our ideas on the format are pretty much aligned and of course the idea of making blog posts about it is to get feedback (if this was developed in isolation it wouldn’t get anywhere) and see how practical or useful this is.

I generally agree that we should keep style out of the source format. I suppose the one thing I am considering reuse of some of the XSL-FO ideas of page regions (before,start,end,after,body) for webpages. It would optional, but it would look something like this…

<page>
  <top>header</top>
  <left>menu</left>
  <middle>body content</middle>
  <right>sidebar</right>
  <bottom>footer</bottom>
</page>

To effectively straddle XSL-FO you need to be able to do that, and the semantics work well (I think) for HTML, XUL and especially the headers and footers of ODT (ODF). Although these page regions have no semantic meaning I think they’re good approximations of the output format structures and it seems good to have a standardised taxonomy. An alternative would be to not enforce a naming convention and to expect the user to do some post-processing to arrange their nodes, Eg, to have a page of <section id=”top”>header</section> …which comes through to HTML as… <div id=”top” class=”section”>header</div> …but that seems to be a rather pointless abstraction/indirection.

This is a bit of a combined response to your previous posts on Pilferpage as a whole. From an information science (library) perspective, the idea of a single-source, higher-level language for producing multiple outputs is nothing new. When you ask “What would a source format that straddled all these formats look like?”, my thought has always been that a (purely) semantic XML format would be the answer. Moreover, I would expect the elements of this source format to be the natural union of all the target formats (ie. in order to support column headers in one of the target formats, they would have to be definable in the source format); although the argument could be made to use the intersection for simplicity or an initial version.

You may also find that part of the “separation of concerns” problems in HTML actually arise from the fact that pretty well all flavours of HTML are mixed semantic-style formats (eg. containing which is semantic, and <b>, <i>, or which are stylistic). There are plenty of legacy and human-factor reasons for this, but the net result in my opinion is that it confuses things — are you marking up document structure or style? We’re wrestling with much the same problem in Lemon8-XML, and how to balance users’ expectations of WYSIWYG editing with the need for them to actually edit in a WYSIWYM fashion.

I also think, having worked a long time ago with Cocoon and Popoon (and of course Docvert), that the XML/XSLT pipeline approach is a very powerful one, especially if you can piggyback on existing XSLT mappings (crosswalks) that have been written by others. In many cases, there is a “dumbing-down” (ie. loss of information) in these (eg. converting from, say, Docbook to HTML) but it sure beats writing everything from scratch. Unfortunately, I don’t have a good answer for an appropriate source format — I’ve tried to stick behind the NLM Journal Publishing DTD, if only because it is well-documented, well-used, and highly semantic (ie. very little style-based markup). Perhaps more importantly, it seems able to represent any type of complex document (including rich metadata); and there are already XHTML and XSL-FO XSLT available.

We’re about to spend some serious time sitting back and digging much deeper into this issue at PKP, since it has some major implications for L8X development, as well as some partnerships with publishers and epresses around the world. It would definitely be great to share your ideas and experience on these issues as we try to figure it out together.

MJ