What's the Big Deal With XSL?

April 22, 1999

G. Ken Holman

What's the Big Deal with XSL?

1 Introduction

I believe that XSL is indeed a big deal; exciting stuff (to the extent that formatting software can be). In this article, I will share my excitement with XSL and my perplexity about the perceived controversy over XSL and Cascading Stylesheets (CSS).

It is not my intention in this short article to try to teach you how to write the syntax of XSL. I'm trying for an overview to help you understand the role that it plays, the relationship of this technology to other technologies, and the direction XSL is going. I've included pointers to places where you can learn more about the nuts and bolts of XSL. Finally, I've used two different implementations of XSL (unfortunately requiring two different stylesheets when there should only be one; more about that later): one to create an HTML 4.0 version of this article, the other to display the live XML.

1.1 Caveats

Off the top I'll share with you that my bugaboo regarding stylesheets (or any other development project) is maintenance. When writing a stylesheet for myself, and especially when writing one for others, planning for future maintenance, tweaking and modification is key. XML and the World Wide Web Consortium (W3C) XSL features supporting the maintenance of large stylesheets gives us, the stylesheet writers, a platform upon which we can build robust and maintainable works.

I'll confess that the stylesheet used to present this article is a bit over the top regarding indexes and cross references, as these illustrate the rich presentation power of XSL. As a result, the rendered HTML version of this document is quite lengthy, but the information in the article, when transmitted to the browser as XML, is much smaller (less than half the length of the HTML).

The development of the XSL recommendation is still in the formative (though not infant) stages. The working drafts are described below and the information contained herein is up to date as of mid-April 1999. For information on further developments of this recommendation, please pursue the links listed below under Where to Learn More About XSL.

2 The Processes of Styling Information

I think about styling structured information as comprising two major processes: transforming the source information into the organization desired for rendering, and rendering the organized information into the presentation desired for consumption.

The latter of these, the rendering of information, itself has two major components: the semantics of style interpreted by the rendering engine (what effects you can achieve) and the expression of those semantics (what the stylesheet looks like).

The XSL developers are addressing this latter process by actively contributing to the W3C Common Formatting Model and have incorporated CSS2 semantics in the XSL formatting semantics. XSL also addresses the former process with powerful transformation facilities to organize our information for rendering purposes.

The controversy I alluded to in my introduction is the loud ruckus heard lately of "why have XSL when we already have CSS"? There need not be controversy. When I use XSL now for styling to the screen (as I have for this article) I use XSL for transformation and generate ordinary CSS semantics and syntax for rendering. The (still-incomplete) XSL formatting facilities will be a superset of CSS semantics and will be in an XML syntax to accommodate the extra functionality required for the powerful semantic concepts being devised. Current users of CSS semantics and syntax, who are satisfied with the functionality provided therein, can continue to use XSL transformation to render their information to HTML/CSS or XML/CSS. Where's the problem?

This has long been recognized by the W3C and the note Using XSL and CSS Together presents their perspective in a public document.

3 CSS - A Great Standard for What It Does

Cascading Stylesheets is an excellent technology available today for rendering a particular organization of information to a browser screen.

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.

From the beginning of its design process, XSL has had the goal of solving the problems both of structured information transformation and structured information rendering. In fact, of providing rich vocabularies that solve the whole presentation problem.

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.

5 Internet Explorer 5 - A Flavor of XSL for the Desktop

It is exciting to have access to a developing technology early in its life, and the release last fall of Beta 2 of IE5, followed by the March 1999 release of the first complete version of IE5 provides it. The MSDN XSL Pages link to all the information required to work with the XSL support in this product.

Be warned, however, the Microsoft implementation of XSL differs from the W3C Working Draft in a number of places. In the Microsoft documentation suite the page http://msdn.microsoft.com/xml/xsl/tutorials/conformance.asp overviews Microsoft's assessment of the differences between the W3C Working Draft and IE5's implementation of XSL. With this page, Microsoft has an opportunity to keep us all up to date with discoveries of other differences not yet listed.

