The root node is the root of the tree. It does not occur anywhere else in the tree. It has a single child which is the element node for the document element of the document.

There is an element node for every element in the document. An element has an expanded name consisting of a local name and a possibly null URI (see ); the URI will be null if the element type name has no prefix and there is no default namespace in scope.

An element node also has a namespace prefix map that specifies the namespace URI for each namespace prefix that is in scope for the element. The semantics of a document type may treat parts of attribute values or data content as namespace prefixes. The namespace prefix map ensures that the semantics can be preserved when the tree is written out as XML. When writing an element node out as XML, an XSL processor must add sufficient namespace-declaring attributes to the start-tag to ensure that all prefixes in the element node's namespace prefix map are correctly declared.

The children of an element node are the element nodes and characters for its content. Entity references to both internal and external entities are expanded. Character references are resolved.

The descendants of an element node are the character children, the element node children, and the descendants of the element node children.

The set of all element nodes in a document can be ordered according to the order of the start-tags of the elements in the document; this is known as document order.

Each element node has an associated set of attribute nodes. A defaulted attribute is treated the same as a specified attribute. If an attribute was declared for the element type, but the default was declared as #IMPLIED, and the attribute was not specified on the element, then the element's attribute set does not contain a node for the attribute.

An attribute node has an expanded name and has a string value. The expanded name consists of a local name and a possibly null URI (see ); the URI will be null if the specified attribute name did not have a prefix. The value is the normalized value as specified by the XML Recommendation . An attribute value whose value is of zero length is not treated specially.

There are no attribute nodes for attributes that declare namespaces (see ).

Each character within a CDATA section is treated as character data. Thus <![CDATA[<]]> in the source document will treated the same as <. Characters inside comments or processing instructions are not character data. Line-endings in external entities are normalized to #xA as specified in the XML Recommendation .

After the tree has been constructed, but before it is otherwise processed by XSL, some whitespace characters may be stripped. The stripping process takes as input a set of element types for which whitespace must be preserved. The stripping process is applied to both stylesheets and source documents, but the set of whitespace-preserving element types is determined differently for stylesheets and for source documents.

A character object is preserved if any of the following apply:

Otherwise the character object is stripped.

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

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

For source documents, the set of whitespace-preserving element types is determined using the stylesheet as follows:

The xsl:stylesheet element can include an indent-result attribute with values yes or no. If the stylesheet specifies indent-result="yes", then the XSL processor may add whitespace to the result tree (possibly based on whitespace stripped from either the source document or the stylesheet) in order to indent the result nicely; if indent-result="no", it must not add any whitespace to the result. When adding whitespace with indent-result="yes", the XSL processor can use any algorithm provided that the result is the same as the result with indent-result="no" after whitespace is stripped from both using the process described with the set of whitespace-preserving element types consisting of just xsl:text.

It is possible for a source node to match more than one template rule. The template rule to be used is determined as follows:

It is an error if this leaves more than one matching template rule. An XSL processor may signal the error; if it does not signal the error, it must recover by choosing from amongst the matching template rules that are left the one that occurs last in the stylesheet.

There is a built-in template rule to allow recursive processing to continue in the absence of a successful pattern match by an explicit rule in the stylesheet. This rule applies to both element nodes and the root node. The following shows the equivalent of the built-in template rule:

The built-in template rule is treated as if it were imported implicitly before the stylesheet and so is considered less important than all other template rules. Thus the author can override the built-in rule by including an explicit rule with match="*|/".

A pattern may consist of a set of patterns representing ancestry separated by the | character. This indicates that an element matching any one of the ancestry patterns matches the entire pattern. Each ancestry pattern may itself have the capability of a full pattern except for the | operator.

This example creates an fo:sequence for either emph or strong elements:

Element ancestry can be represented within the pattern by using the parent operator (/). This operator is based on the familiar directory navigation metaphor. Two patterns separated by the parent operator match an element if the right-hand side matches the element and the left-hand side matches the parent of the element.

For example, the following pattern matches title source elements that have a section element as a parent and a chapter element as a grandparent:

