XSL Transformations (XSLT) Version 4.0

3 Stylesheet Structure

This section describes the overall structure of a stylesheet as a collection of XML documents.

3.7 Stylesheet Element

Changes in 4.0 ⬇ ⬆

A new attribute, main-module, is added to the xsl:stylesheet element. The attribute is provided for the benefit of development tools such as syntax-directed editors to provide information about all the components (variables, functions, etc) visible within a stylesheet module. [Issue 87 PR 353 19 April 2023]

<xsl:stylesheet id? = id version = decimal default-mode? = eqname | "#unnamed"〔'#unnamed'〕 default-validation? = "preserve" | "strip"〔'strip'〕 input-type-annotations? = "preserve" | "strip" | "unspecified"〔'unspecified'〕 default-collation? = uris extension-element-prefixes? = prefixes exclude-result-prefixes? = prefixes expand-text? = boolean fixed-namespaces? = string main-module? = uri schema-role? = ncname use-when? = expression〔true()〕 xpath-default-namespace? = uri >  </xsl:stylesheet>

<xsl:transform id? = id version = decimal default-mode? = eqname | "#unnamed"〔'#unnamed'〕 default-validation? = "preserve" | "strip"〔'strip'〕 input-type-annotations? = "preserve" | "strip" | "unspecified"〔'unspecified'〕 default-collation? = uris extension-element-prefixes? = prefixes exclude-result-prefixes? = prefixes expand-text? = boolean〔'no'〕 fixed-namespaces? = string main-module? = uri schema-role? = ncname use-when? = expression〔true()〕 xpath-default-namespace? = uri >  </xsl:transform>

A stylesheet module is represented by an xsl:stylesheet element in an XML document. xsl:transform is allowed as a synonym for xsl:stylesheet; everything this specification says about the xsl:stylesheet element applies equally to xsl:transform.

The version attribute indicates the version of XSLT that the stylesheet module requires. The attribute is required.

[ERR XTSE0110] The value of the version attribute must be a number: specifically, it must be a valid instance of the type xs:decimal as defined in [XML Schema Part 2].

The version attribute is intended to indicate the version of the XSLT specification against which the stylesheet is written. In a stylesheet written to use XSLT 4.0, the value should normally be set to 4.0. If the value is numerically less than 4.0, the stylesheet is processed using the rules for backwards compatible behavior (see 3.9 Backwards Compatible Processing). If the value is numerically greater than 4.0, the stylesheet is processed using the rules for forwards compatible behavior (see 3.10 Forwards Compatible Processing).

The effect of the input-type-annotations attribute is described in 4.3.1 Stripping Type Annotations from a Source Tree.

The [xsl:]default-validation attribute defines the default value of the validation attribute of all relevant instructions appearing within its scope. For details of the effect of this attribute, see 25.4 Validation.

The optional main-module attribute is purely documentary. By including this attribute in every stylesheet module of a package, an XSLT editing tool may be enabled to locate the top-level module of the relevant package, and thus to gather information about all the global variables, templates, and functions available within the module being edited. This information can be used (for example) to enable auto-completion and error highlighting of the code as it is entered. Note that it may be inconvenient or misleading to use this attribute when the stylesheet module is used as a shared component within multiple stylesheets.

[ERR XTSE0120] An xsl:stylesheet, xsl:transform, or xsl:package element must not have any text node children. (This rule applies after stripping of whitespace text nodes as described in 3.13.1 Stripping Whitespace and Commentary from the Stylesheet.)

[Definition: An element occurring as a child of an xsl:package, xsl:stylesheet, xsl:transform, or xsl:override element is called a top-level element.]

[Definition: Top-level elements fall into two categories: declarations, and user-defined data elements. Top-level elements whose names are in the XSLT namespace are declarations. Top-level elements in any other namespace are user-defined data elements (see 3.7.4 User-defined Data Elements)].

The declaration elements permitted in the xsl:stylesheet element are:

xsl:accumulator
xsl:attribute-set
xsl:character-map
xsl:decimal-format
xsl:function
xsl:global-context-item
xsl:import
xsl:import-schema
xsl:include
xsl:item-type
xsl:key
xsl:mode
xsl:namespace-alias
xsl:output
xsl:param
xsl:preserve-space
xsl:record-type
xsl:strip-space
xsl:template
xsl:use-package
xsl:variable

Note that the xsl:variable and xsl:param elements can act either as declarations or as instructions. A global variable or parameter is defined using a declaration; a local variable or parameter using an instruction.

The child elements of the xsl:stylesheet element may appear in any order. In most cases, the ordering of these elements does not affect the results of the transformation; however:

As described in 6.6 Conflict Resolution for Template Rules, when two template rules with the same priority match the same nodes, there are situations where the order of the template rules will affect which is chosen.
Forwards references to static variables are not allowed in static expressions.

3.7.2 The `default-collation` Attribute

The default-collation attribute is a standard attribute that may appear on any element in the XSLT namespace, or (as xsl:default-collation) on a literal result element.

The attribute, when it appears on an element E, is used to specify the default collation used by all XPath expressions appearing in attributes or text value templates that have E as an ancestor, unless overridden by another default-collation attribute on an inner element. It also determines the collation used by certain XSLT constructs (such as xsl:key and xsl:for-each-group) within its scope.

The value of the attribute is a whitespace-separated list of collation URIs. If any of these URIs is a relative URI reference, then it is resolved as described in [Functions and Operators 4.0] section 5.3.1 Collations.. If the implementation recognizes one or more of the resulting absolute collation URIs, then it uses the first one that it recognizes as the default collation.

[ERR XTSE0125] It is a static error if the value of an [xsl:]default-collation attribute, after resolving against the base URI, contains no URI that the implementation recognizes as a collation URI.

Note:

The reason the attribute allows a list of collation URIs is that collation URIs will often be meaningful only to one particular XSLT implementation. Stylesheets designed to run with several different implementations can therefore specify several different collation URIs, one for use with each. To avoid the above error condition, it is possible to include as the last collation URI in the list either the Unicode Codepoint Collation or a collation in the UCA family (see [Functions and Operators 4.0] section 13.4 The Unicode Collation Algorithm5.3.4 The Unicode Collation Algorithm13.45.3.4 The Unicode Collation Algorithm) with the parameter fallback=yes.

The [xsl:]default-collation attribute does not affect the collation used by xsl:sort or by xsl:merge.

In the absence of an [xsl:]default-collation attribute, the default collation may be set by the calling application in an implementation-defined way. The recommended default, unless the user chooses otherwise, is to use the Unicode codepoint collation.

5 Features of the XSLT Language

5.1 Names

5.1.3 Reserved Namespaces

[Definition: The XSLT namespace, together with certain other namespaces recognized by an XSLT processor, are classified as reserved namespaces and must be used only as specified in this and related specifications.] The reserved namespaces are those listed below.

Each of the reserved namespaces has a conventional prefix. As described in 3.7.1 The fixed-namespaces Attribute, the fixed-namespaces attribute may bind one of the reserved namespaces simply by referring to its conventional prefix. For example, fixed-namespaces="xs" has the effect of binding the prefix xs to the namespace http://www.w3.org/2001/XMLSchema.