IE5 supports the W3C Stylesheet Association processing instruction for linking XML files directly to stylesheets. This requires the XML file to have the name of the stylesheet embedded. A new W3C recommendation I'd like to see developed is some kind of syntax for Universal Resource Locators (URL) that will encode the stylesheet association in the hyperlink. This would allow me to create a page with many references to a single XML file, each URL encoding a different XSL stylesheet with which to view the XML.

IE5 supports scripting in XSL, which can be very powerful when working with the Microsoft Document Object Model (DOM). Unfortunately, scripting hasn't yet been included in the XSL Working Draft, so any scripting written for IE5 will not work on other products. A number of built-in functions specified in the Working Draft are only implemented via scripting in IE5, thus most stylesheets will not be compatible.

You may have noticed in this article that I've chosen to use the suffix ".msxsl" for my XSL stylesheets for IE5. This allows me to distinguish files written for the Microsoft XSL engine from files written for engines supporting the W3C Working Draft, since (at least for now) they are always different. The Microsoft convention is to use the suffix ".xsl" for XSL files, but I find this misleading. I hope the differences in XSL implementation will all be gone when the final recommendation is released (we can always hope, can't we?) and then we wouldn't need to distinguish our stylesheets.

If there remain any differences in the transformation vocabulary or the semantics of the vocabulary as implemented by Microsoft, I hope (again!) that Microsoft consider distinguishing their custom semantics using their own namespace using something along the lines of:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl"

                xmlns:msxsl="http://www.microsoft.com/msxsl"

                xmlns="http://www.w3.org/TR/REC-html40"

                result-ns="">

With the above declaration I could use <msxsl:eval> and <msxsl:script> (since such constructs aren't available in the 19981216 Working Draft) and <msxsl:apply-templates"> with nested templates (since the use of nested templates is not available in the Working Draft, which instead uses the mode= attribute that isn't available in IE5). By writing my stylesheets using two namespaces for transformation, I distinguish those semantics I expect from the Working Draft from those semantics available to me in IE5 without risking unanticipated portability problems by ambiguously using a single namespace. A new user might quickly recognize the first two constructs above as being unique to Microsoft, but may not recognize any nuances about the implemented differences to the W3C semantics for <xsl:apply-templates>. If it seems I'm harping on portability a lot, it is because I think it is incredibly important and could be a barrier to wide acceptance.

In this article I've chosen to write my stylesheet with a target of HTML constructs for both the ornamentation and information content, and CSS style semantics for rendering control. I could have chosen to have my stylesheet produce a target of XML constructs for the ornamentation and information content, and then use CSS style semantics for rendering control, but I was satisfied with the screen painting abilities of <DIV> and <SPAN>. Choosing HTML as my output also gives me an avenue to support HTML/CSS browsers not supporting XML by creating a static HTML/CSS file using the stylesheet.

5.1 The XMLNews Stylesheet Viewer

Recently, I have designed XSL stylesheets for XMLNews, a new initiative that includes a subset of the News Industry Text Format (NITF). I was excited to see what I could do with XML data files (files listing only names of other files, without prose or monologue) and stylesheets using IE5. For the XMLNews project I modified an HTML-based viewer to be triggered from XML using XSL stylesheets.

This snapshot of the XMLNews stylesheet viewer may be updated by the time you read this. New test files and test stylesheets are being created on an ongoing basis. Any updates to this viewer will be made available through the XMLNews web site. This example included with this article is only a preliminary release of a few example stylesheets, but the essence of the processing can be seen.

The viewer.htm file sets up the frames and displays the collections.xml XML file listing the collections of data files and stylesheets. Each XML file describing a collection of files is associated with an XSL stylesheet that renders the list of data files and the list of stylesheet files in two columns of a table. This stylesheet also has the scripting logic to load the given XML and XSL files selected into Microsoft DOM objects and render the one with the other, with the result going to the frame on the right of the canvas.

What was exciting about this was that once each of the stylesheets were written, I was then able to create collections of test files of XML and XSL and simply change the XML control files without needing to touch any of the stylesheet files.

