Extensible Stylesheet Language (XSL)

2.4.1 Root Node

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.

2.4.2 Element Nodes

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 [W3C XML Names]); 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.

<xsl:id attribute="name"/>

2.4.3 Attribute Nodes

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 [W3C XML Names]); 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 [W3C XML]. An attribute value whose value is of zero length is not treated specially.

There are no attribute nodes for attributes that declare namespaces (see [W3C XML Names]).

2.4.4 Character Data

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 [W3C XML].

2.4.5 Whitespace Stripping

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:

• The element type of the parent of the character is in the set of whitespace-preserving element types.

• It is part of a chunk that contains at least one non-whitespace character. As in XML, a whitespace character is #x20, #x9, #xD or #xA. A chunk of characters is a maximal sequence of sibling characters without any intervening elements.

• An ancestor element of the character 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 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:

• If the xsl:stylesheet element specifies a default-space attribute with a value of strip, then the set is initially empty. Otherwise the set initially contains all element types that occur in the document.

• The xsl:strip-space element causes an element type to be removed from the set of whitespace-preserving element types. The element attribute gives the name of the element type.

• The xsl:preserve-space element causes an element type to be added to the set whitespace-preserving element types. The element attribute gives the name of the element type.

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.

2.5.1 Conflict Resolution for Template Rules

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

1. First, all matching template rules that are less important than the most important matching template rule or rules are eliminated from consideration.

2. Next, all matching template rules that are less specific (as defined in Section 2.6.11: Specificity) than the most specific matching template rule or rules are eliminated from consideration.

3. Next, all matching template rules that have a lower priority than the matching template rule or rules with the highest priority are eliminated from consideration. The priority of a rule is specified by the priority attribute on the rule. The value of this must be an integer (positive or negative). The default priority is 0. The integer must not be greater than 2147483647 nor less than -2147483648.

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.

2.5.2 Built-in Template Rule

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:

<xsl:template match="*|/">
  <xsl:process-children/>
</xsl:template>

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="*|/".

2.6.1 Alternative Patterns

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:

<xsl:template match="emph | strong">
  <fo:sequence font-weight="bold">
    <xsl:process-children/>
  </fo:sequence>
</xsl:template>

2.6.2 Matching on Element Ancestry

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:

<xsl:template match="chapter/section/title">
  ...
</xsl:template>

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.

<xsl:template match="para//changed">
  ...
</xsl:template>

2.6.3 Anchors

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.

2.6.4 Matching the Root Node

A RootPattern matches the root node (see Section 2.4.1: Root Node).

2.6.5 Matching on Element Types

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

<xsl:template match="first-name">
  ...
</xsl:template>

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.

<xsl:template match="data-samples/*">
  ...
</xsl:template>

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

2.6.6 Qualifiers

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:

<xsl:template match="book[excerpt]/author[attribute(degree)]">
  ...
</xsl:template>

2.6.7 Matching on Children

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

<xsl:template match="book[excerpt]/author">
  ...
</xsl:template>

2.6.8 Matching on Attributes

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 Section 2.4.3: Attribute Nodes).

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

<xsl:template match="list[attribute(compact)]/item">
  ...
</xsl:template>

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

<xsl:template match="list[attribute(liststyle)='enum']/item">
  ...
</xsl:template>

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.

2.6.9 Matching on Position

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:

• first-of-type(). The element must be the first sibling of its type.

• not-first-of-type(). The element must not be the first sibling of its type.

• last-of-type(). The element must be the last sibling of its type.

• not-last-of-type(). The element must not be the last sibling of its type.

• first-of-any(). The element must be the first sibling element of any type.

• not-first-of-any(). The element must not be the first sibling element of any type.

• last-of-any(). The element must be the last sibling element of any type.

• not-last-of-any(). The element must not be the last sibling element of any type.

• only-of-type(). The element must have no element siblings of the same type.

• not-only-of-type(). The element must have one or more element siblings of the same type.

• only-of-any(). The element must have no element siblings at all.

• not-only-of-any(). The element must have one or more element siblings.

The following pattern matches the first item in a list:

<xsl:template match="list/item[first-of-type()]">
  ...
</xsl:template>

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

<xsl:template match="backmatter/appendix[only-of-type()]">
  ...
