optionally specify the output format to be used for
serializing this tree.
The effective value of the
format
attribute, if specified, must be a lexical QName. The QName is
expanded using the namespace declarations in scope for the
xsl:result-document
element. The expanded-QName must match the expanded QName of a named
output definition in the
stylesheet.
This identifies the xsl:output
declaration
that will control the serialization of the final
result tree (see 20
Serialization), if the result tree is serialized.
If the format
attribute is omitted, the
unnamed output definition is used to
control serialization of the result tree.
[ERR XTDE1460] It is a non-recoverable dynamic
error if the effective value of the
format
attribute is not a valid lexical QName,
or if it does not match the expanded-QName of an output
definition in the stylesheet. If the processor is able
to detect the error statically (for example, when the
format
attribute contains no curly brackets),
then the processor may optionally
signal this as a static error.
Note:
The only way to select the unnamed output
definition is to omit the format
attribute.
The attributes method
,
byte-order-mark
cdata-section-elements
,
doctype-public
, doctype-system
,
encoding
, escape-uri-attributes
,
indent
, media-type
,
normalization-form
,
omit-xml-declaration
, standalone
,
undeclare-prefixes
,
use-character-maps
, and
output-version
may be used to override
attributes defined in the selected output
definition.
With the exception of use-character-maps
,
these attributes are all defined as attribute value
templates, so their values may be set dynamically. For
any of these attributes that is present on the xsl:result-document
instruction, the effective value of the attribute
overrides or supplements the corresponding value from the
output definition. This works in the same way as when one
xsl:output
declaration overrides another:
In the case of cdata-section-elements
,
the value of the serialization parameter is the union
of the expanded names of the elements named in this
instruction and the elements named in the selected
output definition;
In the case of use-character-maps
, the
character maps referenced in this instruction
supplement and take precedence over those defined in
the selected output definition;
In all other cases, the effective value of an attribute actually present on this instruction takes precedence over the value defined in the selected output definition.
Note:
In the case of the attributes method
,
cdata-section-elements
, and
use-character-maps
, the effective
value of the attribute contains one or more lexical
QNames. The prefix in such a QName is expanded using the
in-scope namespaces for the
xsl:result-document
element. In the case of
cdata-section-elements
, an unprefixed
element name is expanded using the default namespace.
The output-version
attribute on the
xsl:result-document
instruction overrides the version
attribute on
xsl:output
(it
has been renamed because version
is available
with a different meaning as a standard attribute: see
3.5 Standard
Attributes). In all other cases, attributes
correspond if they have the same name.
There are some serialization parameters that apply to
some output methods but not to others. For example, the
indent
attribute has no effect on the
text
output method. If a value is supplied for
an attribute that is inapplicable to the output method, its
value is not passed to the serializer. The
processor may validate the value
of such an attribute, but is not required to do so.
The href
attribute is optional. The default
value is the zero-length string. The effective
value of the attribute must
be a URI
Reference, which may be absolute or relative. There
may be implementation-defined
restrictions on the form of absolute URI that may be used,
but the implementation is not required to enforce any restrictions. Any
legal relative URI must be
accepted. Note that the zero-length string is a legal
relative URI.
The base URI of the document node at the root of the
final result tree is based on
the effective value of the
href
attribute. If the effective
value is a relative URI, then it is resolved relative
to the base output URI. If the
implementation provides an API to access final result
trees, then it must allow a final
result tree to be identified by means of this base URI.
Note:
The base URI of the final result tree is not necessarily the same thing as the URI of its serialized representation on disk, if any. For example, a server (or browser client) might store final result trees only in memory, or in an internal disk cache. As long as the processor satisfies requests for those URIs, it is irrelevant where they are actually written on disk, if at all.
Note:
It will often be the case that one final result tree contains links to another final result tree produced during the same transformation, in the form of a relative URI. The mechanism of associating a URI with a final result tree has been chosen to allow the integrity of such links to be preserved when the trees are serialized.
As well as being potentially significant in any API that provides access to final result trees, the base URI of the new document node is relevant if the final result tree, rather than being serialized, is supplied as input to a further transformation.
The optional attributes type
and
validation
may be used on the xsl:result-document
instruction to validate the contents of the new document,
and to determine the type annotation that elements and
attributes within the final result tree will carry.
The permitted values and their semantics are described in
19.2.2 Validating
Document Nodes.
A processor may
allow a final result tree to be
serialized. Serialization is described in 20 Serialization. However, an
implementation (for example, a processor running in an environment
with no access to writable filestore) is not required to support the serialization of
final result trees. An
implementation that does not support the serialization of
final result trees may ignore the
format
attribute and the serialization
attributes. Such an implementation must provide the application with some means
of access to the (un-serialized) result tree, using its URI
to identify it.
Implementations may provide additional mechanisms,
outside the scope of this specification, for defining the
way in which final result trees are
processed. Such mechanisms may
make use of the XSLT-defined attributes on the xsl:result-document
and/or xsl:output
elements, or
they may use additional elements
or attributes in an implementation-defined
namespace.
The following example takes an XHTML document as
input, and breaks it up so that the text following each

 element is included in a separate document. A
new document toc.html
is constructed to act
as an index:
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xhtml="http://www.w3.org/1999/xhtml"> <xsl:output name="toc-format" method="xhtml" indent="yes" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/> <xsl:output name="section-format" method="xhtml" indent="no" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"/> <xsl:template match="/"> <xsl:result-document href="toc.html" format="toc-format" validation="strict">  <title>Table of Contents</title>
Table of Contents
 <xsl:for-each select="/*/xhtml:body/(*[1] | xhtml:h1)">
<xsl:value-of select="."/>
 </xsl:for-each>   </xsl:result-document> <xsl:for-each-group select="/*/xhtml:body/*" group-starting-with="xhtml:h1"> <xsl:result-document href="section{position()}.html" format="section-format" validation="strip">  <title><xsl:value-of select="."/></title>  <xsl:copy-of select="current-group()"/>   </xsl:result-document> </xsl:for-each-group> </xsl:template> </xsl:stylesheet>