For the electronic magazine appearances, I contracted an artist to create layout mockups in HTML for a given story. For each layout I stripped out the story content from the HTML, replaced it with XSL transformation vocabulary instructions, and wrapped it up in an XSL framework. The HTML I received from the artist became the example for my "transformation by example", and my job was to indicate where content belongs in the supplied example. Running the resulting XSL stylesheet on the XML data then accomplished the transformation of the content into a result mimicking what arrived from the artist, but for every story, not just the mockup she created for one story.

6 The Working Draft of the W3C Recommendation for XSL

I find it exciting that many features of the W3C XSL promote maintainability and flexibility in stylesheet writing. These features are in addition to the modularization of the logical and physical structures of the XSL files in XML syntax using XML features of general entities, external parameter entities and marked sections.

When writing a stylesheet, the additional use of XSL constructs for declared constants and macros (templates of stylesheet code with arguments) will allow the logical structure of the code to be compartmentalized and centrally supported.

Modularizing the Logical Structure

When sharing stylesheets, or creating multiple files to help with maintenance, XSL supports both including (logical tree insertion) and importing (ascribing precedence) of whole stylesheets. This leverages one's investment in stylesheets by allowing them to be reused in different scenarios.

Modularizing the Physical Structure

The next Working Draft promises to bring a number of new features to the transformation vocabulary, based on the experiences of those working with preliminary releases of XSL-based tools. The current vocabulary allows the stylesheet writer to explicitly direct the processing of nodes in the source tree on demand. In addition, one can set up node event handling for nodes and then submit portions of the source tree to the XSL engine for node event processing can be done when the order of the source tree nodes isn't known or the stylesheet needs to be flexible for alternative orderings (perhaps because the stylesheet is being shared by other stylesheets).

The ability to select the nodes for direct processing or for passing to the XSL engine for indirect processing gives the stylesheet writer the flexibility to order information by element type name, attribute name, or any node in the source tree. In addition, sort functionality instructs the XSL engine that the order of source nodes be sorted before being processed. With these basic controls information in the source tree can be traversed as many times as required to produce the desired result.

The 19991216 Working Draft describes a set of Formatting Objects and their semantics without, yet, being complete. It is acknowledged in the document that a future Working Draft will flesh out the details required for implementation and stylesheet writing. Nonetheless, the concepts (such as queues) are very interesting. Moreover, it is clear the designers of the semantics have a thorough understanding of the needs in this area. An editor's note in the document notes the committee is developing input to the W3C Common Formatting Model and is providing the semantic model in terms that XSL can be described.

7 Where to Learn More About XSL

As with so many XML-related resources, Robin Cover's pages on the Organization for the Advancement of Structured Information Standards (OASIS) site http://www.oasis-open.org/cover/xsl.html is a valuable resource for XSL information.

To participate in a mail list discussion of XSL issues, Mulberry Technologies is hosting http://www.mulberrytech.com/xsl/xsl-list/ where contributors can post questions, answers or opinions about anything related to XSL.

Over the last week I solicited from the list some contributions for XSL-related links for learning more about the technology. Below is what I got, sorted by URL. I haven't checked all of these sites so I cannot vouch for their authenticity, but you may wish to surf and find out. Not as many people responded as I had expected, but the few that I have seem to have a large number of links (many duplicates but the union set is quite informative). I have noticed some of the newsy articles use outdated or outright incorrect syntax examples, but the prose appears to be well intentioned.

8 Conclusion

Today, your choices in rendering your XML information for consumption are quite clear. With Cascading Stylesheets you can decorate your XML document hierarchy for rich browser painting.

Today, with the Extensible Stylesheet Language you can re-organize your XML document hierarchy into a rich hierarchy for consumption and still apply the semantics of CSS styling for rich browser painting. Investments in learning at this early stage of changing specifications will hold you in good stead for the final version of the recommendation, but remember for production issues it is still a moving target until it is finalized. When it is finalized, remember to hold your vendors to the recommendation to protect yourselves and your customers and users.

Soon, with the completion of the development process, you will be able to re-organize your XML document hierarchy into a rich hierarchy for consumption and apply the semantics of XSL styling for rich rendering in a portable fashion across browser screens, hard-copy media and other rendering devices.

Exciting!

Alphabetical Table of Sections

Summary of Links (sorted by caption)

Sorted Summary of Sidebars