While the parent operator specifies a parent-child relationship, the ancestor operator (//) specifies an ancestor-descendant relationship. Two patterns separated by the ancestor operator match an element if the right-hand side matches the element and the element has at least one ancestor that the left-hand side matches. Thus zero or more levels of hierarchy may intervene between the element matching the pattern specified on the left-hand side of the ancestor operator and the element matching the pattern specified on the right-hand side.

This example applies to changed elements which have a para element as an ancestor.

The first component of an AncestryPattern can be an Anchor. An Anchor is a pattern that only a specific element in the source tree matches (if any elements at all match). The Anchor is said to address the specific element that matches it.

There are two kinds of anchor, relative and absolute. A relative anchor addresses an element relative to the current node. An absolute anchor addresses an element independently of any current node. A match pattern must not contain a RelativeAnchor; all anchors in a match pattern must be absolute. A select pattern may contain both kinds of anchor.

A CurrentNodeAnchor addresses the current node.

A select pattern is implicitly anchored to the current node: if an AncestryPattern in the Pattern does not start with an Anchor or a RootPattern, it is treated as if it were ./AncestryPattern. For example, a select pattern of foo will be treated as ./foo and will thus select the foo children of the current node.

A ParentAnchor addresses the parent of the current node.

A RootPattern matches the root node (see ).

The simplest pattern consists of just an element type name. This matches any element of that type.

The * pattern is a wildcard that matches a single element of any type. When used within an ancestry chain, the wildcard matches exactly one level of hierarchy.

The following pattern matches any element that is an immediate child of a data-samples element.

When determining whether a source element matches an ElementTypeName, the expanded element type names are compared (see ).

An element within the pattern hierarchy may have qualifiers applied to it, which further constrain which elements match the term. These qualifiers may constrain the element to have certain attributes or sub-elements or may constrain its position with respect to its siblings. The qualifiers are specified in square brackets ([]) following the element type name or wildcard symbol. A pattern matches only if all of the qualifiers are satisfied.

This example matches author elements within book elements where the book contains at least one excerpt sub-element and the author has a degree attribute:

An element can be constrained to have a child element of a particular type by specifying the name of that type as a qualifier.

This example has a pattern that matches author elements within book elements which also have excerpt children (the author and excerpt elements are siblings).

Attributes on the source element or any of its ancestor elements can also be used to determine whether a particular rule applies to an element. An attribute qualifier constrains an element either to have a specific attribute with a specific value, or to have a specific attribute with any value.

When matching attribute names, the expanded names are compared (see ).

The following example matches an item element that has for its parent a list element which has a compact attribute:

The following example matches an item element that has for its parent a list element whose liststyle attribute has the value enum:

It is also possible to select attribute nodes. Within a select pattern, an AncestryPattern can end with an AttributePattern. This will select the attribute node with the specified name for each element in the node list selected by the pattern preceding AttributePattern. Within a match pattern, an AncestryPattern must not end with an AttributePattern.

Positional qualifiers may be used to further constrain the pattern to match on the element's position or uniqueness among its siblings.

XSL defines the following positional qualifiers:

The following pattern matches the first item in a list:

The following rule is used for appendix elements when there is only one appendix:

For readability, whitespace may be used in patterns even though not explicitly allowed by the grammar: PatternWhitespace may be freely added within patterns before or after any PatternToken.

When a source element is matched against multiple patterns, it is possible for it to match more than one distinct pattern. In this situation, XSL defines which pattern or patterns are the most specific.

A pattern that starts with an IdAnchor is more specific than a pattern that does not. If two patterns both start with an IdAnchor or both do not start with an IdAnchor, then the one with the more components is the more specific, where a component is either a Qualifier or a OneElementTypePattern.

For example, the following patterns are in decreasing order of specificity:

When a pattern contains alternatives separated by |, each alternative is treated separately for specificity purposes. A rule that contains a pattern with two alternatives is equivalent to two rules with the same content each specifying one of the alternatives as its patterns. For example

is equivalent to

When the rule that is to be applied to the source element has been identified, the rule's template is instantiated. A template can contain literal result elements, character data and instructions for creating fragments of the result tree. Instructions are represented by elements in the XSL namespace.

Instructions can select descendant elements for processing. There are two such instructions, the xsl:process-children instruction and the xsl:process instruction; the xsl:process-children instruction processes the immediate children of the source element, while the xsl:process instruction processes elements selected by a specified pattern.

Note that xsl:process-children selects any character children of the source element as well as the element children. The result in this case is the sequence of results of processing the individual character children and element children in sequence.

In a template an element in the stylesheet that does not belong to the XSL namespace is instantiated to create an element node of the same type; the created element node will have the attributes that were specified on the element in the template tree.

The value of an attribute of a literal result element is interpreted as an attribute value template: it can contain string expressions contained in curly braces ({}).

The namespace prefix map of the result element node is the namespace prefix map of the element node in the stylesheet after the removal of any prefixes that map to the XSL namespace URI.

Since an XSL processor acts on elements belonging to the XSL namespace, the problem arises of how to create elements belonging to the XSL namespace. A namespace whose URI is http://www.w3.org/TR/WD-xsl followed by one or more occurrences of /quote is called a quoted namespace. Quoted namespaces are treated specially: before a result tree is written out as XML all quoted namespace URIs in expanded names and in namespace prefix maps are unquoted by removing the final /quote.

The xsl:define-attribute-set element defines a named set of attributes. The name attribute specifies the name of the attribute set. The content of the xsl:define-attribute-set element is an xsl:attribute-set element that specifies the attributes. A literal result element or an xsl:attribute-set element can specify an attribute set name as the value of the xsl:use attribute.

The following example creates a named attribute set title-style and uses it in a template rule.

If the xsl:use attribute is specified on an element that also specifies a value for an attribute that is also part of the attribute set named by xsl:use, the attribute in the named attribute set is not used.

Multiple definitions of an attribute set with the same name are merged. An attribute from a definition that is more important takes precedence over an attribute from a definition that is less important. It is an error if there are two attribute sets with the same name that are equally important and that both contain the same attribute unless there is a more important definition of the attribute set that also contains the attribute. An XSL processor may signal the error; if it does not signal the error, it must recover by choosing from amongst the most important definitions that specify the attribute the one that was specified last in the stylesheet.

An xsl:use attribute may specify a list of attribute set names separated by whitespace. These attribute sets will be merged treating the list as being in order of increasing importance.

A template can also contain PCDATA. Each data character in a template remaining after whitespace has been stripped as specified in will create a data character in the result tree.

Literal data characters may also be wrapped in an xsl:text element. This wrapping may change what whitespace characters are stripped (see ) but does not affect how the characters are handled by the XSL processor thereafter.

This example creates a block for a chapter element and then processes its immediate children.

The xsl:process-children instruction processes all of the children of the current node, including characters. However, characters that have been stripped as specified in will not be processed.

Processing a character in the source tree adds the character to the result tree. Note that this works at the tree level. Thus, markup of < in content will be represented by a character < in the source tree which will, with the built-in template rules, turn into a < character in the result tree, which would be represented by the markup < (or an equivalent character reference) when the result tree is externalized as an XML document.

The xsl:process element processes elements selected by a pattern. The pattern of an xsl:process element is a select pattern and so is implicitly anchored to the current node. The following example processes all of the author children of the author-group:

The xsl:process element processes all elements which match the specified pattern. Character data content is not matched by an xsl:process element. The pattern must not contain an AttributePattern except as part of an AttributeQualifier

The pattern controls the depth at which matches occur. The following example processes all of the first-names of the authors that are direct children of author-group:

The // operator can be used in the pattern to allow the matches to occur at arbitrary depths.

This example processes all of the heading elements contained in the book element.

An AncestorAnchor in the pattern allows the processing of elements that are not descendants of the current node. This example finds an employee's department and then processes the group children of the department.

This example assumes that a department element contains group and employee elements (at some level). When processing the employee elements, the AncestorAnchor in the pattern allows navigation upward to the department element in order to extract the information about the group to which the employee belongs.

An IdAnchor allows processing of elements with a specific ID. For example, this template rule applies to elements with the ID cfo; the second xsl:process element processes the name child of the element with ID ceo:

Multiple xsl:process elements can be used within a single template to do simple reordering. The following example creates two HTML tables. The first table is filled with domestic sales while the second table is filled with foreign sales.

Use of Anchors in patterns in xsl:process can lead to infinite loops. It is an error if, during the invocation of a rule for an element, that same rule is invoked again for that element. An XSL processor may signal the error; if it does not signal the error, it must recover by creating an empty result tree structure for the nested invocation.

When the result has a known regular structure, it is useful to be able to specify directly the template for selected elements. The xsl:for-each element contains a template which is instantiated for each element selected by the pattern specified by the select attribute.

For example, given an XML document with this structure

the following would create an HTML document containing a table with a row for each customer element

As with xsl:process the pattern is a select pattern and so is implicitly anchored to the current node. The select attribute is required. The pattern must not contain an AttributePattern except as part of an AttributeQualifier.

The xsl:number element does numbering based on the position of the current node in the source tree.

The xsl:number element can have the following attributes:

In addition the xsl:number element has the attributes specified in for number to string conversion.

The xsl:number element first constructs a list of positive integers using the level, count and from attributes:

The list of numbers is then converted into a string using the attributes specified in ; when used with xsl:number the value of each of these attributes is interpreted as an attribute value template. After conversion, the resulting string is inserted in the result tree.

The following would number the items in an ordered list:

The following two rules would number title elements. This is intended for a document that contains a sequence of chapters followed by a sequence of appendices, where both chapters and appendices contain sections which in turn contain subsections. Chapters are numbered 1, 2, 3; appendices are numbered A, B, C; sections in chapters are numbered 1.1, 1.2, 1.3; sections in appendices are numbered A.1, A.2, A.3.

The following example numbers notes sequentially within a chapter:

The following example would number H4 elements in HTML with a three-part label:

The following attributes are used to control conversion of a list of numbers into a string. The numbers are integers greater than 0. The attributes are all optional.

The main attribute is format. The default value for the format attribute is 1. The format attribute is split into a sequence of tokens where each token is a maximal sequence of alphanumeric characters or a maximal sequence of non-alphanumeric characters. The alphanumeric tokens (format tokens) specify the format to be used for each number in the list; the non-alphanumeric tokens (separator tokens) specify the separators used to join numbers in the list. Alphanumeric means any character that has a Unicode category of Nd, Nl, No, Lu, Ll, Lt, Lm or Lo. If the first token is a separator token, then the constructed string will start with that token; if the last token is a separator token, then the constructed string will end with that token. The n-th format token will be used to format the n-th number in the list. If there are more numbers than format tokens, then the last format token will be used to format remaining numbers. The format token specifies the string to be used to represent the number 1. If there are more than n numbers, then the n-th number will be separated from the following number by the separator token following the n-th format token; if there is no such separator token, then the last separator token will be used; if there are no separator tokens, then . will be used.

Format tokens are a superset of the allowed values for the type attribute for the OL element in HTML 4.0 and are interpreted as follows:

When numbering with an alphabetic sequence, the xml:lang attribute specifies which language's alphabet is to be used.

The letter-value attribute disambiguates between numbering schemes that use letters. In many languages there are two commonly used numbering schemes that use letters. One numbering scheme assigns numeric values to letters in alphabetic sequence, and the other assigns numeric values to each letter in some other manner. In English, these would correspond to the numbering sequences specified by the format tokens a and i. In some languages the first member of each sequence is the same, and so the format token alone would be ambiguous. A value of alphabetic specifies the alphabetic sequence; a value of other specifies the other sequence.

The digit-group-sep attribute gives the separator between groups of digits, and the optional n-digits-per-group specifies the number of digits per group. For example, digit-group-sep="," and n-digits-per-group="3" would produce numbers of the form 1,000,000.

The sequence-src attribute gives the URI of a text resource that contains a whitespace separated list of the members of the numbering sequence.

Here are some examples of conversion specifications:

There are two instructions in XSL which support conditional processing in a template: xsl:if and xsl:choose. The xsl:if instruction provides simple if-then conditionality; the xsl:choose instruction supports selection of one choice when there are several possibilities.

Within a template, the xsl:value-of element can be used to compute generated text, for example by extracting text from the source tree or by inserting the value of a string constant. The xsl:value-of element does this with a string expression that is specified as the value of the expr attribute. String expressions can also be used inside attribute values of literal result elements by enclosing the string expression in curly brace ({}).

Attribute Value Templates

In an attribute value that is interpreted as an attribute value template, such as an attribute of a literal result element, string expressions can be used by surrounding the string expression with curly braces ({}). The attribute value template is instantiated by replacing the string expression together with surrounding curly braces by the value of the string expression.

The following example creates an IMG result element from a photograph element in the source; the value of the SRC attribute of the IMG element is computed from the value of the image-dir constant and the content of the href child of the photograph element; the value of the WIDTH attribute of the IMG element is computed from the value of the the width attribute of the size child of the photograph element:

]]>

