Abstract
This specification defines the syntax and semantics of XSLT 4.0, a language designed primarily for transforming XML documents into other XML documents, but also offering support for other data formats including JSON, HTML, and CSV.
XSLT 4.0 is a revised version of the XSLT 3.0 Recommendation [XSLT 3.0] published on 8 June 2017. Changes are presented in 1.2 What’s New in XSLT 4.0?.
XSLT 4.0 is designed to be used in conjunction with XPath 4.0, which is defined in [XPath 4.0]. XSLT shares the same data model as XPath 4.0, which is defined in [XDM 4.0], and it uses the library of functions and operators defined in [Functions and Operators 4.0]. XPath 4.0 and the underlying function library introduce a number of enhancements, for example the availability of union and record types.
This document contains hyperlinks to specific sections or definitions within other documents in this family of specifications. These links are indicated visually by a superscript identifying the target specification: for example XP for XPath 4.0, DM for the XDM data model version 4.0, FO for Functions and Operators version 4.0, SG for XSLT Streaming version 4.0.
An optional feature of the XSLT language is support for streamed transformations. The XSLT 4.0 specification has been modularized so that streaming is now described in a separate specification document. This has been done in order to make the specifications more manageable, both for editors and readers: it does not alter the status of streaming as an optional feature, available in some processors and not others.
Status of this Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document.
This document is a working draft developed and maintained by a W3C Community Group, the XQuery and XSLT Extensions Community Group unofficially known as QT4CG (where "QT" denotes Query and Transformation). This draft is work in progress and should not be considered either stable or complete. Standard W3C copyright and patent conditions apply.
The community group welcomes comments on the specification. Comments are best submitted as issues on the group's GitHub repository.
The community group maintains two extensive test suites, one oriented to XQuery and XPath, the other to XSLT. These can be found at qt4tests and xslt40-test respectively. New tests, or suggestions for correcting existing tests, are welcome. The test suites include extensive metadata describing the conditions for applicability of each test case as well as the expected results. They do not include any test drivers for executing the tests: each implementation is expected to provide its own test driver.
Dedication
The publications of this community group are dedicated to our co-chair, Michael Sperberg-McQueen (1954–2024).
Template rules define the processing that can be applied to items that match a particular pattern.
In XSLT 4.0, patterns can match any kind of item: atomic items and function items as well as nodes.
A template rule identifies the items to which it applies by means of a pattern. As well as being used in template rules, patterns are used for numbering (see 12 Numbering), for grouping (see 14 Grouping), and for declaring keys (see 20.2 Keys).
[Definition: A pattern specifies a set of conditions on an item. An item that satisfies the conditions matches the pattern; an item that does not satisfy the conditions does not match the pattern.]
There are several kinds of pattern:
[Definition: A predicate pattern is written as . (dot) followed by zero or more predicates in square brackets, and it matches any item for which each of the predicates evaluates to true.]
A predicate pattern .[P1][P2]... can be regarded as an abbreviation for the type pattern type(item())[P1][P2]....
The detailed semantics are given in 6.3.2.1 Predicate Patterns. This construct can be used to match items of any kind (nodes, atomic items, and function items). For example, the pattern .[starts-with(., '$')] matches any string that starts with the character $, or a node whose atomized value starts with $. This example shows a predicate pattern with a single predicate, but the grammar allows any number of predicates (zero or more).
[Definition: A type pattern can be written as type(T) (where T is an ItemTypeXP followed by zero or more predicates in square brackets, and it matches any item of type T for which each of the predicates evaluates to true.]
The parameter T can also be a list of item types, separated by "|". For example, type(array(*) | map(*)) matches arrays and maps, while type(text() | comment()) matches text nodes and comment nodes.
The most commonly used type patterns can be abbreviated. For example, match="type(record(F1, F2, *))" can be abbrevated to match="record(F1, F2, *)", while match="type(array(xs:string))" can be abbreviated to match="array(xs:string)". The main case where such abbreviation is not possible is with atomic items: match="type(xs:date)" cannot be abbreviated because a bare QName is interpreted as a node pattern, matching elements named xs:date.
The type pattern match="type(text() | comment())" has almost the same effect as the XNode pattern match="text() | comment()", but the rules for calculating a default priority are different.
[Definition: An XNode pattern uses a subset of the syntax for path expressions, and is defined to match an XNode if the corresponding path expression would select the XNode.]
The syntax for XNode patterns (PathExprP in the grammar: see 6.3.2 Syntax of Patterns) is a subset of the syntax for expressions. XNode patterns, except in a few special cases, are used only for matching nodes. As explained in detail below, a node matches a node pattern if the node can be selected by deriving an equivalent expression, and evaluating this expression with respect to some possible context.
[Definition: A JNode Pattern matches a JNode by specifying constraints on the values of its ·selector· and/or ·content· properties.]
Patterns may be combined using the union, intersect, and except operators. If P and Q are patterns, then:
P union Q (which can also be written P | Q) matches an item if either or both of P and Q match the item.
P intersect Q matches an item if P and Q both match the item.
P except Q matches an item if P matches the item and Q does not.
- Parentheses can be used, for example
P except (Q union R), by virtue of the fact that an XNodePattern may be a ParenthesizedPattern.
Note:
The meaning of a top-level union, intersect, or except operator has changed in XSLT 4.0. Previously these operators were defined in terms of the corresponding XPath operators applied to sets of nodes, which meant they could not be used when matching items other than nodes.
Note:
The specification uses the phrases an item matches a pattern and a pattern matches an item interchangeably. They are equivalent: an item matches a pattern if and only if the pattern matches the item.
Changes in 4.0 (next | previous)
Default priorities are added for new forms of ElementTest and AttributeTest, for example element(p:*) and element(a|b). [Issue 1394 PR 1442 15 September 2024]
The default priority for a template rule using a union pattern has changed. This change may cause incompatible behavior. [Issue 1770 ]
[Definition: If no priority attribute is specified on an xsl:template element, a default priority is computed, based on the syntactic form of the pattern supplied in the match attribute.] The rules are as follows.
For a TypePattern with no predicates, the default priority depends on the item type:
For a choice item type, the default priority is the maximum priority of the item types included in the choice, computed according to the rules below.
For the item type item(), the default priority is -1 (minus one).
For the item types node(), gnode(), jnode(), function(*), and xs:anyAtomicType, the default priority is -0.5.
For any item type that corresponds directly to an XNode Pattern (for example element(*) or element(N)), the default priority is the same as that of the corresponding XNode Pattern: see 6.3.3.4 Default Priority for XNode Patterns.
For the item types array(*), map(*), and record(*), the default priority is -0.25.
For the 19 XSD-defined primitive atomic types, and for xs:untypedAtomic, the default priority is 0 (zero).
For an atomic type other than a primitive type, the default priority is a value greater than 0 (zero) and less than 0.5 (one) that reflects its depth in the type hierarchy. Specifically, the priority is computed as 0.5 - 2^-N where N is the number of derivation steps from xs:anyAtomicType. This formula also works for primitive types. For example:For an atomic type other than a primitive type, the default priority is a value greater than 0 (zero) and less than 0.5 that reflects its depth in the type hierarchy. Specifically, the priority is computed as 0.5 - 2^-N where N is the number of derivation steps from xs:anyAtomicType. This formula also works for primitive types. For example:For an atomic type other than a primitive type, the default priority is a value greater than 0 (zero) and less than 0.5 (one) that reflects its depth in the type hierarchy. Specifically, the priority is computed as 0.5 - 2^-N where N is the number of derivation steps from xs:anyAtomicType. This formula also works for primitive types. For example:
Examples of default priorities for atomic types| Type | Depth (N) | Priority |
|---|
xs:decimal | 1 | 0 |
xs:integer | 2 | 0.25 |
xs:long | 3 | 0.375 |
xs:int | 4 | 0.4375 |
For any other item type, the default priority is 0 (zero).
For a TypePattern having one or more predicates, the default priority is 0.5