Как написать xslt преобразование

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] conforming to the
Namespaces in XML Recommendation [Namespaces in XML 1.0].]

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. Thus this specification is a definition of
the syntax and semantics of the XSLT namespace.

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

A transformation expressed in XSLT describes rules for transforming
zero or more source trees into
one or more result trees. The structure of these trees
is described in [Data Model].
The transformation is achieved by
a set of template rules.
A template rule associates a pattern, which
matches nodes in the source document, with a sequence constructor.
In many cases, evaluating the sequence constructor will cause new
nodes to be constructed, which can be used 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
to be applicable to a wide class of
documents that have similar source tree structures.

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

1.2 What’s New in XSLT 2.0?

XSLT 1.0 was published in November 1999, and version 2.0 represents a significant increase
in the capability of the language. A detailed list of changes is included in J Changes from XSLT 1.0.
XSLT 2.0 has been developed in parallel with XPath 2.0 (see [XPath 2.0]), so the changes
to XPath must be considered alongside the changes to XSLT.

2.1 Terminology

For a full glossary of terms, see C Glossary.

[Definition: The software responsible
for transforming source trees into
result trees using an XSLT stylesheet
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 is referred to as
an implementation
].

[Definition: The term result tree
is used to refer to any tree constructed by instructions
in the stylesheet. A result tree is either a final result tree
or a temporary tree.]

[Definition: A final result tree
is a result tree that forms part of the final output
of a transformation. Once created, the contents of a final result tree are
not accessible within the stylesheet itself.] The xsl:result-document
instruction always creates a final result tree, and a final result tree may also be created
implicitly by the initial template.
The conditions under which
this happens are described in 2.4 Executing a Transformation.
A final result tree may be serialized
as described in 20 Serialization.

[Definition: The term source tree
means any tree provided as input to the transformation. This includes the document containing
the initial context node if any, documents containing
nodes supplied as the values of stylesheet parameters,
documents obtained from the results of functions such as document, doc^FO,
and collection^FO, and documents returned by extension functions or extension
instructions. In the context of a particular XSLT instruction, the term source tree means
any tree provided as input to that instruction; this may be a source tree of the transformation as a whole,
or it may be a temporary tree produced during the course
of the transformation.]

[Definition: The term temporary tree
means any tree that is neither a source tree
nor a final result tree.] Temporary trees
are used to hold intermediate results during the execution of the transformation.

In this specification the phrases must,
must not, should, should not,
may,
required, and recommended
are to be interpreted as described in [RFC2119].

Where the phrase must, must not,
or required relates to the behavior of the
XSLT processor, then an implementation is not conformant unless it behaves
as specified, subject to the more detailed rules in 21 Conformance.

Where the phrase must, must not,
or required relates to a stylesheet, then the
processor must enforce this constraint on stylesheets by reporting an error
if the constraint is not satisfied.

Where the phrase should, should not,
or recommended relates to a stylesheet,
then a processor may produce warning messages if the constraint is not
satisfied, but must not treat this as an error.

[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 must be described in
documentation that accompanies any conformance claim.]

[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] or the XDM specification [Data Model]. Particular
attention is drawn to the following:

• [Definition: The term atomization is defined
  in Section
  2.4.2 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].] For some nodes (for example, elements with element-only content),
  atomization generates a dynamic error.

• [Definition: The term typed value
  is defined in Section
  5.15 typed-value Accessor^DM.
  Every node except an element defined in the schema with element-only content has a
  typed value. For example, the
  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.13 string-value Accessor^DM.
  Every node has a string value. For example, the string value
  of an element is the concatenation of the string values of all its descendant text nodes.]

• [Definition: The term
  XPath 1.0 compatibility mode is defined in Section
  2.1.1 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.]

[Definition: The
term core function means a function that is specified in
[Functions and Operators] and that is in the
standard function
namespace.]

2.2 Notation

[Definition: An XSLT element is an element
in the XSLT namespace whose syntax and semantics are
defined in this specification.] For a non-normative list of XSLT elements, see
D Element Syntax Summary.

In this document the specification of each
XSLT element 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.

• An attribute that is deprecated
  is shown in a grayed font within square brackets.

• 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,
  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.

  Except where the set of allowed values of an
  attribute is specified using the italicized name string or char,
  leading and trailing whitespace in the attribute value is ignored.
  In the case of an attribute value template,
  this applies to the 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,
  extension instructions, and
  XSLT elements from
  the instruction category is allowed;
  other-declarations means that any mixture of XSLT
  elements from the declaration category,
  other than xsl:import, is
  allowed, together with user-defined data elements.

• 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 or
  other-declarations.

[ERR XTSE0010] A 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 XTSE0020] It is a static error
  if an attribute (other than an attribute written using curly brackets in
  a position where an
  attribute value template is permitted) contains a value
  that is not one of the permitted values for that attribute.

• [ERR XTDE0030] It is a non-recoverable dynamic error
  if the effective value of an attribute written
  using curly brackets, in
  a position where an attribute value template is
  permitted, is a value
  that is not one of the permitted values for that attribute.
  If the processor is able to detect the error statically (for example, when
  any XPath expressions within the curly brackets can be evaluated statically), then the processor may
  optionally signal this as a static error.

Special rules apply if the construct appears in part of
the stylesheet that is processed with
forwards-compatible behavior: see 3.9 Forwards-Compatible Processing.

[Definition: Some constructs defined in this
specification are described as being deprecated. The use of this term implies that
stylesheet authors should not use the construct, and that the construct may
be removed in a later version of this specification.] All constructs that are
deprecated in this specification are also (as it happens)
optional features that implementations are
not required to provide.

XSLT defines a set of standard functions which are additional to those defined
in [Functions and Operators]. The signatures of these functions are described using the
same notation as used in [Functions and Operators].
The names of these functions are all in the
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 is
supplied when a transformation is initiated. Except where otherwise indicated, the information
is required.

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, supplied
in the form of XML documents.

The following information is supplied to execute a transformation:

• The stylesheet module that is
  to act as the principal stylesheet module for the transformation.
  The complete 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
  (see 9.5 Global Variables and Parameters). These
  values are available for use within expressions in the
  stylesheet.

• [Definition: A node that acts as
  the initial context node for the transformation. This node is accessible within the
  stylesheet as the initial value of the XPath
  expressions
  . (dot) and self::node(),
  as described in 5.4.3.1 Maintaining Position: the Focus
  ].

  If no initial context
  node is supplied, then the context item,
  context position, and
  context size
  will initially be undefined, 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 which is to
  be executed as the entry point to the transformation. This template must
  exist within the stylesheet. If no
  named template is supplied, then the transformation starts
  with the template rule
  that best matches the 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.
  This must either be the default mode,
  or a mode that is explicitly named in the mode attribute of an
  xsl:template declaration within the stylesheet.
  If an initial mode
  is supplied, then in searching for the template rule that best matches
  the 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.

