/

[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 a
stylesheet
from
multiple
stylesheet modules
an inclusion mechanism that allows stylesheet
modules to be combined without changing the semantics
of the modules being combined, and
an import mechanism that allows stylesheet modules
to override each other.
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 the
namespace
attribute must either have
the same value as the
targetNamespace
attribute of the
xs:schema
element (if
present), or must be absent, in which case its effective
value is that of the
targetNamespace
attribute
of the
xs:schema
element if present or the
zero-length string otherwise.
[ERR XTSE0215]
It is a
static error
if
an
xsl:import-schema
element that contains an
xs:schema
element has
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
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 a
named
template
, a
mode
an
attribute set
, a
key
, a
decimal-format
, a
variable
or
parameter
, a
stylesheet function
, a named
output definition
or a
character
map
is specified as a
QName
using the syntax for
QName
Names
as defined in
[Namespaces in XML 1.0]
[Definition:
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:
A string in the form of a
lexical QName
may occur as the value of an attribute
node in a stylesheet module, or within an XPath
expression
contained
in such an attribute node, or as the result of evaluating
an XPath expression contained in such an attribute node.
The element containing this attribute node is referred to
as the
defining element
of the QName.
[Definition:
An
expanded-QName
contains a pair of values, namely a local name and an
optional namespace URI. It may also contain a namespace
prefix.
Two expanded-QNames are equal if the
namespace URIs are the same (or both absent) and the local
names are the same.
The prefix plays no part in the
comparison, but is used only if the expanded-QName needs to
be converted back to a string.
If the QName has a prefix, then the prefix is expanded
into a URI reference using the namespace declarations in
effect on its
defining element
. The
expanded-QName
consisting of the
local part of the name and the possibly null URI reference
is used as the name of the object. The default namespace of
the defining element (
see
Section
6.2 Element Nodes
DM
is
not
used for unprefixed names.
There are
three
cases where the default
namespace
of the
defining element
is
used when expanding an unprefixed QName:
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
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
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. A
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 a
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
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: