XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (58 page)
Read XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition Online
Authors: Michael Kay
This is the theory. The rules for forward-compatibility mode were simplified in XSLT 2.0 after the XSL Working Group discovered that implementation of this feature in 1.0 processors was patchy. Altova's 1.0 processor, for example, allows unknown functions but rejects unknown attributes; the Saxon XSLT 1.0 implementation accepts both of these but often rejects unknown values for known attributes.
Forward-compatible processing was specified to allow you to write a stylesheet that exploits facilities in version 2.0 while still behaving sensibly when run with an XSLT processor that supports version 1.0 only, or, at some point in the future, to use facilities in version 3.0 and still behave sensibly with an XSLT 2.0 processor. To achieve this, you can use the
system-property()
function (described on page 890, in Chapter 13) to discover which version of XSLT the processor implements, or which processor is being used. For example, you could write code such as the following:
starts-with(system-property(‘xsl:vendor’), ‘xalan’)”>
Relying on the version number this returns is a rather crude mechanism: there are likely to be processors around that implement some of the new features in XSLT 2.0 but not yet all of them. Testing which vendor's processor is in use is therefore handy for portability, especially when vendors have not kept strictly to the conformance rules. Another possibility is to use the
element-available()
and
function-available()
functions described later in the chapter: although these are primarily intended to allow you to test whether particular vendor or user-defined extensions are available, they can also be used to test for the availability of specific XSLT instructions and functions in the core language.
Technically, a processor that implements some of the new XSLT 2.0 features but not all of them doesn't conform either to XSLT 1.0 or to XSLT 2.0. But because many XSLT processors are developed incrementally with new releases every few weeks, you might well find products that occupy this no man's land. A product will presumably return
2.0
as the value ofsystem-property(‘xsl-version’)when the vendor is confident that the product is “almost” conformant: past experience suggests that different vendors will interpret this in different ways.
There was a suggestion that one should ban processors from returning
2.0
unless they are fully conformant with the spec. But there is little point in such a prohibition, because a product that isn't fully conformant with the spec is by definition doing things that the spec doesn't allow.
Backward Compatibility in XSLT 2.0
For an XSLT 2.0 processor, you can invoke backward-compatibility mode by setting the
version
attribute on the1.0. In fact, any value less than2.0will do. You can also set the
xsl:version
attribute on a literal result element in the same way.
Like the switch for forward-compatibility mode, this has static scope: it applies to all instructions and XPath expressions contained within the element where the
version
attribute is set. Unlike forward-compatibility mode, however, this mode affects the results of evaluating instructions and expressions, rather than being purely a compile-time switch.
XSLT 2.0 processors aren't obliged to support backward-compatible processing. If they don't, they must reject any attempt to specifyversion = “1.0”as an error. The reason the facility was made optional was that the language designers expected that the need for it would gradually decline as XSLT 1.0 receded into history. However, some vendors may decide that their customers don't need the facility at all, as it's not actually that difficult to change the few constructs in a stylesheet whose behavior is different under XSLT 2.0.
