WebReference.com - Excerpt from Inside XSLT, Chapter 2, Part 2 (4/5)
Note that the
id attribute of this element can be used when you want to
refer to a particular stylesheet (and note that you should have an XSLT processor
that also reads DTDs or XML schemas in this case).
The version attribute is mandatory, and currently can be set to "1.0". You can also set this value to "1.1" for the XSLT 1.1 working draft; however, because XSLT 1.1 is not going past the working draft stage, "1.1" will probably not be considered a legal value for this attribute in the long run. I'm going to set the version attribute to "1.0" in this book, because that's the current W3C XSLT recommendation, and version 1.1 is not going to progress beyond working draft stage. As mentioned in Chapter 1, the W3C has also released the requirements for XSLT 2.0, so that will be the next version.
XSLT Processors and Forward Compatibility
If the XSLT version is not one that the XSLT processor recognizes, W3C says the processor must assume any new elements are part of the new XSLT version and not just quit, which is what W3C calls forward compatibility. Any elements the processor does not recognize must not be rejected unless the stylesheet tries to instantiate that element and finds no
<xsl:fallback>child element (see Chapter 5). The upshot is that you can set the XSLT version to 2.0, even in XSLT processors that were written for XSLT 1.0, and there should be no problem unless you use XSLT 2.0-specific features. (An exception here seems to be MSXML3, which currently does generate errors if you set the version to values other than 1.0.)
The XSL Namespace
Note that XSLT elements such as <xsl:stylesheet> use the namespace prefix xsl, which, now that XSLT has been standardized, is always set to "http://www.w3.org/1999/XSL/Transform". That namespace is usually set with the xmlns attribute (which is not an XSL attribute, but rather an attribute of any XML element), in the stylesheet's root element, <xsl:stylesheet>:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> . . .
XSL stylesheets use their own namespace this way to avoid conflict with the
other elements you use in your stylesheet. For example, you might want to indicate what
stylesheet was used to transform a document, in which case you might create your own
<stylesheet> element-which is no problem, because it won't conflict
with the XSL element
The namespace prefix customarily used in XSLT stylesheets for XSLT elements
xsl. You can, in fact, use any namespace prefix you want for XSLT elements
(or even none at all), but
xsl is used almost universally because that's the
namespace used throughout the XSLT recommendation.
More on Namespaces
For more on namespaces, see the companion New Riders book, Inside XML, which has an in-depth treatment and plenty of examples.
In practice, this means that all XSLT elements we'll be using start with the
xsl, as in
<xsl:stylesheet>. That, then, is
how you start an XSLT stylesheet, with the
(There is one exception: "simplified" stylesheets omit this element, as you'll see later
in this chapter).
Like any other XML application, XSLT has a well-defined set of rules for
what makes an XSLT stylesheet valid. The W3C even defines a pseudo-DTD for XSLT, listing
all the syntax rules, and you can find that DTD in Appendix A, which is a good resource
if you're ever at a loss to understand some part of XSLT syntax. As Appendix A shows,
<xsl:stylesheet> element can legally contain several other XSLT
elements, and those elements are called top-level elements.
Handling Default Namespaces
The question of namespaces can be tricky. For example, some people assign a default namespace to the whole
<xsl:stylesheet>element as in
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/ 1999/XSL/Transform" xmlns="mydefault">, and then expect
<xsl:template match="mysymbol">to match
mysymbolin the "mydefault" namespace of the source document. It won't, though. Handling default namespaces such as this is one of the issues that XSLT 2.0 is supposed to address.
Created: September 20, 2001
Revised: September 20, 2001