N Incompatibilities with XSLT 2.0 (Non-Normative)

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.

  1. 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.

  2. 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.

  3. 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.

  4. As a consequence of functions such as format-dateFO30 moving from this specification to [Functions and Operators 3.0], error codes associated with these functions have changed.

  5. 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.

  6. 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.

  7. (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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.