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 Document or Entity, well-formed
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.
Within a Document, DocumentFragment, or
Entity being serialized, Nodes are processed as
Note: The serialization of a Node does not always
generate a well-formed XML document, i.e. a LSParser might
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
as a DOMError fatal error. An example would be serializing
the element <LaCañada/> with encoding="us-ascii".
This will result with a generation of a DOMError
"wf-invalid-character-in-node-name" (as proposed in "
When requested by setting the parameter "
normalize-characters" on 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
LSOutput.byteStream or LSOutput.systemId. If
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
(e.g. encoding="UTF-16" will appear if UTF-16 was
Namespaces are fixed up during serialization, the serialization process
will verify that namespace declarations, namespace prefixes and the
namespace URI associated with elements and attributes are consistent. If
inconsistencies are found, the serialized form of the document will be
altered to remove them. The method used for doing the namespace fixup
while serializing a document is the algorithm defined in Appendix B.1,
"Namespace normalization", of [DOM Level 3 Core]
While serializing a document, the parameter "discard-default-content"
controls whether or not non-specified data is serialized.
While serializing, errors and warnings are reported to the application
through the error handler (LSSerializer.domConfig's "
error-handler" parameter). This specification does in no way try to define all possible
errors and warnings that can occur while serializing a DOM node, but some
common error and warning cases are defined. The types (
DOMError.type) of errors and warnings defined by this
In addition to raising the defined errors and warnings, implementations
are expected to raise implementation specific errors and warnings for any
other error and warning cases such as IO errors (file not found,
permission denied,...) and so on.
See also the Document Object Model (DOM) Level 3 Load
and Save Specification.