</xsl:template>

2.6.10 Whitespace in Patterns

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.

2.6.11 Specificity

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:

1. id(employee-of-the-month)

2. employee[attribute(type)='contract',attribute(country)='USA']

3. employee[attribute(type)='contract']

4. employee

5. *

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

<xsl:template match="EMPH|B" priority="1">
  <fo:sequence font-weight="bold"><xsl:process-children/></fo:sequence>
</xsl:template>

is equivalent to

<xsl:template match="EMPH" priority="1">
  <fo:sequence font-weight="bold"><xsl:process-children/></fo:sequence>
</xsl:template>
<xsl:template match="B" priority="1">
  <fo:sequence font-weight="bold"><xsl:process-children/></fo:sequence>
</xsl:template>

2.7.1 Overview

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.

<xsl:template match="chapter/title">
  <fo:rule-graphic/>
  <fo:block space-before="2pt">
    <xsl:text>Chapter </xsl:text>
    <xsl:number/>
    <xsl:text>: </xsl:text>
    <xsl:process-children/>
  </fo:block>
  <fo:rule-graphic/>
</xsl:template>

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.

2.7.2 Literal Result Elements

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.

2.7.3 Named Attribute Sets

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.

<xsl:define-attribute-set name="title-style">
  <xsl:attribute-set font-size="12pt"
                     font-weight="bold"/>
</xsl:define-attribute-set>

<xsl:template match="chapter/heading">
  <fo:block xsl:use="title-style" quadding="start">
    <xsl:process-children/>
  </fo:block>
</xsl:template>

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.

2.7.4 Literal Text in Templates

A template can also contain PCDATA. Each data character in a template remaining after whitespace has been stripped as specified in Section 2.4.5: Whitespace Stripping 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 Section 2.4.5: Whitespace Stripping) but does not affect how the characters are handled by the XSL processor thereafter.

2.7.5 Processing with xsl:process-children

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

<xsl:template match="chapter">
  <fo:block>
    <xsl:process-children/>
  </fo:block>
</xsl:template>

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 Section 2.4.5: Whitespace Stripping 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.

2.7.6 Processing with xsl:process

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:

<xsl:template match="author-group">
  <fo:sequence>
    <xsl:process select="author"/>
  </fo:sequence>
</xsl:template>

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:

<xsl:template match="author-group">
  <fo:sequence>
    <xsl:process select="author/first-name"/>
  </fo:sequence>
</xsl:template>

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.

<xsl:template match="book">
  <fo:block>
    <xsl:process select=".//heading"/>
  </fo:block>
</xsl:template>

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.

<xsl:template match="employee">
  <fo:block>
    Employee <xsl:process select="name"/> belongs to group
    <xsl:process select="ancestor(department)/group"/>
  </fo:block>
</xsl:template>

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:

<xsl:template match="id(cfo)">
  <xsl:process select="name"/> reports to <xsl:process select="id(ceo)/name"/>
</xsl:template>

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.

<xsl:template match="product">
  <TABLE>
    <xsl:process select="sales/domestic"/>
  </TABLE>
  <TABLE>
    <xsl:process select="sales/foreign"/>
  </TABLE>
</xsl:template>

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.

2.7.7 Direct Processing

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

<customers>
  <customer>
    <name>...</name>
    <order>...</order>
    <order>...</order>
  </customer>
  <customer>
    <name>...</name>
    <order>...</order>
    <order>...</order>
  </customer>
</customers>

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

<xsl:template match="/">
  <HTML>
    <HEAD>
      <TITLE>Customers</TITLE>
    </HEAD>
    <BODY>
      <TABLE>
    <TBODY>
      <xsl:for-each select="customers/customer">
        <TR>
          <TH>
        <xsl:process select="name"/>
          </TH>
          <xsl:for-each select="order">
        <TD>
          <xsl:process-children/>
        </TD>
          </xsl:for-each>
        </TR>
      </xsl:for-each>
    </TBODY>
      </TABLE>
    </BODY>
  </HTML>
</xsl:template>

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.

2.7.8 Numbering in the Source Tree

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:

• The level attribute specifies what levels of the source tree should be considered; it has the values single, multi or any. The default is single.

