Serialization

The Serialization specification 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 the serialization specification.

The known non-conformances are:

• The serialization specification 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.

The following page defines how Saxon interprets those aspects of the serialization specification that are implementation-defined.

Implementation-defined aspects of Serialization

This section defines how Saxon interprets those aspects of the serialization specification 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.