XSL Transformations (XSLT) Version 4.0

2.3 Initiating a Transformation

This document does not specify any application programming interfaces or other interfaces for initiating a transformation. This section, however, describes the information that is supplied when a transformation is initiated. Except where otherwise indicated, the information is required.

The execution of a stylesheet necessarily involves two activities: static analysis and dynamic evaluation. Static analysis consists of those tasks that can be performed by inspection of the stylesheet alone, including the binding of static variables, the evaluation of [xsl:]use-when expressions (see 3.12.3 Conditional Element Inclusion) and shadow attributes (see 3.12.4 Shadow Attributes), and the detection of static errors. Dynamic evaluation consists of tasks which in general cannot be carried out until a source document is available.

Dynamic evaluation is further divided into two activities: priming the stylesheet, and invoking a selected component.

• Priming the stylesheet provides the dynamic context for evaluation, and supplies all the information needed to establish the values of global variables.

• Invoking a component (such as a template or function) causes evaluation of that template or function to produce a result, which is an arbitrary XDM value.

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

  The raw result of the invocation is the immediate result of evaluating the sequence constructor contained in the target template or function, modified by applying the coercion rules to convert the immediate result to the type declared in the as attribute of the xsl:template or xsl:function declaration, if present.

  This raw result may optionally be post-processed to construct a result tree, to serialize the result, or both, as described in 2.3.6 Post-processing the Raw Result.

Implementations may allow static analysis and dynamic evaluation to be initiated independently, so that the cost of static analysis can be amortized over multiple transformations using the same stylesheet. Implementations may also allow priming of a stylesheet and invocation of components to be initiated independently, in which case a single act of priming the stylesheet may be followed by a series of independent component invocations. Although this specification does not require such a separation, this section distinguishes information that is needed before static analysis can proceed, information that is needed to prime the stylesheet, and information that is needed when invoking components.

The language is designed to allow the static analysis of each package to be performed independently of other packages, with only basic knowledge of the properties of components made available by used packages. Beyond this, the specification leaves it to implementations to decide how to organize this process. When packages are not used explicitly, the entire stylesheet is treated as a single package.

3.1 Namespaces

A stylesheet module is typically written as a namespace well-formed XML document: more formally, as described in 3.5 Stylesheet Modules, a stylesheet module takes the form of an XDM tree rooted at an element node.

The names of elements and attributes in source documents and result documents are namespace-qualified names. In addition, as described in 5.1.1 Qualified Names, XSLT uses namespace-qualified names to identify variables, functions, templates, and other components. These names generally use namespace prefixes that are resolved to namespace URIs using a set of prefix-uri namespace bindings.

There are two ways namespace bindings can be established in a stylesheet module:

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

  For example, a namespace declaration of the form xmlns:math="http://www.w3.org/2005/xpath-functions/math establishes a binding of the prefix math to the namespace URI http://www.w3.org/2005/xpath-functions/math, thereby enabling functions in that namespace to be invoked using an expression such as math:sin($theta)

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

  For example, the attribute fixed-namespaces="math map array" establishes bindings for the prefixes math, map, and array to the namespace URIs conventionally associated with these prefixes as described in 5.1.3 Reserved Namespaces.

Prefixes used in element and attribute names in the stylesheet, because these are interpreted by the XML parser and not only by the XSLT processor, must be bound using native namespace bindings. In particular, the XSLT namespace is used in the names of XSLT elements, so it must be declared in every stylesheet module using a namespace declaration such as xmlns:xsl="http://www.w3.org/1999/XSL/Transform. (A different prefix can be used: some users prefer xslt, some favor the default namespace.) But namespace prefixes that are only used within the content of attribute and text nodes in the stylesheet (for example, select="math:sin($theta)") can be declared in fixed namespace bindings.

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

The effect of declaring fixed namespace bindings is described in more detail in 3.6.1 The fixed-namespaces Attribute.

3.7 Simplified Stylesheet Modules

A simplified syntax is allowed for a stylesheet module that defines only a single template rule. A simplified stylesheet module consist of a single instruction or literal result element together with its contents. Such a stylesheet module is equivalent to a standard stylesheet module whose xsl:stylesheet element contains a template rule containing the instruction or literal result element; the template rule has a match pattern of match=".", which matches any item.

