F Checklist of Implementation-Defined Features (Non-Normative)

This appendix provides a summary of XSLT language features whose effect is explicitly implementation-defined. The conformance rules (see 27 Conformance) require vendors to provide documentation that explains how these choices have been exercised.

The implementation-defined features are grouped into categories for convenience.

F.1 Application Programming Interfaces

This category covers interfaces for initiating a transformation, setting its parameters, initializing the static and dynamic context, and collecting the results. In general terms, it is implementation defined how input is passed to the processor and how it returns its output. This includes the interpretation of URIs used to refer to stylesheet packages and modules, source documents and collections, collations, and result documents.

More specifically:

  1. If the initialization of any global variables or parameter depends on the context item, a dynamic error can occur if the context item is absent. It is implementation-defined whether this error occurs during priming of the stylesheet or subsequently when the variable is referenced; and it is implementation-defined whether the error occurs at all if the variable or parameter is never referenced. (See 2.3.2 Priming a Stylesheet)

  2. The way in which an XSLT processor is invoked, and the way in which values are supplied for the source document, starting node, stylesheet parameters, and base output URI, are implementation-defined. (See 2.3.2 Priming a Stylesheet)

  3. The way in which a base output URI is established is implementation-defined (See 2.3.6.2 Serializing the Result)

  4. It is implementation-defined how a package is located given its name and version, and which version of a package is chosen if several are available. (See 3.5.2 Dependencies between Packages)

  5. In the absence of an [xsl:]default-collation attribute, the default collation may be set by the calling application in an implementation-defined way. (See 3.7.1 The default-collation Attribute)

  6. It is implementation-defined what forms of URI reference are acceptable in the href attribute of the xsl:include and xsl:import elements, for example, the URI schemes that may be used, the forms of fragment identifier that may be used, and the media types that are supported. The way in which the URI reference is used to locate a representation of a stylesheet module, and the way in which the stylesheet module is constructed from that representation, are also implementation-defined. (See 3.11.1 Locating Stylesheet Modules)

  7. The statically known documentsXP30, statically known collectionsXP30, and the statically known default collection typeXP30 are implementation-defined. (See 5.3.1 Initializing the Static Context)

  8. Implementations may provide user options that relax the requirement for the docFO30 and collectionFO30 functions (and therefore, by implication, the document function) to return stable results. The manner in which such user options are provided, if at all, is implementation-defined. (See 5.3.3 Initializing the Dynamic Context)

  9. Streamed processing may be initiated by invoking the transformation with an initial mode declared as streamable, while supplying the initial match selection (in an implementation-defined way) as a streamed document. (See 6.6.4 Streamable Templates)

  10. The mechanism by which the caller supplies a value for a stylesheet parameter is implementation-defined. (See 9.5 Global Variables and Parameters)

  11. The detail of any external mechanism allowing a processor to enable or disable checking of assertions is implementation-defined. (See 23.2 Assertions)

  12. The way in which the results of the transformation are delivered to an application is implementation-defined. (See 25 Transformation Results)

  13. It is implementation-defined how the URI appearing in the href attribute of xsl:result-document affects the way in which the result tree is delivered to the application. There may be restrictions on the form of this URI. (See 25.1 Creating Secondary Results)

  14. If serialization is supported, then the location to which a final result tree is serialized is implementation-defined, subject to the constraint that relative URI references used to reference one tree from another remain valid. (See 26 Serialization)

F.2 Vendor and User Extensions

This category covers extensions and extensibility: mechanisms for providing vendor or user extensions to the language without sacrificing interoperability.

In general terms, it is implementation-defined:

More specifically:

  1. The mechanisms for creating new extension instructions and extension functions are implementation-defined. It is not required that implementations provide any such mechanism. (See 2.9 Extensibility)

  2. The set of namespaces that are specially recognized by the implementation (for example, for user-defined data elements, and extension attributes) is implementation-defined. (See 3.7.3 User-defined Data Elements)

  3. The effect of user-defined data elements whose name is in a namespace recognized by the implementation is implementation-defined. (See 3.7.3 User-defined Data Elements)

  4. An implementation may define mechanisms, above and beyond xsl:import-schema, that allow schema components such as type definitions to be made available within a stylesheet. (See 3.14 Built-in Types)

  5. The set of extension functions available in the static context for the target expression of xsl:evaluate is implementation-defined. (See 10.4.1 Static context for the target expression)

  6. If the data-type attribute of the xsl:sort element has a value other than text or number, the effect is implementation-defined. (See 13.1.2 Comparing Sort Key Values)

  7. The posture and sweep of extension functions (and references to extension functions) and extension instructions are implementation-defined. (See 19.8.4.2 Streamability of extension instructions)

  8. Additional streamability categories for stylesheet functions may be defined by an implementation. (See 19.8.5 Classifying Stylesheet Functions)

  9. The effect of an extension function returning a string containing characters that are not permitted in XML is implementation-defined. (See 24.1.2 Calling Extension Functions)

  10. The way in which external objects are represented in the type system is implementation-defined. (See 24.1.3 External Objects)

