XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (56 page)

If you use facilities that are new in XSLT version 2.0, and you don't need the stylesheet to run under an XSLT 1.0 processor, then it's best to specify
version = “2.0”
. If there are parts of the stylesheet that you haven't converted from XSLT 1.0, where you want backward-compatible behavior to be invoked, then you can leave those parts in a separate stylesheet module that specifies
version = “1.0”
. It's quite OK to mix versions like this. In fact, XSLT 2.0 allows you to specify the
version
attribute at any level of granularity, for example on an

element, or even on an element that encloses one small part of a template. If you use it on a literal result element, the attribute should be named
xsl:version
to distinguish it from user-defined attributes. Bear in mind, however, that XSLT 1.0 processors allow the
version
attribute to appear only on the

element, or, as
xsl:version
, on a literal result element: it's not permitted, for example, on

.

If you use facilities that are new in XSLT version 2.0, but you also want the stylesheet to run under an XSLT 1.0 processor, then you may need to write it in such a way that it defines fallback behavior to be invoked when running under 1.0. There are various techniques you can use to achieve this. You can use the
element-available()
function to test whether a particular XSLT instruction is implemented; you can use

to define what the processor should do if a construct is not available; or you can use the
system-property()
function (described in Chapter 13) to test which version of XSLT is supported, and execute different code, depending on the result. Whichever technique you use, you need to ensure that those parts of the stylesheet that use XSLT 2.0 facilities are within the scope of an element that specifies
version = “2.0”
, otherwise an XSLT 1.0 processor will reject them at compile time.

The following sections look in more detail at the rules for backward-compatible and forward-compatible behavior.

Forward Compatibility in XSLT 1.0

At present, you are probably more concerned with migration of XSLT 1.0 stylesheets to XSLT 2.0 than with migration from 2.0 to 3.0, so it makes sense to look at the forward-compatibility rules as they were defined in the XSLT 1.0 specification. The rules have changed a little in XSLT 2.0 to reflect the introduction of the
[xsl:]use-when
attribute, so if you are reading this perhaps in 2012 and planning the transition to a new version 3.0, most of the advice should still be relevant, but you will be able to achieve most of what you need using
[xsl:]use-when
instead.

Forward-compatibility mode is invoked, as far as an XSLT 1.0 processor is concerned, by setting the
version
attribute on the

element to any value other than
1.0
(even, surprisingly, a value lower than
1.0
). For an XSLT 2.0 processor, forward-compatibility mode is invoked by a
version
attribute greater than
2.0
.