TransWiki - an Open Translation Project(OTP)

XSL Transformations (XSLT) Version 2.0

W3C Working Draft 12 November 2003

This version:
http://www.w3.org/TR/2003/WD-xslt20-20031112/ (http://www.w3.org/TR/2003/WD-xslt20-20031112/)
Latest version:
http://www.w3.org/TR/xslt20/ (http://www.w3.org/TR/xslt20/)
Previous versions:
http://www.w3.org/TR/2003/WD-xslt20-20030502/ (http://www.w3.org/TR/2003/WD-xslt20-20030502/) http://www.w3.org/TR/2002/WD-xslt20-20021115/ (http://www.w3.org/TR/2002/WD-xslt20-20021115/) http://www.w3.org/TR/2002/WD-xslt20-20020816/ (http://www.w3.org/TR/2002/WD-xslt20-20020816/) http://www.w3.org/TR/2002/WD-xslt20-20020430/ (http://www.w3.org/TR/2002/WD-xslt20-20020430/) http://www.w3.org/TR/2001/WD-xslt20-20011220/ (http://www.w3.org/TR/2001/WD-xslt20-20011220/)
Editor:
Michael Kay, Software AG <Michael.Kay@softwareag.com> (mailto:Michael.Kay@softwareag.com)
This document is also available in these non-normative formats: HTML without revision markings (http://www.w3.org/TR/2003/WD-xslt20-20031112/Overview.html) and HTML with revision markings (http://www.w3.org/TR/2003/WD-xslt20-20031112/Overview-diff.html).

Copyright (http://www.w3.org/Consortium/Legal/ipr-notice#Copyright) © 2003 W3C® (MIT, ERCIM, Keio (http://www.keio.ac.jp/)), All Rights Reserved. W3C liability (http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer), trademark (http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks), document use (http://www.w3.org/Consortium/Legal/copyright-documents) and software licensing (http://www.w3.org/Consortium/Legal/copyright-software) rules apply.

Abstract
摘要

本文档定义了XSLT 2.0的语法与语义。XSLT是一种文档转换语言，它用于将XML文档转换为另一种XML文档。

XSLT 2.0 is designed to be used in conjunction with XPath 2.0, which is defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]. XSLT shares the same data model as XPath 2.0, which is defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)], and it uses the library of functions and operators defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)].

XSLT 2.0是用来与XPath 2.0协同工作的，XPath 2.0的定义在[XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]中。XSLT与XPath 2.0具有相同的数据模型（该数据模型定义在[Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]中）。并且，XSLT使用[Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]中所定义的函数库和操作符。