F.3 Localization

This specification, and the specifications that it refers to, include facilities for adapting the output of a transformation to meet local expectations: examples include the formatting of numbers and dates, and the choice of collations for sorted output. The general principles are:

More specifically:

  1. The combinations of languages and numbering sequences recognized by the xsl:number instruction, beyond those defined as mandatory in this specification, are implementation-defined. There may be implementation-defined upper bounds on the numbers that can be formatted using any particular numbering sequence. There may be constraints on the values of the ordinal attribute recognized for any given language. (See 12.4 Number to String Conversion Attributes)

  2. The facilities for defining collations and allocating URIs to identify them are largely implementation-defined. (See 13.1.3 Sorting Using Collations)

  3. The algorithm used by xsl:sort to locate a collation, given the values of the lang and case-order attributes, is implementation-defined. (See 13.1.3 Sorting Using Collations)

  4. If none of the collation, lang, or case-order attributes is present (on xsl:sort), the collation is chosen in an implementation-defined way. (See 13.1.3 Sorting Using Collations)

  5. When using the family of URIs that invoke the Unicode Collation Algorithm, the effect of supplying a query keyword or value not defined in this specification is implementation-defined. The defaults for query keywords are also implementation-defined unless otherwise stated. (See 13.4 The Unicode Collation Algorithm)

F.4 Optional Features

As well as the optional conformance features identified in 27 Conformance, some specific features of the specification are defined to be optional.

  1. It is implementation-defined whether an XSLT 3.0 processor supports backwards compatible behavior for any XSLT version earlier than XSLT 3.0. (See 3.9 Backwards Compatible Processing)

  2. If an xml:id attribute that has not been subjected to attribute value normalization is copied from a source tree to a result tree, it is implementation-defined whether attribute value normalization will be applied during the copy process. (See 11.9.1 Shallow Copy)

  3. It is implementation-defined whether, and under what circumstances, disabling output escaping is supported. (See 26.2 Disabling Output Escaping)

F.5 Dependencies

When this specification refers normatively to other specifications, it generally gives implementations freedom to decide (within constraints) which version of the referenced specification should be used. Specifically:

  1. It is implementation-defined which versions and editions of XML and XML Namespaces (1.0 and/or 1.1) are supported. (See 4.1 XML Versions)

  2. It is implementation-defined which versions of XML, HTML, and XHTML are supported in the version attribute of the xsl:output declaration. (See 26 Serialization)

  3. It is implementation-defined whether (and if so how) an XSLT 3.0 processor is able to work with versions of XPath later than XPath 3.1. (See 27 Conformance)

  4. It is implementation-defined whether (and if so how) an XSLT 3.0 processor is able to work with versions of [XSLT and XQuery Serialization] later than 3.1. (See 27.3 Serialization Feature)

F.6 Defaults and Limits

To accommodate variations in the way that the XSLT language is deployed, and the constraints of different processing environments, defaults for some options are implementation-defined. In addition, limits on the sizes of ranges of values permitted are in general implementation-defined:

  1. Limits on the value space of primitive datatypes, where not fixed by [XML Schema Part 2], are implementation-defined. (See 4.7 Limits)

  2. The default value of the encoding attribute of the xsl:output element is implementation-defined. Where the encoding is UTF-8, the default for the byte-order-mark attribute is implementation-defined. (See 26 Serialization)

F.7 Detection and Reporting of Errors

Some aspects of error handling are implementation-defined:

  1. It is implementation-defined whether type errors are signaled statically. (See 2.14 Error Handling)

  2. If the effective version of any element in the stylesheet is not 1.0 or 2.0 but is less than 3.0, the recommended action is to report a static error; however, processors may recognize such values and process the element in an implementation-defined way. (See 3.9 Backwards Compatible Processing)

  3. The default values for the warning-on-no-match and warning-on-multiple-match attributes of xsl:mode are implementation-defined. (See 6.6.1 Declaring Modes)

  4. The form of any warnings output when there is no matching template rule, or when there are multiple matching template rules, is implementation-defined. (See 6.6.1 Declaring Modes)

  5. The destination and formatting of messages written using the xsl:message instruction are implementation-defined. (See 23.1 Messages)