With this source

headquarters.jpg ]]>

the result would be

]]>

When an attribute value template is instantiated, a double left or right curly brace outside a string expression will be replaced by a single curly brace. It is an error if a right curly brace occurs in an attribute value template outside a string expression without being followed by a second right curly brace; an XSL processor may signal the error or recover by treating the right curly brace as if it had been doubled. A right curly brace inside an AttributeValue in a string expression is not recognized as terminating the string expression.

Curly braces are not recognized recursively inside string expressions. For example:

]]>

is not allowed.

Global string constants may be defined using a define-constant element. The name attribute specifies the name of the constant, and the value attribute specified the value.

A stylesheet must not contain more than one definition of a constant with the same name and same importance. A definition of a constant will not be used if there is another definition of a constant with the same name and higher importance.

String constants are referenced using a ConstantRef string expression.

The value attribute is interpreted as an attribute value template. If the value of a constant definition x references a constant y, then the value for y must be computed before the value of x. It is an error if it is impossible to do this for all constant definitions because of dependency cycles.

Parts of templates can also be factored out of similar rules into macros for reuse. Macros allow authors to create aggregate result fragments and refer to the composite as if it were a single object. In this example, a macro is defined for a boxed paragraph with the word Warning! preceding the contents. The macro is referenced from a rule for warning elements.

