In the next chapter, we will meet more elements; some of these you will require less often, while others provide more advanced functionality.
We will be looking at the most frequently used aspects of these elements. For fuller descriptions refer either to the XSLT recommendation or to a source such as the XSLT Programmer's Reference 2nd Edition (ISBN 1-861005-06-7 from Wrox Press).
<xsl:stylesheet>
This is simply the container element for all other elements within an XSL stylesheet. In most cases, this means it will be the document element of a stylesheet document.
A stylesheet can be embedded within another document, in which case an id attribute of this element can be used to allow a reference to the stylesheet.
The <xsl:stylesheet> element must contain a version attribute, indicating the version of XSLT that is being used. Currently, this is always 1.0 or 1.1.
The most important change between version 1.0 and version 1.1 of XSLT is that the latter allows multiple output documents to be created from a single XML source document and stylesheet. The full list of changes is documented as an appendix to the XSLT 1.1 specification (http://www.w3.org/TR/xslt11), which is at working draft stage at the time of writing.
The element is also likely to contain several namespaces, as we saw above. Firstly, there will be the XSLT namespace itself to tell the XSL processor which elements to process and which to pass unchanged to the output tree. Then there might be a namespace for XSL formatting objects (which we will look at in Chapter 9), namespaces for elements and attributes we will be matching in the source document, and namespaces for elements we might be creating in the output document. For example, if we wanted to use a stylesheet to document an XML Schema document, producing HTML output, our xsl:stylesheet start tag might look like this:
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xsd="http://www.w3.org/1999/XMLSchema"
xmlns="http://www.w3.org/TR/REC-html40">
In this case, we have defined HTML as our default namespace, and used explicit qualifiers for the XSLT and XML Schema namespaces.
Other optional attributes of the <xsl:stylesheet> element relate to namespace prefixes in the result tree and extension elements (which we will meet later in the book).
<xsl:output>
This element is used to inform the XSL processor of the format of the result tree. Earlier we used the following example (count.xsl) without using <xsl:output>:
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="PLAY">
<HTML>
<HEAD>
<TITLE>Counting</TITLE>
</HEAD>
<BODY>
...
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>
We used various HTML elements directly in our stylesheet, and these were copied directly to the result tree. Since the stylesheet is an XML document, the HTML included in it must itself be well-formed XML, and hence the HTML copied to the result tree will also be well-formed XML. This well-formed XML could meet the rules of the Extensible Hypertext Markup language, XHTML (see Beginning XHTML, ISBN 1-861003-43-9), but this is not essential to the operation of the stylesheet.
If the transformed result tree is being saved as a file, the last stage of XSLT processing will be to serialize the result tree. It seems reasonable to assume that this will also be well-formed XML. In most cases, this would not cause problems, but some HTML browsers (particularly older ones) have difficulty with constructs such as <HR/>, preferring just the opening tag <HR> without a closing tag for a horizontal rule. HTML also allows attributes without values (as in <OPTION selected>). Again, this is not well-formed XML, but some browsers will object to the alternative form of <OPTION selected="selected">. For this reason, alternative forms of serialization are supported through the <xsl:output> element. When, as in the example above, the element is omitted, the serialized output will obey rules we will look at later. In this case, it would be XML.
This element has an optional method attribute that specifies the form that the serialization should take. The three possible values are xml, html and text. The xml option is simple enough - the serialized output will be well-formed XML. The html option handles the cases shown above by converting the tags to the more normal HTML styles of <HR> and <OPTION selected>, and the text method provides a pure text output, removing all tags and converting entity and character references to their text equivalents.
Let's take a simple stylesheet, output.xsl, that creates some HTML, and try the different forms of <xsl:output>. Since we now know more about the use of namespaces in XSL, we will also declare the unqualified names copied to the output to be in the HTML namespace.
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/REC-html40">
<xsl:output method="html" indent="yes"/>
<xsl:template match="/">
<HTML>
<HEAD><TITLE>Testing the xsl:output element</TITLE></HEAD>
<BODY>
<P>
This is a simple stylesheet to show the effect of the xsl:output
element. There is an <HR/> element after this line.
</P>
<HR/>
<SELECT>
<OPTION value="1">First option</OPTION>
<OPTION selected="selected" value="2">Second (selected)
option</OPTION>
<OPTION value="3">Third option</OPTION>
</SELECT>
</BODY>
</HTML>
</xsl:template>
</xsl:stylesheet>
In general in this chapter, we will leave out the HTML namespace declaration for simplicity.
We have specified our output method as html. We have also specified that we want the result indented, by putting in the attribute indent="yes". Although the XSLT recommendation does not specify what action the XSL processor should take as a result of this, with some processors it can make the result more readable.
Continued...
