XSLT: A System Overview | NetBeansв„ў IDE Field Guide: Developing Desktop, Web, Enterprise, and Mobile Applications (2nd Edition)

This section looks at the nature of the transformation process performed by XSLT, concentrating on the inputs and outputs of a transformation.

A Simplified Overview

The core task of an XSLT processor is to apply a stylesheet to a source document and produce a result document. This is shown in Figure 2-1.

Figure 2-1

As a first approximation we can think of the source document, the stylesheet, and the result document as each being an XML document. XSLT performs a transformation process because the output (the result document) is the same kind of object as the input (the source document). This has immediate benefits: for example, it is possible to do a complex transformation as a series of simple transformations, and it is possible to do transformations in either direction using the same technology.

The choice of Rubik's cube to illustrate the transformation process is not entirely whimsical. The mathematics of Rubik's cube relies on group theory, which is where the notion of closure comes from: every operation transforms one instance of a type into another instance of the same type. We're transforming XML documents rather than cubes, but the principle is the same.

The name stylesheet has stuck for the document that defines the transformation, even though purists prefer to call it a transformation sheet. The name reflects the reality that a very common kind of transformation performed using XSLT is to define a display style for the information in the source document, so that the result document contains information from the source document augmented with information controlling the way it is displayed on some output device.

Trees, not Documents

In practice, we don't always want the input or output to be XML in its textual form. If we want to produce HTML output (a very common requirement) we want to produce it directly, rather than having an XML document as an intermediate form. When the Netscape browser displays the result of an XSLT transformation, it doesn't serialize the result to HTML and then parse the serial HTML; rather, it works directly from the result tree as a data structure in memory. Similarly, we might want to take input from a database or (say) an LDAP directory, or an EDI message, or a data file using comma-separated-values syntax. We don't want to spend a lot of time converting these into serial XML documents if we can avoid it, nor do we want another raft of converters to install.

Instead, XSLT defines its operations in terms of a representation of an XML document called the tree. The tree is an abstract data type. There is no defined application programming interface (API) and no defined data representation, only a conceptual model that defines the objects in the tree, their properties, and their relationships. The tree is similar in concept to the W3C DOM, except that the Document Object Model (DOM) does have a defined API. Some implementors do indeed use the DOM as their internal tree structure. Others use a data structure that corresponds more closely to the XPath tree model, while some use optimized internal data structures that are only distantly related to this model. It's a conceptual model we are describing, not something that necessarily exists in an implementation.

The data model for XSLT trees is shared with the XPath and XQuery specifications, which ensures that data can be freely exchanged between these three languages. With XSLT and XPath, this is of course essential, because XSLT always retrieves data from a source document by executing XPath expressions. The companion book XPath 2.0 Programmer's Reference contains a detailed description of this data model, and later in this section I will give a quick summary of the model for ease of reference.

Taking the inputs and output of the XSLT processors as trees produces a new diagram (Figure 2-2). The formal conformance rules say that an XSLT processor must be able to read a stylesheet and use it to transform a source tree into a result tree. This is the part of the system shown in the oval box. There's no official requirement to handle the parts of the process shown outside the box, namely the creation of a source tree from a source XML document (known as parsing ), or the creation of a result XML document from the result tree (called serialization ). In practice, though, most real products are likely to handle these parts as well.

Figure 2-2

Different Output Formats

Although the final process of converting the result tree to an output document is outside the conformance rules of the XSLT standard, this doesn't mean that XSLT has nothing to say on the subject. In fact, there is a substantial section of the specification devoted to serialization, and although everything it says is nonbinding, most implementations have followed it very closely. The main control over this process is the <xsl:output> element, which is described in detail in Chapter 5, page 375.

The <xsl:output> element defines four output formats or methods , namely xml , html , xhtml , and text , In each case a result tree is written to a single output file.

