Serialization

The Serialization specification for XSLT 2.0 and XQuery 1.0 (let's call it Serialization 2/1) does not define its own conformance rules, saying instead that these are up to the host language to define.

Saxon implements all the mandatory provisions of Serialization 2/1.

The known non-conformances are:

• Serialization 2/1 states that characters that can be natively encoded in the chosen encoding must be natively encoded and must not be represented using character or entity references. Saxon behaves this way by default, but provides an extension, saxon:character-representation, which changes the behavior. Such extensions have recently been declared non-conformant, but this one is retained in Saxon for backwards compatibility reasons.

Implementation-defined aspects of Serialization

This section defines how Saxon interprets those aspects of Serialization 2/1 that are implementation-defined. The list follows the numbering of Appendix D of the Serialization specification.

1. For any implementation-defined output method, it is implementation-defined whether sequence normalization process takes place. (See 2 Sequence Normalization)

   Sequence normalization takes place for all output methods, including user-defined output methods.

2. If the namespace URI is non-null for the method serialization parameter, then the parameter specifies an implementation-defined output method. (See 3 Serialization Parameters)

   In such cases the local name of the method must be the name of a Java class that implements one of the interfaces org.xml.sax.ContentHandler, net.sf.saxon.event.Emitter, or net.sf.saxon.event.Receiver. The class is loaded from the classpath and then takes responsibility for producing the serialized output (if any). The actual namespace URI is ignored.

3. If the value of the normalization-form parameter is not NFC, NFD, NFKC, NFKD, fully-normalized, or none then the meaning of the value and its effect is implementation-defined. (See 4 Phases of Serialization)

   Any value other than those listed is an error.

4. The effect of providing an option that allows the encoding phase to be skipped, so that the result of serialization is a stream of Unicode characters, is implementation-defined. The serializer is not required to support such an option. (See 4 Phases of Serialization)

   Saxon allows the serialized output to be written to a Java Writer, which is a character stream. In this case no encoding takes place.

5. A serializer may provide an implementation-defined mechanism to place CDATA sections in the result tree. (See 5.1.4 XML Output Method: the cdata-section-elements Parameter)

   Saxon defines a factory class that enables Java applications to insert user-defined classes into the serialization pipeline. This mechanism could be used to override the standard CDATA processing.

The main change in the Serialization specification for XSLT 3.0 and XQuery 3.0 (let's call it Serialization 3.0) is the introduction of support for HTML5. Saxon 9.5 supports some of these changes, but as yet no detailed test suite is available for these changes so it is not possible to be confident that the changes have been implemented completely.

In addition, Serialization 3.0 introduces some new serialization parameters. The item-separator and html-version parameters are not supported in Saxon 9.5. The suppress-indentation parameter is supported. The parameter-document parameter is supported in XQuery but not in XSLT.