XSL Transformations (XSLT)
Version 2.0

1.1 Stylesheets and Transformation

This specification defines the syntax and semantics of the XSLT language. A transformation in the XSLT language is expressed in the form of a stylesheet, whose syntax is well-formed XML [XML] conforming to the Namespaces in XML Recommendation [XML Names]. A stylesheet generally includes both elements that are defined by XSLT and elements that are not defined by XSLT. XSLT-defined elements are distinguished by belonging to a specific XML namespace (http://www.w3.org/1999/XSL/Transform: see [2.1 XSLT Namespace]), which is referred to in this specification as the XSLT namespace. Thus this specification is a definition of the syntax and semantics of the XSLT namespace.

NOTE: The term stylesheet reflects the fact that one of the important roles of XSLT is to add styling information to an XML source document, by transforming it into a document consisting of XSL formatting objects, or into another presentation-oriented format such as HTML, XHTML, or SVG.

The software responsible for transforming a source document into a result document 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. A specific product that performs the functions of an XSLT processor is referred to as an implementation.

A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by a set of template rules. A template rule associates a pattern, which matches nodes in the source document, with a content constructor, which can be evaluated to produce part of the result tree. The structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, nodes from the source tree can be filtered and reordered, and arbitrary structure can be added. This mechanism allows a stylesheet to be applicable to a wide class of documents that have similar source tree structures.

NOTE: More generally, a transformation can process several source trees and produce several result trees.

A stylesheet may consist of several stylesheet modules, contained in different XML documents. One of these functions as the principal stylesheet module. The complete stylesheet is assembled by finding the stylesheet modules referenced directly or indirectly from the principal stylesheet module using xsl:include and xsl:import elements: see [2.8.1 Stylesheet Inclusion] and [2.8.2 Stylesheet Import].

1.2 Initiating a Transformation

A stylesheet can process further source documents in addition to the principal source document. These additional documents can be loaded using the functions document or collection described in [Functions and Operators], or they can be supplied as stylesheet parameters (see [6.2 Global Variables and Parameters]), or as the result of an extension function (see [16.1 Extension Functions]

NOTE: Sometimes it is useful to write an XSLT stylesheet that does not require input from a principal source document. However, the semantics of the language require that a principal source document is always present. Implementors may provide a mechanism that supplies a default document, containing just a document node with no children, as the principal source document to be used in the absence of any other source document.

1.4 Executing a Transformation

A stylesheet contains a set of template rules. A template rule has two parts: a pattern which is matched against nodes in the source tree and a content constructor which is evaluated to produce a sequence of nodes: these nodes are typically used to form part of the result tree. This allows a stylesheet to be applicable to a wide class of documents that have similar source tree structures.

A content constructor is evaluated for a particular node in the source tree, to create part of the result tree. A content constructor can contain elements (called literal result elements) and text nodes that specify part of the result structure directly. A content constructor can also contain elements from the XSLT namespace that are instructions for creating parts of the result tree.

When a content constructor is evaluated, each instruction is evaluated to produce a sequence of zero or more nodes; the result of the content constructor as a whole is a sequence of nodes formed by concatenating the results of each of the instructions and literal results nodes that it contains, in the order that they appear in the content constructor. The resulting nodes are typically attached as children to an element or document node constructed by the instruction that contains the content constructor, thus forming a tree. During this process, adjacent text nodes will be merged into a single text node. When a content constructor is evaluated to create new nodes, the tree to which these nodes are added is referred to as the current result tree. When the transformation is initiated, a result tree is created, and becomes the current result tree. This tree is referred to as the principal result tree. Various XSLT instructions, (including xsl:variable and xsl:result-document) establish a new current result tree for the nodes created by the content constructor that they contain.

The elements occurring within a content constructor are classified as being either literal result elements or instructions. If the element is in the XSLT namespace, or in a namespace designated as an extension namespace, then it is an instruction. Otherwise, it is a literal result element.

The element syntax summary notation used to describe the syntax of XSLT-defined elements is described in [20 Notation], and a full list of these elements is provided in [C Element Syntax Summary]

Instructions can select and process other nodes in a source tree. The typical way of processing a source node is to create a sequence of result nodes by finding the applicable template rule and evaluating its content constructor. Note that source nodes are processed only if they are selected by such an instruction.

Instructions that select nodes from the source document, or that derive information from these nodes for inclusion in the result document, always access the source tree by means of an Expression in the XPath language, described in [XPath 2.0]. A stylesheet written to use XSLT 2.0 will contain expressions whose syntax and semantics are defined by XPath 2.0 (but see also [2.6 Backwards-Compatible Processing] and [2.7 Forwards-Compatible Processing]).

Execution of a stylesheet against the principal source document proceeds by creating a document node for the principal result tree, finding the template rule that matches the document node of the source tree, and evaluating the content constructor of this template rule to create the children of the new document node. By the time evaluation of this content constructor is complete, these children will typically each act as the parent of further result nodes, so a complete tree is constructed.

It is also possible for the execution of a stylesheet to start at a node in the source document other than the document node, determined by the implementation-specific mechanism for invoking a stylesheet. In this situation, the complete tree remains available for processing by the stylesheet; the only difference is the choice of the node used when applying the first template rule.

In the process of finding the applicable template rule, more than one template rule may have a pattern that matches a given node. However, only one template rule will be applied. The method for deciding which template rule to apply is described in [5.4 Conflict Resolution for Template Rules].

A single content constructor by itself has considerable power. It can create structures of arbitrary complexity; it can pull string values out of arbitrary locations in the source tree; and it can generate structures that are repeated according to the occurrence of nodes in the source tree.

For simple transformations where the structure of the result tree is independent of the structure of the source tree, a stylesheet can often consist of only a single literal result element, containing a content constructor which functions as a template for building the complete result tree. Transformations on XML documents that represent data with a regular and predictable structure (for example, data extracted from a relational database) are often of this kind. XSLT allows a simplified syntax for such stylesheets (see [2.5 Simplified Stylesheet Modules]).

1.5 Maintaining Position: the Focus

When a content constructor is evaluated, the processor keeps track of which nodes are being processed by means of a set of implicit variables referred to collectively as the focus. More specifically, the focus consists of the following five values:

• The context item is the item currently being processed. An item (see [Data Model]) is either a simple value (such as an integer, date, or string), or a node. If the context item is a node, then it will always be a node in the context document. The initial context node is the same as the context document. 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. The context item is returned by the XPath expression . (dot).

• 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. The context position is returned by the XPath expression position().

• 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). The context size is returned by the XPath expression last().

• If the context item is a node (as distinct from a simple value 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 a simple value, there is no context node: its value is an empty sequence. The context node is returned by the XPath expression self::node(), and it is used as the starting node for all relative path expressions.

• The context document is the source document currently being processed. This is initially set to the document node of the principal source document. It changes when instructions such as xsl:apply-templates and xsl:for-each are used to process nodes in a document other than the principal source document. When such an instruction is processing a node, the context document is the document containing that node. When such an instruction is processing a simple value (an item that is not a node), the context document is the same as the context document for the content constructor containing the xsl:apply-templates or xsl:for-each instruction. The context document is returned by the XPath expression / (slash), and it is used as the starting node for all absolute path expressions.

On completion of an instruction which changes the focus (such as xsl:apply-templates or xsl:for-each), the focus reverts to its previous value.

The description above gives an outline of the way the focus works. Detailed rules for the effect of each instruction are given separately with the description of that instruction. In the absence of specific rules, an instruction uses the same focus as its parent instruction.

Sometimes the focus is based on a single node rather than a sequence. A singleton focus based on a node N has the context item (and therefore the context node) set to N, the context document set to the document containing N, and the context position and context size both set to 1 (one).

1.6 Parsing and Serialization

As explained in the previous section, an XSLT stylesheet describes a process that constructs a result tree from a source tree.

The stylesheet does not describe how the source tree is constructed. Frequently an implementation will operate in conjunction with an XML parser (or more strictly, in the terminology of [XML], an XML processor), to build the source tree from an input XML document. An implementation may also provide an application programming interface allowing the tree to be constructed directly, or allowing it to be supplied in the form of a DOM Document object (see [DOM2]). This is outside the scope of this specification. Users should be aware, however, that since the input to the transformation is a tree conforming to the data model described in [Data Model], constructs that might exist in the original XML document, or in the DOM, but which are not within the scope of the data model, cannot be processed by the stylesheet and cannot be guaranteed to remain unchanged in the transformation output. Such constructs include CDATA section boundaries, the use of entity references, and the DOCTYPE declaration and internal DTD subset.

A frequent requirement is to output the result tree as an XML document (or in other formats such as HTML). This process is referred to as serialization. Like parsing, serialization is not part of the transformation process, and it is not required that an XSLT processor should be able to perform serialization. However, for pragmatic reasons, this specification describes a declaration (the xsl:output element, see [18 Serialization]) which allows a stylesheet to specify the desired properties of a serialized output file. Implementations that do not serialize the result tree are allowed to ignore this declaration.

Because it is a common requirement to perform a transformation on a document while retaining lexical characteristics such as CDATA section boundaries, entity references, and the like, an appendix to this specification (see [G Representation of Lexical XML Constructs]) describes a way in which these constructs can be represented within the data model by means of elements in a special namespace. If such a representation is chosen, the tree is transformed in the same way as any other tree. The process of constructing such a tree is something that happens before XSLT transformation starts, and the process of interpreting such a tree and reconstituting the lexical representation is part of the serialization process. Neither of these processes is properly within the scope of XSLT transformation, and therefore, this specification places no requirement on an XSLT processor to support this representation of lexical properties.

1.7 Extensibility

XSLT provides two "hooks" for extending the language, one hook for extending the set of instruction elements used in content constructors and one hook for extending the set of functions used in XPath expressions. These hooks are both based on XML namespaces: see [16 Extensibility and Fallback] for further details. Extension instructions and extension functions defined according to these rules may be provided by the implementor of the XSLT processor, and the implementor may also provide facilities to allow users to create further extension instructions and extension functions. This specification defines how extension instructions and extension functions are invoked, but the facilities for creating new extension instructions and extension functions are 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 should be described in the vendor's documentation.

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. (This might apply, for example, to limits on the size of source documents that can be transformed.)

In all cases where this specification leaves the behavior implementation-defined or implementation-dependent, the implementation has the option of providing mechanisms that allow the user to influence the behavior.

1.8 Error Handling

An error that is 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. Errors classified in this specification as static errors must be signaled by all implementations: that is, the processor must indicate that the error is present, and it must not use the stylesheet to produce a result tree. A static error must be signaled even if it occurs in a part of the stylesheet that is never evaluated.

There is an exception to this rule when the stylesheet specifies forwards-compatible behavior (see [2.7 Forwards-Compatible Processing]).

Generally, errors in the structure of the stylesheet, or in the syntax of XPath expressions contained in the stylesheet, are classified as static errors. Where this specification states that an element in the stylesheet must or must not appear in a certain position, or that it must or must not have a particular attribute, or that an attribute must or must not have a value satisfying specified conditions, then any contravention of this rule is a static error unless otherwise specified.

An error that is not detected until a source document is being transformed is referred to as a dynamic error. In many cases, this specification allows dynamic errors to be signaled (by reporting the error condition and terminating execution), but also defines a recovery action that can be taken. It is implementation-defined whether the error is signaled or the recovery action is taken. If the implementation does choose to take recovery action, it must take the recovery action defined in this specification.

When the implementation makes the choice between signaling a dynamic error or recovering, it is not restricted in how it makes the choice; for example, it may provide options that can be set by the user. When an implementation chooses to recover from a dynamic error, it is also allowed to take other action, such as logging a warning message.

Because different implementations may optimize execution of the stylesheet in different ways, the detection of dynamic errors is to some degree implementation-dependent. In cases where an implementation is able to produce the result tree without evaluating a particular construct, the implementation is never required to evaluate that construct solely in order to determine whether doing so causes a dynamic error. For example, if a variable is declared but never referenced, an implementation can choose whether or not to evaluate the variable declaration, which means that if evaluating the variable declaration causes a dynamic error, some implementations will signal this error and others will not.

There are some cases where this specification requires that a construct must not be evaluated: for example, the content of an xsl:if instruction must not be evaluated if the test condition is false. This means that an implementation must not report any dynamic errors that would arise if the construct were evaluated.

An implementation may signal a dynamic error before any source document is available, but only if it can determine that the error would be signaled for every possible source document and every possible set of parameter values. For example, some circularity errors fall into this category: see [6.3 Circular Definitions].

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. If a type error occurs in an instruction that is actually evaluated, then it must be reported as a dynamic error. An implementation may also, optionally, report a type error as a static error, even if it occurs in part of the stylesheet that is never evaluated, provided it can establish that execution of a particular construct would never succeed. For example, the following construct contains a type error, because 42 is not allowed as an operand of the xsl:apply-templates instruction. An implementation may optionally report this as a static error, even though the offending instruction will never be evaluated, and the type error would therefore never be reported as a dynamic error.

It is implementation-defined whether type errors are reported statically.

<xsl:if test="false()">
  <xsl:apply-templates select="42"/>
</xsl:if>

If more than one error arises, an implementation is not required to signal any errors other than the first one that it detects. It is implementation-dependent which of the several errors is signaled. This applies both to static errors and to dynamic errors. An implementation is allowed to signal more than one error, but if any errors have been signaled, it must not produce a result tree.

Everything said above about error handling applies equally to errors in evaluating XSLT instructions, and errors in evaluating XPath expressions. Static errors and dynamic errors may occur in both cases.

If a transformation has successfully produced a result tree, it is still possible that errors may occur in serializing the result tree. For example, it may be impossible to serialize the result tree using the encoding selected by the user. Such an error is referred to as a serialization error. As with other aspects of serialization, the handling of serialization errors is implementation-defined: see [18 Serialization].

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

NOTE: The 1999 in the URI indicates the year in which the URI was allocated by the W3C. It does not indicate the version of XSLT being used, which is specified by attributes (see [2.4 Stylesheet Element] and [2.5 Simplified Stylesheet Modules]).

XSLT processors must use the XML namespaces mechanism [XML Names] to recognize elements and attributes from this namespace. Elements from the XSLT namespace are recognized only in the stylesheet and not in the source document. The complete list of XSLT-defined elements is specified in [C Element Syntax Summary]. Implementations must not extend the XSLT namespace with additional elements or attributes. Instead, any extension must be in a separate namespace. Any namespace that is used for additional instruction elements must be identified by means of the extension instruction mechanism specified in [16.2 Extension Instructions].

This specification uses a prefix of xsl: for referring to elements in the XSLT namespace. However, XSLT stylesheets are free to use any prefix, provided that there is a namespace declaration that binds the prefix to the URI of the XSLT namespace.

An element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded-QName (see [XPath 2.0]) of the attribute has a non-null namespace URI. The presence of such attributes must not change the behavior of XSLT elements and functions defined in this document or in the XPath specification, though they may be used to modify the behavior of extension functions and extension instructions. Thus, an implementation is always free to ignore such attributes, and must ignore such attributes without giving an error if it does not recognize the namespace URI. Such attributes can provide, for example, unique identifiers, optimization hints, or documentation. The set of namespaces that are recognized for such attributes is implementation-defined.

For example, the following code might be used to provide a hint to a particular implementation that a call to an extension function has side effects:

<xsl:value-of select="abc:set-property('someprop', 3)" 
    abc:side-effects="yes"
    xmlns:abc="http://some.vendor.com/xslt/extensions"/>

[ERR002] It is a static error for an element from the XSLT namespace to have an attribute with an expanded-QName that has a null namespace URI (i.e. an attribute with an unprefixed name) other than attributes defined for the element in this document.

NOTE: The conventions used for the names of XSLT elements, attributes and functions are that names are all lower-case, use hyphens to separate words, and use abbreviations only if they already appear in the syntax of a related language such as XML or HTML.

2.2 XSLT Media Type

The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT stylesheets. It is possible that a media type will be registered specifically for XSLT stylesheets; if and when it is, that media type may also be used.

2.3 Standard Attributes

There are a number of standard attributes that may appear on any XSLT element: specifically version, exclude-result-prefixes, extension-element-prefixes, and default-xpath-namespace.

These attributes may also appear on a literal result element, but in this case, to distinguish them from user-defined attributes, the names of the attributes are in the XSLT namespace. They are thus typically written as xsl:version, xsl:exclude-result-prefixes, xsl:extension-element-prefixes, or xsl:default-xpath-namespace.

It is recommended that these attributes should also be permitted on extension instructions, but this is at the discretion of the implementor of each extension instruction. They may also be permitted on user-defined data elements, though they will only have any useful effect in the case of data elements that are designed to behave like XSLT declarations or instructions.

In the following descriptions, these attributes are referred to generically as [xsl:]version, and so on.

These attributes all affect the element they appear on, and any descendant elements of the element they appear on, together with attributes of those descendant elements. The two forms with and without the XSLT namespace have the same effect; the XSLT namespace is used for the attribute if and only if its parent element is not in the XSLT namespace.

In the case of [xsl:]version and [xsl:]default-xpath-namespace the value can be overridden by a different value for the same attribute appearing on a descendant element. The effective value of the attribute for a particular stylesheet element is determined by the innermost containing element on which the attribute appears.

In the case of [xsl:]exclude-result-prefixes and [xsl:]extension-element-prefixes the values are cumulative. For these attributes, the value is a whitespace-separated list of namespace prefixes, and the effective value for an element is the combined set of prefixes that appear in this attribute for that element and any of its ancestor elements. Again, the two forms with and without the XSLT namespace are equivalent.

Because these attributes may appear on any XSLT element, they are not listed in the syntax summary of each individual element. Instead they are listed and described in the description of the xsl:stylesheet and xsl:transform elements only. This reflects the fact that these attributes are often used on the xsl:stylesheet element, in which case they apply to the entire stylesheet module.

Note that the effect of these attributes does not extend to stylesheet modules referenced by xsl:include or xsl:import declarations.

For the detailed effect of each attribute, see the following sections:

• [xsl:]version: see [2.6 Backwards-Compatible Processing] and [2.7 Forwards-Compatible Processing]
• [xsl:]default-xpath-namespace: see [4.4 Unprefixed Names in Expressions and Patterns].
• [xsl:]exclude-result-prefixes: see [8.1.2 Namespace Nodes for Literal Result Elements].
• [xsl:]extension-element-prefixes: see [16.2 Extension Instructions].

2.4 Stylesheet Element

<xsl:stylesheet
  id = id
  extension-element-prefixes = tokens
  exclude-result-prefixes = tokens
  version = number
  default-xpath-namespace = uri>
  <!-- Content: (xsl:import*, top-level-elements) -->
</xsl:stylesheet>

<xsl:transform
  id = id
  extension-element-prefixes = tokens
  exclude-result-prefixes = tokens
  version = number
  default-xpath-namespace = uri>
  <!-- Content: (xsl:import*, top-level-elements) -->
</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.

[ERR003] An xsl:stylesheet element must have a version attribute, indicating the version of XSLT that the stylesheet requires. [ERR004] The value of the version attribute must be a number (specifically, it must be a DecimalLiteral as defined in [XPath 2.0].) For this version of XSLT, the value should normally be 2.0. When the value is less than 2.0, backwards-compatible processing behavior is enabled (see [2.6 Backwards-Compatible Processing]). When the value is greater than 2.0, forwards-compatible behavior is enabled (see [2.7 Forwards-Compatible Processing]).

[ERR005] An xsl:stylesheet element must have no text node children, other than text nodes consisting entirely of whitespace.

An element occurring as a child of an xsl:stylesheet element is called a top-level element.

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 [2.4.1 User-defined Data Elements])

The xsl:stylesheet element may contain the following types of declaration:

• xsl:import
• xsl:include
• xsl:attribute-set
• xsl:decimal-format
• xsl:function
• xsl:import-schema
• xsl:key
• xsl:namespace-alias
• xsl:output
• xsl:param
• xsl:preserve-space
• xsl:principal-result-document
• xsl:sort-key
• xsl:strip-space
• xsl:template
• xsl:variable

The order in which the children of the xsl:stylesheet element occur is not significant except for xsl:import elements and for error recovery. Users are free to order the elements as they prefer, and stylesheet creation tools need not provide control over the order in which the elements occur.

2.5 Simplified Stylesheet Modules

A simplified syntax is allowed for a stylesheet module that consists of only a single template rule for the document node. The stylesheet module may consist of just a literal result element (see [8.1 Literal Result Elements]). Such a stylesheet is equivalent to a standard stylesheet module whose xsl:stylesheet element contains a template rule containing the literal result element; the template rule has a match pattern of /. For example:

<html xsl:version="2.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Expense Report Summary</title>
  </head>
  <body>
    <p>Total Amount: <xsl:value-of select="expense-report/total"/></p>
  </body>
</html>

has the same meaning as

<xsl:stylesheet version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns="http://www.w3.org/1999/xhtml">
<xsl:template match="/">
<html>
  <head>
    <title>Expense Report Summary</title>
  </head>
  <body>
    <p>Total Amount: <xsl:value-of select="expense-report/total"/></p>
  </body>
</html>
</xsl:template>
</xsl:stylesheet>

More formally, a simplified stylesheet module is equivalent to the standard stylesheet module that would be generated by applying the following transformation to the simplified stylesheet module:

<xsl:stylesheet version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/*">
  <xsl:element name="xsl:stylesheet">
    <xsl:attribute name="version">
      <xsl:value-of select="@xsl:version"/>
    </xsl:attribute>
    <xsl:element name="xsl:template">
      <xsl:attribute name="match">/</xsl:attribute>
      <xsl:copy-of select="."/>
    </xsl:element>
  </xsl:element>
</xsl:template>  

</xsl:stylesheet>

If the outermost element of the simplified stylesheet is not the document element, then in the above transformation the attribute match="/*" must be replaced by a pattern than matches this outermost element. Note that if the element has an ID attribute to enable it to be selected (for example in the fragment identifier of a URI reference), then this ID attribute will be copied to the result document in the same way as other attributes of a literal result element.

[ERR008] A literal result element that is used as the outermost element of a simplified stylesheet module must have an xsl:version attribute. This indicates the version of XSLT that the stylesheet requires. For this version of XSLT, the value should normally be 2.0; the value must be a DecimalLiteral as defined in [XPath 2.0].

Other literal result elements may also have an xsl:version attribute. When the xsl:version attribute is numerically less than 2.0, backwards-compatible processing behavior is enabled (see [2.6 Backwards-Compatible Processing]). When the xsl:version attribute is numerically greater than 2.0, forwards-compatible behavior is enabled (see [2.7 Forwards-Compatible Processing]).

The allowed content of a literal result element when used as a simplified stylesheet is the same as when it occurs within a content constructor. Thus, a literal result element used as the document element of a simplified stylesheet cannot contain declarations.

2.6 Backwards-Compatible Processing

An element enables backwards-compatible behavior for itself, its attributes, its descendants and their attributes if either it has an [xsl:]version attribute (see [2.3 Standard Attributes]) whose value is less than 2.0. An element that has an [xsl:]version attribute whose value is greater than or equal to 2.0 disables backwards-compatible behavior for itself, its attributes, its descendants and their attributes. The compatibility behavior established by an element overrides any compatibility behavior established by an ancestor element.

If an attribute containing an XPath expression is processed with backwards-compatible behavior, then:

• It is constrained to use syntax permitted by XPath 1.0

• It is guaranteed to return the same result as would be returned by XPath 1.0, after conversion of any variables that it references to the equivalent XPath 1.0 data type. This conversion is done as follows. Any numeric value is converted to the nearest XPath 1.0 number. Boolean values remain as booleans; any other simple value is converted to a string. [ERR009] If the value is an empty sequence or a sequence that consists entirely of nodes, then it is converted to a node-set; it is a dynamic error if the value is any other sequence of two or more items. The processor must signal the error. The result of the expression is converted to an XPath 2.0 value by representing any node-set as a sequence of nodes in document order.

It is implementation-defined whether a particular XSLT 2.0 implementation supports backwards-compatible behavior. [ERR010] If an implementation does not support backwards-compatible behavior, then it is a dynamic error if any element is evaluated that enables backwards-compatible behavior. The processor must signal the error.

2.7 Forwards-Compatible Processing

An element enables forwards-compatible behavior for itself, its attributes, its descendants and their attributes if it has an [xsl:]version attribute (see [2.3 Standard Attributes]) whose value is greater than 2.0. An element that has an [xsl:]version attribute whose value is less than or equal to 2.0 disables forwards-compatible behavior for itself, its attributes, its descendants and their attributes. The compatibility behavior established by an element overrides any compatibility behavior established by an ancestor element.

Within a section of a stylesheet where forwards-compatible behavior is enabled, errors that would normally be static errors are treated instead as dynamic errors. This means that no error is reported unless the construct containing the error is actually evaluated.

This means, for example, that when an element is processed with forwards-compatible behavior:

• if it is a top-level element and XSLT 2.0 does not allow such elements as top-level elements, then the element must be ignored along with its content;

• if it is an element in a content constructor and XSLT 2.0 does not allow such elements to occur in content constructors, then if the element is not evaluated, no error must be signaled, and if the element is evaluated, the processor must perform fallback for the element as specified in [16.2.3 Fallback];

• if the element has an attribute that XSLT 2.0 does not allow the element to have or if the element has an optional attribute with a value that XSLT 2.0 does not allow the attribute to have, then the attribute must be ignored.

• if an attribute of the element contains an XPath expression that does not match the allowed syntax of an XPath 2.0 expression, or one that calls a function with an unprefixed name that is not defined in XPath 2.0 or XSLT 2.0, or that calls such a function with the wrong number or type of arguments, the error must not be signaled unless the expression is actually evaluated.

Thus, any XSLT 2.0 processor must be able to process the following stylesheet without error, although the stylesheet includes elements from the XSLT namespace that are not defined in this specification:

<xsl:stylesheet version="17.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:choose>
      <xsl:when test="system-property('xsl:version') >= 17.0">
        <xsl:exciting-new-17.0-feature/>
      </xsl:when>
      <xsl:otherwise>
        <html>
        <head>
          <title>XSLT 17.0 required</title>
        </head>
        <body>
          <p>Sorry, this stylesheet requires XSLT 17.0.</p>
        </body>
        </html>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
</xsl:stylesheet>

NOTE: If a stylesheet depends crucially on a declaration introduced by a version of XSLT after 2.0, then the stylesheet can use an xsl:message element with terminate="yes" (see [15 Messages]) to ensure that implementations that conform to an earlier version of XSLT will not silently ignore the declaration. For example,

<xsl:stylesheet version="18.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:important-new-17.0-declaration/>

  <xsl:template match="/">
    <xsl:choose>
      <xsl:when test="system-property('xsl:version') < 17.0">
        <xsl:message terminate="yes">
          <xsl:text>Sorry, this stylesheet requires XSLT 17.0.</xsl:text>
        </xsl:message>
      </xsl:when>
      <xsl:otherwise>
        ...
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>
  ...
</xsl:stylesheet>

2.8 Combining Stylesheet Modules

XSLT provides two mechanisms to construct a stylesheet from multiple stylesheet modules:

• an inclusion mechanism that allows stylesheet modules to be combined without changing the semantics of the modules being combined, and
• an import mechanism that allows stylesheet modules to override each other.

<xsl:stylesheet version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:import href="article.xsl"/>
  <xsl:import href="bigfont.xsl"/>
  <xsl:attribute-set name="note-style">
    <xsl:attribute name="font-style">italic</xsl:attribute>
  </xsl:attribute-set>
</xsl:stylesheet>

2.9 Embedded Stylesheet Modules

A standard stylesheet module is a complete XML document with the xsl:stylesheet element as its document element. However, a stylesheet module may also be embedded in another resource. Two forms of embedding are possible:

• the XSLT stylesheet may be textually embedded in a non-XML resource, or
• the xsl:stylesheet element may occur in an XML document other than as the document element.

To facilitate the second form of embedding, the xsl:stylesheet element is allowed to have an ID attribute that specifies a unique identifier.

NOTE: In order for such an attribute to be used with the XPath id function, it must actually be declared in the DTD as being of type ID. The same requirement typically applies if the identifier is to be used as a fragment identifier in a URI reference.

The following example shows how the xml-stylesheet processing instruction (see [XML Stylesheet]) can be used to allow a source document to contain its own stylesheet. The URI reference uses a relative URI with a fragment identifier to locate the xsl:stylesheet element:

<?xml-stylesheet type="text/xml" href="#style1"?>
<!DOCTYPE doc SYSTEM "doc.dtd">
<doc>
<head>
<xsl:stylesheet id="style1"
                version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                xmlns:fo="http://www.w3.org/1999/XSL/Format">
<xsl:import href="doc.xsl"/>
<xsl:template match="id('foo')">
  <fo:block font-weight="bold"><xsl:apply-templates/></fo:block>
</xsl:template>
<xsl:template match="xsl:stylesheet">
  <!-- ignore -->
</xsl:template>
</xsl:stylesheet>
</head>
<body>
<para id="foo">
...
</para>
</body>
</doc>

NOTE: A stylesheet module that is embedded in the document to which it is to be applied or that may be included or imported into a stylesheet that is so embedded typically needs to contain a template rule that specifies that xsl:stylesheet elements are to be ignored.

NOTE: The above example uses the pseudo-attribute type="text/xml" in the xml-stylesheet processing instruction to denote an XSLT stylesheet. This usage was defined provisionally in XSLT 1.0, and is subject to change. In the absence of a registered media type for XSLT stylesheets, some vendors' products have adopted different conventions, notably type="text/xsl".

NOTE: Support for the xml-stylesheet processing instruction is not a requirement for conformance with this Recommendation.

Issue (schema-explanation): We need to say something here about schemas and DTDs.

3.1 Parentless Nodes

The data model defined in [Data Model] allows a node to be part of a tree whose root is a node other than a document node.

XSLT does not allow nodes with no parent (other than document nodes) to be created, other than transiently: a node created during the course of XSLT processing is not available for further processing until it has been attached to a tree that is rooted at a document node. However, implementations may allow parentless nodes to be supplied as input to the transformation, for example as parameters to the stylesheet.

3.2 Document Node Children

Ed. Note: This section can be removed when it is confirmed that the data model permits "well-balanced" trees. At the time of writing, this is still an open issue in the data model (Issue 0041).

The normal restrictions on the children of the document node are relaxed for the result tree and for temporary trees constructed during the evaluation of the stylesheet. The document node of such a tree may have any sequence of nodes as children that would be possible for an element node. In particular, it may have text node children, and any number of element node children. When written out using the XML output method (see [18 Serialization]), it is possible that a result tree will not be a well-formed XML document; however, it will always be a well-formed external general parsed entity.

For example, a stylesheet might produce the following output. This is a well-formed external general parsed entity, but it is not a well-formed XML document:

<?xml version="1.0" encoding="iso-8859-1"?>A <i>fine</i> mess!

When a source tree is created by parsing a well-formed XML document, the document node of the source tree will automatically satisfy the normal restrictions of having no text node children and exactly one element child. When a source tree is created in some other way, for example by using the DOM, the usual restrictions are relaxed for the source tree as for the result tree.

3.3 Unparsed Entities

Ed. Note: Unparsed entities don't currently appear in the data model, though we have asked for them to be added. This section can be deleted when the Data Model is updated to support unparsed entities.

The document node has a mapping that gives the URI for each unparsed entity declared in the document's DTD. The URI is generated from the system identifier and public identifier specified in the entity declaration. The processor may use the public identifier to generate a URI for the entity instead of the URI specified in the system identifier. If the processor does not use the public identifier to generate the URI, it must use the system identifier; if the system identifier is a relative URI, it must be resolved into an absolute URI using the URI of the resource containing the entity declaration as the base URI [RFC2396].

3.4 Whitespace Stripping

The source document supplied as input to the transformation process may contain whitespace nodes (that is, text nodes consisting solely of whitespace characters) that are of no interest, and that do not need to be retained by the transformation. Conceptually, such whitespace nodes may be removed from the tree before the transformation commences. This process is referred to as whitespace stripping. The source tree itself must not be modified: the processor may implement whitespace stripping either by creating a copy of the tree from which the whitespace nodes have been removed, or by working on a virtual tree in which the whitespace nodes are treated as if they were absent.

The stripping process takes as input a set of element names whose child whitespace nodes must be preserved. The stripping process is applied to both stylesheets and source documents, but the set of whitespace-preserving element names is determined differently for stylesheets and for source documents.

NOTE: Where multiple transformations are to be applied to the same source document, a useful optimization is to do the whitespace stripping only once. Implementations may therefore allow whitespace stripping to be controlled as a separate operation from the rest of the transformation process.

A text node is preserved if any of the following apply:

• The element name of the parent of the text node is in the set of whitespace-preserving element names.

• The text node contains at least one non-whitespace character. As in XML, a whitespace character is #x20, #x9, #xD or #xA.

  Issue (NEL-char): Should we make provision for XML 1.1 and its introduction of NEL as a whitespace character?

• An ancestor element of the text node has an xml:space attribute with a value of preserve, and no closer ancestor element has xml:space with a value of default.

Otherwise, the text node is stripped.

The xml:space attributes are not removed from the tree.

NOTE: This implies that if an xml:space attribute is specified on a literal result element, it will be included in the result.

For stylesheets, the set of whitespace-preserving element names consists of just xsl:text.

Processing instructions and comments in a stylesheet module are ignored: the stylesheet module is treated as if the processing instructions and comments were not there. This also means that sibling text nodes that are separated by a processing instruction or comment in a stylesheet module are concatenated into a single text node; and a text node is classified as a whitespace text node for the purpose of whitespace stripping only after this concatenation has taken place.

The content model for some XSLT elements (for example xsl:stylesheet and xsl:choose) does not permit text nodes as children of these elements. If the xml:space="preserve" attribute is used to suppress the stripping of whitespace text nodes within such elements, then any whitespace used for the layout of such elements will be retained in the stylesheet tree in the form of whitespace text nodes. Such text nodes must not be reported as an error. [ERR018] Within an XSLT element that is required to be empty, any content other than comments or processing instructions, including any whitespace-only text node preserved using the xml:space="preserve" attribute, is a static error.

<!-- Category: declaration -->
<xsl:strip-space
  elements = tokens />

<!-- Category: declaration -->
<xsl:preserve-space
  elements = tokens />

For source documents, the set of whitespace-preserving element names is specified by xsl:strip-space and xsl:preserve-space declarations. Whether an element name is included in the set of whitespace-preserving names is determined by the best match amongst xsl:strip-space or xsl:preserve-space declarations: it is included if and only if there is no match or the best match is an xsl:preserve-space element. The xsl:strip-space and xsl:preserve-space elements each have an elements attribute whose value is a whitespace-separated list of NameTests; an element name matches an xsl:strip-space or xsl:preserve-space element if it matches one of the NameTests. An element matches a NameTest if and only if the NameTest would be true for the element as an XPath node test. When more than one xsl:strip-space and xsl:preserve-space element matches, the best matching element is determined by the best matching NameTest. This is determined in the same way as with template rules:

• First, any match with lower import precedence than another match is ignored.

• Next, any match that has a lower default priority than the default priority of another match is ignored.

[ERR019] It is an dynamic error if this leaves more than one match. The processor must either signal the error, of must recover by choosing, from amongst the matches that are left, the one that occurs last in declaration order.

NOTE: A source document is supplied as input to the XSLT processor in the form of a tree. Nothing in this specification states that this tree must be built by parsing an XML document; nor does it state that the application that constructs the tree is required to treat whitespace in any particular way. The provisions in this section relate only to whitespace text nodes that are present in the tree supplied as input to the processor. In particular, the processor cannot preserve whitespace text nodes unless they were actually present in the supplied tree.

3.5 Namespace Fixup

Ed. Note: The process of namespace fixup would ideally be described along with the node construction functions defined in the XPath 2.0 data model.

In a tree constructed by parsing an XML document, the following constraints relating to namespace nodes will be satisfied:

• If an element node has an expanded-QName with a non-null namespace URI, then that element node will have at least one namespace node whose string-value is the same as that namespace URI.

• If an attribute node has an expanded-QName with a non-null namespace URI, then the parent element of that attribute will have at least one namespace node whose string-value is the same as that namespace URI and whose expanded-QName has a non-empty local part.

• If an element node has a namespace node with an expanded-QName with a non-empty local part, then every child element of that element will also have a namespace node with that expanded-QName (possibly with a different string-value).

• Every element has a namespace node whose expanded-QName has local-part xml and whose string-value is http://www.w3.org/XML/1998/namespace.

However, when a tree is being constructed as the result of an XSLT transformation, these constraints might not be satisfied unless special action is taken. In particular, since xsl:element and xsl:attribute instructions do not create namespace nodes, they will often cause these constraints not to be satisfied. The process of namespace fixup modifies a tree by adding namespace nodes so that it satisfies all constraints affecting namespace nodes. What namespace nodes are added and where they are added by namespace fixup is implementation-dependent, provided that the resulting tree satisfies the constraints and provided that all namespaces nodes in the resulting tree are allowable, where a namespace node is allowable for an element E if any of the following conditions applies:

• The namespace node was in the tree before namespace fixup.

• The local-part of the expanded-QName of the namespace node is xmland its string-value is http://www.w3.org/XML/1998/namespace.

• The namespace node has a string-value equal to the namespace URI of the expanded-QName of element E.

• The namespace node has a string-value equal to the namespace URI of the expanded-QName of an attribute of element E; this applies only if the local part of the expanded-QName of the namespace node is non-empty.

• Element E has a parent element with a namespace node that is allowable and that has the same expanded-QName and same string-value as the other namespace node; this applies only if the local part of the expanded-QName of the namespace node is non-empty.

Namespace fixup must not result in an element having multiple namespace nodes with the same expanded-QName.

Namespace fixup is performed in two situations:

• It is applied to a result tree, before the result tree is made available to the calling application (whether by serialization or otherwise: see [18 Serialization]).

• It is applied to a temporary tree, before the temporary tree is made available for processing by stylesheet instructions. (see [6.1 Values of Variables and Parameters]).

There is no requirement to perform namespace fixup for the principal source document, nor for any document loaded using the document function, nor for any document supplied as the value of a global parameter, nor for any document returned by an extension function. [ERR020] It is a dynamic error if such a document does not already satisfy the constraints listed above . The processor may signal the error, or may recover by performing namespace fixup, or may produce implementation-dependent results.

3.6 Disable Output Escaping

If an implementation supports the disable-output-escaping attribute of xsl:text and xsl:value-of (see [18.5 Disabling Output Escaping]), then the data model for trees constructed by the processor is augmented with a boolean value representing the value of this property.

Conceptually, each character in a text node on a result tree has a boolean property indicating whether the serializer should disable the normal rules for escaping of special characters (for example, outputting of & as &) in respect of this character.

This property is preserved when a text node is copied using xsl:copy or xsl:copy-of.

NOTE: There are many ways an implementation can avoid the overhead of actually storing a boolean flag with every character.

4.1 Qualified Names

The name of an internal XSLT object, specifically a named template (see [7.1 Named Templates]), a mode (see [5.6 Modes]), an attribute set (see [7.2 Named Attribute Sets]), a key (see [14.3 Keys]), a named sort specification (see [12.4 Using Named Sort Specifications]), a decimal-format (see [14.4 Number Formatting]), a variable or parameter (see [6 Variables and Parameters]), a stylesheet function (see [7.3 Stylesheet Functions]), or a named output definition (see [18 Serialization]), is specified as a QName.

A QName is always written in the form NCName (":" NCName)?, that is, a local name optionally qualified by a namespace prefix. When two QNames are compared, however, they are considered equal if the corresponding expanded-QNames are the same.

An expanded-QName is a pair of values containing a namespace URI and a local name. A QName is expanded by replacing the namespace prefix with the corresponding namespace URI, from the namespace declarations that are in scope at the point where the QName is written. Two expanded-QNames are equal if the namespace URIs are the same and the local names are the same.

QNames always occur either as the value of an attribute node in a stylesheet module, or within an XPath expression contained in such an attribute node, or as the result of evaluating an XPath expression contained in such an attribute node. The element containing this attribute node is referred to as the defining element of the QName.

If the QName has a prefix, then the prefix is expanded into a URI reference using the namespace declarations in effect on its defining element. The expanded-QName consisting of the local part of the name and the possibly null URI reference is used as the name of the object. The default namespace (as defined by a namespace declaration of the form xmlns="some.uri") is not used for unprefixed names.

In the case of an unprefixed QName used as a NameTest within an XPath expression (see [4.2 Expressions]) or within a pattern (see [4.3 Patterns]), or in the elements attribute of the xsl:strip-space and xsl:preserve-space instructions, the namespace to be used in expanding the QName may be specified by means of the [xsl:]default-xpath-namespace attribute, as specified in [4.4 Unprefixed Names in Expressions and Patterns].

[ERR021] In the case of a QName used as the value of an attribute in the stylesheet, or appearing within the text of an XPath expression in the the stylesheet, it is a static error if the defining element has no namespace node whose name matches the prefix of the QName.

[ERR022] In the case of a QName produced by evaluating an XPath expression, it is a dynamic error if the defining element has no namespace node whose name matches the prefix of the QName. The error is a dynamic error even if the value of the expression is known statically, for example if the QName is written as a string literal. The required action depends on the defining element.

4.2 Expressions

XSLT uses the expression language defined by XPath 2.0 [XPath 2.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 the result tree.

An expression must match the XPath production Expr.

An XPath expression may occur as the value of certain attributes on XSLT-defined elements, and also within curly braces in attribute value templates.

[ERR023] It is a static error if the value of such an attribute, or the text between curly braces in an attribute value template, does not match the XPath production Expr, 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.

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

[ERR024] It is a type error if an XPath expression contains a type error, or if the type of the XPath expression is incompatible with the required type. The processor must either signal a type error as a static error, or must attempt to recover by converting the result of the expression to the required type using the standard type conversion rules; if conversion is not possible under these rules, the processor must signal a dynamic error

The context for evaluation of an XPath expression is determined according to the following rules. The context has two parts: the static context, and the dynamic expression evaluation context.

The static context depends on the element in the stylesheet that contains the attribute holding the XPath expression ("the containing element") as follows:

• The type exception policy is, by default, flexible, meaning that the system attempts to convert supplied values to the required type when possible (using the fallback conversion rules defined in [XPath 2.0]). An implementation may provide the alternative policy, strict, as a user-selectable option.

• The in-scope namespaces are the namespace declarations that are in scope for the containing element.

• The default namespace for element names is the namespace defined by the innermost [xsl:]default-xpath-namespace attribute, as described in [4.4 Unprefixed Names in Expressions and Patterns]. The value of this attribute is a namespace URI.

• The default namespace for function names is the namespace http://www.w3.org/2002/04/xquery-operators, defined in [Functions and Operators]. This means that it is not necessary to declare this namespace in the stylesheet, nor to use the prefix xf used in the specification of the