• A base output URI. [Definition: 
  The base output URI is a URI to be used as the base URI when resolving a relative URI allocated to a
  final result tree.
  If the transformation generates more than one final result
  tree, then typically each one will be allocated a URI relative to this base URI.
  ]
  The way in which a base output URI is established
  is implementation-defined.

• A mechanism for obtaining a document node and a media type, given an absolute URI. The total
  set of available documents (modeled as a mapping from URIs to document nodes) forms part of the
  context for evaluating XPath expressions, specifically the doc^FO function.
  The XSLT document function additionally requires the media type of the
  resource representation, for use in interpreting any fragment identifier present within a URI
  Reference.

  Note:

  The set of documents
  that are available to the stylesheet is
  implementation-dependent, as is
  the processing that is carried out to construct a tree representing
  the resource retrieved using a given URI. Some possible ways of
  constructing a document (specifically, rules for constructing a document
  from an Infoset or from a PSVI) are described in [Data Model].

[ERR XTDE0040] It is a non-recoverable dynamic error if the invocation of the
stylesheet specifies a template name that does not match the
expanded-QName of a named template defined in the stylesheet.

[ERR XTDE0045] It is a non-recoverable dynamic error if the invocation of the
stylesheet specifies an initial mode
(other than the default mode)
that does not match the
expanded-QName in the mode attribute of any
template defined in the stylesheet.

[ERR XTDE0047] It is a non-recoverable dynamic error if the invocation of the
stylesheet specifies both an initial mode and an initial
template.

[ERR XTDE0050] It is a non-recoverable dynamic error
if the stylesheet that is invoked declares a visible
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.

[Definition: The transformation
is performed by evaluating an initial template. If a
named template is
supplied when the transformation is initiated, then this is the initial template;
otherwise, the initial
template is the template rule
selected according to the rules of the xsl:apply-templates instruction
for processing the
initial context node in the
initial mode.]

Parameters passed to the transformation by the client application are matched against
stylesheet parameters (see 9.5 Global Variables and Parameters),
not against the template parameters declared within
the initial template.
All template parameters
within the initial template to be executed will take their default values.

[ERR XTDE0060] It is a non-recoverable dynamic error
if the initial template defines a template parameter
that specifies required="yes".

A 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]), or
they can be supplied as stylesheet parameters
(see 9.5 Global Variables and Parameters),
or as the result of an 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 three parts: a
pattern that is matched against nodes,
a (possibly empty) set of template parameters, and a
sequence
constructor that is evaluated to produce a
sequence of items.] In many cases these items are newly constructed
nodes, which are then written to a result tree.

A transformation as a whole is
executed by evaluating the sequence
constructor of the
initial template as described
in 5.7 Sequence Constructors.

The result sequence produced by evaluating the initial template is handled
as follows:

1. If the initial template has an as attribute, then the result
   sequence of the initial template is checked against the required type in the
   same way as for any other template.

2. If the result sequence is non-empty, then it is used to construct
   an implicit
   final result tree,
   following the rules described in 5.7.1 Constructing Complex Content:
   the effect is as if the initial template T were called by an
   implicit template of the form:

   <xsl:template name="IMPLICIT">
     <xsl:result-document href="">
       <xsl:call-template name="T"/>
     </xsl:result-document>
   </xsl:template>

An implicit result tree is also created when the result sequence is empty, provided
that no xsl:result-document instruction has been evaluated during the course of
the transformation. In this situation the implicit result tree will consist of a document node with no children.

A sequence constructor is a
sequence of sibling nodes in the stylesheet, each of which is either an
XSLT instruction,
a literal result element,
a text node, or
an extension instruction.

[Definition: An
instruction is either an XSLT instruction
or an extension instruction.]

[Definition: An
XSLT instruction is an XSLT element
whose syntax summary in this specification contains the annotation
<!-- category: instruction -->.]

Extension instructions are
described in 18.2 Extension Instructions.

The main categories of XSLT instruction are as follows:

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

• an instruction that returns an arbitrary sequence by evaluating an XPath expression:
  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;

• Instructions that declare variables: xsl:variable, xsl:param;

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

Often, a 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
and evaluating the 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 of the selected
template rules
may themselves contain xsl:apply-templates
instructions, this results in a cycle of selecting nodes,
identifying template rules,
constructing sequences, and constructing
result trees, that recurses
through a source tree.

2.5 The Evaluation Context

The results of some expressions and instructions in a stylesheet may depend on information
provided contextually. This context information is divided into two categories: the static
context, which is known during static analysis of the stylesheet, and the dynamic context, which
is not known until the stylesheet is evaluated. Although information in the static context is
known at analysis time, it is sometimes used during stylesheet evaluation.

Some context information can be set by means of declarations within the stylesheet itself.
For example, the namespace bindings used for any XPath expression are determined by the namespace
declarations present in containing elements in the stylesheet. Other information may
be supplied externally or implicitly: an example is the current date and time.

The context information used in processing an XSLT stylesheet includes as a subset all the context
information required when evaluating XPath expressions. The XPath 2.0 specification defines a static
and dynamic context that the host language (in this case, XSLT) may initialize, which affects the
results of XPath expressions used in that context. XSLT augments the context with additional
information: this additional information is used firstly by XSLT constructs outside the scope of
XPath (for example, the xsl:sort element), and secondly, by functions that are
defined in the XSLT specification (such as key and format-number)
that are available for use in XPath expressions appearing within a stylesheet.

The static context for an expression or other construct in a stylesheet is determined by the place
in which it appears lexically. The details vary for different components of the static context, but in
general, elements within a stylesheet module affect the static context for their descendant elements
within the same stylesheet module.

The dynamic context is maintained as a stack. When an instruction or expression is evaluated, it
may add dynamic context information to the stack; when evaluation is complete, the dynamic context
reverts to its previous state. An expression that accesses information from the dynamic context
always uses the value at the top of the stack.

The most commonly used component of the dynamic context is the
context item. This is an implicit variable whose value
is the item (it may be a node or an atomic value) currently being processed. The value of the
context item can be referenced within an XPath expression using the expression . (dot).

Full details of the static and dynamic context are provided in 5.4 The Static and Dynamic Context.

2.6 Parsing and Serialization

An XSLT stylesheet describes a process that
constructs a set of final result trees from a set of
source trees.