Macros are defined using the define-macro element. The name attribute specifies the name of the macro being defined. The content of the define-macro element is a template, called the body of the macro. A macro is invoked using the xsl:invoke element; the content of xsl:invoke is a template. The name of the macro to be invoked is given by the macro attribute. Invoking a macro first instantiates the content of xsl:invoke. It then instantiates the body of the invoked macro passing it the result tree fragment created by the instantiation of the content of xsl:invoke; this fragment can be inserted in the body of the macro using the xsl:contents element.

Macros allow named arguments to be declared with the xsl:macro-arg element; the name attribute specifies the argument name, and the optional default attribute specifies the default value for the argument. Within the body of a macro, macro arguments are referenced using a MacroArgRef string expression. It is an error to refer to a macro argument that has not been declared. An XSL processor may signal the error; if it does not signal the error, it must recover by using an empty string. Arguments are supplied to a macro invocation using the code xsl:arg element; the name attribute specifies the argument name, and the value attribute specifies the argument value. It is an error to supply an argument to a macro invocation if the macro did not declare an argument of that name. An XSL processor may signal the error; if it does not signal the error, it must recover by ignoring the argument. The value attribute of xsl:arg and the default attribute of xsl:macro-arg are interpreted as attribute value templates; they can contain string expressions in curly braces as with literal result elements.