With the xml output method, the output file is an XML document. We'll see later that it need not be a complete XML document; it can also be an XML fragment. The <xsl:output> element allows the stylesheet writer some control over the way in which the XML is written, for example, the character encoding used and the use of CDATA sections.
With the html output method, the output file is an HTML document, typically HTML 4.0, though products may support other versions if they wish. With HTML output, the XSLT processor recognizes many of the conventions of HTML and structures the output accordingly . For example, it recognizes elements such as <hr> that have a start tag and no end tag, as well as the special rules for escape characters within a <script> element. It may also (if it chooses) generate references to built-in entities such as «é ».

Selecting html as the output method doesn't in any way automate the process of creating valid HTML, nor does it cause errors if the result tree produced by the transformation is invalid HTML. All it does is to tell the serializer to use HTML conventions when turning the nodes in the tree back into markup.
The xhtml output method, as one might expect, is a compromise between the xml and html output methods. Generally speaking, it follows the rules of the xml output method, but sticks to the conventions described in the XHTML specification that are designed to make the output display properly in browsers that are designed to handle HTML. Such conventions include, for example, outputting an empty element as (with a space before the «/ » ), and outputting an empty element as .
The text output method is designed to allow output in any other text-based format. For example, the output might be a comma-separated-values file, a document in Microsoft's Rich Text Format (RTF), or in Adobe's Portable Document Format (PDF); or, it might be an electronic data interchange message, or a script in SQL or JavaScript. It's entirely up to you.

If the <xsl:output> element is omitted, the processor makes an intelligent guess, choosing HTML if the output starts with an <html> element in the null namespace, XHTML if it starts with an <html> element in the XHTML namespace, and XML otherwise .

Implementations may include output methods other than these four, but this is outside the scope of the standard. One mechanism provided by several products is to feed the result tree to a user -supplied document handler. In the case of Java products this will generally be written to conform to the ContentHandler interface defined as part of the SAX2 API specification (which since JDK 1.4 is part of the core class library in Java). Most implementations also provide mechanisms to capture the result as a DOM tree. Remember that if you use the result tree directly in this way, the XSLT processor will not serialize the tree, and therefore nothing you say in the <xsl:output> declaration will have any effect.

So, while the bulk of the XSLT Recommendation describes the transformation process from a source tree to a result tree, there is one section that describes another process, serialization. Because the serialization of a document tree as a file is a process that is relevant not only to XSLT but also to XQuery and potentially other applications in the future, the detail is no longer in the XSLT 2.0 Recommendation, but forms a W3C specification in its own right (see http://www.w3.org/TR/xslt-xquery-serialization/ ). The name serialization is used because it turns a tree structure into a stream of characters or bytes (but it mustn't be confused with serialization in distributed object systems such as Component Object Model (COM) or Java, which produces a serial file representation of a COM or Java object). XSLT processors can implement this at their discretion, and it fits into our diagram as shown in Figure 2-3.

Figure 2-3

Multiple Inputs and Outputs

In real life, the processing model is further complicated because there can be multiple inputs and outputs. Specifically:

There can be multiple input documents. The stylesheet can use the document() function (described in Chapter 7, page 532) to load secondary input documents, based on URI references held in the source document or the stylesheet. Each input document is processed as a tree in its own right, in exactly the same way as the principal input document. It is also possible to supply additional input documents as parameters to the stylesheet.
The stylesheet may also consist of multiple documents. There are two declarations that can be used in the stylesheet, <xsl:include> and <xsl:import> , to load additional stylesheet modules and use them as extensions of the principal module. Splitting a stylesheet in this way allows modularity: in a complex environment different aspects of processing can be described in component stylesheets that can be incorporated into several different parent stylesheets. There is a detailed discussion of how to split a stylesheet into modules in Chapter 3.
A single run of the XSLT processor can produce multiple output documents. This allows a single source document to be split into several output files: for example, the input might contain the text of an entire book, while the output contains one HTML file for each chapter, all connected using suitable hyperlinks . This capability, which is provided by the <xsl:result-document> element described in Chapter 5, is new in XSLT 2.0, though many vendors provided similar facilities as extensions to their XSLT 1.0 processors.