The XSLT namespace described in 3.1.1 XSLT Namespace, is reserved, with conventional prefix xsl.
[Definition: The standard function namespacehttp://www.w3.org/2005/xpath-functions, with conventional prefix fn, is used for functions in the function library defined in [Functions and Operators 4.0] and for standard functions defined in this specification.]
The namespace http://www.w3.org/2005/xpath-functions/math, with conventional prefix math, is used for mathematical functions in the function library defined in [xpath-functions-30][Functions and Operators 4.0].
The namespace http://www.w3.org/2005/xpath-functions/map, with conventional prefix map, is used for functions defined in this specification relating to the manipulation of maps.
The namespace http://www.w3.org/2005/xpath-functions/array, with conventional prefix array, is reserved for use as described in [xpath-functions-31][Functions and Operators 4.0].
[Definition: The XML namespace, defined in [Namespaces in XML] as http://www.w3.org/XML/1998/namespace, is used for attributes such as xml:lang, xml:space, and xml:id.]This namespace is always bound to the prefix xml.
[Definition: The schema namespacehttp://www.w3.org/2001/XMLSchema, with conventional prefix xs, is used as defined in [XML Schema Part 1]]. In a stylesheet this namespace may be used to refer to built-in schema datatypes and to the constructor functions associated with those datatypes.
[Definition: The schema instance namespacehttp://www.w3.org/2001/XMLSchema-instance, with conventional prefix xsi, is used as defined in [XML Schema Part 1]]. Attributes in this namespace, if they appear in a stylesheet, are treated by the XSLT processor in the same way as any other attributes.
[Definition: The standard error namespacehttp://www.w3.org/2005/xqt-errors, with conventional prefix err, is used for error codes defined in this specification and related specifications. It is also used for the names of certain predefined variables accessible within the scope of an xsl:catch element.]
The namespace http://www.w3.org/2000/xmlns/ is reserved for use as described in [Namespaces in XML]. No element or attribute node can have a name in this namespace, and although the prefix xmlns is implicitly bound to this namespace, no namespace node will ever define this binding.

Note:

With the exception of the XML namespace, any of the above namespaces that are used in a stylesheet must be explicitly declared with a namespace declaration. Although conventional prefixes are used for these namespaces in this specification, any prefix may be used in a user stylesheet.

Reserved namespaces may be used without restriction to refer to the names of elements and attributes in source documents and result documents. As far as the XSLT processor is concerned, reserved namespaces other than the XSLT namespace may be used without restriction in the names of literal result elements and user-defined data elements, and in the names of attributes of literal result elements or of XSLT elements: but other processors may impose restrictions or attach special meaning to them. Reserved namespaces must not be used, however, in the names of stylesheet-defined objects such as variables and stylesheet functions, nor in the names of extension functions or extension instructions.

It is not an error to use a reserved namespace in the name of an extension attribute: attributes such as xml:space and xsi:type fall into this category. XSLT processors must not reject such attributes, and must not attach any meaning to them other than any meaning defined by the relevant specification.

[ERR XTSE0080] It is a static error to use a reserved namespace in the name of a named template, a mode, an attribute set, a key, a decimal-format, a variable or parameter, a stylesheet function, a named output definition, an accumulator, or a character map; except that the name xsl:initial-template is permitted as a template name.

Note:

The name xsl:original is used within xsl:override to refer to a component that is being overridden. Although the name xsl:original is used to refer to the component, the component has its own name, and no component ever has the name xsl:original.

5.2 Expressions

XSLT uses the expression language defined by XPath 4.0 [XPath 4.0]. Expressions are used in XSLT for a variety of purposes including:

selecting nodes for processing;
specifying conditions for different ways of processing a node;
generating text to be inserted in a result tree.

[Definition: Within this specification, the term XPath expression, or simply expression, means a string that matches the production Expr^XP defined in [XPath 4.0].]

XPath expressions may occur:

As the value of certain attributes on XSLT-defined instructions (for example, the select attribute of the xsl:apply-templates instruction)
Within curly brackets in attribute value templates and text value templates.
As the content of a text node within an xsl:select instruction.

In the above cases, the static processing (compilation) of XPath expressions takes place at the same time as the static processing of the stylesheet itself, while evaluation of the XPath expressions takes place dynamically during stylesheet evaluation. There are also, however:

XPath expressions where both the static processing and dynamic evaluation of the XPath expression takes place during static processing of the stylesheet. These are referred to as static expressions, and they perform the same function as preprocessing directives in other languages.
XPath expressions that are dynamically constructed (as character strings): both the static processing and dynamic evaluation of these expressions occurs during stylesheet evaluation. See ???.

In general:

It is a static error if an XPath expression does not match the XPath production Expr^XP, or if it fails to satisfy other static constraints defined in the XPath specification, for example that all variable references must refer to variables that are in scope. Error codes are defined in [XPath 4.0].
The transformation fails with a dynamic error if any XPath expression is evaluated and raises a dynamic error. Error codes are defined in [XPath 4.0].
The transformation fails with a type error if an XPath expression raises a type error, or if the result of evaluating the XPath expression is evaluated and raises a type error, or if the XPath processor raises a type error during static analysis of an expression. Error codes are defined in [xpath-30][XPath 4.0].

There are some exceptions to these rules, for example:

Static errors may be suppressed where forwards compatible behavior is enabled (see 3.10 Forwards Compatible Processing).
Dynamic errors may be caught using xsl:try and xsl:catch.
Dynamic errors evaluating a predicate within a pattern do not cause the transformation to fail, they merely cause the pattern not to match.

[Definition: The context within a stylesheet where an XPath expression appears may specify the required type of the expression. The required type indicates the type of the value that the expression is expected to return.] If no required type is specified, the expression may return any value: in effect, the required type is then item()*.

[Definition: The term coercion rules means the coercion rules defined in [XPath 4.0], applied unless otherwise specified with XPath 1.0 compatibility mode set to false.]

Note:

In earlier versions of this specification, the coercion rules were referred to as the function conversion rules.

Note:

These are the rules defined in [XPath 4.0] for converting the supplied argument of a function call to the required type of that argument, as defined in the function signature. The same rules are used in XSLT for converting the value of a variable to the declared type of the variable, or the result of evaluating a function or template body to the declared type of the function or template. They are also used when parameters are supplied to a template using xsl:with-param. In all such cases, the rules that apply are the XPath 4.0 rules without XPath 1.0 compatibility mode. The rules with XPath 1.0 compatibility mode set to true are used only for XPath function calls, and for the operands of certain XPath operators.

This specification also invokes the XPath coercion rules to convert the result of evaluating an XSLT sequence constructor to a required type (for example, the sequence constructor enclosed in an xsl:variable, xsl:template, or xsl:function element).

Any dynamic error or type error that occurs when applying the coercion rules to convert a value to a required type results in the transformation failing, in the same way as if the error had occurred while evaluating an expression.

Note:

Note the distinction between the two kinds of error that may occur. Attempting to convert an integer to a date is a type error, because such a conversion is never possible. Type errors can be raised statically if they can be detected statically, whether or not the construct in question is ever evaluated. Attempting to convert the xs:untypedAtomic item 2003-02-29 to a date is a dynamic error rather than a type error, because the problem is with this particular value, not with its type. Dynamic errors are raised only if the instructions or expressions that cause them are actually evaluated.

The XPath specification states (see [XPath 4.0] section A.3.3 End-of-Line Handling) that the host language must specify whether the XPath processor normalizes all line breaks on input, before parsing, and if it does so, whether it uses the rules of [XML 1.0] or [XML 1.1]. In the case of XSLT, all handling of line breaks is the responsibility of the XML parser (which may support either XML 1.0 or XML 1.1); the XSLT and XPath processors perform no further changes.

Note:

Most XPath expressions in a stylesheet appear within XML attributes. They are therefore subject to XML line-ending normalization (for example, a CRLF sequence is normalized to LF) and also to XML attribute-value normalization, which replaces tabs and newlines by spaces. Normalization of whitespace can be prevented by using character references such as 	.

XPath expressions appearing in text nodes, (specifically, in text value templates — see 5.6.2 Text Value Templates, or in the xsl:select instruction) are subject to line-ending normalization but not attribute-value normalization.

In both cases it is unwise to include the characters U+0009 (TAB) , U+000A (NEWLINE) , and U+000D (CARRIAGE RETURN) , as literal characters within string literals. Instead they should be escaped as 	, 
, and  respectively, or constructed dynamically by a call on the char function. This can be conveniently embedded within a string template delimited by backticks: for example `Width:{char(9)}8mm`. (The advantage of using this form in preference to XML character references is that they are more likely to survive when the stylesheet is processed using tools such as XML editors.)

5.3 The Static and Dynamic Context

XPath defines the concept of an expression context^XP which contains all the information that can affect the result of evaluating an expression. The expression context has two parts, the static context^XP, and the dynamic context^XP. The components that make up the expression context are defined in the XPath specification (see [XPath 4.0] section 2.2 Expression Context). This section describes the way in which these components are initialized when an XPath expression is contained within an XSLT stylesheet.

This section does not apply to static expressions (whose context is defined in 9.7 Static Expressions), nor to XPath expressions evaluated using xsl:evaluate (whose context is defined in 10.5.2 Dynamic context for the target expression).

As well as providing values for the static and dynamic context components defined in the XPath specification, XSLT defines additional context components of its own. These context components are used by XSLT instructions (for example, xsl:next-match and xsl:apply-imports), and also by the functions in the extended function library described in this specification.

The following four sections describe:

5.3.1 Initializing the Static Context
5.3.2 Additional Static Context Components used by XSLT
5.3.3 Initializing the Dynamic Context
5.3.4 Additional Dynamic Context Components used by XSLT

5.3.1 Initializing the Static Context

The static context^XP of an XPath expression appearing in an XSLT stylesheet is initialized as follows. In these rules, the term containing element means the element within the stylesheet that is the parent of the attribute or text node whose value contains the XPath expression in question, and the term enclosing element means the containing element or any of its ancestors.

XPath 1.0 compatibility mode is set to true if and only if the containing element is processed with XSLT 1.0 behavior (see 3.9 Backwards Compatible Processing).
The statically known namespaces^XP are the applicable static namespaces for the containing element.
The default namespace for elements and types^XP is determined as described in 5.1.2.1 Unprefixed Element Names.
The default function namespace^XP is http://www.w3.org/2005/xpath-functions (and cannot be changed).
The in-scope schema definitions^XP for the XPath expression are the same as the in-scope schema components for the stylesheet, and are as specified in 3.14 Built-in Types.
The in-scope variables^XP are defined by the variable binding elements that are in scope for the containing element (see 9 Variables and Parameters).
The statically known function definitions^XP are:
- The functions defined in [Functions and Operators 4.0] in namespaces http://www.w3.org/2005/xpath-functions and http://www.w3.org/2005/xpath-functions/math;
- The functions defined in this specification in namespaces http://www.w3.org/2005/xpath-functions and http://www.w3.org/2005/xpath-functions/map;
- Constructor functions for all the simple types in the in-scope schema definitions^XP, including both built-in types and user-defined types;
- The stylesheet functions defined in the containing package;
- Stylesheet functions defined in used packages, subject to visibility: see 3.5.2 Dependencies between Packages;
- any extension functions bound using implementation-defined mechanisms (see 24 Extensibility and Fallback).
  Note:
  The term extension function includes both vendor-supplied and user-written extension functions.
Note:
It follows from the above that a conformant XSLT processor must implement the entire library of functions defined in [Functions and Operators 4.0] as well as those defined in this specification.
The statically known collations^XP are implementation-defined, except that they must always include (a) the Unicode codepoint collation, defined in [Functions and Operators 4.0] section 5.3 Comparison of strings, and (b) the family of UCA collations described in [Functions and Operators 4.0] section 13.4 The Unicode Collation Algorithm5.3.4 The Unicode Collation Algorithm13.45.3.4 The Unicode Collation Algorithm.
Static base URI: In a conventional interpreted environment, the static base URI of an expression in the stylesheet is the base URI of the containing element in the stylesheet. The concept of the base URI of a node is defined in [XDM 4.0] section 7.5.2 base-uri Accessor.
When stylesheets are executed in an environment where no source code is present (for example, because the code of the stylesheet has been compiled and is distributed as executable object code), it is recommended (subject to operational constraints such as security) that the static base URI used during stylesheet evaluation should be the location from which the stylesheet was loaded for execution (its “deployed location”). This means, for example, that when the doc or document functions are called with a relative URI, the required document is by default located relative to the deployed location of the stylesheet.
Whether or not the stylesheet is executed directly from source code, it is possible that no static base URI is available, for example because the code was supplied as an anonymous input stream, or because security policies are set to prevent executable code discovering the location from which it was loaded. If the static base URI is not known, the static-base-uri function returns an empty sequence, and other operations that depend on the static base URI may fail with a dynamic error.
The set of statically known decimal formats^XP is the set of decimal formats defined by xsl:decimal-format declarations in the stylesheet.

5.7 Sequence Constructors

[Definition: A sequence constructor is a sequence of zero or more sibling nodes in the stylesheet that can be evaluated to return a sequence of nodes, atomic items, and function items. The way that the resulting sequence is used depends on the containing instruction.]

Many XSLT elements, and also literal result elements, are defined to take a sequence constructor as their content.

Four kinds of nodes may be encountered in a sequence constructor:

A Text node appearing in the stylesheet (if it has not been removed in the process of whitespace stripping: see 3.13.1 Stripping Whitespace and Commentary from the Stylesheet) is processed as follows:
1. if the effective value of the standard attribute [xsl:]expand-text is no, or in the absence of this attribute, the text node in the stylesheet is copied to create a new parentless text node in the result of the sequence constructor.
2. Otherwise (the effective value of [xsl:]expand-text is yes), the text node in the stylesheet is processed as described in 5.6.2 Text Value Templates.
A literal result element is evaluated to create a new parentless element node, having the same expanded QName as the literal result element: see 11.1 Literal Result Elements.
An XSLT instruction produces a sequence of zero, one, or more items as its result. For most XSLT instructions, these items are nodes, but some instructions (such as xsl:sequence, xsl:select, xsl:map, xsl:array, and xsl:copy-of) can also produce atomic items or function items.
Several instructions, such as xsl:element, return a newly constructed parentless node (which may have its own attributes, namespaces, children, and other descendants). Other instructions, such as xsl:if, pass on the items produced by their own nested sequence constructors.
Three instructions serve primarily to evaluate XPath expressions:
- The xsl:sequence instruction evaluates an XPath expression written statically in its select attribute.
- The xsl:select instruction evaluates an XPath expression written statically in its contained text node.
- The xsl:evaluate instruction compiles and evaluates an XPath expression that is constructed dynamically as a character string.
These three instructions may return atomic items, function items, or nodes.
An extension instruction (see 24.2 Extension Instructions) also produces a sequence of items as its result.

[Definition: The result of evaluating a sequence constructor is the sequence of items formed by concatenating the results of evaluating each of the nodes in the sequence constructor, retaining order. This is referred to as the immediate result of the sequence constructor.]

However:

For the effect of the xsl:fallback instruction, see 24.2.3 Fallback.
For the effect of the xsl:on-empty and xsl:on-non-empty instructions, see 8.5 Conditional Content Construction.

The way that immediate result of a sequence constructor is used depends on the containing element in the stylesheet, and is specified in the rules for that element. It is typically one of the following:

The immediate result may be bound to a variable or delivered as the result of a stylesheet function. In this case the as attribute of the containing xsl:variable or xsl:function element may be used to declare its required type, and the immediate result is then converted to the required type by applying the coercion rules.
Note:
- In the absence of an as attribute, the result of a function is the immediate result of the sequence constructor; but the value of a variable (for backwards compatibility reasons) is a document node whose content is formed by applying the rules in 5.7.1 Constructing Complex Content to the immediate result.
- The coercion rules do not merge adjacent text nodes or insert separators between adjacent items. This means it is often inappropriate to use xsl:value-of in the body of xsl:variable or xsl:function, especially when the intent is to return an atomic result. The xsl:sequence instruction is designed for this purpose, and is usually a better choice.
- The result of a function, or the value of a variable, may contain nodes (such as elements, attributes, and text nodes) that are not attached to any parent node in a result tree. The semantics of XPath expressions when applied to parentless nodes are well-defined; however, such expressions should be used with care. For example, the expression / causes a type error if the root of the tree containing the context node is not a document node.
- Parentless attribute nodes require particular care because they have no namespace nodes associated with them. A parentless attribute node is not permitted to contain namespace-sensitive content (for example, a QName or an XPath expression) because there is no information enabling the prefix to be resolved to a namespace URI. Parentless attributes can be useful in an application (for example, they provide an alternative to the use of attribute sets: see 10.2 Named Attribute Sets) but they need to be handled with care.
The sequence may be returned as the result of the containing element. This happens, for example, when the element containing the sequence constructor is xsl:break, xsl:catch, xsl:fallback, xsl:for-each, xsl:for-each-group, xsl:fork, xsl:if, xsl:iterate, xsl:matching-substring, xsl:non-matching-substring, xsl:on-completion, xsl:otherwise, xsl:perform-sort, xsl:sequence, xsl:try, or xsl:when.
The sequence may be used to construct the content of a new element or document node. This happens when the sequence constructor appears as the content of a literal result element, or of one of the instructions xsl:copy, xsl:element, xsl:document, xsl:result-document, xsl:assert, or xsl:message. It also happens when the sequence constructor is contained in one of the elements xsl:variable, xsl:param, or xsl:with-param, when this instruction has no as attribute. For details, see 5.7.1 Constructing Complex Content.
The sequence may be used to construct the string value of an attribute node, text node, namespace node, comment node, or processing instruction node. This happens when the sequence constructor is contained in one of the elements xsl:attribute, xsl:value-of, xsl:namespace, xsl:comment, or xsl:processing-instruction. For details, see 5.7.2 Constructing Simple Content.

5.7.1 Constructing Complex Content

Many instructions, for example xsl:copy, xsl:element, xsl:document, xsl:result-document, and literal result elements, create a new parent node, and evaluate a sequence constructor forming the content of the instruction to create the attributes, namespaces, and children of the new parent node. The immediate result of the sequence constructor is processed to create the content of the new parent node as described in this section.

When constructing the content of an element, the inherit-namespaces attribute of the xsl:element or xsl:copy instruction, or the xsl:inherit-namespaces property of the literal result element, determines whether namespace nodes are to be inherited. The effect of this attribute is described in the rules that follow.

The immediate result of the sequence constructor is processed as follows (applying the rules in the order they are listed):

The containing instruction may generate attribute nodes and/or namespace nodes, as specified in the rules for the individual instruction. For example, these nodes may be produced by expanding an [xsl:]use-attribute-sets attribute, or by expanding the attributes of a literal result element. Any such nodes are prepended to the immediate result of the sequence constructor.
Any array item in the sequence (see 22 Arrays) is replaced by its members, recursively. This is equivalent to applying the array:flatten function defined in [xpath-functions-31][Functions and Operators 4.0].
Any atomic item in the sequence is cast to a string.
Note:
Casting from xs:QName or xs:NOTATION to xs:string always succeeds, because these values retain a prefix for this purpose. However, there is no guarantee that the prefix used will always be meaningful in the context where the resulting string is used.
Any consecutive sequence of strings in the sequence is converted to a single text node, whose string value contains the content of each of the strings in turn, with U+0020 (SPACE) used as a separator between successive strings.
Any document node within the sequence is replaced by a sequence containing each of its children, in document order.
Zero-length text nodes within the sequence are removed.
Adjacent text nodes within the sequence are merged into a single text node.
Invalid items in the sequence are detected as follows.
[ERR XTDE0410] It is a dynamic error if the sequence used to construct the content of an element node contains a namespace node or attribute node that is preceded in the sequence by a node that is neither a namespace node nor an attribute node.
[ERR XTDE0420] It is a dynamic error if the sequence used to construct the content of a document node contains a namespace node or attribute node.
[ERR XTDE0430] It is a dynamic error if the sequence contains two or more namespace nodes having the same name but different string values (that is, namespace nodes that map the same prefix to different namespace URIs).
[ERR XTDE0440] It is a dynamic error if the sequence contains a namespace node with no name and the element node being constructed has a null namespace URI (that is, it is an error to define a default namespace when the element is in no namespace).
[ERR XTDE0450] It is a type error if the result sequence contains a function item.
Note:
The error code reflects the fact that this error was at one time classified as a dynamic error rather than a type error.
If the sequence contains two or more namespace nodes with the same name (or no name) and the same string value (that is, two namespace nodes mapping the same prefix to the same namespace URI), then all but one of the duplicate nodes are discarded.
Note:
Since the order of namespace nodes is implementation-dependent, it is not significant which of the duplicates is retained.
If an attribute A in the sequence has the same name as another attribute B that appears later in the sequence, then attribute A is discarded from the sequence. Before discarding attribute A, the processor may raise any type errors that would be raised if attribute B were not present.
Each node in the resulting sequence is attached as a namespace, attribute, or child of the newly constructed element or document node. Conceptually this involves making a deep copy of the node; in practice, however, copying the node will only be necessary if the existing node can be referenced independently of the parent to which it is being attached. When copying an element or processing instruction node, its base URI property is changed to be the same as that of its new parent, unless it has an xml:base attribute (see [XML Base]) that overrides this. If the copied element has an xml:base attribute, its base URI is the value of that attribute, resolved (if it is relative) against the base URI of the new parent node.
Except for the handling of base URI, the copying of a node follows the rules of the xsl:copy-of instruction with attributes copy-namespaces="yes" copy-accumulators="no" validation="preserve".
Note:
This has the consequence that the type annotation and the values of the nilled, is-id, and is-idrefs properties are retained. However, if the node under construction (the new parent of the node being copied) uses a validation mode other than preserve, this will be transient: the values will be recomputed when the new parent node is validated.
If the newly constructed node is an element node, then namespace fixup is applied to this node, as described in 5.7.3 Namespace Fixup.
If the newly constructed node is an element node, and if namespaces are inherited, then each namespace node of the newly constructed element (including any produced as a result of the namespace fixup process) is copied to each descendant element of the newly constructed element, unless that element or an intermediate element already has a namespace node with the same name (or absence of a name) or that descendant element or an intermediate element is in no namespace and the namespace node has no name.

Example: A Sequence Constructor for Complex Content

Consider the following stylesheet fragment:

<td>
  <xsl:attribute name="valign">top</xsl:attribute>
  <xsl:value-of select="@description"/>
</td>

This fragment consists of a literal result element td, containing a sequence constructor that consists of two instructions: xsl:attribute and xsl:value-of. The sequence constructor is evaluated to produce a sequence of two nodes: a parentless attribute node, and a parentless text node. The td instruction causes a td element to be created; the new attribute therefore becomes an attribute of the new td element, while the text node created by the xsl:value-of instruction becomes a child of the td element (unless it is zero-length, in which case it is discarded).

Example: Space Separators in Element Content

Consider the following stylesheet fragment:

<doc>
  <e><xsl:sequence select="1 to 5"/></e>
  <f>
    <xsl:for-each select="1 to 5">
      <xsl:value-of select="."/>
    </xsl:for-each>
  </f>
</doc>

This produces the output (when indented):

<doc>
  <e>1 2 3 4 5</e>
  <f>12345</f>
</doc>

The difference between the two cases is that for the e element, the sequence constructor generates a sequence of five atomic items, which are therefore separated by spaces. For the f element, the content is a sequence of five text nodes, which are concatenated without space separation.

It is important to be aware of the distinction between xsl:sequence, which returns the value of its select expression unchanged, and xsl:value-of, which constructs a text node.

6 Template Rules

Template rules define the processing that can be applied to items that match a particular pattern.

6.3 Patterns

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 ItemType^XP 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, *)", andwhile 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 pattern match="type(text() | comment())" has almost the same effect as match="text() | comment()", except that the rules for calculating a default priority are different.
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; an item other than an XNode will never match an XNode pattern. 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.
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.

6.3.1 Examples of Patterns

Example: Patterns

Here are some examples of patterns:

Predicate Patterns:
1. . matches any item.
2. .[. castable as xs:date] matches any item that can be successfully cast to xs:date: for example, an xs:date or xs:dateTime value, or a string in the lexical form of a date, or a node whose typed value is an xs:date or a string in the form of a date.
3. .[string() => matches('^[0-9]$')] matches any item whose string value is a sequence of digits.
4. .[. castable as xs:date][xs:date(.) le current-date()] matches any item that is castable to xs:date provided that the result of casting the value to xs:date is a date in the past.
Type Patterns
1. type(item()) matches any item.
2. type(node()) matches any node. (Note the distinction from the pattern node().)
3. type(xs:date) matches any atomic item of type xs:date (or a type derived by restriction from xs:date).
4. type(xs:date)[. gt current-date()] matches any date in the future.
5. type(xs:string)[starts-with(., 'e')] matches any xs:string value that starts with the letter e. Note there is no type conversion; the pattern will not match an xs:untypedAtomic or xs:anyURI value, nor will it match anya node.
6. type(fn(*)) matches any function item.
7. type(fn($x as xs:integer) as xs:boolean)[.(42)] matches any function that accepts an xs:integer argument and returns a boolean result, provided that the result of calling the function with the argument value 42 is true.
8. type(xs:date | xs:dateTime | xs:time) matches any atomic item that is an instance of xs:date, xs:dateTime, or xs:time.
9. type(array(xs:date) | array(xs:dateTime) | array(xs:time)) matches any array whose members are all of type xs:date, any array whose members are all of type xs:dateTime, or any array whose members are all of type xs:time. Contrast type(array(xs:date | xs:dateTime | xs:time)) which allows the three types to be mixed within a single array.
10. type(map((xs:string|xs:untypedAtomic), *) matches any map whose keys are all instances of xs:string or xs:untypedAtomic.
11. enum("red", "green", "blue") matches any one of the three strings "red", "green", or "blue".
12. record(first, last, *)[?location = 'UK'] matches any map whose keys include the strings "first" and "last", and that also has an entry with key "location" whose value is "UK".
13. record(longitude, latitude) matches any map with two entries whose keys are the strings "longitude" and "latitude".
14. record(title, author as enum("Dickens"), *) matches having an entry whose keys is the string "title", plus an entry whose key is the string "author" and whose associated value is the string "Dickens".
15. record(title, author as enum("Dickens"), *) matches having an entry whose keys is the string "title", plus an entry whose key is the string "author" and whose associated value is the string "Dickens".
16. array(xs:integer)[array:size(.) eq 4] matches any array of four integers.
17. array(record(first, last, *)) matches any array of maps where each map contains entries with keys "first" and "last". (Note that this includes the empty array).
18. array(record(first, last, *))[array:size(.) gt 0] matches any non-empty array of maps where each map contains entries with keys "first" and "last".
19. type(complex) matches any value that is an instance of the item type declared in an xsl:item-type or xsl:record-type declaration with name "complex"
20. type(complex)[?i eq 0] matches any value that is an instance of the item type declared in an xsl:item-type or xsl:record-type declaration with name "complex" and that is a map with an entry having key i and value zero.
XNode Patterns
1. * matches any element.
2. para matches any para element.
3. chapter|appendix matches any chapter element and any appendix element.
4. child::(chapter|appendix) matches any chapter element and any appendix element. Note that although the child axis is explicitly written, an element can match even though it has no parent.
5. olist/entry matches any entry element with an olist parent.
6. appendix//para matches any para element with an appendix ancestor element.
7. appendix/descendant::(para|table) matches any para or tableelement with an appendix ancestor element.
8. schema-element(us:address) matches any element that is annotated as an instance of the type defined by the schema element declaration us:address, and whose name is either us:address or the name of another element in its substitution group.
9. attribute(*, xs:date) matches any attribute annotated as being of type xs:date.
10. / matches a document node.
11. document-node() matches a document node.
12. document-node(schema-element(my:invoice)) matches the document node of a document whose document element is named my:invoice and matches the type defined by the global element declaration my:invoice.
13. text() matches any text node.
14. namespace-node() matches any namespace node.
15. node() matches any node other than an attribute node, namespace node, or document node.
16. id("W33") matches the element with unique ID W33.
17. para[1] matches any para element that is the first para child element of its parent. It also matches a parentless para element.
18. //para matches any para element in a tree that is rooted at a document node.
19. bullet[position() mod 2 = 0] matches any bullet element that is an even-numbered bullet child of its parent.
20. div[@class="appendix"]//p matches any p element with a div ancestor element that has a class attribute with value appendix.
21. @class matches any class attribute (not any element that has a class attribute).
22. @(class|type|kind) matches any attribute named class or type or kind.
23. @* matches any attribute node.
24. $xyz matches any nodeXNode that is present in the value of the variable $xyz. Note that it will not match any other item that is present in the value of the variable.
25. $xyz//* matches any element that is a descendant of a node that is present in the value of the variable $xyz.
26. doc('product.xml')//* matches any element within the document whose document URI is product.xml.
JNode Patterns
1. jnode(*, *) matches any JNode.
2. jnode("date of birth", *) matches any JNode representing a map entry with key "date of birth".
3. jnode(*, array(xs:integer)) matches any JNode representing a map entry or array item whose value is an array of integers.
4. jnode(books, array(record("Author", "Title", *))) matches any JNode representing a map entry whose key is "books" and whose content is an array of records, each record having entries named "Author" and "Title" (with other entries also allowed).
5. jnode(*, record(Author as enum("Dickens"), Title, *)) matches any JNode whose content is a map having an entry with key "Author" and value "Dickens", plus an entry with key "Title" (with other entries also allowed).
6. jnode(*, record(Author as enum("Dickens"), Title, *)) matches any JNode whose content is a map having an entry with key "Author" and value "Dickens", plus an entry with key "Title" (with other entries also allowed).

6.3.2 Syntax of Patterns

[ERR XTSE0340] Where an attribute is defined to contain a pattern, it is a static error if the pattern does not match the production Pattern.

The complete grammar for patterns is listed in E Pattern Syntax Summary. It uses the notation defined in [XPath 4.0] section A.1.1 Notation.

The lexical rules for patterns are the same as the lexical rules for XPath expressions, as defined in [XPath 4.0] section A.3 Lexical structure. Comments are permitted between tokens, using the syntax (: ... :). All other provisions of the XPath grammar apply where relevant, for example the rules for whitespace handling and extra-grammatical constraints.

`Pattern`	::=	`UnionPattern`
`UnionPattern`	::=	`IntersectExceptPattern (("union" \| "\|") IntersectExceptPattern)*`
`IntersectExceptPattern`	::=	`PrimaryPattern (("intersect" \| "except") PrimaryPattern)*`
`PrimaryPattern`	::=	`ParenthesizedPattern \| PredicatePattern \| TypePattern \| XNodePattern \| JNodePattern`
`ParenthesizedPattern`	::=	`"(" Pattern ")"`
`PredicatePattern`	::=	`"." Predicate^XP*`
`TypePattern`	::=	`(WrappedItemTest \| AnyItemTest^XP \| FunctionType^XP \| MapType^XP \| ArrayType^XP \| RecordType^XP \| EnumerationType^XP) Predicate^XP*`
`XNodePattern`	::=	`PathExprP`
`JNodePattern`	::=	`"jnode" "(" JNodePatternSelector "," JNodePatternContent ")" Predicate^XP*`

Patterns fall into four groups:

A PredicatePattern matches items according to conditions that the item must satisfy: for example .[. castable as xs:integer] matches any value (it might be an atomic item, a node, or an array) that is castable as an integer.
A TypePattern matches items according to their type. For example type(xs:integer) matches an atomic item that is an instance of xs:integer, while record(longitude, latitude) matches a map that has exactly two entries, with keys "longitude" and "latitude"
An XNodePattern matches XNodes in an XTree (that is, typically a tree representing the contents of an XML document), by specifying a path that can be used to locate the nodes: for example order matches an element node named order, while billing-address/city matches an element named city whose parent node is an element named billing-address.
The grammar for XNodePattern also allows a ParenthesizedPattern, which can be used to match items other than XNodes. This allows patterns such as P except (Q union R), where P, Q, and R are arbitrary patterns.
A JNodePattern matches JNodes in a JTree (a tree of maps and arrays, often representing the contents of a JSON document), by specifying constraints on the properties of the JNode, notably its ·selector· and ·content· properties. For example the pattern jnode(order, *) matches a JNode corresponding to a map entry with the key "order".

The four kinds of primary pattern listed above may be combined using the union (or |), intersect, and except operators. By virtue of the fact that the grammar for XNodePattern allows a parenthesized pattern, they can also be combined using parentheses.

The following sections define the rules for each of these groups.

6.3.2.3 XNode Patterns

Changes in 4.0 ⬇ ⬆

A function call at the outermost level can now be named using any valid EQName (for example fn:doc) provided it binds to one of the permitted functions fn:doc, fn:id, fn:element-with-id, fn:key, or fn:root. If two functions are called, for example doc('a.xml')/id('abc'), it is no longer necessary to put the second call in parentheses. [Issues 1375 1522 PR 1378 15 October 2024]
The semantics of patterns using the intersect and except operators have been changed to reflect the intuitive meaning: for example a node now matches A except B if it matches A and does not match B. [Issue 402 ]

`XNodePattern`	::=	`PathExprP`
`PathExprP`	::=	`RootedPath \| ("/" RelativePathExprP?) \| ("//" RelativePathExprP) \| RelativePathExprP`
		/* xgs: leading-lone-slash */
`RootedPath`	::=	`VarRef^XPPredicate^XP* (("/" \| "//") RelativePathExprP)?`
`VarRef`	::=	`"$" EQName^XP`
`EQName`	::=	`QName \| URIQualifiedName^XP`
`URIQualifiedName`	::=	`BracedURILiteralNCName`
		/* ws: explicit */
`Predicate`	::=	`"[" Expr^XP "]"`
`Expr`	::=	`(ExprSingle^XP ++ ",")`
`ExprSingle`	::=	`ForExpr^XP \| LetExpr^XP \| QuantifiedExpr^XP \| IfExpr^XP`
`RelativePathExprP`	::=	`StepExprP (("/" \| "//") StepExprP)*`
`StepExprP`	::=	`PostfixExprP \| AxisStepP`
`PostfixExprP`	::=	`(FunctionCallP \| ParenthesizedExprPParenthesizedPattern) Predicate^XP*`
`AxisStepP`	::=	`ForwardStepPPredicate^XP*`
`FunctionCallP`	::=	`OuterFunctionNameArgumentListP`
`ParenthesizedExprPParenthesizedPatternParenthesizedExprPParenthesizedPattern`	::=	`"(" PathExprP ")""(" Pattern ")""(" PathExprPPattern ")"`
`ForwardStepP`	::=	`(ForwardAxisPNodeTest^XP) \| AbbrevForwardStepP`

XNode Patterns are used to match XNodes (typically, nodes in a tree representing an XML document). In addition, an XNodePattern that consists simply of a ParenthesizedPattern, followed optionally by one or more predicates, can match any kind of item.

The names of many of these constructs are chosen to align with the XPath 4.0 grammar. Constructs whose names are suffixed with P are restricted forms of the corresponding XPath 3.04.0 construct without the suffix. Constructs labeled with the suffix “XP40XP” are defined in [XPath 4.0].

In addition to satisfying the grammar as given, the content of any ParenthesizedPattern within an XNodePattern that contains a / or // operator (other than within a predicate) must itself parse as an XNodePattern.

Note:

For example, this means that (array(*))/para is not a valid pattern; neither is para/(array(*)).

The reason for this rule is to ensure that every non-trivial XNodePattern is a valid XPath expression, which enables the semantics to be defined in terms of the semantics of XPath expressions: see 6.3.2.3.1 The Meaning of an XNode Pattern.

In a FunctionCallP, the EQName used for the function name must bind to one of the functions fn:doc#1, fn:id#1, fn:id#2, fn:element-with-id#1, fn:element-with-id#2fn:key#2, fn:key#3 or fn:root#0.

Note:

In the case of a call to the fn:root function, the argument list must be empty: that is, only the zero-arity form of the function is allowed.

Note:

As with XPath expressions, the pattern / union /* can be parsed in two different ways, and the chosen interpretation is to treat union as an element name rather than as an operator. The other interpretation can be achieved by writing (/) union (/*)

6.3.2.3.1 The Meaning of an XNode Pattern

The meaning of an XNode pattern is defined formally as follows, where “if” is to be read as “if and only if”.

A ParenthesizedPattern followed by zero or more predicates matches an item if the pattern within the parentheses matches the item and each of the predicates matches the item.
A ParenthesizedPattern followed by zero or more predicates matches an item if the pattern within the parentheses matches the item and each of the predicates matches the item.
An XNode matches a PathExprP under the following conditions:
1. The PathExprP pattern is converted to an expression, called the equivalent expression. The equivalent expression to a PathExprP is the XPath expression that takes the same lexical form as the PathExprP as written, with the following adjustment:
  If any PathExprP in the Pattern is a RelativePathExprP, then the first StepExprPPS of this RelativePathExprP is adjusted to allow it to match a parentless element, attribute, or namespace node. The adjustment depends on the axis used in this step, whether it appears explicitly or implicitly (according to the rules of [XPath 4.0] section 4.6.7 Abbreviated Syntax), and is made as follows:
  1. If the NodeTest in PS is document-node() (optionally with arguments), and if no explicit axis is specified, then the axis in step PS is taken as self rather than child.
  2. If PS uses the child axis (explicitly or implicitly), and if the NodeTest in PS is not document-node() (optionally with arguments), then the axis in step PS is replaced by child-or-top, which is defined as follows. If the context node is a parentless element, comment, processing-instruction, or text node then the child-or-top axis selects the context node; otherwise it selects the children of the context node. It is a forwards axis whose principal node kind is element.
  3. If PS uses the attribute axis (explicitly or implicitly), then the axis in step PS is replaced by attribute-or-top, which is defined as follows. If the context node is an attribute node with no parent, then the attribute-or-top axis selects the context node; otherwise it selects the attributes of the context node. It is a forwards axis whose principal node kind is attribute.
  4. If PS uses the namespace axis (explicitly or implicitly), then the axis in step PS is replaced by namespace-or-top, which is defined as follows. If the context node is a namespace node with no parent, then the namespace-or-top axis selects the context node; otherwise it selects the namespace nodes of the context node. It is a forwards axis whose principal node kind is namespace.
  The axes child-or-top, attribute-or-top, and namespace-or-top are introduced only for definitional purposes. They cannot be used explicitly in a user-written pattern or expression.
  Note:
  The purpose of this adjustment is to ensure that a pattern such as person matches any element named person, even if it has no parent; and similarly, that the pattern @width matches any attribute named width, even a parentless attribute. The rule also ensures that a pattern using a NodeTest of the form document-node(...) matches a document node. The pattern node() will match any element, text node, comment, or processing instruction, whether or not it has a parent. For backwards compatibility reasons, the pattern node(), when used without an explicit axis, does not match document nodes, attribute nodes, or namespace nodes. The rules are also phrased to ensure that positional patterns of the form para[1] continue to count nodes relative to their parent, if they have one. To match any node at all, XSLT 4.0 allows the pattern .[. instance of type(node()]) to be used.
The meaning of the pattern is then defined in terms of the semantics of the equivalent expression, denoted below as EE.
Specifically, an item N matches a PathExprP pattern P if the following applies, where EE is the equivalent expression to P:
- N is an XNode, and the result of evaluating the expression root(.)//(EE) with a singleton focus based on N is a sequence that includes the XNode N.

If a pattern appears in an attribute of an element that is processed with XSLT 1.0 behavior (see 3.9 Backwards Compatible Processing), then the semantics of the pattern are defined on the basis that the equivalent XPath expression is evaluated with XPath 1.0 compatibility mode set to true.

Note:

This version of the specification includes an incompatible change to the semantics of patterns using the intersect and except operators. This change is made to eliminate cases where the behavior defined in XSLT 3.0 was counter-intuitive.

Consider the pattern para except appendix//para. In XSLT 4.0 this matches any para element that is not the descendant of an appendix element. In XSLT 3.0 it would match the para element in the XML tree shown below:

<appendix>
  <section>
     <para/>
  </section>
</appendix>

because there is an element $S (specifically, the section element), such that the expression $S//(para except appendix//para) selects this para element.

It is recommended that processors should report a compatibility warning when such constructs are encountered. The problem arises with patterns using intersect or except where one of the branches uses the descendant axis: it does not arise in simple cases like * except A, or @* except @code, where the branches only use the child or attribute axis.

The change does not affect the meaning of patterns that use the intersect or except operators nested within a path expression, for example a pattern such as A[.//C except B//C].

Example: The Semantics of XNode Patterns

The XNode patternp matches any p element, because a p element will always be present in the result of evaluating the expressionroot(.)//(child-or-top::p). Similarly, / matches a document node, and only a document node, because the result of the expressionroot(.)//(/) returns the root node of the tree containing the context node if and only if it is a document node.

The XNode patternnode() matches all XNodes selected by the expression root(.)//(child-or-top::node()), that is, all element, text, comment, and processing instruction nodes, whether or not they have a parent. It does not match attribute or namespace nodes because the expression does not select nodes using the attribute or namespace axes. It does not match document nodes because for backwards compatibility reasons the child-or-top axis does not match a document node.

Note:

The pattern type(node()) matches all XNodes.

The XNode pattern$V matches all XNodes selected by the expression root(.)//($V), that is, all XNodes in the value of $V (which will typically be a global variable, though when the pattern is used in contexts such as the xsl:number or xsl:for-each-group instructions, it can also be a local variable).

The XNode patterndoc('product.xml')//product matches all XNodes selected by the expression root(.)//(doc('product.xml')//product), that is, all product elements in the document whose URI is product.xml.

The XNode patternroot(.)/self::E matches an E element that is the root of a tree (that is, an E element with no parent node).

Although the semantics of XNode patterns are specified formally in terms of expression evaluation, it is possible to understand pattern matching using a different model. A XNode pattern such as book/chapter/section can be examined from right to left. A node will only match this pattern if it is a section element; and then, only if its parent is a chapter; and then, only if the parent of that chapter is a book. When the pattern uses the // operator, one can still read it from right to left, but this time testing the ancestors of a node rather than its parent. For example appendix//section matches every section element that has an ancestor appendix element.

The formal definition, however, is useful for understanding the meaning of a pattern such as para[1]. This matches any node selected by the expression root(.)//(child-or-top::para[1]): that is, any para element that is the first para child of its parent, or a para element that has no parent.

Note:

An implementation, of course, may use any algorithm it wishes for evaluating patterns, so long as the result corresponds with the formal definition above. An implementation that followed the formal definition by evaluating the equivalent expression and then testing the membership of a specific node in the result would probably be very inefficient.

Note:

Patterns using the intersect and except operators do not always have the intuitive meaning: in particular, it is not always the case that a node matches A except B if it matches A but does not match B.

For example, consider the pattern para except appendix//para. This expands to root(.)/descendant-or-self::node()/(child::para except child::appendix//para). Since for a given parent node, the results of child::para and child::appendix are disjoint, the right-hand operand of except has no effect.

The effect of matching all paragraphs except those within an appendix can be achieved using the pattern para except //appendix//para; alternatively, use para[not(ancestor::appendix)].

Simpler patterns such as @* except @code generally have the expected effect; the complications arise mainly when non-trivial relative paths are used.

9 Variables and Parameters

[Definition: The two elements xsl:variable and xsl:param are referred to as variable-binding elements.]

[Definition: The xsl:variable element declares a variable, which may be a global variable or a local variable.]

[Definition: The xsl:param element declares a parameter, which may be a stylesheet parameter, a template parameter, a function parameter, or an xsl:iterate parameter. A parameter is a variable with the additional property that its value can be set by the caller.]

[Definition: A variable is a binding between a name and a value. The value of a variable is any sequence (of nodes, atomic items, and/or function items), as defined in [XDM 4.0].]

9.7 Static Expressions

[Definition: A static expression is an XPath expression whose value must be computed during static analysis of the stylesheet.]

Static expressions appear in a number of contexts, in particular:

In [xsl:]use-when attributes (see 3.13.3 Conditional Element Inclusion);
In the select attribute of static variable declarations (xsl:variable or xsl:param with static="yes");
In shadow attributes (see 3.13.4 Shadow Attributes).

There are no syntactic constraints on the XPath expression that can be used as a static expression. However, there are severe constraints on the information provided in its evaluation context. These constraints are designed to ensure that the expression can be evaluated at the earliest possible stage of stylesheet processing, without any dependency on information contained in the stylesheet itself or in any source document.

Specifically, the components of the static and dynamic context are defined by the following two tables:

Static Context Components for Static Expressions
Component	Value
XPath 1.0 compatibility mode	false
Statically known namespaces	the applicable static namespaces for the containing element in the stylesheet
Default namespace for elements and types	determined by the `xpath-default-namespace` attribute if present (see 5.1.2 Unprefixed Lexical QNames in Expressions and Patterns); otherwise absent
Default function namespace	the standard function namespace.
In-scope schema types	The type definitions that would be available in the absence of any `xsl:import-schema` declaration
In-scope element declarations	None
In-scope attribute declarations	None
In-scope variables	The static variables visible within the containing package whose declarations occur prior to the element containing the static expression in stylesheet tree order. Stylesheet tree order is the order that results when all `xsl:import` and `xsl:include` declarations are replaced by the declarations in the imported or included stylesheet module. A static variable is not in scope within its own declaration, and it is in scope only within its declaring package, not in any using packages. If two static variables satisfying this rule have the same name and are both in scope, the one that appears most recently in stylesheet tree order is used; as a consequence of rules defined elsewhere this will always be consistent with the declaration having highest import precedence.
Context item static type	Absent
In-scope named item types	None
Statically known function definitions	The functions defined in [Functions and Operators 4.0] in the `fnmath`, `map`, and `array` namespaces, together with: the functions `element-available`, `function-available`, `type-available`, `available-system-properties`, and `system-property` defined in this specification; functions that appear in both this specification and in [xpath-functions-31][Functions and Operators 4.0] (for example, the functions in the `map` namespaces, and a few others such as `collation-key` and `json-to-xml`); constructor functions for built-in types; the set of extension functions that are present in the static context of every XPath expression (other than a static expression) within the content of the element that contains the static expression. Note that stylesheet functions are not included in the context, which means that the function `function-available` will return `false` in respect of such functions, and `function-lookup` will fail to find them. The effect of this rule is to ensure that `function-available` returns `true` in respect of functions that can be called within the static expression. It also has the effect that these extension functions will be recognized within the static expression itself; however, the fact that a function is available in this sense gives no guarantee that a call on the function will succeed.
Statically known collations	Implementation-defined
Default collation	The Unicode Codepoint Collation
Static Base URI	The base URI of the containing element in the stylesheet document (see [XDM 4.0] section 7.5.2 base-uri Accessor)
Statically known documents	Implementation-defined
Statically known collections	Implementation-defined
Statically known default collection type	Implementation-defined
Statically known decimal formats	A single unnamed decimal format equivalent to the decimal format that is created by an `xsl:decimal-format` declaration with no attributes.

Dynamic Context Components for Static Expressions
Component	Value
Context item, position, and size	Absent
Variable values	A value for every variable present in the in-scope variables. For static parameters where an external value is supplied: the externally supplied value of the parameter. In all other cases: the value of the variable as defined in 9.3 Values of Variables and Parameters.
Dynamically known function definitions	The same as the statically known function definitions
Current dateTime	Implementation-defined
Implicit timezone	Implementation-defined
Executable Base URI	The same as the Static Base URI
Default collation	The Unicode Codepoint Collation
Default language	Implementation-defined
Default calendar	Implementation-defined
Default place	Implementation-defined
Available documents	Implementation-defined
Available text resources	Implementation-defined
Available collections	Implementation-defined
Default collection	Implementation-defined
Available URI collections	Implementation-defined
Default URI collection	Implementation-defined
Environment variables	Implementation-defined

Within a stylesheet module, all static expressions are evaluated in a single execution scope^FO. This need not be the same execution scope as that used for static expressions in other stylesheet modules, or as that used when evaluating XPath expressions appearing elsewhere in the stylesheet module. This means that a function such as current-date will return the same result when called in different [xsl:]use-when expressions within the same stylesheet module, but will not necessarily return the same result as the same call in an [xsl:]use-when expression within a different stylesheet module, or as a call on the same function executed during the transformation proper.

If a static error is present in a static expression, it is treated in the same way as any other static error in the stylesheet module. If a dynamic error occurs during evaluation of a static expression, it is treated as a static error in the analysis of the stylesheet, while retaining its original error code.

10 Callable Components

This section describes three constructs that can be used to provide subroutine-like functionality that can be invoked from anywhere in the stylesheet: named templates (see 10.1 Named Templates), named attribute sets (see 10.2 Named Attribute Sets), and stylesheet functions (see 10.3 Stylesheet Functions).

[Definition: The following constructs are classified as invocation constructs: the instructions xsl:call-template, xsl:apply-templates, xsl:apply-imports, and xsl:next-match; XPath function calls that bind to stylesheet functions; XPath dynamic function calls; the functions accumulator-before and accumulator-after; the [xsl:]use-attribute-sets attribute. These all have the characteristic that they can cause evaluation of constructs that are not lexically contained within the calling construct.]

10.3 Stylesheet Functions

Changes in 4.0 ⬇ ⬆

Parameters on functions declared using xsl:function can now be defined as optional, with a default value supplied. [Issue 155 PR 159 30 September 2022]

[Definition: An xsl:function declaration declares the name, parameters, and implementation of a family of stylesheet functions that can be called from any XPath expression within the stylesheet (subject to visibility rules).]

The effect of an xsl:function declaration is to add a function definition to the static context for all XPath expressions used in the stylesheet (including an XPath expression used within a predicate in a pattern).

The content of the xsl:function element consists of zero or more xsl:param elements that specify the formal parameters of the function, followed by a sequence constructor that defines the value to be returned by the function.

The children and attributes of the xsl:function declaration translate directly into properties of the function definition:

The xsl:function/@name attribute defines the function’s name.
The xsl:param children define the function’s parameters:
- The xsl:param/@name attribute defines the name of the parameter.
- The xsl:param/@required attribute determines whether the parameter is mandatory or optional.
- The xsl:param/@as attribute determines the required type of the parameter.
- The xsl:param/@select attribute determines a default value for an optional parameter.
The xsl:function/@as attribute defines the return type of the function.
The implementation of the function is defined by the sequence constructor content of the xsl:function element.

An xsl:function declaration can only appear as a top-level element in a stylesheet module.

10.3.7 Determinism of Functions

Stylesheet functions have been designed to be largely deterministic: unless a stylesheet function calls some extension function which is itself nondeterministic, the function will return results that depend only on the supplied arguments. This property (coupled with the fact that the effect of calling extension functions is entirely implementation-dependent) enables a processor to implement various optimizations, such as removing invariant function calls from the body of a loop, or combining common subexpressions.

One exception to the intrinsic determinism of stylesheet functions arises because constructed nodes have distinct identity. This means that when a function that creates a new node is called, two calls on the function will return nodes that can be distinguished: for example, with such a function, f:make-node() is f:make-node() will return false.

Three classes of functions can be identified:

Deterministic^FO functions: as the term is defined in [xpath-functions-31][Functions and Operators 4.0], these offer a guarantee that when a function is called repeatedly with the same arguments, it returns the same results. A classic example is the doc function, which offers the guarantee that doc($X) is doc($X): that is, two calls supplying the same URI return the same node.
Proactive functions: these offer the guarantee that each invocation of the function causes a single execution of the function body, or behaves exactly as if it did so. In particular this means that when the function creates new nodes, it creates new nodes on each invocation. By default, stylesheet functions are proactive.
Elidable functions: these offer no guarantee of determinism, and no guarantee of proactive evaluation. If the function creates new nodes, then two calls on the function with the same arguments may or may not return the same nodes, at the implementation’s discretion. Examples of elidable functions include the [xpath-functions-31][Functions and Operators 4.0] functions analyze-string and json-to-xml.

The new-each-time attribute of xsl:function allows a stylesheet function to be assigned to one of these three categories. The value new-each-time="no" means the function is deterministic; the value new-each-time="yes" means it is proactive; and the value new-each-time="maybe" means it is elidable.

The definition of determinism^FO requires a definition of what it means for a function to be called twice with “the same” arguments and to return “the same” result. This is defined in [xpath-functions-31][Functions and Operators 4.0], specifically by the definition of the term identical^FO.

Processors have considerable freedom to optimize execution of stylesheets, and of function calls in particular, but the strategies that are adopted must respect the specification as to whether functions are deterministic, proactive, or elidable. For example, consider a function call that appears within an xsl:for-each instruction, where the supplied arguments to the function do not depend on the context item or on any variables declared within the xsl:for-each instruction. A possible optimization is to execute the function call only once, rather than executing it repeatedly each time round the loop (this is sometimes called loop-lifting). This optimization is safe when the function is deterministic or elidable, but it requires great care if the function is proactive; it is permitted only if the processor is able to determine that the results of stylesheet execution are equivalent to the results that would be obtained if the optimization had not been performed. Declaring a function call to be elidable (by writing new-each-time="maybe") makes it more likely that an implementation will be able to apply this optimization, as well as other optimizations such as caching or memoization.

12 Numbering

 <xsl:number value? = expression select? = expression level? = "single" | "multiple" | "any"〔'single'〕 count? = pattern from? = pattern format? = { string }〔'1'〕 lang? = { language } letter-value? = { "alphabetic" | "traditional" } ordinal? = { string }〔'no'〕 start-at? = { string } grouping-separator? = { char } grouping-size? = { integer } />

The xsl:number instruction is used to create a formatted number. The result of the instruction is a newly constructed text node containing the formatted number as its string value.

[Definition: The xsl:number instruction performs two tasks: firstly, determining a place marker (this is a sequence of integers, to allow for hierarchic numbering schemes such as 1.12.2 or 3(c)ii), and secondly, formatting the place marker for output as a text node in the result sequence.] The place marker to be formatted can either be supplied directly, in the value attribute, or it can be computed based on the position of a selected node within the tree that contains it.

[ERR XTSE0975] It is a static error if the value attribute of xsl:number is present unless the select, level, count, and from attributes are all absent.

Note:

The facilities described in this section are specifically designed to enable the calculation and formatting of section numbers, paragraph numbers, and the like. For formatting of other numeric quantities, the format-number function may be more suitable.

Furthermore, formatting of integers where there is no requirement to calculate the position of a node in the document can now be accomplished using the format-integer function, which borrows many concepts from the xsl:number specification.

12.2 Formatting a Supplied Number

The place marker to be formatted may be specified by an expression. The value attribute contains the expression. The value of this expression is atomized using the procedure defined in [xpath-30][XPath 4.0], and each value $V in the atomized sequence is then converted to the integer value returned by the XPath expression xs:integer(round(number($V))). If the start-at attribute is present, this sequence is then re-based as described in 12.1 The start-at Attribute. The resulting sequence of integers is used as the place marker to be formatted.

If the instruction is processed with XSLT 1.0 behavior, then:

All items in the atomized sequence after the first are discarded;
If the atomized sequence is empty, it is replaced by a sequence containing the xs:double value NaN as its only item;
If any value in the sequence cannot be converted to an integer (this includes the case where the sequence contains a NaN value) then the string NaN is inserted into the formatted result string in its proper position. The error described in the following paragraph does not apply in this case.

[ERR XTDE0980] It is a dynamic error if any undiscarded item in the atomized sequence supplied as the value of the value attribute of xsl:number cannot be converted to an integer, or if the resulting integer is less than 0 (zero).

Note:

The value zero does not arise when numbering nodes in a source document, but it can arise in other numbering sequences. It is permitted specifically because the rules of the xsl:number instruction are also invoked by functions such as format-time: the minutes and seconds component of a time value can legitimately be zero.

The resulting sequence is formatted as a string using the effective values of the attributes specified in 12.4 Number to String Conversion Attributes; each of these attributes is interpreted as an attribute value template. After conversion, the xsl:number element constructs a new text node containing the resulting string, and returns this node.

Example: Numbering a Sorted List

The following example numbers a sorted list:

<xsl:template match="items">
  <xsl:for-each select="item">
    <xsl:sort select="."/>
    <p>
      <xsl:number value="position()" format="1. "/>
      <xsl:value-of select="."/>
    </p>
  </xsl:for-each>
</xsl:template>

13 Sorting

[Definition: A sort key specification is a sequence of one or more adjacent xsl:sort elements which together define rules for sorting the items in an input sequence to form a sorted sequence.]

[Definition: Within a sort key specification, each xsl:sort element defines one sort key component.] The first xsl:sort element specifies the primary component of the sort key specification, the second xsl:sort element specifies the secondary component of the sort key specification, and so on.

A sort key specification may occur immediately within an xsl:apply-templates, xsl:for-each, xsl:perform-sort, or xsl:for-each-group element.

Note:

When used within xsl:for-each, xsl:for-each-group, or xsl:perform-sort, xsl:sort elements must occur before any other children.

13.1 The `xsl:sort` Element

<xsl:sort select? = expression lang? = { language } order? = { "ascending" | "descending" }〔'ascending'〕 collation? = { uri } stable? = { boolean }〔'yes'〕 case-order? = { "upper-first" | "lower-first" } data-type? = { "text" | "number" | eqname } >  </xsl:sort>

The xsl:sort element defines a sort key component. A sort key component specifies how a sort key value is to be computed for each item in the sequence being sorted, and also how two sort key values are to be compared.

The value of a sort key component is determined either by its select attribute or by the contained sequence constructor. If neither is present, the default is select=".", which has the effect of sorting on the actual value of the item if it is an atomic item, or on the typed-value of the item if it is a node. If a select attribute is present, its value must be an XPath expression.

[ERR XTSE1015] It is a static error if an xsl:sort element with a select attribute has non-empty content.

Those attributes of the xsl:sort elements whose values are attribute value templates are evaluated using the same focus as is used to evaluate the select attribute of the containing instruction (specifically, xsl:apply-templates, xsl:for-each, xsl:for-each-group, or xsl:perform-sort).

The stable attribute is permitted only on the first xsl:sort element within a sort key specification.

[ERR XTSE1017] It is a static error if an xsl:sort element other than the first in a sequence of sibling xsl:sort elements has a stable attribute.

[Definition: A sort key specification is said to be stable if its first xsl:sort element has no stable attribute, or has a stable attribute whose effective value is yes.]

13.1.3 Sorting Using Collations

The rules given in this section apply when comparing values whose type is xs:string or a type derived by restriction from xs:string, or whose type is xs:anyURI or a type derived by restriction from xs:anyURI.

[Definition: Facilities in XSLT 3.0 and XPath 3.0 that require strings to be ordered rely on the concept of a named collation. A collation is a set of rules that determine whether two strings are equal, and if not, which of them is to be sorted before the other.] A collation is identified by a URI, but the manner in which this URI is associated with an actual rule or algorithm is largely implementation-defined.

For more information about collations, see [Functions and Operators 4.0] section 5.3 Comparison of strings in [Functions and Operators 4.0]. Some specifications, for example [UNICODE TR10], use the term “collation” to describe rules that can be tailored or parameterized for various purposes. In this specification, a collation URI refers to a collation in which all such parameters have already been fixed. Therefore, if a collation URI is specified, other attributes such as case-order and lang are ignored.

Every implementation must recognize the collation URI http://www.w3.org/2005/xpath-functions/collation/codepoint, which provides the ability to compare strings based on the Unicode codepoint values of the characters in the string.

Furthermore, every implementation must recognize collation URIs representing tailorings of the Unicode Collation Algorithm (UCA), as described in [Functions and Operators 4.0] section 13.4 The Unicode Collation Algorithm5.3.4 The Unicode Collation Algorithm13.45.3.4 The Unicode Collation Algorithm. Although this form of collation URI must be recognized, implementations are not required to support every possible tailoring.

If the xsl:sort element has a collation attribute, then the strings are compared according to the rules for the named collation: that is, they are compared using the XPath function call compare($a, $b, $collation).

If the effective value of the collation attribute of xsl:sort is a relative URI, then it is resolved against the base URI of the xsl:sort element.

[ERR XTDE1035] It is a dynamic error if the collation attribute of xsl:sort (after resolving against the base URI) is not a URI that is recognized by the implementation as referring to a collation.

Note:

It is entirely for the implementation to determine whether it recognizes a particular collation URI. For example, if the implementation allows collation URIs to contain parameters in the query part of the URI, it is the implementation that determines whether a URI containing an unknown or invalid parameter is or is not a recognized collation URI. The fact that this situation is described as an error thus does not prevent an implementation applying a fallback collation if it chooses to do so.

The lang and case-order attributes are ignored if a collation attribute is present. But in the absence of a collation attribute, these attributes provide input to an implementation-defined algorithm to locate a suitable collation:

The lang attribute indicates that a collation suitable for a particular natural language should be used. The effective value of the attribute must either be a string in the value space of xs:language, or a zero-length string. Supplying the zero-length string has the same effect as omitting the attribute. If a language is requested that is not supported, the processor may use a fallback language identified by removing successive hyphen-separated suffixes from the supplied value until a supported language code is obtained; failing this, the processor behaves as if the lang attribute were omitted.
Note:
The fallback algorithm described above is identical to the rules in RFC4647 Basic Filtering used in BCP 47, and is specified in [RFC4647] in greater detail.
The case-order attribute indicates whether the desired collation should sort upper-case letters before lower-case or vice versa. The effective value of the attribute must be either lower-first (indicating that lower-case letters precede upper-case letters in the collating sequence) or upper-first (indicating that upper-case letters precede lower-case).
When lower-first is requested, the returned collation should have the property that when two strings differ only in the case of one or more characters, then a string in which the first differing character is lower-case should precede a string in which the corresponding character is title-case, which should in turn precede a string in which the corresponding character is upper-case. When upper-first is requested, the returned collation should have the property that when two strings differ only in the case of one or more characters, then a string in which the first differing character is upper-case should precede a string in which the corresponding character is title-case, which should in turn precede a string in which the corresponding character is lower-case.
So, for example, if lang="en", then A a B b are sorted with case-order="upper-first" and a A b B are sorted with case-order="lower-first".
As a further example, if lower-first is requested, then a sorted sequence might be “MacAndrew, macintosh, macIntosh, Macintosh, MacIntosh, macintoshes, Macintoshes, McIntosh”. If upper-first is requested, the same sequence would sort as “MacAndrew, MacIntosh, Macintosh, macIntosh, macintosh, MacIntoshes, macintoshes, McIntosh”.

If none of the collation, lang, or case-order attributes is present, the collation is chosen in an implementation-defined way. It is not required that the default collation for sorting should be the same as the default collation used when evaluating XPath expressions, as described in 5.3.1 Initializing the Static Context and 3.7.2 The default-collation Attribute.

Note:

It is usually appropriate, when sorting, to use a strong collation, that is, one that takes account of secondary differences (accents) and tertiary differences (case) between strings that are otherwise equal. A weak collation, which ignores such differences, may be more suitable when comparing strings for equality.

Useful background information on international sorting is provided in [UNICODE TR10]. The case-order attribute may be interpreted as described in section 6.6 of [UNICODE TR10].

The collation, case-order, and lang attributes are ignored when no string comparisons are performed during the sorting process; this includes the cases where (a) the sequences to be sorted are empty, (b) the sort keys are of a non-string type such as xs:integer, or (c) data-type="number" is specified. In these cases, an implementation may raise errors in the value of these attributes, but is not required to do so. As always, an implementation may issue warnings.

B Glossary (Non-Normative)

absent

A component of the context that has no value is said to be absent.

absorption

An operand usage of absorption indicates that the construct reads the subtree(s) rooted at a supplied node(s).

accumulator

An accumulator defines a series of values associated with the nodes of the tree. If an accumulator is applicable to a particular tree, then for each node in the tree, other than attribute and namespace nodes, there will be two values available, called the pre-descent and post-descent values. These two values are available via a pair of functions, accumulator-before and accumulator-after.

accumulator function

The functions accumulator-before and accumulator-after are referred to as the accumulator functions.

alias

A stylesheet can use the xsl:namespace-alias element to declare that a literal namespace URI is being used as an alias for a target namespace URI.

applicable

A template rule is applicable to one or more modes. The modes to which it is applicable are defined by the mode attribute of the xsl:template element. If the attribute is omitted, then the template rule is applicable to the default mode specified in the [xsl:]default-mode attribute of the innermost containing element that has such an attribute, which in turn defaults to the unnamed mode. If the mode attribute is present, then its value must be a non-empty whitespace-separated list of tokens, each of which defines a mode to which the template rule is applicable.

applicable static namespaces

The applicable static namespaces for an element in a stylesheet module are the fixed namespace bindings for the module if the root element of the module has a fixed-namespaces attribute, or the native namespace bindings of the element otherwise.

arity range

A function definition has an arity range, which defines the minimum and maximum number of arguments that must be supplied in a call to the function. The static context can contain multiple function definitions with the same name, provided that their arity ranges do not overlap.

atomize

The term atomization is defined in [XPath 4.0] section 2.5.3 Atomization. It is a process that takes as input a sequence of items, and returns a sequence of atomic items, in which the nodes are replaced by their typed values as defined in [XDM 4.0]. Arrays (see 22 Arrays) are atomized by atomizing their members, recursively.

attribute set

An attribute set is defined as a set of xsl:attribute-set declarations in the same package that share the same expanded QName.

attribute set invocation

An attribute set invocation is a pseudo-instruction corresponding to a single EQName appearing within an [xsl:]use-attribute-sets attribute; the effect of the pseudo-instruction is to cause the referenced attribute set to be evaluated.

attribute value template

In an attribute that is designated as an attribute value template, such as an attribute of a literal result element, an expression can be used by surrounding the expression with curly brackets ({}), following the general rules for value templates

backwards compatible behavior

An element is processed with backwards compatible behavior if its effective version is less than 4.0.

base output URI

The base output URI is a URI to be used as the base URI when resolving a relative URI reference allocated to a final result tree. If the transformation generates more than one final result tree, then typically each one will be allocated a URI relative to this base URI.

basic XSLT processor

A basic XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification with the exception of constructs explicitly associated with an optional feature.

character map

A character map allows a specific character appearing in a text or attribute node in the final result tree to be substituted by a specified string of characters during serialization.

choice operand group

For some construct kinds, one or more operand roles may be defined to form a choice operand group. This concept is used where it is known that operands are mutually exclusive (for example the then and else clauses in a conditional expression).

circularity

A circularity is said to exist if a construct such as a global variable, an attribute set, or a key, cannot be evaluated without reference to its own value. For example, if the expression or sequence constructor specifying the value of a global variableX references a global variable Y, then the value for Ymust be computed before the value of X. A circularity exists if it is impossible to do this for all global variable definitions.

climbing

Climbing: indicates that streamed nodes returned by the construct are reached by navigating the parent, ancestor[-or-self], attribute, and/or namespace axes from the node at the current streaming position.

coercion rules

The term coercion rules means the coercion rules defined in [XPath 4.0], applied unless otherwise specified with XPath 1.0 compatibility mode set to false.

collation

Facilities in XSLT 3.0 and XPath 3.0 that require strings to be ordered rely on the concept of a named collation. A collation is a set of rules that determine whether two strings are equal, and if not, which of them is to be sorted before the other.

combined merge key value

The ordered collection of merge key values computed for one item in a merge input sequence (one for each merge key component within the merge key specification) is referred to as a combined merge key value.

combined posture

The combined posture of a choice operand group is determined by the postures of the operands in the group (the operand postures), and is the first of the following that applies:

If any of the operand postures is roaming, then the combined posture is roaming.
If all of the operand postures are grounded, then the combined posture is grounded.
If one or more of the operand postures is climbing and the remainder (if any) are grounded, then the combined posture is climbing.
If one or more of the operand postures is striding and the remainder (if any) are grounded, then the combined posture is striding.
If one or more of the operand postures is crawling and each of the remainder (if any) is either striding or grounded, then the combined posture is crawling.
Otherwise (for example, if the group includes both an operand with climbing posture and one with crawling posture), the combined posture is roaming.

compatible

The signatures of two components are compatible if they present the same interface to the user of the component. The additional rules depend on the kind of component.

component

The term component is used to refer to any of the following: a stylesheet function, a named template, a mode, an accumulator, an attribute set, a key, global variable, or a mode.

construct

The term construct refers to the union of the following: a sequence constructor, an instruction, an attribute set, a value template, an expression, or a pattern.

consuming

A consuming construct is any construct deemed consuming by the rules in this section (19 Streamability).

containing package

A component declaration results in multiple components, one in the package in which the declaration appears, and potentially one in each package that uses the declaring package, directly or indirectly, subject to the visibility of the component. Each of these multiple components has the same declaring package, but each has a different containing package. For the original component, the declaring package and the containing package are the same; for a copy of a component made as a result of an xsl:use-package declaration, the declaring package will be the original package, and the containing package will be the package in which the xsl:use-package declaration appears.

context item

The context item is the item currently being processed. An item (see [XDM 4.0]) is either an atomic item (such as an integer, date, or string), a node, or a function item. It changes whenever instructions such as xsl:apply-templates and xsl:for-each are used to process a sequence of items; each item in such a sequence becomes the context item while that item is being processed.

context item type

For every expression, it is possible to establish by static analysis, information about the item type of the context item for evaluation of that expression. This is called the context item type of the expression.

context node

If the context item is a node (as distinct from an atomic item such as an integer), then it is also referred to as the context node. The context node is not an independent variable, it changes whenever the context item changes. When the context item is an atomic item or a function item, there is no context node.

context position

The context position is the position of the context item within the sequence of items currently being processed. It changes whenever the context item changes. When an instruction such as xsl:apply-templates or xsl:for-each is used to process a sequence of items, the first item in the sequence is processed with a context position of 1, the second item with a context position of 2, and so on.

context posture

The context posture. This captures information about how the context item used as input to the construct is positioned relative to the streamed input. The context posture of a construct C is the posture of the expression whose value sets the focus for the evaluation of C.

context size

The context size is the number of items in the sequence of items currently being processed. It changes whenever instructions such as xsl:apply-templates and xsl:for-each are used to process a sequence of items; during the processing of each one of those items, the context size is set to the count of the number of items in the sequence (or equivalently, the position of the last item in the sequence).

controlled operand

Within a focus-changing construct there are one or more operands that are evaluated with a focus determined by the controlling operand (or in some cases such as xsl:on-completion, with an absent focus); these are referred to as controlled operands.

controlling operand

Within a focus-changing construct there is in many cases one operand whose value determines the focus for evaluating other operands; this is referred to as the controlling operand.

crawling

Crawling: typically indicates that streamed nodes returned by a construct are reached by navigating the descendant[-or-self] axis.

current captured groups

While the xsl:matching-substring instruction is active, a set of current captured groups is available, corresponding to the capturing subexpressions of the regular expression.

current group

The current group is the group itself, as a sequence of items

current grouping key

The current grouping key is a single atomic item, or in the case of a composite key, a sequence of atomic items, containing the grouping key of the items in the current group.

current merge group

The current merge group is a map. During evaluation of an xsl:merge instruction, as each group of items with equal combined merge key values is processed, the current merge group is set to a map whose keys are the names of the various merge sources, and whose associated values are the items from each merge source having the relevant composite merge key value.

current merge key

The current merge key is a an array, whose members are sequences of atomic items. There is one member in the array for each xsl:merge-key element in the merge key specification. During evaluation of an xsl:merge instruction, as each group of items with equal combined merge key values is processed, the current merge key is set to the combined merge key value that these items have in common.

current mode

At any point in the processing of a stylesheet, there is a current mode. When the transformation is initiated, the current mode is the initial mode, as described in 2.3 Initiating a Transformation. Whenever an xsl:apply-templates instruction is evaluated, the current mode becomes the mode selected by this instruction.

current output URI

The current output URI is the URI associated with the principal result or secondary result that is currently being written.

current template rule

At any point in the processing of a stylesheet, there may be a current template rule. Whenever a template rule is chosen as a result of evaluating xsl:apply-templates, xsl:apply-imports, or xsl:next-match, the template rule becomes the current template rule for the evaluation of the rule’s sequence constructor.

decimal format

All the xsl:decimal-format declarations in a package that share the same name are grouped into a named decimal format; those that have no name are grouped into a single unnamed decimal format.

declaration

Top-level elements fall into two categories: declarations, and user-defined data elements. Top-level elements whose names are in the XSLT namespace are declarations. Top-level elements in any other namespace are user-defined data elements (see 3.7.4 User-defined Data Elements)

declaration order

The declarations within a stylesheet level have a total ordering known as declaration order. The order of declarations within a stylesheet level is the same as the document order that would result if each stylesheet module were inserted textually in place of the xsl:include element that references it.

declared-streamable

The above constructs (template rules belonging to a mode declared with streamable="yes"; and xsl:source-document, xsl:attribute-set, xsl:function, xsl:merge-source, and xsl:accumulator elements specifying streamable="yes") are said to be declared-streamable.

declaring package

The declaring package of a component is the package that contains the declaration (or, in the case of xsl:attribute-set and xsl:key, multiple declarations) of the component.

default collation

In this specification the term default collation means the collation that is used by XPath operators such as eq and lt appearing in XPath expressions within the stylesheet.

default mode

The [xsl:]default-mode attribute defines the default mode, which is used as the default value for the mode attribute of all xsl:template and xsl:apply-templates elements within its scope.

default priority

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.

defining element

A string in the form of a lexical QName may occur as the value of an attribute node in a stylesheet module, or within an XPath expression contained in an attribute or text node within a stylesheet module, or as the result of evaluating an XPath expression contained in such a node. The element containing this attribute or text node is referred to as the defining element of the lexical QName.

deprecated

Some constructs defined in this specification are described as being deprecated. The use of this term implies that stylesheet authors should not use the construct, and that the construct may be removed in a later version of this specification.

dynamic error

An error that is not capable of detection until a source document is being transformed is referred to as a dynamic error.

dynamic evaluation feature

A processor that claims conformance with the dynamic evaluation featuremust evaluate the xsl:evaluate function as described in this specification.

eclipsed

An xsl:function declaration F is said to be eclipsed if the containing package includes an xsl:function declaration G such that F and G have the same name, F has lower import precedence than G, and the arity range of G includes the totality of the arity range of F.

effective value

The effective value of an attribute or text node in the stylesheet is the value after any required expansion or normalization.

effective version

The effective version of an element in a stylesheet module or package manifest is the decimal value of the [xsl:]version attribute (see 3.4 Standard Attributes) on that element or on the innermost ancestor element that has such an attribute, subject to special rules for the xsl:output and xsl:fallback elements.

embedded stylesheet module

A stylesheet module whose outermost element is the child of a non-XSLT element in a host document is referred to as an embedded stylesheet module. See 3.12 Embedded Stylesheet Modules.

enclosing mode

A mode declared by an xsl:mode declaration that has one or more contained xsl:template declarations is referred to as an enclosing mode.

EQName

An EQName is a string representing an expanded QName where the string, after removing leading and trailing whitespace, is in the form defined by the EQName^XP production in the XPath specification.

expanded QName

An expanded QName is a value in the value space of the xs:QName datatype as defined in the XDM data model (see [XDM 4.0]): that is, a triple containing namespace prefix (optional), namespace URI (optional), and local name. Two expanded QNames are equal if the namespace URIs are the same (or both absent) and the local names are the same. The prefix plays no part in the comparison, but is used only if the expanded QName needs to be converted back to a string.

explicit default

An explicit default for a parameter is indicated by the presence of either a select attribute or a non-empty sequence constructor.

explicitly mandatory

A parameter is explicitly mandatory if it is a function parameterwith no required attribute, or if the required attribute is present and has the value yes.

expression

Within this specification, the term XPath expression, or simply expression, means a string that matches the production Expr^XP defined in [XPath 4.0].

extension attribute

An element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded QName (see [XPath 4.0]) of the attribute has a non-null namespace URI. These attributes are referred to as extension attributes.

extension function

An extension function is a named function introduced to the static or dynamic context by mechanisms outside the scope of this specification.

extension instruction

An extension instruction is an element within a sequence constructor that is in a namespace (not the XSLT namespace) designated as an extension namespace.

extension namespace

The extension instruction mechanism allows namespaces to be designated as extension namespaces. When a namespace is designated as an extension namespace and an element with a name from that namespace occurs in a sequence constructor, then the element is treated as an instruction rather than as a literal result element.

final output state

The first of the two output states is called final output state. This state applies when instructions are writing to a final result tree.

final result tree

A final result tree is a result tree that forms part of the output of a transformation: specifically, a tree built by post-processing the items in the principal result or in a secondary result. Once created, the contents of a final result tree are not accessible within the stylesheet itself.

fixed namespace bindings

The fixed namespace bindings for a stylesheet module are established using the fixed-namespaces attribute on the xsl:stylesheet, xsl:transform, or xsl:package element enclosing the stylesheet module.

focus

When a sequence constructor is evaluated, the processor keeps track of which items are being processed by means of a set of implicit variables referred to collectively as the focus.

focus-changing construct

A focus-changing construct is a construct that has one or more operands that are evaluated with a different focus from the parent construct.

focus-setting container

The focus-setting container of a construct C is the innermost focus-changing constructF (if one exists) such that C is directly or indirectly contained in a controlled operand of F. If there is no such construct F, then the focus-setting container is the containing declaration, for example an xsl:function or xsl:template element.

forwards compatible behavior

An element is processed with forwards compatible behavior if its effective version is greater than 4.0.

free-ranging

A free-ranging construct is any construct deemed free-ranging by the rules in this section (19 Streamability).

function definition

The term function definition is defined in [XPath 4.0] section 2.2.1 Static Context. It is the definition of a function that can be called statically from within an XPath expression: in the case of XSLT it typically means either a stylesheet function, or a built-in function such as those defined in [Functions and Operators 4.0]

function parameter

An xsl:param element may appear as a child of an xsl:function element, before any non-xsl:param children of that element. Such a parameter is known as a function parameter. A function parameter is a local variable with the additional property that its value can be set when the function is called, using a function call in an XPath expression.

fundamental item type

There are 28 fundamental item types: the 7 node kinds defined in [XDM 4.0] (element, attribute, etc.), the 19 primitive atomic types defined in [XML Schema Part 2], plus the types fn(*) and xs:untypedAtomic. The fundamental item types are disjoint, and every item is an instance of exactly one of them.

general streamability rules

Many constructs share the same streamability rules. These rules, referred to as the general streamability rules, are defined here.

global context item

An item that is the global context item for the transformation acts as the context item when evaluating the select expression or sequence constructor of a global variablewhose declaration is within the top-level package, as described in 5.3.3.1 Maintaining Position: the Focus. The global context item may also be available in a named template when the stylesheet is invoked as described in 2.3.4 Call-Template Invocation

global variable

A top-level variable-binding element declares a global variable that is visible everywhere except within any region where it is shadowed by another variable binding.

grounded

Grounded: indicates that the value returned by the construct does not contain nodes from the streamed input document

group

The xsl:for-each-group instruction allocates the items in an input sequence into groups of items (that is, it establishes a collection of sequences) based either on common values of a grouping key, or on a pattern that the initial or final item in a group must match.

grouping key

If either of the group-by or group-adjacent attributes is present, then for each item in the population a set of grouping keys is calculated, as follows: the expression contained in the group-by or group-adjacent attribute is evaluated; the result is atomized; and any xs:untypedAtomic items are cast to xs:string. If composite="yes" is specified, there is a single grouping key whose value is the resulting sequence; otherwise, there is a set of grouping keys, consisting of the distinct atomic items present in the result sequence.

guaranteed-streamable

A guaranteed-streamable construct is a construct that is declared to be streamable and that follows the particular rules for that construct to make streaming possible, as defined by the analysis in this specification.

higher-order operand

Whether or not the operand is higher-order. For this purpose an operand O of a construct C is higher-order if the semantics of C potentially require O to be evaluated more than once during a single evaluation of C.

high priority package location

A xsl:package-location without the attribute is-priority, or with is-priority set to true is a high priority package location.

homonymous

Two components are said to be homonymous if they have the same symbolic identifier.

identical (types)

Types S and T are considered identical for the purpose of these rules if and only if subtype(S, T) and subtype(T, S) both hold, where the subtype relation is defined in [XPath 4.0] section 3.3.1 Subtypes of Sequence Types.

immediate result

The result of evaluating a sequence constructor is the sequence of items formed by concatenating the results of evaluating each of the nodes in the sequence constructor, retaining order. This is referred to as the immediate result of the sequence constructor.

implementation

A specific product that performs the functions of an XSLT processor is referred to as an implementation.

implementation-defined

In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation must be described in documentation that accompanies any conformance claim.

implementation-dependent

The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior.

implicit default

If a parameter that is not explicitly mandatory has no explicit default value, then it has an implicit default value, which is the empty sequence if there is an as attribute, or a zero-length string if not.

implicitly mandatory

If a parameter has an implicit default value which cannot be converted to the required type (that is, if it has an as attribute which does not permit the empty sequence), then the parameter is implicitly mandatory.

import precedence

A declarationD in the stylesheet is defined to have lower import precedence than another declaration E if the stylesheet level containing D would be visited before the stylesheet level containing E in a post-order traversal of the import tree (that is, a traversal of the import tree in which a stylesheet level is visited after its children). Two declarations within the same stylesheet level have the same import precedence.

import tree

The stylesheet levels making up a stylesheet are treated as forming an import tree. In the import tree, each stylesheet level has one child for each xsl:import declaration that it contains.

initial function

A stylesheet may be evaluated by calling a named stylesheet function, referred to as the initial function.

initial item

For each group, the item within the group that is first in population order is known as the initial item of the group.

initial match selection

A stylesheet may be evaluated by supplying a value to be processed, together with an initial mode. The value (which can be any sequence of items) is referred to as the initial match selection. The processing then corresponds to the effect of the xsl:apply-templates instruction.

initial mode

The initial mode is the mode used to select template rules for processing items in the initial match selection when apply-templates invocation is used to initiate a transformation.

initial named template

A stylesheet may be evaluated by selecting a named template to be evaluated; this is referred to as the initial named template.

initial sequence

The sequence to be sorted is referred to as the initial sequence.

initial setting

The initial setting of a component of the dynamic context is used when evaluating global variables and stylesheet parameters, when evaluating the use and match attributes of xsl:key, and when evaluating the initial-value of xsl:accumulator and the select expressions or contained sequence constructors of xsl:accumulator-rule

in-scope schema component

The schema components that may be referenced by name in a package are referred to as the in-scope schema components.

inspection

An operand usage of inspection indicates that the construct accesses properties of a supplied node that are available without reading its subtree.

instruction

An instruction is either an XSLT instruction or an extension instruction.

invocation construct

The following constructs are classified as invocation constructs: the instructions xsl:call-template, xsl:apply-templates, xsl:apply-imports, and xsl:next-match; XPath function calls that bind to stylesheet functions; XPath dynamic function calls; the functions accumulator-before and accumulator-after; the [xsl:]use-attribute-sets attribute. These all have the characteristic that they can cause evaluation of constructs that are not lexically contained within the calling construct.

JNode Pattern

A JNode Pattern matches a JNode by specifying constraints on the values of its ·selector· and/or ·content· properties.

key

A key is defined as a set of xsl:key declarations in the same package that share the same name.

key specifier

The expression in the use attribute and the sequence constructor within an xsl:key declaration are referred to collectively as the key specifier. The key specifier determines the values that may be used to find a node using this key.

lexical QName

A lexical QName is a string representing an expanded QName where the string, after removing leading and trailing whitespace, is within the lexical space of the xs:QName datatype as defined in XML Schema (see [XML Schema Part 2]): that is, a local name optionally preceded by a namespace prefix and a colon.

library package

Every package within a stylesheet, other than the top-level package, is referred to as a library package.

literal namespace URI

A namespace URI in the stylesheet tree that is being used to specify a namespace URI in the result tree is called a literal namespace URI.

literal result element

In a sequence constructor, an element in the stylesheet that does not belong to the XSLT namespace and that is not an extension instruction (see 24.2 Extension Instructions) is classified as a literal result element.

local variable

As well as being allowed as a declaration, the xsl:variable element is also allowed in sequence constructors. Such a variable is known as a local variable.

low priority package location

A xsl:package-location with is-priority set to false is a low priority package location.

match type

The match type of a pattern is the most specific U-type that is known to match all items that the pattern can match.

merge activation

A merge activation is a single evaluation of the sequence constructor contained within the xsl:merge-action element, which occurs once for each distinct combined merge key value.

merge input sequence

A merge input sequence is an arbitrary sequence^DM of items which is already sorted according to the merge key specification for the corresponding merge source definition.

merge key component

A merge key component specifies one component of a merge key specification; it corresponds to a single xsl:merge-key element in the stylesheet.

merge key specification

A merge key specification consists of one or more adjacent xsl:merge-key elements which together define how the merge input sequences selected by a merge source definition are sorted. Each xsl:merge-key element defines one merge key component.

merge key value

For each item in a merge input sequence, a value is computed for each merge key component within the merge key specification. The value computed for an item by using the Nth merge key component is referred to as the Nth merge key value of that item.

merge source definition

A merge source definition is the definition of one kind of input to the merge operation. It selects zero or more merge input sequences, and it includes a merge key specification to define how the merge key values are computed for each such merge input sequence.

mode

A mode is a set of template rules; when the xsl:apply-templates instruction selects a set of items for processing, it identifies the rules to be used for processing those items by nominating a mode, explicitly or implicitly.

mode definition

All the xsl:mode declarations in a package that share the same name are grouped into a named mode definition; those that have no name are grouped into a single unnamed mode definition.

motionless

A motionless construct is any construct deemed motionless by the rules in this section (19 Streamability).

named template

Templates can be invoked by name. An xsl:template element with a name attribute defines a named template.

namespace fixup

The rules for the individual XSLT instructions that construct a result tree (see 11 Creating Nodes) prescribe some of the situations in which namespace nodes are written to the tree. These rules, however, are not sufficient to ensure that the prescribed constraints are always satisfied. The XSLT processor must therefore add additional namespace nodes to satisfy these constraints. This process is referred to as namespace fixup.

native namespace bindings

The native namespace bindings for any element in an XSLT stylesheet module are the prefix-uri mappings defined by the namespace nodes of that element, according to the rules in [XDM 4.0].

navigation

An operand usage of navigation indicates that the construct may navigate freely from the supplied node to other nodes in the same tree, in a way that is not constrained by the streamability rules.

non-contextual function call

The term non-contextual function call is used to refer to function calls that do not pass the dynamic context to the called function. This includes all calls on stylesheet functions and all dynamic function calls^XP, (that is calls to function items). It excludes calls to some functions in the namespace http://www.w3.org/2005/xpath-functions, in particular those that explicitly depend on the context, such as the current-group and regex-group functions. It is implementation-defined whether, and under what circumstances, calls to extension functions are non-contextual.

non-positional predicate

A predicate is a non-positional predicate if it satisfies both of the following conditions:

The predicate does not contain a function call or named function reference to any of the following functions, unless that call or reference occurs within a nested predicate:
Note:
The exception for nested predicates is there to ensure that patterns such as match="p[@code = $status[last()]] are not disqualified.
The expression immediately contained in the predicate is a non-numeric expression. An expression is non-numeric if the intersection of its static type (see 19.1 Determining the Static Type of a Construct) with U{xs:decimal, xs:double, xs:float} is U{}.

non-schema-aware processor

A non-schema-aware processor is a processor that does not claim conformance with the schema-aware conformance feature. Such a processor must handle constructs associated with schema-aware processing as described in this section.

operand

In an actual instance of a construct, there will be a number of operands. Each operand is itself a construct; the construct tree can be defined as the transitive relation between constructs and their operands.

operand role

For every construct kind, there is a set of zero or more operand roles.

operand usage

The operand usage. This gives information, in the case where the operand value contains nodes, about how those nodes are used. The operand usage takes one of the values absorption, inspection, transmission, or navigation.

order of first appearance

There is a total ordering among groups referred to as the order of first appearance. A group G is defined to precede a group H in order of first appearance if the initial item of G precedes the initial item of H in population order. If two groups G and H have the same initial item (because the item is in both groups) then G precedes H if the grouping key of G precedes the grouping key of H in the sequence that results from evaluating the group-by expression of this initial item.

output definition

All the xsl:output declarations within a package that share the same name are grouped into a named output definition; those that have no name are grouped into a single unnamed output definition.

output state

Each instruction in the stylesheet is evaluated in one of two possible output states: final output state or temporary output state.

override

A component in a using package may override a component in a used package, provided that the visibility of the component in the used package is either abstract or public. The overriding declaration is written as a child of the xsl:override element, which in turn appears as a child of xsl:use-package.

package

An explicit package is represented by an xsl:package element, which will generally be the outermost element of an XML document. When the xsl:package element is not used explicitly, the entire stylesheet comprises a single implicit package.

package manifest

The content of the xsl:package element is referred to as the package manifest

parameter

The xsl:param element declares a parameter, which may be a stylesheet parameter, a template parameter, a function parameter, or an xsl:iterate parameter. A parameter is a variable with the additional property that its value can be set by the caller.

pattern

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.

picture string

The picture string is the string supplied as the second argument of the format-number function.

place marker

The xsl:number instruction performs two tasks: firstly, determining a place marker (this is a sequence of integers, to allow for hierarchic numbering schemes such as 1.12.2 or 3(c)ii), and secondly, formatting the place marker for output as a text node in the result sequence.

population

The sequence of items to be grouped, which is referred to as the population, is determined by evaluating the XPath expression contained in the select attribute.

population order

The population is treated as a sequence; the order of items in this sequence is referred to as population order.

portion

The integer literals and the optional NamePart within the version number are referred to as the portions of the version number.

posture

The posture of the expression. This captures information about the way in which the streamed input document is positioned on return from evaluating the construct. The posture takes one of the values climbing, striding, crawling, roaming, or grounded.

potentially consuming

An operand is potentially consuming if at least one of the following conditions applies:

The operand’s adjusted sweepS′ is consuming.
The operand usage is transmission and the operand is not grounded.

predicate pattern

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.

principal result

A principal result: this can be any sequence of items (as defined in [XDM 4.0]).

principal stylesheet module

Within a package, one stylesheet module functions as the principal stylesheet module. The complete package is assembled by finding the stylesheet modules referenced directly or indirectly from the principal stylesheet module using xsl:include and xsl:import elements: see 3.11.2 Stylesheet Inclusion and 3.11.3 Stylesheet Import.

priority

The priority of a template rule is specified by the priority attribute on the xsl:template declaration. If no priority is specified explicitly for a template rule, its default priority is used, as defined in 6.3.3 Default Priority for Patterns.

priority package location

The first package location whose value of href, when resolved as described in 5.8 URI References, allows the system to find the specified resource, and its entry if the resource is an archive, is the optimal package location.

processing order

There is another total ordering among groups referred to as processing order. If group R precedes group S in processing order, then in the result sequence returned by the xsl:for-each-group instruction the items generated by processing group R will precede the items generated by processing group S.

processor

The software responsible for transforming source trees into result trees using an XSLT stylesheet is referred to as the processor. This is sometimes expanded to XSLT processor to avoid any confusion with other processors, for example an XML processor.

raw result

The result of invoking the selected component, after any required conversion to the declared result type of the component, is referred to as the raw result.

reference binding

The process of identifying the component to which a symbolic reference applies (possibly chosen from several homonymous alternatives) is called reference binding.

required type

The context within a stylesheet where an XPath expression appears may specify the required type of the expression. The required type indicates the type of the value that the expression is expected to return.

reserved namespace

The XSLT namespace, together with certain other namespaces recognized by an XSLT processor, are classified as reserved namespaces and must be used only as specified in this and related specifications.

result tree

The term result tree is used to refer to any tree constructed by instructions in the stylesheet. A result tree is either a final result tree or a temporary tree.

roaming

Roaming: indicates that the nodes returned by an expression could be anywhere in the tree, which inevitably means that the construct cannot be evaluated using streaming.

scanning expression

A RelativePathExpr is a scanning expression if and only if it is syntactically equivalent to some motionless pattern.

schema-aware XSLT processor

A schema-aware XSLT processor is an XSLT processor that implements the mandatory requirements of this specification connected with the xsl:import-schema declaration, the [xsl:]validation and [xsl:]type attributes, and the ability to handle input documents whose nodes have type annotations other than xs:untyped and xs:untypedAtomic. The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 4.0, as described in [XPath 4.0]. A requirement is mandatory unless the specification includes wording (such as the use of the words should or may) that clearly indicates that it is optional.

schema component

Type definitions and element and attribute declarations are referred to collectively as schema components.

schema instance namespace

The schema instance namespacehttp://www.w3.org/2001/XMLSchema-instance, with conventional prefix xsi, is used as defined in [XML Schema Part 1]

schema namespace

The schema namespacehttp://www.w3.org/2001/XMLSchema, with conventional prefix xs, is used as defined in [XML Schema Part 1]

secondary result

Zero or more secondary results: each secondary result can be any sequence of items (as defined in [XDM 4.0]).

sequence constructor

A sequence constructor is a sequence of zero or more sibling nodes in the stylesheet that can be evaluated to return a sequence of nodes, atomic items, and function items. The way that the resulting sequence is used depends on the containing instruction.

SequenceType

A SequenceType constrains the type and number of items in a sequence. The term is used both to denote the concept, and to refer to the syntactic form in which sequence types are expressed in the XPath grammar: specifically SequenceType^XP in [XPath 4.0].

serialization

A frequent requirement is to output a final result tree as an XML document (or in other formats such as HTML). This process is referred to as serialization.

serialization error

If a transformation has successfully produced a principal result or secondary result, it is still possible that errors may occur in serializing that result . For example, it may be impossible to serialize the result using the encoding selected by the user. Such an error is referred to as a serialization error.

serialization feature

A processor that claims conformance with the serialization featuremust support the conversion of a final result tree to a sequence of octets following the rules defined in 26 Serialization.

shadows

Within a region of the stylesheet where a binding B1 is visible, B₁ shadows another binding B₂ having the same name as B₁ if B₁ occurs at a point where B₂ is visible.

simplified stylesheet

A simplified stylesheet, which is a subtree rooted at a literal result element, as described in 3.8 Simplified Stylesheet Modules. This is first converted to a standard stylesheet module by wrapping it in an xsl:stylesheet element using the transformation described in 3.8 Simplified Stylesheet Modules.

singleton focus

A singleton focus based on an item J has the context item (and therefore the context node, if J is a node) set to J, and the context position and context size both set to 1 (one).

snapshot

A snapshot of a node N is a deep copy of N, as produced by the xsl:copy-of instruction with copy-namespaces set to yes, copy-accumulators set to yes, and validation set to preserve, with the additional property that for every ancestor of N, the copy also has a corresponding ancestor whose name, node-kind, and base URI are the same as the corresponding ancestor of N, and that has copies of the attributes, namespaces and accumulator values of the corresponding ancestor of N. But the ancestor has a type annotation of xs:anyType, has the properties nilled, is-id, and is-idref set to false, and has no children other than the child that is a copy of N or one of its ancestors.

sorted sequence

The sequence after sorting as defined by the xsl:sort elements is referred to as the sorted sequence.

sort key component

Within a sort key specification, each xsl:sort element defines one sort key component.

sort key specification

A sort key specification is a sequence of one or more adjacent xsl:sort elements which together define rules for sorting the items in an input sequence to form a sorted sequence.

sort key value

For each item in the initial sequence, a value is computed for each sort key component within the sort key specification. The value computed for an item by using the Nth sort key component is referred to as the Nth sort key value of that item.

source tree

The term source tree means any tree provided as input to the transformation. This includes the document containing the global context item if any, documents containing nodes present in the initial match selection, documents containing nodes supplied as the values of stylesheet parameters, documents obtained from the results of functions such as document, doc, and collection, documents read using the xsl:source-document instruction, and documents returned by extension functions or extension instructions. In the context of a particular XSLT instruction, the term source tree means any tree provided as input to that instruction; this may be a source tree of the transformation as a whole, or it may be a temporary tree produced during the course of the transformation.

stable

A sort key specification is said to be stable if its first xsl:sort element has no stable attribute, or has a stable attribute whose effective value is yes.

standard attributes

There are a number of standard attributes that may appear on any XSLT element: specifically default-collation, default-mode, default-validation, exclude-result-prefixes, expand-text, extension-element-prefixes, schema-role, use-when, version, and xpath-default-namespace.

standard error namespace

The standard error namespacehttp://www.w3.org/2005/xqt-errors, with conventional prefix err, is used for error codes defined in this specification and related specifications. It is also used for the names of certain predefined variables accessible within the scope of an xsl:catch element.

standard function namespace

The standard function namespacehttp://www.w3.org/2005/xpath-functions, with conventional prefix fn, is used for functions in the function library defined in [Functions and Operators 4.0] and for standard functions defined in this specification.

standard stylesheet module

A standard stylesheet module, which is a subtree rooted at an xsl:stylesheet or xsl:transform element.

static error

An error that can be detected by examining a stylesheet before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.

static expression

A static expression is an XPath expression whose value must be computed during static analysis of the stylesheet.

static parameter

A static variable declared using an xsl:param element is referred to as a static parameter.

static type

The static type of a construct is such that all values produced by evaluating the construct will conform to that type. The static type of a construct comprises a U-type and a cardinality. A cardinality is a range of integers (from min to max).

static variable

A top-level variable-binding element having the attribute static="yes" declares a static variable: that is, a global variable whose value is known during static analysis of the stylesheet.

streamability category

Stylesheet functions belong to one of a number of streamability categories: the choice of category characterizes the way in which the function handles streamed input.

streamable mode

A streamable mode is a mode that is declared in an xsl:mode declaration with the attribute streamable="yes".

streamed document

A streamed document is a source tree that is processed using streaming, that is, without constructing a complete tree of nodes in memory.

streamed node

A streamed node is a node in a streamed document.

streaming

The term streaming refers to a manner of processing in which XML documents (such as source and result documents) are not represented by a complete tree of nodes occupying memory proportional to document size, but instead are processed “on the fly” as a sequence of events, similar in concept to the stream of events notified by an XML parser to represent markup in lexical XML.

streaming feature

A processor that claims conformance with the streaming featuremust use streamed processing in cases where (a) streaming is requested (for example by using the attribute streamable="yes" on xsl:mode, or on the xsl:source-document instruction) and (b) the constructs in question are guaranteed-streamable according to this specification.

streaming parameter

The first parameter of a declared-streamable stylesheet function is referred to as a streaming parameter.

striding

Striding: indicates that the result of a construct contains a sequence of streamed nodes, in document order, that are peers in the sense that none of them is an ancestor or descendant of any other.

string value

The term string value is defined in [XDM 4.0] section 7.5.12 string-value Accessor. Every node has a string value. For example, the string value of an element is the concatenation of the string values of all its descendant text nodes.

stylesheet

A stylesheet consists of one or more packages: specifically, one top-level package and zero or more library packages.

stylesheet function

An xsl:function declaration declares the name, parameters, and implementation of a family of stylesheet functions that can be called from any XPath expression within the stylesheet (subject to visibility rules).

stylesheet level

A stylesheet level is a collection of stylesheet modules connected using xsl:include declarations: specifically, two stylesheet modules A and B are part of the same stylesheet level if one of them includes the other by means of an xsl:include declaration, or if there is a third stylesheet module C that is in the same stylesheet level as both A and B.

stylesheet module

A package consists of one or more stylesheet modules, each one forming all or part of an XML document.

stylesheet parameter

A top-level xsl:param element declares a stylesheet parameter. A stylesheet parameter is a global variable with the additional property that its value can be supplied by the caller when a transformation is initiated.

supplied value

The value of the variable is computed using the expression given in the select attribute or the contained sequence constructor, as described in 9.3 Values of Variables and Parameters. This value is referred to as the supplied value of the variable.

sweep

Every construct has a sweep, which is a measure of the extent to which the current position in the input stream moves during the evaluation of the expression. The sweep is one of: motionless, consuming, or free-ranging .

symbolic identifier

The symbolic identifier of a component is a composite name used to identify the component uniquely within a package. The symbolic identifier comprises the kind of component (stylesheet function, named template, accumulator, attribute set, global variable, key, or mode), the expanded QName of the component (namespace URI plus local name), and in the case of stylesheet functions, the upper bound of the arity range.

symbolic reference

The declaration of a component includes constructs that can be interpreted as references to other components by means of their symbolic identifiers. These constructs are generically referred to as symbolic references. Examples of constructs that give rise to symbolic references are the name attribute of xsl:call-template; the [xsl:]use-attribute-sets attribute of xsl:copy, xsl:element, and literal result elements; the explicit or implicit mode attribute of xsl:apply-templates; XPath variable references referring to global variables; XPath static function calls (including partial function applications) referring to stylesheet functions; and named function references (example: my:f#1) referring to stylesheet functions.

tail position

An instructionJ is in a tail position within a sequence constructorSC if it satisfies one of the following conditions:

J is the last instruction in SC, ignoring any xsl:fallback instructions.
J is in a tail position within the sequence constructor that forms the body of an xsl:if instruction that is itself in a tail position within SC.
J is in a tail position within the sequence constructor that forms the body of an xsl:when or xsl:otherwise branch of an xsl:chooseor xsl:switch instruction that is itself in a tail position within SC.
J is in a tail position within the sequence constructor that forms the body of an xsl:try instruction that is itself in a tail position within SC (that is, it is immediately followed by an xsl:catch element, ignoring any xsl:fallback elements).
J is in a tail position within the sequence constructor that forms the body of an xsl:catch element within an xsl:try instruction that is itself in a tail position within SC.

target expression

The string that results from evaluating the expression in the xpath attribute is referred to as the target expression.

target namespace URI

The namespace URI that is to be used in the result tree as a substitute for a literal namespace URI is called the target namespace URI.

template

An xsl:template declaration defines a template, which contains a sequence constructor; this sequence constructor is evaluated to determine the result of the template. A template can serve either as a template rule, invoked by matching items against a pattern, or as a named template, invoked explicitly by name. It is also possible for the same template to serve in both capacities.

template parameter

An xsl:param element may appear as a child of an xsl:template element, before any non-xsl:param children of that element. Such a parameter is known as a template parameter. A template parameter is a local variable with the additional property that its value can be set when the template is called, using any of the instructions xsl:call-template, xsl:apply-templates, xsl:apply-imports, or xsl:next-match.

template rule

A stylesheet contains a set of template rules (see 6 Template Rules). A template rule has three parts: a pattern that is matched against selected items (often but not necessarily nodes), a (possibly empty) set of template parameters, and a sequence constructor that is evaluated to produce a sequence of items.

temporary output state

The second of the two output states is called temporary output state. This state applies when instructions are writing to a temporary tree or any other non-final destination.

temporary tree

The term temporary tree means any tree that is neither a source tree nor a final result tree.

text value template

In a text node that is designated as a text value template, expressions can be used by surrounding each expression with curly brackets ({}).

top-level

An element occurring as a child of an xsl:package, xsl:stylesheet, xsl:transform, or xsl:override element is called a top-level element.

top-level package

For a given transformation, one package functions as the top-level package. The complete stylesheet is assembled by finding the packages referenced directly or indirectly from the top-level package using xsl:use-package declarations: see 3.5.2 Dependencies between Packages.

transmission

An operand usage of transmission indicates that the construct will (potentially) return a supplied node as part of its result to the calling construct (that is, to its parent in the construct tree).

traversal

A traversal of a tree is a sequence of traversal events.

traversal-event

a traversal event (shortened to event in this section) is a pair comprising a phase (start or end) and a node.

tree

The term tree is used (as in [XDM 4.0]) to refer to the aggregate consisting of a parentless node together with all its descendant nodes, plus all their attributes and namespaces.

tunnel parameter

A parameter passed to a template may be defined as a tunnel parameter. Tunnel parameters have the property that they are automatically passed on by the called template to any further templates that it calls, and so on recursively.

type-adjusted posture and sweep

The type-adjusted posture and sweep of a construct C, with respect to a type T, are the posture and sweep established by applying the general streamability rules to a construct D whose single operand is the construct C, where the operand usage of C in D is the type-determined usage based on the required type T.

type annotation

The term type annotation is used in this specification to refer to the value returned by the dm:type-name accessor of a node: see [XDM 4.0] section 7.5.13 type-name Accessor.

type-determined usage

The type-determined usage of an operand is as follows: if the required type (ignoring occurrence indicator) is fn(*) or a subtype thereof, then inspection; if the required type (ignoring occurrence indicator) is an atomic or union type, then absorption; otherwise navigation.

typed value

The term typed value is defined in [XDM 4.0] section 7.5.14 typed-value Accessor. Every node, other than an element whose type annotation identifies it as having element-only content, has a typed value. For example, the typed value of an attribute of type xs:IDREFS is a sequence of zero or more xs:IDREF values.

type error

Certain errors are classified as type errors. A type error occurs when the value supplied as input to an operation is of the wrong type for that operation, for example when an integer is supplied to an operation that expects a node.

type pattern

A type pattern can be written as type(T) (where T is an ItemType^XP 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.

unnamed mode

The unnamed mode is the default mode used when no mode attribute is specified on an xsl:apply-templates instruction or xsl:template declaration, unless a different default mode has been specified using the [xsl:]default-mode attribute of a containing element.

URI Reference

Within this specification, the term URI Reference, unless otherwise stated, refers to a string in the lexical space of the xs:anyURI datatype as defined in [XML Schema Part 2].

use

If a package Q contains an xsl:use-package element that references package P, then package Q is said to use package P. In this relationship package Q is referred to as the using package, package P as the used package.

user-defined data element

In addition to declarations, the xsl:stylesheet element may contain among its children any element not from the XSLT namespace, provided that the expanded QName of the element has a non-null namespace URI. Such elements are referred to as user-defined data elements.

U-type

A U-type is a set of fundamental item types.

vacuous

An item is vacuous if it is one of the following: a zero-length text node; a document node with no children; an atomic item which, on casting to xs:string, produces a zero-length string; or an array which on flattening using the array:flatten function produces either an empty sequence or a sequence consisting entirely of vacuous items.

value

A variable is a binding between a name and a value. The value of a variable is any sequence (of nodes, atomic items, and/or function items), as defined in [XDM 4.0].

value template

Collectively, attribute value templates and text value templates are referred to as value templates.

variable

The xsl:variable element declares a variable, which may be a global variable or a local variable.

variable-binding element

The two elements xsl:variable and xsl:param are referred to as variable-binding elements.

visibility

The visibility of a component is one of: private, public, abstract, final, or hidden.

whitespace text node

A whitespace text node is a text node whose content consists entirely of whitespace characters (that is, U+0009 (TAB) , U+000A (NEWLINE) , U+000D (CARRIAGE RETURN) , or U+0020 (SPACE) ).

XML namespace

The XML namespace, defined in [Namespaces in XML] as http://www.w3.org/XML/1998/namespace, is used for attributes such as xml:lang, xml:space, and xml:id.

XNode pattern

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.

XPath 1.0 compatibility mode

The term XPath 1.0 compatibility mode is defined in [XPath 4.0] section 2.2.1 Static Context. This is a setting in the static context of an XPath expression; it has two values, true and false. When the value is set to true, the semantics of function calls and certain other operations are adjusted to give a greater degree of backwards compatibility between XPath 4.0 and XPath 1.0.

XSLT 1.0 behavior

An element in the stylesheet is processed with XSLT 1.0 behavior if its effective version is equal to 1.0.

XSLT 1.0 compatibility feature

A processor that claims conformance with the XSLT 1.0 compatibility featuremust support the processing of stylesheet instructions and XPath expressions with XSLT 1.0 behavior, as defined in 3.9 Backwards Compatible Processing.

XSLT 2.0 behavior

An element is processed with XSLT 2.0 behavior if its effective version is equal to 2.0.

XSLT 3.0 behavior

An element is processed with XSLT 3.0 behavior if its effective version is equal to 3.0.

XSLT element

An XSLT element is an element in the XSLT namespace whose syntax and semantics are defined in this specification.

XSLT instruction

An XSLT instruction is an XSLT element whose syntax summary in this specification contains the annotation .

XSLT namespace

The XSLT namespace has the URI http://www.w3.org/1999/XSL/Transform. It is used to identify elements, attributes, and other names that have a special meaning defined in this specification.

E Pattern Syntax Summary (Non-Normative)

This appendix gives the grammar for XSLT patterns. The top-level rule for patterns is Pattern.

This is an extension of the grammar for XPath expressions. The extended BNF notation is explained at [XPath 4.0] section A.1.1 Notation.

Productions that are identical to their counterparts in XPath 4.0 are suffixed XP and link to the corresponding production in the XPath 4.0 specification. Productions whose names end with P are restrictions of the corresponding XPath production: for example, ArgumentListP is a restricted form of the XPath production ArgumentList.

`AbbrevForwardStepP`	::=	`("@" NodeTest^XP) \| SimpleNodeTest^XP`
`AbbreviatedStep`	::=	`".." \| ("@" NodeTest^XP) \| SimpleNodeTest^XP`
`AbsolutePathExpr`	::=	`("/" RelativePathExpr^XP?) \| ("//" RelativePathExpr^XP)`
`AdditiveExpr`	::=	`MultiplicativeExpr^XP (("+" \| "-") MultiplicativeExpr^XP)*`
`AndExpr`	::=	`ComparisonExpr^XP ("and" ComparisonExpr^XP)*`
`AnyArrayType`	::=	`"array" "(" "*" ")"`
`AnyFunctionType`	::=	`("function" \| "fn") "(" "*" ")"`
`AnyItemTest`	::=	`"item" "(" ")"`
`AnyMapType`	::=	`"map" "(" "*" ")"`
`AnyNodeKindTest`	::=	`"node" "(" ")"`
`AnyRecordType`	::=	`"record" "(" "*" ")"`
`Argument`	::=	`ExprSingle^XP \| ArgumentPlaceholder^XP`
`ArgumentList`	::=	`"(" ((PositionalArguments^XP ("," KeywordArguments^XP)?) \| KeywordArguments^XP)? ")"`
`ArgumentListP`	::=	`"(" (ArgumentP ** ",") ")"`
`ArgumentP`	::=	`VarRef^XP \| Literal^XP`
`ArgumentPlaceholder`	::=	`"?"`
`ArrayConstructor`	::=	`SquareArrayConstructor^XP \| CurlyArrayConstructor^XP`
`ArrayType`	::=	`AnyArrayType^XP \| TypedArrayType^XP`
`ArrowExpr`	::=	`UnaryExpr^XP (SequenceArrowTarget^XP \| MappingArrowTarget^XP)*`
`ArrowTarget`	::=	`FunctionCall^XP \| RestrictedDynamicCall^XP`
`AttributeName`	::=	`EQName^XP`
`AttributeTest`	::=	`"attribute" "(" (NameTestUnion^XP ("," TypeName^XP)?)? ")"`
`Axis`	::=	`("ancestor" \| "ancestor-or-self" \| "attribute" \| "child" \| "descendant" \| "descendant-or-self" \| "following" \| "following-or-self" \| "following-sibling" \| "following-sibling-or-self" \| "namespace" \| "parent" \| "preceding" \| "preceding-or-self" \| "preceding-sibling" \| "preceding-sibling-or-self" \| "self") "::"`
`AxisStep`	::=	`(AbbreviatedStep^XP \| FullStep^XP) Predicate^XP*`
`AxisStepP`	::=	`ForwardStepPPredicate^XP*`
`BracedAction`	::=	`EnclosedExpr^XP`
`CastableExpr`	::=	`CastExpr^XP ("castable" "as" CastTarget^XP "?"?)?`
`CastExpr`	::=	`PipelineExpr^XP ("cast" "as" CastTarget^XP "?"?)?`
`CastTarget`	::=	`TypeName^XP`
`ChoiceItemType`	::=	`"(" (ItemType^XP ++ "\|") ")"`
`CommentTest`	::=	`"comment" "(" ")"`
`ComparisonExpr`	::=	`OtherwiseExpr^XP ((ValueComp^XP \| GeneralComp^XP \| NodeComp^XP) OtherwiseExpr^XP)?`
`Constant`	::=	`StringLiteral^XP \| ("-"? NumericLiteral^XP) \| QNameLiteral^XP \| ("true" "(" ")") \| ("false" "(" ")")`
`ContextValueRef`	::=	`"."`
`CurlyArrayConstructor`	::=	`"array" EnclosedExpr^XP`
`DocumentTest`	::=	`"document-node" "(" (ElementTest^XP \| SchemaElementTest^XP \| NameTestUnion^XP)? ")"`
`DynamicFunctionCall`	::=	`PostfixExpr^XPPositionalArgumentList^XP`
`ElementName`	::=	`EQName^XP`
`ElementTest`	::=	`"element" "(" (NameTestUnion^XP ("," TypeName^XP "?"?)?)? ")"`
`EnclosedExpr`	::=	`"{" Expr^XP? "}"`
`EnumerationType`	::=	`"enum" "(" (StringLiteral^XP ++ ",") ")"`
`EQName`	::=	`QName \| URIQualifiedName^XP`
`Expr`	::=	`(ExprSingle^XP ++ ",")`
`ExprSingle`	::=	`ForExpr^XP \| LetExpr^XP \| QuantifiedExpr^XP \| IfExpr^XP`
`ExtensibleFlag`	::=	`"," "*"`
`FieldDeclaration`	::=	`FieldName^XP "?"? ("as" SequenceType^XP)?`
`FieldName`	::=	`NCName^XP \| StringLiteral^XP`
`FilterExpr`	::=	`PostfixExpr^XPPredicate^XP`
`FilterExprAM`	::=	`PostfixExpr^XP "?[" Expr^XP "]"`
`ForBinding`	::=	`ForItemBinding^XP \| ForMemberBinding^XP \| ForEntryBinding^XP`
`ForClause`	::=	`"for" (ForBinding^XP ++ ",")`
`ForEntryBinding`	::=	`((ForEntryKeyBinding^XPForEntryValueBinding^XP?) \| ForEntryValueBinding^XP) PositionalVar^XP? "in" ExprSingle^XP`
`ForEntryKeyBinding`	::=	`"key" VarNameAndType^XP`
`ForEntryValueBinding`	::=	`"value" VarNameAndType^XP`
`ForExpr`	::=	`ForClause^XPForLetReturn^XP`
`ForItemBinding`	::=	`VarNameAndType^XPPositionalVar^XP? "in" ExprSingle^XP`
`ForLetReturn`	::=	`ForExpr^XP \| LetExpr^XP \| ("return" ExprSingle^XP)`
`ForMemberBinding`	::=	`"member" VarNameAndType^XPPositionalVar^XP? "in" ExprSingle^XP`
`ForwardAxisP`	::=	`("child" "::") \| ("descendant" "::") \| ("attribute" "::") \| ("self" "::") \| ("descendant-or-self" "::") \| ("namespace" "::")`
`ForwardStepP`	::=	`(ForwardAxisPNodeTest^XP) \| AbbrevForwardStepP`
`FullStep`	::=	`Axis^XPNodeTest^XP`
`FunctionBody`	::=	`EnclosedExpr^XP`
`FunctionCall`	::=	`EQName^XPArgumentList^XP`
		/* xgs: reserved-function-names */
		/* gn: parens */
`FunctionCallP`	::=	`OuterFunctionNameArgumentListP`
`FunctionItemExpr`	::=	`NamedFunctionRef^XP \| InlineFunctionExpr^XP`
`FunctionSignature`	::=	`"(" ParamList^XP ")" TypeDeclaration^XP?`
`FunctionType`	::=	`AnyFunctionType^XP \| TypedFunctionType^XP`
`GeneralComp`	::=	`"=" \| "!=" \| "<" \| "<=" \| ">" \| ">="`
`GNodeType`	::=	`"gnode" "(" ")"`
`IfExpr`	::=	`"if" "(" Expr^XP ")" (UnbracedActions^XP \| BracedAction^XP)`
`InlineFunctionExpr`	::=	`MethodAnnotation^XP* ("function" \| "fn") FunctionSignature^XP? FunctionBody^XP`
`InstanceofExpr`	::=	`TreatExpr^XP ("instance" "of" SequenceType^XP)?`
`IntersectExceptExpr`	::=	`InstanceofExpr^XP (("intersect" \| "except") InstanceofExpr^XP)*`
`IntersectExceptPattern`	::=	`PrimaryPattern (("intersect" \| "except") PrimaryPattern)*`
`ItemType`	::=	`RegularItemType^XP \| FunctionType^XP \| TypeName^XP \| ChoiceItemType^XP`
`JNodePattern`	::=	`"jnode" "(" JNodePatternSelector "," JNodePatternContent ")" Predicate^XP*`
`JNodePatternContent`	::=	`"*" \| SequenceType^XP`
`JNodePatternSelector`	::=	`"*" \| NCName^XP \| Constant`
`JNodeType`	::=	`"jnode" "(" SequenceType^XP? ")"`
`KeySpecifier`	::=	`NCName^XP \| Literal^XP \| ContextValueRef^XP \| VarRef^XP \| ParenthesizedExpr^XP \| LookupWildcard^XP`
`KeywordArgument`	::=	`EQName^XP ":=" Argument^XP`
`KeywordArguments`	::=	`(KeywordArgument^XP ++ ",")`
`LetArrayBinding`	::=	`"$" "[" (VarNameAndType^XP ++ ",") "]" TypeDeclaration^XP? ":=" ExprSingle^XP`
`LetBinding`	::=	`LetValueBinding^XP \| LetSequenceBinding^XP \| LetArrayBinding^XP \| LetMapBinding^XP`
`LetClause`	::=	`"let" (LetBinding^XP ++ ",")`
`LetExpr`	::=	`LetClause^XPForLetReturn^XP`
`LetMapBinding`	::=	`"$" "{" (VarNameAndType^XP ++ ",") "}" TypeDeclaration^XP? ":=" ExprSingle^XP`
`LetSequenceBinding`	::=	`"$" "(" (VarNameAndType^XP ++ ",") ")" TypeDeclaration^XP? ":=" ExprSingle^XP`
`LetValueBinding`	::=	`VarNameAndType^XP ":=" ExprSingle^XP`
`Literal`	::=	`NumericLiteral^XP \| StringLiteral^XP \| QNameLiteral^XP`
`Lookup`	::=	`"?" KeySpecifier^XP`
`LookupExpr`	::=	`PostfixExpr^XPLookup^XP`
`LookupWildcard`	::=	`"*"`
`MapConstructor`	::=	`"map"? "{" (MapConstructorEntry^XP ** ",") "}"`
`MapConstructorEntry`	::=	`ExprSingle^XP (":" ExprSingle^XP)?`
`MappingArrowTarget`	::=	`"=!>" ArrowTarget^XP`
`MapType`	::=	`AnyMapType^XP \| TypedMapType^XP`
`MethodAnnotation`	::=	`"%method"`
`MethodCall`	::=	`PostfixExpr^XP "?>" NCName^XPPositionalArgumentList^XP`
`MultiplicativeExpr`	::=	`UnionExpr^XP (("" \| "×" \| "div" \| "÷" \| "idiv" \| "mod") UnionExpr^XP)`
`NamedFunctionRef`	::=	`EQName^XP "#" IntegerLiteral`
		/* xgs: reserved-function-names */
`NamespaceNodeTest`	::=	`"namespace-node" "(" ")"`
`NameTest`	::=	`EQName^XP \| Wildcard^XP`
`NameTestUnion`	::=	`(NameTest^XP ++ "\|")`
`NodeComp`	::=	`"is" \| "is-not" \| NodePrecedes^XP \| NodeFollows^XP`
`NodeFollows`	::=	`">>" \| "follows"`
`NodeKindTest`	::=	`DocumentTest^XP \| ElementTest^XP \| AttributeTest^XP \| SchemaElementTest^XP \| SchemaAttributeTest^XP \| PITest^XP \| CommentTest^XP \| TextTest^XP \| NamespaceNodeTest^XP \| AnyNodeKindTest^XP`
`NodePrecedes`	::=	`"<<" \| "precedes"`
`NodeTest`	::=	`UnionNodeTest^XP \| SimpleNodeTest^XP`
`NumericLiteral`	::=	`IntegerLiteral \| HexIntegerLiteral \| BinaryIntegerLiteral \| DecimalLiteral \| DoubleLiteral`
`OccurrenceIndicator`	::=	`"?" \| "*" \| "+"`
		/* xgs: occurrence-indicators */
`OrExpr`	::=	`AndExpr^XP ("or" AndExpr^XP)*`
`OtherwiseExpr`	::=	`StringConcatExpr^XP ("otherwise" StringConcatExpr^XP)*`
`OuterFunctionName`	::=	`EQName^XP`
`ParamList`	::=	`(VarNameAndType^XP ** ",")`
`ParenthesizedExpr`	::=	`"(" Expr^XP? ")"`
`ParenthesizedExprP`	::=	`"(" PathExprP ")"`
`ParenthesizedExprP`	::=	`"(" PathExprP ")"`
`ParenthesizedPattern`	::=	`"(" Pattern ")"`
`PathExpr`	::=	`AbsolutePathExpr^XP \| RelativePathExpr^XP`
		/* xgs: leading-lone-slash */
`PathExprP`	::=	`RootedPath \| ("/" RelativePathExprP?) \| ("//" RelativePathExprP) \| RelativePathExprP`
		/* xgs: leading-lone-slash */
`PathPattern`	::=	`PathExprP`
`PathPattern`	::=	`PathExprP`
`Pattern`	::=	`UnionPattern`
`PipelineExpr`	::=	`ArrowExpr^XP ("->" ArrowExpr^XP)*`
`PITest`	::=	`"processing-instruction" "(" (NCName^XP \| StringLiteral^XP)? ")"`
`PositionalArgumentList`	::=	`"(" PositionalArguments^XP? ")"`
`PositionalArguments`	::=	`(Argument^XP ++ ",")`
`PositionalVar`	::=	`"at" VarName^XP`
`PostfixExpr`	::=	`PrimaryExpr^XP \| FilterExpr^XP \| DynamicFunctionCall^XP \| LookupExpr^XP \| MethodCall^XP \| FilterExprAM^XP`
`PostfixExprP`	::=	`(FunctionCallP \| ParenthesizedExprPParenthesizedPattern) Predicate^XP*`
`Predicate`	::=	`"[" Expr^XP "]"`
`PredicatePattern`	::=	`"." Predicate^XP*`
`PrimaryExpr`	::=	`Literal^XP \| VarRef^XP \| ParenthesizedExpr^XP \| ContextValueRef^XP \| FunctionCall^XP \| FunctionItemExpr^XP \| MapConstructor^XP \| ArrayConstructor^XP \| StringTemplate^XP \| UnaryLookup^XP`
`PrimaryPattern`	::=	`ParenthesizedPattern \| PredicatePattern \| TypePattern \| XNodePattern \| JNodePattern`
`QNameLiteral`	::=	`"#" EQName^XP`
`QuantifiedExpr`	::=	`("some" \| "every") (QuantifierBinding^XP ++ ",") "satisfies" ExprSingle^XP`
`QuantifierBinding`	::=	`VarNameAndType^XP "in" ExprSingle^XP`
`RangeExpr`	::=	`AdditiveExpr^XP ("to" AdditiveExpr^XP)?`
`RecordType`	::=	`AnyRecordType^XP \| TypedRecordType^XP`
`RegularItemType`	::=	`AnyItemTest^XP \| NodeKindTest^XP \| GNodeType^XP \| JNodeType^XP \| MapType^XP \| ArrayType^XP \| RecordType^XP \| EnumerationType^XP`
`RelativePathExpr`	::=	`StepExpr^XP (("/" \| "//") StepExpr^XP)*`
`RelativePathExprP`	::=	`StepExprP (("/" \| "//") StepExprP)*`
`RestrictedDynamicCall`	::=	`(VarRef^XP \| ParenthesizedExpr^XP \| FunctionItemExpr^XP \| MapConstructor^XP \| ArrayConstructor^XP) PositionalArgumentList^XP`
`RootedPath`	::=	`VarRef^XPPredicate^XP* (("/" \| "//") RelativePathExprP)?`
`SchemaAttributeTest`	::=	`"schema-attribute" "(" AttributeName^XP ")"`
`SchemaElementTest`	::=	`"schema-element" "(" ElementName^XP ")"`
`Selector`	::=	`EQName^XP \| Wildcard^XP \| ("get" "(" ExprSingle^XP ")")`
`SequenceArrowTarget`	::=	`"=>" ArrowTarget^XP`
`SequenceType`	::=	`("empty-sequence" "(" ")") \| (ItemType^XPOccurrenceIndicator^XP?)`
`SimpleMapExpr`	::=	`PathExpr^XP ("!" PathExpr^XP)*`
`SimpleNodeTest`	::=	`TypeTest^XP \| Selector^XP`
`SquareArrayConstructor`	::=	`"[" (ExprSingle^XP ** ",") "]"`
`StepExpr`	::=	`PostfixExpr^XP \| AxisStep^XP`
`StepExprP`	::=	`PostfixExprP \| AxisStepP`
`StringConcatExpr`	::=	`RangeExpr^XP ("\|\|" RangeExpr^XP)*`
`StringTemplate`	::=	"`" (StringTemplateFixedPart^XP \| StringTemplateVariablePart^XP)* "`"
		/* ws: explicit */
`StringTemplateFixedPart`	::=	((Char - ('{' \| '}' \| '`')) \| "{{" \| "}}" \| "``")+
		/* ws: explicit */
`StringTemplateVariablePart`	::=	`EnclosedExpr^XP`
`TextTest`	::=	`"text" "(" ")"`
`TreatExpr`	::=	`CastableExpr^XP ("treat" "as" SequenceType^XP)?`
`TypedArrayType`	::=	`"array" "(" SequenceType^XP ")"`
`TypeDeclaration`	::=	`"as" SequenceType^XP`
`TypedFunctionParam`	::=	`("$" EQName^XP "as")? SequenceType^XP`
`TypedFunctionType`	::=	`("function" \| "fn") "(" (TypedFunctionParam^XP ** ",") ")" "as" SequenceType^XP`
`TypedMapType`	::=	`"map" "(" ItemType^XP "," SequenceType^XP ")"`
`TypedRecordType`	::=	`"record" "(" (FieldDeclaration^XP ** ",") ExtensibleFlag^XP? ")"`
`TypeName`	::=	`EQName^XP`
`TypePattern`	::=	`(WrappedItemTest \| AnyItemTest^XP \| FunctionType^XP \| MapType^XP \| ArrayType^XP \| RecordType^XP \| EnumerationType^XP) Predicate^XP*`
`TypeTest`	::=	`RegularItemType^XP \| ("type" "(" SequenceType^XP ")")`
`UnaryExpr`	::=	`("-" \| "+")* ValueExpr^XP`
`UnaryLookup`	::=	`Lookup^XP`
`UnbracedActions`	::=	`"then" ExprSingle^XP "else" ExprSingle^XP`
`UnionExpr`	::=	`IntersectExceptExpr^XP (("union" \| "\|") IntersectExceptExpr^XP)*`
`UnionNodeTest`	::=	`"(" (SimpleNodeTest^XP ++ "\|") ")"`
`UnionPattern`	::=	`IntersectExceptPattern (("union" \| "\|") IntersectExceptPattern)*`
`ValueComp`	::=	`"eq" \| "ne" \| "lt" \| "le" \| "gt" \| "ge"`
`ValueExpr`	::=	`SimpleMapExpr^XP`
`VarName`	::=	`"$" EQName^XP`
`VarNameAndType`	::=	`"$" EQName^XPTypeDeclaration^XP?`
`VarRef`	::=	`"$" EQName^XP`
`Wildcard`	::=	`"" \| (NCName ":" "") \| ("" ":" NCName) \| (BracedURILiteral "")`
		/* ws: explicit */
`WrappedItemTest`	::=	`"type" ChoiceItemType^XP`
`XNodePattern`	::=	`PathExprP`

XSL Transformations (XSLT) Version 4.0

W3C Editor's Draft 218 February 2026

Abstract

Status of this Document

Dedication

3 Stylesheet Structure

3.7 Stylesheet Element

3.7.2 The `default-collation` Attribute

5 Features of the XSLT Language

5.1 Names

5.1.3 Reserved Namespaces

5.2 Expressions

5.3 The Static and Dynamic Context

5.3.1 Initializing the Static Context

5.7 Sequence Constructors

5.7.1 Constructing Complex Content

6 Template Rules

6.3 Patterns

6.3.1 Examples of Patterns

6.3.2 Syntax of Patterns

6.3.2.3 XNode Patterns

6.3.2.3.1 The Meaning of an XNode Pattern

9 Variables and Parameters

9.7 Static Expressions

10 Callable Components

10.3 Stylesheet Functions

10.3.7 Determinism of Functions

12 Numbering

12.2 Formatting a Supplied Number

13 Sorting

13.1 The `xsl:sort` Element

13.1.3 Sorting Using Collations

B Glossary (Non-Normative)

E Pattern Syntax Summary (Non-Normative)

XSL Transformations (XSLT) Version 4.0

W3C Editor's Draft 218 February 2026

Abstract

Status of this Document

Dedication

3 Stylesheet Structure

3.7 Stylesheet Element

3.7.2 The default-collation Attribute

5 Features of the XSLT Language

5.1 Names

5.1.3 Reserved Namespaces

5.2 Expressions

5.3 The Static and Dynamic Context

5.3.1 Initializing the Static Context

5.7 Sequence Constructors

5.7.1 Constructing Complex Content

6 Template Rules

6.3 Patterns

6.3.1 Examples of Patterns

6.3.2 Syntax of Patterns

6.3.2.3 XNode Patterns

6.3.2.3.1 The Meaning of an XNode Pattern

9 Variables and Parameters

9.7 Static Expressions

10 Callable Components

10.3 Stylesheet Functions

10.3.7 Determinism of Functions

12 Numbering

12.2 Formatting a Supplied Number

13 Sorting

13.1 The xsl:sort Element

13.1.3 Sorting Using Collations

B Glossary (Non-Normative)

E Pattern Syntax Summary (Non-Normative)

3.7.2 The `default-collation` Attribute

13.1 The `xsl:sort` Element