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
if any.
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
follows
Document nodes 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
Document node serializes the entire document.
Entity nodes, 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.
true, EntityReference nodes 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. EntityReference nodes with no children (no
corresponding Entity node or the corresponding
Entity nodes have no children) are always serialized.
CDATAsections containing 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 true,
CDATAsections are 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
CDATAsection are 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.
DocumentFragment nodes are serialized by
serializing the children of the document fragment in the order they
appear in the document fragment.
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
"well-formed").
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
completed.
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
requested).
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
specification are:
"no-output-specified" [fatal]LSOutput if no output is specified in the
LSOutput. "unbound-prefix-in-entity-reference" [fatal] true and an entity whose replacement text
contains unbound namespace prefixes is referenced in a location where
there are no bindings for the namespace prefixes. "unsupported-encoding" [fatal]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.
| Modifier and Type | Method and Description |
|---|---|
| public DOMConfiguration | |
| public LSSerializerFilter | getFilter()
When the application provides a filter, the serializer will call out to the filter before serializing each Node. |
| public String | |
| public void | setFilter(LSSerializerFilter filter)
When the application provides a filter, the serializer will call out to the filter before serializing each Node. |
| public void | setNewLine(String newLine)
The end-of-line sequence of characters to be used in the XML being written out. |
| public boolean | Returns: Returnstrue if node was
successfully serialized. Return false in case the
normal processing stopped but the implementation kept serializing
the document; the result of the serialization being implementation
dependent then.The node to serialize. nodeArg, LSOutput The destination for the serialized DOM. destination)Serialize the specified node as described above in the general
description of the |
| public String | Returns: Returns the serialized data.The node to serialize. nodeArg)Serialize the specified node as described above in the general
description of the |
| public boolean | Returns: Returnstrue if node was
successfully serialized. Return false in case the
normal processing stopped but the implementation kept serializing
the document; the result of the serialization being implementation
dependent then.The node to serialize. nodeArg, String The URI to write to. uri)A convenience method that acts as if |
| getDomConfig | back to summary |
|---|---|
| public DOMConfiguration getDomConfig() The
| |
| getFilter | back to summary |
|---|---|
| public LSSerializerFilter getFilter() When the application provides a filter, the serializer will call out
to the filter before serializing each Node. The filter implementation
can choose to remove the node from the stream or to terminate the
serialization early.
| |
| getNewLine | back to summary |
|---|---|
| public String getNewLine() The end-of-line sequence of characters to be used in the XML being
written out. Any string is supported, but XML treats only a certain
set of characters sequence as end-of-line (See section 2.11,
"End-of-Line Handling" in [XML 1.0],
if the serialized content is XML 1.0 or section 2.11, "End-of-Line Handling"
in [XML 1.1], if the
serialized content is XML 1.1). Using other character sequences than
the recommended ones can result in a document that is either not
serializable or not well-formed).
| |
| setFilter | back to summary |
|---|---|
| public void setFilter(LSSerializerFilter filter) When the application provides a filter, the serializer will call out
to the filter before serializing each Node. The filter implementation
can choose to remove the node from the stream or to terminate the
serialization early.
| |
| setNewLine | back to summary |
|---|---|
| public void setNewLine(String newLine) The end-of-line sequence of characters to be used in the XML being
written out. Any string is supported, but XML treats only a certain
set of characters sequence as end-of-line (See section 2.11,
"End-of-Line Handling" in [XML 1.0],
if the serialized content is XML 1.0 or section 2.11, "End-of-Line Handling"
in [XML 1.1], if the
serialized content is XML 1.1). Using other character sequences than
the recommended ones can result in a document that is either not
serializable or not well-formed).
| |
| write | back to summary |
|---|---|
| public boolean write(Node nodeArg, LSOutput destination) throws LSException Serialize the specified node as described above in the general
description of the
If no encoding is reachable through the above properties, a default encoding of "UTF-8" will be used. If the specified encoding is not supported an "unsupported-encoding" fatal error is raised. If no output is specified in the LSOutput, a
"no-output-specified" fatal error is raised.
The implementation is responsible of associating the appropriate media type with the serialized data. When writing to a HTTP URI, a HTTP PUT is performed. When writing to other types of URIs, the mechanism for writing the data to the URI is implementation dependent.
| |
| writeToString | back to summary |
|---|---|
| public String writeToString(Node nodeArg) throws DOMException, LSException Serialize the specified node as described above in the general
description of the
| |
| writeToURI | back to summary |
|---|---|
| public boolean writeToURI(Node nodeArg, String uri) throws LSException A convenience method that acts as if
| |