The stylesheet does not describe how a
source tree is constructed.
Some possible ways of constructing source trees
are described in [Data Model].
Frequently
an implementation will operate in conjunction
with an XML parser (or more strictly, in the
terminology of [XML 1.0], an XML processor), to build a 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 [DOM Level 2]). 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 XDM data model as described in [Data Model], constructs that might exist in the
original XML document, or in the DOM, but which are not within the scope of the data model,
cannot be processed by the stylesheet and cannot be guaranteed to
remain unchanged in the transformation output. Such constructs include CDATA section boundaries,
the use of entity references, and the DOCTYPE declaration and internal DTD subset.

[Definition: A frequent requirement is to
output a final 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), and attributes on the
xsl:result-document instruction, that allow a
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, or in the serialization attributes of
xsl:result-document, 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, and are described in
18.1 Extension Functions.

It is also permissible to extend the language by providing new
instructions. These
are referred to as extension instructions,
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.
For further details, see 18 Extensibility and Fallback.

The XSLT language can also be extended by the use of
extension attributes (see
3.3 Extension Attributes), and by means of
user-defined data elements
(see 3.6.2 User-defined Data Elements).

2.8 Stylesheets and XML Schemas

An XSLT 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 is compiled),
and dynamically (during evaluation of the stylesheet to transform a source document).

There are places within a stylesheet,
and within XPath expressions and
patterns in
a 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^XP syntax defined
in [XPath 2.0].

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

[Definition: The
schema components that may be referenced by name in
a stylesheet are referred to as the
in-scope schema components. This set is the same throughout all the modules of a stylesheet.]

The conformance rules for XSLT 2.0, defined in 21 Conformance, distinguish
between a basic XSLT processor and a
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 that works with a basic
XSLT processor will produce the same results with a schema-aware XSLT processor
provided
that the source documents are untyped (that is, they are not validated against a schema). However,
if source documents are validated against a schema then the results may be different from the
case where they are not validated. Some constructs that work on untyped data may fail with typed data (for example,
an attribute of type xs:date cannot be used as an argument of the
substring^FO function) and other constructs may produce different results depending
on the data type (for example, given the element <product price="10.00" discount="2.00"/>,
the expression @price gt @discount will return true if the attributes have type xs:decimal,
but will return false if they are untyped).

There is a standard set of type definitions that are always available
as in-scope schema components in every
stylesheet. These are defined in 3.13 Built-in Types. The set of built-in types
varies between a basic XSLT processor and a
schema-aware XSLT processor.

The remainder of this section describes facilities that are available only with a
schema-aware XSLT processor.

Additional schema components (type definitions,
element declarations, and attribute declarations) may be added to the
in-scope schema components
by means of the xsl:import-schema declaration in a stylesheet.

The xsl:import-schema declaration may reference an external schema
document by means of a URI, or it may contain an inline xs:schema element.

It is only necessary to import a schema explicitly
if one or more of its schema components
are referenced explicitly by name in the 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 is expected to process. The imported type definitions can be used for temporary nodes
or for nodes on a 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.
For example:

<xsl:template match="document-node(schema-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>

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 an XDM tree, as defined in [Data Model].
The implementation may choose one of several strategies for dealing with this situation:

1. The processor may signal a non-recoverable dynamic error
   if a source document is found to contain a type annotation that is not known to the processor.

2. The processor may maintain additional metadata, beyond that described in [Data Model],
   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 structure representing the
   source document itself, or it might
   be held in a system catalog or repository.

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

4. The processor may be configured to treat the source document 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 xs:untyped and xs:untypedAtomic
   respectively.

Where a stylesheet author chooses to make assertions about the types of nodes or of
variables and parameters,
it is possible for an XSLT processor to perform static analysis of the 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 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 document, that is, a tree rooted at a document node. This applies
  both to temporary trees constructed using the xsl:document (or xsl:copy) instruction
  and also to final result trees
  constructed using xsl:result-document.
  Validation is either strict or lax, as described in [XML Schema Part 1].
  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 type 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) 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 can be detected by examining
a stylesheet before execution starts (that is, before
the source document and values of stylesheet parameters
are available) is referred to as a static error.]

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

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

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

[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
whether the error is signaled or the recovery action is taken.

[Definition: If an implementation chooses to recover from
a recoverable dynamic 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 that is not recoverable is referred to as a
non-recoverable dynamic error. When a non-recoverable dynamic error occurs, the
processor
must signal the error, and the transformation fails.]

Because different implementations may optimize execution of the stylesheet in
different ways, the detection of dynamic errors is to some degree
implementation-dependent. In
cases where an implementation is able to produce the final result trees without evaluating a
particular construct, the implementation is never required to
evaluate that construct solely in order to determine whether doing so causes a dynamic error.
For example, if a variable is declared but never referenced,
an implementation 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
before any source document is available, but only if it can determine that the error would
be signaled for every possible source document and every possible set of parameter values.
For example, some circularity errors fall into this
category: see 9.8 Circular Definitions.

The XPath specification states (see Section
2.3.1 Kinds of Errors^XP)
that if any expression (at any level) can be evaluated during the analysis phase
(because all its explicit operands are known and it has no dependencies on the dynamic context),
then any error in performing this evaluation may be reported 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 unless they
would occur in every possible evaluation of that stylesheet; instead, they must be
signaled as dynamic errors, and signaled only if the XPath expression is actually evaluated.

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

[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. Alternatively, an implementation
may signal a type error during the analysis phase in the same way as a
static error,
even if it occurs in part of the stylesheet that is never evaluated, provided it can establish
that execution of a particular construct would never succeed.

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

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

<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
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. 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 serialized 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.
Static errors and dynamic errors
may occur in both cases.

[Definition: If a transformation has successfully produced
a final 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.]
If the processor performs serialization, then it must
do so as specified in 20 Serialization,
and in particular it must signal any serialization errors that occur.

Errors are identified by a QName. For errors defined in this specification,
the namespace of the QName is always http://www.w3.org/2005/xqt-errors (and is therefore
not given explicitly), while the local part is an 8-character code in the form PPSSNNNN.
Here PP is always XT (meaning XSLT), and SS is one of SE
(static error), DE (dynamic error), RE (recoverable dynamic error), or
TE (type error). Note that the allocation of an error to one of these categories is purely
for convenience and carries no normative implications about the way the error is handled. Many errors,
for example, can be reported either dynamically or statically.

These error codes are used to label error conditions in this specification,
and are summarized in E Summary of Error Conditions).
They are provided primarily for ease of reference.
Implementations may use these codes when signaling errors, but they are
not required to do so. An API specification, however, may
require the use of error codes based on these QNames.
Additional errors defined by
an implementation (or by an application) may use
QNames in an implementation-defined (or user-defined) namespace without risk of collision.

