This section lists all known incompatibilities with XSLT 2.0, that is, situations
where a stylesheet that is error-free
according to the XSLT 2.0 specification and where all elements have an effective version
of 2.0
or less, will produce different results depending on whether it is
run under an XSLT 2.0 processor or an XSLT 3.0 processor.
XSLT 2.0 gave implementations freedom what to do when a node selected by
xsl:apply-templates
matched more than one template rule. XSLT 3.0 is more prescriptive in this situation. The
behavior prescribed in XSLT 3.0 (selecting the template rule that is last in
declaration order) is compatible with the action of some
XSLT 2.0 processors but not necessarily others.
It is now a static error if the same NameTest
appears in both an
xsl:strip-space
and an xsl:preserve-space
declaration with the same precedence and priority. Previously this was a dynamic
error, and processors were allowed to recover from the error.
The current group and current grouping key are now absent rather than empty when not in use, which means that attempting to refer to them in this state gives a dynamic error.
As a consequence of functions such as
format-date
FO30 moving from this specification to [Functions and Operators 3.0], error codes associated with these functions have
changed.
The concept of recoverable dynamic errors has been dropped. Of
the remaining recoverable dynamic errors, some are no longer errors, and others
are now situations where the behavior of the processor is implementation-dependent. Error codes of the form
XTREnnnn
have been renumbered XTDEnnnn
.
In previous versions of the specification, the
element-available
function when applied to names in the
XSLT namespace was defined to return false
in the case of XSLT
elements other than instructions. (Actual practice in implementations was not
always consistent with this rule). In XSLT 3.0 the rules have been changed so that
it returns true
for the names of such elements, bringing the
specification of the function into line with the intuitive meaning of its name.
(This is not strictly speaking an incompatibility, as conforming XSLT 2.0 stylesheets will continue to function correctly without error. It can be considered as migration advice, a warning that care is needed when introducing new XSLT 3.0 features.)
When a function or template has a parameter with a declared
type of item()
, it should not assume (as it could in XSLT 2.0) that
when the supplied item is not a node, it must be an atomic value, and vice versa.
In XSLT 3.0 there is a third option: it might be a function. Functions and
templates that fail to cater for this possibility may fail with a type error if
the caller supplies a function as the relevant parameter value.
XSLT 1.0 and 2.0 required the
grouping-size
attribute of xsl:number
to be a
number (a term which in other contexts was defined to mean any decimal value),
but no interpretation was provided for non-integer values. XSLT 3.0 requires the
value to be an integer.
In XPath 3.0, the rules for matching node tests of the form
element(*, U)
or attribute(*, U)
have changed in the
case where U
is a union type. Specifically, an element or attribute
whose type annotation is a member type of U
will now match such a
node test, whereas in XPath 2.0 it did not. Since the semantics of XSLT pattern
matching are based on the XPath rules for matching node tests, this change affects
which template rules are chosen to match a node when the match patterns use one of
these forms.
The handling of XSLT version numbers that do not
correspond to any published specification has changed. An example is
version="1.1"
(which is sometimes encountered because it was used
in examples in a popular book). XSLT 2.0 requires processors to treat all values
less than 2.0 as if 1.0 were specified. XSLT 3.0 recommends that processors reject
such a value as a static error.
XSLT 3.0 disallows the use of certain reserved namespaces
in extension functions and extension instructions, and in the [xsl:]extension-element-prefixes
attribute.
Note:
For example, it becomes an error to write extension-element-prefixes="xs"
where
the prefix xs
is bound to the XML Schema namespace. Such an attribute is occasionally seen
where exclude-result-prefixes
was probably intended.