LSSerializer provides an API for serializing (writing) a
DOM document out into XML. The XML data is written to a string or an
output stream. Any changes or fixups made during the serialization affect
only the serialized data. The
Document object and its
children are never altered by the serialization operation.
During serialization of XML data, namespace fixup is done as defined in [DOM Level 3 Core]
, Appendix B. [DOM Level 2 Core]
allows empty strings as a real namespace URI. If the
namespaceURI of a
Node is empty string, the
serialization will treat them as
null, ignoring the prefix
LSSerializer accepts any node type for serialization. For
nodes of type
XML will be created when possible (well-formedness is guaranteed if the
document or entity comes from a parse operation and is unchanged since it
was created). The serialized output for these node types is either as a
XML document or an External XML Entity, respectively, and is acceptable
input for an XML parser. For all other types of nodes the serialized form
is implementation dependent.
Entity being serialized,
Nodes are processed as
Documentnodes are written, including the XML declaration (unless the parameter "xml-declaration" is set to
false) and a DTD subset, if one exists in the DOM. Writing a
Documentnode serializes the entire document.
Entitynodes, when written directly by
LSSerializer.write, outputs the entity expansion but no namespace fixup is done. The resulting output will be valid as an external entity.
- If the parameter "
entities" is set to
EntityReferencenodes are serialized as an entity reference of the form "
&entityName;" in the output. Child nodes (the expansion) of the entity reference are ignored. If the parameter " entities" is set to
false, only the children of the entity reference are serialized.
EntityReferencenodes with no children (no corresponding
Entitynode or the corresponding
Entitynodes have no children) are always serialized.
CDATAsectionscontaining content characters that cannot be represented in the specified output encoding are handled according to the " split-cdata-sections" parameter. If the parameter is set to
CDATAsectionsare split, and the unrepresentable characters are serialized as numeric character references in ordinary content. The exact position and number of splits is not specified. If the parameter is set to
false, unrepresentable characters in a
CDATAsectionare reported as
"wf-invalid-character"errors if the parameter " well-formed" is set to
true. The error is not recoverable - there is no mechanism for supplying alternative characters and continuing with the serialization.
DocumentFragmentnodes are serialized by serializing the children of the document fragment in the order they appear in the document fragment.
- All other node types (Element, Text, etc.) are serialized to their corresponding XML source form.
Note: The serialization of a
Node does not always
generate a well-formed XML document, i.e. a
throw fatal errors when parsing the resulting serialization.
Within the character data of a document (outside of markup), any characters that cannot be represented directly are replaced with character references. Occurrences of '<' and '&' are replaced by the predefined entities < and &. The other predefined entities (>, ', and ") might not be used, except where needed (e.g. using > in cases such as ']]>'). Any characters that cannot be represented directly in the output character encoding are serialized as numeric character references (and since character encoding standards commonly use hexadecimal representations of characters, using the hexadecimal representation when serializing character references is encouraged).
To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be represented as "'", and the double-quote character (") as """. New line characters and other characters that cannot be represented directly in attribute values in the output character encoding are serialized as a numeric character reference.
Within markup, but outside of attributes, any occurrence of a character
that cannot be represented in the output character encoding is reported
DOMError fatal error. An example would be serializing
the element <LaCañada/> with
This will result with a generation of a
"wf-invalid-character-in-node-name" (as proposed in "
When requested by setting the parameter "
LSSerializer to true, character normalization is
performed according to the definition of fully
normalized characters included in appendix E of [XML 1.1] on all
data to be serialized, both markup and character data. The character
normalization process affects only the data as it is being written; it
does not alter the DOM's view of the document after serialization has
Implementations are required to support the encodings "UTF-8",
"UTF-16", "UTF-16BE", and "UTF-16LE" to guarantee that data is
serializable in all encodings that are required to be supported by all
XML parsers. When the encoding is UTF-8, whether or not a byte order mark
is serialized, or if the output is big-endian or little-endian, is
implementation dependent. When the encoding is UTF-16, whether or not the
output is big-endian or little-endian is implementation dependent, but a
Byte Order Mark must be generated for non-character outputs, such as
the Byte Order Mark is not generated, a "byte-order-mark-needed" warning
is reported. When the encoding is UTF-16LE or UTF-16BE, the output is
big-endian (UTF-16BE) or little-endian (UTF-16LE) and the Byte Order Mark
is not be generated. In all cases, the encoding declaration, if
generated, will correspond to the encoding used during the serialization
encoding="UTF-16" will appear if UTF-16 was
Namespaces are f