<out>{count(//*)}</out>

<xsl:stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
                  version="4.0" expand-text="yes">
    <xsl:template match=".">
        <out>{count(//*)}</out>
    </xsl:template>
</xsl:stylesheet>

A simplified stylesheet can contain XSLT instructions, in which case the XSLT namespace needs to be declared. This is illustrated in the next example.

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xsl:version="4.0">
  <head>
    <title>Expenditure by Tax Rate</title>
  </head>
  <body>
    <table>
      <thead>
        <tr>
           <th>Gross Amount</th>
           <th>Tax Rate</th>
        </tr>
      </thead>
      <tbody>
        <xsl:for-each-group select="//transaction" group-by="vat-rate">
          <tr>
            <td>{sum(current-group()/value)}</td>
            <td>{current-grouping-key()}</td>
          </tr>
        </xsl:for-each-group>
      </tbody>
    </table>
  </body>
</html>

<xsl:result-document method="json" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:array>
    <xsl:for-each select="?*">
      <xsl:record first="?firstName" 
                  last="?surname"
                  phone="?mobile"/>
    </xsl:for-each>
  </xsl:array>
</xsl:result-document>

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, invoking the transformation by calling the named templateexpand, with the outermost element as the context node:

<xsl:stylesheet version="4.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"&gt;

<xsl:template name="expand">
  <xsl:element name="xsl:stylesheet">
    <xsl:variable name="version"
        select="(if (self::xsl:*) then @version else @xsl:version)
                   otherwise '4.0'"/>
    <xsl:attribute name="version" select="$version"/>
    <xsl:attribute name="expand-text" 
                   select="not(number($version) le 3.0)"/>
    <xsl:element name="xsl:template">
      <xsl:attribute name="match" select="'.'"/>
      <xsl:copy-of select="."/>
    </xsl:element>
  </xsl:element>
</xsl:template>

</xsl:stylesheet>

The allowed content of an instruction or literal result element when used as a simplified stylesheet is the same as when it occurs within a sequence constructor. Thus, a simplified stylesheet cannot contain declarations. In particular, simplified stylesheets therefore cannot use template rules, global variables, stylesheet parameters, stylesheet functions, keys, attribute-sets, or output definitions. Furthermore, they cannot contain xsl:include, xsl:import, or xsl:use-package declarations.

The only useful way to initiate the transformation is to supply an item as the initial match selection, to be matched by the implicit match="." template rule using the unnamed mode.

3.12 Stylesheet Preprocessing

This specification provides three features that cause the raw stylesheet to be preprocessed as the first stage of static processing: This specification provides several features that cause the raw stylesheet to be preprocessed as the first stage of static processing: This specification provides threeseveral features that cause the raw stylesheet to be preprocessed as the first stage of static processing:

• Whitespace and commentary are stripped (see 3.12.1 Stripping Whitespace and Commentary from the Stylesheet).

• Any xsl:note elements are removed: see 3.12.2 The xsl:note element.

• Any xsl:note elements are removed: see 3.12.2 The xsl:note element.

• Elements may be conditionally included or excluded by means of an [xsl:]use-when attribute as described in 3.12.3 Conditional Element Inclusion.

• Attributes may be conditionally computed as described in 3.12.4 Shadow Attributes.

Note that many of the rules affecting the validity of stylesheet documents apply to a stylesheet after this preprocessing phase has been carried out.

5.3 The Static and Dynamic Context

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

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

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

The following four sections describe:

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

6.7 Modes

[Definition:  A mode is a set of template rules; when the xsl:apply-templates instruction selects a set of items for processing, it identifies the rules to be used for processing those items by nominating a mode, explicitly or implicitly.] Modes allow a node in a source tree (for example) to be processed multiple times, each time producing a different result. They also allow different sets of template rules to be active when processing different trees, for example when processing documents loaded using the document function (see 20.1 fn:document).

Modes are identified by an expanded QName; in addition to any named modes, there is always one unnamed mode available. Whether a mode is named or unnamed, its properties may be defined in an xsl:mode declaration. If a mode name is used (for example in an xsl:template declaration or an xsl:apply-templates instruction) and no declaration of that mode appears in the stylesheet, the mode is implicitly declared with default properties.

6.8 Built-in Template Rules

When an item is selected by xsl:apply-templates and there is no user-specified template rule in the stylesheet that can be used to process that item, then a built-in template rule is evaluated instead.

The built-in template rules have lower import precedence than all other template rules. Thus, the stylesheet author can override a built-in template rule by including an explicit template rule.

There are seven sets of built-in template rules available. The set that is chosen is a property of the mode selected by the xsl:apply-templates instruction. This property is set using the on-no-match attribute of the xsl:mode declaration, which takes one of the values deep-copy, shallow-copy, shallow-copy-all,deep-skip, shallow-skip, text-only-copy, or fail, the default being text-only-copy. The effect of these seven sets of built-in template rules is explained in the following subsections.

<xsl:array use="?value">
  <xsl:apply-templates select="array:members(.)" mode="#current"/>
</xsl:array>

<xsl:map>
  <xsl:apply-templates select="map:entries(.)" mode="#current"/>
</xsl:map>

<xsl:map-entry key="map:keys(.)">
  <xsl:apply-templates select="map:items(.)" mode="#current"/>
</xsl:map-entry>

<xsl:stylesheet version="3.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
				  
<xsl:mode on-no-match="shallow-copy-all"/>

<xsl:template match="record(Note)">
  <!-- no action -->
</xsl:template>

</xsl:stylesheet>

[
  { "Title": "Computer Architecture",
    "Authors": [ "Enid Blyton", { "Note": "possibly misattributed" } ],
    "Category": "Computers",
    "Price": 42.60
  },
  { "Title": "Steppenwolf",
    "Authors": [ "Hermann Hesse" ],
    "Category": "Fiction",
    "Price": 12.00,
    "Note": "out of print"
  },
  { "Title": "How to Explore Outer Space with Binoculars",
    "Authors": [ "Bruce Betts", "Erica Colon" ],
    "Category": "Science",
    "Price": 10.40
  }
]

<xsl:template match="document-node()|element()" mode="M">
  <xsl:apply-templates select="@*" mode="#current"/>
  <xsl:apply-templates mode="#current"/>
</xsl:template>

<xsl:template match="." mode="M"/>

<xsl:template match=".[. instance of array(*)]" mode="M">
  <xsl:apply-templates mode="#current" select="?*"/>
</xsl:template>

7.1 The xsl:for-each instruction

<!-- Category: instruction -->
<xsl:for-each
  select = expression
  separator? = { string } >
  <!-- Content: (xsl:sort*, sequence-constructor) -->
</xsl:for-each>

The xsl:for-each instruction processes each in a sequence of items, evaluating the sequence constructor within the xsl:for-each instruction once for each item in that sequence.

The select attribute is required; it contains an expression which is evaluated to produce a sequence, called the input sequence. If there is an xsl:sort element present (see 13 Sorting) the input sequence is sorted to produce a sorted sequence. Otherwise, the sorted sequence is the same as the input sequence.

The xsl:for-each instruction contains a sequence constructor. The sequence constructor is evaluated once for each item in the sorted sequence, with the focus set as follows:

• The context item is the item being processed.

• The context position is the position of this item in the sorted sequence.

• The context size is the size of the sorted sequence (which is the same as the size of the input sequence).

For each item in the input sequence, evaluating the sequence constructor produces a sequence of items (see 5.7 Sequence Constructors). These output sequences are concatenated; if item Q follows item P in the sorted sequence, then the result of evaluating the sequence constructor with Q as the context item is concatenated after the result of evaluating the sequence constructor with P as the context item. The result of the xsl:for-each instruction is the concatenated sequence of items.

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

<xsl:template match="/">
  <html>
    <head>
      <title>Customers</title>
    </head>
    <body>
      <table>
	 <tbody>
	  <xsl:for-each select="customers/customer">
	    <tr>
	      <th>
           <xsl:apply-templates select="name"/>
	      </th>
	      <xsl:for-each select="order">
           <td>
             <xsl:apply-templates/>
           </td>
	      </xsl:for-each>
	    </tr>
	  </xsl:for-each>
	</tbody>
      </table>
    </body>
  </html>
</xsl:template>

[
  { "city": "London", "latitude": 51.5099, "longitude": -0.1181 },
  { "city": "Paris",  "latitude": 48.8647, "longitude": 2.3488 },
  { "city": "Berlin", "latitude": 52.5200, "longitude": 13.4049 }                  
]

<xsl:for-each select="json-doc('input.json')?*">
   <xsl:sort select="?city"/>
   <city number="{position()}" 
         name="{?city}" 
         latitude="{?latitude}" 
         longitude="{?longitude}"/>
</xsl:for-each>

[
   { "city": "London", "data": [12.3, 15.6, null, 18.2] },
   { "city": "Paris",  "data": [7.9, 19.1, 23.0, null] },
   { "city": "Berlin", "data": [5.6, null, 14.6, 9.5] }                  
]

<cities>
  <city name="London" Q1="12.3" Q2="15.6" Q3="" Q4="18.2"/>
  <city name="Paris" Q1="7.9" Q2="19.1" Q3="23.0" Q4=""/>
  <city name="Berlin" Q1="5.6" Q2="" Q3="14.6" Q4="9.5"/>
</cities>

<xsl:for-each select="json-doc('input.json')?*">
   <city name="{?city}">
     <xsl:for-each select="array:members(?data)">
       <xsl:attribute name="Q{position()}" select="?value"/>
     </xsl:for-each>
   </city>  
</xsl:for-each>

{
  "London": { "latitude": 51.5099, "longitude": -0.1181 },
  "Paris":  { "latitude": 48.8647, "longitude": 2.3488 },
  "Berlin": { "latitude": 52.5200, "longitude": 13.4049 }                  
}

<xsl:for-each select="map:pairs(json-doc('input.json'))">
   <xsl:sort select="?key"/>
   <city number="{position()}" 
         name="{?key}" 
         latitude="{?value?latitude}" 
         longitude="{?value?longitude}"/>
</xsl:for-each>

7.2 The xsl:iterate Instruction

The xsl:iterate instruction processes the items in a sequence in order; unlike xsl:for-each, the result of processing one item can affect the way that subsequent items are processed.

<!-- Category: instruction -->
<xsl:iterate
  select = expression >
  <!-- Content: (xsl:param*, xsl:on-completion?, sequence-constructor) -->
</xsl:iterate>

<!-- Category: instruction -->
<xsl:next-iteration>
  <!-- Content: (xsl:with-param*) -->
</xsl:next-iteration>

<!-- Category: instruction -->
<xsl:break
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:break>

<xsl:on-completion
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:on-completion>

[
  { "date": "2008-09-01", credit: 12.00 },
  { "date": "2008-09-01", credit: 8.00 },
  { "date": "2008-09-02", debit: 2.00 },
  { "date": "2008-09-02", credit: 12.00 }
]

<xsl:iterate select="json-doc('account.json') => array:members()">
   <xsl:param name="balance" as="xs:decimal" select="0"/>               
   <xsl:variable name="delta" select="?value?credit otherwise -?value?debit"/>               
   <entry date="{ ?value?date }"
          amount="{ $delta }"
          balance="{ $balance + $delta }"/>
   <xsl:next-iteration>
      <xsl:with-param name="balance" select="$balance + $delta"/>
   </xsl:next-iteration>   
</xsl:iterate>

<xsl:iterate select="json-doc('account.json')?*">
   <xsl:param name="balance" as="xs:decimal" select="0"/>               
   <xsl:variable name="delta" select="?credit otherwise -?debit"/>               
   <entry date="{ ?date }"
          amount="{ $delta }"
          balance="{ $balance + $delta }"/>
   <xsl:next-iteration>
      <xsl:with-param name="balance" select="$balance + $delta"/>
   </xsl:next-iteration>   
</xsl:iterate>

The select attribute contains an expression which is evaluated to produce a sequence, called the input sequence.

The sequence constructor contained in the xsl:iterate instruction is evaluated once for each item in the input sequence, in order, or until the loop exits by evaluating an xsl:break instruction, whichever is earlier. Within the sequence constructor that forms the body of the xsl:iterate instruction, the context item is set to each item from the value of the select expression in turn; the context position reflects the position of this item in the input sequence, and the context size is the number of items in the input sequence (which may be greater than the number of iterations, if the loop exits prematurely using xsl:break).

The xsl:break and xsl:on-completion elements may have either a select attribute or a non-empty contained sequence constructor but not both. The effect of the element in both cases is obtained by evaluating the select expression if present or the contained sequence constructor otherwise; if neither is present, the value is an empty sequence.The xsl:break and xsl:on-completion elements may have either a select attribute or a non-empty contained sequence constructor but not both. The effect of the element in both cases is obtained by evaluating the select expression if present or the contained sequence constructor otherwise; if neither is present, the value is the empty sequence.The xsl:break and xsl:on-completion elements may have either a select attribute or a non-empty contained sequence constructor but not both. The effect of the element in both cases is obtained by evaluating the select expression if present or the contained sequence constructor otherwise; if neither is present, the value is anthe empty sequence.

The effect of xsl:next-iteration is to cause the iteration to continue by processing the next item in the input sequence, potentially with different values for the iteration parameters. The effect of xsl:break is to cause the iteration to finish, whether or not all the items in the input sequence have been processed. In both cases the affected iteration is the one controlled by the innermost ancestor xsl:iterate element.

The instructions xsl:next-iteration and xsl:break are allowed only as descendants of an xsl:iterate instruction, and only in a tail position within the sequence constructor forming the body of the xsl:iterate instruction.

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

• J is the last instruction in SC, ignoring any xsl:fallback instructions.

• J is in a tail position within the sequence constructor that forms the body of an xsl:if instruction that is itself in a tail position within SC.

• J is in a tail position within the sequence constructor that forms the body of an xsl:when or xsl:otherwise branch of an xsl:chooseor xsl:switch instruction that is itself in a tail position within SC.

• J is in a tail position within the sequence constructor that forms the body of an xsl:try instruction that is itself in a tail position within SC (that is, it is immediately followed by an xsl:catch element, ignoring any xsl:fallback elements).

• J is in a tail position within the sequence constructor that forms the body of an xsl:catch element within an xsl:try instruction that is itself in a tail position within SC.

]

[ERR XTSE3120] It is a static error if an xsl:break or xsl:next-iteration element appears other than in a tail position within the sequence constructor forming the body of an xsl:iterate instruction.

[ERR XTSE3125] It is a static error if the select attribute of xsl:break or xsl:on-completion is present and the instruction has children.

[ERR XTSE3130] It is a static error if the name attribute of an xsl:with-param child of an xsl:next-iteration element does not match the name attribute of an xsl:param child of the innermost containing xsl:iterate instruction.

Parameter names in xsl:with-param must be unique: [see ERR XTSE0670].

The result of the xsl:iterate instruction is the concatenation of the sequences that result from the repeated evaluation of the contained sequence constructor, followed by the sequence that results from evaluating the xsl:break or xsl:on-completion element if any.

Any xsl:param element that appears as a child of xsl:iterate declares a parameter whose value may vary from one iteration to the next. The initial value of the parameter is the value obtained according to the rules given in 9.3 Values of Variables and Parameters. The dynamic context for evaluating the initial value of an xsl:param element is the same as the dynamic context for evaluating the select expression of the xsl:iterate instruction (the context item is thus not the first item in the input sequence).

On the first iteration a parameter always takes its initial value (which may depend on variables or other aspects of the dynamic context). Subsequently:

• If an xsl:next-iteration instruction is evaluated, then parameter values for processing the next item in the input sequence can be set in the xsl:with-param children of that instruction; in the absence of an xsl:with-param element that names a particular parameter, that parameter will retain its value from the previous iteration.

• If an xsl:break instruction is evaluated, no further items in the input sequence are processed.

• If neither an xsl:next-iteration nor an xsl:break instruction is evaluated, then the next item in the input sequence is processed using parameter values that are unchanged from the previous iteration.

The xsl:next-iteration instruction contributes nothing to the result sequence (technically, it returns anthe empty sequence). The instruction supplies parameter values for the next iteration, which are evaluated according to the rules given in 9.10 Setting Parameter Values; if there are no further items in the input sequence then it supplies parameter values for use while evaluating the body of the xsl:on-completion element if any.

The xsl:break instruction indicates that the iteration should terminate without processing any remaining items from the input sequence. The select expression or contained sequence constructor is evaluated using the same context item, position, and size as the xsl:break instruction itself, and the result is appended to the result of the xsl:iterate instruction as a whole.

If neither an xsl:next-iteration nor an xsl:break instruction is evaluated, the next item in the input sequence is processed with parameter values unchanged from the previous iteration; if there are no further items in the input sequence, the iteration terminates.

The optional xsl:on-completion element (which is not technically an instruction and is not technically part of the sequence constructor) is evaluated when the input sequence is exhausted. It is not evaluated if the evaluation is terminated using xsl:break. During evaluation of its select expression or sequence constructor the context item, position, and size are absent (that is, any reference to these values is an error). However, the values of the parameters to xsl:iterate are available, and take the values supplied by the xsl:next-iteration instruction evaluated while processing the last item in the sequence.

If the input sequence is empty, then the result of the xsl:iterate instruction is the result of evaluating the select attribute or sequence constructor forming the body of the xsl:on-completion element, using the initial values of the xsl:param elements. If there is no xsl:on-completion element, the result is an empty sequence.If the input sequence is empty, then the result of the xsl:iterate instruction is the result of evaluating the select attribute or sequence constructor forming the body of the xsl:on-completion element, using the initial values of the xsl:param elements. If there is no xsl:on-completion element, the result is the empty sequence.If the input sequence is empty, then the result of the xsl:iterate instruction is the result of evaluating the select attribute or sequence constructor forming the body of the xsl:on-completion element, using the initial values of the xsl:param elements. If there is no xsl:on-completion element, the result is anthe empty sequence.

8.1 Conditional Processing with xsl:if

<!-- Category: instruction -->
<xsl:if
  test = expression
  then? = expression
  else? = expression〔()〕 >
  <!-- Content: sequence-constructor -->
</xsl:if>

The xsl:if element has a mandatory test attribute, whose value is an expression. The content is a sequence constructor.

If the xsl:if element has a then attribute, then it must have no children. That is, the then attribute and the contained sequence constructor are mutually exclusive.

The result of the xsl:if instruction depends on the effective boolean value^XP of the expression in the test attribute. The rules for determining the effective boolean value of an expression are given in [XPath 4.0]: they are the same as the rules used for XPath conditional expressions.

If the effective boolean value of the expression is true, then:

• If there is a then attribute, the expression in the then attribute is evaluated, and the resulting value is returned as the result of the xsl:if instruction.

• If there is a non-empty sequence constructor, it is evaluated and the resulting value is returned as the result of the xsl:if instruction.

• Otherwise, the result of the xsl:if instruction is anthe empty sequence.

If the effective boolean value of the testexpression is false, then:

• If there is an else attribute, the expression in the else attribute is evaluated, and the resulting value is returned as the result of the xsl:if instruction.

• Otherwise, the result of the xsl:if instruction is anthe empty sequence.

If the test expression has no effective boolean value (for example, if it is a sequence of several integers, or a map), then a dynamic error occurs. (See [ERR FORG0006] ^FO.)

<xsl:template match="namelist/name">
  <xsl:apply-templates/>
  <xsl:if test="not(position()=last())">, </xsl:if>
</xsl:template>

<xsl:template match="namelist/name">
  <xsl:if test="not(position()=1)">, </xsl:if>
  <xsl:apply-templates/> 
</xsl:template>

<xsl:function name="f:product" as="xs:double">
   <xsl:param name="in" as="xs:double*"/>
   <xsl:if test="empty($in)" then="1e0" else="head($in) * f:product(tail($in))"/>
</xsl:function>

8.2 Conditional Processing with xsl:choose

<!-- Category: instruction -->
<xsl:choose>
  <!-- Content: (xsl:when+, xsl:otherwise?) -->
</xsl:choose>

<xsl:when
  test = expression
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:when>

<xsl:otherwise
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:otherwise>

The xsl:choose element selects one among a number of possible alternatives. It consists of a sequence of one or more xsl:when elements followed by an optional xsl:otherwise element. Each xsl:when element has an attribute, test, which specifies an expression used as a condition.

The effective value of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent [see ERR XTSE3185]. If the select attribute is absent and the sequence constructor is empty, then the effective value is an empty sequence.The effective value of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent [see ERR XTSE3185]. If the select attribute is absent and the sequence constructor is empty, then the effective value is the empty sequence.The effective value of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent [see ERR XTSE3185]. If the select attribute is absent and the sequence constructor is empty, then the effective value is anthe empty sequence.

When an xsl:choose element is processed, each of the xsl:when elements is tested in turn (that is, in the order that the elements appear in the stylesheet), until one of the xsl:when elements is satisfied. If none of the xsl:when elements is satisfied, then the xsl:otherwise element is considered, as described below.

An xsl:when element is satisfied if the effective boolean value^XP of the expression in its test attribute is true. The rules for determining the effective boolean value of an expression are given in [XPath 4.0]: they are the same as the rules used for XPath conditional expressions.

The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:choose instruction is an empty sequence.The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:choose instruction is the empty sequence.The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:choose instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:choose instruction is anthe empty sequence.

The select expressions and sequence constructors of xsl:when and xsl:otherwise instructions after the selected one are not evaluated. The test expressions for xsl:when instructions after the selected one are not evaluated.

<xsl:template match="orderedlist/listitem">
  <fo:list-item indent-start='2pi'>
    <fo:list-item-label>
      <xsl:variable name="level"
                    select="count(ancestor::orderedlist) mod 3"/>
      <xsl:choose>
        <xsl:when test='$level=1'>
          <xsl:number format="i"/>
        </xsl:when>
        <xsl:when test='$level=2'>
          <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:apply-templates/>
    </fo:list-item-body>
  </fo:list-item>
</xsl:template>

<xsl:template match="orderedlist/listitem">
  <fo:list-item indent-start='2pi'>
    <fo:list-item-label>
      <xsl:variable name="level"
                    select="count(ancestor::orderedlist) mod 3"/>
      <xsl:variable name="format" as="xs:string">
        <xsl:choose>
          <xsl:when test='$level=1' select="'i'"/>
          <xsl:when test='$level=2' select="'a'"/>
          <xsl:otherwise select="'1'"/>
        </xsl:choose>
      </xsl:variable>  
      <xsl:number format="{ $format }"/>
      <xsl:text>. </xsl:text>
    </fo:list-item-label>
    <fo:list-item-body>
      <xsl:apply-templates/>
    </fo:list-item-body>
  </fo:list-item>
</xsl:template>

8.3 Conditional Processing with xsl:switch

<!-- Category: instruction -->
<xsl:switch
  select = expression >
  <!-- Content: (xsl:when+, xsl:otherwise?, xsl:fallback*) -->
</xsl:switch>

<xsl:when
  test = expression
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:when>

<xsl:otherwise
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:otherwise>

The xsl:switch element selects one among a number of possible alternatives. The select attribute of the xsl:switch element is evaluated to obtain an atomic item, which is compared with the values given by the test attributes of the xsl:when elements, in turn.

The content of the xsl:switch element consists of a sequence of one or more xsl:when elements followed by an optional xsl:otherwise element. Each xsl:when element has an attribute, test, which contains an expression.

The result of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent. If the select attribute is absent and the sequence constructor is empty, then the result is an empty sequence.The result of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent. If the select attribute is absent and the sequence constructor is empty, then the result is the empty sequence.The result of an xsl:when or xsl:otherwise branch may be supplied using either a select attribute or a contained sequence constructor. These are mutually exclusive: if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent. If the select attribute is absent and the sequence constructor is empty, then the result is anthe empty sequence.

Any xsl:fallback children are ignored by an XSLT 4.0 processor, but can be used to define the recovery action to be taken by a processor for an earlier version of XSLT when operating with forwards compatible behavior.

An xsl:switch element is processed as follows:

• The select expression of the xsl:switch element is evaluated.

• The result of the evaluation is converted to a single atomic item by applying the coercion rules; a type error occurs if this conversion is not possible. This value is referred to below as the selector.

• Each of the xsl:when elements is tested in turn (that is, in the order that the elements appear in the stylesheet), until one of the xsl:when elements is satisfied. If none of the xsl:when elements is satisfied, then the xsl:otherwise element is considered, as described below.

  An xsl:when element is tested by first evaluating its test expression and converting the result to a sequence of atomic items by applying the coercion rules, and then comparing this sequence of atomic items with the selector value. The comparison is performed using the rules of the XPath = operator, using the default collation that is in scope for the xsl:switch instruction.

  An xsl:when element is satisfied if the result of this comparison is true.

• The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:switch instruction is an empty sequence.The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:switch instruction is the empty sequence.The first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence (that is, the result of evaluating its select attribute or contained sequence constructor as appropriate) is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, the content of the xsl:otherwise element is evaluated, and the resulting sequence is returned as the result of the xsl:switch instruction. If no xsl:when element is satisfied, and no xsl:otherwise element is present, the result of the xsl:switch instruction is anthe empty sequence.

• The select expressions and sequence constructors of xsl:when and xsl:otherwise instructions after the selected one are not evaluated. The test expressions for xsl:when instructions after the selected one are not evaluated.

<xsl:function name="f:month-name" as="xs:string">
    <xsl:param name="month-number" as="xs:integer"/>
    <xsl:switch select="$month-number">
      <xsl:when test="1" select="'January'"/>
      <xsl:when test="2" select="'February'"/>
      <xsl:when test="3" select="'March'"/>
      <xsl:when test="4" select="'April'"/>
      <xsl:when test="5" select="'May'"/>
      <xsl:when test="6" select="'June'"/>
      <xsl:when test="7" select="'July'"/>
      <xsl:when test="8" select="'August'"/>
      <xsl:when test="9" select="'September'"/>
      <xsl:when test="10" select="'October'"/>
      <xsl:when test="11" select="'November'"/>
      <xsl:when test="12" select="'December'"/>
      <xsl:otherwise select="error('Unknown month')"/>
    </xsl:switch>
  </xsl:function>

<xsl:function name="f:days-in-month" as="xs:integer?">
    <xsl:param name="month-number" as="xs:integer"/>
    <xsl:param name="leap-year" as="xs:boolean"/>
    <xsl:switch select="$month-number">
      <xsl:when test="1, 3, 5, 7, 8, 10, 12" select="31"/>
      <xsl:when test="4, 6, 9, 11" select="30"/>
      <xsl:when test="2">
         <xsl:if test="$leap-year" then="29" else="28"/>
      </xsl:when>
    </xsl:switch>
  </xsl:function>

8.4 Try/Catch

The xsl:try instruction can be used to trap dynamic errors occurring within the expression it wraps; the recovery action if such errors occur is defined using a child xsl:catch element.

<!-- Category: instruction -->
<xsl:try
  select? = expression
  rollback-output? = boolean〔'yes'〕 >
  <!-- Content: (sequence-constructor, xsl:catch, (xsl:catch | xsl:fallback)*) -->
</xsl:try>

<xsl:catch
  errors? = tokens〔'*'〕
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:catch>

An xsl:try instruction evaluates either the expression contained in its select attribute, or its contained sequence constructor, and returns the result of that evaluation if it succeeds without error. If a dynamic error occurs during the evaluation, the processor evaluates the first xsl:catch child element applicable to the error, and returns that result instead.

If the xsl:try element has a select attribute, then it must have no children other than xsl:catch and xsl:fallback. That is, the select attribute and the contained sequence constructor are mutually exclusive. If neither is present, the result of the xsl:try is an empty sequence (no dynamic error can occur in this case).If the xsl:try element has a select attribute, then it must have no children other than xsl:catch and xsl:fallback. That is, the select attribute and the contained sequence constructor are mutually exclusive. If neither is present, the result of the xsl:try is the empty sequence (no dynamic error can occur in this case).If the xsl:try element has a select attribute, then it must have no children other than xsl:catch and xsl:fallback. That is, the select attribute and the contained sequence constructor are mutually exclusive. If neither is present, the result of the xsl:try is anthe empty sequence (no dynamic error can occur in this case).

The rollback-output attribute is described in 8.4.1 Recovery of Result Trees. The default value is yes.

[ERR XTSE3140] It is a static error if the select attribute of the xsl:try element is present and the element has children other than xsl:catch and xsl:fallback elements.

Any xsl:fallback children of the xsl:try element are ignored by an XSLT 3.0 processor, but can be used to define the recovery action taken by an XSLT 1.0 or XSLT 2.0 processor operating with forwards compatible behavior.

The xsl:catch element has an optional errors attribute, which lists the error conditions that the xsl:catch element is designed to intercept. The default value is errors="*", which catches all errors. The value is a whitespace-separated list of NameTests^XP; an xsl:catch element catches an error condition if this list includes a NameTest that matches the error code associated with that error condition.

If more than one xsl:catch element matches an error, the error is processed using the first one that matches, in document order. If no xsl:catch matches the error, then the error is not caught (that is, evaluation of the xsl:try element fails with the dynamic error).

An xsl:catch element may have either a select attribute, or a contained sequence constructor.

[ERR XTSE3150] It is a static error if the select attribute of the xsl:catch element is present unless the element has empty content.

The result of evaluating the xsl:catch element is the result of evaluating the XPath expression in its select attribute or the result of evaluating the contained sequence constructor; if neither is present, the result is an empty sequence. This result is delivered as the result of the xsl:try instruction.The result of evaluating the xsl:catch element is the result of evaluating the XPath expression in its select attribute or the result of evaluating the contained sequence constructor; if neither is present, the result is the empty sequence. This result is delivered as the result of the xsl:try instruction.The result of evaluating the xsl:catch element is the result of evaluating the XPath expression in its select attribute or the result of evaluating the contained sequence constructor; if neither is present, the result is anthe empty sequence. This result is delivered as the result of the xsl:try instruction.

If a dynamic error occurs during the evaluation of xsl:catch, it causes the containing xsl:try to fail with this error. The error is not caught by other sibling xsl:catch elements within the same xsl:try instruction, but it may be caught by an xsl:try instruction at an outer level, or by an xsl:try instruction nested within the xsl:catch.

Within the select expression, or within the sequence constructor contained by the xsl:catch element, a number of variables are implicitly declared, giving information about the error that occurred. These are lexically scoped to the xsl:catch element. These variables are all in the standard error namespace, and they are initialized as described in the following table:

Variables declared within the sequence constructor of the xsl:try element (and not within an xsl:catch) are not visible within the xsl:catch element.

The following additional rules apply to the catching of errors:

1. All dynamic errors occurring during the evaluation of the xsl:try sequence constructor or select expression are caught (provided they match one of the xsl:catch elements).

   Note:

   • This includes errors occurring in functions or templates invoked in the course of this evaluation, unless already caught by a nested xsl:try.

   • It also includes (for example) errors caused by calling the error function, or the xsl:message instruction with terminate="yes", or the xsl:assert instruction, or the xs:error constructor function.

   • It does not include errors that occur while evaluating references to variables whose declaration and initialization is outside the xsl:try.

2. The existence of an xsl:try instruction does not affect the obligation of the processor to raise certain errors as static errors, or its right to choose whether to raise some errors (such as type errors) statically or dynamically. Static errors are never caught.

3. Some fatal errors arising in the processing environment, such as running out of memory, may cause termination of the transformation despite the presence of an xsl:try instruction. This is implementation-dependent.

4. If the sequence constructor or select expression of the xsl:try causes execution of xsl:result-document, xsl:message, or xsl:assert instructions and fails with a dynamic error that is caught, it is implementation-dependent whether these instructions have any externally visible effect. The processor is not required to roll back any changes made by these instructions. The same applies to any side effects caused by extension functions or extension instructions.

5. A serialization error that occurs during the serialization of a secondary result produced using xsl:result-document is treated as a dynamic error in the evaluation of the xsl:result-document instruction, and may be caught (for example by an xsl:try instruction that contains the xsl:result-document instruction). A serialization error that occurs while serializing the principal result is treated as occurring after the transformation has finished, and cannot be caught.

6. A validation error is treated as occurring in the instruction that requested validation. For example, if the stylesheet is producing XHTML output and requests validation of the entire result document by means of the attribute validation="strict" on the instruction that creates the outermost html element, then a validation failure can be caught only at that level. Although the validation error might be detected, for example, while writing a p element at a location where no p element is allowed, it is not treated as an error in the instruction that writes the p element and cannot be caught at that level.

7. A type error may be caught if the processor raises it dynamically; this does not affect the processor’s right to raise the error statically if it chooses.

   The following rules are provided to define which expression is considered to fail when a type error occurs, and therefore where the error can be caught. The general principle is that where the semantics of a construct C place requirements on the type of some subexpression, a type error is an error in the evaluation of C, not in the evaluation of the subexpression.

   For example, consider the following construct:

   <xsl:variable name="v" as="xs:integer">
     <xsl:sequence select="$foo"/>
   </xsl:variable>

   The expected type of the result of the sequence constructor is xs:integer; if the value of variable $foo turns out to be a string, then a type error will occur. It is not possible to catch this by writing:

   <xsl:variable name="v" as="xs:integer">
     <xsl:try>
       <xsl:sequence select="$foo"/>
       <xsl:catch>...</xsl:catch>
     </xsl:try>
   </xsl:variable>

   This fails to catch the error because the xsl:sequence instruction is deemed to evaluate successfully; the failure only occurs when the result of this instruction is bound to the variable.

   A similar rule applies to functions: if the body of a function computes a result which does not conform to the required type of the function result, it is not possible to catch this error within the function body itself; it can only be caught by the caller of the function. Similarly, if an expression used to compute an argument to a function returns a value of the wrong type for the function signature, this is not considered an error in this expression, but an error in evaluating the function call as a whole.

   A consequence of these rules is that when a type error occurs while initializing a global variable (because the initializer returns a value of the wrong type, given the declared type of the variable), then this error cannot be caught.

   Note:

   Because processors are permitted to raise type errors during static analysis, it is unwise to attempt to recover from type errors dynamically. The best strategy is generally to prevent their occurrence. For example, rather than writing $p + 1 where $p is a parameter of unknown type, and then catching the type error that occurs if $p is not numeric, it is better first to test whether $p is numeric, perhaps by means of an expression such as $p instance of my:numeric, where my:numeric is a union type with xs:double, xs:float, and xs:decimal as its member types.

8. The fact that the application tries to catch errors does not prevent the processor from organizing the evaluation in such a way as to prevent errors occurring. For example exists(//a[10 div . gt 5]) may still do an “early exit”, rather than examining every item in the sequence just to see if it triggers a divide-by-zero error.

9. Except as specified above, the optimizer must not rearrange the evaluation (at compile time or at run time) so that expressions written to be subject to the try/catch are evaluated outside its scope, or expressions written to be external to the try/catch are evaluated within its scope. This does not prevent expressions being rearranged, but any expression that is so rearranged must carry its try/catch context with it.

8.5 Conditional Content Construction

The facilities described in this section are designed to make it easier to generate result trees conditionally depending on what is found in the input, without violating the rules for streamability. Although these facilities were introduced to the language specifically to make streaming easier, they are available whether or not streaming is in use, and users have often found them convenient in non-streaming applications.

The facilities are introduced first by example:

<xsl:if test="exists(event)">
  <events>
    <xsl:copy-of select="event"/>
  </events>
</xsl:if>

<xsl:where-populated>
  <events>
    <xsl:copy-of select="event"/>
  </events>
</xsl:where-populated>

<xsl:if test="exists(item-for-sale)">
  <h1>Items for Sale</h1>
</xsl:if>  
<xsl:apply-templates select="item-for-sale"/>
<xsl:if test="exists(item-for-sale)">
  <p>Total value: {accumulator-before('total-value')}</p>
</xsl:if>

<xsl:sequence>
  <xsl:on-non-empty>
    <h1>Items for Sale</h1>
  </xsl:on-non-empty>  
  <xsl:apply-templates select="item-for-sale"/>
  <xsl:on-non-empty>
    <p>Total value: {accumulator-before('total-value')}</p>
  </xsl:on-non-empty>  
</xsl:sequence>

<xsl:apply-templates select="item-for-sale"/>
<xsl:if test="empty(item-for-sale)">
  <p>There are no items for sale.</p>
</xsl:if>

<xsl:sequence>
  <xsl:apply-templates select="item-for-sale"/>
  <xsl:on-empty>
    <p>There are no items for sale.</p>
  </xsl:on-empty>
</xsl:sequence>

For further examples showing the use of these instructions when streaming, see 7 Handling Empty Input^SG.

<xsl:where-populated expand-text="yes">
  <ul class="my-list">
    <xsl:for-each select="source-item">
       <li>{.}</li>
    </xsl:for-each>
  </ul>
</xsl:where-populated>

<ol>
  <xsl:attribute name="class" select="numbered-list"/>
  <xsl:sequence>
    <xsl:value-of select="xyz"/>
    <xsl:on-empty select="'The list is empty'"/>
  </xsl:sequence>
</ol>

9.2 Parameters

<!-- Category: declaration -->
<xsl:param
  name = eqname
  select? = expression
  as? = sequence-type
  required? = boolean
  tunnel? = boolean〔'no'〕
  static? = boolean〔'no'〕 >
  <!-- Content: sequence-constructor -->
</xsl:param>

The xsl:param element may be used:

• As a child of xsl:stylesheet or xsl:package, to define a parameter to the transformation. Stylesheet parameters are set by the calling application: see 2.3.2 Priming a Stylesheet.

• As a child of xsl:template to define a parameter to a template, which may be supplied when the template is invoked using xsl:call-template, xsl:apply-templates, xsl:apply-imports or xsl:next-match. Template parameters are set by means of an xsl:with-param child element of the invoking instruction, as described in 9.10 Setting Parameter Values.

• As a child of xsl:function to define a parameter to a stylesheet function, which may be supplied when the function is called from an XPath expression. Function parameters are set either positionally or by keyword by means of the argument list in an XPath function call.

• As a child of xsl:iterate to define a parameter that can vary from one iteration to the next. Iteration parameters always take their default values for the first iteration, and in subsequent iterations are set using an xsl:with-param child of the xsl:next-iteration instruction.

The attributes applicable to xsl:param depend on its parent element in the stylesheet, as defined by the following table:

In the table, the entries for the name, select, and as attributes indicate whether the attribute must appear, is optional, or must be absent; the entries for the required, tunnel, and static attributes indicate the values that are permitted if the attribute is present, with the default value shown in bold. (The value yes can also be written true or 1, while no can also be written false or 0.)

The name attribute is mandatory: it specifies the name of the parameter. The value of the name attribute is an EQName, which is expanded as described in 5.1.1 Qualified Names.

[ERR XTSE0580] It is a static error if the values of the name attribute of two sibling xsl:param elements represent the same expanded QName.

If the xsl:param element has a select attribute, then the sequence constructor must be empty.

The static attribute can take the value yes only on stylesheet parameters, and is explained in 9.5 Global Variables and Parameters.

The optional tunnel attribute may be used to indicate that a parameter is a tunnel parameter. The default is no; the value yes may be specified only for template parameters. Tunnel parameters are described in 10.1.6 Tunnel Parameters

<xsl:param name="n" as="(xs:QName | enum('*'))?"/>

9.3 Values of Variables and Parameters

A variable-binding element may specify the supplied value of a variable or the default value of a parameter in four different ways.

• If the variable-binding element has a select attribute, then the value of the attribute must be an expression and the supplied value of the variable is the value that results from evaluating the expression. In this case, the content of the variable-binding element must be empty.

• If the variable-binding element has empty content and has neither a select attribute nor an as attribute, then the supplied value of the variable is a zero-length string. Thus

  <xsl:variable name="x"/>

  is equivalent to

  <xsl:variable name="x" select="''"/>

• If a variable-binding element satisfies all the following conditions:

  • The element has no select attribute

  • The element has no as attribute

  • The element has non-empty content (that is, the variable-binding element has one or more child nodes)

  • There is no disqualifying element among the element's children.

  then the content of the variable-binding element specifies the supplied value. The content of the variable-binding element is a sequence constructor; a new document is constructed with a document node having as its children the sequence of nodes that results from evaluating the sequence constructor and then applying the rules given in 5.7.1 Constructing Complex Content. The value of the variable is then a singleton sequence containing this document node. For further details, see 9.4 Creating Implicit Document Nodes.

• Otherwise, the supplied value is the sequence that results from evaluating the (possibly empty) sequence constructor contained within the variable-binding element (see 5.7 Sequence Constructors).

These combinations are summarized in the table below.

[ERR XTSE0620] It is a static error if a variable-binding element has a select attribute and has non-empty content.

<xsl:variable name="i" as="xs:integer*" select="1 to 3"/>

<xsl:variable name="i" as="xs:integer" select="@size"/>

<xsl:variable name="z"/>

<xsl:variable name="doc"><c/></xsl:variable>

<xsl:variable name="seq" as="xs:integer*">
  <xsl:for-each select="1 to 3">
    <xsl:sequence select=".*2"/>
  </xsl:for-each>
</xsl:variable>

<xsl:variable name="attset" as="attribute()+">
  <xsl:attribute name="x">2</xsl:attribute>
  <xsl:attribute name="y">3</xsl:attribute>
  <xsl:attribute name="z">4</xsl:attribute>    
</xsl:variable>

<xsl:variable name="empty" as="empty-sequence()"/>

The actual value of the variable depends on the supplied value, as described above, and the required type, which is determined by the value of the as attribute.

<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="td[$n]"/>

<xsl:variable name="n" select="2"/>
...
<xsl:value-of select="td[$n]"/>

<xsl:variable name="n">2</xsl:variable>
...
<xsl:value-of select="td[position()=$n]"/>

<xsl:variable name="n" as="xs:integer">2</xsl:variable>
...
<xsl:value-of select="td[$n]"/>

9.8 Local Variables and Parameters

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

An xsl:param element may also be used to create a variable binding with local scope:

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

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

• An xsl:param element may appear as a child of an xsl:iterate instruction, before any non-xsl:param children of that element. This defines a parameter whose value may be initialized on entry to the iteration, and which may be varied each time round the iteration by use of an xsl:with-param element in the xsl:next-iteration instruction.

The result of evaluating a local xsl:variable or xsl:param element (that is, the contribution it makes to the result of the sequence constructor it is part of) is anthe empty sequence.

10.3 Stylesheet Functions

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

<!-- Category: declaration -->
<xsl:function
  name = eqname
  as? = sequence-type〔'item()*'〕
  visibility? = "public" | "private" | "final" | "abstract"〔'private'〕
  streamability? = "unclassified" | "absorbing" | "inspection" | "filter" | "shallow-descent" | "deep-descent" | "ascent" | eqname〔'unclassified'〕
  override-extension-function? = boolean〔'yes'〕
  [override]? = boolean〔'yes'〕
  new-each-time? = "yes" | "true" | "1" | "no" | "false" | "0" | "maybe"
  cache? = boolean〔'no'〕 >
  <!-- Content: (xsl:param*, sequence-constructor) -->
</xsl:function>

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

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

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

• The xsl:function/@name attribute defines the function’s name.

• The xsl:param children define the function’s parameters:

  • The xsl:param/@name attribute defines the name of the parameter.

  • The xsl:param/@required attribute determines whether the parameter is mandatory or optional.

  • The xsl:param/@as attribute determines the required type of the parameter.

  • The xsl:param/@select attribute determines a default value for an optional parameter.

• The xsl:function/@as attribute defines the return type of the function.

• The implementation of the function is defined by the sequence constructor content of the xsl:function element.

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

<xsl:function name="f:compare" as="xs:boolean">
  <xsl:param name="arg1" as="xs:double"/>
  <xsl:param name="arg2" as="xs:double"/>
  <xsl:param name="options" as="map(*)" 
             required="no" 
             select="{ 'order': 'ascending' }"/>
  <xsl:if test="$options?order = 'descending'" 
          then="$arg1 gt $arg2" 
          else="$arg2 gt $arg1"/>
</xsl:function>

10.4 Static XPath Evaluation

The two instructions described in this section, xsl:sequence and xsl:select, can be used to evaluate XPath expressions that are statically known: that is, the XPath expressions are statically processed during the static processing of the stylesheet, and are dynamically evaluated during the dynamic evaluation of the stylesheet. The xsl:sequence instruction can also be used to evaluate a sequence constructor.

<xsl:variable name="values" as="xs:integer*">
    <xsl:sequence select="(1,2,3,4)"/>
    <xsl:sequence select="(8,9,10)"/>
</xsl:variable>
<xsl:value-of select="sum($values)"/>

<xsl:variable name="prices" as="xs:decimal*">
   <xsl:for-each select="//product">
      <xsl:sequence select="@price otherwise @cost * 1.5" as="xs:decimal"/>
   </xsl:for-each>
</xsl:variable>

<xsl:sequence select="//product/(+@price otherwise @cost*1.5))"/>

<xsl:select>//product/(+@price otherwise @cost*1.5))</xsl:select>

11.9 Copying Nodes

13.2 Creating a Sorted Sequence

<!-- Category: instruction -->
<xsl:perform-sort
  select? = expression >
  <!-- Content: (xsl:sort+, sequence-constructor) -->
</xsl:perform-sort>

The xsl:perform-sort instruction is used to return a sorted sequence.

The initial sequence is obtained either by evaluating the select attribute or by evaluating the contained sequence constructor (but not both). If there is no select attribute and no sequence constructor then the initial sequence (and therefore, the sorted sequence) is an empty sequence.The initial sequence is obtained either by evaluating the select attribute or by evaluating the contained sequence constructor (but not both). If there is no select attribute and no sequence constructor then the initial sequence (and therefore, the sorted sequence) is the empty sequence.The initial sequence is obtained either by evaluating the select attribute or by evaluating the contained sequence constructor (but not both). If there is no select attribute and no sequence constructor then the initial sequence (and therefore, the sorted sequence) is anthe empty sequence.

[ERR XTSE1040] It is a static error if an xsl:perform-sort instruction with a select attribute has any content other than xsl:sort and xsl:fallback instructions.

The result of the xsl:perform-sort instruction is the result of sorting its initial sequence using its contained sort key specification.

<xsl:function name="local:sort" 
          as="xs:anyAtomicType*">
  <xsl:param name="in" as="xs:anyAtomicType*"/>
  <xsl:perform-sort select="$in">
    <xsl:sort select="."/>
  </xsl:perform-sort>
</xsl:function>

<xsl:function name="bib:books-by-price" 
          as="schema-element(bib:book)*">
  <xsl:param name="in" as="schema-element(bib:book)*"/>
  <xsl:perform-sort select="$in">
    <xsl:sort select="xs:decimal(bib:price)"/>
  </xsl:perform-sort>
</xsl:function>
   ...
   <xsl:copy-of select="bib:books-by-price(//bib:book)
                             [position() = 1 to 5]"/>

14.1 The xsl:for-each-group Element

The xsl:for-each-groupinstruction allows a flat sequence of items to be processed as a sequence of groups, allowing a number of criteria to be used to define the grouping. The instruction may be used anywhere within a sequence constructor.

<!-- Category: instruction -->
<xsl:for-each-group
  select = expression
  group-by? = expression
  group-adjacent? = expression
  group-starting-with? = pattern
  group-ending-with? = pattern
  split-when? = expression
  merge-when? = expression
  composite? = boolean〔'no'〕
  collation? = { uri } >
  <!-- Content: (xsl:sort*, sequence-constructor) -->
</xsl:for-each-group>

The select attribute contains an expression which is evaluated to produce a sequence, called the population.

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

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

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

A group is never empty. If the population is empty, the number of groups will be zero.

The assignment of items to groups depends on the group-by, group-adjacent, group-starting-with, group-ending-with, split-when,and merge-when attributes.

[ERR XTSE1080] These six attributes are mutually exclusive: it is a static error if none of these attributes is present or if more than one of them is present.

[ERR XTSE1090] It is a static error to specify the collation attribute or the composite attribute if neither the group-by attribute nor the group-adjacent attribute is specified.

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

When calculating grouping keys for an item in the population, the expression contained in the group-by or group-adjacent attribute is evaluated with that item as the context item, with its position in population order as the context position, and with the size of the population as the context size.

If the group-by attribute is present, and if the composite attribute is omitted or takes the value no, then an item in the population may have multiple grouping keys: that is, the group-by expression evaluates to a sequence, and each item in the sequence is treated as a separate grouping key. The item is included in as many groups as there are distinct grouping keys (which may be zero).

If the group-adjacent attribute is used, and if the composite attribute is omitted or takes the value no, then each item in the population must have exactly one grouping key value.

[ERR XTTE1100] It is a type error if the result of evaluating the group-adjacent expression is an empty sequence or a sequence containing more than one item, unless composite="yes" is specified. [ERR XTTE1100] It is a type error if the result of evaluating the group-adjacent expression is the empty sequence or a sequence containing more than one item, unless composite="yes" is specified. [ERR XTTE1100] It is a type error if the result of evaluating the group-adjacent expression is anthe empty sequence or a sequence containing more than one item, unless composite="yes" is specified.

Atomic grouping keys are compared using the rules of the distinct-values function, using the relevant collation. The relevant collation is the collation specified as the effective value of the collation attribute, resolved if relative against the base URI of the xsl:for-each-group element; if there is no collation attribute then the default collation is used. Given this collation, two grouping keys K₁ and K₂ are considered equal if count(distinct-values(($K1, $K2), $collation)) = 1.

Composite grouping keys are equal if they contain the same number of items and the items are pairwise equal when compared according to the rules in the previous paragraph.

[ERR XTDE1110] It is a dynamic error if the collation URI specified to xsl:for-each-group (after resolving against the base URI) is a collation that is not recognized by the implementation. (For notes, [see ERR XTDE1035].)

For more information on collations, see 13.1.3 Sorting Using Collations.

The way in which an xsl:for-each-group element is evaluated depends on which of the six group-defining attributes is present:

• If the group-by attribute is present, the items in the population are examined, in population order. For each item J, the expression in the group-by attribute is evaluated to produce a sequence of zero or more grouping key values. If composite="yes" is specified, there will be a single grouping key, which will in general be a sequence of zero or more atomic items; otherwise, there will be zero or more grouping keys, each of which will be a single atomic item. For each one of these grouping keys, if there is already a group created to hold items having that grouping key value, J is appended to that group; otherwise a new group is created for items with that grouping key value, and J becomes its first member.

  An item in the population may thus be appended to zero, one, or many groups. An item will never be appended more than once to the same group; if two or more grouping keys for the same item are equal, then the duplicates are ignored. An item here means the item at a particular position within the population—if the population contains the same node at several different positions in the sequence then a group may indeed contain duplicate nodes.

  The number of groups will be the same as the number of distinct grouping key values present in the population.

• If the group-adjacent attribute is present, the items in the population are examined, in population order. If an item has the same value for the grouping key as its preceding item within the population (in population order), then it is appended to the same group as its preceding item; otherwise a new group is created and the item becomes its first member.

• If the group-starting-with attribute is present, then its value must be a pattern.

  The items in the population are examined in population order. If an item matches the pattern, or is the first item in the population, then a new group is created and the item becomes its first member. Otherwise, the item is appended to the same group as its preceding item within the population.

• If the group-ending-with attribute is present, then its value must be a pattern.

  The items in the population are examined in population order. If an item is the first item in the population, or if the previous item in the population matches the pattern, then a new group is created and the item becomes its first member. Otherwise, the item is appended to the same group as its preceding item within the population.

• If the split-when attribute is present, then its value must be an expression. This expression is evaluated once for every item in the population except the first. The context item is that item, the context position is its position in the population, and the context size is the size of the population. The expression is supplied with two variables: $group is set to the contents of the current group being constructed, and $next is the next item in the population. If the effective boolean value^XP of the expression is true, then this item forms the start of a new group; if it is false, the item is added to the existing group.

  • The variable $group is implicitly declared, and shadows any other variable of the same name. Its name is in no namespace. Its scope is the split-when expression, and its type is item()+.

  • The variable $next is implicitly declared, and shadows any other variable of the same name. Its name is in no namespace. Its scope is the split-when expression, and its type is item().

  For example:

  • split-when="count($group) = 3" starts a new group whenever the existing group has exactly three members; that is, it partitions the population into groups of size 3 (with the last group being smaller if necessary).

  • split-when="$next[self::h1]" starts a new group whenever an h1 element is encountered. The effect is the same as specifying group-starting-with="h1"

  • split-when="foot($group)/@continued='no'" starts a new group immediately after any element having @continued="no". The effect is the same as specifying group-ending-with="*[@continued='no']"

  • split-when="node-name($group[last()] != node-name($next)" starts a new group whenever the name of an item differs from the name of the previous item. The effect is the same as specifying group-adjacent="node-name(.)".

  • split-when="foot($group)[self::hr] or $next[self::hr]" starts a new group immediately before and immediately after every hr element. (That is, hr elements become singleton groups.)

  • split-when="$next ne foot($group) + 1" starts a new group whenever the current item is not equal to the previous item plus one. For example 1, 2, 5, 6, 7, 10, 11 is grouped as (1, 2), (5, 6, 7), (10, 11).

  • split-when="sum($group/string-length()) gt 40" starts a new group when the sum of the string lengths of the items in the current group exceeds 40.

  • split-when="ends-with(foot($group), '.') and matches($next, '^\p{Lu}')" starts a new group when the last item in the current group ends with "." and the next item starts with a capital letter.

  • split-when="deep-equal(slice($group, -2 to -1), ('', ''))" starts a new group after two consecutive zero-length strings.

  • split-when="count($group) gt 1 and head($group)/@name = foot($group)/@name" starts a new group if the last item in the current group has the same value for @name as the first item in that group (provided they are not the same item).

• If the merge-when attribute is present, then its value must be an expression that is a sequence comparator. [Definition: A sequence comparator is an expression that evaluates two sequences of items and results in a true or false value. ]

  The sequence comparator is supplied with two variables: $group-a and $group-b. Each of these variables is implicitly declared, and shadows any other variable of the same name. Its name is in no namespace. Its scope is the merge-when expression, and its type is item()+.

  The sequence comparator is evaluated not item by item (as with split-when) but group by group. The context item is absent, the context position is the position of the first sequence ($group-a) within the sequence of groups being constructed, and the context size is the number of groups at the moment of evaluation.

  The process begins by creating singleton groups. For each item in the population a group is created, with that item's position as its grouping key, and the item as its only member.

  After the groups are created, they are evaluated pairwise against the sequence comparator. The pairwise comparison begins with the first two groups, then the first and third groups, and so on until the first and last groups, then pairwise comparison moves to the second and third groups, then the second and fourth groups, and so forth. Pairwise comparison proceeds until the next-to-last and last groups are evaluated.

  $group-a is set to the items in the first group in a pair of groups, G₁, and $group-b to the second group, G₂.

  If the effective boolean value^XP of the sequence comparator is true, then all items in G₂ are merged with the items in G₁, preserving original sequence order, and the grouping keys of G₂ are merged with those of G₁, sorted in ascending order. The process of merging two groups is identical to the process described in 15 Merging to merge sequences. Pairwise comparison then restarts from the beginning with the first pair of groups, as described above.

  The process is repeated until it is the case that there is no pair of groups for which the sequence comparator evaluates to true, or there is only one group.

  Every item in the population will be appended to exactly one group.

  Unlike other grouping methods, a group created by merge-when may have more than one grouping key. Although those grouping keys are not significant for the semantics of the grouping operation, they can be used to examine the original population, and they are useful for the merge operation.

  merge-when is most effective for building clusters or networks. For example:

  • merge-when="$group-a/(@id | is-related-to) = $group-b/(@id | is-related-to)" creates groups of elements. In a group with more than one item, each item has at least one other item that it relates to, or that relates to the same item it relates to. That is, each group represents a kind of network cluster.

  • Suppose we have elements containing text units where word tokens of significance are wrapped in children tok elements. merge-when="every $a in $group-a, $b in $group-b satisfies count($a/tok[. = $b/tok]) ge 3" creates groups of possibly related texts. In groups of more than one item, any pair of texts has at least three common word-tokens.

  • merge-when="some $a in $group-a, $b in $group-b satisfies count($a/tok[. = $b/tok]) ge 3" creates groups of related texts, likely less cohesive than in the previous example. In groups of more than one item, every text has at least one other text with which it has three word-tokens in common.

  • merge-when="not($group-a = $group-b)" creates maximal groups of distinct values. For example, 4, 1, 5, 1, 9, 4, 1 is grouped as 4, 1, 5, 9 (with grouping keys 1, 2, 3, 5), 1, 4 (with grouping keys 4, 6), and 1 (with grouping key 7). Note, the first group is always the result of the distinct-values function, and the final group always contains the items that appear most frequently in the original population.

  • In merge-when="count($group-a) le 3 and count(distinct-values(($group-a, $group-b) ! node-name(.))) eq 1" no group has more than three items. Within each group, every item has the same node name. The effect is the same as specifying group-by="node-name(.)" then subgrouping with split-when="count($group) = 3".

  • merge-when="some $a in $group-a, $b in $group-b satisfies tokenize($a/@class) = tokenize($b/@class)" creates groups of elements. In a group with multiple items, every item has at least one other item that has at least one of its tokens in @class.

  • merge-when="some $a in $group-a, $b in $group-b satisfies abs($a - $b) le 2" creates groups of numerals. Each numeral has at least one other numeral where the two differ by two or less. For example, 3, 9, 4, 1, 10, 6 is grouped as (3, 4, 1, 6) (with grouping keys 1, 3, 4, 6) and (9, 10) (with grouping keys 2, 5).

  • merge-when="some $a in $group-a, $b in $group-b satisfies abs($a - $b) le xs:dayTimeDuration('PT2H')" creates groups of time values. Within groups of more than one item, each time value has at least one other time value that is two hours or less apart. For example, xs:time("11:12:00Z"), xs:time("13:24:55Z"), xs:time("09:44:10Z"), xs:time("14:09:22Z"), xs:time("08:16:30Z") is grouped as (xs:time("11:12:00Z"), xs:time("09:44:10Z"), xs:time("08:16:30Z")) (with grouping keys 1, 3, 5) and (xs:time("13:24:55Z"), xs:time("14:09:22Z")) (with grouping keys 2, 4).

  • merge-when="every $a in $group-a, $b in $group-b satisfies (string-to-codepoints($a) = string-to-codepoints($b))" creates groups of strings. In groups with more than one member, each member shares at least one codepoint with every other member. For example, ("animal", "bison", "cat", "dog", "zebra") is grouped as ("animal", "bison", "zebra") (linking letters are a, i, n, and b), ("cat") (although it shares letter a with "animal," the group has already been merged with "bison," which has no common letter with "cat"), and ("dog"). The grouping keys are 1, 2, 5, 3, and 4, respectively.

In all cases the order of items within each group is predictable, and reflects the original population order, in that the items are processed in population order and each item is appended at the end of zero or more groups.

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

The sequence constructor contained in the xsl:for-each-group element is evaluated once for each of the groups, in processing order. The sequences that result are concatenated, in processing order, to form the result of the xsl:for-each-group element. Within the sequence constructor, the context item is the initial item of the relevant group, the context position is the position of this group in the processing order of the groups, and the context size is the number of groups This has the effect that within the sequence constructor, a call on position() takes successive values 1, 2, ... last().

15.1 Terminology for Merging

[Definition: A merge source definition is the definition of one kind of input to the merge operation. It selects zero or more merge input sequences, and it includes a merge key specification to define how the merge key values are computed for each such merge input sequence.] A merge source definition corresponds to an xsl:merge-source element in the stylesheet.

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

[Definition: A merge key specification consists of one or more adjacent xsl:merge-key elements which together define how the merge input sequences selected by a merge source definition are sorted. Each xsl:merge-key element defines one merge key component.] For example, a merge key specification for a log file might specify two merge key components, date and time.

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

[Definition:  For each item in a merge input sequence, a value is computed for each merge key component within the merge key specification. The value computed for an item by using the Nth merge key component is referred to as the Nth merge key value of that item.] A merge key value may be any sequence of atomic items (including an empty sequence).[Definition:  For each item in a merge input sequence, a value is computed for each merge key component within the merge key specification. The value computed for an item by using the Nth merge key component is referred to as the Nth merge key value of that item.] A merge key value may be any sequence of atomic items (including the empty sequence).[Definition:  For each item in a merge input sequence, a value is computed for each merge key component within the merge key specification. The value computed for an item by using the Nth merge key component is referred to as the Nth merge key value of that item.] A merge key value may be any sequence of atomic items (including anthe empty sequence).

[Definition:  The ordered collection of merge key values computed for one item in a merge input sequence (one for each merge key component within the merge key specification) is referred to as a combined merge key value.] Since each merge key value is (in general) a sequence of atomic items, the combined merge key value is modeled as an array of such sequences.

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

15.4 Defining the Merge Keys

The keys on which the input sequences are sorted are referred to as merge keys. If the attribute sort-before-merge has the value yes, the input sequences will be sorted into the correct sequence before the merge operation takes place (alternatively, the processor may use an algorithm that has the same effect as sorting followed by merging). If the attribute is absent or has the value no, then the input sequences must already be in the correct order.

The merge key for each type of input sequence (that is, for each xsl:merge-source element) is defined by a sequence of xsl:merge-key element children of the xsl:merge-source element. Each xsl:merge-key element defines one merge key component. The syntax and semantics of an xsl:merge-key element are closely based on the rules for the xsl:sort element (with minor exceptions noted below; the only difference in syntax is the absence of the stable attribute); the main difference is that xsl:merge-key elements do not cause a sort to take place, they merely declare the existing sort order of the input sequence.

<xsl:merge-key
  select? = expression
  lang? = { language }
  order? = { "ascending" | "descending" }〔'ascending'〕
  collation? = { uri }
  case-order? = { "upper-first" | "lower-first" }
  data-type? = { "text" | "number" | eqname } >
  <!-- Content: sequence-constructor -->
</xsl:merge-key>

The select attribute and the contained sequence constructor are mutually exclusive:

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

The value of Nth item in the merge key of an item J in a merge input sequenceS is computed as follows, where K is the Nth xsl:merge-key element of the relevant xsl:merge-source:

1. If K has a select attribute, then the result of evaluating and atomizing that select expression;

2. If K contains a non-empty sequence constructor, then the result of evaluating and atomizing that sequence constructor;

3. Otherwise, the result of atomizing the context item.

In each case the evaluation uses a singleton focus based on J, or, if streamable="yes" is specified on the xsl:merge-source element, a singleton focus based on a snapshot of J (see 10 Streamable Merging^SG).

The effect of the xsl:merge-key elements is defined in terms of the rules for an equivalent sequence of xsl:sort elements: if the rules for sorting (see 13.1.1 The Sorting Process) with stable="yes" would place an item A before an item B in the sorted sequence produced by the sorting process, then A must precede B in the input sequence to the merging process.

The merge keys of the various input sequences to a merge operation must be compatible with each other, since the merge operation will decide the ordering of the result sequence by comparing merge key values across input sequences. This means that across all the xsl:merge-source children of an xsl:merge instruction:

• Each xsl:merge-source element must have the same number of xsl:merge-key child elements; let this number be N.

• For each integer J in 1..N, consider the set S of xsl:merge-key elements that are in position J among the xsl:merge-key children of their parent xsl:merge-source element. For each attribute A in the set lang, order, collation, case-order, and data-type it must be the case that for any two elements s1 and s2 in S, the effective value of attribute A on s1 is the same as the effective value of attribute A on s2, where two attributes are said to have the same effective value if either (a) both attributes are absent, or (b) both attributes are present and the results of evaluating them (they are attribute value templates) are codepoint-equal. Furthermore, in the case of the collation attribute, the absolute collation URI must be the same after resolving against the base URI.

If any of the attributes lang, order, collation, case-order, or data-type are attribute value templates, then their effective values are evaluated using the focus of the containing xsl:merge instruction.

[ERR XTSE2200] It is a static error if the number of xsl:merge-key children of a xsl:merge-source element is not equal to the number of xsl:merge-key children of another xsl:merge-source child of the same xsl:merge instruction.

[ERR XTDE2210] It is a dynamic error if there are two xsl:merge-key elements that occupy corresponding positions among the xsl:merge-key children of two different xsl:merge-source elements and that have differing effective values for any of the attributes lang, order, collation, case-order, or data-type. Values are considered to differ if they have different effective values. In the case of the collation attribute, the values are compared as absolute URIs after resolving against the base URI. The error may be raised statically if it is detected statically.

[ERR XTDE2220] It is a dynamic error if any input sequence to an xsl:merge instruction contains two items that are not correctly sorted according to the merge key values defined on the xsl:merge-key children of the corresponding xsl:merge-source element, when compared using the collation rules defined by the attributes of the corresponding xsl:merge-key children of the xsl:merge instruction, unless the attribute sort-before-merge is present with the value yes.

[ERR XTTE2230] It is a type error if some item selected by a particular merge key in one input sequence is not comparable using the XPath le operator with the corresponding item selected by the corresponding sort key in another input sequence.

17.1 The xsl:analyze-string Instruction

<!-- Category: instruction -->
<xsl:analyze-string
  select = expression
  regex = { string }
  flags? = { string }〔''〕 >
  <!-- Content: (xsl:matching-substring?, xsl:non-matching-substring?, xsl:fallback*) -->
</xsl:analyze-string>

<xsl:matching-substring
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:matching-substring>

<xsl:non-matching-substring
  select? = expression >
  <!-- Content: sequence-constructor -->
</xsl:non-matching-substring>

The xsl:analyze-string instruction takes as input a string (the result of evaluating the expression in the select attribute), a regular expression (the effective value of the regex attribute), and a set of flags.

If the result of evaluating the select expression is an empty sequence, it is treated as a zero-length string. If the value is not a string, it is converted to a string by applying the coercion rules.If the result of evaluating the select expression is the empty sequence, it is treated as a zero-length string. If the value is not a string, it is converted to a string by applying the coercion rules.If the result of evaluating the select expression is anthe empty sequence, it is treated as a zero-length string. If the value is not a string, it is converted to a string by applying the coercion rules.

The flags attribute may be used to control the interpretation of the regular expression. If the attribute is omitted, the effect is the same as supplying a zero-length string. This is interpreted in the same way as the $flags attribute of the functions matches, replace, and tokenize. Specifically, if it contains the letter m, the match operates in multiline mode. If it contains the letter s, it operates in dot-all mode. If it contains the letter i, it operates in case-insensitive mode. If it contains the letter x, then whitespace within the regular expression is ignored. For more detailed specifications of these modes, see [Functions and Operators 4.0] ([Functions and Operators 4.0] section 6.2 Flags).

<xsl:variable name="regex" 
               expand-text="no">[0-9]{1,5}[a-z]{3}[0-9]{1,2}</xsl:variable>
<xsl:analyze-string regex="{$regex}"....

The xsl:analyze-string instruction may have two child elements: xsl:matching-substring and xsl:non-matching-substring. Both elements are optional, and neither may appear more than once. At least one of them must be present. If both are present, the xsl:matching-substring element must come first.

The content of the xsl:analyze-string instruction must take one of the following forms:

1. A single xsl:matching-substring instruction, followed by zero or more xsl:fallback instructions

2. A single xsl:non-matching-substring instruction, followed by zero or more xsl:fallback instructions

3. A single xsl:matching-substring instruction, followed by a single xsl:non-matching-substring instruction, followed by zero or more xsl:fallback instructions

[ERR XTSE1130] It is a static error if the xsl:analyze-string instruction contains neither an xsl:matching-substring nor an xsl:non-matching-substring element.

Any xsl:fallback elements among the children of the xsl:analyze-string instruction are ignored by an processor supporting XSLT 2.0 or later, but allow fallback behavior to be defined when the stylesheet is used with an XSLT 1.0 processor operating with forwards-compatible behavior.

For the xsl:matching-substring and xsl:non-matching-substring elements, the select attribute and the contained sequence constructor are mutually exclusive [see ERR XTSE3185].

This instruction is designed to process all the non-overlapping substrings of the input string that match the regular expression supplied: that is, the disjoint matching segments^FO that result from processing the input string using the supplied regular expression and the supplied flags.

[ERR XTDE1140] It is a dynamic error if the effective value of the regex attribute does not conform to the required syntax for regular expressions, as specified in [Functions and Operators 4.0]. If the regular expression is known statically (for example, if the attribute does not contain any expressions enclosed in curly brackets) then the processor may raise the error as a static error.

[ERR XTDE1145] It is a dynamic error if the effective value of the flags attribute has a value other than the values defined in [Functions and Operators 4.0]. If the value of the attribute is known statically (for example, if the attribute does not contain any expressions enclosed in curly brackets) then the processor may raise the error as a static error.

Processing proceeds as follows. Let M be the sequence of disjoint matching segments^FO that results from applying the regular expression to the input string, with the given flags, in order of their start position. Between any two adjacent matching segments M₁ and M₂, if the end position of M₁ is not the same as the start position of M₂, insert a non-matching segment comprising the characters from the input string between the end of M₁ and the start of M₂. Similarly, insert a non-matching segment at the start of the sequence if the first matching segment is not positioned at the start of the input, and insert a non-matching segment at the end if the last matching segment is not positioned at the end of the input. The result is a sequence consisting of matching and non-matching segments, that together define a partitioning of the input string.

The instruction then processes each of these segments in turn. For a matching segment, it evaluates the xsl:matching-substring child if it exists. For a non-matching segment, it evaluates the xsl:non-matching-substring if it exists. The child xsl:matching-substring or xsl:non-matching-substring is evaluated by evaluating its select attribute or its contained sequence constructor. The context item for this evaluation is the string value of the matching or non-matching segment (as an instance of xs:string); the context position is the position of this segment within the sequence of matching and non-matching segments, and the context size is the number of segments.

If the xsl:matching-substring or xsl:non-matching-substring child is absent, then processing proceeds as if the element were present with empty content and no select attribute. That is, the corresponding segment produces no output.

23.1 Messages

<!-- Category: instruction -->
<xsl:message
  select? = expression
  terminate? = { boolean }〔'no'〕
  error-code? = { eqname }〔'Q{http://www.w3.org/2005/xqt-errors}XTMM9000'〕 >
  <!-- Content: sequence-constructor -->
</xsl:message>

The xsl:message instruction sends a message in an implementation-defined way. The xsl:message instruction causes the creation of a new document, which is typically serialized and output to an implementation-defined destination. The result of the xsl:message instruction is anthe empty sequence.

The content of the message may be specified by using either or both of the optional select attribute and the sequence constructor that forms the content of the xsl:message instruction.

If the xsl:message instruction contains a sequence constructor, then the sequence obtained by evaluating this sequence constructor is used to construct the content of the new document node, as described in 5.7.1 Constructing Complex Content.

If the xsl:message instruction has a select attribute, then the value of the attribute must be an XPath expression. The effect of the xsl:message instruction is then the same as if a single xsl:copy-of instruction with this select attribute were added to the start of the sequence constructor.

If the xsl:message instruction has no content and no select attribute, then an empty message is produced.

The tree produced by the xsl:message instruction is not technically a final result tree. The tree has no URI and processors are not required to make the tree accessible to applications.

The terminate attribute is interpreted as an attribute value template.

If the effective value of the terminate attribute is yes, then the processormust raise a dynamic error after sending the message. This error may be caught in the same way as any other dynamic error using xsl:catch. The default value is no. Note that because the order of evaluation of instructions is implementation-dependent, this gives no guarantee that any particular instruction will or will not be evaluated before processing terminates.

The optional error-code attribute (also interpreted as an attribute value template) may be used to indicate the error code associated with the message. This may be used irrespective of the value of terminate. The effective value of the error code attribute is expected to be an EQName. If no error code is specified, or if the effective value is not a valid EQName, the error code will have local part XTMM9000 and namespace URI http://www.w3.org/2005/xqt-errors. User-defined error codes should be in a namespace other than http://www.w3.org/2005/xqt-errors. When the value of terminate is yes, the error code may be matched in an xsl:catch element to catch the error and cause processing to continue normally.

[ERR XTMM9000] When a transformation is terminated by use of <xsl:message terminate="yes"/>, the effect is the same as when a dynamic error occurs during the transformation. The default error code is XTMM9000; this may be overridden using the error-code attribute of the xsl:message instruction.

<messages>
  <message name="problem">A problem was detected.</message>
  <message name="error">An error was detected.</message>
</messages>

<xsl:param name="lang" select="'en'"/>
<xsl:variable name="messages"
  select="document(concat('resources/', $lang, '.xml'))/messages"/>

<xsl:template name="localized-message">
  <xsl:param name="name"/>
  <xsl:message select="string($messages/message[@name=$name])"/>
</xsl:template>

<xsl:template name="problem">
  <xsl:call-template name="localized-message">
    <xsl:with-param name="name">problem</xsl:with-param>
  </xsl:call-template>
</xsl:template>

Any dynamic error that occurs while evaluating the select expression or the contained sequence constructor, and any serialization error that occurs while processing the result, does not cause the transformation to fail; at worst, it means that no message is output, or that the only message that is output is one that relates to the error that occurred.

23.2 Assertions

The xsl:assert instruction is used to assert that the value of a particular expression is true; if the value of the expression is false, and assertions are enabled, then a dynamic error occurs.

<!-- Category: instruction -->
<xsl:assert
  test = expression
  select? = expression
  error-code? = { eqname }〔'Q{http://www.w3.org/2005/xqt-errors}XTMM9001'〕 >
  <!-- Content: sequence-constructor -->
</xsl:assert>

By default, assertions are disabled.

An implementation must provide an external mechanism to enable or disable assertion checking. This may work either statically or dynamically, and may be at the level of the stylesheet as a whole, or at the level of an individual package, or otherwise. The detail of such mechanisms is implementation-defined.

If assertion checking is enabled, the instruction is evaluated as follows:

1. The expression in the test attribute is evaluated. If the effective boolean value of the result is true, the assertion succeeds, and no further action is taken. If the effective boolean value is false, or if a dynamic error occurs during evaluation of the expression, then the assertion fails.

2. If the assertion fails, then the effect of the instruction is governed by the rules for evaluation of an xsl:message instruction with the same select attribute, error-code attribute, and contained sequence constructor, and with the value terminate="yes". However, the default error code if the error-code attribute is omitted is XTMM9001 rather than XTMM9000.

   Note:

   To the extent that the behavior of xsl:message is implementation-defined, this rule does not prevent an implementation treating xsl:assert and xsl:message differently.

   Note:

   If evaluation of the test expression fails with a dynamic error, the effect is exactly the same as if the evaluation returns false, including the fact that the instruction fails with error code XTMM9001.

3. If an assertion fails, then the following sibling instructions of the xsl:assert instruction are not evaluated.

   Note:

   This means that xsl:assert can be used (rather like xsl:if and xsl:choose) to prevent subsequent instructions from executing if a particular precondition is not true, which might be useful if the subsequent instructions have side-effects (for example, by calling extension functions) or if they can fail in uncatchable ways (for example, non-terminating recursion). It is worth noting that there are limits to this guarantee. It does not ensure, for example, that when an assertion within a template fails, the following siblings of the xsl:call-template instruction that invokes that template will not be evaluated; nor does it ensure that if an assertion fails while processing the first item of a sequence using xsl:for-each, then subsequent items in the sequence will not be processed.

[ERR XTMM9001] When a transformation is terminated by use of xsl:assert, the effect is the same as when a dynamic error occurs during the transformation. The default error code is XTMM9001; this may be overridden using the error-code attribute of the xsl:assert instruction.

As with any other dynamic error, an error caused by an assertion failing may be trapped using xsl:try: see 8.4 Try/Catch.

The result of the xsl:assert instruction is anthe empty sequence.

<xsl:param name="DEBUG" as="xs:boolean" select="false()" 
           static="yes" required="no"/>
<xsl:function name="f:days-elapsed" as="xs:integer">
  <xsl:param name="date" as="xs:date"/>
  <xsl:assert use-when="$DEBUG" test="$date lt current-date()"/>
  <xsl:sequence select="(current-date() - $since) 
                            div xs:dayTimeDuration('PT1D')"/>
</xsl:function>

An implementation may provide a user option allowing a processor to treat assertions as being true without explicit checking. This option must not be enabled by default. If such an option is in force, the effect of any assertion not being true is implementation-dependent.

24.3 Extension Instructions

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

In XSLT 4.0 it is possible to use extension instructions to invoke named templates: see 10.1.3 Invoking Named Templates using Extension Instructions.

25.1 Creating Secondary Results

<!-- Category: instruction -->
<xsl:result-document
  format? = { eqname }
  href? = { uri }
  select? = expression
  validation? = "strict" | "lax" | "preserve" | "strip"
  type? = eqname
  method? = { "xml" | "html" | "xhtml" | "text" | "json" | "adaptive" | eqname }
  allow-duplicate-names? = { boolean }
  build-tree? = { boolean }
  byte-order-mark? = { boolean }
  canonical? = { boolean }
  cdata-section-elements? = { eqnames }
  doctype-public? = { string }
  doctype-system? = { string }
  encoding? = { string }
  escape-solidus? = { boolean }
  escape-uri-attributes? = { boolean }
  html-version? = { decimal }
  include-content-type? = { boolean }
  indent? = { boolean }
  item-separator? = { string }
  json-lines? = { boolean }
  json-node-output-method? = { "xml" | "html" | "xhtml" | "text" | eqname }
  media-type? = { string }
  normalization-form? = { "NFC" | "NFD" | "NFKC" | "NFKD" | "fully-normalized" | "none" | nmtoken }
  omit-xml-declaration? = { boolean }
  parameter-document? = { uri }
  standalone? = { boolean | "omit" }
  suppress-indentation? = { eqnames }
  undeclare-prefixes? = { boolean }
  use-character-maps? = eqnames
  output-version? = { nmtoken } >
  <!-- Content: sequence-constructor -->
</xsl:result-document>

The xsl:result-document instruction is used to create a secondary result.

The select attribute and the contained sequence constructor are mutually exclusive; if the select attribute is present then the sequence constructor must be empty, and if the sequence constructor is non-empty then the select attribute must be absent [see ERR XTSE3185]. The value of the select attribute or the immediate result of the contained sequence constructor is referred to as the raw result.

As with the principal result of the transformation, a secondary result may be delivered to the calling application in three ways (see 2.3.6 Post-processing the Raw Result):

1. The raw result may be delivered as is.

2. The raw result may be used to construct a final result tree by invoking the process of sequence normalization^SE.

3. The raw result may be serialized to a sequence of octets (which may then, optionally, be saved to a persistent storage location).

The decision whether or not to serialize the raw result depends on the processor and on the way it is invoked. This is implementation-defined, and it is not controlled by anything in the stylesheet.

If the result is not serialized, then the decision whether to return the raw result or to construct a tree depends on the effective value of the build-tree attribute. If the effective value of the build-tree attribute is yes, then a final result tree is created by invoking the process of sequence normalization^SE. Conversely, if the result is serialized, then the decision whether or not to construct a tree depends on the choice of serialization method, and the build-tree attribute is then ignored. For example, with method="xml" a tree is always constructed, whereas with method="json" a tree is never constructed.

The xsl:result-document instruction defines a URI that may be used to identify the secondary result. The instruction may optionally specify the output format to be used for serializing the result.

Technically, the result of evaluating the xsl:result-document instruction is anthe empty sequence. This means it does not contribute anything to the result of the sequence constructor it is part of.

The effective value of the format attribute, if specified, must be an EQName. The value is expanded using the namespace declarations in scope for the xsl:result-document element. The resulting expanded QNamemust match the expanded QName of a named output definition in the stylesheet. This identifies the xsl:output declaration that will control the serialization of the final result tree (see 26 Serialization), if the result tree is serialized. If the format attribute is omitted, the unnamed output definition is used to control serialization of the result tree.

[ERR XTDE1460] It is a dynamic error if the effective value of the format attribute is not a valid EQName, or if it does not match the expanded QName of an output definition in the containing package. If the processor is able to detect the error statically (for example, when the format attribute contains no curly brackets), then the processor may optionally raise this as a static error.

The parameter-document attribute allows serialization parameters to be supplied in an external document. The external document must contain an output:serialization-parameters element with the format described in [Serialization 4.0] section 3.1 Setting Serialization Parameters by Means of a Parameter Document, and the parameters are interpreted as described in that specification.

If present, the effective value of the URI supplied in the parameter-document attribute is dereferenced, after resolution against the base URI of the xsl:result-document element if it is a relative reference. The parameter document should be read during run-time evaluation of the stylesheet. If the location of the stylesheet at development time is different from the deployed location, any relative reference should be resolved against the deployed location. A serialization error occurs if the result of dereferencing the URI is ill-formed or invalid; but if no document can be found at the specified location, the attribute should be ignored.

A serialization parameter specified in the parameter-document takes precedence over a value supplied directly as an attribute of xsl:result-document, which in turn takes precedence over a value supplied in the selected output definition, except that the values of the cdata-section-elements and suppress-indentation attributes are merged in the same way as when multiple xsl:output declarations are merged.

The attributes method, allow-duplicate-names, build-tree, byte-order-markcanonical, cdata-section-elements, doctype-public, doctype-system, encoding, escape-solidusescape-uri-attributes, html-version, indent, item-separator, json-lines, json-node-output-method, media-type, normalization-form, omit-xml-declaration, standalone, suppress-indentation, undeclare-prefixes, use-character-maps, and output-version may be used to override attributes defined in the selected output definition.

With the exception of use-character-maps, these attributes are all defined as attribute value templates, so their values may be set dynamically. For any of these attributes that is present on the xsl:result-document instruction, the effective value of the attribute overrides or supplements the corresponding value from the output definition. This works in the same way as when one xsl:output declaration overrides another. Some of the attributes have more specific rules:

• In the case of cdata-section-elements and suppress-indentation, the value of the serialization parameter is the union of the expanded names of the elements named in this instruction and the elements named in the selected output definition.

• In the case of use-character-maps, the character maps referenced in this instruction supplement and take precedence over those defined in the selected output definition.

• In the case of doctype-public and doctype-system, setting the effective value of the attribute to a zero-length string has the effect of overriding any value for these attributes obtained from the output definition. The corresponding serialization parameter is not set (is “absent”).

• In the case of item-separator, setting the effective value of the attribute to the special value "#absent" has the effect of overriding any value for this attribute obtained from the output definition. The corresponding serialization parameter is not set (is “absent”). It is not possible to set the value of the serialization parameter to the literal 7-character string "#absent".

• In all other cases, the effective value of an attribute actually present on this instruction takes precedence over the value defined in the selected output definition.

In the case of the attributes method, json-node-output-methodcdata-section-elements, suppress-indentation, and use-character-maps, the effective value of the attribute contains an EQName or a space-separated list of EQNames. Where lexical QNames are used in these attributes (whether prefixed or unprefixed), the namespace context is established in the same way as for the corresponding attributes of xsl:output: see 26.2 Serialization parameters.

The output-version attribute on the xsl:result-document instruction overrides the version attribute on xsl:output (it has been renamed because version is available with a different meaning as a standard attribute: see 3.3 Standard Attributes). In all other cases, attributes correspond if they have the same name.

There are some serialization parameters that apply to some output methods but not to others. For example, the indent attribute has no effect on the text output method. If a value is supplied for an attribute that is inapplicable to the output method, its value is not passed to the serializer. The processor may validate the value of such an attribute, but is not required to do so.

The item-separator serialization parameter is used when the raw result is used to construct a result tree by applying sequence normalization, and it is also used when the result tree is serialized. For example, if the sequence constructor delivers a sequence of integers, and the text serialization method is used, then the result of serialization will be a string obtained by converting each integer to a string, and separating the strings using the defined item-separator.

The href attribute is optional. The default value is the zero-length string. The effective value of the attribute must be a URI Reference, which may be absolute or relative. If it is relative, then it is resolved against the base output URI. There may be implementation-defined restrictions on the form of absolute URI that may be used, but the implementation is not required to enforce any restrictions. Any valid relative URI reference must be accepted. Note that the zero-length string is a valid relative URI reference.

If the implementation provides an API to access secondary results, then it must allow a secondary result to be identified by means of the absolutized value of the href attribute. In addition, if a final result tree is constructed (that is, if the effective value of build-tree is yes), then this value is used as the base URI of the document node at the root of the final result tree.

The optional attributes type and validation may be used on the xsl:result-document instruction to validate the contents of a final result tree, and to determine the type annotation that elements and attributes within the final result tree will carry. The permitted values and their semantics are described in 25.4.2 Validating Document Nodes. Any such validation is applied to the document node produced as the result of sequence normalization^SE. If sequence normalization does not take place (typically because the raw result is delivered to the application directly, or because the selected serialization method does not involve sequence normalization) then the validation and type attributes are ignored.

A processormay allow a final result tree to be serialized. Serialization is described in 26 Serialization. However, an implementation (for example, a processor running in an environment with no access to writable filestore) is not required to support the serialization of final result trees. An implementation that does not support the serialization of final result trees may ignore the format attribute and the serialization attributes. Such an implementation must provide the application with some means of access to the (un-serialized) result tree, using its URI to identify it.

Implementations may provide additional mechanisms, outside the scope of this specification, for defining the way in which final result trees are processed. Such mechanisms may make use of the XSLT-defined attributes on the xsl:result-document and/or xsl:output elements, or they may use additional elements or attributes in an implementation-defined namespace.

<xsl:stylesheet
	version="3.0"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:xhtml="http://www.w3.org/1999/xhtml">
	
<xsl:output name="toc-format" method="xhtml" indent="yes"
     doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
     doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/>
            
<xsl:output name="section-format" method="xhtml" indent="no"
     doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
     doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"/>	
	 
<xsl:template match="/">
  <xsl:result-document href="toc.html" 
                       format="toc-format" 
                       validation="strict">
    <html xmlns="http://www.w3.org/1999/xhtml">
      <head><title>Table of Contents</title></head>
      <body>
        <h1>Table of Contents</h1>
        <xsl:for-each select="/*/xhtml:body/(*[1] | xhtml:h1)">
          <p>
            <a href="section{position()}.html">
              <xsl:value-of select="."/>
            </a>
          </p>
        </xsl:for-each>
      </body>
    </html>
  </xsl:result-document>
  <xsl:for-each-group select="/*/xhtml:body/*" group-starting-with="xhtml:h1">
    <xsl:result-document href="section{position()}.html" 
                         format="section-format" validation="strip">  	
      <html xmlns="http://www.w3.org/1999/xhtml">
        <head><title><xsl:value-of select="."/></title></head>
        <body>
          <xsl:copy-of select="current-group()"/>
        </body>
      </html>
    </xsl:result-document>
  </xsl:for-each-group>
</xsl:template>

</xsl:stylesheet>