27 Conformance

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:

  1. The schema-awareness feature, defined in 27.2 Schema-Awareness Conformance Feature

  2. The serialization feature, defined in 27.3 Serialization Feature

  3. The backwards compatibility feature, defined in 27.4 Compatibility Features

  4. The streaming feature, defined in 27.5 Streaming Feature.

  5. The dynamic evaluation feature, defined in 27.6 Dynamic Evaluation Feature.

  6. The higher-order functions feature, defined in 27.8 Higher-Order Functions Feature.

  7. 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:

[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, docFO30, and collectionFO30, 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.

27.1 Basic XSLT Processor

[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.

27.2 Schema-Awareness Conformance Feature

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:

27.3 Serialization Feature

[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 serializeFO30 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 serializeFO30 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.

27.4 Compatibility Features

[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.

27.5 Streaming Feature

[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.

27.6 Dynamic Evaluation Feature

[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.

27.7 XPath 3.1 Feature

[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:

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.

27.7.1 Arrays

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].

27.8 Higher-Order Functions Feature

[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 filterFO30, for-eachFO30, fold-leftFO30, and fold-rightFO30.

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.