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.16 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
datatype).
If the element or attribute is not considered valid, as defined above, the transformation fails [see ERR XTTE1540].
If an element node is validated against the type
xs:untyped
, the effect is the same as specifying
validation="strip"
: that is, the elements and
attributes in the subtree rooted at the target element are copied
with a type annotation of xs:untyped
or
xs:untypedAtomic
respectively.
If an element or attribute node is validated against the type
xs:untypedAtomic
, the effect is the same as specifying
[xsl:]type="xs:string"
except that when validation
succeeds, the returned element or attribute has a type annotation
of xs:untypedAtomic
. Validation fails in the case of
an element with element children.
[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 XTTE1535] It is a type error if the value
of the type
attribute of an xsl:copy
or xsl:copy-of
instruction refers
to a complex type definition and one or more of the items being
copied is an attribute node.
[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" should be 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
3.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 Properties DM30). 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.8.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:stream
, 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
or xsl:assert
.
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 24.2.1 Validating Constructed
Elements and Attributes.
Note:
The type
attribute on xsl:stream
, 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 3.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 (such as ID/IDREF constraints) are not satisfied.
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 26
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.
<!-- Category: declaration
-->
<xsl:output
name? = eqname
method? = "xml" | "html" | "xhtml" | "text" |
eqname
byte-order-mark? = "yes" | "no"
cdata-section-elements? = eqnames
doctype-public? = string
doctype-system? = string
encoding? = string
escape-uri-attributes? = "yes" | "no"
html-version? = decimal
include-content-type? = "yes" | "no"
indent? = "yes" | "no"
item-separator? = string
media-type? = string
normalization-form? = "NFC" | "NFD" | "NFKC" | "NFKD" |
"fully-normalized" | "none" | nmtoken
omit-xml-declaration? = "yes" | "no"
parameter-document? = uri
standalone? = "yes" | "no" | "omit"
suppress-indentation? = eqnames
undeclare-prefixes? = "yes" | "no"
use-character-maps? = eqnames
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
within a package 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.]
An output definition is scoped to a package. If this is a
library package the output definition applies only to xsl:result-document
instructions within the same package. If it is the top-level
package, the output definition applies to xsl:result-document
instructions within the same package and also to the implicit
final result tree.
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
and
suppress-indentation
attributes, 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.
The parameter-document
attribute allows
serialization parameters to be supplied in an external document.
The external document must contain an
output:serialization-parameters
element with the
format described in
Section 3.1 Setting Serialization Parameters by Means of a Data
Model Instance SER30, and the
parameters are interpreted as described in that specification.
If present, the URI supplied in the
parameter-document
attribute is dereferenced, after
resolution against the base URI of the xsl:output
element if it is a relative reference. If the location of the
stylesheet at development time is different from the deployed
location, any relative reference should be resolved against the
deployed location. A serialization error occurs if the result of
dereferencing the URI is ill-formed or invalid; but if no document
can be found at the specified location, the attribute
may
be ignored.
A serialization parameter specified in the
parameter-document
takes precedence over a value
supplied directly in the output declaration, except that the values
of the cdata-section-elements
and
suppress-indentation
attributes are merged in the same
way as when multiple xsl:output
declarations are
merged.
[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 URI
references in the href
attribute of the
xsl:result-document
instruction, then these relative URI references 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 EQName. If it is a lexical
QName with no a prefix, then it identifies a method specified
in [XSLT and XQuery
Serialization] and must be one of
xml
, html
, xhtml
, or
text
. If it is a lexical QName with a prefix,
then the lexical 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. If the attribute is absent or has a
zero-length string as its value, then the serialization parameter
is not set (is "absent").
The value of the doctype-public
attribute provides
the value of the doctype-public
parameter to the
serialization method. If the attribute is absent or has a
zero-length string as its value, then the serialization parameter
is not set (is "absent").
The value of doctype-public
must conform to the
rules for a PubidLiteralXML
(see [XML 1.0]).
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 html-version
attribute provides
the value of the html-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.
Note:
This serialization parameter is new in version 3.0. If it is
absent, the html output method uses the value of the
version
parameter in its place. For XHTML
serialization, the html-version
parameter indicates
the version of XHTML to be used, while the version
parameter indicates the version of XML.
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 item-separator
attribute provides
the value of the item-separator
parameter to the
serialization method. The value of the serialization parameter can
be any string (including a zero-length string), or absent. To set
the parameter to absent, the item-separator
attribute
can either be omitted, or set to the special value
item-separator="#absent"
; it is not possible to set
the value of the serialization parameter to the literal 7-character
string "#absent".
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 specifies 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 suppress-indentation
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
suppress-indentation
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 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 25.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.
The item-separator
serialization parameter defined
in [XSLT and XQuery
Serialization] is not available in xsl:output
; it is not
applicable, because the sequence that is serialized by XSLT is
always a singleton document node. Formally therefore, the
serializer is always invoked passing an empty string as the value
of this parameter.
If the processor performs serialization, then it must signal any serialization errors that occur. These have the same effect as 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.
<!-- Category: declaration
-->
<xsl:character-map
name = eqname
use-character-maps? =
eqnames >
<!-- Content: (xsl:output-character*) -->
</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.
The name of a character map is local to the package in which its declaration appears; it may be referenced only from within the same package.
[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 25.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"> <!-- newlines as CRLF --> <xsl:output-character character="
" string="
" /> <!-- tabs as three spaces --> <xsl:output-character character="	" string=" " /> <!-- images for special characters --> <xsl:output-character character="" string="<img src='special1.gif' />" /> <xsl:output-character character="" string="<img src='special2.gif' />" /> ... </xsl:character-map>
Note:
When character maps are used, there is no guarantee that the serialized output will be well-formed XML (or HTML). Furthermore, the fact that the result tree was validated against a schema gives no guarantee that the serialized output will still be valid against the same schema. Conversely, it is possible to use character maps to produce schema-valid output from a result tree that would fail validation.
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-escaping
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.
Similarly, 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 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 <hr/> good coding practice</xsl:text> </title>
should generate the output:
<title><![CDATA[This is not ]]><hr/><![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
this method 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. If disabling output escaping is not supported, any request to disable output escaping is ignored.
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:
When disable-output-escaping is used, there is no guarantee that the serialized output will be well-formed XML (or HTML). Furthermore, the fact that the result tree was validated against a schema gives no guarantee that the serialized output will still be valid against the same schema. Conversely, it is possible to use disable-output-escaping to produce schema-valid output from a result tree that would fail validation.
Note:
The facility to define character maps for use during serialization, as described in 25.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 satisfy the conformance requirements for a basic XSLT processor and for each of the optional features with which it claims conformance.
The following optional features are defined:
The schema-awareness feature, defined in 26.2 Schema-Awareness Conformance Feature
The serialization feature, defined in 26.3 Serialization Feature
The backwards compatibility feature, defined in 26.4 Compatibility Features
The streaming feature, defined in 26.5 Streaming Feature.
The dynamic evaluation feature, defined in 26.6 Dynamic Evaluation Feature.
The XQuery invocation feature, defined in 26.7 XQuery Invocation Feature.
A processor that does not claim conformance with an optional feature must satisfy the requirements for processors that do not implement that feature.
Note:
There is no conformance level or feature defined in this specification that requires implementation of the static typing features described in [XPath 3.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 3.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 zero 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 feature, 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.11 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, and is not caught using xsl:catch
, 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 constructs explicitly associated with an optional feature.] These constructs are listed below.
The mandatory requirements of this specification are taken to include the mandatory requirements of XPath 3.0, as described in [XPath 3.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 conformant processor must either be a conformant schema-aware XSLT processor or a conformant non-schema-aware processor.
[Definition: A schema-aware XSLT
processor is an XSLT processor that implements the mandatory
requirements of this specification connected with the xsl:import-schema
declaration, the [xsl:]validation
and [xsl:]type
attributes
, and the ability to handle input documents whose
nodes have type annotations other than xs:untyped
and
xs:untypedAtomic
. The mandatory requirements of this
specification are taken to include the mandatory requirements of
XPath 3.0, as described in [XPath
3.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 non-schema-aware processor is a processor that does not claim conformance with the schema-aware conformance feature. Such a processor must handle constructs associated with schema-aware processing as described in this section.]
[ERR XTSE1650] A non-schema-aware 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.15 Built-in
Types.
A non-schema-aware processor is
not able to validate input documents, and is not able to handle
input documents containing type annotations other than
xs:untyped
or xs:untypedAtomic
.
Therefore, such a processor must treat
any [xsl:]validation
attribute with a value of
preserve
or lax
, or a
[xsl:]default-validation
attribute with a value of
preserve
as if the value were
strip
.
Note:
The values lax
and preserve
indicate
that the validation to be applied depends on the calling
application, so it is appropriate for the request to be treated
differently by different kinds of processor. By contrast,
requesting strict
validation, either through the
[xsl:]validation
attribute or the type
attribute, indicates that the stylesheet is expecting to deal with
typed data, and therefore cannot be processed without performing
the validation.
[ERR XTSE1660] A non-schema-aware processor
must signal a static error if the
stylesheet includes an [xsl:]type
attribute, or an [xsl:]validation
or
[xsl:]default-validation
attribute with a value other
than strip
, preserve
, or
lax
.
A non-schema-aware processor constrains the data model as follows:
Atomic values must belong to one of the atomic types listed in 3.15 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 non-schema-aware processor
must raise a 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 non-schema-aware 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 item, trees
passed as stylesheet parameters, trees
accessed using the document
, doc
FO30,
and collection
FO30
functions, and trees returned by extension
functions and extension instructions.
[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 25 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 XSLT 1.0 compatibility feature must support the processing of stylesheet instructions and XPath expressions with XSLT 1.0 behavior, as defined in 3.10 Backwards Compatible Processing.]
Note that a processor that does not claim conformance with the XSLT 1.0 compatibility feature must raise a dynamic error if an instruction is evaluated whose effective version is 1.0. [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, 2.0, or 3.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 XSLT 1.0 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.
Note:
There are no incompatibilities between 3.0 and 2.0 that would
justify a 2.0-compatibility mode. When a 3.0 processor encounters a
stylesheet that specifies version="2.0"
, evaluation
therefore proceeds exactly as if it specified
version="3.0"
. However, a software product may invoke
an XSLT 2.0 processor in preference to an XSLT 3.0 processor when
the stylesheet specifies version="3.0"
, in which case
any use of new 3.0 constructs will be rejected.
[Definition: A processor that claims conformance with
the streaming feature must use
streamed processing in cases where (a) streaming is requested (for
example by using the attribute streamable="yes"
on
xsl:mode
, or the xsl:stream
instruction) and (b)
the constructs in question are guaranteed-streamable according to
this specification.]
A processor that does not claim conformance with the streaming feature is not required to use streamed processing and is not required to determine whether any construct is guaranteed streamable. Such a processor must, however, implement the semantics of all constructs in the language provided that enough memory is available to perform the processing without streaming.
A processor that conforms with the feature must return the value "yes"
in response
to the function call
system-property('xsl:supports-streaming')
; a processor
that does not conform with the feaure must return the value "no"
.
Note:
The term streamed processing as used here means the ability to process arbitrarily large input documents without ever-increasing memory requirements.
[Definition: A processor that claims
conformance with the dynamic evaluation feature must evaluate the xsl:evaluate
function as
described in this specification.]
A processor that does not claim conformance with the dynamic
evaluation feature must report a dynamic
error if an xsl:evaluate
instruction is
evaluated. It must not report a static
error merely because of the presence of an xsl:evaluate
instruction in
the stylesheet, unless a processor that conforms with the feature
would report the same static error.
A processor that conforms with the feature must return the value "yes"
in response
to the function call
system-property('xsl:supports-dynamic-evaluation')
; a
processor that does not conform with the feaure must return the value "no"
.
A processor that conforms with the feature must return the value true
in response
to the function call
element-available('xsl:evaluate')
; a processor that
does not conform with the feaure must
return the value false
.
Note:
A processor may allow dynamic evaluation to be enabled and
disabled by means of configuration settings, perhaps for security
reasons. In consequence, it may be impossible to tell during static
analysis of the stylesheet whether or not the feature will be
available during execution. A stylesheet author wanting to check
whether the feature is available should therefore make the test
using a run-time call on system-property
, rather than
relying on tests in an [xsl:]use-when
attribute.
[Definition: A processor that claims
conformance with the XQuery invocation feature must allow XQuery library modules to be referenced in
xsl:use-package
,
and must allow the using package to reference the public functions
and variables declared in the referenced library
module.]
This appendix contains the schema for the XML representation of JSON described in 21.2.1 XML Representation of JSON, together with the stylesheets used for converting from this XML representation to strings matching the JSON grammar.
These schema documents and stylesheets are also available as separate resources (links are listed at the top of this document).
The schema is reproduced below:
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://www.w3.org/2013/XSL/json" xmlns:j="http://www.w3.org/2013/XSL/json"> <!-- * This is a schema for the XML representation of JSON used as the target for the * XSLT 3.0 function fn:json-to-xml() * * The schema is made available under the terms of the W3C software notice and license * at http://www.w3.org/Consortium/Legal/copyright-software-19980720 * --> <xs:element name="map" type="j:mapType"> <xs:unique name="unique-key"> <xs:selector xpath="*"/> <xs:field xpath="@key"/> </xs:unique> </xs:element> <xs:element name="array" type="j:arrayType"/> <xs:element name="string" type="j:stringType"/> <xs:element name="number" type="j:numberType"/> <xs:element name="boolean" type="xs:boolean"/> <xs:element name="null" type="j:nullType"/> <xs:complexType name="nullType"> <xs:sequence/> </xs:complexType> <xs:complexType name="stringType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="escaped" type="xs:boolean" use="optional" default="false"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:simpleType name="numberType"> <xs:restriction base="xs:double"> <!-- exclude positive and negative infinity, and NaN --> <xs:minExclusive value="-INF"/> <xs:maxExclusive value="INF"/> </xs:restriction> </xs:simpleType> <xs:complexType name="arrayType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element ref="j:map"/> <xs:element ref="j:array"/> <xs:element ref="j:string"/> <xs:element ref="j:number"/> <xs:element ref="j:boolean"/> <xs:element ref="j:null"/> </xs:choice> </xs:complexType> <xs:complexType name="mapType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="map"> <xs:complexType> <xs:complexContent> <xs:extension base="j:mapType"> <xs:attribute name="key" type="xs:string"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:unique name="unique-key-2"> <xs:selector xpath="*"/> <xs:field xpath="@key"/> </xs:unique> </xs:element> <xs:element name="array"> <xs:complexType> <xs:complexContent> <xs:extension base="j:arrayType"> <xs:attributeGroup ref="j:key-group"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="string"> <xs:complexType> <xs:simpleContent> <xs:extension base="j:stringType"> <xs:attributeGroup ref="j:key-group"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="number"> <xs:complexType> <xs:simpleContent> <xs:extension base="j:numberType"> <xs:attributeGroup ref="j:key-group"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="boolean"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:boolean"> <xs:attributeGroup ref="j:key-group"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> <xs:element name="null"> <xs:complexType> <xs:attributeGroup ref="j:key-group"/> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> <xs:attributeGroup name="key-group"> <xs:attribute name="key" type="xs:string"/> <xs:attribute name="escaped-key" type="xs:boolean" use="optional" default="false"/> </xs:attributeGroup> </xs:schema>
The stylesheet is reproduced below:
<?xml version="1.0" encoding="UTF-8"?> <xsl:package name="http://www.w3.org/2013/XSLT/xml-to-json.xsl" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:j="http://www.w3.org/2013/XSL/json" exclude-result-prefixes="xs j" default-mode="j:xml-to-json" version="3.0" package-version="3.0"> <!-- * This is a stylesheet for converting XML to JSON (with minimal whitespace). * It expects the XML to be in the format produced by the XSLT 3.0 function * fn:json-to-xml(), but is designed to be highly customizable. * * The stylesheet is made available under the terms of the W3C software notice and license * at http://www.w3.org/Consortium/Legal/copyright-software-19980720 * --> <xsl:stylesheet> <!-- The delimiter to be used before and after keys in a map --> <xsl:param name="j:key-delimiter" as="xs:string">"</xsl:param> <!-- The delimiter to be used before and after string values --> <xsl:param name="j:string-delimiter" as="xs:string">"</xsl:param> <!-- The separator to be used between keys and values --> <xsl:param name="j:colon" as="xs:string">:</xsl:param> <!-- The separator to be used between entries in a map --> <xsl:param name="j:entry-separator" as="xs:string">,</xsl:param> <!-- The opening delimiter of an array --> <xsl:param name="j:start-array" as="xs:string">[</xsl:param> <!-- The closing delimiter of an array --> <xsl:param name="j:end-array" as="xs:string">]</xsl:param> <!-- The opening delimiter of a map --> <xsl:param name="j:start-map" as="xs:string">{</xsl:param> <!-- The closing delimiter of a map --> <xsl:param name="j:end-map" as="xs:string">}</xsl:param> <!-- The separator to be used between members of an array --> <xsl:param name="j:array-separator" as="xs:string" select="$j:comma"/> <xsl:template name="j:start-array"> <xsl:value-of select="$j:start-array"/> </xsl:template> <xsl:template name="j:end-array"> <xsl:value-of select="$j:end-array"/> </xsl:template> <xsl:template name="j:start-map"> <xsl:value-of select="$j:start-map"/> </xsl:template> <xsl:template name="j:end-map"> <xsl:value-of select="$j:end-map"/> </xsl:template> <xsl:template name="j:map-separator"> <xsl:value-of select="$j:map-separator"/> </xsl:template> <xsl:template name="j:array-separator"> <xsl:value-of select="$j:array-separator"/> </xsl:template> <!-- Entry point: function to convert a supplied XML node to a JSON string --> <xsl:function name="j:xml-to-json" as="xs:string" visibility="public"> <xsl:param name="xml" as="node()"/> <xsl:apply-templates select="$xml"/> </xsl:function> <!-- Conversion of XML to JSON can be achieved by applying templates to the XML root in this mode --> <xsl:mode name="j:xml-to-json" streamable="yes" visibility="public" on-no-match="shallow-copy"/> <!-- Template rule for j:map elements, representing JSON objects --> <xsl:template match="j:map"> <xsl:call-template name="j:start-map"/> <xsl:for-each select="*"> <xsl:if test="position() gt 1"> <xsl:call-template name="j:map-separator"/> </xsl:if> <xsl:apply-templates select="@key"/> <xsl:call-template name="j:entry-separator"/> <xsl:apply-templates select="."/> </xsl:for-each> <xsl:call-template name="j:end-map"/> </xsl:template> <!-- Template rule for j:array elements, representing JSON arrays --> <xsl:template match="j:array"> <xsl:call-template name="j:start-array"/> <xsl:for-each select="*"> <xsl:if test="position() gt 1"> <xsl:call-template name="j:array-separator"/> </xsl:if> <xsl:apply-templates select="."/> </xsl:for-each> <xsl:call-template name="j:end-array"/> </xsl:template> <!-- Template rule for j:string elements in which special characters are already escaped --> <xsl:template match="j:string[@escaped='true']"> <xsl:value-of select="concat($j:string-delimiter, ., $j:string-delimiter)"/> </xsl:template> <!-- Template rule for j:string elements in which special characters need to be escaped --> <xsl:template match="j:string[not(@escaped='true')]"> <xsl:value-of select="concat($j:string-delimiter, j:escape(.), $j:string-delimiter)"/> </xsl:template> <!-- Template rule for j:number and j:boolean elements (representing JSON numbers and booleans) --> <xsl:template match="j:number | j:boolean"> <xsl:value-of select="."/> </xsl:template> <!-- Template rule for JSON null elements (representing JSON null values) --> <xsl:template match="j:null"> <xsl:text>null</xsl:text> </xsl:template> <!-- Template rule matching a key within a map where special characters in the key are already escaped --> <xsl:template match="j:*/@key[../@key-escaped='true']"> <xsl:value-of select="concat($j:key-delimiter, ., $j:key-delimiter)"/> </xsl:template> <!-- Template rule matching a key within a map where special characters in the key need to be escaped --> <xsl:template match="j:*/@key[not(../@key-escaped='true')]"> <xsl:value-of select="concat($j:key-delimiter, j:escape(.), $j:key-delimiter)"/> </xsl:template> <!-- Template rule matching (and discarding) text nodes in the XML: typically ignorable whitespace --> <xsl:template match="text()"/> <!-- Function to escape special characters --> <xsl:function name="j:escape" as="xs:string"> <xsl:param name="in" as="xs:string"/> <xsl:value-of> <xsl:for-each select="string-to-codepoints($in)"> <xsl:choose> <xsl:when test=". gt 65535"> <xsl:value-of select="concat('\u', j:hex4((. - 65536) idiv 1024 + 55296))"/> <xsl:value-of select="concat('\u', j:hex4((. - 65536) mod 1024 + 56320))"/> </xsl:when> <xsl:when test=". = 34">\"</xsl:when> <xsl:when test=". = 92">\\</xsl:when> <xsl:when test=". = 08">\b</xsl:when> <xsl:when test=". = 09">\t</xsl:when> <xsl:when test=". = 10">\n</xsl:when> <xsl:when test=". = 12">\f</xsl:when> <xsl:when test=". = 13">\r</xsl:when> <xsl:when test=". lt 32 or (. ge 127 and . le 160)"> <xsl:value-of select="concat('\u', j:hex4(.))"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="codepoints-to-string(.)"/> </xsl:otherwise> </xsl:choose> </xsl:for-each> </xsl:value-of> </xsl:function> <!-- Function to convert a UTF16 codepoint into a string of four hex digits --> <xsl:function name="j:hex4" as="xs:string"> <xsl:param name="ch" as="xs:integer"/> <xsl:variable name="hex" select="'0123456789abcdef'"/> <xsl:value-of> <xsl:value-of select="substring($hex, $ch idiv 4096 + 1, 1)"/> <xsl:value-of select="substring($hex, $ch idiv 256 mod 16 + 1, 1)"/> <xsl:value-of select="substring($hex, $ch idiv 16 mod 16 + 1, 1)"/> <xsl:value-of select="substring($hex, $ch mod 16 + 1, 1)"/> </xsl:value-of> </xsl:function> </xsl:stylesheet> </xsl:package>
The stylesheet is reproduced below:
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:j="http://www.w3.org/2013/XSL/json" exclude-result-prefixes="xs j" version="2.0"> <!-- * This is a stylesheet for converting XML to JSON (indented for readability). * It expects the XML to be in the format produced by the XSLT 3.0 function * fn:json-to-xml(), but is designed to be highly customizable. * * The stylesheet is made available under the terms of the W3C software notice and license * at http://www.w3.org/Consortium/Legal/copyright-software-19980720 * --> <xsl:import href="xml-to-json.xsl"/> <xsl:param name="indent-spaces" as="xs:integer" select="3"/> <xsl:param name="j:colon" as="xs:string"> : </xsl:param> <xsl:template name="j:start-array"> <xsl:text> [
</xsl:text> <xsl:variable name="depth" select="count(ancestor::*)"/> <xsl:for-each select="1 to ($depth + 1) * $indent-spaces"><xsl:text> </xsl:text></xsl:for-each> </xsl:template> <xsl:template name="j:end-array"> <xsl:text> ] </xsl:text> </xsl:template> <xsl:template name="j:start-map"> <xsl:text> {
</xsl:text> <xsl:variable name="depth" select="count(ancestor::*)"/> <xsl:for-each select="1 to ($depth + 1) * $indent-spaces"><xsl:text> </xsl:text></xsl:for-each> </xsl:template> <xsl:template name="j:end-map"> <xsl:text> } </xsl:text> </xsl:template> <xsl:template name="j:map-separator"> <xsl:variable name="depth" select="count(ancestor::*)"/> <xsl:text>,
</xsl:text> <xsl:for-each select="1 to $depth * $indent-spaces"><xsl:text> </xsl:text></xsl:for-each> </xsl:template> <xsl:template name="j:array-separator"> <xsl:variable name="depth" select="count(ancestor::*)"/> <xsl:text>,
</xsl:text> <xsl:for-each select="1 to $depth * $indent-spaces"><xsl:text> </xsl:text></xsl:for-each> </xsl:template> </xsl:stylesheet>
A component of the context that has no value is said to be absent.
An operand usage of absorption indicates that the construct reads the subtree(s) rooted at a supplied node(s).
An accumulator defines a value that is computed progressively while processing the nodes of a document in document order. The value for a given node is available via a pair of functions, one giving the value for a node before processing its descendants, and one giving the value for the same node after processing its descendants.
The functions accumulator-before
and
accumulator-after
are
referred to as the accumulator functions.
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 Atomization XP30. It is a process that takes as input a sequence of items, and returns a sequence of atomic values, in which the nodes are replaced by their typed values as defined in [Data Model].
An attribute set is defined as a set of xsl:attribute-set
declarations in the same package that share the same expanded
QName.
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 ({}
), following the
general rules for value templates
An element is processed with backwards compatible
behavior if its effective version is less than
3.0
.
The base output URI is a URI to be used as the base URI when resolving a relative URI reference 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 constructs explicitly associated with an optional feature.
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.
For some construct kinds, one or more operand roles may be
defined to form a choice operand group. This concept is used
where it is known that operands are mutually exclusive (for example the
then
and else
clauses in a conditional
expression).
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.
Climbing: indicates that nodes returned by the construct are reached by navigating the parent, ancestor[-or-self], attribute, and/or namespace axes from the node at the current streaming position.
Facilities in XSLT 3.0 and XPath 3.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 combined posture of a choice operand group is determined by the postures of the operands in the group, and is the first of the following that applies:
The signatures of two components are compatible if they present the same interface to the user of the component. The additional rules depend on the kind of component.
The term component is used to refer to any of the following: a stylesheet function, a named template, a mode, an accumulator an attribute set, a key, global variable, or a mode.
The ordered collection of merge key values computed for one item in a merge input sequence (one for each merge key component within the merge key specification) is referred to as a composite merge key value.
The term construct refers to the union of the following: a sequence constructor, an instruction, an attribute set, a value template, an expression, or a pattern.
A consuming construct is any construct deemed consuming by the rules in this section (19 Streamability).
A component declaration results in multiple components, one in
the package in which the declaration appears, and potentially one
in each package that uses the declaring package, directly or
indirectly, subject to the visibility of the component. Each of
these multiple compenents has the same declaring package,
but each has a different containing package. For the
original component, the declaring package and the containing
package are the same; for a copy of a component made as a result of
a xsl:use-package
declaration, the declaring package will be the original package,
and the containing package will be the package in which the
xsl:use-package
declaration appears.
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), a
node, or a function item. The context item is
initially set to the initial context
item 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.
For every expression, it is possible to establish by static analysis, information about the item type of the context item for evaluation of that expression. This is called the context item type of the expression.
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 or a function item, 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 posture. This captures information about how the context item used as input to the construct is positioned relative to the streamed input. The context posture of a construct C is the posture of the expression whose value sets the focus for the evaluation of C.
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).
Within a focus-changing construct
there are one or more operands that are evaluated with a focus determined by
the controlling operand (or in some
cases such as xsl:on-completion
, with
an absent
focus); these are referred to as
controlled operands.
Within a focus-changing construct there is in many cases one operand whose value determines the focus for evaluating other operands; this is referred to as the controlling operand.
The term core function means a function that is specified in [Functions and Operators] and that is in the standard function namespace.
Crawling: typically indicates that nodes returned by a construct are reached by navigating the descendant[-or-self] axis.
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 value is the group itself, as a sequence of items
The evaluation context for XPath expressions includes a component called the current grouping key, which is a sequence of atomic values. The current grouping key is the grouping key shared in common by all the items within the current group.
The current grouping key value is a single atomic value, or in the case of a composite key, a sequence of atomic values, containing the grouping key of the items in the current group value.
At any point in the processing of a stylesheet, there is a
current mode. When the transformation is initiated, the
current mode is the initial mode, 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
,
xsl:analyze-string
,
xsl:iterate
,
xsl:stream
, xsl:merge
, or xsl:evaluate
instruction is evaluated, or when evaluating a sequence constructor
contained in an xsl:sort
or xsl:key
element, or when
a non-contextual function
call is made, the current template rule becomes
absent for the evaluation of that
instruction or function.
All the xsl:decimal-format
declarations in a package 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.8.3 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.
The declaring package of a component is the package that
contains the declaration (or, in the case of xsl:attribute-set
and
xsl:key
, multiple
declarations) of the component.
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.
If no priority
attribute is specified on an
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 an attribute or text node within a stylesheet module, or as the result of evaluating an XPath expression contained in such a node. The element containing this attribute or text node is referred to as the defining element of the lexical 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.
A processor that claims conformance with the dynamic
evaluation feature must evaluate the
xsl:evaluate
function
as described in this specification.
The result of evaluating a value template is referred to as its effective value.
The effective version of an element in a stylesheet module or package manifest is the decimal
value of the [xsl:]version
attribute (see 3.5 Standard Attributes) on that
element or on the innermost ancestor element that has such an
attribute, excluding the version
attribute on an
xsl:output
element.
An embedded stylesheet module is a stylesheet module that is embedded within another XML document, typically the source document that is being transformed.
An EQName is a string representing a expanded QName where the string, after removing leading and trailing whitespace, is in the form defined by the EQNameXP30 production in the XPath specification.
An expanded QName is a value in the value space of the
xs:QName
datatype as defined in the XDM data model
(see [Data Model]): that is, a
triple containing namespace prefix (optional), namespace URI
(optional), and local name. 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.
The exposed visibility of a component is established by
an xsl:expose
element in
the package manifest.
Within this specification, the term XPath expression, or simply expression, means a string that matches the production ExprXP30 defined in [XPath 3.0].
An element from the XSLT namespace may have any attribute not from the XSLT namespace, provided that the expanded QName (see [XPath 3.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.
A focus-changing construct is a construct that has one or more operands that are evaluated with a different focus from the parent construct.
The focus-setting container of a construct C
is the innermost focus-changing
construct F (if one exists) such that C
is directly or indirectly contained in a controlled operand of F.
If there is no such construct F, then the
focus-setting container is the containing declaration, for example
an xsl:function
or
xsl:template
element.
An element is processed with forwards compatible behavior
if its effective version is greater than
3.0
.
A free-ranging construct is any construct deemed free-ranging by the rules in this section (19 Streamability).
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 3.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.
Many constructs share the same streamability rules. These rules, referred to as the general streamability rules, are defined here.
A top-level variable-binding element declares a global variable that is visible everywhere (except within its own declaration, and where it is shadowed by another binding).
Grounded: indicates that the value returned by the construct does not contain nodes from the streamed input document
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 item in a group must
match.
If either of the group-by
or
group-adjacent
attributes is present, then for each
item in the population a set of grouping keys is
calculated, as follows: the expression contained in the
group-by
or group-adjacent
attribute is
evaluated; the result is atomized; and any
xs:untypedAtomic
values are cast to
xs:string
. If composite="yes"
is
specified, there is a single grouping key whose value is the
resulting sequence; otherwise, there is a set of grouping keys,
consisting of the distinct atomic values present in the result
sequence.
A guaranteed-streamable construct is a construct that is declared to be streamable and that follows the particular rules for that construct to make streaming possible, as defined by the analysis in this specification.
Whether or not the operand is higher-order. For this purpose an operand O of a construct C is higher-order if the semantics of C potentially require O to be evaluated more than once during a single evaluation of C.
Two components are said to be homonymous if they have the same symbolic identifier.
Types S and T are considered identical for the purpose of
these rules if and only if subtype(S, T)
and
subtype(T, S)
both hold, where the subtype relation is
defined in Section <IP_ADDRESS>
The judgement subtype(A, B) XP30.
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.
An item that acts as the initial context item for the
transformation. This item 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
The transformation is performed by evaluating an initial function.
For each group, the item within the group that is first in population order is known as the initial item of the group.
The initial mode, if specified, must
either be the default mode, or a mode that is explicitly named
either in an xsl:mode
declaration, or in
the mode
attribute of an xsl:template
declaration
within the stylesheet. If an initial mode is supplied, then in
searching for the template rule that best matches the
initial context item, the
processor considers only those rules that apply to the initial
mode. If no initial mode is supplied, then the mode used is that
named in the default-mode
attribute of the
xsl:stylesheet
element of the principal
stylesheet module; or failing that, the mode named in the
default-mode
attribute of its containing xsl:package
element; or
in the absence of such an attribute, the unnamed mode.
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 item in the
initial mode.
An operand usage of inspection indicates that the construct accesses properties of a supplied node that are available without reading its subtree.
An instruction is either an XSLT instruction or an extension instruction.
A key is defined as a set of xsl:key
declarations in the
same package 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 expanded
QName where the string, after removing leading and trailing
whitespace, is within the lexical space of the
xs:QName
datatype as defined in XML Schema (see
[XML Schema Part 2]): that is, a local
name optionally preceded by a namespace prefix and a colon.
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 23.2 Extension Instructions) is classified as a literal result element.
As well as being allowed as a declaration, the xsl:variable
element is also
allowed in sequence constructors. Such a
variable is known as a local variable.
A map consists of a set of entries. Each entry comprises a key which is an arbitrary atomic value, and an arbitrary sequence called the associated value.
The match type of a pattern is the most specific
ItemType
that is known to match all items that the
pattern can match.
A merge activation is a single evaluation of the sequence
constructor contained within the xsl:merge-action
element,
which occurs once for each distinct composite merge key value.
A merge input sequence is an arbitrary sequenceDM30 of items which is already sorted according to the merge key specification for the corresponding merge source definition.
A merge key component specifies one component of a
merge key specification; it
corresponds to a single xsl:merge-key
element in the
stylesheet.
A merge key specification consists of one or more
adjacent xsl:merge-key
elements which
together define how the merge input sequences
selected by a merge source definition are
sorted. Each xsl:merge-key
element defines
one merge key component.
For each item in a merge input sequence, a value is computed for each merge key component within the merge key specification. The value computed for an item by using the Nth merge key component is referred to as the Nth merge key value of that item.
A merge source definition is the definition of one kind of input to the merge operation. It selects zero or more merge input sequences, and it includes a merge key specification to define how the merge key values are computed for each such merge input sequence.
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 20.1 fn:document)
or when processing temporary trees.
All the xsl:mode
declarations in a stylesheet that share the same name are grouped
into a named mode definition; those that have no name are
grouped into a single unnamed mode definition.
A motionless construct is any construct deemed motionless by the rules in this section (19 Streamability).
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.
An operand usage of navigation indicates that the construct may navigate freely from the supplied node to other nodes in the same tree, in a way that is not constrained by the streamability rules.
The term non-contextual function call is used to refer to
function calls that do not pass the dynamic context to the called
function. This includes all calls on stylesheet
functions and all dynamic
function invocationsXP30, (that is
calls to function items as permitted by XPath 3.0). It does not
include calls to all core functions in particular those that
explicitly depend on the context, such as the current-group
and regex-group
functions. It is
implementation-defined whether,
and under what circumstances, calls to extension functions are
non-contextual.
A predicate is a non-positional predicate if it satisfies both of the following conditions:
A non-schema-aware processor is a processor that does not claim conformance with the schema-aware conformance feature. Such a processor must handle constructs associated with schema-aware processing as described in this section.
In an actual instance of a construct, there will be a number of operands.
For every construct kind, there is a set of zero or more operand roles.
The operand usage. This gives information, in the case where the operand value contains nodes, about how those nodes are used. The operand usage takes one of the values absorption, inspection, transmission, or navigation.
There is a total 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 within a package 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
A component in a using package may override a component
in a used package, provided that the visibility of the component in
the used package is either abstract
or
public
. The overriding declaration is written as a
child of the xsl:override
element, which in
turn appears as a child of xsl:use-package
.
A package is represented by an xsl:package
element, which will
generally be the outermost element of an XML document.
The content of the xsl:package
element is referred
to as the package manifest
The xsl:param
element
declares a parameter, which may be a stylesheet parameter, a template parameter, a function parameter, or an
xsl:iterate
parameter. A parameter is a variable with the additional
property that its value can be set by the caller.
A pattern specifies a set of conditions on an item. An item that satisfies the conditions matches the pattern; an item that does not satisfy the conditions does not match the pattern.
The picture string is the string supplied as the second
argument of the
format-number
FO30
function.
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 motionless instruction having no consuming instruction as a following sibling is referred to as a post-descent instruction.
The posture of the expression. This captures information about the way in which the streamed input document is positioned on return from evaluating the construct. The posture takes one of the values climbing, striding, crawling, roaming, or grounded.
The potential visibility of a component is established when the component is declared or accepted into a package.
An operand is potentially consuming if either or both of the following conditions applies:
A motionless instruction having no consuming instruction as a preceding sibling is referred to as a pre-descent instruction.
For a given transformation, one stylesheet module
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.12.2 Stylesheet Inclusion and
3.12.3 Stylesheet Import.
The priority of a template rule is specified by the
priority
attribute on the xsl:template
declaration. If
no priority is specified explicitly for a template rule, its
default priority is used, as defined in
6.5 Default Priority for Template
Rules.
There is another total 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.
The result of invoking the selected component, after any required conversion to the declared result type of the component, is referred to as the raw result.
The process of identifying the component to which a symbolic reference applies (possibly chosen from several homonymous alternatives) is called reference binding.
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.
Roaming: indicates that the nodes returned by an expression could be anywhere in the tree, which inevitably means that the construct cannot be evaluated using streaming.
Within a map, no two entries have the same key. Two
atomic values K1
and K2
are the same
key for this purpose if the relation deep-equal(K1, K2,
$UCC)
holds, where $UCC
is the Unicode
codepoint collation.
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 the mandatory requirements of this specification
connected with the xsl:import-schema
declaration, the [xsl:]validation
and [xsl:]type
attributes
, and the ability to handle input documents whose
nodes have type annotations other than xs:untyped
and
xs:untypedAtomic
. The mandatory requirements of this
specification are taken to include the mandatory requirements of
XPath 3.0, as described in [XPath
3.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, atomic values, and function items. 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 25 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.9 Simplified Stylesheet
Modules.
A singleton focus based on an item J has the context item (and therefore the context node, if J is a node) set to J, and the context position and context size both set to 1 (one).
A snapshot of a node N is a deep copy of
N, as produced by the xsl:copy-of
instruction with
copy-namespaces
set to yes
and
validation
set to preserve
, with the
additional property that for every ancestor of N, the
copy also has a corresponding ancestor whose name, node-kind, and
base URI are the same as the corresponding ancestor of
N, and that has copies of the attributes and namespaces
of the corresponding ancestor of N. But the ancestor has
a type annotation of xs:anyType
, has the properties
nilled
, is-id
, and is-idref
set to false, and has no children other than the child that is a
copy of N or one of its ancestors.
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 item if any,
documents containing nodes supplied as the values of stylesheet parameters, documents
obtained from the results of functions such as document
, doc
FO30,
and collection
FO30,
documents read using the xsl:stream
instruction,
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
default-collation
, default-mode
,
default-validation
,
exclude-result-prefixes
,
expand-text
,
extension-element-prefixes
, use-when
,
version
, and xpath-default-namespace
.
The standard error namespace
http://www.w3.org/2005/xqt-errors
is used for error
codes defined in this specification and related specifications. It
is also used for the names of certain predefined variables
accessible within the scope of an xsl:catch
element.
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 for
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.8 Stylesheet Element)
together with its descendant nodes and associated attributes and
namespaces.
An error that can be detected by examining a stylesheet before execution starts (that is, before the source document and values of stylesheet parameters are available) is referred to as a static error.
A static expression is an XPath expression whose value must be computed during static analysis of the stylesheet.
A static variable declared using an
xsl:param
element is
referred to as a static parameter.
A top-level variable-binding element having
the attribute static="yes"
declares a static
variable: that is, a global variable whose value is known
during static analysis of the stylesheet.
A streamable mode is a mode that is declared in an xsl:mode
declaration with the
attribute streamable="yes"
.
A streamed document is a source tree that is processed using streaming, that is, without constructing a complete tree of nodes in memory.
A streamed node is a node in a streamed document.
The term streaming refers to a manner of processing in which documents (such as source and result documents) are not represented by a complete tree of nodes occupying memory proportional to document size, but instead are processed "on the fly" as a sequence of events, similar in concept to the stream of events notified by an XML parser to represent markup in lexical XML.
A processor that claims conformance with the streaming
feature must use streamed processing
in cases where (a) streaming is requested (for example by using the
attribute streamable="yes"
on xsl:mode
, or the xsl:stream
instruction) and (b)
the constructs in question are guaranteed-streamable according to
this specification.
Striding: indicates that the result of a construct is a sequence of nodes, in document order, that are peers in the sense that none of them is an ancestor or descendant of any other.
The term string value is defined in Section 5.13 string-value Accessor DM30. 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].
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 package 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.
Every construct has a sweep, which is a measure of the extent to which the current position in the input stream moves during the evaluation of the expression. The sweep is one of: motionless, consuming, or free-ranging .
The symbolic identifier of a component is a composite name used to identify the component uniquely within a package. The symbolic identifier comprises the kind of component (stylesheet function, named template, accumulator, attribute set, global variable, or mode), the expanded QName of the component (namespace URI plus local name), and in the case of stylesheet functions, the arity.
The declaration of a component includes
constructs that can be interpreted as references to other components by
means of their symbolic identifiers. These
constructs are generically referred to as symbolic
references. Examples of constructs that give rise to symbolic
references are the name
attribute of xsl:call-template
; the
[xsl:]use-attribute-sets
attribute of xsl:copy
, xsl:element
, and literal result elements; the
mode
attribute of xsl:template
and xsl:apply-templates
;
XPath variable references referring to global variables; and XPath
function calls referring to stylesheet functions
or accumulator functions.
An instruction J is in a tail position within a sequence constructor SC if it satisfies one of the following conditions:
The string that results from evaluating the expression in the
xpath
attribute is referred to as the target
expression.
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 ; this
sequence constructor is evaluated to determine the result of the
template. A template can serve either as a template
rule, invoked by matching items 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.
In a text node that is designated as a text value
template, expressions can be used by surrounding each
expression with curly brackets ({}
).
An element occurring as a child of an xsl:stylesheet
,
xsl:transform
, or
xsl:override
element is called a top-level element.
An operand usage of transmission indicates that the construct will (potentially) return a supplied node as part of its result to the calling construct (that is, to its parent in the construct tree).
A traversal of a tree is a sequence of traversal events.
a traversal event (shortened to event in this section) is a pair comprising a phase (start or end) and a node.
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 Accessor DM30.
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 type-determined usage of an operand is as follows: if
the required type (ignoring occurrence indicator) is
function(*)
or a subtype thereof, then inspection;
if the required type (ignoring occurrence indicator) is
xs:anyAtomicType
or a subtype thereof, then absorption;
otherwise navigation.
The term typed value is defined in Section
5.15 typed-value Accessor DM30. Every
node, other than an element whose type annotation identifies
it as having 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.
There is always an unnamed mode available. The unnamed
mode is the default mode used when no mode
attribute
is specified on an xsl:apply-templates
instruction or xsl:template
declaration,
unless a different default mode has been specified using the
[xsl:]default-mode
attribute of a containing
element.
Within this specification, the term URI Reference, unless
otherwise stated, refers to a string in the lexical space of the
xs:anyURI
datatype as defined in [XML Schema Part 2].
If a package Q contains an xsl:use-package
element
that references package P, then package Q is
said to use package P. In this relationship
package Q is referred to as the using package,
package P as the used package.
In addition to declarations, the xsl:stylesheet
element may
contain among its children 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, atomic values, and/or function items), as defined in [Data Model].
Collectively, attribute value templates and text value templates are referred to as value templates.
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
The visibility of a component is one of: private
,
public
, abstract
, final
, or
hidden
.
A whitespace text node is a text node whose content consists entirely of whitespace characters (that is, #x09, #x0A, #x0D, or #x20).
The XML namespace, defined in [Namespaces in XML] 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 Context XP30. 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 3.0 and XPath 1.0.
A processor that claims conformance with the XQuery
invocation feature must allow XQuery
library modules to be referenced in xsl:use-package
, and must
allow the using package to reference the public functions and
variables declared in the referenced library module.
An element in the stylesheet is processed with XSLT 1.0 behavior if its effective version is equal to 1.0.
A processor that claims conformance with the XSLT 1.0 compatibility feature must support the processing of stylesheet instructions and XPath expressions with XSLT 1.0 behavior, as defined in 3.10 Backwards Compatible Processing.
An element is processed with XSLT 2.0 behavior if its effective version is equal to 2.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 <!--
category: instruction -->
.
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.
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:
|
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: 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:
|
|
Model:
Permitted parent elements: |
|
Category: declaration Model:
Permitted parent elements: |
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction 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:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
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: instruction Model:
Permitted parent elements:
|
|
Category: declaration Model:
Permitted parent elements: |
|
Category: instruction Model:
Permitted parent elements:
|
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements: |
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements: |
|
Model:
Permitted parent elements: |
|
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:
|
|
Model:
Permitted parent elements: |
|
Category: instruction Model:
Permitted parent elements:
|
|
Model:
Permitted parent elements: |
|
Model:
Permitted parent elements: |
|
Category: declaration Model:
Permitted parent elements: |
|
Model:
Permitted parent elements: |
|
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: instruction 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:
|
|
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 includes all error codes defined in this specification, but this is not an exhaustive list of all errors that can occur. Implementations must signal errors using these error codes, and applications can test for these codes; however, when more than one rule in the specification is violated, different processors will not necessarily signal the same error code. Implementations are not required to signal errors using the descriptive text used here.
Note:
The appendix is non-normative because the same information is given normatively elsewhere.
Static errors
It is a static error 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 if present
must be a number: specifically, it
must be 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.
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.
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"