Serialization

Saxon implements the XSLT and XQuery Serialization 3.1 Recommendation dated 21 March 2017.

Saxon implements all the mandatory provisions of Serialization 3.1.

The known non-conformances are:

Serialization 3.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 behaviour. Such extensions have 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 3.1 that are implementation-defined. The list follows the numbering of Appendix E of the Serialization specification.

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 other than json and adaptive, including user-defined output methods.
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.
The effect of additional serialization parameters on the output of the serializer, where the name of such a parameter MUST be namespace-qualified, is implementation-defined or implementation-dependent. The extent of this effect on the output MUST NOT override the provisions of this specification. (See 3 Serialization Parameters)

► Saxon (PE and EE) defines a number of serialization parameters in the Saxon namespace, documented at Extensions: Serialization Parameters. Other parameters in the Saxon namespace are rejected; parameters in other namespaces are generally ignored.
Implementation-defined schema components MAY be included in the set of schema components that are used in evaluating an XQuery expression or XSLT instruction in the process of using an XDM instance to determine the serialization parameters. (See 3.1 Setting Serialization Parameters by Means of a Data Model Instance)

► Saxon does not include any such schema components.
If an instance of the data model used to determine the settings of serialization parameters contains elements or attributes that are in a namespace other than http://www.w3.org/2010/xslt-xquery-serialization, the implementation MAY interpret them to specify the values of implementation-defined serialization parameters in an implementation-defined manner. (See 3.1 Setting Serialization Parameters by Means of a Data Model Instance)

► Saxon (PE and EE) recognizes additional serialization parameters in the Saxon namespace: see Extensions: Serialization Parameters.
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.
If an implementation supports a value of the version parameter for the XML or XHTML output method for which this document does not provide a normative definition, the behavior is implementation-defined. (See 5.1.1 XML Output Method: the version Parameter)

► Saxon recognizes version="1.0" and "1.1" only; other versions result in an error.
A serializer MAY provide an implementation-defined mechanism to place CDATA sections in the result tree. (See 5.1.5 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.
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.
For the HTML output method, it is implementation-defined whether the basefont, frame and isindex elements, which are not part of HTML5, are considered to be void elements when the requested HTML version has the value 5.0. (See 7.1 Markup for Elements)

► Saxon recognizes these three elements as void.
If an implementation supports a value of the version parameter for the HTML output method for which this document does not provide a normative definition, the behavior is implementation-defined. (See 7.4.1 HTML Output Method: the version and html-version Parameters)

► Saxon requires the version to be a decimal number. If the value is 5.0 or greater, HTML5 serialization is used. If it is less than 5.0, HTML 4.0 serialization is used.
It is implementation-defined whether the serialization process recovers from serialization errors when the Adaptive output method is used. If it does, it is implementation-defined what error indicator is used. (See 10 Adaptive Output Method)

► Saxon aims to recover from all serialization errors when using the Adaptive output method. The effect of a serialization error is highly varied depending on the actual error.
It is implementation-defined whether, when the Adaptive output method is used, a serializer includes hyperlinks in its output to record the types of atomic values, the bindings of namespace prefixes, the causes of error indicators, and other information. (See 10 Adaptive Output Method)

► Saxon does not include hyperlinks in its output.