s you can see, distilling out the logical core of the document and expressing it in XML is relatively easy once you stick to the principles of modular HTML.  But what about presentation?  Do we have any chance of reusing the immense design heritage now expressed in HTML and, in particular, can we carry over the formatting of existing modularized Web sites to XML anywhere as painlessly as we can do it for its structure?

XML was conceived as a logical markup system strictly orthogonal to (i.e. independent of) any stylesheet language it can be used with.  For visually unsophisticated documents, CSS2 is likely to become the language of choice.  However, even the relatively simple formatting such as that of the "framed heading" on the Object International site the capabilities of CSS are insufficient.  Recognizing this deficiency, W3C is now developing a new stylesheet language called XSL particularly for use in conjunction with XML.  Now in the state of a working draft, XSL is expected to become a standard by December this year.

One of the ancestors of XSL is DSSSL, a complex and well-established stylesheet language developed for use with SGML.  Probably the most important idea inherited by XSL from DSSSL is the transformation stage of processing XML documents before any visual or, in general, presentational machinery is set into motion.  At the very first stage of applying an XSL stylesheet to an XML document, the original hierarchical tree of XML elements is transformed into another tree using pattern-and-action declarations of the stylesheet.

The important thing is that the new document resulting from such transformation can be absolutely arbitrary, with the only restriction that it must itself be correct XML.  The transformed document can use any tags with any possible meaning, it can freely rearrange the original document's content, select some parts of it and drop some others, or add any content of its own (thus implementing the concept of generated content).  This makes XSL a perfect tool for various document management and conversion tasks.  In particular, it can be used to automatically convert XML back to modular HTML.

Indeed, it's easy to construct an XSL stylesheet transforming all instances of the FRAMED-HEADING element into corresponding HTML modules they were derived from, inserting the content of the elements (i.e. the text of the headings) where they belong in the modules.  After this is performed, all we need to do is to feed the HTML code produced by the stylesheet to the good old HTML formatting engine of the browser. XSL specification does not require this "feeding" behavior from XSL implementations, but it is likely that XSL engines built into common graphic browsers will provide this feature.

At least one demo of this technology is already available.  Microsoft has developed an ActiveX control transforming XML document into HTML as specified by an attached XSL stylesheet.  Results of this conversion can be "pasted" into the currently displayed HTML document to be interpreted by the standard HTML layout engine of the browser.  (I will not present here an XSL example for my FRAMED-HEADING illustration because the XSL syntax used by the Microsoft implementation is different from that of the current W3C draft, which itself is not altogether stable.)

Check out an XSL demo developed by ArborText, Inc. Currently viewable only in Microsoft Internet Explorer 4.0, this demo will download and install the Microsoft XSL ActiveX control on your system (if it's not yet installed).  Then, you can select combinations of two sample documents with four different stylesheets which exemplify extracting parts of documents and simple formatting changes.  The HTML produced by these stylesheets is in no way "modular" as defined by this article---in fact, it is pretty much what I called academic HTML, but this difference is not critical: with XSL, you can transform your XML into any syntactically (but not necessarily semantically) valid HTML.

One conclusion that we can draw from this story is that a standardized technology is an important, but not necessary condition for implementing some abstraction which is just ripe for implementing. People will always find workarounds with existing tools (in our case, HTML), sometimes not even realizing what they're striving for. By using and promoting the modular approach, we're paving the way for an easy and painless transition to XML.