XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.

advertisement

What's New in XSLT 2.0

April 10, 2002

In my previous article, I went through a brief overview of some of the features that XPath 2.0 offers over and above XPath 1.0. We saw that XPath 2.0 represents a significant increase in functionality for XSLT users. In this article, we'll take a look at some of the new features specific to XSLT 2.0, as outlined in the latest working draft. Again, this assumes that you are familiar with the basics of XSLT/XPath 1.0.

XSLT 2.0 and XPath 2.0

XSLT 2.0 goes hand in hand with XPath 2.0. The two languages are specified separately and have separate requirements documents only because XPath 2.0 is also meant to be used in contexts other than XSLT, such as XQuery 1.0. But for the purposes of XSLT users, the two are linked together. You can't use XPath 2.0 with XSLT 1.0 or XPath 1.0 with XSLT 2.0. (At least, the W3C is not currently proposing any such combination.)

Note

Ever wonder what happened to XSLT 1.1? It's been canceled. Officially as of August 2001, and actually as of a number of months before then, the XSL Working Group ceased work on XSLT 1.1, instead focusing its efforts on the development of XSLT and XPath 2.0, carrying forward the requirements for XSLT 1.1 into the requirements for XSLT 2.0.

A Welcome Arrival

A new version of XSLT has been heavily anticipated in the XSLT user community for some time. As is true with the first versions of many languages, it did not become clear which extensions to the language would prove to be the most important until there had been some real-world experience with it. Since November 16, 1999, when XSLT 1.0 became a recommendation, it has become quite apparent that certain areas of missing functionality are due for inclusion in the next version of the language. In this article, we'll show how XSLT 2.0 addresses four of these areas.

  • Conversion of result tree fragments to node-sets
  • Multiple output documents
  • Built-in support for grouping
  • User-defined functions (implemented in XSLT)

Death To the Result Tree Fragment!

Related Reading

XSLT

XSLT
By Doug Tidwell

In XSLT 1.0 the result tree fragment (RTF) type is like a node-set, but it is really a second-class citizen. An RTF is what you get whenever you use xsl:variable to construct a temporary tree. The problem is that you can't then use an XPath expression to access the innards of this tree, unless you use a vendor-specific extension function, usually called something like node-set(), to convert the RTF into a first-class node-set (consisting of one root node). The rationale for the RTF data type was that it would reduce implementation burden, but since almost all existing XSLT processors provide their own version of a node-set() extension function anyway, that consideration has become moot. In any case, the need to overcome this limitation has been clear for some time, as it is important to be able to break up complex transformations into sequences of simpler transformations.

If you haven't guessed already, XSLT 2.0 has shown RTFs the door. Now when you use xsl:variable to create a temporary tree, the value of that variable is a true node-set. Actually, in XPath 2.0 terms, it is a true node sequence, consisting of one document node, which is XPath 2.0's name for what XPath 1.0 called a "root node". With that sequence you can then use path expressions to drill down inside the tree, apply templates to it, and so on, just like you would with any other source document. With XSLT 2.0, there is no longer a need for the node-set() extension function.

Enabling Multiple Output Documents

Comment on this articleWhat do you think of the new features in XSLT 2.0? Share your views with others in our forum.
Post your comments

Another extension which many XSLT 1.0 processors provide is support for multiple output documents. This extension has proven very useful, especially for statically generating web sites containing multiple pages. The problem with extensions is that they aren't standard. Each XSLT processor has a different extension element for doing this, e.g. saxon:output, xt:document, etc.

XSLT 2.0 provides a standard way to output multiple documents, using the xsl:result-document element. The following example stylesheet constructs multiple output documents, one "principal result document" and a variable number of "secondary result documents". The principal source document will be serialized as XHTML, and the secondary result documents will be serialized as text.

<xsl:stylesheet version="2.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns="http://www.w3.org/1999/xhtml">

  <xsl:output method="xhtml"/>
  <xsl:output method="text" name="textFormat"/>

  <xsl:template match="/">
    <html>
      <head>
        <title>Links to text documents</title>
      </head>
      <body>
        <p>Here is a list of links to text files:</p>
        <ul>
          <xsl:apply-templates select="//textBlob"/>
        </ul>
      </body>
    </html>
  </xsl:template>

  <xsl:template match="textBlob">
    <xsl:variable name="uri" select="concat('text', position(), '.txt')"/>
    <li>
      <a href="{$uri}">
        <xsl:value-of select="$uri"/>
      </a>
    </li>
    <xsl:result-document href="{$uri}" format="textFormat">
      <xsl:value-of select="."/>
    </xsl:result-document>
  </xsl:template>

</xsl:stylesheet>

The href attribute of xsl:result-document is used to assign the URI of the corresponding output document. For many processors, this will mean writing the document to a file with that name. The format attribute refers to a named output definition. In this case, it points to the xsl:output element that we appropriately named textFormat.

Another thing worth noting from the example aboveis the use of the XHTML output method, newly introduced in XSLT 2.0.

Pages: 1, 2

Next Pagearrow







close