/

[ERR XTSE0150]
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
Note:
This might appear to contradict the specification of XPath
2.0, which states that a static error [XPST0017]
is raised when an expression
contains a call to a function that is not present (with matching name and
arity) in the static context. This apparent contradiction is resolved by
specifying that the XSLT processor constructs a static context for the
expression in which every possible function name and arity (other than names in
the
standard function namespace
is present; when no other implementation of
the function is available, the function call is bound to a fallback error
function whose run-time effect is to raise a dynamic error.
Certain XSLT constructs also produce different results when backwards-compatible behavior is enabled.
This is described separately for each such construct.
These rules do not apply to the
xsl:output
element,
whose
version
attribute
has an entirely different purpose: it is used to define the version of the output
method to be used for serialization.
Note:
By making use of backwards-compatible behavior, it is possible
to write the stylesheet in a way that ensures that its results when processed with an XSLT 2.0 processor are
identical to the effects of processing the same stylesheet using an
XSLT 1.0 processor. The differences are described (non-normatively) in
J.1 Incompatible Changes
To assist with transition, some parts of a stylesheet may be processed with backwards compatible behavior enabled,
and other parts with this behavior disabled. All data values manipulated by an XSLT 2.0 processor are defined by
the XDM data model, whether or not the relevant expressions use backwards compatible behavior.
Because the same data model is used in both cases, expressions are fully composable. The result of evaluating
instructions or expressions with backwards compatible behavior is fully defined in the XSLT 2.0 and XPath 2.0
specifications, it is not defined by reference to the XSLT 1.0 and XPath 1.0 specifications.
It is
implementation-defined
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.
Note:
To write a stylesheet that works with both XSLT 1.0 and 2.0 processors, while making
selective use of XSLT 2.0 facilities, it is necessary to understand both the rules for
backwards-compatible behavior in XSLT 2.0, and the rules for forwards-compatible
behavior in XSLT 1.0. If the
xsl:stylesheet
element specifies
version="2.0"
, then an XSLT 1.0 processor will ignore XSLT 2.0
declarations
that were not defined in XSLT 1.0, for
example
xsl:function
and
xsl:import-schema
. If any new XSLT 2.0
instructions are used (for example
xsl:analyze-string
or
xsl:namespace
),
or if new XPath 2.0 features are used (for example, new functions, or syntax such as conditional
expressions, or calls to a function defined using
xsl:function
),
then the stylesheet must provide fallback behavior that relies on XSLT 1.0 and XPath 1.0
facilities only. The fallback behavior can be invoked by using the
xsl:fallback
instruction, or by testing the results of the
function-available
or
element-available
functions, or by testing the value of the
xsl:version
property returned by the
system-property
function.
3.9 Forwards-Compatible Processing
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:
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.
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.
Example: Forwards Compatible Behavior
For example,
an XSLT 2.0
processor
will
process the following stylesheet without error, although the
stylesheet includes elements from
the
XSLT namespace
that are not
defined in this specification:
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

Sorry, this stylesheet requires XSLT 17.0.

Sorry, this stylesheet requires XSLT 17.0.



...



...

3.10 Combining Stylesheet Modules
XSLT provides two mechanisms to construct
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.
3.10.1 Locating Stylesheet Modules
The include and import mechanisms use two declarations,
xsl:include
and
xsl:import
, which are defined in the sections that follow.
These declarations use an
href
attribute, whose value is a
URI reference
to identify the
stylesheet module
to be included
or imported. If the value of this
attribute is a relative URI, it is resolved as described in
5.8 URI References
After resolving against the base URI, the way in which the URI reference is
used to locate a representation of a
stylesheet module
, and the way in which
the stylesheet module is constructed from that representation, are
implementation-defined
. In particular,
it is implementation-defined which URI schemes are supported, whether
fragment identifiers are supported, and what media types are supported.
Conventionally, the URI is a reference to a resource containing the
stylesheet module as a source XML document, or it may include a fragment
identifier that selects an embedded stylesheet module within a source XML
document; but the implementation is free to use other mechanisms to locate
the stylesheet module identified by the URI reference.
The referenced
stylesheet module
may be any of the four kinds of stylesheet module:
that is, it may be
standalone
or
embedded
, and it may be
standard
or
simplified
. If it is a
simplified stylesheet module
then
it is transformed into the equivalent
standard stylesheet module
by applying the transformation described in
3.7 Simplified Stylesheet Modules
Implementations
may
choose to accept
URI references containing a fragment identifier defined
by reference to the XPointer specification (see
[XPointer Framework]
). Note that if
the implementation does not support the use of fragment identifiers in the URI reference,
then it will not be possible to include an
embedded
stylesheet module
[ERR XTSE0165]
It is a
static error
if the processor is not able to retrieve the resource
identified by the URI reference, or if the resource that is retrieved does
not contain a stylesheet module conforming to this specification.
3.10.2 Stylesheet Inclusion

href
uri-reference
/>
A stylesheet module may include another stylesheet module using an
xsl:include
declaration.
The
xsl:include
declaration
has a
required
href
attribute whose value is a URI reference
identifying the stylesheet module to be included. This attribute is used as described
in
3.10.1 Locating Stylesheet Modules
[ERR XTSE0170]
An
xsl:include
element
must
be a
top-level
element.
[Definition:
stylesheet level
is a collection of
stylesheet modules
connected
using
xsl:include
declarations:
specifically, two stylesheet modules
and
are part of the same
stylesheet level if one of them includes the other by means of an
xsl:include
declaration, or if there is a third stylesheet module
that is in the same
stylesheet level as both
and
[Definition:
The
declarations
within a
stylesheet level
have a total ordering known
as
declaration order
. The order of declarations within a stylesheet
level is the same as the document order that would result if each stylesheet module were
inserted textually in place of the
xsl:include
element that references it.
In other respects, however, the effect of
xsl:include
is not equivalent to
the effect that would be obtained by textual inclusion.
[ERR XTSE0180]
It is a
static error
if a stylesheet module
directly or indirectly includes itself.
Note:
It is not intrinsically an error for a
stylesheet
to include the same module more than once. However, doing so can cause errors
because of duplicate definitions. Such multiple inclusions are less
obvious when they are indirect. For example, if stylesheet
includes stylesheet
, stylesheet
includes stylesheet
, and stylesheet
includes
both stylesheet
and stylesheet
, then
will be included indirectly by
twice. If
all of
and
are used as
independent stylesheets, then the error can be avoided by separating
everything in
other than the inclusion of
into a separate stylesheet
B'
and changing
to
contain just inclusions of
B'
and
, similarly
for
, and then changing
to include
B'
C'
3.10.3 Stylesheet Import

href
uri-reference
/>
A stylesheet module may import another
stylesheet module
using an
xsl:import
declaration
Importing a stylesheet module is the same
as including it (see
3.10.2 Stylesheet Inclusion
) except that
template rules
and other
declarations
in the
importing module take precedence over
template rules and declarations in the imported module; this is
described in more detail below.
The
xsl:import
declaration
has a
required
href
attribute whose value is a URI reference
identifying the stylesheet module to be included. This attribute is used as described
in
3.10.1 Locating Stylesheet Modules
[ERR XTSE0190]
An
xsl:import
element
must
be a
top-level
element.
[ERR XTSE0200]
The
xsl:import
element children
must
precede all other
element children of an
xsl:stylesheet
element, including
any
xsl:include
element children and any
user-defined data elements
Example: Using
xsl:import
For example,
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">



italic


[Definition:
The
stylesheet levels
making up a
stylesheet
are
treated as forming an
import tree
. In the import tree,
each stylesheet level has one child for each
xsl:import
declaration that it contains.
The ordering
of the children is the
declaration order
of the
xsl:import
declarations within their stylesheet level.
[Definition:
declaration
in the stylesheet
is defined to have lower
import precedence
than another
declaration
if the stylesheet level containing
would be
visited before the stylesheet level containing
in a
post-order traversal of the import tree (that is, a traversal of the
import tree in which a stylesheet level is visited
after its children). Two declarations within the same stylesheet level have
the same import precedence.
For example, suppose
stylesheet module
imports stylesheet modules
and
in that order;
stylesheet module
imports stylesheet module
stylesheet module
imports stylesheet module
Then the import tree has the following structure:
+---+---+
| |
B C
| |
D E
The order of import precedence (lowest first) is
In general, a
declaration
with higher import precedence takes precedence over a declaration with
lower import precedence. This is defined in detail for each kind of declaration.
[ERR XTSE0210]
It is a
static error
if
a stylesheet module directly or indirectly imports itself.
Note:
The case where a stylesheet module with a particular
URI is imported several times is not treated specially. The effect is exactly the same as if
several stylesheet modules with different URIs but identical content were imported. This might or might
not cause an error, depending on the content of the stylesheet module.
3.11 Embedded Stylesheet Modules
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.
Note:
In order for such an attribute value to be used as a fragment
identifier in a URI, the XDM attribute node must generally have the
is-id
property: see
Section
5.5 is-id Accessor
DM
. This property will typically be set
if the attribute is defined in a DTD as being of type
ID
, or if is defined in a schema as being
of type
xs:ID
. It is also necessary that the media type of the containing document should
support the use of ID values as fragment identifiers. Such support is widespread in existing products, and
is expected to be endorsed in respect of the media type
application/xml
by a future
revision of
[RFC3023]
An alternative, if the implementation supports it, is to
use an
xml:id
attribute. XSLT allows this attribute (like other namespaced attributes)
to appear on any
XSLT element
Example: The
xml-stylesheet
Processing Instruction
The following example shows how the
xml-stylesheet
processing instruction (see
[XML Stylesheet]
) can be used to allow a
source document to contain its own stylesheet. The URI reference uses a
relative URI with a fragment identifier to locate the
xsl:stylesheet
element:




version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format">











...



Note:
A stylesheet module that is embedded in the document to which it is
to be applied typically needs
to contain a
template rule
that specifies that
xsl:stylesheet
elements are to be ignored.
Note:
The above example uses the pseudo-attribute
type="application/xslt+xml"
in the
xml-stylesheet
processing instruction to denote an XSLT stylesheet. This usage
is subject to confirmation:
see
3.4 XSLT Media Type
In the absence of a registered media type for XSLT stylesheets, some vendors' products
have adopted different conventions, notably
type="text/xsl"
Note:
Support for the
xml-stylesheet
processing instruction is not
required for conformance with this Recommendation. Implementations are not
constrained in the mechanisms they use to identify a stylesheet when a transformation is initiated:
see
2.3 Initiating a Transformation
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.
Note:
This does not apply to XML parsing or validation errors, which
will be reported in the usual way.
It also does not apply to attributes
that are necessarily processed
before
[xsl:]use-when
, examples being
xml:space
and
[xsl:]xpath-default-namespace
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.
Note:
This allows all the declarations that depend on the same condition to be
included in one stylesheet module, and for their inclusion or exclusion to be controlled
by a single
use-when
attribute at the level of the module.
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:
Static Context Components for
use-when
Expressions
Component
Value
XPath 1.0 compatibility mode
false
In scope namespaces
determined by the in-scope namespaces for the containing element
in the stylesheet
Default element/type namespace
determined by the
xpath-default-namespace
attribute
if present (see
5.2 Unprefixed QNames in Expressions and Patterns
); otherwise the null namespace
Default function namespace
The
standard function namespace
In scope type definitions
The type definitions that would be available in the absence of any
xsl:import-schema
declaration
In scope element declarations
None
In scope attribute declarations
None
In scope variables
None
In scope functions
The
core functions
defined in
[Functions and Operators]
together with the functions
element-available
function-available
type-available
and
system-property
defined in this specification, plus
the set of extension functions that are
present in the static context of every XPath expression (other than a use-when expression) within the
content of the element that is the parent of the
use-when
attribute.
Note that
stylesheet functions
are
not
included in the context, which means that the function
function-available
will
return
false
in respect of such functions. The effect of this
rule is to ensure that
function-available
returns true in respect of functions that
can be called within the scope of the
use-when
attribute. It also has the effect that
these extensions functions will be recognized within the
use-when
attribute itself;
however, the fact that a function is available in this sense gives no guarantee that a call on the
function will succeed.
In scope collations
Implementation-defined
Default collation
The Unicode Codepoint Collation
Base URI
The base URI of the containing element in the stylesheet
Statically known documents
None
Statically known collections
None
Dynamic Context Components for
use-when
Expressions
Component
Value
Context item, position, and size
Undefined
Dynamic variables
None
Current date and time
Implementation-defined
Implicit timezone
Implementation-defined
Available documents
None
Available collections
None
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.
Example: Using Conditional Exclusion to Achieve Portability
This example demonstrates the use of the
use-when
attribute to
achieve portability of a stylesheet across schema-aware and non-schema-aware processors.
use-when="system-property('xsl:is-schema-aware')='yes'"/>

use-when="system-property('xsl:is-schema-aware')='yes'"
priority="2">

The effect of these declarations is that a non-schema-aware processor ignores the
xsl:import-schema
declaration and the first template rule, and therefore
generates no errors in respect of the schema-related constructs in these declarations.
Example: Including Variant Stylesheet Modules
This example includes different stylesheet modules depending on which XSLT processor
is in use.
use-when="system-property('xsl:vendor')='vendor-A'"/>
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
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.
Note:
The names that are imported from the XML Schema namespace do not include all the
names of top-level types defined in either the Schema for Schemas or the Schema for Datatypes. The Schema
for Datatypes, as well as defining built-in types such as
xs:integer
and
xs:double
also defines types that are intended for use only within the Schema for DataTypes, such as
xs:derivationControl
. A
stylesheet
that is designed to process XML Schema documents as its
input or output may import the Schema for Schemas.
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
Note:
The facilities described in this section are not available
with a
basic XSLT processor
They require a
schema-aware XSLT processor
as described in
21 Conformance

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


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.
Note:
The synthetic schema document does not need to be constructed by a real implementation. It is purely
a mechanism for defining the semantics of
xsl:import-schema
in terms of rules that
already exist within the XML Schema specification. In particular, it implicitly defines the
rules that determine whether the set of
xsl:import-schema
declarations are
mutually consistent.
These rules do not cause names to be imported transitively. The fact that
a name is available for reference within a schema document A does not of itself make the name available
for reference in a stylesheet that imports the target namespace of schema document A.
(See
[XML Schema Part 1]
section 3.15.3, Constraints on XML Representations of Schemas.)
The stylesheet must import all the namespaces containing names that it actually references.
The
namespace
attribute indicates that a schema for the given namespace is required
by the
stylesheet
. This information may be enough on its own
to enable an implementation to locate
the required schema components. The
namespace
attribute may be omitted
to indicate that a schema for names in no namespace is being imported. The zero-length
string is not a valid namespace URI, and is therefore not a valid value for the
namespace
attribute.
The
schema-location
attribute is a
URI Reference
that gives a hint indicating where a schema document
or other resource containing the required definitions may be found. It is likely that a
schema-aware XSLT processor
will
be able to process a schema document found at this location.
The XML Schema specification gives implementations flexibility in how to handle
multiple imports for the same namespace. Multiple imports do not cause
errors if the definitions do not conflict.
A consequence of these rules is that it is not intrinsically an error if no schema
document can be located for a namespace identified in an
xsl:import-schema
declaration.
This will cause an error only if it results in the stylesheet containing references to names that have not
been imported.
An inline schema document (using an
xs:schema
element as a child of the
xsl:import-schema
element) has the same status as an external schema document, in the sense that it acts as a hint for a source of schema
components in the relevant namespace. To ensure that the inline schema document is always used, it is advisable to
use a target namespace that is unique to this schema document.
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.
Example: An Inline Schema Document
The following example shows an inline schema document. This declares a simple type
local:yes-no
, which the stylesheet then uses in the declaration of a variable.
The example assumes the namespace declaration
xmlns:local="http://localhost/ns/yes-no"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

4 Data Model
The data model used by XSLT is the XPath 2.0 and XQuery 1.0 data model
(XDM), as
defined in
[Data Model]
. XSLT operates on source, result and
stylesheet documents using the same data model.
This section elaborates on some particular features of XDM as
it is used by XSLT:
The rules in
4.2 Stripping Whitespace from the Stylesheet
and
4.4 Stripping Whitespace from a Source Tree
make use of the concept of a whitespace text node.
[Definition:
whitespace text node
is a text node whose content consists entirely of whitespace characters (that is,
#x09, #x0A, #x0D, or #x20).
Note:
Features of a source XML document that are not represented
in the 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.
Note:
The specification referenced as
[Namespaces in XML 1.0]
was actually
published without a version number.
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:
All comments and processing instructions are removed.
Any text nodes that are now adjacent to each other are merged.
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
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
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
Note:
Using
xml:space="preserve"
in parts of the stylesheet that
contain
sequence constructors
will cause all text nodes in that part of the stylesheet,
including those that contain whitespace only, to be copied to the result of the sequence constructor.
When the result of the sequence constructor is used to form the content of an element, this can cause errors
if such text nodes are followed by attribute nodes generated using
xsl:attribute
Note:
If an
xml:space
attribute is
specified on a
literal result element
it will be copied to the result tree in the same way as any other attribute.
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.
Note:
Stripping type annotations does not necessarily return the
document to the state it would be in had validation not taken place. In
particular, any defaulted elements and attributes that were added to the
tree by the validation process will still be present , and
elements and attributes validated as IDs will still be accessible using the
id
FO
function.
4.4 Stripping Whitespace from a Source Tree
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.
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.

elements
tokens
/>

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.
Note:
In
[Data Model]
, processes are described for constructing an
XDM tree from an Infoset or from a PSVI. Those processes
deal with whitespace according to their own rules, and the provisions in
this section apply to the resulting tree. In practice this means that
elements that are defined in a DTD or a Schema to contain element-only
content will have
whitespace text nodes
stripped, regardless of the
xsl:strip-space
and
xsl:preserve-space
declarations in the stylesheet.
However, source trees are not necessarily constructed using those processes;
indeed, they are not necessarily constructed by parsing XML documents.
Nothing in the XSLT specification constrains how the source tree is
constructed, or what happens to
whitespace text nodes
during its construction. The
provisions in this section relate only to whitespace text nodes that are
present in the tree supplied as input to the XSLT processor. The XSLT
processor cannot preserve whitespace text nodes unless they were actually
present in the supplied tree.
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
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.)
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.
For the
xs:duration
type: the maximum absolute values of the
years, months, days, hours, minutes, and seconds components.
For the
xs:yearMonthDuration
type: the maximum absolute value,
expressed as an integer number of months.
For the
xs:dayTimeDuration
type: the maximum absolute value,
expressed as a decimal number of seconds.
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.
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.
Note:
In practice, the nodes in a
final result tree
will often be streamed
directly from the XSLT processor to the serializer. In such an implementation,
disable-output-escaping
can be viewed not so much a property stored with nodes
in the tree, but rather as additional information passed across the interface between the
XSLT processor and the serializer.
5 Features of the XSLT Language
5.1 Qualified Names
The name of a stylesheet-defined object, specifically
named template
mode
an
attribute set
key
decimal-format

variable
or
parameter
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:
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:
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:
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:
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).
The default namespace is used when expanding the first argument
of the function
element-available
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.
Note:
Note the distinction between the two kinds of error that may occur. Attempting to convert
an integer to a date is a type error, because such a conversion is never possible. Type errors can be reported
statically if they can be detected statically, whether or not the construct in question is ever evaluated.
Attempting to convert the string
2003-02-29
to a date is a dynamic error rather than a type error,
because the problem is with this particular value, not with its type.
Dynamic errors are reported only if the instructions or expressions that cause them are actually evaluated.
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.4.1 Initializing the Static Context
The
static context
XP
of an XPath
expression appearing in an XSLT stylesheet is initialized as follows. In these rules,
the term
containing element
means the element within the stylesheet that is
the parent of the attribute whose value contains the XPath expression in question,
and the term
enclosing element
means the containing element or any of its ancestors.
XPath 1.0 compatibility mode
is set to true
if and only if the containing element
occurs in part of the
stylesheet
where
backwards compatible behavior
is enabled (see
3.8 Backwards-Compatible Processing
).
The
statically known namespaces
XP
are the namespace declarations that are in scope for the containing element.
The
default element/type namespace
XP
is the namespace defined by the
[xsl:]xpath-default-namespace
attribute on the innermost enclosing element
that has such an attribute, as described in
5.2 Unprefixed QNames in Expressions and Patterns
. The value of this attribute
is a namespace URI. If there is no
[xsl:]xpath-default-namespace
attribute on an enclosing element,
the default namespace for element names and type names is the null namespace.
The
default function namespace
XP
is the
standard function namespace
defined in
[Functions and Operators]
. This means that it is not necessary to declare this
namespace in the
stylesheet
, nor is it necessary
to use the prefix
fn
(or any other prefix) in calls to the
core functions
The
in-scope schema definitions
XP
for the XPath expression are the same as the
in-scope schema components
for the
stylesheet
, and are as specified in
3.13 Built-in Types
The
in-scope variables
XP
are defined by the
variable binding elements
that are in scope
for the containing element (see
9 Variables and Parameters
).
The
function signatures
XP
are the
core functions
defined
in
[Functions and Operators]
the constructor functions for all the atomic types in the
in-scope schema definitions
XP
the additional
functions defined in this specification, the
stylesheet
functions
defined in the stylesheet, plus any
extension
functions
bound using
implementation-defined
mechanisms (see
18 Extensibility and Fallback
).
Note:
It follows from the above that a conformant XSLT processor must implement the
entire library of
core functions
defined in
[Functions and Operators]
The
statically known collations
XP
are
implementation-defined
However, the set of in-scope collations
must
always include
the Unicode codepoint collation, defined in
Section
7.3 Equality and Comparison of Strings
FO
The
default collation
XP
is
defined by the value of the
[xsl:]default-collation
attribute on the innermost enclosing
element that has such an attribute. For details, see
3.6.1 The default-collation attribute
[Definition:
In
this specification the term
default collation
means the collation that
is used by XPath operators such as
eq
and
lt
appearing in
XPath expressions within the stylesheet.
This collation is also used by default when comparing strings
in the evaluation of the
xsl:key
and
xsl:for-each-group
elements. This
may
also
(but need not necessarily) be the same as the default collation used for
xsl:sort
elements
within the stylesheet. Collations used by
xsl:sort
are described in
13.1.3 Sorting Using Collations
The
base URI
XP
is the base URI of the containing element. The concept
of the base URI of a node is defined in
Section
5.2 base-uri Accessor
DM
5.4.2 Additional Static Context Components used by XSLT
Some of the components of the XPath static context are used also by
XSLT elements
. For
example, the
xsl:sort
element makes use of the collations defined in the static
context, and attributes such as
type
and
as
may reference types defined
in the
in-scope schema components
Many top-level declarations in a stylesheet, and attributes on the
xsl:stylesheet
element, affect the behavior of instructions within the stylesheet. Each of these constructs is
described in its appropriate place in this specification.
A number of these constructs are of particular significance because they are
used by functions defined in XSLT, which are added to the library of functions available for use in
XPath expressions within the stylesheet. These are:
The set of named keys, used by the
key
function
The set of named decimal formats, used by the
format-number
function
The values of system properties, used by the
system-property
function
The set of available instructions, used by the
element-available
function
5.4.3 Initializing the Dynamic Context
For convenience, the dynamic context is described in two parts: the
focus
, which represents the place in the source document that
is currently being processed, and a collection of additional context variables.
A number of functions specified in
[Functions and Operators]
are defined to be
stable
FO
, meaning that if they are called
twice during the same
execution scope
FO
with the same arguments, then they return the same results
(see
Section
1.7 Terminology
FO
).
In XSLT, the execution of a stylesheet defines the execution scope.
This means, for example, that if the function
current-dateTime
FO
is called repeatedly during
a transformation, it produces the same result each time. By implication, the components
of the dynamic context on which these functions depend are also stable for the duration
of the transformation. Specifically, the following components defined in
Section
2.1.2 Dynamic Context
XP
must be stable:
function implementations
current dateTime
implicit timezone
available documents
available collections
, and
default collection
The values of global variables and stylesheet parameters are also stable
for the duration of a transformation. The focus is
not
stable;
the additional dynamic context components defined in
5.4.4 Additional Dynamic Context Components used by XSLT
are also
not
stable.
As specified in
[Functions and Operators]
, implementations may provide user options that relax the
requirement for the
doc
FO
and
collection
FO
functions
(and therefore, by implication,
the
document
function) to return stable results. By default, however, the
functions must be stable. The manner in which such user options are provided, if
at all, is
implementation-defined
XPath expressions contained in
[xsl:]use-when
attributes are not considered to be evaluated "during the
transformation" as defined above. For details see
3.12 Conditional Element Inclusion
5.4.3.1 Maintaining Position: the Focus
[Definition:
When a
sequence constructor
is
evaluated, the
processor
keeps track of which
items are being processed
by means of a set of implicit variables referred to collectively as the
focus
More specifically, the focus consists of the following three values:
[Definition:
The
context item
is the item currently
being processed. An item (see
[Data Model]
) is either an atomic value (such as an
integer, date, or string), or a node. The context item is initially set to the
initial context node
supplied when the transformation is invoked (see
2.3 Initiating a Transformation
).
It changes
whenever instructions such as
xsl:apply-templates
and
xsl:for-each
are used to process a sequence of items; each item in such a sequence becomes the context item
while that item is being processed.
The context item is returned by the XPath
expression
(dot).
[Definition:
The
context position
is the position of
the context item within the sequence of items currently being processed. It changes whenever the
context item changes. When an instruction such as
xsl:apply-templates
or
xsl:for-each
is used to process
a sequence of items, the first item in the sequence is processed with a context position of 1, the
second item with a context position of 2, and so on.
The context position is returned
by the XPath
expression
position()
[Definition:
The
context size
is the number of items in
the sequence of items currently being processed. It changes
whenever instructions such as
xsl:apply-templates
and
xsl:for-each
are used to process a sequence of items; during the processing of each one of those items, the
context size is set to the count of the number of items in the sequence (or equivalently, the position
of the last item in the sequence).
The context size is returned
by the XPath
expression
last()
[Definition:
If the
context item
is a node (as distinct
from an atomic value such as an integer), then it is also referred to as the
context node
The context node is not an independent variable, it changes whenever the context item changes. When
the context item is an atomic value, there is no context
node.
The context node is returned by the XPath
expression
self::node()
, and it is used
as the starting node for all relative path expressions.
Where the containing element of an XPath expression is an
instruction
or a
literal result element
the initial context item, context position, and context size
for the XPath
expression
are the same as
the
context item
context position
, and
context size
for the
evaluation of the containing instruction or literal result element.
In other cases (for example, where the containing element is
xsl:sort
xsl:with-param
, or
xsl:key
),
the rules are given in the specification of the containing element.
The
current
function can be used within any XPath
expression
to select the item that was supplied as the context item to the XPath expression by the XSLT processor.
Unlike
(dot) this is unaffected by changes to the context item that occur within
the XPath expression. The
current
function is described in
16.6.1 current
On completion of an instruction that changes the
focus
(such as
xsl:apply-templates
or
xsl:for-each
), the focus reverts to its previous value.
When a
stylesheet function
is called,
the focus within the body of the function is initially undefined. The focus
is also undefined on initial entry to the
stylesheet
if no
initial context node
is supplied.
When the focus is
undefined, evaluation of any
expression
that
references the context item, context position, or context size results
in a
non-recoverable dynamic error
[XPDY0002]
The description above gives an outline of the way the
focus
works. Detailed rules for the effect
of each instruction are given separately with the description of that instruction. In the absence
of specific rules, an instruction uses the same focus as its parent instruction.
[Definition:
singleton focus
based on a node
has the
context item
(and therefore the
context node
) set to
and the
context position
and
context size
both set to 1 (one).
5.4.3.2 Other components of the XPath Dynamic Context
The previous section explained how the
focus
for an XPath
expression appearing in an XSLT stylesheet is initialized.
This section explains how the other components of the
dynamic context
XP
of an XPath
expression are initialized.
The
dynamic variables
XP
are the current values of the in-scope
variable binding elements
The
current date and time
represents an
implementation-dependent
point in time
during processing of the transformation; it does not change during the course of the transformation.
The
implicit timezone
XP
is
implementation-defined
The
available documents
XP
and the
available collections
XP
are determined as part of the process for initiating a transformation (see
2.3 Initiating a Transformation
).
The
available documents
XP
are defined as part of the XPath 2.0 dynamic context to support
the
doc
FO
function, but this component is also referenced by the similar XSLT
document
function: see
16.1 Multiple Source Documents
. This variable defines
a mapping between URIs passed to the
doc
FO
or
document
function and the document nodes that are returned.
Note:
Defining this as part of the evaluation context is a formal way of
specifying that the way in which URIs get turned into document nodes is outside the control of the
language specification, and depends entirely on the run-time environment in which the transformation
takes place.
The XSLT-defined
document
function
allows the use of URI references containing fragment identifiers.
The interpretation of a fragment identifier
depends on the media type of the resource representation.
Therefore, the information supplied in
available documents
XP
for XSLT processing
must provide not only a mapping from URIs to document nodes as required by XPath, but also a mapping
from URIs to media types.
The
default collection
XP
is
implementation-defined
. This allows options such
as setting the default collection to be an empty sequence, or to be undefined.
5.4.4 Additional Dynamic Context Components used by XSLT
In addition to the values that make up the
focus
an XSLT processor maintains a number of other dynamic context components that reflect aspects of the evaluation
context. These components are fully described in the sections of the specification that maintain and use them.
They are:
The
current template rule
, which is the
template rule
most recently invoked by an
xsl:apply-templates
xsl:apply-imports
or
xsl:next-match
instruction: see
6.7 Overriding Template Rules
The
current mode
, which is the
mode
set by the most recent call of
xsl:apply-templates
(for a full definition see
6.5 Modes
);
The
current group
and
current grouping key
which provide information about the collection of items currently being processed
by an
xsl:for-each-group
instruction: see
14.1 The Current Group
and
14.2 The Current Grouping Key
The
current captured substrings
this is a sequence of strings, which is maintained when a string
is matched against a regular expression using the
xsl:analyze-string
instruction,
and which is accessible using the
regex-group
function:
see
15.2 Captured Substrings
The
output state
: this is a flag whose two possible
values are
final output state
and
temporary output state
. This flag indicates whether
instructions are currently writing to a
final result tree
or to an internal data structure. The
initial setting is
final output state
, and it is switched
to
temporary output state
by instructions such as
xsl:variable
. For more details, see
19.1 Creating Final Result Trees
The following non-normative table summarizes the initial state of each
of the components in the
evaluation context, and the instructions which cause the state of the component to change.
Component
Initial Setting
Set by
Cleared by
focus
singleton focus based on the
initial context node
if supplied
xsl:apply-templates
xsl:for-each
xsl:for-each-group
xsl:analyze-string
calls on
stylesheet functions
current template rule
If a
named template
is supplied as the entry point
to the transformation, then null; otherwise the
initial template
xsl:apply-templates
xsl:apply-imports
xsl:next-match
xsl:for-each
xsl:for-each-group
, and
xsl:analyze-string
and calls on
stylesheet functions
. Also cleared while
evaluating global variables or default values of stylesheet parameters, and the sequence constructors
contained in
xsl:key
and
xsl:sort
current mode
the initial
mode
xsl:apply-templates
calls on
stylesheet functions
evaluation of global variables and stylesheet parameters, evaluation of the sequence constructor
contained in
xsl:key
or
xsl:sort
. Clearing the current mode
causes the current mode to be set to the default (unnamed) mode.
current group
empty sequence
xsl:for-each-group
calls on
stylesheet functions
current grouping key
empty sequence
xsl:for-each-group
calls on
stylesheet functions
current captured substrings
empty sequence
xsl:matching-substring
xsl:non-matching-substring
calls on
stylesheet functions
output state
final output state
Set to
temporary output state
by instructions
such as
xsl:variable
xsl:attribute
, etc., and by
calls on
stylesheet functions
None
5.5 Patterns
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:
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.5.1 Examples of Patterns
Example: Patterns
Here are some examples of patterns:
para
matches any
para
element.
matches any element.
chapter|appendix
matches any
chapter
element and any
appendix
element.
olist/entry
matches any
entry
element with
an
olist
parent.
appendix//para
matches any
para
element with
an
appendix
ancestor element.
schema-element(us:address)
matches any element that is annotated as
an instance of the
type defined by the schema element declaration
us:address
and whose name is either
us:address
or the name of another element
in its substitution group.
attribute(*, xs:date)
matches any attribute
annotated as being of type
xs:date
matches a document node.
document-node()
matches a document node.
document-node(schema-element(my:invoice))
matches the document node
of a document whose document element is named
my:invoice
and matches the type defined by the global
element declaration
my:invoice
text()
matches any text node.
node()
matches any node other than an attribute
node, namespace node, or document node.
id("W33")
matches the element with unique ID
W33
para[1]
matches any
para
element
that is the first
para
child element of its
parent. It also matches a parentless
para
element.
//para
matches any
para
element
that has a parent node.
bullet[position() mod 2 = 0]
matches any
bullet
element that is an even-numbered
bullet
child of its parent.
div[@class="appendix"]//p
matches any
element with a
div
ancestor element that
has a
class
attribute with value
appendix
@class
matches any
class
attribute
not
any element that has a
class
attribute).
@*
matches any attribute node.
5.5.2 Syntax of Patterns
[ERR XTSE0340]
Where an attribute is
defined to contain a
pattern
it is a
static error
if the
pattern does not match the production
Pattern
Every pattern is a legal XPath
expression
, but the converse is not true:
2+2
is an example of a legal XPath expression that is not a pattern.
The XPath expressions that can be used as patterns are those that
match the grammar for
Pattern
, given below.
Informally, a
Pattern
is
a set of path expressions separated by
where each step
in the path expression is constrained to be an
AxisStep
XP
that uses only the
child
or
attribute
axes. Patterns may
also use the
//
operator.
Predicate
XP
within the
PredicateList
XP
in a pattern
can contain arbitrary XPath expressions (enclosed between square brackets)
in the same way as a
predicate
XP
in a path expression.
Patterns may start with an
id
FO
or
key
function call,
provided that the value to be matched is supplied as either a literal or a reference to
variable
or
parameter
and the key name (in the case of the
key
function)
is supplied as a string literal. These patterns will
never match a node in a tree whose root is not a document node.
If a pattern occurs in part of the
stylesheet
where
backwards compatible behavior
is enabled (see
3.8 Backwards-Compatible Processing
), then
the semantics of the pattern are defined on the basis that the equivalent
XPath expression is evaluated with
XPath 1.0 compatibility mode
set to true.
Patterns
[1]
Pattern
::=
PathPattern
Pattern
'|'
PathPattern
[2]
PathPattern
::=
RelativePathPattern
| '/'
RelativePathPattern
| '//'
RelativePathPattern
IdKeyPattern
(('/' | '//')
RelativePathPattern
)?
[3]
RelativePathPattern
::=
PatternStep
(('/' | '//')
RelativePathPattern
)?
[4]
PatternStep
::=
PatternAxis
NodeTest
XP
PredicateList
XP
[5]
PatternAxis
::=
('child' '::' | 'attribute' '::' | '@')
[6]
IdKeyPattern
::=
'id' '('
IdValue
')'
| 'key' '('
StringLiteral
XP
','
KeyValue
')'
[7]
IdValue
::=
StringLiteral
XP
VarRef
XP
[8]
KeyValue
::=
Literal
XP
VarRef
XP
The constructs
NodeTest
XP
PredicateList
XP
VarRef
XP
Literal
XP
, and
StringLiteral
XP
are part of the XPath expression
language, and are defined in
[XPath 2.0]
5.5.3 The Meaning of a Pattern
The meaning of a pattern is defined formally as follows.
First we define the concept of an
equivalent expression
. In general,
the equivalent expression is the XPath expression that takes the same lexical form as the pattern as written.
However, if the pattern contains a
PathPattern
that is a
RelativePathPattern
, then
the first
PatternStep
PS
of this
RelativePathPattern
is adjusted to allow it to match
a parentless element or attribute node, as follows:
If the
NodeTest
in
PS
is
document-node()
(optionally
with arguments), and if no explicit axis is specified, then the axis in step
PS
is taken as
self
rather than
child
If
PS
uses the child axis (explicitly or
implicitly), and if the
NodeTest
in
PS
is not
document-node()
(optionally
with arguments),
then the axis in step
PS
is replaced by
child-or-top
, which is defined as follows.
If the context node is a parentless element, comment, processing-instruction, or text node
then the
child-or-top
axis selects the context node; otherwise it selects the children of
the context node. It is a forwards axis whose principal node kind is element.
If
PS
uses the attribute axis,
then the axis in step
PS
is replaced by
attribute-or-top
, which is defined as follows.
If the context node is an attribute node with no parent,
then the
attribute-or-top
axis selects the context node; otherwise it selects the attributes of
the context node. It is a forwards axis whose principal node kind is attribute.
The axes
child-or-top
and
attribute-or-top
are introduced
only for definitional purposes. They cannot be used explicitly in a user-written pattern or expression.
Note:
The purpose of these adjustments is to ensure that a pattern such as
person
matches any
element named
person
, even if it has no parent; and similarly, that the pattern
@width
matches any attribute named
width
, even a parentless attribute. The rule also ensures that
a pattern using a
NodeTest
of the form
document-node(...)
matches a document node.
The pattern
node()
will
match any element, text node, comment, or processing instruction, whether or not it has a parent.
For backwards compatibility reasons, the pattern
node()
, when used without an explicit axis,
does not match document nodes, attribute nodes, or namespace nodes. The rules are also phrased to ensure
that positional patterns of the form
para[1]
continue to count nodes relative to their parent,
if they have one.
Let the equivalent expression, calculated according to these rules, be
EE
To determine whether a node
matches the pattern,
evaluate the
expression
root(.)//(
EE
with a
singleton focus
based on
If the result is a sequence of nodes that includes
, then node
matches the pattern; otherwise node
does not match the pattern.
Example: The Semantics of Patterns
The pattern
matches any
element,
because a
element will always be present in the result
of evaluating the
expression
root(.)//(child-or-top::p)
. Similarly,
matches a document node, and only a document node,
because the result of the
expression
root(.)//(/)
returns the root node of the tree containing the context node if and
only if it is a document node.
The pattern
node()
matches all nodes selected by the expression
root(.)//(child-or-top::node())
, that is, all element, text, comment, and processing
instruction nodes, whether or not they have a parent. It does not match attribute or namespace nodes because the
expression does not select nodes using the attribute or namespace axes.
It does not match document nodes
because for backwards compatibility reasons the
child-or-top
axis does not
match a document node.
Although the semantics of patterns are specified formally in
terms of expression evaluation, it is possible to understand pattern
matching using a different model. In a pattern,
indicates alternatives; a
pattern with one or more
separated alternatives matches
if any one of the alternatives matches. A pattern such as
book/chapter/section
can be examined from right to left. A node will only match this pattern
if it is a
section
element;
and then, only if its parent is a
chapter
; and then, only
if the parent of that
chapter
is a
book
. When the
pattern uses the
//
operator, one can still read it from right to
left, but this time testing the ancestors of a node rather than its parent.
For example
appendix//section
matches every
section
element that has an ancestor
appendix
element.
The formal definition, however, is useful for understanding the meaning
of a pattern such as
para[1]
. This matches any node selected
by the expression
root(.)//(child-or-top::para[1])
: that is, any
para
element that is the first
para
child of its parent, or a
para
element that has no parent.
Note:
An implementation, of course, may use any
algorithm it wishes for evaluating patterns, so long as the result corresponds
with the formal definition above. An implementation that followed the formal
definition by evaluating the equivalent expression and then testing the membership of
a specific node in the result would probably be very inefficient.
5.5.4 Errors in Patterns
Any
dynamic error
or
type error
that occurs during the evaluation
of a
pattern
against a particular node is treated as a
recoverable error
even if the error
would not be recoverable under other circumstances. The
optional recovery action
is to treat
the pattern as not matching that node.
Note:
The reason for this provision is that it is difficult for the stylesheet
author to predict which predicates in a pattern will actually be evaluated. In the case of
match patterns in template rules, it is not even possible to predict which patterns will be evaluated
against a particular node. Making errors in patterns recoverable enables an implementation,
if it chooses to do so, to report such errors while stylesheets are under development, while
masking them if they occur during production running.
One particular optimization is
required
by this specification: for a
PathPattern
that starts with
or
//
or with an
IdKeyPattern
the result of testing this pattern against a node in a tree whose root is not a document node
must be a non-match, rather than a dynamic error. This rule applies
to each
PathPattern
within a
Pattern
Note:
Without the above rule, any attempt to apply templates to a parentless element
node would create the risk of a dynamic error if the stylesheet has a template rule specifying
match="/"
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
}}
Note:
An expression within a variable part may contain an unescaped curly bracket
within a
StringLiteral
XP
or within a comment.
[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
Note:
This process can generate dynamic errors, for example if
the sequence contains an element with a complex content type (which cannot
be atomized).
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.
Note:
Not all attributes are designated as attribute value
templates. Attributes whose value is an
expression
or
pattern
attributes of
declaration
elements
and attributes that refer to named XSLT objects are generally not designated as
attribute value templates (an exception is the
format
attribute of
xsl:result-document
). Namespace declarations
are not XDM attribute nodes and are therefore never treated as
attribute value templates.
Example: Attribute Value Templates
The following example creates an
img
result element
from a
photograph
element in the source; the value of the
src
and
width
attributes are computed using
XPath expressions enclosed in attribute value templates:

With this source

headquarters.jpg


the result would be

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

produces the output node:

Curly brackets are
not
recognized recursively inside
expressions.
Example: Curly Brackets can not be Nested
For example:

is
not
allowed. Instead, use simply:

5.7 Sequence Constructors
[Definition:
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
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.