XSLT 2.0 also includes optional facilities to serialize the results of a transformation, by means of an interface to the serialization component described in [XSLT and XQuery Serialization (http://www.w3.org/TR/xslt20/#serialization-spec)].

借助于在[XSLT and XQuery Serialization (http://www.w3.org/TR/xslt20/#serialization-spec)]中所描述的序列化组件接口，XSLT 2.0还包含了一些对文档的转换结果进行序列化的选项工具。

This document contains hyperlinks to specific sections or definitions within other documents in this family of specifications. These links are indicated visually by a superscript identifying the target specification: for example XP for XPath, DM for the Data Model, FO for Functions and Operators.

本文档中含有一些指向其它文档（这些文档与XSLT在同一规范族）中的某些章节或定义的超链接。这些链接用一个标识目标规范的上标文字来指示。例如，XP表示XPath、DM表示Data Model（数据模型）、FO表示Functions and Operators（函数与操作符）

Status of this Document

本文档状态

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index (http://www.w3.org/TR/) at http://www.w3.org/TR/.
本章描述了在本文档出版时的情况。其他文档可能跟随本文档。当前W3C出版的清单和本技术报告的最新修订可以在后面的网站中找到 W3C technical reports index (http://www.w3.org/TR/) at http://www.w3.org/TR/.

This specification is a Last Call Working Draft of XSLT 2.0. This is a signal that:

• the XSL Working Group believes that it has satisfied its relevant technical requirements;
• the Working Group believes that it has satisfied significant dependencies with other groups;
• other groups are invited to review the document to confirm that these dependencies have been satisfied;
• the Working Group is planning to advance the specification to become a Candidate Recommendation.

The final date for comments on this draft is 15 February 2004. Comments should be sent to public-qt-comments@w3.org (mailto:public-qt-comments@w3.org). Because the same mailing list is also used for comments on XPath 2.0 and XQuery 1.0, it is helpful to include the string [XSLT2.0] in the subject line, together with an originator's reference number that can be used to track progress in dealing with the comment. If possible, please send each comment as a separate email. Archives (http://lists.w3.org/Archives/Public/public-qt-comments/) of the comments and responses are available.
本规范是关于XSLT 2.0 的最后工作草案。这表示本规范已经：

• XSL 工作小组相信，本文档已经满足了相关的技术要求；
• 工作组相信，本文档也满足了其他组的的重要依赖关系的技术要求;
• 其他相关工作组已被邀请参加评审本文档并确认这些重大的依赖关系已经得到满足；
• 工作组计划提升本规范为一候选的解决方案。

关于本草案建议的最后是 2004年2月15日。相关建议应该发送到public-qt-comments@w3.org (mailto:public-qt-comments@w3.org)。由于这个邮件列表同时用于XP蓰2.0 和 XQuery 1.0，所以在主题中注明[XSLT2.0]将大有 帮助，同时加上创始人相关号将能被用于跟踪处理建议的进展情况。 如果可能，请将每个建议以不同的邮件形式发送。 Archives (http://lists.w3.org/Archives/Public/public-qt-comments/)上关于建议和相关的回复现在可以 使用。

The document is published in two versions: one that highlights changes (http://www.w3.org/TR/xslt20/Overview-diff.html) since the previous published Working Draft, and one without change highlighting (http://www.w3.org/TR/xslt20/Overview.html).
本文档已出版2个版本： [http://www.w3.org/TR/xslt20/Overview-diff.html 强调了自从前一个发布 的工作草案变更的版本，和没有强调变更的版本 (http://www.w3.org/TR/xslt20/Overview.html).

As predicted in the previous (May 2003) draft, there are relatively few technical innovations in this draft, but a substantial amount of editorial revision and clarification. The technical changes of note are the ability of many XSLT instructions (for example, xsl:attribute and xsl:value-of) to use a select attribute or a contained sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) interchangeably, and the introduction of tunnel parameters (http://www.w3.org/TR/xslt20/#dt-tunnel-parameter) which allow parameter values to be passed from a high-level template rule to a low-level rule without being declared in all the intermediate templates. Named sort keys and the sort function have been replaced with a new xsl:perform-sort instruction. There have been revisions to the date formatting functions, aligning them with the xsl:number instruction and transferring some of the functionality into xsl:number to make it more widely applicable.

A detailed summary of the changes is included at K.2.4 Changes since the May 2003 draft

一份关于变更的详细摘要包含在 K.2.4 Changes since the May 2003 draft 中。 A detailed summary of the changes is included at K.2.4 Changes since the May 2003 draft

The Working Group has commenced, but has not yet completed, a review of the classification of all error conditions described in this draft. It is likely that this review will cause the classification of some errors to change, for example some errors currently classified as recoverable may change to being non-recoverable, or vice versa. Comments on the classification, or on the general approach to handling of dynamic errors, are welcomed.

The statements in this draft concerning dependencies on other specifications that are not yet Recommendations (notably XML 1.1 and XML Namespaces 1.1) must be regarded as provisional, pending final acceptance of those specifications.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

XSLT 2.0 is a revised version of the XSLT 1.0 Recommendation [XSLT 1.0 (http://www.w3.org/TR/xslt20/#XSLT10)] published on 16 November 1999. The changes made in this document are intended to meet the requirements for XSLT 2.0 described in [XSLT 2.0 Requirements (http://www.w3.org/TR/xslt20/#XSLT20REQ)] and to incorporate fixes for errors (http://www.w3.org/1999/11/REC-xslt-19991116-errata/) that have been detected in XSLT 1.0. A summary of the changes since XSLT 1.0 is included in K Changes from XSLT 1.0.

XSLT 2.0 is designed to be used together with XPath 2.0, which has been developed by the W3C XSL Working Group in collaboration with the XML Query Working Group. The current specification of XPath 2.0 can be found in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

Public discussion of XSL, including XSL Transformations, takes place on the XSL-List (http://www.mulberrytech.com/xsl/xsl-list/index.html) mailing list.

The English version of this specification is the only normative version. However, for translations of this document, see http://www.w3.org/Style/XSL/translations.html (http://www.w3.org/Style/XSL/translations.html).

The development of XSLT is undertaken by the XSL Working Group which is now part of the W3C XML Activity (http://www.w3.org/XML/Activity).

Patent disclosures relevant to this specification may be found on the XSL Working Group's patent disclosure page at http://www.w3.org/Style/XSL/Disclosures.html (http://www.w3.org/Style/XSL/Disclosures.html).

Table of Contents

目录
1 Introduction (http://www.w3.org/TR/xslt20/#introduction) 介绍

    1.1 What is XSLT? (http://www.w3.org/TR/xslt20/#what-is-xslt) 什么是XSLT？
    1.2 What's new in XSLT 2.0? (http://www.w3.org/TR/xslt20/#whats-new-in-xslt2) XSLT 2.0 的新特性

2 Concepts (http://www.w3.org/TR/xslt20/#concepts) 基本概念

    2.1 Terminology (http://www.w3.org/TR/xslt20/#terminology) 术语
    2.2 Notation (http://www.w3.org/TR/xslt20/#notation) 符号
    2.3 Initiating a Transformation (http://www.w3.org/TR/xslt20/#initiating) 转换初始化
    2.4 Executing a Transformation (http://www.w3.org/TR/xslt20/#executing-a-transformation) 执行转换
    2.5 The Stylesheet Evaluation Context (http://www.w3.org/TR/xslt20/#context) 样式评估
        2.5.1 Maintaining Position: the Focus (http://www.w3.org/TR/xslt20/#focus) 位置维护：关注点
        2.5.2 Additional Context Variables (http://www.w3.org/TR/xslt20/#additional-context-variables) 附加上下文变量
    2.6 Parsing and Serialization (http://www.w3.org/TR/xslt20/#parsing-and-serialization) 解析和实例化
    2.7 Extensibility (http://www.w3.org/TR/xslt20/#extensibility) 扩展性
    2.8 Stylesheets and Schemas (http://www.w3.org/TR/xslt20/#stylesheets-and-schemas) 样式和模式
    2.9 Error Handling (http://www.w3.org/TR/xslt20/#errors) 错误处理

3 Stylesheet Structure (http://www.w3.org/TR/xslt20/#stylesheet-structure) 样式结构

    3.1 XSLT Namespace (http://www.w3.org/TR/xslt20/#xslt-namespace) XSLT 名字空间
    3.2 Reserved Namespaces (http://www.w3.org/TR/xslt20/#reserved-namespaces) 保留名字空间
    3.3 Extension Attributes (http://www.w3.org/TR/xslt20/#extension-attributes) 扩展属性
    3.4 XSLT Media Type (http://www.w3.org/TR/xslt20/#xslt-media-type) XSLT 类型
    3.5 Standard Attributes (http://www.w3.org/TR/xslt20/#standard-attributes) 标准属性
    3.6 Stylesheet Element (http://www.w3.org/TR/xslt20/#stylesheet-element) 样式元素
        3.6.1 User-defined Data Elements (http://www.w3.org/TR/xslt20/#user-defined-top-level) 用户定义数据元素
    3.7 Simplified Stylesheet Modules (http://www.w3.org/TR/xslt20/#simplified-stylesheet) 简单样式模块
    3.8 Backwards-Compatible Processing (http://www.w3.org/TR/xslt20/#backwards) 向后兼容
    3.9 Forwards-Compatible Processing (http://www.w3.org/TR/xslt20/#forwards) 前兼容性
    3.10 Combining Stylesheet Modules (http://www.w3.org/TR/xslt20/#combining-modules) 合并样式模块
        3.10.1 Locating Stylesheet Modules (http://www.w3.org/TR/xslt20/#locating-modules)查找样式模块
        3.10.2 Stylesheet Inclusion (http://www.w3.org/TR/xslt20/#include)包含样式
        3.10.3 Stylesheet Import (http://www.w3.org/TR/xslt20/#import) 样式倒入
    3.11 Embedded Stylesheet Modules (http://www.w3.org/TR/xslt20/#embedded)内嵌样式模块
    3.12 Built-in Types (http://www.w3.org/TR/xslt20/#built-in-types) 内置类型
    3.13 Importing Schema Components (http://www.w3.org/TR/xslt20/#import-schema) 倒入模式组件

4 Data Model (http://www.w3.org/TR/xslt20/#data-model) 数据模型

    4.1 XML Versions (http://www.w3.org/TR/xslt20/#xml-versions) XML 版本
    4.2 Stripping Whitespace from the Stylesheet (http://www.w3.org/TR/xslt20/#stylesheet-stripping) 去除样式中的空格
    4.3 Stripping Whitespace from a Source Tree (http://www.w3.org/TR/xslt20/#strip) 从源树中去除空格
    4.4 Attributes Types and DTD Validation (http://www.w3.org/TR/xslt20/#id-in-data-model) 属性类型昨DTD校验
    4.5 Disable Output Escaping (http://www.w3.org/TR/xslt20/#d-o-e-in-data-model) 禁止输出？？

5 Syntactic Constructs (http://www.w3.org/TR/xslt20/#constructs)句法结构

    5.1 Qualified Names (http://www.w3.org/TR/xslt20/#qname) 保留字
    5.2 Unprefixed QNames in Expressions and Patterns (http://www.w3.org/TR/xslt20/#unprefixed-qnames) 表达式和类型中的无前缀的保留字
    5.3 Expressions (http://www.w3.org/TR/xslt20/#expressions) 表达式
        5.3.1 Initializing the Static Context (http://www.w3.org/TR/xslt20/#static-context)静态上下文初始化
        5.3.2 Initializing the Dynamic Context (http://www.w3.org/TR/xslt20/#evaluation-context)动态上下文初始化
    5.4 Patterns (http://www.w3.org/TR/xslt20/#patterns) 模式
    5.5 Attribute Value Templates (http://www.w3.org/TR/xslt20/#attribute-value-templates) 属性 值模版
    5.6 Sequence Constructors (http://www.w3.org/TR/xslt20/#sequence-constructors) 序列号创建
        5.6.1 Constructing Complex Content (http://www.w3.org/TR/xslt20/#constructing-complex-content) 复杂内容创建
        5.6.2 Constructing Simple Content (http://www.w3.org/TR/xslt20/#constructing-simple-content) 简单内容创建
        5.6.3 Namespace Fixup (http://www.w3.org/TR/xslt20/#namespace-fixup)名字空间修正

6 Template Rules (http://www.w3.org/TR/xslt20/#rules) 模版规则

    6.1 Defining Templates (http://www.w3.org/TR/xslt20/#defining-templates)定义模版
    6.2 Defining Template Rules (http://www.w3.org/TR/xslt20/#defining-template-rules) 定义模版规则
    6.3 Applying Template Rules (http://www.w3.org/TR/xslt20/#applying-templates)应用模版规则
    6.4 Conflict Resolution for Template Rules (http://www.w3.org/TR/xslt20/#conflict)模版规则冲突处理
    6.5 Modes (http://www.w3.org/TR/xslt20/#modes) 方法
    6.6 Built-in Template Rules (http://www.w3.org/TR/xslt20/#built-in-rule)内置模版规则
    6.7 Overriding Template Rules (http://www.w3.org/TR/xslt20/#apply-imports)重写模版规则

7 Repetition (http://www.w3.org/TR/xslt20/#for-each)复制 8 Conditional Processing (http://www.w3.org/TR/xslt20/#conditionals) 有条件执行

    8.1 Conditional Processing with xsl:if (http://www.w3.org/TR/xslt20/#xsl-if) 用xsl:if有条件执行
    8.2 Conditional Processing with xsl:choose (http://www.w3.org/TR/xslt20/#xsl-choose)用xsl:choose有条件执行

9 Variables and Parameters (http://www.w3.org/TR/xslt20/#variables-and-parameters) 变量和参数

    9.1 Variables (http://www.w3.org/TR/xslt20/#variables)变量
    9.2 Parameters (http://www.w3.org/TR/xslt20/#parameters)参数
    9.3 Values of Variables and Parameters (http://www.w3.org/TR/xslt20/#variable-values)变量和参数的值
    9.4 Temporary Trees (http://www.w3.org/TR/xslt20/#temporary-trees)临时树
    9.5 Global Variables and Parameters (http://www.w3.org/TR/xslt20/#global-variables)全局变量和参数
    9.6 Local Variables and Parameters (http://www.w3.org/TR/xslt20/#local-variables)局部变量和参数
    9.7 Scope of Variables (http://www.w3.org/TR/xslt20/#scope-of-variables) 变量作用域
    9.8 Circular Definitions (http://www.w3.org/TR/xslt20/#circularity) 循环定义

10 Callable Components (http://www.w3.org/TR/xslt20/#callable-components)可调用组件

    10.1 Named Templates (http://www.w3.org/TR/xslt20/#named-templates) 已命名模版
        10.1.1 Passing Parameters to Templates (http://www.w3.org/TR/xslt20/#with-param) 模版参数传递
        10.1.2 Tunnel Parameters (http://www.w3.org/TR/xslt20/#tunnel-params) 
    10.2 Named Attribute Sets (http://www.w3.org/TR/xslt20/#attribute-sets)
    10.3 Stylesheet Functions (http://www.w3.org/TR/xslt20/#stylesheet-functions)

11 Creating Nodes and Sequences (http://www.w3.org/TR/xslt20/#creating-new-nodes)

    11.1 Literal Result Elements (http://www.w3.org/TR/xslt20/#literal-result-element)
        11.1.1 Setting the Type Annotation for Literal Result Elements (http://www.w3.org/TR/xslt20/#setting-annotation-for-lre)
        11.1.2 Attribute Nodes for Literal Result Elements (http://www.w3.org/TR/xslt20/#attributes-for-lres)
        11.1.3 Namespace Nodes for Literal Result Elements (http://www.w3.org/TR/xslt20/#lre-namespaces)
        11.1.4 Namespace Aliasing (http://www.w3.org/TR/xslt20/#namespace-aliasing)
    11.2 Creating Element Nodes using xsl:element (http://www.w3.org/TR/xslt20/#xsl-element)
        11.2.1 Setting the Type Annotation for a Constructed Element Node (http://www.w3.org/TR/xslt20/#annotation-for-constructed-element)
    11.3 Creating Attribute Nodes using xsl:attribute (http://www.w3.org/TR/xslt20/#creating-attributes)
        11.3.1 Setting the Type Annotation for a Constructed Attribute Node (http://www.w3.org/TR/xslt20/#annotation-for-constructed-attribute)
    11.4 Creating Text Nodes (http://www.w3.org/TR/xslt20/#creating-text-nodes)
        11.4.1 Literal Text Nodes (http://www.w3.org/TR/xslt20/#literal-text-nodes)
        11.4.2 Creating Text Nodes using xsl:text (http://www.w3.org/TR/xslt20/#xsl-text)
        11.4.3 Generating Text with xsl:value-of (http://www.w3.org/TR/xslt20/#value-of)
    11.5 Creating Processing Instructions (http://www.w3.org/TR/xslt20/#creating-processing-instructions)
    11.6 Creating Namespace Nodes (http://www.w3.org/TR/xslt20/#creating-namespace-nodes)
    11.7 Creating Comments (http://www.w3.org/TR/xslt20/#creating-comments)
    11.8 Copying Nodes from a Source Tree to a Result Tree (http://www.w3.org/TR/xslt20/#copying)
        11.8.1 Shallow Copy (http://www.w3.org/TR/xslt20/#shallow-copy)
        11.8.2 Deep Copy (http://www.w3.org/TR/xslt20/#copy-of)
    11.9 Constructing Sequences (http://www.w3.org/TR/xslt20/#constructing-sequences)

12 Numbering (http://www.w3.org/TR/xslt20/#number)

    12.1 Formatting a Supplied Number (http://www.w3.org/TR/xslt20/#formatting-supplied-number)
    12.2 Numbering based on Position in a Document (http://www.w3.org/TR/xslt20/#numbering-based-on-position)
    12.3 Number to String Conversion Attributes (http://www.w3.org/TR/xslt20/#convert)

13 Sorting (http://www.w3.org/TR/xslt20/#sorting)

    13.1 The xsl:sort Element (http://www.w3.org/TR/xslt20/#xsl-sort)
        13.1.1 The Sorting Process (http://www.w3.org/TR/xslt20/#d0e16967)
        13.1.2 Comparing Sort Key Values (http://www.w3.org/TR/xslt20/#comparing-sort-keys)
        13.1.3 Sorting using Collations (http://www.w3.org/TR/xslt20/#collating-sequences)
    13.2 Creating a Sorted Sequence (http://www.w3.org/TR/xslt20/#creating-sorted-sequence)
    13.3 Processing a Sequence in Sorted Order (http://www.w3.org/TR/xslt20/#sorted-iteration)

14 Grouping (http://www.w3.org/TR/xslt20/#grouping)

    14.1 The Current Group (http://www.w3.org/TR/xslt20/#current-group)
    14.2 The Current Grouping Key (http://www.w3.org/TR/xslt20/#current-grouping-key)
    14.3 The xsl:for-each-group Element (http://www.w3.org/TR/xslt20/#xsl-for-each-group)
    14.4 Examples of Grouping (http://www.w3.org/TR/xslt20/#grouping-examples)

15 Regular Expressions (http://www.w3.org/TR/xslt20/#regular-expressions)

    15.1 The xsl:analyze-string instruction (http://www.w3.org/TR/xslt20/#analyze-string)
    15.2 Captured Substrings (http://www.w3.org/TR/xslt20/#regex-group)
    15.3 Examples of Regular Expression Matching (http://www.w3.org/TR/xslt20/#regex-examples)

16 Additional Functions (http://www.w3.org/TR/xslt20/#add-func)

    16.1 Multiple Source Documents (http://www.w3.org/TR/xslt20/#document)
    16.2 Reading Text Files (http://www.w3.org/TR/xslt20/#unparsed-text)
    16.3 Keys (http://www.w3.org/TR/xslt20/#key)
        16.3.1 The xsl:key Declaration (http://www.w3.org/TR/xslt20/#xsl-key)
        16.3.2 The key Function (http://www.w3.org/TR/xslt20/#keys)
    16.4 Number Formatting (http://www.w3.org/TR/xslt20/#format-number)
        16.4.1 Defining a Decimal Format (http://www.w3.org/TR/xslt20/#defining-decimal-format)
        16.4.2 Processing the Picture String (http://www.w3.org/TR/xslt20/#processing-picture-string)
        16.4.3 Analysing the Picture String (http://www.w3.org/TR/xslt20/#analysing-picture-string)
        16.4.4 Formatting the Number (http://www.w3.org/TR/xslt20/#formatting-the-number)
    16.5 Formatting Dates and Times (http://www.w3.org/TR/xslt20/#format-date)
        16.5.1 The Picture String (http://www.w3.org/TR/xslt20/#date-picture-string)
        16.5.2 The language, calendar, and country arguments (http://www.w3.org/TR/xslt20/#lang-cal-country)
        16.5.3 Examples of date and time formatting (http://www.w3.org/TR/xslt20/#date-time-examples)
    16.6 Miscellaneous Additional Functions (http://www.w3.org/TR/xslt20/#misc-func)
        16.6.1 current (http://www.w3.org/TR/xslt20/#current-function)
        16.6.2 unparsed-entity-uri (http://www.w3.org/TR/xslt20/#unparsed-entity-uri)
        16.6.3 unparsed-entity-public-id (http://www.w3.org/TR/xslt20/#unparsed-entity-public-id)
        16.6.4 generate-id (http://www.w3.org/TR/xslt20/#generate-id)
        16.6.5 system-property (http://www.w3.org/TR/xslt20/#system-property)

17 Messages (http://www.w3.org/TR/xslt20/#message) 18 Extensibility and Fallback (http://www.w3.org/TR/xslt20/#extension)

    18.1 Extension Functions (http://www.w3.org/TR/xslt20/#extension-functions)
        18.1.1 Testing Availability of Functions (http://www.w3.org/TR/xslt20/#testing-function-availability)
        18.1.2 Calling Extension Functions (http://www.w3.org/TR/xslt20/#calling-exension-functions)
        18.1.3 External Objects (http://www.w3.org/TR/xslt20/#external-objects)
    18.2 Extension Instructions (http://www.w3.org/TR/xslt20/#extension-instruction)
        18.2.1 Designating an Extension Namespace (http://www.w3.org/TR/xslt20/#designating-extension-namespace)
        18.2.2 Testing Availability of Instructions (http://www.w3.org/TR/xslt20/#testing-instruction-available)
        18.2.3 Fallback (http://www.w3.org/TR/xslt20/#fallback)

19 Result Trees (http://www.w3.org/TR/xslt20/#result-trees)

    19.1 Creating Result Trees (http://www.w3.org/TR/xslt20/#creating-result-trees)
    19.2 Validation (http://www.w3.org/TR/xslt20/#validation)
        19.2.1 Validating Constructed Elements and Attributes (http://www.w3.org/TR/xslt20/#validating-constructed-nodes)
        19.2.2 Validating Document Nodes (http://www.w3.org/TR/xslt20/#validating-document-nodes)

20 Serialization (http://www.w3.org/TR/xslt20/#serialization)

    20.1 Character Maps (http://www.w3.org/TR/xslt20/#character-maps)
    20.2 Disabling Output Escaping (http://www.w3.org/TR/xslt20/#disable-output-escaping)

21 Conformance (http://www.w3.org/TR/xslt20/#conformance)

    21.1 Basic XSLT Processor (http://www.w3.org/TR/xslt20/#basic-conformance)
    21.2 Schema-Aware XSLT Processor (http://www.w3.org/TR/xslt20/#schema-aware-conformance)
    21.3 Serialization Feature (http://www.w3.org/TR/xslt20/#serialization-feature)
    21.4 Backwards Compatibility Feature (http://www.w3.org/TR/xslt20/#backwards-compatibility-feature)

Appendices

A References (http://www.w3.org/TR/xslt20/#references)

    A.1 Normative References (http://www.w3.org/TR/xslt20/#normative-references)
    A.2 Other References (http://www.w3.org/TR/xslt20/#other-references)

B The XSLT Media Type (http://www.w3.org/TR/xslt20/#xslt-mime-definition)

    B.1 Registration of MIME media type application/xslt+xml (http://www.w3.org/TR/xslt20/#media-type-registration)
    B.2 Fragment Identifiers (http://www.w3.org/TR/xslt20/#media-type-fragid)

C Glossary (http://www.w3.org/TR/xslt20/#glossary) (Non-Normative) D Element Syntax Summary (http://www.w3.org/TR/xslt20/#element-syntax-summary) (Non-Normative) E Summary of Error Conditions (http://www.w3.org/TR/xslt20/#error-summary) (Non-Normative) F Checklist of Implementation-Defined Features (http://www.w3.org/TR/xslt20/#implementation-defined-features) (Non-Normative) G Schema for XSLT Stylesheets (http://www.w3.org/TR/xslt20/#schema-for-xslt) (Non-Normative) H Acknowledgements (http://www.w3.org/TR/xslt20/#d0e27004) (Non-Normative) I Checklist of Requirements (http://www.w3.org/TR/xslt20/#d0e27131) (Non-Normative) J Summary of Issues (http://www.w3.org/TR/xslt20/#issues-list) (Non-Normative)

    J.1 Open Issues (http://www.w3.org/TR/xslt20/#open-issues)
    J.2 Decided Issues (http://www.w3.org/TR/xslt20/#decided-issues)
    J.3 Closed Issues (http://www.w3.org/TR/xslt20/#closed-issues)

K Changes from XSLT 1.0 (http://www.w3.org/TR/xslt20/#changes) (Non-Normative)

    K.1 Incompatible Changes (http://www.w3.org/TR/xslt20/#incompatibilities)
        K.1.1 Backwards Compatibility Behavior (http://www.w3.org/TR/xslt20/#backwards-compatibility-behavior)
        K.1.2 Incompatibility in the Absence of a Schema (http://www.w3.org/TR/xslt20/#incompatility-without-schema)
        K.1.3 Compatibility in the Presence of a Schema (http://www.w3.org/TR/xslt20/#compatibility-with-schema)
        K.1.4 XPath 2.0 Backwards Compatibility (http://www.w3.org/TR/xslt20/#xpath-compatibility)
    K.2 New Functionality (http://www.w3.org/TR/xslt20/#changes-since-1.0)
        K.2.1 Pervasive changes (http://www.w3.org/TR/xslt20/#pervasive-changes)
        K.2.2 Major Features (http://www.w3.org/TR/xslt20/#major-features)
        K.2.3 Minor Changes (http://www.w3.org/TR/xslt20/#minor-changes)
        K.2.4 Changes since the May 2003 draft (http://www.w3.org/TR/xslt20/#changes-in-this-draft)

1 Introduction

1.1 What is XSLT?

This specification defines the syntax and semantics of the XSLT 2.0 language.

[Definition: A transformation in the XSLT language is expressed in the form of a stylesheet, whose syntax is well-formed XML [XML 1.0 (http://www.w3.org/TR/xslt20/#XML)] conforming to the Namespaces in XML Recommendation [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)].]

A stylesheet generally includes elements that are defined by XSLT as well as elements that are not defined by XSLT. XSLT-defined elements are distinguished by use of the namespace http://www.w3.org/1999/XSL/Transform (see 3.1 XSLT Namespace), which is referred to in this specification as the XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace). Thus this specification is a definition of the syntax and semantics of the XSLT namespace.

The term stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) reflects the fact that one of the important roles of XSLT is to add styling information to an XML source document, by transforming it into a document consisting of XSL formatting objects (see [XSL (http://www.w3.org/TR/xslt20/#XSLFO)]), or into another presentation-oriented format such as HTML, XHTML, or SVG. However, XSLT is used for a wide range of XML-to-XML transformation tasks, not exclusively for formatting and presentation applications.

A transformation expressed in XSLT describes rules for transforming one or more source trees into one or more result trees. The structure of these trees is described in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]. The transformation is achieved by a set of template rules (http://www.w3.org/TR/xslt20/#dt-template-rule). A template rule associates a pattern (http://www.w3.org/TR/xslt20/#dt-pattern), which matches nodes in the source document, with a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), which can be evaluated to produce part of a result tree. The structure of the result trees can be completely different from the structure of the source trees. In constructing a result tree, nodes from the source trees can be filtered and reordered, and arbitrary structure can be added. This mechanism allows a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) to be applicable to a wide class of documents that have similar source tree structures.

[Definition: A stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) may consist of several stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module), contained in different XML documents. For a given transformation, one of these functions as the principal stylesheet module. The complete stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) is assembled by finding the stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) referenced directly or indirectly from the principal stylesheet module using xsl:include and xsl:import elements: see 3.10.2 Stylesheet Inclusion and 3.10.3 Stylesheet Import.]

1.2 What's new in XSLT 2.0?

XSLT 1.0是1999年11月发布的，2.0在语言性能上有了重要的提高。变化的详细列表可以在在J Changes from XSLT 1.0找到。XSLT2.0是与XPath2.0（see [XPath 2.0]）并行发展的，因此，XPath的变化和XSLT的变化必须同时考虑。

2 Concepts

2.1 Terminology

For a full glossary of terms, see C Glossary.

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

[Definition: A specific product that performs the functions of an XSLT processor (http://www.w3.org/TR/xslt20/#dt-processor) is referred to as an implementation ].

Note:

The precise meanings of the terms source tree and result tree, as used in this specification, depend on the context. In the context of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) as a whole, the source trees are the trees provided as the initial input to the transformation, together with any trees supplied as stylesheet parameters and any trees accessed using the document, doc FO or collection FO functions; while the result trees are the trees created by an explicit xsl:result-document instruction as well as the implicit result tree created in the absence of an xsl:result-document instruction. In the context of an individual instruction in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), the term source tree also includes any temporary tree (http://www.w3.org/TR/xslt20/#dt-temporary-tree) that the instruction is using for input, and the term result tree includes any temporary tree (http://www.w3.org/TR/xslt20/#dt-temporary-tree) that the instruction is using for output.

In this specification the words must, must not, should, should not, may, required, and recommended are to be interpreted as described in [RFC2119 (http://www.w3.org/TR/xslt20/#RFC2119)]. Where the word must relates to the behavior of the XSLT processor (http://www.w3.org/TR/xslt20/#dt-processor), then an implementation is not conformant unless it behaves as specified, subject to the more detailed rules in 21 Conformance. Where the word must relates to a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), then the processor must enforce this constraint on stylesheets.

[Definition: In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation should be described in the vendor's documentation.]

[Definition: The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior.] (This might apply, for example, to limits on the size of source documents that can be transformed.)

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

A paragraph labeled as a Note or described as an example is non-normative.

Many terms used in this document are defined in the XPath specification [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)] or the Data Model specification [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]. Particular attention is drawn to the following:

[Definition: The term atomization is defined in Section 2.3.2 Atomization (http://www.w3.org/TR/xpath20/#id-atomization)XP. It is a process that takes as input a sequence of nodes and atomic values, and returns a sequence of atomic values, in which the nodes are replaced by their typed values as defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)].] For some nodes (for example, elements with element-only content), atomization generates a dynamic error (http://www.w3.org/TR/xslt20/#dt-dynamic-error).

[Definition: The term typed value is defined in Section 5.6 typed-value Accessor (http://www.w3.org/TR/xpath-datamodel/#dm-typed-value)DM. Every node except an element defined in the schema with element-only content has a typed value (http://www.w3.org/TR/xslt20/#dt-string-value). For example, the typed value (http://www.w3.org/TR/xslt20/#dt-typed-value) of an attribute of type xs:IDREFS is a sequence of zero or more xs:IDREF values.]

[Definition: The term string value is defined in Section 5.5 string-value Accessor (http://www.w3.org/TR/xpath-datamodel/#dm-string-value)DM. Every node has a string value (http://www.w3.org/TR/xslt20/#dt-string-value). For example, the string value (http://www.w3.org/TR/xslt20/#dt-string-value) of an element is the concatenation of the string values (http://www.w3.org/TR/xslt20/#dt-string-value) of all its descendant text nodes.]

[Definition: The term XPath 1.0 compatibility mode is defined in Section 2.1.1 Static Context (http://www.w3.org/TR/xpath20/#static_context)XP. This is a setting in the static context of an XPath expression; it has two values, true and false. When the value is set to true, the semantics of function calls and certain other operations are adjusted to give a greater degree of backwards compatibility between XPath 2.0 and XPath 1.0.]

2.2 Notation

In this document the specification of each XSLT-defined element type is preceded by a summary of its syntax in the form of a model for elements of that element type. A full list of all these specifications can be found in D Element Syntax Summary. The meaning of syntax summary notation is as follows:

An attribute that is required is shown with its name in bold. An attribute that may be omitted is shown with a question mark following its name.

The string that occurs in the place of an attribute value specifies the allowed values of the attribute. If this is surrounded by curly brackets ({...}), then the attribute value is treated as an attribute value template (http://www.w3.org/TR/xslt20/#dt-attribute-value-template), and the string occurring within curly brackets specifies the allowed values of the result of evaluating the attribute value template. Alternative allowed values are separated by |. A quoted string indicates a value equal to that specific string. An unquoted, italicized name specifies a particular type of value.

In all cases where this specification states that the value of an attribute must be one of a limited set of values, leading and trailing whitespace in the attribute value is ignored. In the case of an attribute value template (http://www.w3.org/TR/xslt20/#dt-attribute-value-template), this applies to the effective value (http://www.w3.org/TR/xslt20/#dt-effective-value) obtained when the attribute value template is expanded.

Unless the element is required to be empty, the model element contains a comment specifying the allowed content. The allowed content is specified in a similar way to an element type declaration in XML; sequence constructor means that any mixture of text nodes, literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element), extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction), and XSLT elements from the instruction (http://www.w3.org/TR/xslt20/#dt-instruction) category is allowed; other-declarations means that any mixture of XSLT elements from the declaration (http://www.w3.org/TR/xslt20/#dt-declaration) category, other than xsl:import, is allowed, together with user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element).

The element is prefaced by comments indicating if it belongs to the instruction category or declaration category or both. The category of an element only affects whether it is allowed in the content of elements that allow a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) or other-declarations.

Example: Syntax Notation
This example illustrates the notation used to describe XSLT elements.

<xsl:example-element

  select = expression
  debug? = { "yes" | "no" }>

</xsl:example-element>

This example defines a (non-existent) element xsl:example-element. The element is classified as an instruction. It takes a mandatory select attribute, whose value is an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression), and an optional debug attribute, whose value must be either yes or no; the curly brackets indicate that the value can be defined as an attribute value template (http://www.w3.org/TR/xslt20/#dt-attribute-value-template), allowing a value such as debug="{$debug}", where the variable (http://www.w3.org/TR/xslt20/#dt-variable) debug is evaluated to yield "yes" or "no" at run-time.

The content of an xsl:example-element instruction is defined to be a sequence of zero or more xsl:variable and xsl:param elements, followed by an xsl:sequence element.

[ERR XT0010] A static error (http://www.w3.org/TR/xslt20/#dt-static-error) is signaled if an XSLT-defined element is used in a context where it is not permitted, if a required attribute is omitted, or if the content of the element does not correspond to the content that is allowed for the element.

Attributes are validated as follows. These rules apply to the value of the attribute after removing leading and trailing whitespace.

[ERR XT0020] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if an attribute (other than an attribute written using curly brackets in a position where an attribute value template (http://www.w3.org/TR/xslt20/#dt-attribute-value-template) is permitted) contains a value that is not one of the permitted values for that attribute.

[ERR XT0030] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the effective value (http://www.w3.org/TR/xslt20/#dt-effective-value) of an attribute written using curly brackets, in a position where an attribute value template (http://www.w3.org/TR/xslt20/#dt-attribute-value-template) is permitted, is a value that is not one of the permitted values for that attribute.

Special rules apply if the construct appears in part of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that is processed with forwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-forwards-compatible-behavior): see 3.9 Forwards-Compatible Processing.

Note:

This working draft includes a non-normative XML Schema for XSLT stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) (see G Schema for XSLT Stylesheets). The syntax summaries described in this section are normative.

XSLT defines a set of standard functions which are additional to those defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]. The signatures of these functions are described using the same notation as used in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]. The names of these functions are all in the standard function namespace (http://www.w3.org/TR/xslt20/#dt-standard-function-namespace).

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 must be supplied when a transformation is initiated.

Implementations may allow a transformation to run as two or more phases, for example parsing, compilation and execution. Such a distinction is outside the scope of this specification, which treats transformation as a single process controlled using a set of stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module), supplied in the form of XML documents.

The following information is supplied to execute a transformation:

The stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) that is to act as the principal stylesheet module (http://www.w3.org/TR/xslt20/#dt-principal-stylesheet-module) for the transformation. The complete stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) is assembled by recursively expanding the xsl:import and xsl:include declarations in the principal stylesheet module, as described in 3.10.2 Stylesheet Inclusion and 3.10.3 Stylesheet Import.

A set (possibly empty) of values for stylesheet parameters (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) (see 9.5 Global Variables and Parameters). These values are available for use within expressions (http://www.w3.org/TR/xslt20/#dt-expression) in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet).

[Definition: A node that acts as the initial context node for the transformation. This node is accessible within the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) as the initial value of the XPath expressions (http://www.w3.org/TR/xslt20/#dt-expression) . (dot) and self::node(), as described in 2.5.1 Maintaining Position: the Focus].

If no initial context node is supplied, then the context item (http://www.w3.org/TR/xslt20/#dt-context-item), context position (http://www.w3.org/TR/xslt20/#dt-context-position), and context size (http://www.w3.org/TR/xslt20/#dt-context-size) will initially be unset, and the evaluation of any expression that references these values will result in a dynamic error. (Note that the initial context size and context position will always be 1 (one) when an initial context node is supplied, and will be undefined if no initial context node is supplied).

Optionally, the name of a named template (http://www.w3.org/TR/xslt20/#dt-named-template) which is to be executed as the entry point to the transformation. This template must exist within the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet). If no named template is supplied, then the transformation starts with the template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) that best matches the initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node), according to the rules defined in 6.4 Conflict Resolution for Template Rules. Either a named template, or an initial context node, or both, must be supplied.

Optionally, an initial mode (http://www.w3.org/TR/xslt20/#dt-mode). If an initial mode is supplied, then in searching for the template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) that best matches the initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node), the processor considers only those rules that apply to the initial mode. If no initial mode is supplied, the default mode is used.

[Definition: A base output URI, that is, a URI to be used as the base URI when resolving a relative URI allocated to a result tree. If the transformation generates multiple result trees, then typically each one will be allocated a URI relative to this base URI.]

[ERR XT0040] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the invocation of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) specifies a template name that does not match the expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) of a named template defined in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet).

[ERR XT0050] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the stylesheet that is invoked declares a visible stylesheet parameter (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) with required="yes" and no value for this parameter is supplied during the invocation of the stylesheet. A stylesheet parameter is visible if it is not masked by another global variable or parameter with the same name and higher import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence).

[Definition: The transformation is performed by evaluating an initial template; if a named template (http://www.w3.org/TR/xslt20/#dt-named-template) is supplied when the transformation is initiated, then this is the initial template; otherwise, the initial template is the template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) selected according to the rules of the xsl:apply-templates instruction for processing the initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node) in the initial mode (http://www.w3.org/TR/xslt20/#dt-mode).]

Parameters passed to the transformation by the client application are matched against stylesheet parameters (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) (see 9.5 Global Variables and Parameters), not against the template parameters (http://www.w3.org/TR/xslt20/#dt-template-parameter) declared within the initial template (http://www.w3.org/TR/xslt20/#dt-initial-template). All template parameters (http://www.w3.org/TR/xslt20/#dt-template-parameter) within the initial template to be executed will take their default values.

[ERR XT0060] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the initial template (http://www.w3.org/TR/xslt20/#dt-initial-template) defines a template parameter (http://www.w3.org/TR/xslt20/#dt-template-parameter) that specifies required="yes".

A stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) can process further source documents in addition to those supplied when the transformation is invoked. These additional documents can be loaded using the functions document (see 16.1 Multiple Source Documents) or doc FO or collection FO (see [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]), or they can be supplied as stylesheet parameters (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) (see 9.5 Global Variables and Parameters), or as the result of an extension function (http://www.w3.org/TR/xslt20/#dt-extension-function) (see 18.1 Extension Functions).

2.4 Executing a Transformation

[Definition: A stylesheet contains a set of template rules (see 6 Template Rules). A template rule has two parts: a pattern (http://www.w3.org/TR/xslt20/#dt-pattern) that is matched against nodes, and a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) that is evaluated to produce a sequence of items. In most cases these items are nodes, which are then written to a result tree.]

A transformation as a whole is executed by evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) of the initial template (http://www.w3.org/TR/xslt20/#dt-initial-template) as described in 5.6 Sequence Constructors. If the result is a non-empty sequence, then this sequence is used to construct an implicit result tree, following the rules described in 5.6.1 Constructing Complex Content: the effect is as if the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) contained in the initial template (http://www.w3.org/TR/xslt20/#dt-initial-template) were contained in an xsl:result-document element with no attributes.

[Definition: The elements appearing within a sequence constructor are referred to as instructions.]

The main categories of instruction elements are as follows:

instructions that create new nodes: xsl:element, xsl:attribute, xsl:processing-instruction, xsl:comment, xsl:value-of, xsl:text, xsl:namespace;

an instruction that creates an arbitrary sequence: xsl:sequence;

instructions that cause conditional or repeated evaluation of nested instructions: xsl:if, xsl:choose, xsl:for-each, xsl:for-each-group;

instructions that invoke templates: xsl:apply-templates, xsl:apply-imports, xsl:call-template, xsl:next-match;

an instruction that declares variables: xsl:variable;

other specialized instructions: xsl:number, xsl:analyze-string, xsl:message, xsl:result-document.

Often, a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) will include an xsl:apply-templates instruction, which selects a sequence of nodes to be processed. Each of the selected nodes is processed by searching the stylesheet for a matching template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) and evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) of that template rule. The resulting sequences of items are concatenated, in order, to give the result of the xsl:apply-templates instruction, as described in 6.3 Applying Template Rules; this sequence is often added to a result tree. Since the sequence constructors (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) of the selected template rules (http://www.w3.org/TR/xslt20/#dt-template-rule) may themselves contain xsl:apply-templates instructions, this results in a cycle of selecting nodes, identifying template rules (http://www.w3.org/TR/xslt20/#dt-template-rule), constructing sequences, and constructing result trees, that recurses through the source tree.

2.5 The Stylesheet Evaluation Context

During the evaluation of a stylesheet, certain information is maintained about the current state of processing. This information is referred to collectively as the evaluation context. The variables that make up the evaluation context are described in this section.

The evaluation context is structured as a stack. When an instruction (http://www.w3.org/TR/xslt20/#dt-instruction) is evaluated, it inherits the state of the evaluation context from its calling instruction. An instruction may make modifications to the state of the evaluation context, but on return to its caller, the evaluation context is always in the same state as it was on entry to the instruction. The scope of variables in the evaluation context is dynamic; they are passed implicitly from a calling template to a called template, except where otherwise specified.

The variables making up the evaluation context are not available when a stylesheet function (http://www.w3.org/TR/xslt20/#dt-stylesheet-function) is called from an XPath expression. On entry to a stylesheet function, a new empty evaluation context is established. Some variables in an empty evaluation context are said to be undefined, in which case any reference to this variable causes a dynamic error (http://www.w3.org/TR/xslt20/#dt-dynamic-error). Other variables are initialized to a defined value, such as an empty sequence.

For convenience, the evaluation context is described in two parts: the focus (http://www.w3.org/TR/xslt20/#dt-focus), which represents the place in the source document that is currently being processed, and a collection of additional context variables.

2.5.1 Maintaining Position: the Focus

[Definition: When a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) is evaluated, the processor (http://www.w3.org/TR/xslt20/#dt-processor) keeps track of which nodes are being processed by means of a set of implicit variables referred to collectively as the focus.] More specifically, the focus consists of the following three values:

[Definition: The context item is the item currently being processed. An item (see [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]) is either an atomic value (such as an integer, date, or string), or a node. The context item is initially set to the initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node) supplied when the transformation is invoked (see 2.3 Initiating a Transformation). It changes whenever instructions such as xsl:apply-templates and xsl:for-each are used to process a sequence of items; each item in such a sequence becomes the context item while that item is being processed.] The context item is returned by the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) . (dot).

[Definition: The context position is the position of the context item within the sequence of items currently being processed. It changes whenever the context item changes. When an instruction such as xsl:apply-templates or xsl:for-each is used to process a sequence of items, the first item in the sequence is processed with a context position of 1, the second item with a context position of 2, and so on.] The context position is returned by the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) position().

[Definition: The context size is the number of items in the sequence of items currently being processed. It changes whenever instructions such as xsl:apply-templates and xsl:for-each are used to process a sequence of items; during the processing of each one of those items, the context size is set to the count of the number of items in the sequence (or equivalently, the position of the last item in the sequence).] The context size is returned by the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) last().

[Definition: If the context item (http://www.w3.org/TR/xslt20/#dt-context-item) is a node (as distinct from an atomic value such as an integer), then it is also referred to as the context node. The context node is not an independent variable, it changes whenever the context item changes. When the context item is an atomic value, there is no context node.] The context node is returned by the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) self::node(), and it is used as the starting node for all relative path expressions.

The current function can be used within any XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) to select the item that was supplied as the context item to the XPath expression by the XSLT processor; unlike . (dot) this is unaffected by changes to the context item that occur within the XPath expression. The current function is described in 16.6.1 current.

On completion of an instruction that changes the focus (http://www.w3.org/TR/xslt20/#dt-focus) (such as xsl:apply-templates or xsl:for-each), the focus reverts to its previous value.

When a stylesheet function (http://www.w3.org/TR/xslt20/#dt-stylesheet-function) is called, the focus within the body of the function is initially undefined. The focus is also undefined on initial entry to the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) if no initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node) supplied.

[ERR XT0070] When the focus is undefined, evaluation of any expression (http://www.w3.org/TR/xslt20/#dt-expression) that references the context item, context position, or context size results in a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error).

The description above gives an outline of the way the focus (http://www.w3.org/TR/xslt20/#dt-focus) works. Detailed rules for the effect of each instruction are given separately with the description of that instruction. In the absence of specific rules, an instruction uses the same focus as its parent instruction.

Sometimes the focus is based on a single node.

[Definition: A singleton focus based on a node N has the context item (http://www.w3.org/TR/xslt20/#dt-context-item) (and therefore the context node (http://www.w3.org/TR/xslt20/#dt-context-node)) set to N, and the context position (http://www.w3.org/TR/xslt20/#dt-context-position) and context size (http://www.w3.org/TR/xslt20/#dt-context-size) both set to 1 (one).]

2.5.2 Additional Context Variables

In addition to the values that make up the focus (http://www.w3.org/TR/xslt20/#dt-focus), an XSLT processor maintains a number of other internal variables that reflect aspects of the evaluation context. These variables are fully described in the sections of the specification that maintain and use these variables. They are:

The current template (http://www.w3.org/TR/xslt20/#dt-current-template-rule), which is the template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) most recently invoked by an xsl:apply-templates, xsl:apply-imports, or xsl:next-match instruction: see 6.7 Overriding Template Rules;

The current mode (http://www.w3.org/TR/xslt20/#dt-current-mode), which is the mode (http://www.w3.org/TR/xslt20/#dt-mode) in which the current template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) was invoked: see 6.5 Modes;

The current group (http://www.w3.org/TR/xslt20/#dt-current-group) and current grouping key (http://www.w3.org/TR/xslt20/#dt-current-grouping-key), which provide information about the collection of items currently being processed by an xsl:for-each-group instruction: see 14.1 The Current Group and 14.2 The Current Grouping Key;

The current captured substrings (http://www.w3.org/TR/xslt20/#dt-current-captured-substrings): this is a sequence of strings, which is maintained when a string is matched against a regular expression using the xsl:analyze-string instruction, and which is accessible using the regex-group function: see 15.2 Captured Substrings.

The output state (http://www.w3.org/TR/xslt20/#dt-output-state): this is a flag whose two possible values are final output state (http://www.w3.org/TR/xslt20/#dt-final-output-state) and temporary output state (http://www.w3.org/TR/xslt20/#dt-temporary-output-state). This flag indicates whether instructions are currently writing to a final result tree or to an internal data structure. The initial setting is final output state (http://www.w3.org/TR/xslt20/#dt-final-output-state), and it is switched to temporary output state (http://www.w3.org/TR/xslt20/#dt-temporary-output-state) by instructions such as xsl:variable. For more details, see 19.1 Creating Result Trees.

The following non-normative table summarizes the initial state of each of the variables in the evaluation context, and the instructions which cause the state of the variable to change.

Variable
Initial Setting
Set by
Cleared by


focus (http://www.w3.org/TR/xslt20/#dt-focus)
singleton focus based on the initial context node (http://www.w3.org/TR/xslt20/#dt-initial-context-node) if supplied
xsl:apply-templates, xsl:for-each, xsl:for-each-group, xsl:analyze-string
calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

current template (http://www.w3.org/TR/xslt20/#dt-current-template-rule)
the initial template (http://www.w3.org/TR/xslt20/#dt-initial-template)
xsl:apply-templates, xsl:apply-imports, xsl:next-match
xsl:for-each, xsl:for-each-group, calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

current mode (http://www.w3.org/TR/xslt20/#dt-current-mode)
the initial mode (http://www.w3.org/TR/xslt20/#dt-mode)
xsl:apply-templates
calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

current group (http://www.w3.org/TR/xslt20/#dt-current-group)
empty sequence
xsl:for-each-group
calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

current grouping key (http://www.w3.org/TR/xslt20/#dt-current-grouping-key)
empty sequence
xsl:for-each-group
calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

current captured substrings (http://www.w3.org/TR/xslt20/#dt-current-captured-substrings)
empty sequence
xsl:matching-substring
xsl:non-matching-substring; calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)

output state (http://www.w3.org/TR/xslt20/#dt-output-state)
final output state (http://www.w3.org/TR/xslt20/#dt-final-output-state)
Set to temporary output state (http://www.w3.org/TR/xslt20/#dt-temporary-output-state) by instructions such as xsl:variable, xsl:attribute, etc., and by calls on stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function)
None

2.6 Parsing and Serialization

An XSLT stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) describes a process that constructs a set of result trees from a set of source trees.

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

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

Like parsing, serialization is not part of the transformation process, and it is not required that an XSLT processor must be able to perform serialization. However, for pragmatic reasons, this specification describes declarations (the xsl:output element and the xsl:character-map declarations, see 20 Serialization) which allow a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) to specify the desired properties of a serialized output file. When serialization is not being performed, either because the implementation does not support the serialization option, or because the user is executing the transformation in a way that does not invoke serialization, then the content of the xsl:output and xsl:character-map declarations has no effect. Under these circumstances the processor may report any errors in an xsl:output or xsl:character-map declaration, but is not required to do so.

2.7 Extensibility

XSLT defines a number of features that allow the language to be extended by implementers, or, if implementers choose to provide the capability, by users. These features have been designed, so far as possible, so that they can be used without sacrificing interoperability. Extensions other than those explicitly defined in this specification are not permitted.

These features are all based on XML namespaces; namespaces are used to ensure that the extensions provided by one implementer do not clash with those of a different implementer.

The most common way of extending the language is by providing additional functions, which can be invoked from XPath expressions. These are known as extension functions (http://www.w3.org/TR/xslt20/#dt-extension-function), and are described in 18.1 Extension Functions.

It is also permissible to extend the language by providing new XSLT instructions. These are referred to as extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction), and are described in 18.2 Extension Instructions. A stylesheet that uses extension instructions must declare that it is doing so by using the [xsl:]extension-element-prefixes attribute.

Extension instructions and extension functions defined according to these rules may be provided by the implementer of the XSLT processor, and the implementer may also provide facilities to allow users to create further extension instructions and extension functions.

This specification defines how extension instructions and extension functions are invoked, but the facilities for creating new extension instructions and extension functions are implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined). For further details, see 18 Extensibility and Fallback.

The XSLT language can also be extended by the use of extension attributes (http://www.w3.org/TR/xslt20/#dt-extension-attribute) (see 3.3 Extension Attributes), and by means of user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element) (see 3.6.1 User-defined Data Elements).

2.8 Stylesheets and Schemas

An XSLT stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) can make use of information from a schema. An XSLT transformation can take place in the absence of a schema (and, indeed, in the absence of a DTD), but where the source document has undergone schema validity assessment, the XSLT processor has access to the type information associated with individual nodes, not merely to the untyped text.

Information from a schema can be used both statically (when the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) is compiled), and dynamically (during evaluation of the stylesheet to transform a source document).

There are places within a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), and within XPath expressions (http://www.w3.org/TR/xslt20/#dt-expression) and patterns in a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), where it is possible to refer to named type definitions in a schema, or to element and attribute declarations. For example, it is possible to declare the types expected for the parameters of a function. This is done using the SequenceType (http://www.w3.org/TR/xpath20/#doc-xpath-SequenceType) XP syntax defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

[Definition: Type definitions and element and attribute declarations are referred to collectively as schema components.]

[Definition: The schema components (http://www.w3.org/TR/xslt20/#dt-schema-component) that may be referenced by name in a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) are referred to as the in-scope schema components. This set is the same throughout a stylesheet.]

The conformance rules for XSLT 2.0, defined in 21 Conformance, distinguish between a basic XSLT processor (http://www.w3.org/TR/xslt20/#dt-basic-xslt-processor) and a schema-aware XSLT processor (http://www.w3.org/TR/xslt20/#dt-schema-aware-xslt-processor). As the names suggest, a basic XSLT processor does not support the features of XSLT that require access to schema information, either statically or dynamically. A stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that works with a basic XSLT processor will work unchanged with a schema-aware XSLT processor, unless the type information created as a result of schema processing introduces type errors (for example, an attribute of type xs:integer cannot be used as an argument of the concat FO function), or unless the type information changes the outcome of operations such as comparison and sorting.

There is a standard set of type definitions that are always available as in-scope schema components (http://www.w3.org/TR/xslt20/#dt-in-scope-schema-component) in every stylesheet. These are defined in 3.12 Built-in Types. The set of built-in types varies between a basic XSLT processor (http://www.w3.org/TR/xslt20/#dt-basic-xslt-processor) and a schema-aware XSLT processor (http://www.w3.org/TR/xslt20/#dt-schema-aware-xslt-processor).

The remainder of this section describes facilities that are available only with a schema-aware XSLT processor (http://www.w3.org/TR/xslt20/#dt-schema-aware-xslt-processor).

Additional schema components (http://www.w3.org/TR/xslt20/#dt-schema-component) (type definitions, element declarations, and attribute declarations) may be added to the in-scope schema components (http://www.w3.org/TR/xslt20/#dt-in-scope-schema-component) by means of the xsl:import-schema declaration in a stylesheet.

It is only necessary to import a schema explicitly if one or more of its schema components (http://www.w3.org/TR/xslt20/#dt-schema-component) are referenced explicitly by name in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet); it is not necessary to import a schema merely because the stylesheet is used to process a source document that has been assessed against that schema. It is possible to make use of the information resulting from schema assessment (for example, the fact that a particular attribute holds a date) even if no schema has been imported by the stylesheet.

Further, importing a schema does not of itself say anything about the type of the source document that the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) is expected to process. The imported type definitions can be used for temporary nodes or for nodes on the result tree just as much as for nodes in source documents. It is possible to make assertions about the type of an input document by means of tests within the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet). For example:

Example: Asserting the Required Type of the Source Document
<xsl:template match="document-node(element(my:invoice))" priority="2">
. . .
</xsl:template>

<xsl:template match="document-node()" priority="1">

  <xsl:message terminate="yes">Source document is not an invoice</xsl:message>

</xsl:template>

This example will cause the transformation to fail with an error message unless the document element of the source document is valid against the top-level element declaration my:invoice, and has been annotated as such.

It is possible that a source document may contain nodes whose type annotation is not one of the types imported by the stylesheet. This creates a potential problem because in the case of an expression such as data(.) instance of xs:integer the system needs to know whether the type named in the type annotation of the context node is derived by restriction from the type xs:integer. This information is not explicitly available in the data model, as defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]. The implementation may choose one of several strategies for dealing with this situation:

The processor may signal a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if a source document is found to contain a type annotation that is not known to the processor.

The processor may maintain additional metadata, beyond that described in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)], that allows the source document to be processed as if all the necessary schema information had been imported using xsl:import-schema. Such metadata might be held in the data model itself, or it might be held in a system catalog or repository.

The processor may be configured to use a fixed set of schemas, which are automatically used to validate all source documents before they can be supplied as input to a transformation. In this case it is impossible for a source document to have a type annotation that the processor is not aware of.

The processor may be configured to treat the input data model as if no schema processing had been performed, that is, effectively to strip all type annotations from elements and attributes on input, marking them instead as having type xdt:untypedAny and xdt:untypedAtomic respectively.

Where a stylesheet author chooses to make assertions about the types of nodes or of variables (http://www.w3.org/TR/xslt20/#dt-variable) and parameters (http://www.w3.org/TR/xslt20/#dt-parameter), it is possible for an XSLT processor to perform static analysis of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) (that is, analysis in the absence of any source document). Such analysis may reveal errors that would otherwise not be discovered until the transformation is actually executed. An XSLT processor is not required to perform such static type-checking. Under some circumstances (see 2.9 Error Handling) type errors that are detected early may be reported as static errors. In addition an implementation may report any condition found during static analysis as a warning, provided that this does not prevent the stylesheet being evaluated as described by this specification.

A stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) can also control the type annotations of nodes that it constructs in a final result tree, or in temporary trees. This can be done in a number of ways.

It is possible to request explicit validation of a complete result tree. Validation is either strict or lax, as described in [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)]. If validation of a result tree fails (strictly speaking, if the outcome of the validity assessment is invalid), then the transformation fails, but in all other cases, the element and attribute nodes of the tree will be annotated with the names of the types to which these nodes conform. These annotations will be discarded if the result tree is serialized as an XML document, but they remain available when the result tree is passed to an application (perhaps another stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet)) for further processing.

It is also possible to validate individual element and attribute nodes as they are constructed. This is done using the type and validation attributes of the xsl:element, xsl:attribute, xsl:copy, and xsl:copy-of instructions, or the xsl:type and xsl:validation attributes of a literal result element.

When elements, attributes, or document nodes are copied, either explicitly using the xsl:copy or xsl:copy-of instructions, or implicitly when nodes in a sequence are attached to a new parent node, the options validation="strip" and validation="preserve" are available, to control whether existing type annotations are to be retained or not.

When nodes in a temporary tree are validated, type information is available for use by operations carried out on the temporary tree, in the same way as for a source document that has undergone schema assessment.

For details of how validation of element and attribute nodes works, see 19.2 Validation.

2.9 Error Handling

[Definition: An error that is detected by examining a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.]

Errors classified in this specification as static errors must be signaled by all implementations: that is, the processor (http://www.w3.org/TR/xslt20/#dt-processor) must indicate that the error is present. A static error must be signaled even if it occurs in a part of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that is never evaluated. Static errors are never recoverable. After signaling a static error, a processor may continue for the purpose of signaling additional errors, but it must eventually terminate abnormally without producing any result tree.

There is an exception to this rule when the stylesheet specifies forwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-forwards-compatible-behavior) (see 3.9 Forwards-Compatible Processing).

Generally, errors in the structure of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), or in the syntax of XPath expressions (http://www.w3.org/TR/xslt20/#dt-expression) contained in the stylesheet, are classified as static errors (http://www.w3.org/TR/xslt20/#dt-static-error). Where this specification states that an element in the stylesheet must or must not appear in a certain position, or that it must or must not have a particular attribute, or that an attribute must or must not have a value satisfying specified conditions, then any contravention of this rule is a static error unless otherwise specified.

[Definition: An error that is not detected until a source document is being transformed is referred to as a dynamic error.]

[Definition: Some dynamic errors are classed as recoverable errors. When a recoverable error occurs, this specification allows the processor either to signal the error (by reporting the error condition and terminating execution) or to take a defined recovery action and continue processing.] It is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) whether the error is signaled or the recovery action is taken.

[Definition: If an implementation chooses to recover from a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error), it must take the optional recovery action defined for that error condition in this specification.]

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

[Definition: A dynamic error (http://www.w3.org/TR/xslt20/#dt-dynamic-error) that is not recoverable is referred to as a non-recoverable dynamic error. When a non-recoverable dynamic error occurs, the processor (http://www.w3.org/TR/xslt20/#dt-processor) must signal the error, and the transformation fails.]

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

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

An implementation may signal a dynamic error (http://www.w3.org/TR/xslt20/#dt-dynamic-error) before any source document is available, but only if it can determine that the error would be signaled for every possible source document and every possible set of parameter values. For example, some circularity (http://www.w3.org/TR/xslt20/#circularity) errors fall into this category: see 9.8 Circular Definitions.

The XPath specification states, in effect, that an XPath processor may evaluate a constant subexpression during the analysis phase, and if any error occurs during that evaluation, it may report this as a static error. For XPath expressions used in an XSLT stylesheet, however, any such errors must not be reported as static errors in the stylesheet; instead, they must be held back until the evaluation phase, and signaled only if the XPath expression is actually evaluated.

Example: Errors in Constant Subexpressions
An XPath processor may report statically that the expression 1 div 0 fails with a "divide by zero" error. But suppose this XPath expression occurs in an XSLT construct such as:

<xsl:choose>

  <xsl:when test="system-property('xsl:version') = '1.0'">

    <xsl:value-of select="1 div 0"/>

  </xsl:when>

  <xsl:otherwise>

    <xsl:value-of select="xs:double('+INF')"/>

  </xsl:otherwise>

</xsl:choose>

Then the XSLT processor must not report an error, because the relevant XPath construct appears in a context where it will never be executed by an XSLT 2.0 processor. (An XSLT 1.0 processor will execute this code successfully, returning positive infinity, because it uses double arithmetic rather than decimal arithmetic.)

[Definition: Certain errors are classified as type errors. A type error occurs when the value supplied as input to an operation is of the wrong type for that operation, for example when an integer is supplied to an operation that expects a node.] If a type error occurs in an instruction that is actually evaluated, then it must be signaled in the same way as a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error). Alternatively, an implementation may signal a type error during the analysis phase in the same way as a static error (http://www.w3.org/TR/xslt20/#dt-static-error), even if it occurs in part of the stylesheet that is never evaluated, provided it can establish that execution of a particular construct would never succeed.

It is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) whether type errors are signaled statically.

Example: A Type Error
For example, the following construct contains a type error, because 42 is not allowed as an operand of the xsl:apply-templates instruction. An implementation may optionally signal this as a static error, even though the offending instruction will never be evaluated, and the type error would therefore never be signaled as a dynamic error.

<xsl:if test="false()">

  <xsl:apply-templates select="42"/>

</xsl:if>

On the other hand, in the following example it is not possible to determine statically whether the operand of xsl:apply-templates will have a suitable dynamic type. An implementation may produce a warning in such cases, but it must not treat it as an error.

<xsl:template match="para">

  <xsl:param name="p" as="item()"/>

  <xsl:apply-templates select="$p"/>

</xsl:template>

If more than one error arises, an implementation is not required to signal any errors other than the first one that it detects. It is implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent) which of the several errors is signaled. This applies both to static errors and to dynamic errors. An implementation is allowed to signal more than one error, but if any errors have been signaled, it must not finish as if the transformation were successful.

When a transformation signals one or more dynamic errors, the final state of any persistent resources updated by the transformation is implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent). Implementations are not required to restore such resources to their initial state. In particular, where a transformation produces multiple result documents, it is possible that one or more result documents may be written successfully before the transformation terminates, but the application cannot rely on this behavior.

Everything said above about error handling applies equally to errors in evaluating XSLT instructions, and errors in evaluating XPath expressions (http://www.w3.org/TR/xslt20/#dt-expression). Static errors and dynamic errors may occur in both cases.

[Definition: If a transformation has successfully produced a result tree, it is still possible that errors may occur in serializing the result tree. For example, it may be impossible to serialize the result tree using the encoding selected by the user. Such an error is referred to as a serialization error.] As with other aspects of serialization, the handling of serialization errors is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined): see 20 Serialization.

The error codes used to label error conditions in this specification (and summarized in E Summary of Error Conditions) are provided for ease of reference. Implementations may use these codes when signaling errors, but they are not required to do so. An implementation that uses these codes within an API should treat the codes as unprefixed QNames; additional codes defined by an implementation (or by an application) can then use QNames in an implementation-defined namespace without risk of collision.

3 Stylesheet Structure

[Definition: A stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) consists of one or more stylesheet modules, each one forming all or part of a well-formed XML document.]

Note:

A stylesheet module, as defined here, contains XML in its raw textual form. In discussing the semantics of a stylesheet module, this specification frequently makes reference to nodes in the data model (see [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]) that is generated when the XML document containing the stylesheet module is parsed. These references should not be taken as implying that an implementation must always start with stylesheet modules as textual XML documents, nor that it must represent the stylesheet internally as an instance of the data model.

A stylesheet module is either a standard stylesheet module or a simplified stylesheet module:

[Definition: A standard stylesheet module is an XML document, or part of an XML document, having an xsl:stylesheet or xsl:transform element as its outermost element (see 3.6 Stylesheet Element).]

[Definition: A simplified stylesheet module is an XML document, or part of an XML document, whose outermost element is a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element) to be copied to the result tree. This element is not itself in the XSLT namespace, but it must have an xsl:version attribute, which implies that the XSLT namespace must be declared. For further details see 3.7 Simplified Stylesheet Modules. ]

Both forms of stylesheet module (standard and simplified) can exist either as an entire XML document, or embedded as part of another XML document, typically a source document that is to be processed using the stylesheet.

[Definition: A standalone stylesheet module is a stylesheet module that comprises the whole of an XML document.]

[Definition: An embedded stylesheet module is a stylesheet module that is embedded within another XML document, typically the source document that is being transformed.] (see 3.11 Embedded Stylesheet Modules).

There are thus four kinds of stylesheet module:

standalone standard stylesheet modules standalone simplified stylesheet modules embedded standard stylesheet modules embedded simplified stylesheet modules

3.1 XSLT Namespace

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

Note:

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

XSLT processors (http://www.w3.org/TR/xslt20/#dt-processor) must use the XML namespaces mechanism [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)] to recognize elements and attributes from this namespace. Elements from the XSLT namespace are recognized only in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) and not in the source document. The complete list of XSLT-defined elements is specified in D Element Syntax Summary. Implementations (http://www.w3.org/TR/xslt20/#dt-implementation) must not extend the XSLT namespace with additional elements or attributes. Instead, any extension must be in a separate namespace. Any namespace that is used for additional instruction elements must be identified by means of the extension instruction (http://www.w3.org/TR/xslt20/#dt-extension-instruction) mechanism specified in 18.2 Extension Instructions.

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

Note:

Throughout this specification, an element or attribute that is in no namespace, or an expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) whose namespace part is an empty sequence, is referred to as having a null namespace URI.

Note:

The conventions used for the names of XSLT elements, attributes and functions are that names are all lower-case, use hyphens to separate words, and use abbreviations only if they already appear in the syntax of a related language such as XML or HTML. Names of types defined in XML Schema however, are regarded as single words and are capitalized exactly as in XML Schema. This sometimes leads to composite function names such as current-dateTimeFO.

3.2 Reserved Namespaces

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

The XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace), described in 3.1 XSLT Namespace, is reserved.

[Definition: The standard function namespace http://www.w3.org/2003/11/xpath-functions is used for functions in the core function library, defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]. ]

[Definition: The XML namespace, defined in [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)] as http://www.w3.org/XML/1998/namespace, is used for attributes such as xml:lang and xml:space].

[Definition: The schema namespace http://www.w3.org/2001/XMLSchema is used as defined in [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] ]. In a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) this namespace may be used to refer to built-in schema datatypes and to the constructor functions associated with those datatypes.

[Definition: The schema datatypes namespace http://www.w3.org/2001/XMLSchema-datatypes is used as defined in [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)]]. In a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) this namespace may be used to refer to built-in schema datatypes and to the constructor functions associated with those datatypes: in these respects it is equivalent to the schema namespace (http://www.w3.org/TR/xslt20/#dt-schema-namespace).

[Definition: The XPath datatypes namespace http://www.w3.org/2003/11/xpath-datatypes is used as defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]]. In a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) this namespace may be used to refer to the types xdt:untypedAtomic, xdt:yearMonthDuration, xdt:dayTimeDuration, xdt:anyAtomicType, and to the constructor functions associated with the first three of these types.

[Definition: The schema instance namespace http://www.w3.org/2001/XMLSchema-instance is used as defined in [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] ]. Attributes in this namespace, if they appear in a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), are treated by the XSLT processor in the same way as any other attributes.

Reserved namespaces may be used without restriction to refer to the names of elements and attributes in source documents and result documents. As far as the XSLT processor is concerned, reserved namespaces other than the XSLT namespace may be used without restriction in the names of literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element) and user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element), and in the names of attributes of literal result elements or of XSLT instructions: but other processors may impose restrictions or attach special meaning to them. Reserved namespaces must not be used, however, in the names of stylesheet-defined objects such as variables (http://www.w3.org/TR/xslt20/#dt-variable) and stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function).

Note:

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

[ERR XT0080] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) to use a reserved namespace (http://www.w3.org/TR/xslt20/#dt-reserved-namespace) in the name of a named template (http://www.w3.org/TR/xslt20/#dt-named-template), a mode (http://www.w3.org/TR/xslt20/#dt-mode), an attribute set (http://www.w3.org/TR/xslt20/#dt-attribute-set), a key (http://www.w3.org/TR/xslt20/#dt-key), a decimal-format (http://www.w3.org/TR/xslt20/#dt-decimal-format), a variable (http://www.w3.org/TR/xslt20/#dt-variable) or parameter (http://www.w3.org/TR/xslt20/#dt-parameter), a stylesheet function (http://www.w3.org/TR/xslt20/#dt-stylesheet-function), a named output definition (http://www.w3.org/TR/xslt20/#dt-output-definition), or a character map (http://www.w3.org/TR/xslt20/#dt-character-map).

3.3 Extension Attributes

[Definition: An element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) (see [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]) of the attribute has a non-null namespace URI. These attributes are referred to as extension attributes.] The presence of an extension attribute must not cause the result trees produced by the transformation to be different from the result trees that a conformant XSLT 2.0 processor might produce. They must not cause the processor to fail to signal an error that a conformant processor is required to signal. This means that an extension attribute must not change the effect of any instruction except to the extent that the effect is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) or implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent).

Note:

Extension attributes (http://www.w3.org/TR/xslt20/#dt-extension-attribute) may be used to modify the behavior of extension functions (http://www.w3.org/TR/xslt20/#dt-extension-function) and extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction). They may be used to select processing options in cases where the specification leaves the behavior implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) or implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent). They may also be used for optimization hints, for diagnostics, or for documentation.

Extension attributes (http://www.w3.org/TR/xslt20/#dt-extension-attribute) may also be used to control what happens to a result tree once the transformation is complete. They may thus be used to provide additional parameters to the serializer, or to override the serialization behavior specified in 20 Serialization.

An implementation that does not recognize the name of an extension attribute, or that does not recognize its value, must perform the transformation as if the extension attribute were not present. As always, it is permissible to produce warning messages.

Example: An Extension Attribute for xsl:message
For example, the following code might be used to indicate to a particular implementation that the xsl:message instruction is to ask the user for confirmation before continuing with the transformation:

<xsl:message

    abc:pause="yes"

    xmlns:abc="http://vendor.example.com/xslt/extensions">Phase 1 complete</xsl:message>

Implementations that do not recognize the namespace http://vendor.example.com/xslt/extensions will simply ignore the extra attribute, and evaluate the xsl:message instruction in the normal way.

[ERR XT0090] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) for an element from the XSLT namespace to have an attribute whose namespace is either null (that is, an attribute with an unprefixed name) or the XSLT namespace, other than attributes defined for the element in this document.

3.4 XSLT Media Type

The media type application/xslt+xml will be registered for XSLT stylesheet modules.

The proposed definition of the media type is at B The XSLT Media Type

This media type should be used for an XML document containing a standard stylesheet module (http://www.w3.org/TR/xslt20/#dt-standard-stylesheet-module) at its top level, and it may also be used for a simplified stylesheet module (http://www.w3.org/TR/xslt20/#dt-simplified-stylesheet-module). It should not be used for an XML document containing an embedded stylesheet module (http://www.w3.org/TR/xslt20/#dt-embedded-stylesheet-module).

3.5 Standard Attributes

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

These attributes may also appear on a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element), but in this case, to distinguish them from user-defined attributes, the names of the attributes are in the XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace). They are thus typically written as xsl:version, xsl:exclude-result-prefixes, xsl:extension-element-prefixes, or xsl:xpath-default-namespace.

It is recommended that these attributes should also be permitted on extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction), but this is at the discretion of the implementer of each extension instruction. They may also be permitted on user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element), though they will only have any useful effect in the case of data elements that are designed to behave like XSLT declarations or instructions.

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

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

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

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

Because these attributes may appear on any XSLT element, they are not listed in the syntax summary of each individual element. Instead they are listed and described in the description of the xsl:stylesheet and xsl:transform elements only. This reflects the fact that these attributes are often used on the xsl:stylesheet element, in which case they apply to the entire stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module).

Note that the effect of these attributes does not extend to stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) referenced by xsl:include or xsl:import declarations.

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

[xsl:]version

see 3.8 Backwards-Compatible Processing and 3.9 Forwards-Compatible Processing

[xsl:]xpath-default-namespace

see 5.2 Unprefixed QNames in Expressions and Patterns

[xsl:]exclude-result-prefixes

see 11.1.3 Namespace Nodes for Literal Result Elements

[xsl:]extension-element-prefixes

see 18.2 Extension Instructions

3.6 Stylesheet Element

<xsl:stylesheet

  id? = id
  extension-element-prefixes? = tokens
  exclude-result-prefixes? = tokens
  version = number
  xpath-default-namespace? = uri
  default-validation? = "strict" | "lax" | "preserve" | "strip">

</xsl:stylesheet>

<xsl:transform

  id? = id
  extension-element-prefixes? = tokens
  exclude-result-prefixes? = tokens
  version = number
  xpath-default-namespace? = uri
  default-validation? = "strict" | "lax" | "preserve" | "strip">

</xsl:transform>

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

[ERR XT0100] An xsl:stylesheet element must have a version attribute, indicating the version of XSLT that the stylesheet module requires.

[ERR XT0110] The value of the version attribute must be a number (specifically, it must be a DecimalLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-DecimalLiteral) XP as defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].) For this version of XSLT, the value should normally be 2.0. A value of 1.0 indicates that the stylesheet module was written with the intention that it should be processed using an XSLT 1.0 processor.

If a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that specifies [xsl:]version="1.0" in the outermost element of the principal stylesheet module (http://www.w3.org/TR/xslt20/#dt-principal-stylesheet-module) (that is, version="1.0" in the case of a standard stylesheet module (http://www.w3.org/TR/xslt20/#dt-standard-stylesheet-module), or xsl:version="1.0" in the case of a simplified stylesheet module (http://www.w3.org/TR/xslt20/#dt-simplified-stylesheet-module)) is submitted to an XSLT 2.0 processor, the processor should output a warning advising the user of possible incompatibilities, unless the user has requested otherwise. The processor must then process the stylesheet using the rules for backwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-backwards-compatible-behavior). These rules require that if the processor does not support backwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-backwards-compatible-behavior), it must signal an error and must not execute the transformation.

When the value of the version attribute is greater than 2.0, forwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-forwards-compatible-behavior) is enabled (see 3.9 Forwards-Compatible Processing).

Note:

XSLT 1.0 allowed the [xsl:]version attribute to take any numeric value, and specified that if the value was not equal to 1.0, the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) would be executed in forwards compatible mode. XSLT 2.0 continues to allow the attribute to take any unsigned decimal value. A software product that includes both an XSLT 1.0 processor and an XSLT 2.0 processor (or that can execute as either) may use the [xsl:]version attribute to decide which processor to invoke; such behavior is outside the scope of this specification. When the stylesheet is executed with an XSLT 2.0 processor, the value 1.0 is taken to indicate that the stylesheet module was written with XSLT 1.0 in mind: if this value appears on the outermost element of the principal stylesheet module then an XSLT 2.0 processor will either reject the stylesheet or execute it in backwards compatible mode, as described above. Setting version="2.0" indicates that the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) is to be executed with neither backwards nor forwards compatible behavior enabled. Any other value less than 2.0 enables backwards compatible behavior, while any value greater than 2.0 enables forwards compatible behavior.

When developing a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that is designed to execute under either XSLT 1.0 or XSLT 2.0, the recommended practice is to create two separate entry modules, one specifying version="1.0", and the other specifying version="2.0"; these entry modules can use xsl:include or xsl:import to incorporate the common code. Subsidiary stylesheet modules should specify version="2.0" if they make use of XSLT 2.0 facilities, and version="1.0" otherwise.

The default-validation attribute defines the default value of the validation attribute of all xsl:element, xsl:attribute, xsl:copy, xsl:copy-of, and xsl:result-document instructions, and of the xsl:validation attribute of all literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element). It also determines the validation applied to the implicit result tree created in the absence of an xsl:result-document instruction. This default applies within the stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module): it does not extend to included or imported stylesheet modules. If the attribute is omitted, the default is strip. For details of the effect of this attribute, see 19.2 Validation.

[ERR XT0120] An xsl:stylesheet element must not have any text node children. (This rule applies after stripping of whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) as described in 4.2 Stripping Whitespace from the Stylesheet)

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

[Definition: Top-level elements fall into two categories: declarations, and user-defined data elements. Top-level elements whose names are in the XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace) are declarations. Top-level elements in any other namespace are user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element) (see 3.6.1 User-defined Data Elements)]

The declaration (http://www.w3.org/TR/xslt20/#dt-declaration) elements permitted in the xsl:stylesheet element are:

xsl:import xsl:include xsl:attribute-set xsl:character-map xsl:decimal-format xsl:function xsl:import-schema xsl:key xsl:namespace-alias xsl:output xsl:param xsl:preserve-space xsl:strip-space xsl:template xsl:variable

If there are xsl:import elements, these must come before any other elements. Apart from this, the child elements of the xsl:stylesheet element may appear in any order. The ordering of these elements does not affect the results of the transformation unless there are conflicting declarations (for example, two template rules with the same priority that match the same node). In general, it is an error for a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) to contain such conflicting declarations, but in some cases the processor is allowed to recover from the error by choosing the declaration that appears last in the stylesheet.

3.6.1 User-defined Data Elements

[Definition: In addition to declarations (http://www.w3.org/TR/xslt20/#dt-declaration), the xsl:stylesheet element may contain any element not from the XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace), provided that the expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) of the element has a non-null namespace URI. Such elements are referred to as user-defined data elements.]

[ERR XT0130] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the xsl:stylesheet element has a child element whose name has a null namespace URI.

An implementation may attach an implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) meaning to user-defined data elements that appear in particular namespaces. The set of namespaces that are recognized for such data elements is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined). The presence of a user-defined data element must not change the behavior of XSLT elements and functions defined in this document; for example, it is not permitted for a user-defined data element to specify that xsl:apply-templates should use different rules to resolve conflicts. The constraints on what user-defined data elements can and cannot do are exactly the same as the constraints on extension attributes (http://www.w3.org/TR/xslt20/#dt-extension-attribute), described in 3.3 Extension Attributes. Thus, an implementation is always free to ignore user-defined data elements, and must ignore such data elements without giving an error if it does not recognize the namespace URI.

User-defined data elements can provide, for example,

information used by extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction) or extension functions (http://www.w3.org/TR/xslt20/#dt-extension-function) (see 18 Extensibility and Fallback),

information about what to do with the result tree,

information about how to obtain the source tree,

optimization hints for the processor (http://www.w3.org/TR/xslt20/#dt-processor),

metadata about the stylesheet,

structured documentation for the stylesheet.

[ERR XT0140] A user-defined data element (http://www.w3.org/TR/xslt20/#dt-data-element) must not precede an xsl:import element within a stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module).

3.7 Simplified Stylesheet Modules

A simplified syntax is allowed for a stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) that defines only a single template rule for the document node. The stylesheet module may consist of just a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element) (see 11.1 Literal Result Elements) together with its contents. The literal result element must have an xsl:version attribute (and it must therefore also declare the XSLT namespace). Such a stylesheet module is equivalent to a standard stylesheet module whose xsl:stylesheet element contains a template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) containing the literal result element, minus its xsl:version attribute; the template rule has a match pattern (http://www.w3.org/TR/xslt20/#dt-pattern) of /.

Example: A Simplified Stylesheet
For example:

<html xsl:version="2.0"

      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

      xmlns="http://www.w3.org/1999/xhtml">

  <head>

    <title>Expense Report Summary</title>

  </head>

  <body>

Total Amount: <xsl:value-of select="expense-report/total"/>

  </body>

</html>

has the same meaning as

<xsl:stylesheet version="2.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

                xmlns="http://www.w3.org/1999/xhtml">

<xsl:template match="/">
<html>

  <head>

    <title>Expense Report Summary</title>

  </head>

  <body>

Total Amount: <xsl:value-of select="expense-report/total"/>

  </body>

</html>
</xsl:template>
</xsl:stylesheet>

Note that it is not possible, using a simplified stylesheet, to request that the serialized output contains a DOCTYPE declaration. This can only be done by using a standard stylesheet module, and using the xsl:output element.

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 template (http://www.w3.org/TR/xslt20/#dt-named-template) expand, with the containing literal result element as the context node (http://www.w3.org/TR/xslt20/#dt-context-node):

<xsl:stylesheet version="2.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template name="expand">

  <xsl:element name="xsl:stylesheet">

    <xsl:attribute name="version">

      <xsl:value-of select="@xsl:version"/>

    </xsl:attribute>

    <xsl:element name="xsl:template">

      <xsl:attribute name="match">/</xsl:attribute>

      <xsl:copy-of select="."/>

    </xsl:element>

  </xsl:element>

</xsl:template>

</xsl:stylesheet>

[ERR XT0150] A literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element) that is used as the outermost element of a simplified stylesheet module must have an xsl:version attribute. This indicates the version of XSLT that the stylesheet requires. For this version of XSLT, the value will normally be 2.0; the value must be a DecimalLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-DecimalLiteral) XP as defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

Other literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element) may also have an xsl:version attribute. When the xsl:version attribute is numerically less than 2.0, backwards-compatible processing behavior is enabled (see 3.8 Backwards-Compatible Processing). When the xsl:version attribute is numerically greater than 2.0, forwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-forwards-compatible-behavior) is enabled (see 3.9 Forwards-Compatible Processing).

The allowed content of a literal result element when used as a simplified stylesheet is the same as when it occurs within a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor). Thus, a literal result element used as the document element of a simplified stylesheet cannot contain declarations (http://www.w3.org/TR/xslt20/#dt-declaration).

3.8 Backwards-Compatible Processing

[Definition: An element enables backwards-compatible behavior for itself, its attributes, its descendants and their attributes if it has an [xsl:]version attribute (see 3.5 Standard Attributes) whose value is less than 2.0.]

An element that has an [xsl:]version attribute whose value is greater than or equal to 2.0 disables backwards-compatible behavior for itself, its attributes, its descendants and their attributes. The compatibility behavior established by an element overrides any compatibility behavior established by an ancestor element.

If an attribute containing an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) is processed with backwards-compatible behavior, then the expression is evaluated with XPath 1.0 compatibility mode (http://www.w3.org/TR/xslt20/#dt-compatibility-mode) set to true. For details of this mode, see Section (http://www.w3.org/TR/xpath20/#dt-static-context) XP.

Certain XSLT constructs also produce different results when backwards-compatible behavior is enabled. This is described separately for each such construct.

These rules do not apply to the xsl:output element, whose version attribute has an entirely different purpose: it is used to define the version of the output method to be used for serialization.

Note:

By making use of backwards-compatible behavior, it is possible to write the stylesheet in a way that ensures that its results when processed with an XSLT 2.0 processor are identical to the effects of processing the same stylesheet using an XSLT 1.0 processor. The differences are described (non-normatively) in K.1 Incompatible Changes. To assist with transition, some parts of a stylesheet may be processed with backwards compatible behavior enabled, and other parts with this behavior disabled. All data values manipulated by an XSLT 2.0 processor are defined by the XPath 2.0 data model, whether or not the relevant expressions use backwards compatible behavior. Because the same data model is used in both cases, expressions are fully composable. The result of evaluating instructions or expressions with backwards compatible behavior is fully defined in the XSLT 2.0 and XPath 2.0 specifications, it is not defined by reference to the XSLT 1.0 and XPath 1.0 specifications.

It is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) whether a particular XSLT 2.0 implementation supports backwards-compatible behavior.

[ERR XT0160] If an implementation does not support backwards-compatible behavior, then it is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if any element is evaluated that enables backwards-compatible behavior.

Note:

To write a stylesheet that works with both XSLT 1.0 and 2.0 processors, while making selective use of XSLT 2.0 facilities, it is necessary to understand both the rules for backwards-compatible behavior in XSLT 2.0, and the rules for forwards-compatible behavior in XSLT 1.0. If the xsl:stylesheet element specifies version="2.0", then an XSLT 1.0 processor will ignore XSLT 2.0 declarations (http://www.w3.org/TR/xslt20/#dt-declaration) that were not defined in XSLT 1.0, for example xsl:function and xsl:import-schema. If any new XSLT 2.0 instructions are used (for example xsl:analyze-string or xsl:namespace), or if new XPath 2.0 features are used (for example, new functions, or syntax such as conditional expressions, or calls to a function defined using xsl:function), then the stylesheet must provide fallback behavior that relies on XSLT 1.0 and XPath 1.0 facilities only. The fallback behavior can be invoked by using the xsl:fallback instruction, or by testing the results of the function-available or element-available functions, or by testing the value of the xsl:version property returned by the system-property function.

3.9 Forwards-Compatible Processing

[Definition: An element enables forwards-compatible behavior for itself, its attributes, its descendants and their attributes if it has an [xsl:]version attribute (see 3.5 Standard Attributes) whose value is greater than 2.0.]

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

These rules do not apply to the version attribute of the xsl:output element, which has an entirely different purpose: it is used to define the version of the output method to be used for serialization.

Within a section of a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) where forwards-compatible behavior is enabled, errors that would normally be static errors (http://www.w3.org/TR/xslt20/#dt-static-error) are treated instead as dynamic errors (http://www.w3.org/TR/xslt20/#dt-dynamic-error). This means that no error is signaled unless the construct containing the error is actually evaluated.

This includes, but is not limited to, the following situations:

if an element in the XSLT namespace appears as a child of the xsl:stylesheet element, and XSLT 2.0 does not allow such elements as declarations, then the element must be ignored along with its content;

if an element in the XSLT namespace appears in a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) and XSLT 2.0 does not allow such elements to occur in sequence constructors, then the processor (http://www.w3.org/TR/xslt20/#dt-processor) must not signal an error, and if the element is evaluated, the processor (http://www.w3.org/TR/xslt20/#dt-processor) must perform fallback for the element as specified in 18.2.3 Fallback;

if an element has an attribute that XSLT 2.0 does not allow the element to have, then the attribute must be ignored.

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

if an instruction element has a mandatory attribute with a value that XSLT 2.0 does not allow the attribute to have, then the error must not be signaled unless the instruction is actually evaluated.

if an attribute contains an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) that does not match the allowed syntax of an XPath 2.0 expression, the error must not be signaled unless the expression is actually evaluated.

if an attribute contains an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) that calls a function that cannot be identified by its name and arity (http://www.w3.org/TR/xslt20/#dt-arity), the error must not be signaled unless the function call is actually evaluated.

Example: Forwards Compatible Behavior
For example, an XSLT 2.0 processor (http://www.w3.org/TR/xslt20/#dt-processor) will process the following stylesheet without error, although the stylesheet includes elements from the XSLT namespace (http://www.w3.org/TR/xslt20/#dt-xslt-namespace) that are not defined in this specification:

<xsl:stylesheet version="17.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:template match="/">

    <xsl:choose>

      <xsl:when test="system-property('xsl:version') >= 17.0">

        <xsl:exciting-new-17.0-feature/>

      </xsl:when>

      <xsl:otherwise>

        <html>

        <head>

          <title>XSLT 17.0 required</title>

        </head>

        <body>

Sorry, this stylesheet requires XSLT 17.0.

        </body>

        </html>

      </xsl:otherwise>

    </xsl:choose>

  </xsl:template>

</xsl:stylesheet>

Note:

If a stylesheet depends crucially on a declaration (http://www.w3.org/TR/xslt20/#dt-declaration) introduced by a version of XSLT after 2.0, then the stylesheet can use an xsl:message element with terminate="yes" (see 17 Messages) to ensure that implementations that conform to an earlier version of XSLT will not silently ignore the declaration (http://www.w3.org/TR/xslt20/#dt-declaration).

Example: Testing the XSLT Version
For example,

<xsl:stylesheet version="18.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

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

  <xsl:template match="/">

    <xsl:choose>

      <xsl:when test="number(system-property('xsl:version')) < 17.0">

        <xsl:message terminate="yes">

          <xsl:text>Sorry, this stylesheet requires XSLT 17.0.</xsl:text>

        </xsl:message>

      </xsl:when>

      <xsl:otherwise>

        ...

      </xsl:otherwise>

    </xsl:choose>

  </xsl:template>

  ...

</xsl:stylesheet>

3.10 Combining Stylesheet Modules

XSLT提供了两种用多个stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module)构建一个stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet)的机制：

一种是包括机制（inclusion mechanism），这种机制在不修改各个module语义的情况下结合多个stylesheet module

一种是引入机制（import mechanism），这种机制允许各个stylesheet module相互重叠。

3.10.1 Locating Stylesheet Modules

The include and import mechanisms use two declarations, xsl:include and xsl:import, which are defined in the sections that follow.

These declarations use an href attribute, whose value is a URI reference, to identify the stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) to be included or imported. If the value of this attribute is a relative URI, it is resolved using the algorithm defined in [RFC2396 (http://www.w3.org/TR/xslt20/#RFC2396)], relative to the base URI of the xsl:include or xsl:import element as defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)].

After resolving against the base URI, the way in which the URI reference is used to locate a stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined). In particular, it is implementation-defined which URI schemes are supported, whether fragment identifiers are supported, and what media types are supported. Conventionally, the URI is a reference to a resource containing the stylesheet module as a source XML document, or it may include a fragment identifier that selects an embedded stylesheet module within a source XML document; but the implementation is free to use other mechanisms to locate the stylesheet module identified by the URI reference.

The referenced stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) may be any of the four kinds of stylesheet module: that is, it may be standalone (http://www.w3.org/TR/xslt20/#dt-standalone-stylesheet-module) or embedded (http://www.w3.org/TR/xslt20/#dt-embedded-stylesheet-module), and it may be standard (http://www.w3.org/TR/xslt20/#dt-standard-stylesheet-module) or simplified (http://www.w3.org/TR/xslt20/#dt-simplified-stylesheet-module). If it is a simplified stylesheet module (http://www.w3.org/TR/xslt20/#dt-simplified-stylesheet-module) then it is transformed into the equivalent standard stylesheet module (http://www.w3.org/TR/xslt20/#dt-standard-stylesheet-module) by applying the transformation described in 3.7 Simplified Stylesheet Modules.

Implementations may choose to accept URI references containg a fragment identifier defined by reference to the XPointer specification (see [XPointer (http://www.w3.org/TR/xslt20/#XPOINTER)]). Note that if the implementation does not support the use of fragment identifiers in the URI reference, then it will not be possible to include an embedded stylesheet module (http://www.w3.org/TR/xslt20/#dt-embedded-stylesheet-module).

[ERR XT0165] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the processor is not able to retrieve the resource identified by the URI reference, or if the resource that is retrieved does not contain a stylesheet module conforming to this specification.

3.10.2 Stylesheet Inclusion

<xsl:include

  href = uri-reference />

A stylesheet module may include another stylesheet module using an xsl:include declaration.

The xsl:include declaration has a required href attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.10.1 Locating Stylesheet Modules.

[ERR XT0170] An xsl:include element must be a top-level (http://www.w3.org/TR/xslt20/#dt-top-level) element.

[Definition: A stylesheet level is a collection of stylesheet modules (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) connected using xsl:include declarations: specifically, two stylesheet modules A and B are part of the same stylesheet level if one of them includes the other by means of an xsl:include declaration, or if there is a third stylesheet module C that is in the same stylesheet level as both A and B.]

[Definition: The declarations (http://www.w3.org/TR/xslt20/#dt-declaration) within a stylesheet level (http://www.w3.org/TR/xslt20/#dt-stylesheet-level) have a total ordering known as declaration order. The order of declarations within a stylesheet level is the same as the document order that would result if each stylesheet module were inserted textually in place of the xsl:include element that references it.] In other respects, however, the effect of xsl:include is not equivalent to the effect that would be obtained by textual inclusion.

[ERR XT0180] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if a stylesheet module directly or indirectly includes itself.

Note:

It is not intrinsically an error for a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) to include the same module more than once. However, doing so can cause errors because of duplicate definitions. Such multiple inclusions are less obvious when they are indirect. For example, if stylesheet B includes stylesheet A, stylesheet C includes stylesheet A, and stylesheet D includes both stylesheet B and stylesheet C, then A will be included indirectly by D twice. If all of B, C and D are used as independent stylesheets, then the error can be avoided by separating everything in B other than the inclusion of A into a separate stylesheet B' and changing B to contain just inclusions of B' and A, similarly for C, and then changing D to include A, B', C'.

3.10.3 Stylesheet Import

<xsl:import

  href = uri-reference />

A stylesheet module may import another stylesheet module (http://www.w3.org/TR/xslt20/#dt-stylesheet-module) using an xsl:import declaration (http://www.w3.org/TR/xslt20/#dt-declaration). Importing a stylesheet module is the same as including it (see 3.10.2 Stylesheet Inclusion) except that template rules (http://www.w3.org/TR/xslt20/#dt-template-rule) and other declarations (http://www.w3.org/TR/xslt20/#dt-declaration) in the importing module take precedence over template rules and declarations in the imported module; this is described in more detail below.

The xsl:import declaration has a required href attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.10.1 Locating Stylesheet Modules.

[ERR XT0190] An xsl:import element must be a top-level (http://www.w3.org/TR/xslt20/#dt-top-level) element.

[ERR XT0200] The xsl:import element children must precede all other element children of an xsl:stylesheet element, including any xsl:include element children and any user-defined data elements (http://www.w3.org/TR/xslt20/#dt-data-element).

Example: Using xsl:import
For example,

<xsl:stylesheet version="2.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

  <xsl:import href="article.xsl"/>

  <xsl:import href="bigfont.xsl"/>

  <xsl:attribute-set name="note-style">

    <xsl:attribute name="font-style">italic</xsl:attribute>

  </xsl:attribute-set>

</xsl:stylesheet>

[Definition: The stylesheet levels (http://www.w3.org/TR/xslt20/#dt-stylesheet-level) making up a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) are treated as forming an import tree. In the import tree, each stylesheet level has one child for each xsl:import declaration that it contains.] The ordering of the children is the declaration order (http://www.w3.org/TR/xslt20/#dt-declaration-order) of the xsl:import declarations within their stylesheet level.

[Definition: A declaration (http://www.w3.org/TR/xslt20/#dt-declaration) D in the stylesheet is defined to have lower import precedence than another declaration E if the stylesheet level containing D would be visited before the stylesheet level containing E in a post-order traversal of the import tree (that is, a traversal of the import tree in which a stylesheet level is visited after its children). Two declarations within the same stylesheet level have the same import precedence.]

For example, suppose

stylesheet module A imports stylesheet modules B and C in that order;

stylesheet module B imports stylesheet module D;

stylesheet module C imports stylesheet module E.

Then the import tree has the following structure:

         A

         |

     +---+---+

     |       |

     B       C

     |       |

     D       E

The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration (http://www.w3.org/TR/xslt20/#dt-declaration) with higher import precedence takes precedence over a declaration with lower import precedence. This is defined in detail for each kind of declaration.

[ERR XT0210] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if a stylesheet module directly or indirectly imports itself.

Note:

The case where a stylesheet module with a particular URI is imported several times is not treated specially. The effect is exactly the same as if several stylesheet modules with different URIs but identical content were imported. This might or might not cause an error, depending on the content of the stylesheet module.

3.11 Embedded Stylesheet Modules

A standalone stylesheet module (http://www.w3.org/TR/xslt20/#dt-standalone-stylesheet-module) is a complete XML document with the xsl:stylesheet element as its document element. However, a stylesheet module may also be embedded in another resource. Two forms of embedding are possible:

the XSLT stylesheet may be textually embedded in a non-XML resource, or

the xsl:stylesheet element may occur in an XML document other than as the document element.

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

Note:

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

Example: The xml-stylesheet Processing Instruction
The following example shows how the xml-stylesheet processing instruction (see [XML Stylesheet (http://www.w3.org/TR/xslt20/#XMLSTYLE)]) can be used to allow a source document to contain its own stylesheet. The URI reference uses a relative URI with a fragment identifier to locate the xsl:stylesheet element:

<?xml-stylesheet type="application/xslt+xml" href="#style1"?>
<!DOCTYPE doc SYSTEM "doc.dtd">
<doc>
<head>
<xsl:stylesheet id="style1"

                version="2.0"

                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

                xmlns:fo="http://www.w3.org/1999/XSL/Format">

<xsl:import href="doc.xsl"/>
<xsl:template match="id('foo')">

  <fo:block font-weight="bold"><xsl:apply-templates/></fo:block>

</xsl:template>
<xsl:template match="xsl:stylesheet">
<xsl:import-schema

  namespace? = uri-reference
  schema-location? = uri-reference />

The xsl:import-schema declaration is used to identify schema components (http://www.w3.org/TR/xslt20/#dt-schema-component) (that is, top-level type definitions and top-level element and attribute declarations) that need to be available statically, that is, before any source document is available. Names of such components used statically within the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) must refer to an in-scope schema component (http://www.w3.org/TR/xslt20/#dt-in-scope-schema-component), which means they must either be built-in types as defined in 3.12 Built-in Types, or they must be imported using an xsl:import-schema declaration.

The xsl:import-schema declaration identifies a namespace containing the names of the components to be imported (or indicates that components whose names are in no namespace are to be imported). The effect is that the names of top-level element and attribute declarations and type definitions from this namespace (or non-namespace) become available for use within XPath expressions in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), and within other stylesheet constructs such as the type and as attributes of various XSLT elements.

The same schema components are available in all stylesheet modules; importing components in one stylesheet module makes them available throughout the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet).

The namespace and schema-location attributes are both optional.

If two xsl:import-schema declarations specify the same namespace, or if both specify no namespace, then only the one with highest import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) is used. If this leaves more than one, then all the declarations at the highest import precedence are used (which may cause conflicts, as described below).

After discarding any xsl:import-schema declarations under the above rule, the effect of the remaining xsl:import-schema declarations is defined in terms of a hypothetical document called the synthetic schema document, which is constructed as follows. The synthetic schema document defines an arbitrary target namespace that is different from any namespace actually used by the application, and it contains xs:import elements corresponding one-for-one with the xsl:import-schema declarations in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), with the following correspondence:

The namespace attribute of the xs:import element is copied from the namespace attribute of the xsl:import-schema declaration if present, and is absent if it is absent.

The schemaLocation attribute of the xs:import element is copied from the schema-location attribute of the xsl:import-schema declaration if present, and is absent if it is absent.

The base URI of the xs:import element is the same as the base URI of the xsl:import-schema declaration.

The schema components included in the in-scope schema components (http://www.w3.org/TR/xslt20/#dt-in-scope-schema-component) (that is, the components whose names are available for use within the stylesheet) are the top-level element and attribute declarations and type definitions that are available for reference within the synthetic schema document. See [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] (Part 1, section 4.2.3, References to schema components across namespaces).

[ERR XT0220] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the synthetic schema document does not satisfy the constraints described in [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] (Part 1, section 5.1, Errors in Schema Construction and Structure). This includes, without loss of generality, conflicts such as multiple definitions of the same name..

Note:

The synthetic schema document does not need to be constructed by a real implementation. It is purely a mechanism for defining the semantics of xsl:import-schema in terms of rules that already exist within the XML Schema specification. In particular, it implicitly defines the rules that determine whether the set of xsl:import-schema declarations are mutually consistent.

These rules do not cause names to be imported transitively. The fact that a name is available for reference within a schema document A does not of itself make the name available for reference in a stylesheet that imports the target namespace of schema document A. (See [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] Part 1, section 3.15.3, Constraints on XML Representations of Schemas.) The stylesheet must import all the namespaces containing names that it actually references.

The namespace attribute indicates that a schema for the given namespace is required by the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet). This information may be enough on its own to enable an implementation to locate the required schema components. The namespace attribute may be omitted to indicate that a schema for names in no namespace is being imported. The zero-length string is not a valid namespace URI, and is therefore not a valid value for the namespace attribute.

The schema-location attribute gives a hint indicating where a schema document or other resource containing the required definitions may be found. It is likely that a schema-aware XSLT processor (http://www.w3.org/TR/xslt20/#dt-schema-aware-xslt-processor) will be able to process a schema document found at this location.

The XML Schema specification gives implementations flexibility in how to handle multiple imports for the same namespace. Multiple imports do not cause errors if the definitions do not conflict.

A consequence of these rules is that it is not intrinsically an error if no schema document can be located for a namespace identified in an xsl:import-schema declaration. This will cause an error only if it results in the stylesheet containing references to names that have not been imported.

The use of a namespace in an xsl:import-schema declaration does not by itself associate any namespace prefix with the namespace. If names from the namespace are used within the stylesheet module then a namespace declaration must be included in the stylesheet module, in the usual way.

4 Data Model

The data model used by XSLT is the XPath 2.0 and XQuery 1.0 data model, as defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]. XSLT operates on source, result and stylesheet documents using the same data model.

This section elaborates on some particular features of the data model as it is used by XSLT:

The rules in 4.2 Stripping Whitespace from the Stylesheet and 4.3 Stripping Whitespace from a Source Tree make use of the concept of a whitespace text node.

[Definition: A whitespace text node is a text node whose content consists entirely of whitespace characters (that is, #x09, #x0A, #x0D, or #x20).]

Note:

Features of a source XML document that are not represented in the tree defined by the data model will have no effect on the operation of an XSLT stylesheet. Examples of such features are entity references, CDATA sections, character references, whitespace within element tags, and the choice of single or double quotes around attribute values.

4.1 XML Versions

The data model defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)] is capable of representing either an XML 1.0 document (conforming to [XML 1.0 (http://www.w3.org/TR/xslt20/#XML)] and [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)]) or an XML 1.1 document (conforming to [XML 1.1 (http://www.w3.org/TR/xslt20/#XML1.1)] and [XML Namespaces 1.1 (http://www.w3.org/TR/xslt20/#XMLNAMES1.1)]), and it makes no distinction between the two. In principle, therefore, XSLT 2.0 can be used with either of these XML versions; the only differences arise outside the boundary of the transformation proper, either while creating the data model from textual XML (parsing), or while producing textual XML from the data model (serialization).

Construction of the data model is outside the scope of this specification, so XSLT 2.0 places no formal requirements on an XSLT processor to accept input from either XML 1.0 documents or XML 1.1 documents or both. This specification does define a serialization capability (see 20 Serialization), though from a conformance point of view it is an optional feature. Although facilities are described for serializing the data model as either XML 1.0 or XML 1.1 (and controlling the choice), there is again no formal requirement on an XSLT processor to support either or both of these XML versions as serialization targets.

Because the data model is the same whether the original document was XML 1.0 or XML 1.1, the semantics of XSLT processing do not depend on the version of XML used by the original document. There is no reason in principle why all the input and output documents used in a single transformation must conform to the same version of XML.

Some of the syntactic constructs in XSLT 2.0 and XPath 2.0, for example the productions Char (http://www.w3.org/TR/2000/REC-xml-20001006#NT-Char) XML and NCName (http://www.w3.org/TR/REC-xml-names/#NT-NCName) Names, are defined by reference to the XML and XML Namespaces specifications. There are slight variations between the XML 1.0 and XML 1.1 versions of these productions. It is recommended that an XSLT 2.0 processor should implement the 1.1 versions.

At the time of writing there is no published version of [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] that references the XML 1.1 specifications. This means that data types such as xs:NCName and xs:ID are constrained by the XML 1.0 rules. It is recommended that an XSLT 2.0 processor should implement the rules in later versions of [XML Schema (http://www.w3.org/TR/xslt20/#XMLSCHEMA)] as they become available.

4.2 Stripping Whitespace from the Stylesheet

The tree representing the stylesheet is preprocessed as follows:

All comments and processing instructions are removed.

Any text nodes that are now adjacent to each other are merged.

Any whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) that satisfies both the following conditions is removed from the tree:

The parent of the text node is not an xsl:text element

The text node does not have an ancestor element that has an xml:space attribute with a value of preserve, unless there is a closer ancestor element having an xml:space attribute with a value of default.

Any whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) whose parent is one of the following elements is removed from the tree, regardless of any xml:space attributes:

xsl:analyze-string xsl:apply-imports xsl:apply-templates xsl:attribute-set xsl:call-template xsl:character-map xsl:choose xsl:next-match xsl:stylesheet xsl:transform

Any whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) whose following-sibling node is an xsl:param or xsl:sort element is removed from the tree, regardless of any xml:space attributes.

[ERR XT0260] Within an XSLT element that is required to be empty, any content other than comments or processing instructions, including any whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) preserved using the xml:space="preserve" attribute, is a static error (http://www.w3.org/TR/xslt20/#dt-static-error).

4.3 Stripping Whitespace from a Source Tree

A source document supplied as input to the transformation process may contain whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) that are of no interest, and that do not need to be retained by the transformation. Conceptually, an XSLT processor (http://www.w3.org/TR/xslt20/#dt-processor) makes a copy of the source tree from which unwanted whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) have been removed. This process is referred to as whitespace stripping.

The stripping process takes as input a set of element names whose child whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) are to be preserved.

A whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) is preserved if either of the following apply:

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

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

Otherwise, the whitespace text node (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) is stripped.

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

Note:

This implies that if an xml:space attribute is specified on a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element), it will be included in the result.

Note:

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

<xsl:strip-space

  elements = tokens />

<xsl:preserve-space

  elements = tokens />

The set of whitespace-preserving element names is specified by xsl:strip-space and xsl:preserve-space declarations (http://www.w3.org/TR/xslt20/#dt-declaration). Whether an element name is included in the set of whitespace-preserving names is determined by the best match among all the xsl:strip-space or xsl:preserve-space declarations: it is included if and only if there is no match or the best match is an xsl:preserve-space element. The xsl:strip-space and xsl:preserve-space elements each have an elements attribute whose value is a whitespace-separated list of NameTests (http://www.w3.org/TR/xpath20/#doc-xpath-NameTest) XP; an element name matches an xsl:strip-space or xsl:preserve-space element if it matches one of the NameTests (http://www.w3.org/TR/xpath20/#doc-xpath-NameTest) XP. An element matches a NameTest (http://www.w3.org/TR/xpath20/#doc-xpath-NameTest) XP if and only if the NameTest (http://www.w3.org/TR/xpath20/#doc-xpath-NameTest) XP would be true for the element as an XPath node test. When more than one xsl:strip-space and xsl:preserve-space element matches, the best matching element is determined by the best matching NameTest (http://www.w3.org/TR/xpath20/#doc-xpath-NameTest) XP. This is determined in the same way as with template rules (http://www.w3.org/TR/xslt20/#dt-template-rule):

First, any match with lower import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) than another match is ignored.

Next, any match that has a lower default priority (http://www.w3.org/TR/xslt20/#dt-default-priority) than the default priority (http://www.w3.org/TR/xslt20/#dt-default-priority) of another match is ignored.

[ERR XT0270] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if this leaves more than one match. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to select, from the matches that are left, the one that occurs last in declaration order (http://www.w3.org/TR/xslt20/#dt-declaration-order).

Note:

A source document is supplied as input to the XSLT processor (http://www.w3.org/TR/xslt20/#dt-processor) in the form of a tree conforming to the data model described in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]. Nothing in this specification states that this tree must be built by parsing an XML document; nor does it state that the application that constructs the tree is required to treat whitespace in any particular way. The provisions in this section relate only to whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) that are present in the tree supplied as input to the processor. In particular, the processor cannot preserve whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) unless they were actually present in the supplied tree.

4.4 Attributes Types and DTD Validation

The data model allows attribute nodes to have type annotations derived from schema processing. It is also possible for a limited set of type annotations (on attributes only) to be derived from DTD-based validation of a source document. Because the construction of the data model is outside the scope of XSLT processing, this specification (in common with [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]) neither requires nor prevents this. This section merely points out some of the consequences of the decision.

In general, creating type annotations based on DTD attribute types is likely to create some backwards compatibility problems. For example, an attribute annotated with type xs:NMTOKENS will have a different typed value (http://www.w3.org/TR/xslt20/#dt-typed-value) than if it were annotated as xdt:untypedAtomic. If the value of the colors attribute is red green blue, then the expression @colors = "red" will return true if the type annotation is xs:NMTOKENS, but false if the type annotation is xdt:untypedAtomic.

Special considerations apply to ID attributes, because in XSLT 1.0, attributes defined in a DTD as having type ID were explicitly recognized by the XPath id FO function. An XSLT 2.0 processor wishing to offer the best possible backwards compatibility should therefore recognize ID attributes during DTD processing, and annotate the resulting nodes accordingly, even though it does not recognize other DTD-based types such as NMTOKENS.

The conformance rules for a basic XSLT processor (http://www.w3.org/TR/xslt20/#dt-basic-xslt-processor) do not allow attribute nodes to be annotated with type xs:ID. For backwards compatibility reasons, however, a processor may implement the id FO function so that it recognizes attributes defined in a DTD as being ID attributes, even though they are not annotated as being of type xs:ID in the data model.

A basic XSLT processor (http://www.w3.org/TR/xslt20/#dt-basic-xslt-processor) does not allow nodes to be annotated as being of type xs:IDREF or xs:IDREFS, which means that with such a processor, the idref FO function will always return an empty sequence.

4.5 Disable Output Escaping

For backwards compatibility reasons, XSLT 2.0 continues to support the disable-output-escaping feature introduced in XSLT 1.0. This is an optional feature and implementations are not required to support it. A new facility, that of named character maps (http://www.w3.org/TR/xslt20/#dt-character-map) (see 20.1 Character Maps) is introduced in XSLT 2.0. It provides similar capabilities to disable-output-escaping, but without distorting the data model.

If an implementation (http://www.w3.org/TR/xslt20/#dt-implementation) supports the disable-output-escaping attribute of xsl:text, xsl:value-of, and xsl:attribute (see 20.2 Disabling Output Escaping), then the data model for trees constructed by the processor (http://www.w3.org/TR/xslt20/#dt-processor) is augmented with a boolean value representing the value of this property. This boolean value, however, can be set only within a final result tree that is being passed to the serializer.

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

Note:

In practice, the nodes in a final result tree will often be streamed directly from the XSLT processor to the serializer. In such an implementation, disable-output-escaping can be viewed not so much a property stored with nodes in the tree, but rather as additional information passed across the interface between the XSLT processor and the serializer.

5 Syntactic Constructs

5.1 Qualified Names

The name of a stylesheet-defined object, specifically a named template (http://www.w3.org/TR/xslt20/#dt-named-template), a mode (http://www.w3.org/TR/xslt20/#dt-mode), an attribute set (http://www.w3.org/TR/xslt20/#dt-attribute-set), a key (http://www.w3.org/TR/xslt20/#dt-key), a decimal-format (http://www.w3.org/TR/xslt20/#dt-decimal-format), a variable (http://www.w3.org/TR/xslt20/#dt-variable) or parameter (http://www.w3.org/TR/xslt20/#dt-parameter), a stylesheet function (http://www.w3.org/TR/xslt20/#dt-stylesheet-function), a named output definition (http://www.w3.org/TR/xslt20/#dt-output-definition), or a character map (http://www.w3.org/TR/xslt20/#dt-character-map) is specified as a QName (http://www.w3.org/TR/xslt20/#dt-qname) using the syntax for QName (http://www.w3.org/TR/REC-xml-names/#NT-QName)Names as defined in [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)].

[Definition: A QName is always written in the form (NCName ":")? NCName, that is, a local name optionally preceded by a namespace prefix. When two QNames are compared, however, they are considered equal if the corresponding expanded-QNames (http://www.w3.org/TR/xslt20/#dt-expanded-qname) are the same, as described below.]

Because an atomic value of type xs:QName is sometimes referred to loosely as a QName, this specification also uses the term lexical QName (http://www.w3.org/TR/xslt20/#dt-lexical-qname) to emphasize that it is referring to a QName (http://www.w3.org/TR/REC-xml-names/#NT-QName)Names in its lexical form rather than its expanded form. This term is used especially when strings containing lexical QNames are manipulated as run-time values.

[Definition: A lexical QName is a string representing a QName (http://www.w3.org/TR/xslt20/#dt-qname) in the form (NCName ":")? NCName, that is, a local name optionally preceded by a namespace prefix.]

[Definition: QNames may occur as the value of an attribute node in a stylesheet module, or within an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) contained in such an attribute node, or as the result of evaluating an XPath expression contained in such an attribute node. The element containing this attribute node is referred to as the defining element of the QName.]

[Definition: An expanded-QName is a pair of values containing a local name and an optional namespace URI. Two expanded-QNames are equal if the namespace URIs are the same (or both absent) and the local names are the same.]

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

There are two cases where the default namespace from the static context is used when expanding an unprefixed QName:

Where a QName is used to define the name of an element being constructed in the result tree. This applies both to cases where the name is known statically (that is, the name of a literal result element) and to cases where it is computed dynamically (the value of the name attribute of the xsl:element instruction).

The default namespace is used when expanding the first argument of the function element-available.

In the case of an unprefixed QName used as a NameTest within an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) (see 5.3 Expressions) , and in certain other contexts, the namespace to be used in expanding the QName may be specified by means of the [xsl:]xpath-default-namespace attribute, as specified in 5.2 Unprefixed QNames in Expressions and Patterns.

[ERR XT0280] In the case of a prefixed QName (http://www.w3.org/TR/xslt20/#dt-qname) used as the value of an attribute in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), or appearing within an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) in the stylesheet, it is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the defining element (http://www.w3.org/TR/xslt20/#dt-defining-element) has no namespace node whose name matches the prefix of the QName (http://www.w3.org/TR/xslt20/#dt-qname).

[ERR XT0290] Where the result of evaluating an XPath expression (or an attribute value template) is required to be a lexical QName (http://www.w3.org/TR/xslt20/#dt-lexical-qname), then unless otherwise specified it is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the defining element (http://www.w3.org/TR/xslt20/#dt-defining-element) has no namespace node whose name matches the prefix of the lexical QName (http://www.w3.org/TR/xslt20/#dt-lexical-qname). This error may be signaled as a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the value of the expression can be determined statically.

Note:

In some cases this is defined as a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error), for example when evaluating the name attribute of xsl:element and xsl:attribute

5.2 Unprefixed QNames in Expressions and Patterns

The attribute [xsl:]xpath-default-namespace (see 3.5 Standard Attributes) may be used on an element in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) to define the namespace that will be used for an unprefixed element name or type name within an XPath expression, and in certain other contexts listed below.

The value of the attribute is the namespace URI to be used.

For any element in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), this attribute has an effective value, which is the value of the [xsl:]xpath-default-namespace on that element or on the innermost containing element that specifies such an attribute, or the zero-length string if no containing element specifies such an attribute.

For any element in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), the effective value of this attribute determines the value of the default namespace for element and type names in the static context of any XPath expression contained in an attribute of that element. The effect of this is specified in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]; in summary, it determines the namespace used for any unprefixed type name in the SequenceType production, and for any element name appearing in a path expression or in the SequenceType production.

The effective value of this attribute similarly applies to any of the following constructs appearing within its scope:

any unprefixed element name or type name used in a pattern (http://www.w3.org/TR/xslt20/#dt-pattern)

any unprefixed element name used in the elements attribute of the xsl:strip-space or xsl:preserve-space instructions

any unprefixed element name or type name used in the as attribute of an XSLT instructions

any unprefixed type name used in the type attribute of an XSLT instruction.

The [xsl:]xpath-default-namespace attribute must be in the XSLT namespace if and only if its parent element is not in the XSLT namespace.

If the effective value of the attribute is a zero-length string, which will be the case if it is explicitly set to a zero-length string or if it is not specified at all, then an unprefixed element name or type name refers to a name that is in no namespace. The default namespace (as defined by an xmlns="some-uri" declaration) is not used.

The attribute does not affect other names, for example function names, variable names, or names used as arguments to the key or system-property functions.

5.3 Expressions

XSLT uses the expression language defined by XPath 2.0 [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]. Expressions are used in XSLT for a variety of purposes including:

selecting nodes for processing;

specifying conditions for different ways of processing a node;

generating text to be inserted in the result tree.

[Definition: Within this specification, the term XPath expression, or simply expression, means a string that matches the production Expr (http://www.w3.org/TR/xpath20/#doc-xpath-Expr)XP defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].]

An XPath expression may occur as the value of certain attributes on XSLT-defined elements, and also within curly brackets in attribute value templates (http://www.w3.org/TR/xslt20/#dt-attribute-value-template).

[ERR XT0300] Except where forwards-compatible behavior (http://www.w3.org/TR/xslt20/#dt-forwards-compatible-behavior) is enabled (see 3.9 Forwards-Compatible Processing), it is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the value of such an attribute, or the text between curly brackets in an attribute value template, does not match the XPath production Expr (http://www.w3.org/TR/xpath20/#doc-xpath-Expr)XP, or if it fails to satisfy other static constraints defined in the XPath specification, for example that all variable references must refer to variables (http://www.w3.org/TR/xslt20/#dt-variable) that are in scope.

[ERR XT0310] The transformation fails with a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if any XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) is evaluated and raises a dynamic error.

[ERR XT0320] The transformation fails with a type error (http://www.w3.org/TR/xslt20/#dt-type-error) if an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) raises a type error, or if the result of evaluating the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) is evaluated and raises a type error, or if the XPath processor signals a type error during static analysis of an expression (http://www.w3.org/TR/xslt20/#dt-expression).

[Definition: The context within a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) where an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) appears may specify the required type of the expression. The required type indicates the data type of value that the expression is expected to return.] If no required type is specified, the expression may return any value: in effect, the required type is then item()*.

[Definition: Except where otherwise indicated, the actual value of an expression (http://www.w3.org/TR/xslt20/#dt-expression) is converted to the required type (http://www.w3.org/TR/xslt20/#dt-required-type) using the function conversion rules. These are the rules defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)] for converting the supplied argument of a function call to the required type of that argument, as defined in the function signature. The relevant rules are those that apply when XPath 1.0 compatibility mode (http://www.w3.org/TR/xslt20/#dt-compatibility-mode) is set to false.]

This specification also invokes the XPath 2.0 function conversion rules (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules) to convert the result of evaluating an XSLT sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) to a required type (for example, the sequence constructor enclosed in an xsl:variable, xsl:template, or xsl:function element).

Any dynamic error (http://www.w3.org/TR/xslt20/#dt-dynamic-error) or type error (http://www.w3.org/TR/xslt20/#dt-type-error) that occurs when applying the function conversion rules (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules) to convert a value to a required type results in the transformation failing, in the same way as if the error had occurred while evaluating an expression.

Note:

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

XPath defines the concept of an expression context (http://www.w3.org/TR/xpath20/#dt-expression-context)XP which contains all the information that can affect the result of evaluating an expression (http://www.w3.org/TR/xslt20/#dt-expression). The evaluation context has two parts, the static context (http://www.w3.org/TR/xpath20/#dt-static-context)XP, and the dynamic context (http://www.w3.org/TR/xpath20/#dt-dynamic-context)XP. The components that make up the expression context are defined in the XPath specification (see Section 2.1 Expression Context (http://www.w3.org/TR/xpath20/#context)XP). The following paragraphs describe the way in which these components are initialized when an XPath expression is contained within an XSLT stylesheet.

5.3.1 Initializing the Static Context

The static context (http://www.w3.org/TR/xpath20/#dt-static-context)XP of an XPath expression appearing in an XSLT stylesheet is initialized as follows. In these rules, the term containing element means the element within the stylesheet that is the parent of the attribute whose value contains the XPath expression in question.

XPath 1.0 compatibility mode (http://www.w3.org/TR/xslt20/#dt-compatibility-mode) is set to true if and only if the containing element occurs in part of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) where backwards compatible behavior (http://www.w3.org/TR/xslt20/#dt-backwards-compatible-behavior) is enabled (see 3.8 Backwards-Compatible Processing).

The in-scope namespaces (http://www.w3.org/TR/xpath20/#dt-is-namespaces)XP are the namespace declarations that are in scope for the containing element.

The default namespace for element names and type names (http://www.w3.org/TR/xpath20/#dt-def-elemtype-ns)XP is the namespace defined by the [xsl:]xpath-default-namespace attribute on the innermost containing element that has such an attribute, as described in 5.2 Unprefixed QNames in Expressions and Patterns. The value of this attribute is a namespace URI. If there is no [xsl:]xpath-default-namespace attribute on a containing element, the default namespace for element names and type names is the null namespace.

The default namespace for function names (http://www.w3.org/TR/xpath20/#dt-def-fn-ns)XP is the standard function namespace (http://www.w3.org/TR/xslt20/#dt-standard-function-namespace), defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)]. This means that it is not necessary to declare this namespace in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), nor is it necessary to use the prefix fn (or any other prefix) in calls to the core functions.

The in-scope schema definitions (http://www.w3.org/TR/xpath20/#dt-issd)XP for the XPath expression are the same as the in-scope schema components (http://www.w3.org/TR/xslt20/#dt-in-scope-schema-component) for the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), and are as specified in 3.12 Built-in Types.

The in-scope variables (http://www.w3.org/TR/xpath20/#dt-is-vars)XP are defined by the variable binding elements (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) that are in scope for the containing element (see 9 Variables and Parameters).

The in-scope functions (http://www.w3.org/TR/xpath20/#dt-is-funcs)XP are the core functions defined in [Functions and Operators (http://www.w3.org/TR/xslt20/#FANDO)], the additional functions defined in this specification, the stylesheet functions (http://www.w3.org/TR/xslt20/#dt-stylesheet-function) defined in the stylesheet, plus any extension functions (http://www.w3.org/TR/xslt20/#dt-extension-function) bound using implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined) mechanisms (see 18 Extensibility and Fallback).

[ERR XT0330] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) for an expression (http://www.w3.org/TR/xslt20/#dt-expression) to call any function that is not included in the in-scope functions. This error occurs only if the function call is actually evaluated.

The in-scope collations (http://www.w3.org/TR/xpath20/#dt-is-collations)XP are implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined). However, the set of in-scope collations must always include the Unicode codepoint collation, defined in Section 7.3 Equality and Comparison of Strings (http://www.w3.org/TR/xpath-functions/#string-compare)FO.

The default collation (http://www.w3.org/TR/xpath20/#dt-def-collation)XP is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined).

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

This collation is also used by default when comparing strings in the evaluation of the xsl:key and xsl:for-each-group elements. This may also (but need not necessarily) be the same as the default collation used for xsl:sort elements within the stylesheet. Collations used by xsl:sort are described in 13.1.3 Sorting using Collations.

Implementations should provide a mechanism allowing the user to select the default collation (http://www.w3.org/TR/xslt20/#dt-default-collation) to be used by XPath expressions within a stylesheet.

The base URI (http://www.w3.org/TR/xpath20/#dt-base-uri)XP is the base URI of the containing element. The concept of the base URI of a node is defined in Section 5.1 base-uri Accessor (http://www.w3.org/TR/xpath-datamodel/#dm-base-uri)DM

5.3.2 Initializing the Dynamic Context

The dynamic context (http://www.w3.org/TR/xpath20/#dt-dynamic-context)XP of an XPath expression appearing in an XSLT stylesheet is initialized as follows.

Where the containing element is an instruction (http://www.w3.org/TR/xslt20/#dt-instruction) or a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element), the initial context item, context position, and context size for the XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) are the same as the context item (http://www.w3.org/TR/xslt20/#dt-context-item), context position (http://www.w3.org/TR/xslt20/#dt-context-position), and context size (http://www.w3.org/TR/xslt20/#dt-context-size) for the evaluation of the containing instruction or literal result element.

In other cases, the rules are given in the specification of the containing element.

The dynamic variables (http://www.w3.org/TR/xpath20/#dt-dyn-vars)XP are the current values of the in-scope variable binding elements (http://www.w3.org/TR/xslt20/#dt-variable-binding-element).

The current date and time represents an implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent) point in time during processing of the transformation; it does not change during the course of the transformation.

The implicit timezone (http://www.w3.org/TR/xpath20/#dt-timezone)XP is implementation-defined (http://www.w3.org/TR/xslt20/#dt-implementation-defined).

The available documents (http://www.w3.org/TR/xpath20/#dt-known-docs)XP, and the available collections (http://www.w3.org/TR/xpath20/#dt-known-collections)XP are implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent).

The available documents (http://www.w3.org/TR/xpath20/#dt-known-docs)XP are defined as part of the XPath 2.0 dynamic context to support the doc FO function, but this variable is also referenced by the similar XSLT document function: see 16.1 Multiple Source Documents. This variable defines a mapping between URIs passed to the doc FO or document function and the document nodes that are returned.

Note:

Defining this as part of the evaluation context is a formal way of specifying that the way in which URIs get turned into document nodes is outside the control of the language specification, and depends entirely on the run-time environment in which the transformation takes place.

Unlike the doc FO function, the XSLT-defined document function allows the use of URI references containing fragment identifiers. The interpretation of a fragment identifier depends on the media type of the resource. Therefore, the information supplied in available documents (http://www.w3.org/TR/xpath20/#dt-known-docs)XP for XSLT processing must provide not only a mapping from URIs to document nodes as required by XPath, but also a mapping from URIs to media types.

5.4 Patterns

A template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) identifies the nodes to which it applies by means of a pattern. As well as being used in template rules, patterns are used for numbering (see 12 Numbering), for grouping (see 14 Grouping), and for declaring keys (http://www.w3.org/TR/xslt20/#key) (see 16.3 Keys).

[Definition: A pattern specifies a set of conditions on a node. A node that satisfies the conditions matches the pattern; a node that does not satisfy the conditions does not match the pattern. The syntax for patterns is a subset of the syntax for expressions (http://www.w3.org/TR/xslt20/#dt-expression).] As explained in detail below, a node matches a pattern if the node can be selected by deriving an equivalent expression, and evaluating this expression with respect to some possible context.

Example: Patterns
Here are some examples of patterns:

para matches any para element.

• matches any element.

chapter|appendix matches any chapter element and any appendix element.

olist/entry matches any entry element with an olist parent.

appendix//para matches any para element with an appendix ancestor element.

element(us:address) matches any element that is annotated as an instance of the type defined by the schema element declaration us:address, and whose name is either us:address or the name of another element in its substitution group.

attribute(*, xs:date) matches any attribute annotated as being of type xs:date.

/ matches a document node.

document-node() matches a document node.

document-node(element(my:invoice)) matches the document node of a document whose document element matches the element declaration my:invoice.

text() matches any text node.

node() matches any node other than an attribute node, namespace node, or document node.

id("W33") matches the element with unique ID.

para[1] matches any para element that is the first para child element of its parent. It also matches a parentless para element.

//para matches any para element that has a parent node.

bullet[position() mod 2 = 0] matches any bullet element that is an even-numbered bullet child of its parent.

div[@class="appendix"]//p matches any p element with a div ancestor element that has a class attribute with value appendix.

@class matches any class attribute (not any element that has a class attribute).

@* matches any attribute node.

[ERR XT0340] Where an attribute is defined to contain a pattern (http://www.w3.org/TR/xslt20/#dt-pattern), it is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the pattern does not match the production Pattern (http://www.w3.org/TR/xslt20/#NT-Pattern). Every pattern is a legal XPath expression (http://www.w3.org/TR/xslt20/#dt-expression), but the converse is not true: 2+2 is an example of a legal XPath expression that is not a pattern. The XPath expressions that can be used as patterns are those that match the grammar for Pattern (http://www.w3.org/TR/xslt20/#NT-Pattern), given below.

Informally, a Pattern (http://www.w3.org/TR/xslt20/#NT-Pattern) is a set of path expressions separated by | or union, where each step in the path expression is constrained to be an AxisStep (http://www.w3.org/TR/xpath20/#doc-xpath-AxisStep) XP that uses only the child or attribute axes. Patterns may also use the // operator. Predicates (http://www.w3.org/TR/xpath20/#doc-xpath-Predicates) XP in a pattern can contain arbitrary XPath expressions (enclosed between square brackets) in the same way as predicates in a path expression.

Patterns may start with an id FO or key function call, provided that the value to be matched is supplied as either a literal or a reference to a variable (http://www.w3.org/TR/xslt20/#dt-variable) or parameter (http://www.w3.org/TR/xslt20/#dt-parameter), and the key name (in the case of the key function) is supplied as a string literal. These patterns will never match a node in a tree whose root is not a document node.

If a pattern occurs in part of the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) where backwards compatible behavior (http://www.w3.org/TR/xslt20/#dt-backwards-compatible-behavior) is enabled (see 3.8 Backwards-Compatible Processing), then the semantics of the pattern are defined on the basis that the equivalent XPath expression is evaluated with XPath 1.0 compatibility mode (http://www.w3.org/TR/xslt20/#dt-compatibility-mode) set to true.

Patterns

[1]
Pattern
 ::=
PathPattern (http://www.w3.org/TR/xslt20/#NT-PathPattern)




| Pattern (http://www.w3.org/TR/xslt20/#NT-Pattern) ('|' | 'union') PathPattern (http://www.w3.org/TR/xslt20/#NT-PathPattern)

[2]
PathPattern
 ::=
RelativePathPattern (http://www.w3.org/TR/xslt20/#NT-RelativePathPattern)




| '/' RelativePathPattern (http://www.w3.org/TR/xslt20/#NT-RelativePathPattern)?




| '//' RelativePathPattern (http://www.w3.org/TR/xslt20/#NT-RelativePathPattern)




| IdKeyPattern (http://www.w3.org/TR/xslt20/#NT-IdKeyPattern) (('/' | '//') RelativePathPattern (http://www.w3.org/TR/xslt20/#NT-RelativePathPattern))?

[3]
RelativePathPattern
 ::=
PatternStep (http://www.w3.org/TR/xslt20/#NT-PatternStep) (('/' | '//') RelativePathPattern (http://www.w3.org/TR/xslt20/#NT-RelativePathPattern))?

[4]
PatternStep
 ::=
PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis)? NodeTest (http://www.w3.org/TR/xpath20/#doc-xpath-NodeTest) XP Predicates (http://www.w3.org/TR/xpath20/#doc-xpath-Predicates) XP

[5]
PatternAxis
 ::=
('child' '::' | 'attribute' '::' | '@')

[6]
IdKeyPattern
 ::=
'id' '(' IdValue (http://www.w3.org/TR/xslt20/#NT-IdValue) ')'




| 'key' '(' StringLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-StringLiteral) XP ',' KeyValue (http://www.w3.org/TR/xslt20/#NT-KeyValue) ')'

[7]
IdValue
 ::=
StringLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-StringLiteral) XP | VarRef (http://www.w3.org/TR/xpath20/#doc-xpath-VarRef) XP

[8]
KeyValue
 ::=
Literal (http://www.w3.org/TR/xpath20/#doc-xpath-Literal) XP | VarRef (http://www.w3.org/TR/xpath20/#doc-xpath-VarRef) XP
The constructs NodeTest (http://www.w3.org/TR/xpath20/#doc-xpath-NodeTest) XP, Predicates (http://www.w3.org/TR/xpath20/#doc-xpath-Predicates) XP, VarRef (http://www.w3.org/TR/xpath20/#doc-xpath-VarRef) XP, Literal (http://www.w3.org/TR/xpath20/#doc-xpath-Literal) XP, and StringLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-StringLiteral) XP are part of the XPath expression language, and are defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

The meaning of a pattern is defined formally as follows.

First we define the concept of an equivalent expression. In general, the equivalent expression is the XPath expression that takes the same lexical form as the pattern as written. However, if the pattern contains a PathPattern that is a RelativePathPattern, then the first PatternStep PS of this RelativePathPattern is adjusted to allow it to match a parentless element or attribute node, as follows:

If the NodeTest in PS is document-node() (optionally with arguments), and if no explicit axis is specified, then the axis in step PS is taken as self rather than child.

If PS uses the child axis (explicitly or implicitly), and if the NodeTest in PS is not document-node() (optionally with arguments), then the axis in step PS is replaced by child-or-top, which is defined as follows. If the context node is a parentless element, comment, processing-instruction, or text node then the child-or-top axis selects the context node; otherwise it selects the children of the context node. It is a forwards axis whose principal node kind is element.

If PS uses the attribute axis, then the axis in step PS is replaced by attribute-or-top, which is defined as follows. If the context node is an attribute node with no parent, then the attribute-or-top axis selects the context node; otherwise it selects the attributes of the context node. It is a forwards axis whose principal node kind is attribute.

The axes child-or-top and attribute-or-top are introduced only for definitional purposes. They cannot be used explicitly in a user-written pattern or expression.

Note:

The purpose of these adjustments is to ensure that a pattern such as person matches any element named person, even if it has no parent; and similarly, that the pattern @width matches any attribute named width, even a parentless attribute. The rule also ensures that a pattern using a NodeTest of the form document-node(...) matches a document node. The pattern node() will match any element, text node, comment, or processing instruction, whether or not it has a parent. For backwards compatibility reasons, the pattern node(), when used without an explicit axis, does not match document nodes, attribute nodes, or namespace nodes. The rules are also phrased to ensure that positional patterns of the form para[1] continue to count nodes relative to their parent, if they have one.

Let the equivalent expression, calculated according to these rules, be EE.

To determine whether a node N matches the pattern, evaluate the expression (http://www.w3.org/TR/xslt20/#dt-expression) root(.)//(EE) with a singleton focus (http://www.w3.org/TR/xslt20/#dt-singleton-focus) based on N. If the result is a sequence of nodes that includes N, then node N matches the pattern; otherwise node N does not match the pattern.

Example: The Semantics of Patterns
For example, p matches any p element, because a p element will always be present in the result of evaluating the expression (http://www.w3.org/TR/xslt20/#dt-expression) root(.)//(child-or-top::p). Similarly, / matches a document node, and only a document node, because the result of the expression (http://www.w3.org/TR/xslt20/#dt-expression) root(.)//(/) returns the root node of the tree containing the context node if and only if it is a document node.

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

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

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

The way in which the processor evaluates a pattern may affect the detection of dynamic errors (http://www.w3.org/TR/xslt20/#dt-dynamic-error). For example, given the pattern chapter[P]/section[Q], where P and Q are arbitrary expressions, an error in evaluating Q might or might not be signaled while matching a section element that has no chapter parent, and an error in evaluating P might or might not be signaled while matching an element that is not a section. In general, it is well defined whether a node matches a pattern, but it is not well defined whether or not dynamic errors will be signaled when evaluating a pattern against a node that does not match the pattern.

One particular optimization is required by this specification: for a PathPattern (http://www.w3.org/TR/xslt20/#NT-PathPattern) that starts with / or // or with an IdKeyPattern (http://www.w3.org/TR/xslt20/#NT-IdKeyPattern), the result of testing this pattern against a node in a tree whose root is not a document node must be a non-match, rather than a dynamic error. This rule applies to each to each PathPattern (http://www.w3.org/TR/xslt20/#NT-PathPattern) within a Pattern (http://www.w3.org/TR/xslt20/#NT-Pattern).

Note:

Without the above rule, any attempt to apply templates to a parentless element node would create the risk of a dynamic error if the stylesheet has a template rule specifying match="/".

Note:

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

5.5 Attribute Value Templates

[Definition: In an attribute that is designated as an attribute value template, such as an attribute of a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element), an expression (http://www.w3.org/TR/xslt20/#dt-expression) can be used by surrounding the expression with curly brackets ({})].

An attribute value template consists of an alternating sequence of fixed parts and variable parts. A variable part consists of an XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) enclosed in curly brackets ({}). A fixed part may contain any characters, except that a left curly bracket must be written as Template:And a right curly bracket must be written as.

Note:

An expression within a variable part may contain an unescaped curly bracket within a StringLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-StringLiteral) XP or within a comment.

[ERR XT0350] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if an unescaped left curly bracket appears in a fixed part of an attribute value template without a matching right curly bracket.

[ERR XT0360] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the string contained between matching curly brackets in an attribute value template does not match the XPath production Expr (http://www.w3.org/TR/xpath20/#doc-xpath-Expr)XP.

[ERR XT0370] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if an unescaped right curly bracket occurs in a fixed part of an attribute value template.

[Definition: The result of evaluating an attribute value template is referred to as the effective value of the attribute.] The effective value is the string obtained by concatenating the expansions of the fixed and variable parts. The expansion of a fixed part is obtained by replacing any double curly brackets (Template:Or) by the corresponding single curly bracket. The expansion of a variable part is obtained by evaluating the enclosed XPath expression (http://www.w3.org/TR/xslt20/#dt-expression) and converting the resulting value to a string. This conversion is done by atomizing (http://www.w3.org/TR/xslt20/#dt-atomization) the result of the expression using the procedure defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)], and then converting each of the atomic values in the atomized sequence to a string, adding a single space after each value other than the last. If the atomized sequence is empty, the result is a zero-length string.

Note:

This process can generate dynamic errors, for example if the sequence contains an xs:QName (which cannot be cast to a string), or an element with a complex content type (which cannot be atomized).

If backwards compatible behavior (http://www.w3.org/TR/xslt20/#dt-backwards-compatible-behavior) is enabled for the attribute, the rules for converting the value of the expression to a string are modified as follows. After atomizing (http://www.w3.org/TR/xslt20/#dt-atomization) the result of the expression, all items other than the first item in the resulting sequence are discarded, and the effective value is obtained by converting the first item in the sequence to a string. If the atomized sequence is empty, the result is a zero-length string.

Curly brackets are not treated specially in an attribute value in an XSLT stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) unless the attribute is specifically designated as one that permits an attribute value template; in an element syntax summary, the value of such attributes is surrounded by curly brackets.

Note:

Not all attributes are designated as attribute value templates. Attributes whose value is an expression (http://www.w3.org/TR/xslt20/#dt-expression) or pattern (http://www.w3.org/TR/xslt20/#dt-pattern), attributes of declaration (http://www.w3.org/TR/xslt20/#dt-declaration) elements and attributes that refer to named XSLT objects are not designated as attribute value templates. Namespace declarations are not attribute nodes in the data model and are therefore never treated as attribute value templates.

Example: Attribute Value Templates
The following example creates an img result element from a photograph element in the source; the value of the src and width attributes are computed using XPath expressions enclosed in attribute value templates:

<xsl:variable name="image-dir" select="'/images'"/>

<xsl:template match="photograph">

  <img src="{$image-dir}/{href}" width="{size/@width}"/>

</xsl:template>

With this source

<photograph>

  <href>headquarters.jpg</href>

  <size width="300"/>

</photograph>

the result would be

<img src="/images/headquarters.jpg" width="300"/>

Example: Producing a Space-Separated List
The following example shows how the values in a sequence are output as a space-separated list. The following literal result element:

<temperature readings="{10.32, 5.50, 8.31}"/>

produces the output node:

<temperature readings="10.32 5.5 8.31"/>

Curly brackets are not recognized recursively inside expressions.

Example: Curly Brackets cannot be Nested
For example:

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

is not allowed. Instead, use simply:

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

5.6 Sequence Constructors

[Definition: A sequence constructor is a sequence of zero or more sibling nodes in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that can be evaluated to return a sequence of nodes and atomic values. The way that the resulting sequence is used depends on the containing instruction.]

Many XSLT elements (including literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element)) are defined to take a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) as their content.

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

Text nodes appearing in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) (if they have not been removed in the process of whitespace stripping: see 4.2 Stripping Whitespace from the Stylesheet) are copied to create a new parentless text node in the result sequence.

Literal result elements (http://www.w3.org/TR/xslt20/#dt-literal-result-element) are evaluated to create a new parentless element node, having the same expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) as the literal result element, which is added to the result sequence: see 11.1 Literal Result Elements

XSLT instructions (http://www.w3.org/TR/xslt20/#dt-instruction) produce a sequence of zero, one, or more items as their result. These items are added to the result sequence. For most XSLT instructions, these items are nodes, but some instructions (xsl:sequence and xsl:copy-of) can also produce atomic values. Several instructions, such as xsl:element, return a newly constructed parentless node (which may have its own attributes, namespaces, children, and other descendants). Other instructions, such as xsl:if, pass on the items produced by their own nested sequence constructors. The xsl:sequence instruction may return atomic values, or existing nodes.

Extension instructions (http://www.w3.org/TR/xslt20/#dt-extension-instruction) (see 18.2 Extension Instructions) also produce a sequence of items as their result. The items in this sequence are added to the result sequence.

There are several ways the result of a sequence constructor may be used.

The sequence may be bound to a variable or returned from a stylesheet function, in which case it becomes available as a value to be manipulated in arbitrary ways by XPath expressions. The sequence is bound to a variable when the sequence constructor appears within one of the elements xsl:variable, xsl:param, or xsl:with-param, when this instruction has an as attribute. The sequence is returned from a stylesheet function when the sequence constructor appears within the xsl:function element.

Note:

This will typically expose to the stylesheet elements, attributes, and other nodes that have not yet been attached to a parent node in a result tree. The semantics of XPath expressions when applied to parentless nodes are well-defined; however, such expressions should be used with care. For example, the expression / selects the root node of the tree containing the context node, which will not necessarily be a document node. The expression /E selects an E element child of the root node of the tree: if the root node is itself an E element, this expression will not select it.

Parentless attribute nodes require particular care because they have no namespace nodes associated with them. This means, for example, that the name FO function will not be able to determine a prefix to use when reporting the name of the attribute. When a parentless attribute node has content containing namespace prefixes (for example, a QName or an XPath expression) then there is no information allowing the prefix to be resolved to a namespace URI. Parentless attributes can be useful in an application (for example, they provide an alternative to the use of attribute sets: see 10.2 Named Attribute Sets) but they need to be handled with care.

The sequence may be returned as the result of the containing element. This happens when the instruction containing the sequence constructor is xsl:analyze-string, xsl:apply-imports, xsl:apply-templates, xsl:call-template, xsl:choose, xsl:fallback, xsl:for-each, xsl:for-each-group, xsl:if, xsl:matching-substring, xsl:next-match, xsl:non-matching-substring, xsl:otherwise, xsl:perform-sort, xsl:sequence, or xsl:when

The sequence may be used to construct the content of a new element or document node. This happens when the sequence constructor appears as the content of a literal result element, or of one of the instructions xsl:copy, xsl:element, or xsl:message. It also happens when the sequence constructor is contained in one of the elements xsl:variable, xsl:param, or xsl:with-param, when this instruction has no as attribute. For details, see 5.6.1 Constructing Complex Content.

The sequence may be used to construct the string value (http://www.w3.org/TR/xslt20/#dt-string-value) of an attribute node, text node, namespace node, comment node, or processing instruction node. This happens when the sequence constructor is contained in one of the elements xsl:attribute, xsl:value-of, xsl:namespace, xsl:comment, or xsl:processing-instruction. For details, see 5.6.2 Constructing Simple Content.

Note:

The term sequence constructor replaces template as used in XSLT 1.0. The change is made partly for clarity (to avoid confusion with template rules (http://www.w3.org/TR/xslt20/#dt-template-rule) and named templates (http://www.w3.org/TR/xslt20/#dt-named-template)), but also to reflect a more formal definition of the semantics. Whereas XSLT 1.0 described a template as a sequence of instructions that write to the result tree, XSLT 2.0 describes a sequence constructor as something that can be evaluated to return a sequence of items; what happens to these items depends on the containing instruction.

5.6.1 Constructing Complex Content

This section describes how the sequence obtained by evaluating a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) may be used to construct the children of a newly constructed document node, or the children, attributes and namespaces of a newly constructed element node. The sequence of items may be obtained by evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) contained in an instruction such as xsl:copy, xsl:element, xsl:result-document, or a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element).

The sequence is processed as follows:

The containing instruction may generate attribute nodes and/or namespace nodes, as specified in the rules for the individual instruction. For example, these nodes may be produced by expanding an [xsl:]use-attribute-sets attribute, or by expanding the attributes of a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element). Any such nodes are prepended to the sequence produced by evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor).

Any atomic value in the sequence is cast to a string. Special considerations apply to two atomic types for which casting to xs:string is not possible:

[ERR XT0380] A recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) occurs if the sequence contains an atomic value of type xs:QName, because such values cannot be cast to a string. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to ignore the offending xs:QName value.

Any consecutive sequence of strings within the result sequence is converted to a single text node, whose string value (http://www.w3.org/TR/xslt20/#dt-string-value) contains the content of each of the strings in turn, with a with a single space (#x20) used as a separator between successive strings. If this process would create a text node whose string value is zero-length, no text node is created and the content is discarded.

Any document node within the result sequence is replaced by a sequence containing each of its children, in document order.

Adjacent text nodes within the result sequence are merged into a single text node.

Invalid namespace and attribute nodes are detected as follows.

[ERR XT0410] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if the result sequence used to construct the content of an element node contains a namespace node or attribute node that is preceded in the sequence by a node that is neither a namespace node nor an attribute node. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to ignore the offending namespace or attribute node.

[ERR XT0420] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if the result sequence used to construct the content of a document node contains a namespace node or attribute node. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to ignore the offending namespace or attribute node.

[ERR XT0430] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if the result sequence contains two or more namespace nodes having the same name but different string values (http://www.w3.org/TR/xslt20/#dt-string-value) (that is, namespace nodes that map the same prefix to different namespace URIs). The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to discard all conflicting namespace nodes other than the one that appears last in the result sequence.

[ERR XT0440] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if the result sequence contains a namespace node with no name and the element node being constructed has a null namespace URI (that is, it is an error to define a default namespace when the element is in no namespace). The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to ignore the offending namespace node.

If the result sequence contains two or more namespace nodes with the same name (or no name) and the same string value (http://www.w3.org/TR/xslt20/#dt-string-value) (that is, two namespace nodes mapping the same prefix to the same namespace URI), then all but one of the duplicate nodes are discarded.

Note:

Since the order of namespace nodes is undefined, it is not significant which of the duplicates is retained.

If an attribute A in the result sequence has the same name as another attribute B that appears later in the result sequence, then attribute A is discarded from the result sequence.

Each node in the resulting sequence is attached as a namespace, attribute, or child of the newly constructed element or document node. Conceptually this involves making a deep copy of the node; in practice, however, copying the node will only be necessary if the existing node can be referenced independently of the parent to which it is being attached. When copying an element node, its base URI property is changed to be the same as that of its new parent, unless it has an xml:base attribute (see [XMLBASE (http://www.w3.org/TR/xslt20/#XMLBASE)]) that overrides this.

If the newly constructed node is an element node, then namespace fixup is applied to this node, as described in 5.6.3 Namespace Fixup

Example: A Sequence Constructor for Complex Content
For example, consider the following stylesheet fragment:

<td>

  <xsl:attribute name="valign">top</xsl:attribute>

  <xsl:value-of select="@description"/>

5.6.2 Constructing Simple Content

The xsl:attribute, xsl:comment, xsl:processing-instruction, xsl:namespace, and xsl:value-of elements create nodes that cannot have children. Specifically, the xsl:attribute instruction creates an attribute node, xsl:comment creates a comment node, xsl:processing-instruction creates a processing instruction node, xsl:namespace creates a namespace node, and xsl:value-of creates a text node. The string value of the new node is constructed using either the select attribute of the instruction, or the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) that forms the content of the instruction. The select attribute allows the content to be specified by means of an XPath expression, while the sequence constructor allows it to be specified by means of a sequence of XSLT instructions. The select attribute or sequence constructor is evaluated to produce a result sequence, and the string value (http://www.w3.org/TR/xslt20/#dt-string-value) of the new node is derived from this result sequence in the following way:

The sequence is atomized (http://www.w3.org/TR/xslt20/#dt-atomization).

Every value in the atomized sequence is cast to a string. Special considerations apply to atomic values of type xs:QName:

[ERR XT0450] A recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) occurs if the sequence contains a value of type xs:QName, because such values cannot be cast to a string. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to ignore the xs:QNamevalue.

Note:

An example showing how to construct QName-valued attributes (specifically, an xsi:type attribute) is given in 11.6 Creating Namespace Nodes. Essentially, the application is responsible for choosing a namespace prefix, and this can then be used firstly to create a namespace node by using the xsl:namespace instruction, and secondly to construct the lexical QName (http://www.w3.org/TR/xslt20/#dt-lexical-qname), which is then written directly as the attribute value.

The strings within the resulting sequence are concatenated, with a (possibly zero-length) separator inserted between successive strings. When the select attribute is used the default separator is a single space character (#x20). When the value is constructed using a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), the default separator is a zero-length string. In the case of xsl:attribute and xsl:value-of, a different separator can be specified using the separator attribute of the instruction; it is permissible for this to be a zero-length string, in which case the strings are concatenated with no separator. In the case of xsl:comment, xsl:processing-instruction, and xsl:namespace the default separator cannot be changed.

The string that results from this concatenation forms the string value (http://www.w3.org/TR/xslt20/#dt-string-value) of the new attribute, namespace, comment, processing-instruction, or text node.

5.6.3 Namespace Fixup

In a tree supplied to or constructed by an XSLT processor, the following constraints relating to namespace nodes must be satisfied in addition to those specified in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]:

If an element node has an expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) with a non-null namespace URI, then that element node must have at least one namespace node whose string value (http://www.w3.org/TR/xslt20/#dt-string-value) is the same as that namespace URI.

If an element node has an attribute node whose expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) has a non-null namespace URI, then the element must have at least one namespace node whose string value (http://www.w3.org/TR/xslt20/#dt-string-value) is the same as that namespace URI and whose name is non-empty.

Every element must have a namespace node whose expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) has local-part xml and whose string value (http://www.w3.org/TR/xslt20/#dt-string-value) is http://www.w3.org/XML/1998/namespace. The namespace prefix xml must not be associated with any other namespace URI, and the namespace URI http://www.w3.org/XML/1998/namespace must not be associated with any other prefix.

A namespace node must not have the name xmlns.

If an element is annotated with the type xs:QName, or a type derived from xs:QName, or if it has an attribute with such a type annotation, then that element must have a namespace node whose string value (http://www.w3.org/TR/xslt20/#dt-string-value) is the same as the namespace URI of that QName value, and whose name is the same as the prefix used in the lexical representation of the QName (if the lexical representation is unprefixed, the namespace node must be unnamed).

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

The actual namespace nodes that are added to the tree by the namespace fixup process are implementation-defined, provided firstly, that at the end of the process the above constraints must all be satisfied, and secondly, that a namespace node must not be added to the tree unless the namespace node is necessary either to satisfy these constraints, or to enable the tree to be serialized using the original namespace prefixes from the source document or stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet).

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

Namespace fixup is applied to every element that is constructed using a literal result element (http://www.w3.org/TR/xslt20/#dt-literal-result-element), or one of the instructions xsl:element, xsl:copy, or xsl:copy-of. An implementation is not required to perform namespace fixup for elements in any source document, that is, documents loaded using the document, doc FO or collection FO function, documents supplied as the value of a stylesheet parameter (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter), or documents returned by an extension function (http://www.w3.org/TR/xslt20/#dt-extension-function) or extension instruction (http://www.w3.org/TR/xslt20/#dt-extension-instruction).

[ERR XT0490] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if such a source document does not already satisfy the constraints listed above . This is a recoverable error (http://www.w3.org/TR/xslt20/#dt-recoverable-error). The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is either to perform namespace fixup, or to produce implementation-dependent (http://www.w3.org/TR/xslt20/#dt-implementation-dependent) results.

In an InfoSet (see [XML Information Set (http://www.w3.org/TR/xslt20/#INFOSET)]) created from a document conforming to [XML Namespaces 1.0 (http://www.w3.org/TR/xslt20/#XMLNAMES)], it will always be true that if a parent element has an in-scope namespace with a non-empty namespace prefix, then its child elements will also have an in-scope namespace with the same namespace prefix, though possibly with a different namespace URI. This constraint is removed in [XML Namespaces 1.1 (http://www.w3.org/TR/xslt20/#XMLNAMES1.1)]. XSLT 2.0 supports the creation of result trees that do not satisfy this constraint: the namespace fixup process does not add a namespace node to an element merely because its parent node in the result tree has such a namespace node.

Note:

This has implications on serialization, defined in [XSLT and XQuery Serialization (http://www.w3.org/TR/xslt20/#serialization-spec)]. It means that it is possible to create result trees that cannot be faithfully serialized as XML 1.0 documents. When such a result tree is serialized as XML 1.0, namespace declarations written for the parent element will be inherited by its child elements as if the corresponding namespace nodes were present on the child element, except in the case of the default namespace, which can be undeclared using the construct xmlns="". When the same result tree is serialized as XML 1.1, however, it is possible to undeclare any namespace on the child element (for example, xmlms:foo="") to prevent this inheritance taking place.

6 模板规则(Template Rules)

模板规则定义了匹配指定 模式 (http://www.w3.org/TR/xslt20/#dt-pattern) 的节点的处理过程。

6.1 定义模板

<xsl:template

  match? = pattern
  name? = qname
  priority? = number
  mode? = tokens
  as? = sequence-type>

</xsl:template>

[定义: 使用xsl:template标签定义一个“模板”，该模板包含一个创建节点和/或基本数值的 序列构造器 (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) 。 一个模板既可以作为一个 模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule) 被匹配模式 (http://www.w3.org/TR/xslt20/#dt-pattern) 的节点调用，也可以作为一个 命名模板 (http://www.w3.org/TR/xslt20/#dt-named-template), 显式的通过模板名字调用。同一个模板可以同时具有上述两种功能。]

一个xsl:template元素必须至少包含match或name属性中的一个。如果包含match（匹配）属性，则该模板是一个模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule) 。如果包含一个name（名字）属性，则该模板是一个 命名模板 (http://www.w3.org/TR/xslt20/#dt-named-template)。xsl:template元素中只有包含match属性的时候才能具有mode（模式）和priority（优先级）属性。

一个 模板 (http://www.w3.org/TR/xslt20/#dt-template) 可以被多种方式调用，调用方式取决于该模板是一个 模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule) 还是一个命名模板 (http://www.w3.org/TR/xslt20/#dt-named-template)。如果模板被调用，则返回xsl:template element元素中 序列构造器(sequence constructor) (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) 的执行结果。如果提供了as属性，则as属性定义返回值的类型。

序列构造器 (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) 的执行结果使用 功能转换规则(function conversion rules) (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules) 转换到需要的类型。

如果没有指定as属性，则默认值是item()*，即允许任何值。不进行任何转换。

===6.2 定义模板规则
本节描述了模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule)。命名模板 (http://www.w3.org/TR/xslt20/#dt-named-template) 在第“10.1小节 命名模板”描述。

模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule)是由xsl:template和一个match属性指定的。match属性是一个模式 (http://www.w3.org/TR/xslt20/#NT-Pattern)，指定该规则所要应用到的节点。应用模板规则后的结果是将匹配到的节点作为 内容节点 (http://www.w3.org/TR/xslt20/#dt-context-node) 在xsl:template元素的序列构造器中执行后的结果，

例子： 一个简单的模板规则
例如，一个XML文档可能包含：
This is an <emph>important</emph> point.

下面的 模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule) 匹配emph元素，并产生一个font-weight属性为bold的fo:wrapper元素。

<xsl:template match="emph">

  <fo:wrapper font-weight="bold" xmlns:fo="http://www.w3.org/1999/XSL/Format">

    <xsl:apply-templates/>

  </fo:wrapper>

</xsl:template>

当xsl:apply-templates指令选择了一个与match属性中指定的模式匹配的节点后，执行模板规则 (http://www.w3.org/TR/xslt20/#dt-template-rule)。xsl:apply-templates指令在下一节中描述。如果有多个模板规则都可以匹配同一个节点，只有一个会被执行，就像在“6.4 模板规则冲突解决”小节中描述的那样。

6.3 Applying Template Rules

<xsl:apply-templates

  select? = expression
  mode? = token>

</xsl:apply-templates>

The xsl:apply-templates instruction takes as input a sequence of nodes in the source tree, and produces as output a sequence of items; these will often be nodes to be added to the result tree.

If the instruction has one or more xsl:sort children, then the input sequence is sorted as described in 13 Sorting. The result of this sort is referred to below as the sorted sequence; if there are no xsl:sort elements, then the sorted sequence is the same as the input sequence.

Each node in the input sequence is processed by finding a template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) whose pattern (http://www.w3.org/TR/xslt20/#dt-pattern) matches that node. If there is more than one, the best among them is chosen, using rules described in 6.4 Conflict Resolution for Template Rules. If there is no template rule whose pattern matches the node, a built-in template rule is used (see 6.6 Built-in Template Rules). The chosen template rule is evaluated. The rule that matches the Nth node in the sorted sequence is evaluated with that node as the context item (http://www.w3.org/TR/xslt20/#dt-context-item), with N as the context position (http://www.w3.org/TR/xslt20/#dt-context-position), and with the length of the sorted sequence as the context size (http://www.w3.org/TR/xslt20/#dt-context-size). Each template rule that is evaluated produces a sequence of items as its result. The resulting sequences (one for each node in the sorted sequence) are then concatenated, to form a single sequence. They are concatenated retaining the order of the nodes in the sorted sequence. The final concatenated sequence forms the result of the xsl:apply-templates instruction.

Example: Applying Template Rules
Suppose the source document is as follows:

<message>Proceed <emph>at once</emph> to the exit!</message>

This can be processed using the two template rules shown below.

<xsl:template match="message">

<xsl:apply-templates select="child::node()"/>

</xsl:template>

<xsl:template match="emph">

  

    <xsl:apply-templates select="child::node()"/>

  

</xsl:template>

There is no template rule for the document node; the built-in template rule for this node will cause the message element to be processed. The template rule for the message element causes a p element to be written to the result tree; the contents of this p element are constructed as the result of the xsl:apply-templates instruction. This instruction selects the three child nodes of the message element (a text node containing the value "Proceed ", an emph element node, and a text node containing the value " to the exit!"). The two text nodes are processed using the built-in template rule for text nodes, which returns a copy of the text node. The emph element is processed using the explicit template rule that specifies match="emph".

When the emph element is processed, this template rule constructs a b element. The contents of the b element are constructed by means of another xsl:apply-templates instruction, which in this case selects a single node (the text node containing the value "at once"). This is again processed using the built-in template rule for text nodes, which returns a copy of the text node.

The final result of the match="message" template rule thus consists of a p element node with three children: a text node containing the value "Proceed ", a b element that is the parent of a text node containing the value "at once", and a text node containing the value " to the exit!". This result tree might be serialized as:

Proceed at once to the exit!

The default value of the select attribute is child::node(), which causes all the children of context node to be processed.

Note:

This includes child element nodes, text nodes, comments, and processing instructions. It does not, however, include attributes.

[ERR XT0510] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if an xsl:apply-templates instruction with no select attribute is evaluated when the context item (http://www.w3.org/TR/xslt20/#dt-context-item) is not a node. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to return the empty sequence.

Note:

If stripping of whitespace text nodes (http://www.w3.org/TR/xslt20/#dt-whitespace-text-node) has not been enabled for an element, then all whitespace in the content of the element will be processed as text, and thus whitespace between child elements will count in determining the position of a child element as returned by the position FO function. This typically means that the child elements will be numbered 2, 4, 6... This effect can be prevented by stripping whitespace text nodes as specified in 4.3 Stripping Whitespace from a Source Tree, or by writing <xsl:apply-templates select="*"/> to avoid processing the child text nodes.

A select attribute can be used to process nodes selected by an expression instead of processing all children. The value of the select attribute is an expression (http://www.w3.org/TR/xslt20/#dt-expression). The expression must evaluate to a sequence of nodes (it can contain zero, one, or more nodes).

[ERR XT0520] It is a type error (http://www.w3.org/TR/xslt20/#dt-type-error) if the sequence returned by the select expression contains an item that is not a node.

Note:

In XSLT 1.0, the select attribute selected a set of nodes, which by default were processed in document order. In XSLT 2.0, it selects a sequence of nodes. In cases that would have been valid in XSLT 1.0, the expression will return a sequence of nodes in document order, so the effect is the same.

Example: Applying Templates to Selected Nodes
The following example processes all of the given-name children of the author elements that are children of author-group:

<xsl:template match="author-group">

  <fo:wrapper>

    <xsl:apply-templates select="author/given-name"/>

  </fo:wrapper>

</xsl:template>

Example: Applying Templates to Nodes that are not Descendants
It is also possible to process elements that are not descendants of the context node. This example assumes that a department element has group children and employee descendants. It finds an employee's department and then processes the group children of the department.

<xsl:template match="employee">

  <fo:block>

    Employee <xsl:apply-templates select="name"/> belongs to group

    <xsl:apply-templates select="ancestor::department/group"/>

  </fo:block>

</xsl:template>

Example: Matching by Schema-Defined Types
It is possible to write template rules that are matched according to the schema-defined type of an element or attribute. The following example applies different formatting to the children of an element depending on their type:

<xsl:template match="product">

</xsl:template>

<xsl:template match="product/*" priority="3">

  <tr>

</xsl:template>

Example: Processing Recursive Structures
It is possible for there to be two matching descendants where one is a descendant of the other. This case is not treated specially: both descendants will be processed as usual.

For example, given a source document

the rule

<xsl:template match="doc">

  <xsl:apply-templates select=".//div"/>

</xsl:template>

will process both the outer div and inner div elements.

This means that if the template rule for the div element processes its own children, then these grandchildren will be processed more than once, which is probably not what is required. The solution is to process one level at a time in a recursive descent, by using select="div" in place of select=".//div"

Note:

The xsl:apply-templates instruction is most commonly used to process nodes that are descendants of the context node. Such use of xsl:apply-templates cannot result in non-terminating processing loops. However, when xsl:apply-templates is used to process elements that are not descendants of the context node, the possibility arises of non-terminating loops. For example,

<xsl:template match="foo">

  <xsl:apply-templates select="."/>

</xsl:template>

Implementations may be able to detect such loops in some cases, but the possibility exists that a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) may enter a non-terminating loop that an implementation is unable to detect. This may present a denial of service security risk.

6.4 Conflict Resolution for Template Rules

It is possible for a node in a source document to match more than one template rule (http://www.w3.org/TR/xslt20/#dt-template-rule). When this happens, only one template rule is evaluated for the node. The template rule to be used is determined as follows:

First, all matching template rules that have lower import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) than the matching template rule or rules with the highest import precedence are eliminated from consideration.

Next, all matching template rules that have lower priority than the matching template rule or rules with the highest priority are eliminated from consideration. The priority of a template rule is specified by the priority attribute on the template rule.

[ERR XT0530] The value of this must be a decimal number (positive or negative), matching the production IntegerLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-IntegerLiteral) XP or DecimalLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-DecimalLiteral) XP with an optional leading minus sign (-).

[Definition: If no priority attribute is specified on the xsl:template element, a default priority is computed, based on the syntax of the pattern supplied in the match attribute.] The rules are as follows:

If the pattern contains multiple alternatives separated by | or union, then the template rule is treated equivalently to a set of template rules, one for each alternative. However, it is not an error if a node matches more than one of the alternatives.

If the pattern has the form /, then the priority is −0.5.

If the pattern has the form of a QName (http://www.w3.org/TR/xslt20/#dt-qname) optionally preceded by a PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis) or has the form processing-instruction(StringLiteral (http://www.w3.org/TR/xpath20/#doc-xpath-StringLiteral) XP) or processing-instruction(NCName (http://www.w3.org/TR/REC-xml-names/#NT-NCName) Names) optionally preceded by a PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis), then the priority is 0.

If the pattern has the form of an ElementTest (http://www.w3.org/TR/xpath20/#doc-xpath-ElementTest) XP or AttributeTest (http://www.w3.org/TR/xpath20/#doc-xpath-AttributeTest) XP, optionally preceded by a PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis), then the priority is as shown in the table below. In this table, the symbols E, A, and T represent an arbitrary element name, attribute name, and type name respectively, while the symbol * represents itself. A SchemaContextPath (http://www.w3.org/TR/xpath20/#doc-xpath-SchemaContextPath) XP may be specified in addition to the element or attribute name; this does not affect the priority. The presence or absence of the keyword nillable does not affect the priority.

Format
Priority
Notes


element()
−0.5
(equivalent to *)

element(*,*)
−0.5
(equivalent to *)

attribute()
−0.5
(equivalent to @*)

attribute(*,*)
−0.5
(equivalent to @*)

element(E,*)
0
(matches by substitution group)

element(*,T)
0
(matches by type only)

attribute(*,T)
0
(matches by type only)

attribute(A,*)
0
(equivalent to @A)

element(E,T)
0.25
(matches by substitution group and type)

element(E)
0.25
(matches by substitution group and type)

attribute(A,T)
0.25
(matches by name and type)

attribute(A)
0.25
(matches by name and type)

If the pattern has the form of a DocumentTest (http://www.w3.org/TR/xpath20/#doc-xpath-DocumentTest) XP, then if it includes no ElementTest (http://www.w3.org/TR/xpath20/#doc-xpath-ElementTest) XP the priority is −0.5. If if does include an ElementTest (http://www.w3.org/TR/xpath20/#doc-xpath-ElementTest) XP, then the priority is the same as the priority of that ElementTest (http://www.w3.org/TR/xpath20/#doc-xpath-ElementTest) XP, computed according to the table above.

If the pattern has the form NCName (http://www.w3.org/TR/REC-xml-names/#NT-NCName) Names:* or *:NCName (http://www.w3.org/TR/REC-xml-names/#NT-NCName) Names, optionally preceded by a PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis), then the priority is −0.25.

If the pattern is any other NodeTest (http://www.w3.org/TR/xpath20/#doc-xpath-NodeTest) XP, optionally preceded by a PatternAxis (http://www.w3.org/TR/xslt20/#NT-PatternAxis), then the priority is −0.5.

Otherwise, the priority is 0.5.

Note:

In many cases this means that highly selective patterns have higher priority than less selective patterns. The most common kind of pattern (a pattern that tests for a node of a particular kind, with a particular expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) or a particular type) has priority 0. The next less specific kind of pattern (a pattern that tests for a node of a particular kind and an expanded-QName (http://www.w3.org/TR/xslt20/#dt-expanded-qname) with a particular namespace URI) has priority −0.25. Patterns less specific than this (patterns that just test for nodes of a given kind) have priority −0.5. Patterns that specify both the name and the required type have a priority of +0.25, putting them above patterns that only specify the name or the type. Patterns more specific than this, for example patterns that include predicates or that specify the ancestry of the required node, have priority 0.5.

However, it is not invariably true that a more selective pattern has higher priority than a less selective pattern. For example, the priority of the pattern node()[self::*] is higher than that of the pattern salary. Similarly, the patterns attribute(*, xs:decimal) and attribute(*, xs:short) have the same priority, despite the fact that the latter pattern matches a subset of the nodes matched by the former. Therefore, to achieve clarity in a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) it is good practice to allocate explicit priorities.

[ERR XT0540] It is a recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-recoverable-error) if the conflict resolution algorithm for template rules leaves more than one matching template rule. The optional recovery action (http://www.w3.org/TR/xslt20/#dt-optional-recovery-action) is to select, from the matching template rules that are left, the one that occurs last in declaration order (http://www.w3.org/TR/xslt20/#dt-declaration-order).

6.5 Modes

[Definition: Modes allow a node in the source tree to be processed multiple times, each time producing a different result. They also allow different sets of template rules (http://www.w3.org/TR/xslt20/#dt-template-rule) to be active when processing different trees, for example when processing documents loaded using the document function (see 16.1 Multiple Source Documents) or when processing temporary trees (http://www.w3.org/TR/xslt20/#dt-temporary-tree) (see 9.4 Temporary Trees)]

Modes are identified by a QName (http://www.w3.org/TR/xslt20/#dt-qname), except for the default mode, which is unnamed.

A template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) is applicable to one or more modes. The modes to which it is applicable are defined by the mode attribute of the xsl:template element. If the attribute is omitted, then the template rule is applicable to the default mode. If the attribute is present, then its value must be a space-separated list of tokens, each of which defines a mode to which the template rule is applicable. Each token must be one of the following:

a QName (http://www.w3.org/TR/xslt20/#dt-qname), which is expanded as described in 5.1 Qualified Names to define the name of the mode

the token #default, to indicate that the template rule is applicable to the default mode

the token #all, to indicate that the template rule is applicable to all modes.

[ERR XT0550] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if the same token is included more than once in the list or if the token #all appears together with any other value.

The xsl:apply-templates element also has an optional mode attribute. The value of this attribute must either be a QName (http://www.w3.org/TR/xslt20/#dt-qname), which is expanded as described in 5.1 Qualified Names to define the name of a mode, or the token #default, to indicate that the default mode is to be used, or the token #current, to indicate that the current mode (http://www.w3.org/TR/xslt20/#dt-current-mode) is to be used. If the attribute is omitted, the default mode is used.

When searching for a template rule to process each node selected by the xsl:apply-templates instruction, only those template rules that are applicable to the selected mode are considered.

[Definition: At any point in the processing of a stylesheet, there is a current mode. When the transformation is initiated, the current mode is the default mode, unless a different initial mode has been supplied, as described in 2.3 Initiating a Transformation. Whenever an xsl:apply-templates instruction is evaluated, the current mode becomes the mode selected by this instruction.] When a stylesheet function is called, the current mode becomes the default mode. No other instruction changes the current mode. On completion of the xsl:apply-templates instruction, or on return from a stylesheet function call, the current mode reverts to its previous value. The current mode is used when an xsl:apply-templates instruction uses the syntax mode="#current"; it is also used by the xsl:apply-imports and xsl:next-match instructions (see 6.7 Overriding Template Rules).

6.6 Built-in Template Rules

When a node is selected by xsl:apply-templates and there is no template rule in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet) that can be used to process that node, a built-in template rule is evaluated instead.

The built-in template rules apply to all modes.

The built-in rule for document nodes and element nodes is equivalent to calling xsl:apply-templates with no select attribute, and with the mode attribute set to #current. If the built-in rule was invoked with parameters, those parameters are passed on in the implicit xsl:apply-templates instruction.

Example: Using a Built-In Template Rule
For example, suppose the stylesheet contains the following instruction:

<xsl:apply-templates select="title" mode="mm">

  <xsl:with-param name="init" select="10"/>

</xsl:apply-template>

If there is no explicit template rule that matches the title element, then the following implicit rule is used:

<xsl:template match="title" mode="#all">

  <xsl:with-param name="init"/>

  <xsl:apply-templates mode="#current">

    <xsl:with-param name="init" select="$init"/>

  </xsl:apply-templates>

</xsl:template>

The built-in template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) for text and attribute nodes returns a text node containing the string value (http://www.w3.org/TR/xslt20/#dt-string-value) of the context node, unless the string value (http://www.w3.org/TR/xslt20/#dt-string-value) is zero-length, in which case it returns an empty sequence. It is effectively:

<xsl:template match="text()|@*" mode="#all">

  <xsl:value-of select="."/>

</xsl:template>

The built-in template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) for processing instructions and comments does nothing (it returns the empty sequence).

<xsl:template match="processing-instruction()|comment()" mode="#all"/>

The built-in template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) for namespace nodes is also to do nothing. There is no pattern that can match a namespace node, so the built-in template rule is always used when xsl:apply-templates selects a namespace node.

The built-in template rules (http://www.w3.org/TR/xslt20/#dt-template-rule) have lower import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) than all other template rules. Thus, the stylesheet author can override a built-in template rule by including an explicit template rule.

6.7 Overriding Template Rules

<xsl:apply-imports> </xsl:apply-imports>

<xsl:next-match> </xsl:next-match>

A template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) that is being used to override another template rule (see 6.4 Conflict Resolution for Template Rules) can use the xsl:apply-imports or xsl:next-match instruction to invoke the overridden template rule. The xsl:apply-imports instruction only considers template rules in imported stylesheet modules; the xsl:next-match instruction considers all other template rules of lower import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) and/or priority. Both instructions will invoke the built-in template rule for the node (see 6.6 Built-in Template Rules) if no other template rule is found.

[Definition: At any point in the processing of a stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet), there may be a current template rule. Whenever a template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) is chosen by matching a pattern, the template rule becomes the current template rule for the evaluation of the rule's sequence constructor. When an xsl:for-each or xsl:for-each-group instruction is evaluated, or when a stylesheet function (http://www.w3.org/TR/xslt20/#dt-stylesheet-function) is called (see 10.3 Stylesheet Functions), the current template rule becomes null for the evaluation of that instruction or function.]

The current template rule is not affected by invoking named templates (see 10.1 Named Templates) or named attribute sets (see 10.2 Named Attribute Sets). While evaluating a global variable (http://www.w3.org/TR/xslt20/#dt-global-variable) or the default value of a stylesheet parameter (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) (see 9.5 Global Variables and Parameters) the current template rule is null.

Note:

These rules ensure that when xsl:apply-imports or xsl:next-match is called, the context item is the same as when the current template rule was invoked, and is always a node.

Both xsl:apply-imports and xsl:next-match search for a template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) that matches the context node, and that is applicable to the current mode (http://www.w3.org/TR/xslt20/#dt-current-mode) (see 6.5 Modes). In choosing a template rule, they use the usual criteria such as the priority and import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) of the template rules, but they consider as candidates only a subset of the template rules in the stylesheet (http://www.w3.org/TR/xslt20/#dt-stylesheet). This subset differs between the two instructions:

The xsl:apply-imports instruction considers as candidates only those template rules contained in stylesheet levels (http://www.w3.org/TR/xslt20/#dt-stylesheet-level) that are descendants in the import tree (http://www.w3.org/TR/xslt20/#dt-import-tree) of the stylesheet level (http://www.w3.org/TR/xslt20/#dt-stylesheet-level) that contains the current template rule (http://www.w3.org/TR/xslt20/#dt-current-template-rule).

Note:

This is not the same as saying that the search considers all template rules whose import precedence is lower than that of the current template rule.

The xsl:next-match instruction considers as candidates all those template rules that come after the current template rule (http://www.w3.org/TR/xslt20/#dt-current-template-rule) in the ordering of template rules implied by the conflict resolution rules given in 6.4 Conflict Resolution for Template Rules. That is, it considers all template rules with lower import precedence (http://www.w3.org/TR/xslt20/#dt-import-precedence) than the current template rule (http://www.w3.org/TR/xslt20/#dt-current-template-rule), plus the template rules that are at the same import precedence that have lower priority than the current template rule. If the processor has recovered from the error that occurs when two matching template rules have the same import precedence and priority, then it also considers all matching template rules with the same import precedence and priority that occur before the current template rule in declaration order (http://www.w3.org/TR/xslt20/#dt-declaration-order).

If no matching template rule is found that satisfies these criteria, the built-in template rule for the node kind is used (see 6.6 Built-in Template Rules).

An xsl:apply-imports or xsl:next-match instruction may use xsl:with-param child elements to pass parameters to the chosen template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) (see 10.1.1 Passing Parameters to Templates). It also passes on any tunnel parameters (http://www.w3.org/TR/xslt20/#dt-tunnel-parameter) as described in 10.1.2 Tunnel Parameters.

[ERR XT0560] It is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if xsl:apply-imports or xsl:next-match is evaluated when the current template rule (http://www.w3.org/TR/xslt20/#dt-current-template-rule) is null.

Example: Using xsl:apply-imports
For example, suppose the stylesheet doc.xsl contains a template rule (http://www.w3.org/TR/xslt20/#dt-template-rule) for example elements:

<xsl:template match="example">

<xsl:apply-templates/>

</xsl:template>

Another stylesheet could import doc.xsl and modify the treatment of example elements as follows:

<xsl:import href="doc.xsl"/>

<xsl:template match="example">

     <xsl:apply-imports/>

</xsl:template>

The combined effect would be to transform an example into an element of the form:

...

An xsl:fallback instruction appearing as a child of an xsl:next-match instruction is ignored by an XSLT 2.0 processor, but can be used to define fallback behavior when the stylesheet is processed by an XSLT 1.0 processor in forwards-compatible mode.

7 Repetition

<xsl:for-each

  select = sequence-expression>

</xsl:for-each>

The xsl:for-each instruction processes each item in a sequence of items, evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) within the xsl:for-each instruction once for each item in that sequence.

The select attribute is required, and the expression (http://www.w3.org/TR/xslt20/#dt-expression) must evaluate to 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 (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), which is evaluated once for each item in the sorted sequence. The sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) is evaluated with the focus (http://www.w3.org/TR/xslt20/#dt-focus) set as follows:

The context item (http://www.w3.org/TR/xslt20/#dt-context-item) is the item being processed. If this is a node, it will also be the context node (http://www.w3.org/TR/xslt20/#dt-context-node). If it is not a node, there will be no context node: that is, the value of self::node() will be an empty sequence.

The context position (http://www.w3.org/TR/xslt20/#dt-context-position) is the position of this item in the sorted sequence.

The context size (http://www.w3.org/TR/xslt20/#dt-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 (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) produces a sequence of items (see 5.6 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.

Note:

With XSLT 1.0, the selected nodes were processed in document order. With XSLT 2.0, XPath expressions that would have been valid under XPath 1.0 (such as path expressions and union expressions) will return a sequence of nodes that is already in document order, so backwards compatibility is maintained.

Example: Using xsl:for-each
For example, given an XML document with this structure

<customers>

  <customer>

    <name>...</name>

    <order>...</order>

    <order>...</order>

  </customer>

  <customer>

    <name>...</name>

    <order>...</order>

    <order>...</order>

  </customer>

</customers>

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

<xsl:template match="/">

  <html>

    <head>

      <title>Customers</title>

    </head>

    <body>

                <xsl:apply-templates select="name"/>

                  <xsl:apply-templates/>

    </body>

  </html>

</xsl:template>

8 Conditional Processing

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

8.1 Conditional Processing with xsl:if

<xsl:if

  test = expression>

</xsl:if>

The xsl:if element has a mandatory test attribute, which specifies an expression (http://www.w3.org/TR/xslt20/#dt-expression). The content is a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor).

The result of the xsl:if instruction depends on the effective boolean value (http://www.w3.org/TR/xpath20/#dt-ebv)XP of the expression in the test attribute. The rules for determining the effective boolean value of an expression are given in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]: they are the same as the rules used for XPath conditional expressions.

If the effective boolean value of the expression (http://www.w3.org/TR/xslt20/#dt-expression) is true, then the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) is evaluated (see 5.6 Sequence Constructors), and the resulting node sequence is returned as the result of the xsl:if instruction; otherwise, the sequence constructor is not evaluated, and the empty sequence is returned.

Example: Using xsl:if
In the following example, the names in a group of names are formatted as a comma separated list:

<xsl:template match="namelist/name">

  <xsl:apply-templates/>

  <xsl:if test="not(position()=last())">, </xsl:if>

</xsl:template>

The following colors every other table row yellow:

<xsl:template match="item">

  <tr>

    <xsl:if test="position() mod 2 = 0">

       <xsl:attribute name="bgcolor">yellow</xsl:attribute>

    </xsl:if>

    <xsl:apply-templates/>

8.2 Conditional Processing with xsl:choose

<xsl:choose> </xsl:choose>

<xsl:when

  test = expression>

</xsl:when>

<xsl:otherwise> </xsl:otherwise>

The xsl:choose element selects one among a number of possible alternatives. It consists of a sequence of xsl:when elements followed by an optional xsl:otherwise element. Each xsl:when element has a single attribute, test, which specifies an expression (http://www.w3.org/TR/xslt20/#dt-expression). The content of the xsl:when and xsl:otherwise elements is a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor).

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 (http://www.w3.org/TR/xpath20/#dt-ebv)XP of the expression (http://www.w3.org/TR/xslt20/#dt-expression) in its test attribute is true. The rules for determining the effective boolean value of an expression are given in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)]: they are the same as the rules used for XPath conditional expressions.

The content of the first, and only the first, xsl:when element that is satisfied is evaluated, and the resulting sequence 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.

Only the sequence constructor of the selected xsl:when or xsl:otherwise instruction is evaluated. The test expressions for xsl:when instructions after the selected one are not evaluated.

Example: Using xsl:choose
The following example enumerates items in an ordered list using arabic numerals, letters, or roman numerals depending on the depth to which the ordered lists are nested.

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

9 Variables and Parameters

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

[Definition: The xsl:variable element declares a variable, which may be a global variable (http://www.w3.org/TR/xslt20/#dt-global-variable) or a local variable (http://www.w3.org/TR/xslt20/#dt-local-variable).]

[Definition: The xsl:param element declares a parameter, which may be a stylesheet parameter (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter), a template parameter (http://www.w3.org/TR/xslt20/#dt-template-parameter), or a function parameter (http://www.w3.org/TR/xslt20/#dt-function-parameter). A parameter is a variable (http://www.w3.org/TR/xslt20/#dt-variable) with the additional property that its value can be set by the caller when the stylesheet, the template, or the function is invoked.]

[Definition: A variable is a binding between a name and a value. The value of a variable is any sequence (of nodes and/or atomic values), as defined in [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)].]

9.1 Variables

<xsl:variable

  name = qname
  select? = expression
  as? = sequence-type>

</xsl:variable>

The xsl:variable element has a required name attribute, which specifies the name of the variable. The value of the name attribute is a QName (http://www.w3.org/TR/xslt20/#dt-qname), which is expanded as described in 5.1 Qualified Names.

The xsl:variable element has an optional as attribute, which specifies the required type (http://www.w3.org/TR/xslt20/#dt-required-type) of the variable. The value of the as attribute is a SequenceType (http://www.w3.org/TR/xpath20/#doc-xpath-SequenceType) XP, as defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

[Definition: The value of the variable is computed using the expression (http://www.w3.org/TR/xslt20/#dt-expression) given in the select attribute or the contained sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), as described in 9.3 Values of Variables and Parameters. This value is referred to as the supplied value of the variable.] If the xsl:variable element has a select attribute, then the sequence constructor must be empty.

If the as attribute is specified, then the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the variable is converted to the required type, using the function conversion rules (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules).

[ERR XT0570] It is a type error (http://www.w3.org/TR/xslt20/#dt-type-error) if the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of a variable cannot be converted to the required type.

If the as attribute is omitted, the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the variable is used directly, and no conversion takes place.

9.2 Parameters

<xsl:param

  name = qname
  select? = expression
  as? = sequence-type
  required? = "yes" | "no"
  tunnel? = "yes" | "no">

</xsl:param>

The xsl:param element may be used as a child of xsl:stylesheet, to define a parameter to the transformation; or 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; or 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 (http://www.w3.org/TR/xslt20/#dt-expression).

The xsl:param element has a required name attribute, which specifies the name of the parameter. The value of the name attribute is a QName (http://www.w3.org/TR/xslt20/#dt-qname), which is expanded as described in 5.1 Qualified Names.

[ERR XT0580] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if two parameters of a template or of a stylesheet function have the same name.

Note:

For rules concerning stylesheet parameters, see 9.5 Global Variables and Parameters. Local variables may shadow (http://www.w3.org/TR/xslt20/#dt-shadows) template parameters and function parameters: see 9.7 Scope of Variables.

The supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the parameter is the value supplied by the caller. If no value was supplied by the caller, and if the parameter is not mandatory, then the supplied value is computed using the expression (http://www.w3.org/TR/xslt20/#dt-expression) given in the select attribute or the contained sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), as described in 9.3 Values of Variables and Parameters. If the xsl:param element has a select attribute, then the sequence constructor must be empty.

Note:

This specification does not dictate whether and when the default value of a parameter is evaluated. For example, if the default is specified as <xsl:param name="p"><foo/></xsl:param>, then it is not specified whether a distinct foo element node will be created on each invocation of the template or function, or whether the same foo element node will be used for each invocation. However, it is permissible for the default value to be depend on the values of other parameters, or on the evaluation context, in which case the default must effectively be evaluated on each invocation.

The xsl:param element has an optional as attribute, which specifies the required type (http://www.w3.org/TR/xslt20/#dt-required-type) of the parameter. The value of the as attribute is a SequenceType (http://www.w3.org/TR/xpath20/#doc-xpath-SequenceType) XP, as defined in [XPath 2.0 (http://www.w3.org/TR/xslt20/#XPATH20)].

If the as attribute is specified, then the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the parameter is converted to the required type, using the function conversion rules (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules).

[ERR XT0590] It is a type error (http://www.w3.org/TR/xslt20/#dt-type-error) if the conversion of the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of a parameter to its required type fails.

If the as attribute is omitted, the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the parameter is used directly, and no conversion takes place.

The optional required attribute may be used to indicate that a parameter is mandatory. This attribute may be specified for stylesheet parameters (http://www.w3.org/TR/xslt20/#dt-stylesheet-parameter) and for template parameters (http://www.w3.org/TR/xslt20/#dt-template-parameter); it must not be specified for function parameters (http://www.w3.org/TR/xslt20/#dt-function-parameter), which are always mandatory. A parameter is mandatory if it is a function parameter (http://www.w3.org/TR/xslt20/#dt-function-parameter) or if the required attribute is present and has the value yes. Otherwise, the parameter is optional. If the parameter is mandatory, then the xsl:param element must be empty and must not have a select attribute.

[ERR XT0600] If a default value is given explicitly, that is, if there is either a select attribute or a non-empty sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), then it is a type error (http://www.w3.org/TR/xslt20/#dt-type-error) if the default value cannot be converted to the required type, using the function conversion rules (http://www.w3.org/TR/xslt20/#dt-function-conversion-rules).

If an optional parameter has no select attribute and has an empty sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), and if there is no as attribute, then the default value of the parameter is a zero length string.

[ERR XT0610] If an optional parameter has no select attribute and has an empty sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor), and if there is an as attribute, then the default value of the parameter is an empty sequence. If the empty sequence is not a valid instance of the required type defined in the as attribute, then the parameter is treated as a required parameter, which means that it is a non-recoverable dynamic error (http://www.w3.org/TR/xslt20/#dt-nonrec-dynamic-error) if the caller supplies no value for the parameter.

Note:

The effect of these rules is that specifying <xsl:param name="p" as="xs:date" select="2"/> is an error, but if the default value of the parameter is never used, then the processor has discretion whether or not to report the error. By contrast, <xsl:param name="p" as="xs:date"/> is treated as if required="yes" had been specified: the empty sequence is not a valid instance of xs:date, so in effect there is no default value and the parameter is therefore treated as being mandatory.

The optional tunnel attribute may be used to indicate that a parameter is a tunnel parameter (http://www.w3.org/TR/xslt20/#dt-tunnel-parameter). The default is no; the value yes may be specified only for template parameters (http://www.w3.org/TR/xslt20/#dt-template-parameter). Tunnel parameters are described in 10.1.2 Tunnel Parameters

9.3 Values of Variables and Parameters

A variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) may specify the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the variable (http://www.w3.org/TR/xslt20/#dt-variable) or parameter (http://www.w3.org/TR/xslt20/#dt-parameter) in four different ways.

If the variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) has a select attribute, then the value of the attribute must be an expression (http://www.w3.org/TR/xslt20/#dt-expression) and the supplied value (http://www.w3.org/TR/xslt20/#dt-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 (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) has empty content and has neither a select attribute nor an as attribute, then the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) of the variable is a zero-length string. Thus

<xsl:variable name="x"/>

is equivalent to

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

[Definition: If a variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) has no select attribute and has non-empty content (that is, the variable-binding element has one or more child nodes), and has no as attribute, then the content of the variable-binding element specifies the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value). The content of the variable-binding element is a sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor); a new document (referred to as a temporary tree) is constructed with a document node having as its children the sequence of nodes that results from evaluating the sequence constructor.] Temporary trees are described in more detail in 9.4 Temporary Trees.

If a variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) has an as attribute but no select attribute, then the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value) is the sequence that results from evaluating the (possibly empty) sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) contained within the variable-binding element (see 5.6 Sequence Constructors).

These combinations are summarized in the table below.

select attribute
as attribute
content
Effect


present
absent
empty
Value is obtained by evaluating the select attribute

present
present
empty
Value is obtained by evaluating the select attribute, adjusted to the type required by the as attribute

present
absent
present
Static error

present
present
present
Static error

absent
absent
empty
Value is a zero-length string

absent
present
empty
Value is an empty sequence, provided the as attribute permits an empty sequence

absent
absent
present
Value is a temporary tree

absent
present
present
Value is obtained by evaluating the sequence constructor, adjusted to the type required by the as attribute
[ERR XT0620] It is a static error (http://www.w3.org/TR/xslt20/#dt-static-error) if a variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) has a select attribute and has non-empty content.

Example: Values of Variables
The value of the following variable is the sequence of integers (1, 2, 3):

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

The value of the following variable is an integer, assuming that the attribute @size exists, and is annotated either as an integer, or as xdt:untypedAtomic:

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

The value of the following variable is a zero-length string:

<xsl:variable name="z"/>

The value of the following variable is document node containing an empty element as a child (that is, a temporary tree):

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

The value of the following variable is sequence of integers (2, 4, 6):

<xsl:variable name="seq" as="xs:integer*">

  <xsl:for-each select="1 to 3">

    <xsl:sequence select=".*2"/>

  </xsl:for-each>

</xsl:variable>

The value of the following variable is sequence of parentless attribute nodes:

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

The value of the following variable is an empty sequence:

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

The actual value of the variable depends on the supplied value (http://www.w3.org/TR/xslt20/#dt-supplied-value), as described above, and the required type, which is determined by the value of the as attribute.

Example: Pitfalls with Numeric Predicates
When a variable is used to select nodes by position, be careful not to do:

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

This will output the value of the first td element, because the variable n will be bound to a node, not a number. Instead, do one of the following:

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

or

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

or

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

9.4 Temporary Trees

A temporary tree is constructed by evaluating an xsl:variable, xsl:param, or xsl:with-param element that has non-empty content and that has no as attribute. This element is referred to as the variable-binding element. The value of the variable (http://www.w3.org/TR/xslt20/#dt-variable) is a single node, the document node of the temporary tree. This document node is created implicitly, and its content is formed from the result of evaluating the sequence constructor (http://www.w3.org/TR/xslt20/#dt-sequence-constructor) owned by the variable-binding element, as described in 5.6.1 Constructing Complex Content.

The base URI of a node in the temporary tree (http://www.w3.org/TR/xslt20/#dt-temporary-tree) is determined as if all the nodes in the temporary tree came from a single entity whose URI was the base URI of the variable-binding element (http://www.w3.org/TR/xslt20/#dt-variable-binding-element) (see [Data Model (http://www.w3.org/TR/xslt20/#DATAMODEL)]). Thus, the base URI of the document node will be equal to the base URI of the variable-binding element; an xml:base attribute within the temporary tree will change the base URI for its parent element and that element's descendants, just as it would within a document constructed by parsing.

A temporary tree (http://www.w3.org/TR/xslt20/#dt-temporary-tree) is available for processing in exactly the same way as any source document. For example, its nodes are accessible using path expressions, and they can be processed using instructions such as xsl:apply-templates and xsl:for-each. Also, the key and id FO functions can be used to find nodes within a temporary tree, provided that at the time the function is called, the context item is a node within the temporary tree.

Example: Two-Phase Transformation
For example, the following stylesheet uses a temporary tree as the intermediate result of a two-phase transformation, using different modes (http://www.w3.org/TR/xslt20/#dt-mode) for the two phases (see 6.5 Modes):

<xsl:stylesheet

  version="2.0"

  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="phase1.xsl"/>
<xsl:import href="phase2.xsl"/>

<xsl:variable name="intermediate">

  <xsl:apply-templates select="/" mode="phase1"/>

</xsl:variable>

<xsl:template match="/">

  <xsl:apply-templates select="$intermediate" mode="phase2"/>

</xsl:template>

</xsl:stylesheet>