Errors defined in the [XPath 2.0] and [Functions and Operators] specifications use QNames
with a similar structure, in the same namespace. When errors occur in processing XPath expressions,
an XSLT processor should use the original error code reported by the XPath processor,
unless a more specific XSLT error code is available.

Note:

A stylesheet module is represented by an XDM element node
(see [Data Model]).
In the case of a standard stylesheet module, this
will be an xsl:stylesheet or xsl:transform element. In the case of a simplified
stylesheet module, it can be any element (not in the XSLT namespace) that has
an xsl:version attribute.

Although stylesheet modules will commonly be
maintained in the form of documents conforming to XML 1.0 or XML 1.1, this specification
does not mandate such a representation. As with source trees,
the way in which stylesheet modules are constructed, from textual XML or otherwise, is outside
the scope of this specification.

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

XSLT processors
must use the XML namespaces
mechanism [Namespaces in XML 1.0] to recognize elements and attributes from this
namespace. Elements from the XSLT namespace are recognized only in the
stylesheet and not in the source document. The complete list of
XSLT-defined elements is specified in D Element Syntax Summary.
Implementations
must not extend the XSLT
namespace with additional elements or attributes. Instead, any
extension must be in a separate namespace. Any namespace that is used
for additional instruction elements must be identified by means of the
extension instruction
mechanism specified in 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.

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, described in
  3.1 XSLT Namespace, is reserved.

• [Definition: The standard function namespace
  http://www.w3.org/2005/xpath-functions
  is used for functions in the function library defined in
  [Functions and Operators] and standard functions defined in this
  specification.]

• [Definition: The XML namespace, defined
  in [Namespaces in XML 1.0] as http://www.w3.org/XML/1998/namespace,
  is used for attributes such as xml:lang, xml:space,
  and xml:id.]

• [Definition: The schema
  namespace
  http://www.w3.org/2001/XMLSchema is used
  as defined in [XML Schema Part 1]
  ]. In a 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
  instance namespace
  http://www.w3.org/2001/XMLSchema-instance is used
  as defined in [XML Schema Part 1]
  ]. Attributes in this namespace, if they appear
  in a stylesheet, are treated by the XSLT processor in the same way as any other attributes.

• The
  namespace http://www.w3.org/2000/xmlns/ is reserved for use as described in
  [Namespaces in XML 1.0]. No element or attribute node can have a name in this
  namespace, and although the prefix xmlns is implicitly bound to this
  namespace, no namespace node will ever define this binding.

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 and
user-defined data elements,
and in the names of attributes of literal result elements or of
XSLT elements:
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 and stylesheet functions.

[ERR XTSE0080] It is a static error
to use a reserved namespace in the name of
a named template,
a mode,
an attribute set,
a key,
a decimal-format,
a variable or parameter,
a stylesheet function, a
named output definition, or a
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 (see [XPath 2.0]) 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
final 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
or implementation-dependent.

Furthermore, if serialization is performed using one of the serialization
methods xml, xhtml, html, or text
described in 20 Serialization, the presence
of an extension attribute must not cause the serializer to behave in a way
that is inconsistent with the mandatory provisions of that specification.

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

[ERR XTSE0090] It is a 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
at its top level, and it may also be used for a
simplified stylesheet module. It
should not be used for an XML document containing an
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,
xpath-default-namespace,
default-collation, and use-when.]

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

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

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

These attributes all affect the element they appear on,
together with any elements and attributes that have
that element as an ancestor. 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,
[xsl:]xpath-default-namespace, and [xsl:]default-collation,
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
ancestor-or-self element on which the attribute appears.

In an embedded stylesheet module,
standard attributes
appearing on ancestors of the outermost element of the stylesheet module have no effect.

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.

The effect of the [xsl:]use-when attribute is
described in 3.12 Conditional Element Inclusion.

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 entry for the xsl:stylesheet and
xsl:transform elements only.
This reflects the fact that these attributes are often used on the
xsl:stylesheet element only, in which case they apply to the entire
stylesheet module.

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

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

[xsl:]version

see 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

[xsl:]use-when

see 3.12 Conditional Element Inclusion

[xsl:]default-collation

see 3.6.1 The default-collation attribute

3.6 Stylesheet Element

<xsl:stylesheet
  id? = id
  extension-element-prefixes? = tokens
  exclude-result-prefixes? = tokens
  version = number
  xpath-default-namespace? = uri
  default-validation? = "preserve" | "strip"
  default-collation? = uri-list
  input-type-annotations? = "preserve" | "strip" | "unspecified">
  <!-- Content: (xsl:import*, other-declarations) -->
</xsl:stylesheet>

<xsl:transform
  id? = id
  extension-element-prefixes? = tokens
  exclude-result-prefixes? = tokens
  version = number
  xpath-default-namespace? = uri
  default-validation? = "preserve" | "strip"
  default-collation? = uri-list
  input-type-annotations? = "preserve" | "strip" | "unspecified">
  <!-- Content: (xsl:import*, other-declarations) -->
</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.

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

