DOMImplementationLS contains the factory methods for creating Load and Save objects.

The expectation is that an instance of the DOMImplementationLS interface can be obtained by using binding-specific casting methods on an instance of the DOMImplementation interface or, if the Document supports the feature "Core" version "3.0" defined in , by using the method DOMImplementation.getFeature with parameter values "LS" (or "LS-Async") and "3.0" (respectively).

An interface to an object that is able to build, or augment, a DOM tree from various input sources.

LSParser provides an API for parsing XML and building the corresponding DOM document structure. A LSParser instance can be obtained by invoking the DOMImplementationLS.createLSParser() method.

As specified in , when a document is first made available via the LSParser:

Asynchronous LSParser objects are expected to also implement the events::EventTarget interface so that event listeners can be registered on asynchronous LSParser objects.

Events supported by asynchronous LSParser objects are:

While parsing an input source, errors are reported to the application through the error handler (LSParser.domConfig's "error-handler" parameter). This specification does in no way try to define all possible errors that can occur while parsing XML, or any other markup, but some common error cases are defined. The types (DOMError.type) of errors and warnings defined by this specification are: "check-character-normalization-failure" [error]

Raised if the paramter "check-character-normalization" is set to true and a string is encountered that fails normalization checking.

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,...), XML well-formedness errors, and so on.

This interface represents an input source for data.

This interface allows an application to encapsulate information about an input source in a single object, which may include a public identifier, a system identifier, a byte stream (possibly with a specified encoding), a base URI, and/or a character stream.

The exact definitions of a byte stream and a character stream are binding dependent.

The application is expected to provide objects that implement this interface whenever such objects are needed. The application can either provide its own objects that implement this interface, or it can use the generic factory method DOMImplementationLS.createLSInput() to create objects that implement this interface.

The LSParser will use the LSInput object to determine how to read data. The LSParser will look at the different inputs specified in the LSInput in the following order to know which one to read from, the first one that is not null and not an empty string will be used:

LSInput.characterStream

If all inputs are null, the LSParser will report a DOMError with its DOMError.type set to "no-input-specified" and its DOMError.severity set to DOMError.SEVERITY_FATAL_ERROR.

LSInput objects belong to the application. The DOM implementation will never modify them (though it may make copies and modify the copies, if necessary).

LSResourceResolver provides a way for applications to redirect references to external resources.

Applications needing to implement custom handling for external resources can implement this interface and register their implementation by setting the "resource-resolver" parameter of DOMConfiguration objects attached to LSParser and LSSerializer. It can also be register on DOMConfiguration objects attached to Document if the "LS" feature is supported.

The LSParser will then allow the application to intercept any external entities, including the external DTD subset and external parameter entities, before including them. The top-level document entity is never passed to the resolveResource method.

Many DOM applications will not need to implement this interface, but it will be especially useful for applications that build XML documents from databases or other specialized input sources, or for applications that use URN's.

LSParserFilters provide applications the ability to examine nodes as they are being constructed while parsing. As each node is examined, it may be modified or removed, or the entire parse may be terminated early.

At the time any of the filter methods are called by the parser, the owner Document and DOMImplementation objects exist and are accessible. The document element is never passed to the LSParserFilter methods, i.e. it is not possible to filter out the document element. Document, DocumentType, Notation, Entity, and Attr nodes are never passed to the acceptNode method on the filter. The child nodes of an EntityReference node are passed to the filter if the parameter "entities" is set to false. Note that, as described by the parameter "entities", entity reference nodes to non-defined entities are never discarded and are always passed to the filter.

All validity checking while parsing a document occurs on the source document as it appears on the input stream, not on the DOM document as it is built in memory. With filters, the document in memory may be a subset of the document on the stream, and its validity may have been affected by the filtering.

All default attributes must be present on elements when the elements are passed to the filter methods. All other default content must be passed to the filter methods.

DOM applications must not raise exceptions in a filter. The effect of throwing exceptions from a filter is DOM implementation dependent.

This interface represents a progress event object that notifies the application about progress as a document is parsed. It extends the Event interface defined in .

The units used for the attributes position and totalSize are not specified and can be implementation and input dependent.

This interface represents a load event object that signals the completion of a document load.

A 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 , Appendix B. 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

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 &lt; and &amp;. The other predefined entities (&gt;, &apos;, and &quot;) might not be used, except where needed (e.g. using &gt; 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 "&apos;", and the double-quote character (") as "&quot;". 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 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.

When outputting unicode data, whether or not a byte order mark is serialized, or if the output is big-endian or little-endian, is implementation dependent.

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 .

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]

Raised when writing to a LSOutput if no output is specified in the LSOutput.

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.

This interface represents an output destination for data.

This interface allows an application to encapsulate information about an output destination in a single object, which may include a URI, a byte stream (possibly with a specified encoding), a base URI, and/or a character stream.

The exact definitions of a byte stream and a character stream are binding dependent.

The application is expected to provide objects that implement this interface whenever such objects are needed. The application can either provide its own objects that implement this interface, or it can use the generic factory method DOMImplementationLS.createLSOutput() to create objects that implement this interface.

The LSSerializer will use the LSOutput object to determine where to serialize the output to. The LSSerializer will look at the different outputs specified in the LSOutput in the following order to know which one to output to, the first one that is not null and not an empty string will be used:

LSOutput.characterStream

LSOutput objects belong to the application. The DOM implementation will never modify them (though it may make copies and modify the copies, if necessary).

LSSerializerFilters provide applications the ability to examine nodes as they are being serialized and decide what nodes should be serialized or not. The LSSerializerFilter interface is based on the NodeFilter interface defined in .

Document, DocumentType, DocumentFragment, Notation, Entity, and children of Attr nodes are not passed to the filter. The child nodes of an EntityReference node are only passed to the filter if the EntityReference node is skipped by the method LSParserFilter.acceptNode().

When serializing an Element, the element is passed to the filter before any of its attributes are passed to the filter. Namespace declaration attributes, and default attributes (except in the case when "discard-default-content" is set to false), are never passed to the filter.

The result of any attempt to modify a node passed to a LSSerializerFilter is implementation dependent.

DOM applications must not raise exceptions in a filter. The effect of throwing exceptions from a filter is DOM implementation dependent.

For efficiency, a node passed to the filter may not be the same as the one that is actually in the tree. And the actual node (node object identity) may be reused during the process of filtering and serializing a document.