• The count attribute is a match pattern that specifies what elements should be counted at those levels. The count attribute defaults to the element type name of the current node.

• The from attribute is a match pattern that specifies where counting starts from.

In addition the xsl:number element has the attributes specified in Section 2.7.9: Number to String Conversion Attributes for number to string conversion.

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

• When level="single", it goes up to the nearest ancestor (including the current node as its own ancestor) that matches the count pattern, and constructs a list of length one containing one plus the number of preceding siblings of that ancestor that match the count pattern. If there is no such ancestor, it constructs an empty list. If the from attribute is specified, then the only ancestors that are searched are those that are descendants of the nearest ancestor that matches the from pattern.

• When level="multi", it constructs a list of all ancestors of the current node in document order followed by the element itself; it then selects from the list those elements that match the count pattern; it then maps each element of the list to one plus the number of preceding siblings of that element that match the count pattern. If the from attribute is specified, then the only ancestors that are searched are those that are descendants of the nearest ancestor that matches the from pattern.

• When level="any", it constructs a list of length one containing one plus number of elements at any level of the document that start before this node and that match the count pattern. If the from attribute is specified, then only elements after the first element before this element that match the from pattern are considered.

The list of numbers is then converted into a string using the attributes specified in Section 2.7.9: Number to String Conversion Attributes; 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:

<xsl:template match="ol/item">
  <fo:block>
    <xsl:number/><xsl:text>. </xsl:text><xsl:process-children/>
  </fo:block>
<xsl:template>

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.

<xsl:template match="title">
  <fo:block>
     <xsl:number level="multi"
                 count="chapter|section|subsection"
                 format="1.1. "/>
     <xsl:process-children/>
  </fo:block>
</xsl:template>

<xsl:template match="appendix//title">
  <fo:block>
     <xsl:number level="multi"
                 count="appendix|section|subsection"
                 format="A.1. "/>
     <xsl:process-children/>
  </fo:block>
</xsl:template>

The following example numbers notes sequentially within a chapter:

<xsl:template match="note">
  <fo:block>
     <xsl:number level="any" from="chapter" format="(1) "/>
     <xsl:process-children/>
  </fo:block>
</xsl:template>

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

<xsl:template match="H4">
 <fo:block>
   <xsl:number level="any" from="H1" count="H2"/>
   <xsl:text>.</xsl:text>
   <xsl:number level="any" from="H2" count="H3"/>
   <xsl:text>.</xsl:text>
   <xsl:number level="any" from="H3" count="H4"/>
   <xsl:text> </xsl:text>
   <xsl:process-children/>
 </fo:block>
</xsl:template>

2.7.9 Number to String Conversion Attributes

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:

• Any token where the last character has a decimal digit value of 1 (as specified in the Unicode 2.0 character property database), and the Unicode value of preceding characters is one less than the Unicode value of the last character. This generates a decimal representation of the number where each number is at least as long as the format token. Thus a format token 1 generates the sequence 1 2 ... 10 11 12 ..., and a format token 01 generates the sequence 01 02 ... 09 10 11 12 ... 99 100 101.

• A format token A generates the sequence A B C ... Z AA AB AC....

• A format token a generates the sequence a b c ... z aa ab ac....

• A format token i generates the sequence i ii iii iv v vi vii vii ix x ....

• A format token I generates the sequence I II III IV V VI VII VII IX X ....

• Any other format token indicates a numbering sequence that starts with that token. If an implementation does not support a numbering system that starts with that token, it must use a format token of 1.

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:

• format="ア" specifies Katakana numbering

• format="イ" specifies Katakana numbering in the "iroha" order

• format="๑" specifies numbering with Thai digits

• format="א" letter-value="other" specifies "traditional" Hebrew numbering

• format="ა" letter-value="other" specifies Georgian numbering

• format="α" letter-value="other" specifies "classical" Greek numbering

• format="а" letter-value="other" specifies Old Slavic numbering

2.7.10 Conditionals within a Template

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.

<xsl:template match="namelist/name">
  <xsl:process-children/>
  <xsl:if test=".[not-last-of-type()]">, </xsl:if>
</xsl:template>