There are restrictions on the use of the xsl:result-document
instruction, designed to ensure that the results are fully
interoperable even when processors optimize the sequence in
which instructions are evaluated. Informally, the
restriction is that the xsl:result-document
instruction can only be used while writing a final result
tree, not while writing to a temporary tree or a sequence.
This restriction is defined formally as follows.
[Definition: Each instruction in the stylesheet is evaluated in one of two possible output states: final output state or temporary output state].
[Definition: The first of the two output states is called final output state. This state applies when instructions are writing to a final result tree.]
[Definition: The second of the two output states is called temporary output state. This state applies when instructions are writing to a temporary tree or any other non-final destination.]
The instructions in the initial template are
evaluated in final output state. An
instruction is evaluated in the same output state as
its calling instruction, except that xsl:variable
, xsl:param
, xsl:with-param
,
xsl:attribute
,
xsl:comment
,
xsl:processing-instruction
,
xsl:namespace
,
xsl:value-of
,
xsl:function
,
xsl:key
, xsl:sort
, and xsl:message
always
evaluate the instructions in their contained sequence constructor in
temporary output
state.
[ERR XTDE1480] It is a non-recoverable dynamic
error to evaluate the xsl:result-document
instruction in temporary output
state.
[ERR XTDE1490] It is a non-recoverable dynamic error for a transformation to generate two or more final result trees with the same URI.
Note:
Note, this means that it is an error to evaluate more
than one xsl:result-document
instruction that omits the href
attribute,
or to evaluate any xsl:result-document
instruction that omits the href
attribute if
an initial final result tree is created
implicitly.
Technically, the result of evaluating the xsl:result-document
instruction is an empty sequence. This means it does not
contribute any nodes to the result of the
sequence constructor it is part of.
[ERR XTRE1495] It is a recoverable dynamic error for a transformation to generate two or more final result trees with URIs that identify the same physical resource. The optional recovery action is implementation-dependent, since it may be impossible for the processor to detect the error.
[ERR XTRE1500] It is a recoverable dynamic error for a stylesheet to write to an external resource and read from the same resource during a single transformation, whether or not the same URI is used to access the resource in both cases. The optional recovery action is implementation-dependent: implementations are not required to detect the error condition. Note that if the error is not detected, it is undefined whether the document that is read from the resource reflects its state before or after the result tree is written.
It is possible to control the type annotation applied to
individual element and attribute nodes as they are
constructed. This is done using the type
and
validation
attributes of the xsl:element
, xsl:attribute
,
xsl:copy
, xsl:copy-of
,
xsl:document
,
and xsl:result-document
instructions, or the xsl:type
and
xsl:validation
attributes of a literal result
element.
The [xsl:]type
attribute is used to request
validation of an element or attribute against a specific
simple or complex type defined in a schema. The
[xsl:]validation
attribute is used to request
validation against the global element or attribute
declaration whose name matches the name of the element or
attribute being validated.
The [xsl:]type
and
[xsl:]validation
attributes are mutually
exclusive. Both are optional, but if one is present then
the other must be omitted. If
both attributes are omitted, the effect is the same as
specifying the validation
attribute with the
value specified in the default-validation
attribute of the containing xsl:stylesheet
element; if this is not specified, the effect is the same
as specifying validation="strip"
.
[ERR XTSE1505] It is a static error if
both the [xsl:]type
and
[xsl:]validation
attributes are present on the
xsl:element
,
xsl:attribute
,
xsl:copy
, xsl:copy-of
,
xsl:document
,
or xsl:result-document
instructions, or on a literal result
element.
The detailed rules for validation vary depending on the kind of node being validated. The rules for element and attribute nodes are given in 19.2.1 Validating Constructed Elements and Attributes, while those for document nodes are given in 19.2.2 Validating Document Nodes.
[xsl:]validation
AttributeThe [xsl:]validation
attribute defines
the validation action to be taken. It determines not
only the type annotation of the node that
is constructed by the relevant instruction itself, but
also the type annotations of all element and attribute
nodes that have the constructed node as an ancestor.
Conceptually, the validation requested for a child
element or attribute node is applied before the
validation requested for its parent element. For
example, if the instruction that constructs a child
element specifies validation="strict"
,
this will cause the child element to be checked against
an element declaration, but if the instruction that
constructs its parent element specifies
validation="strip"
, then the final effect
will be that the child node is annotated as
xs:untyped
.
In the paragraphs below, the term contained nodes means the elements and attributes that have the newly constructed node as an ancestor.
The value strip
indicates that the
new node and each of the contained nodes will have
the type annotation
xs:untyped
if it is an
element, or
xs:untypedAtomic
if it is
an attribute. Any previous type annotation present
on a contained element or attribute node (for
example, a type annotation that is present on an
element copied from a source document) is also
replaced by xs:untyped
or
xs:untypedAtomic
as
appropriate. The typed value of the node is
changed to be the same as its string value, as an
instance of xs:untypedAtomic
. In the
case of elements the nilled
property
is set to false
. The values of the
is-id
and is-idrefs
properties are unchanged. Schema validation
is not invoked.
The value preserve
indicates that
nodes that are copied will retain their type
annotations, but nodes whose content is newly
constructed will be annotated as
xs:anyType
in the case of elements, or
xs:untypedAtomic
in the
case of attributes. Schema validation is not
invoked. The detailed effect depends on the
instruction:
In the case of xsl:element
and literal result elements, the new element
has a type annotation of
xs:anyType
, and the type
annotations of contained nodes are retained
unchanged.
In the case of xsl:attribute
,
the effect is exactly the same as specifying
validation="strip"
: that is, the
new attribute will have the type annotation
xs:untypedAtomic
.
In the case of xsl:copy-of
,
all the nodes that are copied will retain their
type annotations unchanged.
In the case of xsl:copy
, the
effect depends on the kind of node being
copied.
Where the node being copied is an attribute, the copied attribute will retain its type annotation.
Where the node being copied is an
element, the copied element will have a
type annotation of
xs:anyType
(because this instruction does not copy the
content of the element, it would be wrong
to assume that the type is unchanged); but
any contained nodes will have their type
annotations retained in the same way as
with xsl:element
.
The value strict
indicates that
type annotations are
established by performing strict schema validity
assessment on the element or attribute node created
by this instruction as follows:
In the case of an element, a
top-level element declaration is
identified whose local name and namespace (if
any) match the name of the element, and
schema-validity assessment is carried out
according to the rules defined in [XML Schema Part 1] (section
3.3.4 "Element Declaration Validation Rules",
validation rule "Schema-Validity Assessment
(Element)", clauses 1.1 and 2, using the
top-level element declaration as the
"declaration stipulated by the processor",
which is mentioned in clause <IP_ADDRESS>).
The element is considered valid if the result
of the schema validity assessment is a PSVI in
which the relevant element node has a
validity
property whose value is
valid
. If there is no
matching element declaration, or if the
element is not considered valid, the
transformation fails [see
ERR
XTTE1510], [see
ERR
XTTE1512]. In effect this means that
the element being validated must be declared using a
top-level declaration in the schema, and
must conform to its
declaration. The process of validation applies
recursively to contained elements and
attributes to the extent required by the schema
definition.
Note:
It is not an error if the identified type definition is a simple type, although [XML Schema Part 1] does not define explicitly that this case is permitted.
In the case of an attribute, a
top-level attribute declaration is
identified whose local name and namespace (if
any) match the name of the attribute, and
schema-validity assessment is carried out
according to the rules defined in [XML Schema Part 1] (section
3.2.4 "Attribute Declaration Validation Rules",
validation rule "Schema-Validity Assessment
(Attribute)"). The attribute is considered
valid if the result of the schema validity
assessment is a PSVI in which the relevant
attribute node has a validity
property whose value is valid
. If
the attribute is not considered valid, the
transformation fails [see ERR
XTTE1510]. In effect this
means that the attribute being validated
must be declared
using a top-level declaration in the schema,
and must conform to
its declaration.
The schema components used to validate an
element or attribute may be located in any way
described by [XML Schema Part 1] (see
section 4.3.2, How schema documents are
located on the Web). The components in the
schema constructed from the synthetic schema
document (see 3.14
Importing Schema Components) will
always be available for validating constructed
nodes; if additional schema components are
needed, they may
be located in other ways, for example
implicitly from knowledge of the namespace in
which the elements and attributes appear, or
using the xsi:schemaLocation
attribute of elements within the tree being
validated.
If no validation is performed for a node,
which can happen when the schema specifies
lax
or skip
validation for that node or for a subtree, then
the node is annotated as
xs:anyType
in the
case of an element, and
xs:untypedAtomic
in
the case of an attribute.
The value lax
has the same effect
as the value strict
, except that
whereas strict
validation fails
if there is no matching top-level element
declaration or if the outcome of validity
assessment is a validity
property of
invalid
or notKnown
,
lax
validation fails only if the
outcome of validity assessment is a
validity
property of
invalid
. That is, lax
validation does not cause a type error when the
outcome is notKnown
.
In practice this means that the element or
attribute being validated must conform to its declaration if a
top-level declaration is available. If no such
declaration is available, then the element or
attribute is not validated, but its attributes and
children are validated, again with lax validation.
Any nodes whose validation outcome is a
validity
property of
notKnown
are annotated as
xs:anyType
in the case of
an element, and
xs:untypedAtomic
in the
case of an attribute.
Note:
When the parent element lacks a declaration, the XML Schema specification defines the recursive checking of children and attributes as optional. For this specification, this recursive checking is required.
Note:
If an element that is being validated has an
xsi:type
attribute, then the value
of the xsi:type
attribute will be
taken into account when performing the
validation. However, the presence of an
xsi:type
attribute will not of
itself cause an element to be validated: if
validation against a named type is required, as
distinct from validation against a top-level
element declaration, then it must be requested
using the XSLT [xsl:]type
attribute
on the instruction that invokes the validation,
as described in section <IP_ADDRESS> Validation
using the [xsl:]type Attribute
[ERR
XTTE1510] If the validation
attribute of an xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
, or
xsl:result-document
instruction, or the xsl:validation
attribute of a literal result element, has the
effective value strict
, and schema
validity assessment concludes that the validity of the
element or attribute is invalid or unknown, a type
error occurs. As with other type errors, the error
may be signaled statically if
it can be detected statically.
[ERR
XTTE1512] If the validation
attribute of an xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
, or
xsl:result-document
instruction, or the xsl:validation
attribute of a literal result element, has the
effective value strict
, and there is no
matching top-level declaration in the schema, then a
type error occurs. As with other type errors, the error
may be signaled statically if
it can be detected statically.
[ERR
XTTE1515] If the validation
attribute of an xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
, or
xsl:result-document
instruction, or the xsl:validation
attribute of a literal result element, has the
effective value lax
, and schema validity
assessment concludes that the element or attribute is
invalid, a type error occurs. As with other type
errors, the error may be
signaled statically if it can be detected
statically.
Note:
No mechanism is provided to validate an element or attribute against a local declaration in a schema. Such validation can usually be achieved by applying validation to a containing element for which a top-level element declaration exists.
[xsl:]type
AttributeThe [xsl:]type
attribute takes as its
value a QName
. This must be the name of a type
definition included in the in-scope schema
components for the stylesheet. If the QName
has no prefix, it is expanded using the default
namespace established using the effective
[xsl:]xpath-default-namespace
attribute if
there is one; otherwise, it is taken as being a name in
no namespace.
If the [xsl:]type
attribute is present,
then the newly constructed element or attribute is
validated against the type definition identified by
this attribute.
In the case of an element, schema-validity
assessment is carried out according to the rules
defined in [XML Schema Part
1] (section 3.3.4 "Element Declaration
Validation Rules", validation rule "Schema-Validity
Assessment (Element)", clauses 1.2 and 2), using
this type definition as the "processor-stipulated
type definition". The element is considered valid
if the result of the schema validity assessment is
a PSVI in which the relevant element node has a
validity
property whose value is
valid
.
In the case of an attribute, the attribute is
considered valid if (in the terminology of XML
Schema) the attribute's normalized value is locally
valid with respect to that type definition
according to the rules for "String Valid" ([XML Schema Part 1], section
3.14.4). (Normalization here refers to the process
of normalizing whitespace according to the rules of
the whiteSpace
facet for the data
type).
If the element or attribute is not considered valid, as defined above, the transformation fails [see ERR XTTE1540].
[ERR
XTSE1520] It is a static error if the value
of the type
attribute of an xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
xsl:document
,
or xsl:result-document
instruction, or the xsl:type
attribute of
a literal result element, is not a valid
QName
, or if it uses a prefix that is not
defined in an in-scope namespace declaration, or if the
QName is not the name of a type definition included in
the in-scope schema
components for the stylesheet.
[ERR
XTSE1530] It is a static error if the value
of the type
attribute of an xsl:attribute
instruction refers to a complex type definition.
[ERR
XTTE1540] It is a type error if an
[xsl:]type
attribute is defined for a
constructed element or attribute, and the outcome of
schema validity assessment against that type is that
the validity
property of that element or
attribute information item is other than
valid
.
Note:
Like other type errors, this error may be signaled
statically if it can be detected statically. For
example, the instruction <xsl:attribute
name="dob"
type="xs:date">1999-02-29</xsl:attribute>
may result in a static error being signaled. If the
error is not signaled statically, it will be signaled
when the instruction is evaluated.
As well as checking for validity against the schema, the validity assessment process causes type annotations to be associated with element and attribute nodes. If default values for elements or attributes are defined in the schema, the validation process will where necessary create new nodes containing these default values.
Validation of an element or attribute node only takes into account constraints on the content of the element or attribute. Validation rules affecting the document as a whole are not applied. Specifically, this means:
The validation rule "Validation Root Valid (ID/IDREF)" is not applied. This means that validation will not fail if there are non-unique ID values or dangling IDREF values in the subtree being validated.
The validation rule "Validation Rule: Identity-constraint Satisfied" is not applied.
There is no check that the document contains
unparsed entities whose names match the values of
nodes of type xs:ENTITY
or
xs:ENTITIES
. (XSLT 2.0 provides no
facility to construct unparsed entities within a
tree.)
There is no check that the document contains
notations whose names match the values of nodes of
type xs:NOTATION
. (The
XDM data model makes no provision for
notations to be represented in the tree.)
With these caveats, validating a newly constructed element, using strict or lax validation, is equivalent to the following steps:
The element is serialized to textual XML form, according to the rules defined in [XSLT and XQuery Serialization] using the XML output method, with all parameters defaulted. Note that this process discards any existing type annotations.
The resulting XML document is parsed to create an XML Information Set (see [XML Information Set].)
The Information Set produced in the previous step is validated according to the rules in [XML Schema Part 1]. The result of this step is a Post-Schema Validation Infoset (PSVI). If the validation process is not successful (as defined above), a type error is raised.
The PSVI produced in the previous step is converted back into the XDM data model by the mapping described in [Data Model] (Section 3.3.1 Mapping PSVI Additions to Node PropertiesDM). This process creates nodes with simple or complex type annotations based on the types established during schema validation.
Validating an attribute using strict or lax validation requires a modified version of this procedure. A copy of the attribute is first added to an element node that is created for the purpose, and namespace fixup (see 5.7.3 Namespace Fixup) is performed on this element node. The name of this element is of no consequence, but it must be the same as the name of a synthesized element declaration of the form:
<xs:element name="E"> <xs:complexType> <xs:sequence/> <xs:attribute ref="A"/> </xs:complexType> </xs:element>
where A is the name of the attribute being validated.
This synthetic element is then validated using the procedure given above for validating elements, and if it is found to be valid, a copy of the validated attribute is made, retaining its type annotation, but detaching it from the containing element (and thus, from any namespace nodes).
The XDM data model does not permit an
attribute node with no parent to have a typed value
that includes a namespace-qualified name, that is, a
value whose type is derived from xs:QName
or xs:NOTATION
. This restriction is
imposed because these types rely on the namespace nodes
of a containing element to resolve namespace prefixes.
Therefore, it is an error to validate a parentless
attribute against such a type. This affects the
instructions xsl:attribute
,
xsl:copy
, and
xsl:copy-of
.
[ERR
XTTE1545] A type error occurs if a
type
or validation
attribute
is defined (explicitly or implicitly) for an
instruction that constructs a new attribute node, if
the effect of this is to cause the attribute value to
be validated against a type that is derived from, or
constructed by list or union from, the primitive types
xs:QName
or xs:NOTATION
.
It is possible to apply validation to a document node.
This happens when a new document node is
constructed by one of the instructions xsl:document
,
xsl:result-document
,
xsl:copy
, or
xsl:copy-of
,
and this instruction has a type
attribute,
or a validation
attribute with the value
strict
or lax
.
Document-level validation is not applied to the
document node that is created implicitly when a
variable-binding element has no select
attribute and no as
attribute (see 9.4 Creating implicit document
nodes). This is equivalent to using
validation="preserve"
on xsl:document
: nodes
within such trees retain their type annotation. Similarly,
validation is not applied to document nodes created using
xsl:message
.
The values validation="preserve"
and
validation="strip"
do not request
validation. In the first case, all element and attribute
nodes within the tree rooted at the new document node
retain their type annotations. In the second
case, elements within the tree have their type annotation
set to xs:untyped
, while
attributes have their type annotation set to
xs:untypedAtomic
.
When validation is requested for a document node (that
is, when validation
is set to
strict
or lax
, or when a
type
attribute is present), the following
processing takes place:
[ERR XTTE1550] A type error occurs unless the children of the document node comprise exactly one element node, no text nodes, and zero or more comment and processing instruction nodes, in any order.
The single element node child is validated, using
the supplied values of the validation
and type
attributes, as described in
19.2.1
Validating Constructed Elements and
Attributes.
Note:
The type
attribute on
xsl:document
and xsl:result-document
,
and on xsl:copy
and
xsl:copy-of
when copying a document node, thus refers to the
required type of the element node that is the only
element child of the document node. It does not
refer to the type of the document node itself.
The validation rule "Validation Root Valid (ID/IDREF)" is applied to the single element node child of the document node. This means that validation will fail if there are non-unique ID values or dangling IDREF values in the document tree.
Identity constraints, as defined in section 3.11
of [XML Schema Part 1],
are checked. (This refers to constraints defined
using xs:unique
, xs:key
,
and xs:keyref
.)
There is no check that the tree contains unparsed
entities whose names match the values of nodes of
type xs:ENTITY
or
xs:ENTITIES
. This is because there is no
facility in XSLT 2.0 to create unparsed entities in a
result
tree. It is possible to add unparsed entity
declarations to the result document by referencing a
suitable DOCTYPE during serialization.
There is no check that the document contains
notations whose names match the values of nodes of
type xs:NOTATION
. This is because
notations are not part of the XDM data
model. It is possible to add notations to the result
document by referencing a suitable DOCTYPE during
serialization.
All other children of the document node (comments and processing instructions) are copied unchanged.
[ERR XTTE1555] It is a type error if,
when validating a document node, document-level
constraints are not satisfied. These constraints include
identity constraints (xs:unique
,
xs:key
, and xs:keyref
) and
ID/IDREF constraints.
A processor
may output a final result
tree as a sequence of octets, although it is not
required to be able to do so (see
21 Conformance).
Stylesheet authors can use xsl:output
declarations to
specify how they wish result trees to be serialized. If a
processor serializes a final result tree, it must do so as specified by these
declarations.
The rules governing the output of the serializer are
defined in [XSLT and
XQuery Serialization]. The serialization is controlled
using a number of serialization parameters. The values of
these serialization parameters may be set within the
stylesheet,
using the xsl:output
, xsl:result-document
,
and xsl:character-map
declarations.

<xsl:output
name? = qname
method? = "xml" | "html" | "xhtml" | "text" |
qname-but-not-ncname
byte-order-mark? = "yes" | "no"
cdata-section-elements? = qnames
doctype-public? = string
doctype-system? = string
encoding? = string
escape-uri-attributes? = "yes" | "no"
include-content-type? = "yes" | "no"
indent? = "yes" | "no"
media-type? = string
normalization-form? = "NFC" | "NFD" | "NFKC" |
"NFKD" | "fully-normalized" | "none" |
nmtoken
omit-xml-declaration? = "yes" | "no"
standalone? = "yes" | "no" | "omit"
undeclare-prefixes? = "yes" | "no"
use-character-maps? = qnames
version? =
nmtoken />
The xsl:output
declaration is optional; if used, it must always appear as a top-level element within a
stylesheet module.
A stylesheet may contain multiple xsl:output
declarations
and may include or import stylesheet modules that also
contain xsl:output
declarations. The name of an xsl:output
declaration is
the value of its name
attribute, if any.
[Definition: All the xsl:output
declarations in
a stylesheet that share the same name are grouped into a
named output definition; those that have no name are
grouped into a single unnamed output definition.]
A stylesheet always includes an unnamed output
definition; in the absence of an unnamed xsl:output
declaration,
the unnamed output definition is equivalent to the one that
would be used if the stylesheet contained an xsl:output
declaration
having no attributes.
A named output definition is used when
its name matches the format
attribute used in an
xsl:result-document
element. The unnamed output definition is used when an
xsl:result-document
element omits the format
attribute. It is also
used when serializing the final result tree that is created
implicitly in the absence of an xsl:result-document
element.
All the xsl:output
elements making
up an output definition are effectively
merged. For those attributes whose values are
namespace-sensitive, the merging is done after lexical QNames
have been converted into expanded QNames. For the
cdata-section-elements
attribute, the output
definition uses the union of the values from all the
constituent xsl:output
declarations.
For the use-character-maps
attribute, the
output definition uses the concatenation of the sequences of
expanded
QNames values from all the constituent xsl:output
declarations,
taking them in order of increasing import
precedence, or where several have the same import
precedence, in declaration order. For
other attributes, the output definition uses the value
of that attribute from the xsl:output
declaration
with the highest import precedence.
[ERR XTSE1560] It is a static error if
two xsl:output
declarations within an output definition specify
explicit values for the same attribute (other than
cdata-section-elements
and
use-character-maps
), with the values of the
attributes being not equal, unless there is another xsl:output
declaration
within the same output definition that has higher
import precedence and that specifies an explicit value for
the same attribute.
If none of the xsl:output
declarations
within an output definition specifies a
value for a particular attribute, then the corresponding
serialization parameter takes a default value. The default
value depends on the chosen output method.
There are some serialization parameters that apply to some
output methods but not to others. For example, the
indent
attribute has no effect on the
text
output method. If a value is supplied for
an attribute that is inapplicable to the output method, its
value is not passed to the serializer. The
processor may validate the value of
such an attribute, but is not required to do so.
An implementation may allow the
attributes of the xsl:output
declaration to
be overridden, or the default values to be changed, using the
API that controls the transformation.
The location to which final result trees are serialized
(whether in filestore or elsewhere) is implementation-defined
(which in practice may mean that it
is controlled using an implementation-defined API). However,
these locations must satisfy the
constraint that when two final result trees are both
created (implicitly or explicitly) using relative URIs in the
href
attribute of the xsl:result-document
instruction, then these relative URIs may be used to
construct references from one tree to the other, and such
references must remain valid when
both result trees are serialized.
The method
attribute on the xsl:output
element
identifies the overall method that is to be used for
outputting the final result tree.
[ERR XTSE1570] The value must (if present) be a valid
QName. If the QName does not have a prefix,
then it identifies a method specified in [XSLT and XQuery
Serialization] and must be one
of xml
, html
, xhtml
,
or text
. If the QName has a prefix, then the QName is expanded into an expanded-QName
as described in 5.1 Qualified
Names; the expanded-QName identifies the output
method; the behavior in this case is not specified by this
document.
The default for the method
attribute
depends on the contents of the tree being serialized,
and is chosen as follows. If the document node of the
final result tree has an element
child, and any text nodes preceding the first element child
of the document node of the result tree contain only
whitespace characters, then:
If the expanded-QName of this first
element child has local part html
(in lower
case), and namespace URI
http://www.w3.org/1999/xhtml
, then the
default output method is normally
xhtml
. However, if the
version
attribute of the xsl:stylesheet
element of the principal
stylesheet module has the value 1.0
, and
if the result tree is generated implicitly (rather than
by an explicit xsl:result-document
instruction), then the default output method in this
situation is xml
.
If the expanded-QName of this first
element child has local part html
(in any
combination of upper and lower case) and a null namespace
URI, then the default output method is
html
.
In all other cases, the default output method is
xml
.
The default output method is used if the selected
output definition does not
include a method
attribute.
The other attributes on xsl:output
provide
parameters for the output method. The following attributes
are allowed:
The value of the encoding
attribute
provides the value of the encoding
parameter
to the serialization method. The default value is
implementation-defined,
but in the case of the xml
and
xhtml
methods it must be either UTF-8
or
UTF-16
.
The byte-order-mark
attribute defines
whether a byte order mark is written at the start of the
file. If the value yes
is specified, a byte
order mark is written; if no
is specified,
no byte order mark is written. The default value depends
on the encoding used. If the encoding is
UTF-16
, the default is yes
; for
UTF-8
it is implementation-defined,
and for all other encodings it is no
. The
value of the byte order mark indicates whether high order
bytes are written before or after low order bytes; the
actual byte order used is implementation-dependent
, unless it is defined by the selected
encoding.
The cdata-section-elements
attribute is a
whitespace-separated list of QNames. The default value is
an empty list. After expansion of these names using the
in-scope namespace declarations for the xsl:output
declaration
in which they appear, this list of names provides the
value of the cdata-section-elements
parameter to the serialization method. In the case
of an unprefixed name, the default namespace (that is,
the namespace declared using xmlns="uri"
) is
used.
Note:
This differs from the rule for most other QNames
used in a stylesheet. The reason is that these names
refer to elements in the result document, and therefore
follow the same convention as the name of a literal
result element or the name
attribute of
xsl:element
.
The value of the doctype-system
attribute
provides the value of the doctype-system
parameter to the serialization method. By default, the
parameter is not supplied.
The value of the doctype-public
attribute
provides the value of the doctype-public
parameter to the serialization method. By default, the
parameter is not supplied.
The value of the escape-uri-attributes
attribute provides the value of the
escape-uri-attributes
parameter to the
serialization method. The default value is
yes
.
The value of the include-content-type
attribute provides the value of the
include-content-type
parameter to the
serialization method. The default value is
yes
.
The value of the indent
attribute
provides the value of the indent
parameter
to the serialization method. The default value is
yes
in the case of the html
and
xhtml
output methods, no
in the
case of the xml
output method.
The value of the media-type
attribute
provides the value of the media-type
parameter to the serialization method. The default value
is text/xml
in the case of the
xml
output method, text/html
in
the case of the html
and xhtml
output methods, and text/plain
in the case
of the text
output method.
The value of the normalization-form
attribute provides the value of the
normalization-form
parameter to the
serialization method. A value that is an
NMTOKEN
other than one of those enumerated
for the normalization-form
attribute
specifes an implementation-defined normalization form;
the behavior in this case is not specified by this
document. The default value is none
.
The value of the omit-xml-declaration
attribute provides the value of the
omit-xml-declaration
parameter to the
serialization method. The default value is
no
.
The value of the standalone
attribute
provides the value of the standalone
parameter to the serialization method. The default
value is omit
; this means that no
standalone
attribute is to be included in
the XML declaration.
The undeclare-prefixes
attribute is
relevant only when producing output with
method="xml"
and version="1.1"
(or later). It defines whether namespace
undeclarations (of the form xmlns:foo=""
)
should be output when a child
element has no namespace node with the same name (that
is, namespace prefix) as a namespace node of its parent
element. The default value is no
: this means
that namespace undeclarations are not output, which has
the effect that when the resulting XML is reparsed, the
new tree may contain namespace nodes on the child element
that were not there in the original tree before
serialization.
The use-character-maps
attribute provides
a list of named character maps that are used in
conjunction with this output definition. The way
this attribute is used is described in 20.1 Character Maps.
The default value is an empty list.
The value of the version
attribute
provides the value of the version
parameter
to the serialization method. The set of permitted
values, and the default value, are implementation-defined.
A serialization error will be
reported if the requested version is not supported by the
implementation.
If the processor performs serialization, then it must signal any non-recoverable serialization errors that occur. These have the same effect as non-recoverable dynamic errors: that is, the processor must signal the error and must not finish as if the transformation had been successful.
[Definition: A character map allows a specific character appearing in a text or attribute node in the final result tree to be substituted by a specified string of characters during serialization.] The effect of character maps is defined in [XSLT and XQuery Serialization].
The character map that is supplied as a parameter to the
serializer is determined from the xsl:character-map
elements referenced from the xsl:output
declaration
for the selected output definition.
The xsl:character-map
element is a declaration that may appear as a child of the
xsl:stylesheet
element.

<xsl:character-map
name = qname
use-character-maps? =
qnames>

</xsl:character-map>
The xsl:character-map
declaration declares a character map with a name and a set
of character mappings. The character mappings are specified
by means of xsl:output-character
elements contained either directly within the xsl:character-map
element, or in further character maps referenced in the
use-character-maps
attribute.
The required name
attribute provides a name for the character map. When a
character map is used by an output definition or
another character map, the character map with the highest
import precedence is used.
[ERR XTSE1580] It is a static error if the stylesheet contains two or more character maps with the same name and the same import precedence, unless it also contains another character map with the same name and higher import precedence.
The optional use-character-maps
attribute
lists the names of further character maps that are included
into this character map.
[ERR XTSE1590] It is a static error if
a name in the use-character-maps
attribute
of the xsl:output
or xsl:character-map
elements does not match the name
attribute of any xsl:character-map
in the stylesheet.
[ERR XTSE1600] It is a static error if
a character map references itself, directly or indirectly,
via a name in the use-character-maps
attribute.
It is not an error if the same character map is referenced more than once, directly or indirectly.
An output definition, after
recursive expansion of character maps referenced via its
use-character-maps
attribute, may contain
several mappings for the same character. In this situation,
the last character mapping takes precedence. To establish
the ordering, the following rules are used:
Within a single xsl:character-map
element, the characters defined in character maps
referenced in the use-character-maps
attribute are considered before the characters defined
in the child xsl:output-character
elements.
The character maps referenced in a single
use-character-maps
attribute are
considered in the order in which they are listed in
that attribute. The expansion is depth-first: each
referenced character map is fully expanded before the
next one is considered.
Two xsl:output-character
elements appearing as children of the same xsl:character-map
element are considered in document order.
The xsl:output-character
element is defined as follows:
<xsl:output-character
character = char
string =
string />
The character map that is passed as a parameter to the
serializer contains a mapping for the character specified
in the character
attribute to the string
specified in the string
attribute.
Character mapping is not applied to characters for which output escaping has been disabled as described in 20.2 Disabling Output Escaping.
If a character is mapped, then it is not subjected to XML or HTML escaping.
Character maps can be useful when producing serialized output in a format that resembles, but is not strictly conformant to, HTML or XML. For example, when the output is a JSP page, there might be a need to generate the output:
<jsp:setProperty name="user" property="id" value='<%= "id" + idValue %>'/>
Although this output is not well-formed XML or HTML,
it is valid in Java Server Pages. This can be achieved by
allocating three Unicode characters (which are not needed
for any other purpose) to represent the strings
<%
, %>
, and
"
, for example:
<xsl:character-map name="jsp"> <xsl:output-character character="«" string="<%"/> <xsl:output-character character="»" string="%>"/> <xsl:output-character character="§" string='"'/> </xsl:character-map>
When this character map is referenced in the xsl:output
declaration, the required output can be produced by
writing the following in the stylesheet:
<jsp:setProperty name="user" property="id" value='«= §id§ + idValue »'/>
This works on the assumption that when an apostrophe or quotation mark is generated as part of an attribute value by the use of character maps, the serializer will (where possible) use the other choice of delimiter around the attribute value.
The following example illustrates a composite character map constructed in a modular fashion:
<xsl:output name="htmlDoc" use-character-maps="htmlDoc" /> <xsl:character-map name="htmlDoc" use-character-maps="html-chars doc-entities windows-format" /> <xsl:character-map name="html-chars" use-character-maps="latin1 ..." /> <xsl:character-map name="latin1"> <xsl:output-character character=" " string=" " /> <xsl:output-character character="¡" string="¡" /> ... </xsl:character-map> <xsl:character-map name="doc-entities"> <xsl:output-character character="" string="&t-and-c;" /> <xsl:output-character character="" string="&chap1;" /> <xsl:output-character character="" string="&chap2;" /> ... </xsl:character-map> <xsl:character-map name="windows-format">  <xsl:output-character character="
" string="
" />  <xsl:output-character character="	" string=" " />  <xsl:output-character character="" string="" /> <xsl:output-character character="" string="" /> ... </xsl:character-map>
Normally, when using the XML, HTML, or XHTML output
method, the serializer will escape special characters such
as &
and <
when outputting
text nodes. This ensures that the output is well-formed.
However, it is sometimes convenient to be able to produce
output that is almost, but not quite well-formed XML; for
example, the output may include ill-formed sections which
are intended to be transformed into well-formed XML by a
subsequent non-XML-aware process. For this reason, XSLT
defines a mechanism for disabling output escaping.
This feature is deprecated.
This is an optional feature: it is not required that a XSLT processor that implements the serialization option should offer the ability to disable output escaping, and there is no conformance level that requires this feature.
This feature requires an extension to the serializer
described in [XSLT and
XQuery Serialization]. Conceptually, the final
result tree provides an additional boolean property
disable-escaping
associated with every
character in a text node. When this property is set, the
normal action of the serializer to escape special
characters such as &
and <
is suppressed.
An xsl:value-of
or
xsl:text
element
may have a disable-output-escaping
attribute;
the allowed values are yes
or no
.
The default is no
; if the value is
yes
, then every character in the text node
generated by evaluating the xsl:value-of
or
xsl:text
element
should have the
disable-output
property set.
For example,
<xsl:text disable-output-escaping="yes"><</xsl:text>
should generate the single character
<
.
If output escaping is disabled for an xsl:value-of
or
xsl:text
instruction evaluated when temporary output state is
in effect, the request to disable output escaping is
ignored.
If output escaping is disabled for text within an
element that would normally be output using a CDATA
section, because the element is listed in the
cdata-section-elements
, then the relevant text
will not be included in a CDATA section. In effect, CDATA
is treated as an alternative escaping mechanism, which is
disabled by the disable-output-escaping
option.
For example, if <xsl:output
cdata-section-elements="title"/>
is specified,
then the following instructions:
<title> <xsl:text disable-output-escaping="yes">This is not
 good coding practice</xsl:text> </title>
should generate the output:
<title><![CDATA[This is not ]]>
<![CDATA[ good coding practice]]></title>
The disable-output-escaping
attribute may
be used with the html
output method as well as
with the xml
output method. The
text
output method ignores the
disable-output-escaping
attribute, since it
does not perform any output escaping.
A processor will only be able to disable output escaping if it controls how the final result tree is output. This might not always be the case. For example, the result tree might be used as a source tree for another XSLT transformation instead of being output. It is implementation-defined whether (and under what circumstances) disabling output escaping is supported.
[ERR XTRE1620] It is a recoverable dynamic error if an
xsl:value-of
or xsl:text
instruction specifies that output escaping is to be
disabled and the implementation does not support this. The
optional recovery action
is to ignore the disable-output-escaping
attribute.
[ERR XTRE1630] It is a recoverable dynamic error if an
xsl:value-of
or xsl:text
instruction specifies that output escaping is to be
disabled when writing to a final result tree that is
not being serialized. The optional recovery action
is to ignore the disable-output-escaping
attribute.
If output escaping is disabled for a character that is not representable in the encoding that the processor is using for output, the request to disable output escaping is ignored in respect of that character.
Since disabling output escaping might not work with all implementations and can result in XML that is not well-formed, it should be used only when there is no alternative.
Note:
The facility to define character maps for use during serialization, as described in 20.1 Character Maps, has been produced as an alternative mechanism that can be used in many situations where disabling of output escaping was previously necessary, without the same difficulties.
A processor that claims conformance with this specification must claim conformance either as a basic XSLT processor or as a schema-aware XSLT processor. The rules for these two conformance levels are defined in the following sections.
A processor that claims conformance at either of these two levels may additionally claim conformance with either or both of the following optional features: the serialization feature, defined in 21.3 Serialization Feature, and the backwards compatibility feature, defined in 21.4 Backwards Compatibility Feature.
Note:
There is no conformance level or feature defined in this specification that requires implementation of the static typing features described in [XPath 2.0]. An XSLT processor may provide a user option to invoke static typing, but to be conformant with this specification it must allow a stylesheet to be processed with static typing disabled. The interaction of XSLT stylesheets with the static typing feature of XPath 2.0 has not been specified, so the results of using static typing, if available, are implementation-defined.
An XSLT processor takes as its inputs a stylesheet and one or more XDM trees conforming to the data model defined in [Data Model]. It is not required that the processor supports any particular method of constructing XDM trees, but conformance can only be tested if it provides a mechanism that enables XDM trees representing the stylesheet and primary source document to be constructed and supplied as input to the processor.
The output of the XSLT processor consists of zero or more final result trees. It is not required that the processor supports any particular method of accessing a final result tree, but if it does not support the serialization module, conformance can only be tested if it provides some alternative mechanism that enables access to the results of the transformation.
Certain facilities in this specification are described as producing implementation-defined results. A claim that asserts conformance with this specification must be accompanied by documentation stating the effect of each implementation-defined feature. For convenience, a non-normative checklist of implementation-defined features is provided at F Checklist of Implementation-Defined Features.
A conforming processor must signal any static error occurring in the stylesheet, or in any XPath expression, except where specified otherwise either for individual error conditions or under the general provisions for forwards compatible behavior (see 3.9 Forwards-Compatible Processing). After signaling such an error, the processor may continue for the purpose of signaling additional errors, but must terminate abnormally without performing any transformation.
When a dynamic error occurs during the course of a transformation, the action depends on whether the error is classified as a recoverable error. If a non-recoverable error occurs, the processor must signal it and must eventually terminate abnormally. If a recoverable error occurs, the processor must either signal it and terminate abnormally, or it must take the defined recovery action and continue processing.
Some errors, notably type errors, may be treated as static errors or dynamic errors at the discretion of the processor.
A conforming processor may impose limits on the processing resources consumed by the processing of a stylesheet.
[Definition: A basic XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification with the exception of certain explicitly-identified constructs related to schema processing.] These constructs are listed below.
The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 2.0, as described in [XPath 2.0]. A requirement is mandatory unless the specification includes wording (such as the use of the words should or may) that clearly indicates that it is optional.
A basic XSLT processor must enforce the following restrictions. It must signal a static or dynamic error when the restriction is violated, as described below.
[ERR XTSE1650] A basic XSLT processor
must signal a static error if
the stylesheet includes an xsl:import-schema
declaration.
Note:
A processor that rejects an xsl:import-schema
declaration will also reject any reference to a
user-defined type defined in a schema, or to a
user-defined element or attribute declaration; it will
not, however, reject references to the built-in types
listed in 3.13 Built-in
Types.
[ERR XTSE1660] A basic XSLT processor
must signal a static error if
the stylesheet includes an
[xsl:]type
attribute, or an
[xsl:]validation
or
default-validation
attribute with a value
other than strip
.
A basic XSLT processor constrains the data model as follows:
Atomic values must belong to one of the atomic types listed in 3.13 Built-in Types (except as noted below).
An atomic value may also belong to an implementation-defined type that has been added to the context for use with extension functions or extension instructions.
The set of constructor functions available are limited to those that construct values of the above atomic types.
The static context, which defines the full set of
type names recognized by an XSLT processor and also by
the XPath processor, includes these atomic types, plus
xs:anyType
, xs:anySimpleType
,
xs:untyped
, and
xs:anyAtomicType
.
Element nodes must be
annotated with the type annotation
xs:untyped
, and attribute
nodes with the type annotation
xs:untypedAtomic
.
[ERR XTDE1665] A basic XSLT processor
must raise a non-recoverable dynamic
error if the input to the processor includes a node
with a type annotation other than
xs:untyped
or
xs:untypedAtomic
, or an atomic
value of a type other than those which a basic XSLT
processor supports. This error will not arise if the
input-type-annotations
attribute is set to
strip
.
Note:
Although this is expressed in terms of a requirement to detect invalid input, an alternative approach is for a basic XSLT processor to prevent this error condition occurring, by not providing any interfaces that would allow the situation to arise. A processor might, for example, implement a mapping from the PSVI to the data model that loses all non-trivial type annotations; or it might not accept input from a PSVI at all.
The phrase input to the processor is
deliberately wide: it includes the tree containing the
initial context node,
trees passed as stylesheet parameters,
trees accessed using the document
, doc
FO, and
collection
FO
functions, and trees returned by extension functions and
extension
instructions.
[Definition: A schema-aware XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification, including those features that a basic XSLT processor signals as an error. The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 2.0, as described in [XPath 2.0]. A requirement is mandatory unless the specification includes wording (such as the use of the words should or may) that clearly indicates that it is optional.]
[Definition: A processor that claims
conformance with the serialization feature
must support the conversion of a
final result tree to a sequence
of octets following the rules defined in
20
Serialization.] It
must respect all the attributes
of the xsl:output
and xsl:character-map
declarations, and must provide
all four output methods, xml
,
xhtml
, html
, and
text
. Where the specification uses words such
as must and required, then it must serialize the result tree in precisely
the way described; in other cases it may use an alternative, equivalent
representation.
A processor may claim conformance with the serialization
feature whether or not it supports the setting
disable-output-escaping="yes"
on xsl:text
, or xsl:value-of
.
A processor that does not claim conformance with the
serialization feature must not
signal an error merely because the stylesheet contains xsl:output
or xsl:character-map
declarations, or serialization attributes on the
xsl:result-document
instruction. Such a processor may
check that these declarations and attributes have valid
values, but is not required to do
so. Apart from optional validation, these
declarations should be
ignored.
[Definition: A processor that claims conformance with the backwards compatibility feature must support the processing of stylesheet instructions and XPath expressions with backwards compatible behavior, as defined in 3.8 Backwards-Compatible Processing.]
Note that a processor that does not claim conformance
with the backwards compatibility feature must raise a non-recoverable dynamic
error if an instruction is evaluated containing an
[xsl:]version
attribute that invokes backwards
compatible behavior [see ERR XTDE0160].
Note:
The reason this is a dynamic error rather than a
static error is to allow stylesheets to contain
conditional logic, following different paths depending on
whether the XSLT processor implements XSLT 1.0 or XSLT
2.0. The selection of which path to use can be controlled
by using the system-property
function to test the xsl:version
system
property.
A processor that claims conformance with the backwards compatibility feature must permit the use of the namespace axis in XPath expressions when backwards compatible behavior is enabled. In all other circumstances, support for the namespace axis is optional.
This appendix registers a new MIME media type,
"application/xslt+xml
".
This information is being submitted to the IESG (Internet Engineering Steering Group) for review, approval, and registration with IANA (the Internet Assigned Numbers Authority).
application
xslt+xml
None.
charset
This parameter has identical semantics to the
charset
parameter of the
application/xml
media type as
specified in [RFC3023].
By virtue of XSLT content being XML, it has the same
considerations when sent as
"application/xslt+xml
" as does XML. See
RFC 3023, section 3.2.
Several XSLT instructions may cause arbitrary URIs to be dereferenced. In this case, the security issues of [RFC3986], section 7, should be considered.
In addition, because of the extensibility features
for XSLT, it is possible that
"application/xslt+xml
" may describe
content that has security implications beyond those
described here. However, if the processor follows only
the normative semantics of this specification, this
content will be ignored. Only in the case where the
processor recognizes and processes the additional
content, or where further processing of that content is
dispatched to other processors, would security issues
potentially arise. And in that case, they would fall
outside the domain of this registration document.
This specification describes processing semantics that dictate behavior that must be followed when dealing with, among other things, unrecognized elements.
Because XSLT is extensible, conformant
"application/xslt+xml
" processors can
expect that content received is well-formed XML, but it
cannot be guaranteed that the content is valid XSLT or
that the processor will recognize all of the elements
and attributes in the document.
This media type registration is for XSLT stylesheet modules as described by the XSLT 2.0 specification, which is located at http://www.w3.org/TR/xslt20/. It is also appropriate to use this media type with earlier and later versions of the XSLT language.
Existing XSLT 1.0 stylesheets are most often
described using the unregistered media type
"text/xsl
".
There is no experimental, vendor specific, or
personal tree predecessor to
"application/xslt+xml
", reflecting the
fact that no applications currently recognize it. This
new type is being registered in order to allow for the
expected deployment of XSLT 2.0 on the World Wide Web,
as a first class XML application.
There is no single initial octet sequence that is always present in XSLT documents.
XSLT documents are most often identified with
the extensions ".xsl
" or
".xslt
".
TEXT
Norman Walsh<EMAIL_ADDRESS>.
COMMON
The XSLT specification is a work product of the World Wide Web Consortium's XSL Working Group. The W3C has change control over these specifications.
A QName is always written in the form
(NCName ":")? NCName
, that is, a local name
optionally preceded by a namespace prefix. When two
QNames are compared, however, they are considered equal
if the corresponding expanded-QNames are the same, as
described below.
Within this specification, the term URI
Reference, unless otherwise stated, refers to a
string in the lexical space of the xs:anyURI
data type as defined in [XML
Schema Part 2].
The XML namespace, defined in [Namespaces in XML 1.0] as
http://www.w3.org/XML/1998/namespace
,
is used for attributes such as xml:lang
,
xml:space
, and xml:id
.
The term XPath 1.0 compatibility mode is
defined in Section
2.1.1 Static ContextXP.
This is a setting in the static context of an XPath
expression; it has two values, true
and
false
. When the value is set to true, the
semantics of function calls and certain other operations
are adjusted to give a greater degree of backwards
compatibility between XPath 2.0 and XPath 1.0.
An XSLT element is an element in the XSLT namespace whose syntax and semantics are defined in this specification.
An XSLT instruction is an XSLT element
whose syntax summary in this specification contains the
annotation
.
The XSLT namespace has the URI
http://www.w3.org/1999/XSL/Transform
. It is
used to identify elements, attributes, and other names
that have a special meaning defined in this
specification.
A stylesheet can use the xsl:namespace-alias
element to declare that a literal namespace URI is
being used as an alias for a target namespace URI.
The arity of a stylesheet function is the
number of xsl:param
elements in
the function definition.
The term atomization is defined in Section 2.4.2 AtomizationXP. It is a process that takes as input a sequence of nodes and atomic values, and returns a sequence of atomic values, in which the nodes are replaced by their typed values as defined in [Data Model].
The xsl:attribute-set
element defines a named attribute set: that is, a
collection of attribute definitions that can
be used repeatedly on different constructed elements.
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
({}
)
A processor that claims conformance with the backwards compatibility feature must support the processing of stylesheet instructions and XPath expressions with backwards compatible behavior, as defined in 3.8 Backwards-Compatible Processing.
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
.
The base output URI is a URI to be used as the base URI when resolving a relative URI allocated to a final result tree. If the transformation generates more than one final result tree, then typically each one will be allocated a URI relative to this base URI.
A basic XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification with the exception of certain explicitly-identified constructs related to schema processing.
A character map allows a specific character appearing in a text or attribute node in the final result tree to be substituted by a specified string of characters during serialization.
A circularity is said to exist if a construct such as a global variable, an attribute set, or a key is defined in terms of itself. For example, if the expression or sequence constructor specifying the value of a global variable X references a global variable Y, then the value for Y must be computed before the value of X. A circularity exists if it is impossible to do this for all global variable definitions.
Facilities in XSLT 2.0 and XPath 2.0 that require strings to be ordered rely on the concept of a named collation. A collation is a set of rules that determine whether two strings are equal, and if not, which of them is to be sorted before the other.
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.
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 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 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 term core function means a function that is specified in [Functions and Operators] and that is in the standard function namespace.
While the xsl:matching-substring
instruction is active, a set of current captured
substrings is available, corresponding to the
parenthesized sub-expressions of the regular
expression.
The evaluation context for XPath expressions includes a
component called the current group,
which is a sequence. The current group is the collection
of related items that are processed collectively in one
iteration of the xsl:for-each-group
element.
The evaluation context for XPath expressions includes a component called the current grouping key, which is an atomic value. The current grouping key is the grouping key shared in common by all the items within the current group.
At any point in the processing of a stylesheet, there
is a current mode. When the transformation is
initiated, the current mode is the default mode,
unless a different initial mode has been supplied,
as described in 2.3 Initiating a
Transformation. Whenever an xsl:apply-templates
instruction is evaluated, the current mode becomes the
mode selected by this instruction.
At any point in the processing of a stylesheet, there
may be a current template rule. Whenever a
template rule is chosen as
a result of evaluating xsl:apply-templates
,
xsl:apply-imports
,
or xsl:next-match
,
the template rule becomes the current template rule for
the evaluation of the rule's sequence constructor. When
an xsl:for-each
,
xsl:for-each-group
,
or xsl:analyze-string
instruction is evaluated, or when evaluating a sequence
constructor contained in an xsl:sort
or xsl:key
element, or
when a stylesheet function is
called (see 10.3
Stylesheet Functions), the current template rule
becomes null for the evaluation of that instruction or
function.
The three functions format-date
,
format-time
, and
format-dateTime
are referred to collectively as the date formatting
functions.
All the xsl:decimal-format
declarations in a stylesheet that share the same name are
grouped into a named decimal format; those that
have no name are grouped into a single unnamed decimal
format.
Top-level elements fall into two categories: declarations, and user-defined data elements. Top-level elements whose names are in the XSLT namespace are declarations. Top-level elements in any other namespace are user-defined data elements (see 3.6.2 User-defined Data Elements)
The 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 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.
There is always a default mode available. The
default mode is an unnamed mode, and it is used when no
mode
attribute is specified on an xsl:apply-templates
instruction.
If no priority
attribute is specified on
the xsl:template
element, a default priority is computed, based on
the syntax of the pattern supplied in the
match
attribute.
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.
Some constructs defined in this specification are described as being deprecated. The use of this term implies that stylesheet authors should not use the construct, and that the construct may be removed in a later version of this specification.
An error that is not detected until a source document is being transformed is referred to as a dynamic error.
The result of evaluating an attribute value template is referred to as the effective value of the attribute.
An embedded stylesheet module is a stylesheet module that is embedded within another XML document, typically the source document that is being transformed.
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.
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 element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded-QName (see [XPath 2.0]) of the attribute has a non-null namespace URI. These attributes are referred to as extension attributes.
An extension function is a function that is
available for use within an XPath expression, other than a
core
function defined in [Functions and Operators], an
additional function defined in this XSLT specification,
a constructor function named after an atomic
type, or a stylesheet function defined
using an xsl:function
declaration.
An extension instruction is an element within a sequence constructor that is in a namespace (not the XSLT namespace) designated as an extension namespace.
The extension instruction mechanism allows namespaces to be designated as extension namespaces. When a namespace is designated as an extension namespace and an element with a name from that namespace occurs in a sequence constructor, then the element is treated as an instruction rather than as a literal result element.
The first of the two output states is called final output state. This state applies when instructions are writing to a final result tree.
A final result tree is a result tree that forms part of the final output of a transformation. Once created, the contents of a final result tree are not accessible within the stylesheet itself.
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.
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
.
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
.
An xsl:param
element may appear as a child of an xsl:function
element, before any non-xsl:param
children of
that element. Such a parameter is known as a function
parameter. A function parameter is a local
variable with the additional property that its value
can be set when the function is called, using a function
call in an XPath expression.
A top-level variable-binding element declares a global variable that is visible everywhere (except where it is shadowed by another binding).
The xsl:for-each-group
instruction allocates the items in an input
sequence into groups of items (that is, it
establishes a collection of sequences) based either on
common values of a grouping key, or on a pattern that the initial
or final node in a group must match.
If either of the group-by
attribute or
group-adjacent
attributes is present, then
grouping keys are calculated for each item in the
population. The grouping keys
are the items in the sequence obtained by evaluating the
expression contained in the group-by
attribute or group-adjacent
attribute,
atomizing the result, and then casting an
xs:untypedAtomic
value to
xs:string
.
A specific product that performs the functions of an XSLT processor is referred to as an implementation
In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation must be described in documentation that accompanies any conformance claim.
The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior.
A declaration D in the stylesheet is defined to have lower import precedence than another declaration E if the stylesheet level containing D would be visited before the stylesheet level containing E in a post-order traversal of the import tree (that is, a traversal of the import tree in which a stylesheet level is visited after its children). Two declarations within the same stylesheet level have the same import precedence.
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 schema components that may be referenced by name in a stylesheet are referred to as the in-scope schema components. This set is the same throughout all the modules of a stylesheet.
A node that acts as the initial context node
for the transformation. This node is accessible within
the stylesheet as the initial value of
the XPath expressions .
(dot) and
self::node()
, as described in <IP_ADDRESS> Maintaining Position: the
Focus
For each group, the item within the group that is first in population order is known as the initial item of the group.
The sequence to be sorted is referred to as the initial sequence.
The transformation is performed by evaluating an
initial template. If a named template is supplied
when the transformation is initiated, then this is the
initial template; otherwise, the initial template
is the template rule selected according
to the rules of the xsl:apply-templates
instruction for processing the initial context node in
the initial mode.
An instruction is either an XSLT instruction or an extension instruction.
A key is defined as a set of xsl:key
declarations in
the stylesheet that share the same
name.
The expression in the use
attribute and
the sequence constructor
within an xsl:key
declaration are referred to collectively as the key
specifier. The key specifier determines the values
that may be used to find a node using this key.
A lexical QName is a string representing a
QName in the form
(NCName ":")? NCName
, that is, a local name
optionally preceded by a namespace prefix.
A namespace URI in the stylesheet tree that is being used to specify a namespace URI in the result tree is called a literal namespace URI.
In a sequence constructor, an element in the stylesheet that does not belong to the XSLT namespace and that is not an extension instruction (see 18.2 Extension Instructions) is classified as a literal result element.
As well as being allowed as declaration elements, the
xsl:variable
element is also allowed in sequence constructors.
Such a variable is known as a local variable.
Modes allow a node in a source tree to be processed
multiple times, each time producing a different result.
They also allow different sets of template
rules to be active when processing different trees,
for example when processing documents loaded using the
document
function (see 16.1 Multiple Source
Documents) or when processing temporary
trees.
Templates can be invoked by name. An xsl:template
element
with a name
attribute defines a named
template.
The rules for the individual XSLT instructions that construct a result tree (see 11 Creating Nodes and Sequences) prescribe some of the situations in which namespace nodes are written to the tree. These rules, however, are not sufficient to ensure that the prescribed constraints are always satisfied. The XSLT processor must therefore add additional namespace nodes to satisfy these constraints. This process is referred to as namespace fixup.
A dynamic error that is not recoverable is referred to as a non-recoverable dynamic error. When a non-recoverable dynamic error occurs, the processor must signal the error, and the transformation fails.
If an implementation chooses to recover from a recoverable dynamic error, it must take the optional recovery action defined for that error condition in this specification.
There is an ordering among groups referred to as the order of
first appearance. A group G is defined to
precede a group H in order of first appearance
if the initial item of G
precedes the initial item of H in population
order. If two groups G and H
have the same initial item (because the item is in both
groups) then G precedes H if the
grouping
key of G precedes the grouping key of
H in the sequence that results from evaluating
the group-by
expression of this initial
item.
All the xsl:output
declarations in a stylesheet that share the same name are
grouped into a named output definition; those that
have no name are grouped into a single unnamed output
definition.
Each instruction in the stylesheet is evaluated in one of two possible output states: final output state or temporary output state
The xsl:param
element
declares a parameter, which may be a stylesheet parameter, a
template parameter, or a
function parameter. A
parameter is a variable with the additional property
that its value can be set by the caller when the
stylesheet, the template, or the function is invoked.
A pattern specifies a set of conditions on a node. A node that satisfies the conditions matches the pattern; a node that does not satisfy the conditions does not match the pattern. The syntax for patterns is a subset of the syntax for expressions.
The formatting of a number is controlled by a picture string. The picture string is a sequence of characters, in which the characters assigned to the variables decimal-separator-sign, grouping-sign, zero-digit-sign, digit-sign and pattern-separator-sign are classified as active characters, and all other characters (including the percent-sign and per-mille-sign) are classified as passive characters.
The xsl:number
instruction
performs two tasks: firstly, determining a place
marker (this is a sequence of integers, to allow for
hierarchic numbering schemes such as 1.12.2
or 3(c)ii
), and secondly, formatting the
place marker for output as a text node in the result
sequence.
The sequence of items to be grouped, which is referred
to as the population, is determined by evaluating
the XPath expression contained in the
select
attribute.
The population is treated as a sequence; the order of items in this sequence is referred to as population order
A stylesheet may consist of several
stylesheet modules, contained
in different XML documents. For a given transformation,
one of these functions as the principal stylesheet
module. The complete stylesheet is assembled by finding
the stylesheet modules referenced
directly or indirectly from the principal stylesheet
module using xsl:include
and
xsl:import
elements: see 3.10.2 Stylesheet
Inclusion and 3.10.3
Stylesheet Import.
There is another ordering among groups referred to as
processing order. If group R
precedes group S in processing order, then in
the result sequence returned by the xsl:for-each-group
instruction the items generated by processing group
R will precede the items generated by
processing group S.
The software responsible for transforming source trees into result trees using an XSLT stylesheet is referred to as the processor. This is sometimes expanded to XSLT processor to avoid any confusion with other processors, for example an XML processor.
Some dynamic errors are classed as recoverable errors. When a recoverable error occurs, this specification allows the processor either to signal the error (by reporting the error condition and terminating execution) or to take a defined recovery action and continue processing.
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.
The XSLT namespace, together with certain other namespaces recognized by an XSLT processor, are classified as reserved namespaces and must be used only as specified in this and related specifications.
The term result tree is used to refer to any tree constructed by instructions in the stylesheet. A result tree is either a final result tree or a temporary tree.
Type definitions and element and attribute declarations are referred to collectively as schema components.
The schema instance namespace
http://www.w3.org/2001/XMLSchema-instance
is
used as defined in [XML Schema
Part 1]
The schema namespace
http://www.w3.org/2001/XMLSchema
is used as
defined in [XML Schema Part
1]
A schema-aware XSLT processor is an XSLT processor that implements all the mandatory requirements of this specification, including those features that a basic XSLT processor signals as an error. The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 2.0, as described in [XPath 2.0]. A requirement is mandatory unless the specification includes wording (such as the use of the words should or may) that clearly indicates that it is optional.
A sequence constructor is a sequence of zero or more sibling nodes in the stylesheet that can be evaluated to return a sequence of nodes and atomic values. The way that the resulting sequence is used depends on the containing instruction.
A frequent requirement is to output a final result tree as an XML document (or in other formats such as HTML). This process is referred to as serialization.
If a transformation has successfully produced a final result tree, it is still possible that errors may occur in serializing the result tree. For example, it may be impossible to serialize the result tree using the encoding selected by the user. Such an error is referred to as a serialization error.
A processor that claims conformance with the serialization feature must support the conversion of a final result tree to a sequence of octets following the rules defined in 20 Serialization.
A binding shadows another binding if the binding occurs at a point where the other binding is visible, and the bindings have the same name.
A simplified stylesheet module is a tree, or
part of a tree, consisting of a literal result element
together with its descendant nodes and associated
attributes and namespaces. This element is not itself in
the XSLT namespace, but it must
have an xsl:version
attribute, which implies
that it must have a namespace
node that declares a binding for the XSLT namespace. For
further details see 3.7 Simplified Stylesheet
Modules.
A singleton focus based on a node N has the context item (and therefore the context node) set to N, and the context position and context size both set to 1 (one).
Within a sort key specification,
each xsl:sort
element defines one sort key component.
A sort key specification is a sequence of one
or more adjacent xsl:sort
elements which
together define rules for sorting the items in an input
sequence to form a sorted sequence.
For each item in the initial sequence, a value is computed for each sort key component within the sort key specification. The value computed for an item by using the Nth sort key component is referred to as the Nth sort key value of that item.
The sequence after sorting as defined by the xsl:sort
elements is
referred to as the sorted sequence.
The term source tree means any tree provided as
input to the transformation. This includes the document
containing the initial context node if
any, documents containing nodes supplied as the values of
stylesheet parameters,
documents obtained from the results of functions such as
document
,
doc
FO, and
collection
FO, and
documents returned by extension functions or extension
instructions. In the context of a particular XSLT
instruction, the term source tree means any tree
provided as input to that instruction; this may be a
source tree of the transformation as a whole, or it may
be a temporary tree produced during
the course of the transformation.
A sort key specification
is said to be stable if its first xsl:sort
element has no
stable
attribute, or has a
stable
attribute whose effective
value is yes
.
A standalone stylesheet module is a stylesheet module that comprises the whole of an XML document.
There are a number of standard attributes that
may appear on any XSLT element: specifically
version
,
exclude-result-prefixes
,
extension-element-prefixes
,
xpath-default-namespace
,
default-collation
, and
use-when
.
The standard function namespace
http://www.w3.org/2005/xpath-functions
is
used for functions in the function library defined in
[Functions and Operators]
and standard functions defined in this specification.
A standard stylesheet module is a tree, or part
of a tree, consisting of an xsl:stylesheet
or
xsl:transform
element (see 3.6
Stylesheet Element) together with its descendant
nodes and associated attributes and namespaces.
An error that is detected by examining a stylesheet before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.
The term string value is defined in Section 5.13 string-value AccessorDM. Every node has a string value. For example, the string value of an element is the concatenation of the string values of all its descendant text nodes.
A transformation in the XSLT language is expressed in the form of a stylesheet, whose syntax is well-formed XML [XML 1.0] conforming to the Namespaces in XML Recommendation [Namespaces in XML 1.0].
An xsl:function
declaration declares the name, parameters, and
implementation of a stylesheet function that can
be called from any XPath expression within the stylesheet.
A stylesheet level is a collection of stylesheet modules connected
using xsl:include
declarations: specifically, two stylesheet modules
A and B are part of the same
stylesheet level if one of them includes the other by
means of an xsl:include
declaration, or if there is a third stylesheet module
C that is in the same stylesheet level as both
A and B.
A stylesheet consists of one or more stylesheet modules, each one forming all or part of an XML document.
A top-level xsl:param
element
declares a stylesheet parameter. A stylesheet
parameter is a global variable with the additional
property that its value can be supplied by the caller
when a transformation is initiated.
The value of the variable is computed using the
expression given in the
select
attribute or the contained sequence constructor, as
described in 9.3 Values of
Variables and Parameters. This value is referred
to as the supplied value of the variable.
The namespace URI that is to be used in the result tree as a substitute for a literal namespace URI is called the target namespace URI.
An xsl:template
declaration defines a template, which contains a
sequence
constructor for creating nodes and/or atomic
values. A template can serve either as a template
rule, invoked by matching nodes against a pattern, or as a
named
template, invoked explicitly by name. It is also
possible for the same template to serve in both
capacities.
An xsl:param
element may appear as a child of an xsl:template
element, before any non-xsl:param
children of
that element. Such a parameter is known as a template
parameter. A template parameter is a local
variable with the additional property that its value
can be set when the template is called, using any of the
instructions xsl:call-template
,
xsl:apply-templates
,
xsl:apply-imports
,
or xsl:next-match
.
A stylesheet contains a set of template rules (see 6 Template Rules). A template rule has three parts: a pattern that is matched against nodes, a (possibly empty) set of template parameters, and a sequence constructor that is evaluated to produce a sequence of items.
The second of the two output states is called temporary output state. This state applies when instructions are writing to a temporary tree or any other non-final destination.
The term temporary tree means any tree that is neither a source tree nor a final result tree.
An element occurring as a child of an xsl:stylesheet
element is called a top-level element.
A parameter passed to a template may be defined as a tunnel parameter. Tunnel parameters have the property that they are automatically passed on by the called template to any further templates that it calls, and so on recursively.
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
AccessorDM.
Certain errors are classified as type errors. A type error occurs when the value supplied as input to an operation is of the wrong type for that operation, for example when an integer is supplied to an operation that expects a node.
The term typed value is defined in Section
5.15 typed-value
AccessorDM. Every node
except an element defined in the schema with element-only
content has a typed value. For example, the
typed
value of an attribute of type xs:IDREFS
is a sequence of zero or more xs:IDREF
values.
In addition to declarations, the xsl:stylesheet
element may contain any element not from the XSLT
namespace, provided that the expanded-QName of the element
has a non-null namespace URI. Such elements are referred
to as user-defined data elements.
A variable is a binding between a name and a value. The value of a variable is any sequence (of nodes and/or atomic values), as defined in [Data Model].
The xsl:variable
element
declares a variable, which may be a global
variable or a local variable.
The two elements xsl:variable
and
xsl:param
are
referred to as variable-binding elements
A whitespace text node is a text node whose content consists entirely of whitespace characters (that is, #x09, #x0A, #x0D, or #x20).
The syntax of each XSLT element is summarized below, together with the context in the stylesheet where the element may appear. Some elements (specifically, instructions) are allowed as a child of any element that is allowed to contain a sequence constructor. These elements are:
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: declaration instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements:
|
This appendix provides a summary of error conditions that a processor may signal. This list is not exhaustive or definitive. The errors are numbered for ease of reference, but there is no implication that an implementation must signal errors using these error codes, or that applications can test for these codes. Moreover, implementations are not required to signal errors using the descriptive text used here.
Static errors
A static error is signaled if an XSLT-defined element is used in a context where it is not permitted, if a required attribute is omitted, or if the content of the element does not correspond to the content that is allowed for the element.
It is a static error if an attribute (other than an attribute written using curly brackets in a position where an attribute value template is permitted) contains a value that is not one of the permitted values for that attribute.
It is a static error to use a reserved namespace in the name of a named template, a mode, an attribute set, a key, a decimal-format, a variable or parameter, a stylesheet function, a named output definition, or a character map.
It is a static error for an element from the XSLT namespace to have an attribute whose namespace is either null (that is, an attribute with an unprefixed name) or the XSLT namespace, other than attributes defined for the element in this document.
The value of the version
attribute
must be a number: specifically,
it must be a a valid
instance of the type xs:decimal
as defined
in [XML Schema Part
2].
An xsl:stylesheet
element must not have any text
node children.
It is a static error if the value of an
[xsl:]default-collation
attribute,
after resolving against the base URI, contains no
URI that the implementation recognizes as a collation
URI.
It is a static error if the xsl:stylesheet
element has a child element whose name has a null
namespace URI.
A literal result element
that is used as the outermost element of a simplified
stylesheet module must have an
xsl:version
attribute.
It is a static error if the processor is
not able to retrieve the resource identified by the URI
reference [ in the href
attribute of
xsl:include
or xsl:import
]
, or if the resource that is retrieved does not contain a
stylesheet module conforming to this specification.
An xsl:include
element
must be a top-level element.
It is a static error if a stylesheet module directly or indirectly includes itself.
An xsl:import
element
must be a top-level element.
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.
It is a static error if a stylesheet module directly or indirectly imports itself.
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.
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.
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.
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"
.
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.
Where an attribute is defined to contain a pattern, it is a static error if the pattern does not match the production Pattern.
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 an unescaped right curly bracket occurs in a fixed part of an attribute value template.
An xsl:template
element
must have either a
match
attribute or a name
attribute, or both. An xsl:template
element
that has no match
attribute must have no mode
attribute
and no priority
attribute.
The value of this attribute [the priority
attribute of the xsl:template
element] must conform to
the rules for the xs:decimal
type defined in
[XML Schema Part 2]. Negative
values are permitted..
It is a static error if the list [of modes
in the mode
attribute of xsl:template
] is
empty, if the same token is included more than once in
the list, if the list contains an invalid token, or if
the token #all
appears together with any
other value.
It is a static error if two parameters of a template or of a stylesheet function have the same name.
It is a static error if a variable-binding
element has a select
attribute and has
non-empty content.
It is a static error if a stylesheet contains more than one binding of a global variable with the same name and same import precedence, unless it also contains another binding with the same name and higher import precedence.
It is a static error if a stylesheet
contains an xsl:call-template
instruction whose name
attribute does not
match the name
attribute of any xsl:template
in the
stylesheet.
It is a static error if a stylesheet contains more than one template with the same name and the same import precedence, unless it also contains a template with the same name and higher import precedence.
It is a static error if a single xsl:call-template
,
xsl:apply-templates
,
xsl:apply-imports
,
or xsl:next-match
element contains two or more xsl:with-param
elements with matching name
attributes.
In the case of xsl:call-template
,
it is a static error to pass a
non-tunnel parameter named x to a
template that does not have a template parameter named
x, unless backwards compatible
behavior is enabled for the xsl:call-template
instruction.
It is a static error if a template that is
invoked using xsl:call-template
declares a template parameter
specifying required="yes"
and not
specifying tunnel="yes"
, if no value
for this parameter is supplied by the calling
instruction.
It is a static error if the value of the
use-attribute-sets
attribute of an xsl:copy
, xsl:element
, or
xsl:attribute-set
element, or the xsl:use-attribute-sets
attribute of a literal result element,
is not a whitespace-separated sequence of
QNames, or if it
contains a QName that does not match the
name
attribute of any xsl:attribute-set
declaration in the stylesheet.
It is a static error if an xsl:attribute-set
element directly or indirectly references itself via the
names contained in the use-attribute-sets
attribute.
A stylesheet function must have a prefixed name, to remove any risk of a clash with a function in the default function namespace. It is a static error if the name has no prefix.
Because arguments to a stylesheet function call
must all be specified, the
xsl:param
elements within an xsl:function
element
must not specify a default
value: this means they must be
empty, and must not have a
select
attribute.
It is a static error for a stylesheet to contain two or more functions with the same expanded-QName, the same arity, and the same import precedence, unless there is another function with the same expanded-QName and arity, and a higher import precedence.
It is a static error if an attribute on a literal result element is in the XSLT namespace, unless it is one of the attributes explicitly defined in this specification.
It is a static error if a namespace prefix
is used within the
[xsl:]exclude-result-prefixes
attribute and
there is no namespace binding in scope for that
prefix.
It is a static error if the value
#default
is used within the
[xsl:]exclude-result-prefixes
attribute and
the parent element of the
[xsl:]exclude-result-prefixes
attribute has
no default namespace.
It is a static error if there is more than
one such declaration [more than one xsl:namespace-alias
declaration] with the same literal namespace URI and
the same import precedence and
different values for the target namespace URI,
unless there is also an xsl:namespace-alias
declaration with the same literal namespace URI and
a higher import precedence.
It is a static error if a value other than
#default
is specified for either the
stylesheet-prefix
or the
result-prefix
attributes of the xsl:namespace-alias
element when there is no in-scope binding for that
namespace prefix.
It is a static error if the
select
attribute of the xsl:attribute
element is present unless the element has empty
content.
It is a static error if the
select
attribute of the xsl:value-of
element
is present when the content of the element is non-empty,
or if the select
attribute is absent when
the content is empty.
It is a static error if the
select
attribute of the xsl:processing-instruction
element is present unless the element has empty
content.
It is a static error if the
select
attribute of the xsl:namespace
element is present when the element has content other
than one or more xsl:fallback
instructions, or if the select
attribute is
absent when the element has empty content.
It is a static error if the
select
attribute of the xsl:comment
element
is present unless the element has empty content.
It is a type error to use the xsl:copy
or xsl:copy-of
instruction to copy a node that has namespace-sensitive
content if the copy-namespaces
attribute has
the value no
and its explicit or implicit
validation
attribute has the value
preserve
. It is also a type error if either
of these instructions (with
validation="preserve"
) is used to copy an
attribute having namespace-sensitive content, unless the
parent element is also copied. A node has
namespace-sensitive content if its typed value contains
an item of type xs:QName
or
xs:NOTATION
or a type derived therefrom. The
reason this is an error is because the validity of the
content depends on the namespace context being
preserved.
It is a static error if the
value
attribute of xsl:number
is present
unless the select
, level
,
count
, and from
attributes are
all absent.
It is a static error if an xsl:sort
element with a
select
attribute has non-empty content.
It is a static error if an xsl:sort
element other
than the first in a sequence of sibling xsl:sort
elements has a
stable
attribute.
It is a static error if an xsl:perform-sort
instruction with a select
attribute has any
content other than xsl:sort
and xsl:fallback
instructions.
It is a static error if the current-group
function is used within a pattern.
It is a static error if the current-grouping-key
function is used within a pattern.
These four attributes [the group-by
,
group-adjacent
,
group-starting-with
, and
group-ending-with
attributes of xsl:for-each-group
] are mutually exclusive: it is a static error if none of these
four attributes is present, or if more than one of them
is present.
It is an error to specify the collation
attribute if neither the group-by
attribute
nor group-adjacent
attribute is
specified.
It is a static error if the xsl:analyze-string
instruction contains neither an xsl:matching-substring
nor an xsl:non-matching-substring
element.
It is a static error if an xsl:key
declaration has a
use
attribute and has non-empty content, or
if it has empty content and no use
attribute.
It is a static error if the xsl:key
declaration has a
collation
attribute whose value (after
resolving against the base URI) is not a URI
recognized by the implementation as referring to a
collation.
It is a static error if there are several xsl:key
declarations in
the stylesheet with the same key name
and different effective collations. Two collations are
the same if their URIs are equal under the rules for
comparing xs:anyURI
values, or if the
implementation can determine that they are different URIs
referring to the same collation.
It is a static error if a named or unnamed
decimal format contains two
conflicting values for the same attribute in different
xsl:decimal-format
declarations having the same import precedence,
unless there is another definition of the same attribute
with higher import precedence.
It is a static error if the character
specified in the zero-digit
attribute is not
a digit or is a digit that does not have the numeric
value zero.
It is a static error if, for any named or unnamed decimal format, the variables representing characters used in a picture string do not each have distinct values. These variables are decimal-separator-sign, grouping-sign, percent-sign, per-mille-sign, digit-zero-sign, digit-sign, and pattern-separator-sign.
It is a static error if there is no
namespace bound to the prefix on the element bearing the
[xsl:]extension-element-prefixes
attribute
or, when #default
is specified, if
there is no default namespace.
It is a static error if both the
[xsl:]type
and [xsl:]validation
attributes are present on the xsl:element
, xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
xsl:document
,
or xsl:result-document
instructions, or on a literal result
element.
It is a static error if the value of the
type
attribute of an xsl:element
, xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
xsl:document
,
or xsl:result-document
instruction, or the xsl:type
attribute of a
literal result element, is not a valid
QName
, or if it uses a prefix that is not
defined in an in-scope namespace declaration, or if the
QName is not the name of a type definition included in
the in-scope schema
components for the stylesheet.
It is a static error if the value of the
type
attribute of an xsl:attribute
instruction refers to a complex type definition
It is a static error if two xsl:output
declarations within an output definition specify
explicit values for the same attribute (other than
cdata-section-elements
and
use-character-maps
), with the values of the
attributes being not equal, unless there is another
xsl:output
declaration within the same output definition that
has higher import precedence and that specifies an
explicit value for the same attribute.
The value [of the method
attribute on
xsl:output
]
must (if present)
be a valid QName.
If the QName does
not have a prefix, then it identifies a method specified
in [XSLT and XQuery
Serialization] and must be
one of xml
, html
,
xhtml
, or text
.
It is a static error if the stylesheet contains two or more character maps with the same name and the same import precedence, unless it also contains another character map with the same name and higher import precedence.
It is a static error if a name in the
use-character-maps
attribute of the
xsl:output
or
xsl:character-map
elements does not match the name
attribute of any xsl:character-map
in the stylesheet.
It is a static error if a character map
references itself, directly or indirectly, via a name in
the use-character-maps
attribute.
A basic XSLT processor
must signal a static error
if the stylesheet includes an xsl:import-schema
declaration.
A basic XSLT processor
must signal a static error
if the stylesheet includes an
[xsl:]type
attribute, or an
[xsl:]validation
or
default-validation
attribute with a value
other than strip
.
Type errors
It is a type error if the result of evaluating the sequence constructor cannot be converted to the required type.
It is a type error if an xsl:apply-templates
instruction with no select
attribute is
evaluated when the context item is not a node.
It is a type error if the sequence returned
by the select
expression [of xsl:apply-templates
]
contains an item that is not a node.
It is a type error if the supplied value of a variable cannot be converted to the required type.
It is a type error if the conversion of the supplied value of a parameter to its required type fails.
If a default value is given explicitly, that is, if
there is either a select
attribute or a
non-empty sequence constructor, then
it is a type
error if the default value cannot be converted to the
required type, using the function conversion
rules.
If the as
attribute [of xsl:function
] is
specified, then the result evaluated by the sequence constructor (see
5.7 Sequence
Constructors) is converted to the required type,
using the function conversion
rules. It is a type error if this conversion
fails.
If the value of a parameter to a stylesheet function cannot be converted to the required type, a type error is signaled.
It is a type error if the xsl:number
instruction
is evaluated, with no value
or
select
attribute, when the context item
is not a node.
It is a type error if the result of
evaluating the select
attribute of the
xsl:number
instruction is anything other than a single node.
If any sort key value, after atomization and any
type conversion required by the
data-type
attribute, is a sequence
containing more than one item, then the effect depends on
whether the xsl:sort
element is
evaluated with backwards
compatible behavior. With backwards compatible
behavior, the effective sort key value is the first item
in the sequence. In other cases, this is a type error.
It is a type error if the grouping key
evaluated using the group-adjacent
attribute is an empty sequence, or a sequence containing
more than one item.
When the group-starting-with
or
group-ending-with
attribute [of the xsl:for-each-group
instruction] is used, it is a type error if the result of
evaluating the select
expression contains an
item that is not a node.
If the validation
attribute of an
xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
or xsl:result-document
instruction, or the xsl:validation
attribute
of a literal result element, has the effective value
strict
, and schema validity assessment
concludes that the validity of the element or attribute
is invalid or unknown, a type error occurs. As with other
type errors, the error may be
signaled statically if it can be detected statically.
If the validation
attribute of an
xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
or xsl:result-document
instruction, or the xsl:validation
attribute
of a literal result element, has the effective value
strict
, and there is no matching top-level
declaration in the schema, then a type error occurs. As
with other type errors, the error may be signaled statically if it can be
detected statically.
If the validation
attribute of an
xsl:element
,
xsl:attribute
,
xsl:copy
,
xsl:copy-of
,
or xsl:result-document
instruction, or the xsl:validation
attribute
of a literal result element, has the effective value
lax
, and schema validity assessment
concludes that the element or attribute is invalid, a
type error occurs. As with other type errors, the error
may be signaled statically if
it can be detected statically.
It is a type error if an
[xsl:]type
attribute is defined for a
constructed element or attribute, and the outcome of
schema validity assessment against that type is that the
validity
property of that element or
attribute information item is other than
valid
.
A type
error occurs if a type
or
validation
attribute is defined (explicitly
or implicitly) for an instruction that constructs a new
attribute node, if the effect of this is to cause the
attribute value to be validated against a type that is
derived from, or constructed by list or union from, the
primitive types xs:QName
or
xs:NOTATION
.
A type error occurs [when a document node is validated] unless the children of the document node comprise exactly one element node, no text nodes, and zero or more comment and processing instruction nodes, in any order.
It is a type error if, when validating a
document node, document-level constraints are not
satisfied. These constraints include identity constraints
(xs:unique
, xs:key
, and
xs:keyref
) and ID/IDREF constraints.
Dynamic errors
It is a non-recoverable dynamic error if the effective value of an attribute written using curly brackets, in a position where an attribute value template is permitted, is a value that is not one of the permitted values for that attribute. If the processor is able to detect the error statically (for example, when any XPath expressions within the curly brackets can be evaluated statically), then the processor may optionally signal this as a static error.
It is a non-recoverable dynamic error if the invocation of the stylesheet specifies a template name that does not match the expanded-QName of a named template defined in the stylesheet.
It is a non-recoverable dynamic
error if the invocation of the stylesheet specifies an initial
mode (other than the
default mode) that does not match the expanded-QName in the
mode
attribute of any template defined in
the stylesheet.
It is a non-recoverable dynamic error if the invocation of the stylesheet specifies both an initial mode and an initial template.
It is a non-recoverable dynamic
error if the stylesheet that is invoked declares a
visible stylesheet parameter with
required="yes"
and no value for this
parameter is supplied during the invocation of the
stylesheet. A stylesheet parameter is visible if it is
not masked by another global variable or parameter with
the same name and higher import precedence.
It is a non-recoverable dynamic
error if the initial template defines a
template parameter that
specifies required="yes"
.
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.
It is a recoverable dynamic error if
this [the process of finding an xsl:strip-space
or xsl:preserve-space
declaration to match an element in the source document]
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
).
Action: The
optional recovery
action is to select, from the matches that are left,
the one that occurs last in declaration
order.
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.
It is a non-recoverable dynamic error if the result sequence used to construct the content of an element node contains a namespace node or attribute node that is preceded in the sequence by a node that is neither a namespace node nor an attribute node.
It is a non-recoverable dynamic error if the result sequence used to construct the content of a document node contains a namespace node or attribute node.
It is a non-recoverable dynamic error if the result sequence contains two or more namespace nodes having the same name but different string values (that is, namespace nodes that map the same prefix to different namespace URIs).
It is a non-recoverable dynamic error if the result sequence contains a namespace node with no name and the element node being constructed has a null namespace URI (that is, it is an error to define a default namespace when the element is in no namespace).
It is a non-recoverable dynamic
error if namespace fixup is performed on an element
that contains among the typed values of the element and
its attributes two values of type xs:QName
or xs:NOTATION
containing conflicting
namespace prefixes, that is, two values that use the same
prefix to refer to different namespace URIs.
It is a recoverable dynamic error if
the conflict resolution algorithm for template rules
leaves more than one matching template rule.
Action: The optional recovery
action is to select, from the matching template rules
that are left, the one that occurs last in declaration order.
It is a non-recoverable dynamic
error if xsl:apply-imports
or xsl:next-match
is evaluated when the current template
rule is null.
If an optional parameter has no select
attribute and has an empty sequence constructor, and
if there is an as
attribute, then the
default value of the parameter is an empty sequence. If
the empty sequence is not a valid instance of the
required type defined in the as
attribute,
then the parameter is treated as a required parameter,
which means that it is a non-recoverable dynamic
error if the caller supplies no value for the
parameter.
In general, a circularity in a stylesheet is a non-recoverable dynamic error.
In other cases, [with xsl:apply-templates
,
xsl:apply-imports
,
and xsl:next-match
, or
xsl:call-template
with tunnel parameters] it is a
non-recoverable dynamic
error if the template that is invoked declares a
template parameter with
required="yes"
and no value for this
parameter is supplied by the calling instruction.
It is a recoverable dynamic error if
the name of a constructed attribute is
xml:space
and the value is not either
default
or preserve
.
Action: The optional recovery
action is to construct the attribute with the value
as requested.
It is a non-recoverable dynamic
error if the effective value of the
name
attribute [of the xsl:element
instruction] is not a lexical QName.
In the case of an xsl:element
instruction with no namespace
attribute, it
is a non-recoverable dynamic
error if the effective value of the
name
attribute is a QName whose prefix is not declared in an
in-scope namespace declaration for the xsl:element
instruction.
It is a non-recoverable dynamic
error if the effective value of the
namespace
attribute [of the xsl:element
instruction] is not in the lexical space of the
xs:anyURI
data type.
It is a non-recoverable dynamic
error if the effective value of the
name
attribute [of an xsl:attribute
instruction] is not a lexical QName.
In the case of an xsl:attribute
instruction with no namespace
attribute, it
is a non-recoverable dynamic
error if the effective value of the
name
attribute is the string
xmlns
.
In the case of an xsl:attribute
instruction with no namespace
attribute, it
is a non-recoverable dynamic
error if the effective value of the
name
attribute is a lexical QName whose prefix
is not declared in an in-scope namespace declaration for
the xsl:attribute
instruction.
It is a non-recoverable dynamic
error if the effective value of the
namespace
attribute [of the xsl:attribute
instruction] is not in the lexical space of the
xs:anyURI
data type.
It is a non-recoverable dynamic
error if the effective value of the
name
attribute [of the xsl:processing-instruction
instruction] is not both an NCName
Names and a PITarget
XML.
It is a non-recoverable dynamic
error if the string value of the new namespace node
[created using xsl:namespace
] is
not valid in the lexical space of the data type
xs:anyURI
. [see ERR XTDE0835]