[ERR XTSE0110] The value of the version attribute
must be a number: specifically, it must be a
a valid instance of the type xs:decimal as defined in
[XML Schema Part 2].
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
that specifies [xsl:]version="1.0" in the
outermost element of the principal
stylesheet module (that is, version="1.0" in the case of a
standard stylesheet module, or
xsl:version="1.0" in the case of a 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.
These rules require that if the processor does not support
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
is enabled (see 3.9 Forwards-Compatible Processing).

The effect of the input-type-annotations attribute is described
in 4.3 Stripping Type Annotations from a Source Tree.

The default-validation attribute defines the default value
of the validation attribute of all xsl:document, 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. It also
determines the validation applied to the implicit
final result tree created in the absence of an
xsl:result-document instruction.
This default applies within the stylesheet module:
it does not extend to included or imported stylesheet modules.
If the attribute is omitted, the default is strip.
The permitted values are preserve and strip.
For details of the effect of this attribute, see 19.2 Validation.

[ERR XTSE0120] An xsl:stylesheet element must not have
any text node children. (This rule applies after stripping of
whitespace text nodes 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 are declarations.
Top-level elements in any other namespace are
user-defined data elements
(see 3.6.2 User-defined Data Elements)].

The 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

Note that the xsl:variable and xsl:param elements
can act either as declarations or as instructions.
A global variable or parameter is defined using a declaration; a local variable or parameter using an instruction.

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
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.7 Simplified Stylesheet Modules

A simplified syntax is allowed for a stylesheet module
that defines only a single template rule for the document node.
The stylesheet module may consist of
just a 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 containing the literal result element,
minus its xsl:version attribute;
the template rule has a match pattern of /.

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

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

More formally, a simplified stylesheet module is
equivalent to the standard stylesheet module that would be generated by
applying the following transformation to the simplified stylesheet module,
invoking the transformation by calling the
named template
expand, with
the containing literal result element as the 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" select="@xsl:version"/>
    <xsl:element name="xsl:template">
      <xsl:attribute name="match">/</xsl:attribute>
      <xsl:copy-of select="."/>
    </xsl:element>
  </xsl:element>
</xsl:template>  

</xsl:stylesheet>

[ERR XTSE0150] A literal result element that
is used as the outermost element of a
simplified stylesheet module must have
an xsl:version attribute. This
indicates the version of XSLT that the stylesheet requires.
For this version of XSLT, the value will normally be 2.0; the
value must be a valid instance of the type
xs:decimal as defined in [XML Schema Part 2].

Other
literal result elements may also
have an xsl:version attribute. When the xsl:version
attribute is numerically less than
2.0, backwards-compatible processing behavior is enabled (see 3.8 Backwards-Compatible Processing).
When the xsl:version attribute is numerically greater than 2.0,
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.
Thus, a literal result element used as the document element of
a simplified stylesheet cannot
contain declarations.
Simplified stylesheets therefore cannot use
global variables,
stylesheet parameters,
stylesheet functions,
keys,
attribute-sets, or
output definitions.
In turn this means that the only useful way to initiate the transformation is to supply a document node as the
initial context node, to be matched by the
implicit match="/" template rule using the default mode.

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 is processed with
backwards-compatible behavior, then the expression is evaluated with XPath 1.0 compatibility mode
set to true. For details of this mode, see Section
2.1.1 Static Context^XP.
Furthermore,
in such an expression any function call for which no implementation is
available (unless it uses the
standard function namespace) is bound to a
fallback error function whose effect when evaluated is to raise a dynamic error
[see ERR XTDE1425] . The effect is that with
backwards-compatible behavior enabled, calls
on extension functions
that are not available in a particular implementation
do not cause an error unless the function call is actually evaluated. For
further details, see 18.1 Extension Functions.

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.

It is
implementation-defined
whether a particular XSLT 2.0 implementation supports backwards-compatible behavior.

[ERR XTDE0160] If an implementation does not support backwards-compatible
behavior, then it is a non-recoverable dynamic error
if any element is evaluated that enables
backwards-compatible behavior.

3.9 Forwards-Compatible Processing

The intent of forwards-compatible behavior is to make it possible to
write a stylesheet that takes advantage of features introduced in some version of
XSLT subsequent to XSLT 2.0, while retaining the ability to execute the
stylesheet with an XSLT 2.0 processor using appropriate fallback behavior.

It is always possible to write conditional code to run under different XSLT
versions by using the use-when feature described in 3.12 Conditional Element Inclusion. The
rules for forwards-compatible behavior supplement this mechanism in two
ways:

• certain constructs in the stylesheet that mean nothing to an XSLT 2.0
  processor are ignored, rather than being treated as errors.

• explicit fallback behavior can be defined for instructions defined in a
  future XSLT release, using the
  xsl:fallback instruction.

The detailed rules follow.

[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 where forwards-compatible
behavior is enabled:

• 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 to occur as children of the xsl:stylesheet element,
  then the element and its content must be ignored.

• 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 in the XSLT namespace appears as part of a
  sequence constructor, and XSLT 2.0 does not allow
  such elements to appear as part of a sequence constructor, then:

  1. If the element has one or more xsl:fallback children, then no error
     is reported either statically or dynamically, and the result of evaluating the instruction is the concatenation of
     the sequences formed by evaluating the sequence constructors within its
     xsl:fallback children, in document order. Siblings of the xsl:fallback
     elements are ignored, even if they are valid XSLT 2.0 instructions.

  2. If the element has no xsl:fallback children, then a static error is reported in the
     same way as if forwards-compatible behavior were not enabled.

<xsl:stylesheet version="17.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:exciting-new-17.0-feature>
      <xsl:fly-to-the-moon/>
      <xsl:fallback>
        <html>
          <head>
            <title>XSLT 17.0 required</title>
          </head>
          <body>
            <p>Sorry, this stylesheet requires XSLT 17.0.</p>
          </body>
        </html>
      </xsl:fallback>
    </xsl:exciting-new-17.0-feature>
  </xsl:template>
</xsl:stylesheet>

<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')) lt 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 provides two mechanisms to construct
a stylesheet from multiple
stylesheet modules:

• an inclusion mechanism that allows stylesheet modules to be combined
  without changing the semantics of the modules being combined,
  and

• an import mechanism that allows stylesheet modules to override each
  other.

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

         A
         |
     +---+---+
     |       |
     B       C
     |       |
     D       E

3.11 Embedded Stylesheet Modules

An embedded stylesheet module
is a stylesheet module whose containing element is not
the outermost element of the containing XML document. Both
standard stylesheet modules and
simplified stylesheet modules
may be embedded in this way.

Two situations where embedded stylesheets may be useful are:

• The stylesheet may be embedded in the source document to be transformed.

• The stylesheet may be embedded in an XML document that describes a sequence of processing
  of which the XSLT transformation forms just one part.

The xsl:stylesheet element may have an id
attribute to facilitate reference to the stylesheet module within the containing document.

<?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">
  <!-- ignore -->
</xsl:template>
</xsl:stylesheet>
</head>
<body>
<para id="foo">
...
</para>
</body>
</doc>

3.12 Conditional Element Inclusion

Any element in the XSLT namespace may have a use-when attribute whose
value is an XPath expression that can be evaluated statically. If the attribute is present
and the effective boolean value^XP of the
expression is false, then the element, together with all the nodes having
that element as an ancestor, is effectively excluded from the
stylesheet module. When a node
is effectively excluded from a stylesheet module the stylesheet module has the same effect
as if the node were not there. Among other things this means that no static or dynamic errors
will be reported in respect of the element and its contents, other than errors in the
use-when attribute itself.

A literal result element,
or any other element within a
stylesheet module that is not in the XSLT namespace,
may similarly carry an xsl:use-when attribute.

If the xsl:stylesheet or xsl:transform element itself is
effectively excluded, the effect is to exclude all the children of the
xsl:stylesheet or xsl:transform element, but not the
xsl:stylesheet or xsl:transform element or its attributes.

Conditional element exclusion happens after stripping of whitespace text nodes from the
stylesheet, as described in 4.2 Stripping Whitespace from the Stylesheet.

There are no syntactic constraints on the XPath expression that can be used as the value of the
use-when attribute. However, there are severe constraints on the information provided
in its evaluation context. These constraints are designed to ensure that the expression can be
evaluated at the earliest possible stage of stylesheet processing, without any dependency
on information contained in the stylesheet itself or in any source document.

Specifically, the components of the static and dynamic context are defined by the following two tables:

Within a stylesheet module,
all expressions contained in [xsl:]use-when
attributes are evaluated in a single execution scope^FO.
This need not be
the same execution scope as that used for [xsl]:use-when expressions in other
stylesheet modules, or as that used when evaluating XPath expressions appearing
elsewhere in the stylesheet module. This means that a function such as
current-date^FO will return the same result when called in different
[xsl:]use-when expressions within the same stylesheet module, but will not
necessarily return the same result as the same call in an [xsl:]use-when
expression within a different stylesheet module, or as a call on
the same function executed during the transformation proper.

The use of [xsl:]use-when is illustrated in the following examples.

<xsl:import-schema schema-location="http://example.com/schema"
              use-when="system-property('xsl:is-schema-aware')='yes'"/>

<xsl:template match="/" 
              use-when="system-property('xsl:is-schema-aware')='yes'" 
              priority="2">
  <xsl:result-document validation="strict">
    <xsl:apply-templates/>
  </xsl:result-document>
</xsl:template>

<xsl:template match="/">
  <xsl:apply-templates/>
</xsl:template>

<xsl:include href="module-A.xsl" 
     use-when="system-property('xsl:vendor')='vendor-A'"/>
<xsl:include href="module-B.xsl" 
     use-when="system-property('xsl:vendor')='vendor-B'"/>

3.13 Built-in Types

Every XSLT 2.0 processor includes the following named type definitions
in the in-scope schema components:

• All the primitive atomic types defined in [XML Schema Part 2],
  with the exception of xs:NOTATION. That is:
  xs:string,
  xs:boolean,
  xs:decimal,
  xs:double,
  xs:float,
  xs:date,
  xs:time,
  xs:dateTime,
  xs:duration,
  xs:QName,
  xs:anyURI,
  xs:gDay,
  xs:gMonthDay,
  xs:gMonth,
  xs:gYearMonth,
  xs:gYear,
  xs:base64Binary, and
  xs:hexBinary.

• The derived atomic type xs:integer defined in [XML Schema Part 2].

• The types xs:anyType and xs:anySimpleType.

• The following types defined in [XPath 2.0]:
  xs:yearMonthDuration,
  xs:dayTimeDuration,
  xs:anyAtomicType,
  xs:untyped, and
  xs:untypedAtomic.

A schema-aware XSLT processor additionally supports:

• All other built-in types defined in [XML Schema Part 2]

• User-defined types, and element and attribute declarations, that are
  imported using an xsl:import-schema declaration
  as described in 3.14 Importing Schema Components. These may include both simple and complex types.

An implementation may define mechanisms that allow additional
schema components to be added to the
in-scope schema components for the
stylesheet. For example, the mechanisms used to define
extension functions
(see 18.1 Extension Functions) may also be used to
import the types used in the interface to such functions.

These schema components are the only ones that may be
referenced in XPath expressions within the stylesheet, or in the
[xsl:]type and as attributes of those elements that permit these attributes.

For a Basic XSLT Processor, schema built-in types that are not included in the
static context (for example, xs:NCName) are «unknown types» in the sense of
Section
2.5.4 SequenceType Matching^XP. In the language of that section, a Basic XSLT Processor
must be able to determine whether these unknown types are derived from known
schema types such as xs:string. The purpose of this rule is to ensure that
system functions such as local-name-from-QName^FO, which is defined to return
an xs:NCName, behave correctly. A stylesheet that uses a Basic XSLT Processor
will not be able to test whether the returned value is an xs:NCName, but it will
be able to use it as if it were an xs:string.

3.14 Importing Schema Components

<!-- Category: declaration -->
<xsl:import-schema
  namespace? = uri-reference
  schema-location? = uri-reference>
  <!-- Content: xs:schema? -->
</xsl:import-schema>

The xsl:import-schema declaration is used to identify
schema components (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 must refer to an
in-scope schema component,
which means they must either be built-in types as defined in 3.13 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, 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.

The namespace and schema-location attributes are both optional.

If the xsl:import-schema element contains an
xs:schema element, then the schema-location
attribute must be absent, and one of the following
must be true:

• the namespace attribute of the xsl:import-schema
  element and the targetNamespace attribute of the xs:schema
  element are both absent (indicating a no-namespace schema), or

• the namespace attribute of the xsl:import-schema
  element and the targetNamespace attribute of the xs:schema
  element are both present and both have the same value, or

• the namespace attribute of the xsl:import-schema
  element is absent and the targetNamespace attribute of
  the xs:schema element is present, in which case the target namespace
  is as given on the xs:schema element.

[ERR XTSE0215] It is a
static error if an xsl:import-schema
element that contains an xs:schema element has a schema-location attribute,
or if it has a namespace attribute that conflicts with the target namespace
of the contained schema.

If two xsl:import-schema declarations specify the same namespace,
or if both specify no namespace, then only the
one with highest 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, 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 it is explicitly present, or is implied by the
  targetNamespace attribute of a contained xs:schema element,
  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.
  If there is a contained xs:schema element, the effective value of the
  schemaLocation attribute is a URI referencing a document containing a copy of the xs:schema
  element.

• 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
(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 Part 1]
(section 4.2.3, References to schema components across namespaces).

[ERR XTSE0220] It is a
static error if the
synthetic schema document does not satisfy the constraints described in
[XML Schema 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.

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.

<xsl:import-schema>
  <xs:schema targetNamespace="http://localhost/ns/yes-no"
             xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:simpleType name="local:yes-no">
      <xs:restriction base="xs:string">
        <xs:enumeration value="yes"/>
        <xs:enumeration value="no"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:schema>
</xsl:import-schema>

<xs:variable name="condition" select="local:yes-no('yes')" as="local:yes-no"/>

Note:

Features of a source XML document that are not represented
in the XDM tree 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 XDM data model defined in [Data Model] is capable of representing
either an XML 1.0 document (conforming to [XML 1.0] and [Namespaces in XML 1.0])
or an XML 1.1 document (conforming to [XML 1.1] and [Namespaces in XML 1.1]), and
it makes no distinction between the two.
In principle, therefore, XSLT 2.0 can be used with either of these XML versions.

Construction of the XDM tree 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 XDM tree 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 XDM tree 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^XML
and 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.
Implementations may support either version; it is
recommended
that an XSLT 2.0 processor that implements the 1.1 versions should also provide a mode
that supports the 1.0 versions. It is thus implementation-defined
whether the XSLT processor supports XML 1.0 with XML Namespaces 1.0, or XML 1.1 with XML Namespaces 1.1, or supports both versions at user
option.

At the time of writing there is no published version of [XML Schema Part 2] 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, and do not allow the full range of values permitted by XML 1.1.
This situation will not be resolved until a new
version of [XML Schema Part 2] becomes available; in the meantime, it is recommended
that implementers wishing to support XML 1.1 should consult [XML Schema 1.0 and XML 1.1] for guidance.
An XSLT 2.0 processor that supports XML 1.1 should
implement the rules in later versions of [XML Schema Part 2] as they become available.

4.2 Stripping Whitespace from the Stylesheet

The tree representing the stylesheet is preprocessed as follows:

1. All comments and processing instructions are removed.

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

3. Any 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.

4. Any 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

5. Any 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 XTSE0260] Within an
XSLT element that is required to be empty,
any content other than comments or processing instructions, including any
whitespace text node
preserved using the xml:space="preserve" attribute, is a
static error.

4.3 Stripping Type Annotations from a Source Tree

[Definition: The term
type annotation is used in this specification to refer to the value returned by the
dm:type-name accessor of a node: see Section
5.14 type-name Accessor^DM.]

There is sometimes a requirement to write stylesheets that produce the same
results whether or not the source documents have been validated against a
schema. To achieve this, an option is provided to remove any type annotations
on element and attribute nodes in a source tree,
replacing them with an annotation of xs:untyped in the case of element
nodes, and xs:untypedAtomic in the case of attribute nodes.

Such stripping of type annotations can be requested by specifying
input-type-annotations="strip" on the xsl:stylesheet
element. This attribute
has three permitted values: strip, preserve,
and unspecified. The
default value is unspecified. Stripping of type annotations takes place if
at least one stylesheet module
in the stylesheet specifies
input-type-annotations="strip".

[ERR XTSE0265] It is a
static error if there is a
stylesheet module
in the stylesheet that specifies
input-type-annotations="strip" and
another stylesheet module
that specifies input-type-annotations="preserve".

The source trees to which this applies are the same as those affected by
xsl:strip-space and xsl:preserve-space:
see 4.4 Stripping Whitespace from a Source Tree.

When type annotations are stripped, the following changes are made to the source tree:

• The type annotation of every element node is changed to xs:untyped

• The type annotation of every attribute node is changed to xs:untypedAtomic

• The typed value of every element and attribute node is set to be the same as its string value, as
  an instance of xs:untypedAtomic.

• The is-nilled property of every element node is set to false.

The values of the is-id and is-idrefs properties are
not changed.

4.4 Stripping Whitespace from a Source Tree

A source tree supplied as input to the
transformation process may contain whitespace text nodes
that are of no interest,
and that do not need to be retained by the transformation. Conceptually,
an XSLT processor makes a copy of the source
tree from which unwanted whitespace text nodes
have been removed. This process is referred to as whitespace stripping.

For the purposes of this section, the term source tree means the document
containing the initial context node, and any document
returned by the functions document, doc^FO, or
collection^FO. It does not include documents passed as the values of
stylesheet parameters or returned from
extension functions.

The stripping process takes as input a set of element names
whose child whitespace text nodes are to be preserved.
The way in which this set of element names is established using the
xsl:strip-space and xsl:preserve-space declarations
is described later in this section.

A 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
is stripped.

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

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

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

The set of
whitespace-preserving element names is specified by
xsl:strip-space and xsl:preserve-space
declarations. Whether an
element name is included in the set of whitespace-preserving names is
determined by the best match 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^XP; an element name matches an
xsl:strip-space or xsl:preserve-space
element if it matches one of the NameTests^XP.
An element matches a NameTest^XP if and only if the
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^XP. This is determined in the
same way as with template rules:

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

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

[ERR XTRE0270] It is a recoverable dynamic error if
this
leaves more than one match, unless all the matched declarations are equivalent (that is,
they are all xsl:strip-space or they are all xsl:preserve-space).
The optional recovery action is to select, from the matches that are left, the
one that occurs last in
declaration order.

If an element in a source document has a type annotation
that is a simple type or a complex type with
simple content, then any whitespace text nodes among its children are preserved, regardless of
any xsl:strip-space declarations. The reason for this
is that stripping a whitespace
text node from an element with simple content could make the element invalid: for
example, it could cause the minLength facet to be violated.

Stripping of type annotations happens before stripping of whitespace text nodes,
so this situation
will not occur if input-type-annotations="strip" is specified.

4.5 Attribute Types and DTD Validation

The mapping from the Infoset to the XDM data model, described in
[Data Model], does not retain attribute types. This means, for example, that an attribute
described in the DTD as having attribute type NMTOKENS will be annotated in the XDM tree
as xs:untypedAtomic rather than xs:NMTOKENS, and its typed value
will consist of a single xs:untypedAtomic value rather than a sequence of
xs:NMTOKEN values.

Attributes with a DTD-derived type of ID, IDREF, or IDREFS will be marked in the
XDM tree as having the is-id or is-idrefs properties. It is these properties,
rather than any type annotation, that are examined by the functions id^FO and
idref^FO described in [Functions and Operators].

4.6 Limits

The XDM data model (see [Data Model]) leaves it to the host language to
define limits. This section describes the limits that apply to XSLT.

Limits on some primitive data types are defined in [XML Schema Part 2].
Other limits, listed below, are implementation-defined.
Note that this does not necessarily mean that each limit must be a simple constant: it may vary depending
on environmental factors such as available resources.

The following limits are implementation-defined:

1. For the xs:decimal type, the maximum number of decimal digits
   (the totalDigits facet). This must be at least 18 digits. (Note, however, that
   support for the full value range of xs:unsignedLong requires 20 digits.)

2. For the types xs:date, xs:time, xs:dateTime, xs:gYear,
   and xs:gYearMonth: the range of values of the year component, which must be
   at least +0001 to +9999; and the maximum number of fractional second digits, which must be at least 3.

3. For the xs:duration type: the maximum absolute values of the
   years, months, days, hours, minutes, and seconds components.

4. For the xs:yearMonthDuration type: the maximum absolute value,
   expressed as an integer number of months.

5. For the xs:dayTimeDuration type: the maximum absolute value,
   expressed as a decimal number of seconds.

6. For the types xs:string, xs:hexBinary, xs:base64Binary, xs:QName,
   xs:anyURI, xs:NOTATION, and types derived from them: the maximum length of the value.

7. For sequences, the maximum number of items in a sequence.

4.7 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
(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 supports
the disable-output-escaping attribute
of xsl:text and xsl:value-of,
(see 20.2 Disabling Output Escaping), then the data model
for trees constructed by the processor is augmented with a boolean value
representing the value of this property. 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.

5.1 Qualified Names

The name of a stylesheet-defined object, specifically
a named template,
a mode,
an attribute set,
a key,
a decimal-format,

a variable or parameter,
a stylesheet function, a
named output definition,
or a character map
is specified as a QName using the syntax
for QName^Names as defined in [Namespaces in XML 1.0].

[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 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 to emphasize that it is referring
to a 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 in the form
(NCName ":")? NCName, that is, a local name
optionally preceded by a namespace prefix.]

[Definition: A
string in the form of a lexical QName may occur
as the value of an attribute node in a stylesheet
module, or within an XPath expression contained in
such an attribute node, or as the result
of evaluating an XPath expression contained in such an attribute node.
The element
containing this attribute node is referred to as the defining element of the QName.]

[Definition: An
expanded-QName contains a pair of values,
namely a local name and an optional namespace URI. It may also contain a namespace prefix.
Two expanded-QNames are equal if the namespace URIs are the same
(or both absent) and the local names are the same. The prefix plays
no part in the comparison, but is used only if the expanded-QName needs to be converted back
to a string.]

If the QName has a prefix, then the
prefix is expanded into a URI reference using the namespace
declarations in effect on its defining element. The
expanded-QName
consisting of the local part of the name and the possibly null URI
reference is used as the name of the object. The default namespace of the defining element
(see Section
6.2 Element Nodes^DM) is
not used for unprefixed names.

There are three cases where the default namespace
of the defining element
is used when expanding an unprefixed QName:

1. Where a QName is used to define the name of an element
   being constructed.
   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).

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

3. The default namespace applies to any unqualified element names
   appearing in the cdata-section-elements attribute of
   xsl:output or xsl:result-document

In the case of an unprefixed QName used as a
NameTest within an XPath 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 XTSE0280] In the case of a prefixed
QName
used as the value of an attribute in the
stylesheet, or appearing within
an XPath expression in the stylesheet,
it is a static error if the defining element has
no namespace node whose name matches the prefix of the QName.

[ERR XTDE0290] Where the result of evaluating an XPath expression (or an
attribute value template) is required to be a lexical QName,
then unless otherwise specified
it is a non-recoverable dynamic error if the defining element has
no namespace node whose name matches the prefix of the lexical QName.
This error may be signaled as a
static error
if the value of the expression can be determined statically.

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 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, 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,
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 (including XPath expressions in
attribute value templates).
The effect of this is specified in [XPath 2.0]; 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

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

• any unprefixed type name
  used in the type attribute of an XSLT element

• any unprefixed type name
  used in the xsl:type attribute of a
  literal result element.

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
of the parent element (see Section
6.2 Element Nodes^DM)
is not used.

The attribute does not affect other names, for example function names,
variable names, or template names, or strings that are interpreted as
lexical QNames during stylesheet evaluation,
such as the effective value of the name
attribute of xsl:element or the string supplied as the first argument to
the key function.

5.3 Expressions

XSLT uses the expression language defined by XPath 2.0 [XPath 2.0].
Expressions are used in XSLT for a variety of purposes including:

• selecting nodes for processing;

• specifying conditions for different ways of processing a node;

• generating text to be inserted in a result tree.

[Definition: Within this specification, the term
XPath expression, or simply expression, means
a string that matches the production
Expr^XP
defined in [XPath 2.0].]

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

Except where
forwards-compatible behavior
is enabled (see 3.9 Forwards-Compatible Processing), it is a
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^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 that are
in scope. Error codes are defined in [XPath 2.0].

The transformation fails with a
non-recoverable dynamic error if any XPath
expression
is evaluated and raises a dynamic error.
Error codes are defined in [XPath 2.0].

The transformation fails with a
type error
if an XPath expression raises a type error, or if the result of evaluating
the XPath expression is evaluated and raises a type error,
or if the XPath processor signals a type error during static analysis of an
expression.
Error codes are defined in [XPath 2.0].

[Definition: The context within a stylesheet
where an XPath expression
appears may specify the required type of
the expression. The required type indicates the type of the 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 is converted to the required type
using the function conversion rules. These are the rules defined in
[XPath 2.0] 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 is set to false.]

This specification also invokes the
XPath 2.0 function conversion rules
to convert the result of evaluating an XSLT 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 or
type error that occurs when applying the
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.

5.4 The Static and Dynamic Context

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

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

The following four sections describe:

5.4.1 Initializing the Static Context

5.4.2 Additional Static Context Components used by XSLT

5.4.3 Initializing the Dynamic Context

5.4.4 Additional Dynamic Context Components used by XSLT

5.5 Patterns

A 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 (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.]
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.

5.6 Attribute Value Templates

[Definition: In an
attribute that is designated as an
attribute value template, such as an attribute of a
literal result element,
an 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 enclosed
in curly brackets ({}). A fixed part
may contain any characters, except that a left curly bracket must be written as
{{ and a right curly bracket must be written as }}.

[ERR XTSE0350] It is a static error
if an unescaped left curly bracket appears in a fixed part of an attribute value template without a matching right
curly bracket.

It is a static error
if the string contained between matching curly brackets in an attribute value template
does not match the XPath production Expr^XP, or if it contains
other XPath static errors. The error is signaled using the appropriate XPath error code.

[ERR XTSE0370] It is a 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 ({{ or }}) by the
  corresponding single curly bracket.

• The expansion of a variable part is obtained
  by evaluating the enclosed XPath
  expression and converting the resulting value to a string.
  This
  conversion is done using the rules given in 5.7.2 Constructing Simple Content.

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

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

<xsl:template match="photograph">
  <img src="{$image-dir}/{href}" width="{size/@width}"/>
</xsl:template>

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

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

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

<temperature readings="10.32 5.5 8.31"/>

Curly brackets are not recognized recursively inside
expressions.

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

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

5.7 Sequence Constructors

[Definition: A sequence
constructor is a sequence of zero or more
sibling nodes in the 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,
and also
literal result elements, are defined to take
a sequence constructor as
their content.

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

• Text nodes appearing in the 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
  are evaluated to create a new parentless element node,
  having the same expanded-QName
  as the literal result element, which is added to the result
  sequence: see 11.1 Literal Result Elements

• XSLT instructions 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
  (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
  / causes a type error if the root of the tree containing the context node
  is not a document node..

  Parentless attribute nodes require particular care because they have no namespace nodes associated
  with them. A parentless attribute node is not permitted to contain namespace-sensitive
  content (for example, a QName or an XPath expression) because there
  is no information enabling 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,
  xsl:document, xsl:result-document,
  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.7.1 Constructing Complex Content.

• The sequence may be used to construct the 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.7.2 Constructing Simple Content.