A Family Affair

XML-Based Rendering Languages

Similarly, an XML document is, more particularly, an implementation of a domain language. We should not forget that XML is a meta language that allows you to create a particular domain language. XML does not specify the vocabulary per se, but it provides some syntax rules. It's like having all the spoken languages of this world being based on the same alphabet and the same basic grammatical rules, but being spoken with different words and different inflections.

This week, we'll take a closer look at a particular family of XML-based domain languages: the rendering languages. These languages' vocabularies represent visual or audible objects. Interpreters of rendering languages take as input an XML-based rendering language, transform its elements into visual or audible objects, and make these objects accessible to our senses. We are used to calling these interpreters browsers or viewers, but, to be more precise, let's call them rendering language interpreters.

Presenting the Family: XHTML

The eldest son of this proud family is XHTML, who's just coming out of his difficult adolescent years. We used to call him HTML, but he no longer likes that name. Some say that XHTML is still in a teenage crisis.

XHTML became a rendering language by tradition, not by design. The people behind the Mosaic browser decided how a <h4> or a <p> element should look. Then Netscape and Microsoft built on the Mosaic heritage. It wasn't decided by a committee, nor set down in a recommendation. Nowhere was it explicitly mentioned that an <h4> element is displayed by default with this particular font, size, or any other visual characteristics. HTML became a de facto rendering language. When it grew up and became XHTML, it inherited the same visual characteristics it acquired in childhood.

Increasingly in web development, the XHTML language will become important in the context of using the XSLT transformation language. XSLT is used, as you know, to transform an XML tree into something else. This "something else" may be an XHTML tree.

Client-side transformations

When the transformation from XML to XHTML occurs at the client side, the browser requires:

• an XSLT engine to transform the XML document into XHTML
• an XHTML interpreter to parse, interpret, and display the visual objects

Thus, the browser includes at least two interpreters. (In most cases it has a third, non-XML one -- the CSS style interpreter.)

Now, what about the document model? How do client-side transformations affect your ability to script your document in a browser? Using XHTML as a rendering language, there are potentially three XML documents that can be accessed on the client side, after an XML document is transformed into XHTML using XSLT:

1. The original XML document
2. The XSLT document
3. The XHTML document

Microsoft's Internet Explorer 5, currently the only browser in which client-side XSLT transformations are practical, provides access to all three documents from the same document model. If a JavaScript has to access one of these documents, it can do so using the document object -- the document object being, of course, the XHTML document, as a result of the XSLT transformation (not totally XHTML compliant, but let's keep that for another story).

To access the XSLT document (itself an XML document), we simply have to use a JavaScript expression like TheXSLTDocument = document.XSLDocument. Similarly, the XML document can be accessed with the TheXMLDocument = document.XMLDocument. The resultant XHTML document object includes the XSLT and XML documents as components.

We ought to mention here that IE is not yet compliant with the XSLT 1.0 recommendation. Of course, we all know that IE is still an evolving species. What is interesting in the Microsoft implementation is the fact that the three documents are available from the scripting language. The scripting language can dynamically change at run-time any of the three XML document object models.

Let's hope that the DOM3 working group will take into account more sophisticated structures like this, and that the next DOM3 recommendation will bring a standard way to access multiple DOM or sub DOMs or, put differently, to access the components of a new breed of compound documents as presented above.

SVG

Now let me introduce to you another W3C offspring with a promising future: SVG (Scalable Vector Graphics). The SVG language has been designed from the ground up as a rendering language. Each of its visual objects are defined in a recommendation. As is the case for XHTML, an SVG interpreter decodes and renders the SVG visual elements. But the visual capabilities of SVG outshine those of XHTML.

In addition to being a rendering language, SVG also offers an API that can be used to directly manipulate the SVG visual objects. The SVG recommendation introduces new interfaces to be added to the default XML DOM interfaces. Thus, for instance, an SVG <path> element is:

• a Node object
• an Element object, since the Element interface inherits from the Node interface
• an SVGElement object, since this interface inherits from the Element interface
• an SVGPathElement object, since this interface inherits from the SVGElement interface

Thus an SVGPathElement inherits the characteristics of several parents, and presents a more sophisticated object model. A path element's object counterpart offers XML DOM and SVG DOM interfaces.

Again, if an SVG fragment is embedded in an XHTML document as the result of an XSLT transformation, we end up with a pretty sophisticated document object model.

XSL

Another family member is named XSL. It is also known as "XSL-FO." This rendering language has been designed from the ground up to provide a visual model for documents. It has no special DOM and actually can only be interpreted, or its elements accessed, with the default XML DOM. Its visual objects allow quite sophisticated page layouts. I got into an interesting discussion about this topic with Jon Smirl, an XML-DEV community member, over the suggestion that an XSL-FO implementation could be made to use the SVG DOM to visually render the XSL-FO elements. An interesting point of view, and one which highlights the fact that a rendering language that also offers an API can be used as a tool to implement an interpreter for another rendering language.

WML

Time for us to meet the noisy kid of the family. This kid is growing rapidly, and his exploits are making the news headlines. They're becoming more and more well-known, especially in Europe where the cell phone market is booming. You probably recognize what I am talking about -- WML (Wireless Markup Language).

With WML, we are in the land of "visual efficiency." This language uses the card metaphor to download several pages at a time into a cell phone. Because of the reduced rendering capabilities of cell phones, this language does not offer a rich visual model, but a model sufficient to render the information in the most efficient way when only a couple of text lines can be displayed.

Audible Rendering Languages

Finally, the hoped-for child in the family is an audible rendering language. Several proposals are still on the table, but there are not yet any official W3C recommendations. Let's hope that this year we'll have a new-born rendering language. "Why?" I hear you ask. Simple enough. I do not want to be in front of a motorist who reads his web pages on a visual browser. I'd prefer one that listens to his web pages.

Conclusion