On a project today one of XML’s paradoxes struck me: we adopt XML for publishing often because we want to re-target our documents to different publications and media; however we then find it useful if the information is organized or formatted similarly on different media and applications, in order to reduce gratuitous differences, ease processing and to increase branding.
So our books end up getting PDA-isms such as small sections, or HTML-isms such as page focus, or RSS/Atom-isms such as chapter and section summaries (It was worth writing this blog for the pleasure of saying “RSS/atom-ism”.) And our HTML pages get book-isms, such as the familiar TOC and next/previous/up buttons. The initial movement for media and publication independence is met by a counter movement for cross-media and cross-publication homogeneity.
…
Rather than thinking in terms of XML documents as ideally being free of particular presentation dependencies (”Just model the Information” was the SGML mantra) it may be more prudent to think of XML as encoding both the raw data and information required by a mythical all-purpose medium. This would explain, for example, why we have generic tables: tables have long been a conundrum for pure markup theorists, because specific markup using lists of named elements and some selection/sorting/styling code should provide much better value…but tables encode this cross-media information which does not violate the separation of content and specific presentations on specific media.
Interesting. We've been modeling the page content of our Web site for a few years now. Users -- publishers -- don't understand the value of a model, especially of such an abstract one such as ours. They resent not being able to specify presentation. The value of such a model becomes evident when we render the content for sight-impaired visitors. Does your model distinguish between decorative and informative images, for example? Does it make explicit the relationship of various page components so they can be "chunked" or reordered? What function do they perform. When we render for accessibility, we don't simply render the HTML of the usual site complemented with the recommendations of W3C, etc. We generate a completely different HTML -- only the content is the same. Presently, the content of the accessible page is the same as that of the "inaccessible" version. In the future, I can imagine restructuring a site for accessibility, so that the content of both versions of the site is the same, but not on a page-by-page basis.
I'd love to see the (approx) DTD or schema you use, or the general details. Mature document types are really interesting, because they show what compromises and frills are needed to make initial blue-sky schemas actually work. But we the public don't get to see many mature in-house DTDs: instead we probably get to see too many public schemas/DTDs, which usually don't start off elegant but which also are not easily changed.
Hey Rick,
Have a look at the source behind http://channelxml.com or http://extf.net/saxon/dotnet/asp.net/liveclipboard/ (although the last one is even more of a work in progress than the first > part of a demo for LiveClipboard that will hopefully be in better shape later today). I've been using unordered lists for the structure of all the work I do now, and have for almost a year. The general idea allows from a MUCH looser, less defined structure which, in this case, then uses CSS to take what would normally look like just an outline, and turn it into some quite a bit more (visually speaking anyway.)
You can take this concept to some pretty cool levels as well -- e.g. using the markup and contained content as the data that then drives the processing and output of something else -- in essence this is just Lisp in angle brackets instead of parenthesis. :)
It's fun to consider media that can be rendered but can't be marked up efficiently. Graphics and sound are two good places to start.
There is no all purpose media if it has to wrap media types. There are boxes and boxes in boxes. The most interesting concept I've had to play with in years has been the nested finite coordinate systems of VRML/X3D because it leads one to consider every thing as space and the things in that space as mere locals to be scaled, stretched and squashed or translated.
Tables are to layout what transforms are to real time space/time.
Then and only then does one get to talk about ontologies of objects in those spaces and how the relationships among the spaces drive the evolution/transformation of the objects and the relationships.
Hey Len,
I couldn't agree more... The more involved I get with ontologies the more understanding I gain into much of what you just mapped out. Thats not to say I understand it all... Just understand enough to recognize that your point is spot on.
This > http://www.xsltblog.com/archives/2004/12/jean_paoli_spea.html < post from a year and half ago showcases a few of the areas that have been my primary focus in this area since well before this post, and continuing forward to now and as far into the future as I can currently see at any given time (about 12ms or so ;) :D
Fascinating stuff!
Trackback to new Dad (congratulations!) Bill de hÓra