What's the Big Deal With XSL? (sections 3 and 4)
April 22, 1999
3 CSS - A Great Standard for What It Does
|
The original CSS Level 1 allowed overriding the presentation semantics of HTML tags. This, combined with the semantic-free grouping constructs for divisions <DIV> and spans <SPAN> of HTML 4.0, gives the ability to paint the browser screen as desired with the tree of source information.
Both CSS Level 1 and the more recent and powerful Level 2 can be used for the rendering of XML as described in last month's article by Tim Bray. Note the semantics of style that can be expressed in CSS have a heritage in the display media, though aural rendition is also available.
While CSS is a powerful tool for rendering of XML, it is not aimed at the transformation of the source information prior to its rendering. Limited facilities to attach ornamental text and images to the document tree before rendering are available, but CSS does not give one the power to rearrange components of the document, collate and sort selected components of the document, or decorate the rendered tree with rich information.
In essence, when using CSS the organization of information for rendering is very tightly bound to the organization of the XML tree. So, for those applications which only need to decorate the document as it is, CSS does the job.
4 XSL - A Great Standard for What It Can Do and Will Do
Despite the problems with the implementations available today, XSL has a lot to offer the XML community.
|
XSL describes two vocabularies: one vocabulary for transforming information from source to result hierarchy, and a second vocabulary for expressing the semantics of XSL formatting.
Both inputs to XSL, the source document of structured information to be styled plus the stylesheet describing the styled result, are themselves XML documents. These documents can employ all the features of XML document description, thus they can be created using typical XML tools and be physically structured as any other XML document. However, XSL is defined in terms of operations on the abstract tree structures in the documents, not their actual XML syntax.
The XSL transformation engine produces a structured result tree of information. (Note I didn't say "result document"; XSL thinks in terms of trees, not angle brackets.) This output tree could take the form of XSL formatting objects to be rendered to hard copy, to a screen device, using an aural rendering device, etc. Alternatively, the output could be in some other format such as HTML.
The XSL Processing Model Overview
What information can be found in this result tree? Any ornamentation you have included or referred to in your stylesheet and anything you want from the source tree, in any order and any number of times you need. The stylesheet transforms the source tree essentially "by example", where templates of the output markup are labeled for processing by the XSL engine, and "call in" information from the source tree.
Consider this article you are reading. In the XSL rendering I created for consumption, you can read a table of contents at the start, the body of the article in the middle, and at the end an index of sections, two summaries of the external links used in the article, and a summary of all the side bars. If you look at the XML version of the article, you will find only the body of the article and nothing else. The stylesheet contains templates of all the output fragments and the use of XSL instructions creates the generated tables of information with live links.
Note also that internal references are richly rendered with information found indirectly using XML's ID and IDREF attribute types. XML's ID/IDREF facilities give unique addresses to document structures and are very useful in a variety of rendering tasks.
Through the transformation vocabulary and the formatting vocabulary, XSL gives the stylesheet writer control of both components of styling: transformation of the content and rendering of the content.
4.1 Conformance
At this early stage of the development of XSL, implementations vary a great deal, using differing vocabularies and also attaching different semantics to the same vocabulary. Perhaps this is to experiment with concepts being proposed to the committee, or perhaps to leverage an existing installed base of product or customers. To illustrate the differences, I've used two different stylesheets to prepare this article, one conforming to Microsoft's IE5 5.00.2014.0216 implementation for direct viewing of the XML, and one conforming to W3C Working Draft 19991216 to produce the static HTML.
It is incumbent upon us, users of stylesheet products, to expect, indeed to insist upon conformance to the W3C recommendations as written. As the design of XSL nears completion, we need to impress this upon the vendors. As the time for experimentation comes to an end, we need to be assured of portability between products, adherence to standards, and a commitment from the vendors to support published recommendations.
4.1.1 Accommodating Incompatibilities to Conformance
XSL provides a technique, based on namespaces, for accommodating incompatibilities among experimental versions of XSL within a stylesheet otherwise conforming to the working draft. This method can also be used after the recommendation is published to support vendors wishing to offer their users features above and beyond the bounds of the XSL recommendation.
Unfortunately, this technique isn't yet being used and I think we, as users, must insist that something be done by vendors before we get a large installed base of incompatible and non-conforming stylesheets in our community.
XSL identifies the transformation vocabulary using a namespace whose Universal Resource Identifier (URI) is http://www.w3.org/TR/WD-xsl. As a stylesheet writer, I anticipate that stylesheet directives from this namespace will work as described in the W3C specification. If an engine supports additional functionality, I feel it is the vendor's responsibility to place this extended vocabulary in their own namespace with its own URI.
This is not the case at this time. Today I can write a stylesheet according to the W3C working draft and not have it function correctly, even with products using the W3C namespace. I can also invest a lot of time in a stylesheet that works with one vendor's product, only to discover unexpectedly the stylesheet doesn't run in another vendor's XSL engine. I would hope that by the time XSL is complete, vendors will provide their own namespaces for their proprietary features, and I will be allowed to use the W3C namespace when I want a product to follow the W3C rules. Any other situation does not serve me, a stylesheet writer, because I can inadvertently write non-portable stylesheets. I have no problems with using non-portable functionality as long as I'm aware I'm doing so and I'm doing so in an unambiguous fashion.
At trade shows and in private correspondence I've been pushing vendors to consider how using this technique will protect their stylesheet writer users, and I've received only a mixed response. I would encourage others to talk with their vendors about how their own investments in stylesheet writing will be protected.
4.2 Features of Note in this Article's Stylesheet
The XSL stylesheet for this article has some features that are worth a close look. I've chosen to translate my XML document into an HTML document, primarily using <DIV> and <SPAN> with CSS style semantics and syntax, though I did use a number of HTML constructs to accommodate legacy browsers.
Note the use of entities (declared in the DTD, referenced in the document). This allows me to parameterize the CSS output with entire rule settings or just individual values. As well, I've parameterized some of the boilerplate. In other applications where I've used external declaration subsets of parameter and general entities, parameterization has been a successful method of supporting a number of different stylesheets with a single set of stylesheet source.
In the <xsl:stylesheet> instruction I'm asking the XSL engine to emit the result tree as an HTML instance. I'm making the default namespace that of HTML, so no prefixes will be required on ordinary HTML elements:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"
xmlns="http://www.w3.org/TR/REC-html40"
result-ns="">
The stylesheet provides the skeleton of the HTML document which contains instructions from the XSL transformation vocabulary that obtain the information from the source tree. Information is explicitly accessed using "select patterns" to describe locations in the source tree, as in this example where I obtain two values from the source tree to make the <title> meta data of the page:
<title><xsl:value-of select="/article/title"/> - <xsl:value-of select="/article/author/name"/></title>
The remainder of the stylesheet is a collection of templates of output, labeled for the XSL engine by the "match patterns" describing candidate locations of the source tree.
<xsl:template match="author"/> <!--author of document-->
<!--don't show in parse order, shown with title-->
<xsl:template match="extlink"> <!--an external link-->
<a><xsl:attribute name="href">
<xsl:value-of select="@href"/></xsl:attribute>
<xsl:apply-templates/></a></xsl:template>
<xsl:template match="intlink"> <!--an internal reference-->
<a><xsl:attribute name="href">
#<xsl:value-of select="@idref"/></xsl:attribute>
<xsl:value-of select="id(@idref)/title"/></a></xsl:template>
Note above how for the <intlink> element (which is declared EMPTY) the XSL processor indirectly obtains the title of the element to which the link points through the IDREF attribute. Thus, when the element is used, the title of the section being hyperlinked to is inserted in the text at that point. This guarantees consistency and prevents me from having to write the title of the section in the prose where it is referenced.
There are a number of coding differences in the two stylesheets that are required by incompatible implementation differences, but one difference was programmed in to meet rendering requirements. Note in the W3C stylesheet used to create the HTML view of this article that all side bars are rendered. In the IE5 stylesheet targeted for on-line XML viewing, those sidebars indicated through an attribute to be suppressed for XML rendering are transformed using an empty template, thereby adding nothing to the result node tree for formatting.
Lastly, note how I traverse the source node tree numerous times to produce tables of content, indexes of content and summary tables, all in addition to the traversal used for the main presentation of the body of the content. This is all processing offloaded to the browser and taken away from the delivery machine and the bandwidth of the connected pipe. The HTML version of this article is approximately 86Kb, while the XML version of this article is approximately 41Kb.
4.3 What Products Supporting XSL Can Do Today
All of the XSL products available today support the transformation vocabulary to some extent. Many of these are very robust and ready for prime time, even using the Working Draft syntax. An important caveat is that any and every implementation that exists today is bound to change because the development committee hasn't finalized the transformation vocabulary or semantics.
I know of only one experimental implementation of the formatting vocabulary, James Tauber's Formatting Object Processor (FOP), but he acknowledges the Working Draft's definition of XSL Formatting Objects is incomplete. We are all awaiting the next Working Draft where we hope to find the first draft of a complete set of formatting objects.
4.4 What Products Supporting XSL Will Be Able To Do Soon
One of the most exciting aspects of XSL is the Formatting Object vocabulary. Rendering engines for the formatting vocabulary will be able to present our structured information to hard-copy devices, screen devices, aural devices, and any other form of presentation people may conceive of. This means that stylesheet writers will be able to write a single stylesheet for all renderings and not have to create a stylesheet with formatting semantics for print and a stylesheet with CSS semantics for display.
The objective of the stylesheet writer when using the formatting vocabulary is to transform the source information into a result tree comprised exclusively of formatting objects. The formatter then reads the instance of formatting objects without any knowledge of the source tree and renders the stylesheet writer's specified results.
At the recent XTech'99 conference, attendees heard an announcement regarding US$30,000 and US$60,000 bounties being offered by Sun and Adobe for screen and hard-copy device implementations of formatting objects.
The semantics of formatting objects are not limited to display properties and their values. In addition, the current Working Draft describes the concept of queues of information the stylesheet writer builds from the source data. Conditions triggered within the formatter by different criteria in the formatting object instance cause these queues of information to be processed or reprocessed on a repeated basis.
These powerful semantics will give us the ability to write very expressive stylesheets for the rendering of our information across different devices, far more expressive than can be supported by the semantics of other formatting languages.
4.5 What Can Be Done For Hard Copy In The Meantime
Yet another option for rendering XML information to hard copy today, is using the Document Style Semantics and Specification Language (DSSSL - ISO 10179:1996). For those who are familiar with the style semantics standardized in DSSSL, James Clark's JADE can be invoked with a well-formed XML instance and rendered with all the implemented back ends targeted for hard-copy devices.