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 27.2 Schema-Awareness Conformance Feature
The serialization feature, defined in 27.3 Serialization Feature
The backwards compatibility feature, defined in 27.4 Compatibility Features
The streaming feature, defined in 27.5 Streaming Feature.
The dynamic evaluation feature, defined in 27.6 Dynamic Evaluation Feature.
The higher-order functions feature, defined in 27.8 Higher-Order Functions Feature.
The XPath 3.1 feature, defined in 27.7 XPath 3.1 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 [XDM 3.0]. 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.10 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.
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.
The mandatory requirements of this specification are taken to include the mandatory requirements of [XPath 3.0], [XDM 3.0], and [Functions and Operators 3.0]. An XSLT 3.0 processor must provide a mode of operation which conforms to the 3.0 versions of those specifications as extended by 21 Maps and 22 Processing JSON Data.
A processor may also provide a mode of operation which conforms to the 3.1 versions of those specifications; in this case it must do so as described in XPath 3.1 Feature.
A processor may also provide a mode of operation which conforms to versions of those specifications later than the 3.1 versions; in such cases the detail of how XSLT 3.0 interacts with new features introduced by such later versions (for example, extensions to the data model) is implementation-defined.
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.
Some of the optional features are defined in such a way that if the feature is not provided, the data model is constrained to exclude certain kinds of item. For example:
A processor that does not provide the schema-awareness feature restricts the data model so that it does not contain atomic values of types other than the built-in types, or nodes with non-trivial type annotations.
A processor that does not provide the higher-order functions feature constrains the data model so that it does not contain function items other than maps or arrays.
A processor that does not provide the XPath 3.1 Feature constrains the data model so that it does not contain arrays.
[ERR XTDE1665] A dynamic error may be raised if the input to the processor includes an item that requires availability of an optional feature that the processor does not provide.
Note:
It is not necessarily possible to trigger this error. A processor that does not provide an optional feature might not define or recognize any representation of the items that are disallowed. The error code is provided for use in cases where a processor is able to interoperate with other software that does not have the same constraints — for example, where a package compiled with a non-schema-aware processor is able to invoke functions in a package that was compiled with a schema-aware processor. Even in that case, processors have the option of filtering or converting the input so that it meets the relevant constraints: for example, a non-schema-aware processor when presented with a schema-validated document in the form of a PSVI might simply ignore the properties it does not understand.
The dynamic error is optional: for example a processor might report no error if the offending item is not actually used.
The phrase input to the processor is deliberately wide: it includes (inter alia)
the global context item, items present in the initial match selection, items passed as stylesheet parameters, items returned by functions such as
document
, doc
FO30, and
collection
FO30, items returned by extension functions and extension instructions,
items supplied in function or template parameters or results across package boundaries,
and nodes
reachable from any of the above by axis navigation.
[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.
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 a package 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.14 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 a package includes an
[xsl:]type
attribute; or an [xsl:]validation
or
[xsl:]default-validation
attribute with a value other than
strip
, preserve
, or
lax
; or an
xsl:mode
element whose typed
attribute is
equal to yes
or strict
; or an as
attribute whose value is a
SequenceType that can only match
nodes with a type annotation other than xs:untyped
or
xs:untypedAtomic
(for example, as="element(*,
xs:integer)"
).
A non-schema-aware processor constrains the data model as follows, and raises a dynamic error ([see ERR XTDE1665]) if the constraints are not satisfied:
Atomic values must belong to one of the atomic types listed in 3.14 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
.
[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 26 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.
Note:
A processor that does not claim conformance with the serialization feature
may offer alternative serialization capabilities, and these
may make use of the serialization parameters defined on
xsl:output
and/or xsl:result-document
.
If the processor claims conformance with
the serialization feature then it must fully implement the
serialize
FO30 function defined in [Functions and Operators 3.0]
or [Functions and Operators 3.1] as appropriate, and must not
raise error [ERR FODC0010] FO30 as the result of such a call.
If the processor does not claim conformance with
the serialization feature, then it may raise
error [ERR FODC0010] FO30 in respect of some or
all calls on the serialize
FO30 function; it must not
return a result from a call on this function unless the result is conformant with
the specification, given the parameters actually supplied.
A processor that claims conformance with the Serialization Feature must satisfy the mandatory requirements of [XSLT and XQuery Serialization]. It must provide a mode of operation which conforms to the 3.0 version of that specification. It may also provide a mode of operation which conforms to a later version of that specification; in such cases the detail of how XSLT 3.0 interacts with new features introduced by such a version (for example, support for new serialization properties) is implementation-defined.
[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.9 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="2.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 on
the xsl:source-document
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 feature 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 feature 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 feature 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 XPath 3.1 feature must implement XPath 3.1 (including [XPath 3.1], [XDM 3.1], [XSLT and XQuery Serialization 3.1], and [Functions and Operators 3.1]).]
Specifically:
All constructs where an expression, pattern, SequenceType, or ItemType
is
expected must accept the XPath 3.1 grammar within those constructs.
All functions defined in [Functions and Operators 3.1] are available.
Note:
Functions labeled as higher-order are available only if the higher-order functions feature is also available.
If both the XPath 3.1 feature and the Higher-Order Functions feature
are available, then the load-xquery-module
FO31
function will be available. However, as prescribed in the specification
of that function, it has the option of returning a dynamic error if no suitable
XQuery processor is available.
The union type xs:numeric
is recognized.
The data model includes maps and arrays.
A processor that does not provide the XPath 3.1 feature constrains the data model by disallowing arrays, and may raise a dynamic error ([see ERR XTDE1665]) if this constraint is not satisfied.
Serialization of final results follows the rules in [XSLT and XQuery Serialization 3.1] (for example, it supports JSON serialization).
The xsl:evaluate
instruction supports dynamic evaluation of
XPath 3.1 expressions.
The result of system-property("xsl:xpath-version")
is
"3.1"
.
A processor that claims conformance with the XPath 3.1 feature may accept or reject constructs defined in any version of XPath (and its associated specifications) later than 3.1.
XPath 3.1 introduces arrays as a new data structure, along with maps, largely in order
to
provide improved support for JSON. An array is an item, and it can be used as a function,
so if
$A
is an array, then $A(3)
selects the third member of the array, counting
from one. The members of an array can be arbitrary values (that is, sequences).
Arrays become available in XSLT 3.0 when the XPath 3.1 Feature is implemented.
There are no specific constructs in XSLT 3.0 to construct or manipulate arrays, but
this
can be achieved using facilities in XPath 3.1. The syntax for SequenceTypes
is extended to allow arrays to be declared: for example array(xs:integer)
represents an array
whose members are (single) integers, while array(map(xs:string, node()*))
represents an array
whose members are maps from strings to sequences of nodes.
Like maps and sequences, arrays are immutable, and have no discernible identity (two arrays with the same members cannot be distinguished).
A number of functions for manipulating arrays are defined in [Functions and Operators 3.1].
[Definition: The higher-order functions feature contains functionality connected with the use of functions as items in the data model, that can be stored in variables and passed to other functions.]
[ERR XTSE3540] A processor that does not provide the
higher-order functions feature raises a static error if any of the following
XPath constructs are found in an expression, pattern,
SequenceType, or ItemType
: a
TypedFunctionTestXP30, a
NamedFunctionRefXP30, an
InlineFunctionExprXP30, or an
ArgumentPlaceholderXP30.
Note:
The effect is to disallow the three constructs used to create function-valued items:
named function references
such as round#1
, inline function expressions such as function($x){$x+1}
, and
partial function application such as starts-with(?, '#')
, along with sequence types
such as function(xs:integer) as xs:string
that serve no useful purpose in the absence of such items.
The item type function(*)
is allowed by these rules, and serves as a generic type for maps and arrays.
Where a processor does not provide the higher-order functions feature, functions whose specification in [Functions and Operators 3.1] labels them with the higher-order property are excluded from the static context of expressions and patterns. An attempt to reference such a function therefore fails in the same way as an attempt to call a non-existent function.
Note:
Examples of functions labeled with this property are filter
FO30, for-each
FO30,
fold-left
FO30, and fold-right
FO30.
A processor that does not provide the higher-order functions feature constrains the data model by disallowing function items other than maps and arrays, and may raise a dynamic error ([see ERR XTDE1665]) if this constraint is not satisfied.
The same rules apply to a dynamic XPath expression processed using xsl:evaluate
.