<xsl:template match="orderedlist/listitem">
  <fo:list-item indent-start='2pi'>
    <fo:list-item-label>
      <xsl:choose>
        <xsl:when test='ancestor(orderedlist/orderedlist)'>
          <xsl:number format="i"/>
        </xsl:when>
        <xsl:when test='ancestor(orderedlist)'>
          <xsl:number format="a"/>
        </xsl:when>
        <xsl:otherwise>
          <xsl:number format="1"/>
        </xsl:otherwise>
      </xsl:choose>
      <xsl:text>. </xsl:text>
    </fo:list-item-label>
    <fo:list-item-body>
      <xsl:process-children/>
    </fo:list-item-body>
  </fo:list-item>
</xsl:template>

2.7.11 Computing Generated Text

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 ({}).

<xsl:template match="person">
  <P>
   <xsl:value-of expr="attribute(first-name)"/>
   <xsl:text> </xsl:text>
   <xsl:value-of expr="attribute(surname)"/>
  </P>
</xsl:template>

<xsl:template match="person">
  <P>
   <xsl:value-of expr="first-name"/>
   <xsl:text> </xsl:text>
   <xsl:value-of expr="surname"/>
  </P>
</xsl:template>

<xsl:template match="procedure">
  <fo:block>
    <xsl:value-of expr="ancestor(*[attribute(security)])/attribute(security)"/>
  </fo:block>
  <xsl:process-children/>
</xsl:template>

<xsl:define-constant name="image-dir" value="/images"/>

<xsl:template match="photograph">
<IMG SRC="{constant(image-dir)}/{href}" WIDTH="{size/attribute(width)}"/>
</xsl:template>

<photograph>
  <href>headquarters.jpg</href>
  <size width="300"/>
</photograph>

<IMG SRC="/images/headquarters.jpg" WIDTH="300"/>

<a href="#{id({attribute(ref)})/title}">

2.7.12 String Constants

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.

<xsl:define-constant name="para-font-size" value="12pt"/>

<xsl:template match="para">
 <fo:block font-size="{constant(para-font-size)}">
   <xsl:process-children/>
 </fo:block>
</xsl:template>

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.

2.7.13 Macros

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.

<xsl:define-macro name="warning-para">
  <fo:box>
    <fo:block>
      <xsl:text>Warning! </xsl:text>
      <xsl:contents/>
    </fo:block>
  </fo:box>
</xsl:define-macro>

<xsl:template match="warning">
  <xsl:invoke macro="warning-para">
    <xsl:process-children/>
  </xsl-invoke>
</xsl:template>

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.

<xsl:define-macro name="numbered-block">
  <xsl:macro-arg name="format" default="1. "/>
  <xsl:number format="{arg(format)}"/>
  <fo:block/>
    <xsl:contents/>
  </fo:block>
</xsl:define-macro>

<xsl:template match="appendix/title">
  <xsl:invoke name="numbered-block">
    <xsl:arg name="format" value="A. "/>
    <xsl:process-children/>
  </xsl:invoke>
</xsl:template>

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.

2.9.1 Stylesheet Import

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 Section 2.4.2.2: Base URI).

<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">
  <xsl:import href="article.xsl"/>
  <xsl:import href="bigfont.xsl"/>
  <xsl:define-attribute-set name="note-style">
    <xsl:attribute-set font-posture="italic"/>
  </xsl:define-attribute-set>
</xsl:stylesheet>

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.

2.9.2 Stylesheet Inclusion

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 Section 2.4.2.2: Base URI). 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.

2.9.3 Embedding Stylesheets

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:

• the XSL 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.

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:

• the mechanism allows a part of a resource to be specified as the stylesheet, for example by using a URI with a fragment identifier, and
• the mechanism can itself can be embedded in the document, for example as a processing instruction.

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.

<?xml version="1.0"?>
<?xml:stylesheet type="text/xsl" href="#id(style1)"?>
<!DOCTYPE doc SYSTEM "doc.dtd">
<doc>
<head>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl" id="style1">
<xsl:import href="doc.xsl"/>
<xsl:template match="id(foo)">
 <fo:block font-weight="bold"><xsl:process-children/></fo:block>
</xsl:template>
</xsl:stylesheet>
</head>
<body>
<para id="foo">
...
</para>
</body>
</doc>