This example defines a macro for a numbered-block with an argument to control the format of the number.

It is an error if a stylesheet contains more than one definition of a macro with the same name and same importance. An XSL processor may signal the error; if it does not signal the error, if must recover by choosing from amongst the definitions with highest importance the one that occurs last in the stylesheet.

An XSL stylesheet may contain xsl:import elements. All the xsl:import elements must occur at the beginning of the stylesheet. The xsl:import element has an href attribute whose value is the URI of a stylesheet to be imported. A relative URI is resolved relative to the base URI of the xsl:import element (see ).

Rules and definitions in the importing stylesheet are defined to be more important than rules and definitions in any imported stylesheets. Also rules and definitions in one imported stylesheet are defined to be more important than rules and definitions in previous imported stylesheets.

In general a more important rule or definition takes precedence over a less important rule or definition. This is defined in detail for each kind of rule and definition.

An XSL stylesheet may include another XSL stylesheet using an xsl:include element. The xsl:include element has an href attribute whose value is the URI of a stylesheet to be included. A relative URI is resolved relative to the base URI of the xsl:include element (see ). The xsl:include element can occur as the child of the xsl:stylesheet element at any point after all xsl:import elements.

The inclusion works at the XML tree level. The resource located by the href attribute value is parsed as an XML document, and the children of the xsl:stylesheet element in this document replace the xsl:include element in the including document. Also any xsl:import elements in the included document are moved up in the including document to after any existing xsl:import elements in the including document. Unlike with xsl:import, the fact that rules or definitions are included does not affect the way they are processed.

Normally an XSL stylesheet is a complete XML document with the xsl:stylesheet element as the document element. However an XSL stylesheet may also be embedded in another resource. Two forms of embedding are possible:

In the second case, the possibility arises of documents with inline style, that is documents that specify their own style. XSL does not define a specific mechanism for this. This is because this can be done by means of a general purpose mechanism for associating stylesheets with documents provided that:

It is not in the scope of XSL to define such a mechanism.

The xsl:stylesheet element may have an ID attribute that specifies a unique identifier.

The following example shows how inline style can be accomplished using the xml:stylesheet processing instruction mechanism for associating a stylesheet with an XML document. The URI uses an XPointer in a fragment identifier to locate the xsl:stylesheet element.