This specification defines the Document Object Model Load and Save Level 3, a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents.

1. Document Object Model Load and Save

Editors:: Johnny Stenback, Netscape; Andy Heninger, IBM (until March 2001)

1.1. Overview

This section defines a set of interfaces for loading and saving document objects as defined in [DOM Level 3 Core]. The functionality specified in this section (the Load and Save functionality) is sufficient to allow software developers and web script authors to load and save XML content inside conforming products. The DOM Load and Save API also allows filtering of XML content using only DOM API calls; access and manipulation of the Document is defined in [DOM Level 3 Core].

The proposal for loading is influenced by the Java APIs for XML Processing [JAXP] and by SAX2 [SAX].

1.1.1. Overview of the Interfaces

The list of interfaces involved with the Loading and Saving XML documents is:

DOMImplementationLS -- A new DOMImplementation interface that provides the factory methods for creating the objects required for loading and saving.
DOMBuilder -- A parser interface.
DOMInputSource -- Encapsulate information about the XML document to be loaded.
DOMEntityResolver -- During loading, provides a way for applications to redirect references to external entities.
DOMBuilderFilter -- Provide the ability to examine and optionally remove Element nodes as they are being processed during the parsing of a document.
DOMWriter -- An interface for writing out or serializing DOM documents.
DocumentLS -- Provides a client or browser style interface for loading and saving.
ParseErrorEvent -- ParseErrorEvent is the event that is fired if there's an error in the XML document being parsed using the methods of DocumentLS.

1.1.2. The DOMInputStream type

To ensure interoperability, the DOM Load and Save specifies the following:

Type Definition DOMInputStream

A DOMInputStream represents a reference to a byte stream source of an XML input.

IDL Definition

typedef Object DOMInputStream;

Note: Even though the DOM uses the type DOMInputStream, bindings may use different types. For example, in Java DOMInputStream is bound to the java.io.InputStream type, while in ECMAScript DOMInputStream is bound to Object.

1.1.3. The DOMOutputStream type

To ensure interoperability, the DOM Load and Save specifies the following:

Type Definition DOMOutputStream

A DOMOutputStream represents a byte stream destination for the XML output.

IDL Definition

typedef Object DOMOutputStream;

Note: Even though the DOM uses the type DOMOutputStream, bindings may use different types. For example, in Java DOMOutputStream is bound to the java.io.OutputStream type, while in ECMAScript DOMOutputStream is bound to Object.

1.1.4. The DOMReader type

To ensure interoperability, the DOM Load and Save specifies the following:

Type Definition DOMReader

A DOMReader represents a character stream for the XML input.

IDL Definition

typedef Object DOMReader;

Note: Even though the DOM uses the type DOMReader, bindings may use different types. For example, in Java DOMReader is bound to the java.io.Reader type, while in ECMAScript DOMReader is NOT bound, and therefore as no recommended meaning in ECMAScript.

1.2. Fundamental interfaces

The interface within this section is considered fundamental, and must be fully implemented by all conforming implementations of the DOM Load and Save module.

Interface DOMImplementationLS

DOMImplementationLS contains the factory methods for creating objects that implement the DOMBuilder (parser) and DOMWriter (serializer) interfaces.

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 [DOM Level 3 Core], by using the method Node.getInterface with parameter values "LS-Load" and "3.0" (respectively).

IDL Definition

interface DOMImplementationLS {

  // DOMIMplementationLSMode
  const unsigned short      MODE_SYNCHRONOUS               = 1;
  const unsigned short      MODE_ASYNCHRONOUS              = 2;

  DOMBuilder         createDOMBuilder(in unsigned short mode, 
                                      in DOMString schemaType)
                                        raises(DOMException);
  DOMWriter          createDOMWriter();
  DOMInputSource     createDOMInputSource();
};

Definition group DOMIMplementationLSMode

An integer indicating which type of mode this is.

Defined Constants

MODE_ASYNCHRONOUS: Create an asynchronous DOMBuilder.
MODE_SYNCHRONOUS: Create a synchronous DOMBuilder.

Methods

createDOMBuilder

Create a new DOMBuilder. The newly constructed parser may then be configured by means of its setFeature method, and used to parse documents by means of its parse method.

Parameters

mode of type unsigned short: The mode argument is either MODE_SYNCHRONOUS or MODE_ASYNCHRONOUS, if mode is MODE_SYNCHRONOUS then the DOMBuilder that is created will operate in synchronous mode, if it's MODE_ASYNCHRONOUS then the DOMBuilder that is created will operate in asynchronous mode.
schemaType of type DOMString: An absolute URI representing the type of the schema language used during the load of a Document using the newly created DOMBuilder. Note that no lexical checking is done on the absolute URI. In order to create a DOMBuilder for any kind of schema types (i.e. the DOMBuilder will be free to use any schema found), use the value null.
Note: For W3C XML Schema [XML Schema Part 1], applications must use the value "http://www.w3.org/2001/XMLSchema". For XML DTD [XML 1.0], applications must use the value "http://www.w3.org/TR/REC-xml". Other Schema languages are outside the scope of the W3C and therefore should recommend an absolute URI in order to use this method.

Return Value

DOMBuilder

The newly created DOMBuilder object. This DOMBuilder is either synchronous or asynchronous depending on the value of the mode argument.

Note: By default, the newly created DOMBuilder does not contain a DOMErrorHandler, i.e. the value of the errorHandler is null. However, implementations may provide a default error handler at creation time. In that case, the initial value of the errorHandler attribute on the new created DOMBuilder contains a reference to the default error handler.

Exceptions

DOMException

NOT_SUPPORTED_ERR: Raised if the requested mode or schema type is not supported.

createDOMInputSource

Create a new "empty" DOMInputSource.

Return Value

DOMInputSource

The newly created DOMInputSource object.

No Parameters

No Exceptions

createDOMWriter

Create a new DOMWriter object. DOMWriters are used to serialize a DOM tree back into an XML document.

Return Value

DOMWriter

The newly created DOMWriter object.

Note: By default, the newly created DOMWriter does not contain a DOMErrorHandler, i.e. the value of the errorHandler is null. However, implementations may provide a default error handler at creation time. In that case, the initial value of the errorHandler attribute on the new created DOMWriter contains a reference to the default error handler.

No Parameters

No Exceptions

Interface DocumentLS

The DocumentLS interface provides a mechanism by which the content of a document can be replaced with the DOM tree produced when loading a URI, or parsing a string. The expectation is that an instance of the DocumentLS interface can be obtained by using binding-specific casting methods on an instance of the Document interface or, if the Document supports the feature "Core" version "3.0" defined in [DOM Level 3 Core], by using the method Node.getInterface with parameter values "LS-Load" and "3.0" (respectively).

IDL Definition

interface DocumentLS {
           attribute boolean         async;
                                        // raises(DOMException) on setting

  void               abort();
  boolean            load(in DOMString uri);
  boolean            loadXML(in DOMString source);
  DOMString          saveXML(in Node snode)
                                        raises(DOMException);
};

Attributes

async of type boolean

Indicates whether the method load should be synchronous or asynchronous. When the async attribute is set to true the load method returns control to the caller before the document has completed loading. The default value of this attribute is false.

Issue async-1:: Should the DOM spec define the default value of this attribute? What if implementing both async and sync IO is impractical in some systems?
Resolution: 2001-09-14. default is false but we need to check with Mozilla and IE.

Exceptions on setting

DOMException

NOT_SUPPORTED_ERR: Raised if the implementation doesn't support the mode the attribute is being set to.

Methods

abort

If the document is currently being loaded as a result of the method load being invoked the loading and parsing is immediately aborted. The possibly partial result of parsing the document is discarded and the document is cleared.

No Parameters

No Return Value

No Exceptions

load

Replaces the content of the document with the result of parsing the given URI. Invoking this method will either block the caller or return to the caller immediately depending on the value of the async attribute. Once the document is fully loaded the document will fire a "load" event that the caller can register as a listener for. If an error occurs the document will fire an "error" event so that the caller knows that the load failed (see ParseErrorEvent). If this method is called on a document that is currently loading, the current load is interrupted and the new URI load is initiated.
When invoking this method the features used in the DOMBuilder interface are assumed to have their default values with the exception that the feature "entities" is "false".

Parameters

uri of type DOMString: The URI reference for the XML file to be loaded. If this is a relative URI, the base URI used by the implementation is implementation dependent.

Return Value

boolean

If async is set to true load returns true if the document load was successfully initiated. If an error occurred when initiating the document load load returns false.
If async is set to false load returns true if the document was successfully loaded and parsed. If an error occurred when either loading or parsing the URI load returns false.

No Exceptions

loadXML

Replace the content of the document with the result of parsing the input string, this method is always synchronous. This method always parses from a DOMString, which means the data is always UTF16. All other encoding information is ignored.
The features used in the DOMBuilder interface are assumed to have their default values when invoking this method.

Parameters

source of type DOMString: A string containing an XML document.

Return Value

boolean

true if parsing the input string succeeded without errors, otherwise false.

No Exceptions

saveXML

Save the document or the given node and all its descendants to a string (i.e. serialize the document or node).
The features used in the DOMWriter interface are assumed to have their default values when invoking this method.

Parameters

snode of type Node: Specifies what to serialize, if this parameter is null the whole document is serialized, if it's non-null the given node is serialized.

Return Value

DOMString

The serialized document or null in case an error occured.

Exceptions

DOMException

WRONG_DOCUMENT_ERR: Raised if the node passed in as the node parameter is from an other document.

1.3. Load Interfaces

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "LS-Load" and "3.0" (respectively) to determine whether or not these interfaces are supported by the implementation. In order to fully support them, an implementation must also support the "Core" feature defined in the DOM Level 3 Core specification [DOM Level 3 Core].

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "LS-Load-Async" and "3.0" (respectively) to determine whether or not the asynchronous mode is supported by the implementation. In order to fully support the asyncrhonous mode, an implementation must also support the "LS-Load" feature defined in this section.

Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core].

Interface DOMInputSource

This interface represents a single input source for an XML entity.

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), and/or a character stream.

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

There are two places that the application will deliver this input source to the parser: as the argument to the parse method, or as the return value of the DOMEntityResolver.resolveEntity method.

(ED: There are at least three places where DOMInputSource is passed to the parser (parseWithContext).)

The DOMBuilder will use the DOMInputSource object to determine how to read XML input. If there is a character stream available, the parser will read that stream directly; if not, the parser will use a byte stream, if available; if neither a character stream nor a byte stream is available, the parser will attempt to open a URI connection to the resource identified by the system identifier.

A DOMInputSource object belongs to the application: the parser shall never modify it in any way (it may modify a copy if necessary).

Note: Even though all attributes in this interface are writable the DOM implementation is expected to never mutate a DOMInputSource.

IDL Definition

interface DOMInputSource {
           attribute DOMInputStream  byteStream;
           attribute DOMReader       characterStream;
           attribute DOMString       stringData;
           attribute DOMString       encoding;
           attribute DOMString       publicId;
           attribute DOMString       systemId;
           attribute DOMString       baseURI;
};

Attributes

baseURI of type DOMString: The base URI to be used (see section 5.1.4 in [IETF RFC 2396]) for resolving relative URIs to absolute URIs. If the baseURI is itself a relative URI, the behavior is implementation dependent.
byteStream of type DOMInputStream: An attribute of a language-binding dependent type that represents a stream of bytes.
The parser will ignore this if there is also a character stream specified, but it will use a byte stream in preference to opening a URI connection itself.
If the application knows the character encoding of the byte stream, it should set the encoding attribute. Setting the encoding in this way will override any encoding specified in the XML declaration itself.
characterStream of type DOMReader: An attribute of a language-binding dependent type that represents a stream of 16-bit units. Application must encode the stream using UTF-16 (defined in [Unicode 2.0] and Amendment 1 of [ISO/IEC 10646]).
If a character stream is specified, the parser will ignore any byte stream and will not attempt to open a URI connection to the system identifier.
encoding of type DOMString: The character encoding, if known. The encoding must be a string acceptable for an XML encoding declaration ([XML 1.0] section 4.3.3 "Character Encoding in Entities").
This attribute has no effect when the application provides a character stream. For other sources of input, an encoding specified by means of this attribute will override any encoding specified in the XML declaration or the Text declaration, or an encoding obtained from a higher level protocol, such as HTTP [IETF RFC 2616].
publicId of type DOMString: The public identifier for this input source. The public identifier is always optional: if the application writer includes one, it will be provided as part of the location information.
stringData of type DOMString: A string attribute that represents a sequence of 16 bit units (utf-16 encoded characters).
If string data is available in the input source, the parser will ignore the character stream and the byte stream and will not attempt to open a URI connection to the system identifier.
systemId of type DOMString: The system identifier, a URI reference [IETF RFC 2396], for this input source. The system identifier is optional if there is a byte stream or a character stream, but it is still useful to provide one, since the application can use it to resolve relative URIs and can include it in error messages and warnings (the parser will attempt to fetch the ressource identifier by the URI reference only if there is no byte stream or character stream specified).
If the application knows the character encoding of the object pointed to by the system identifier, it can register the encoding by setting the encoding attribute.
If the system ID is a relative URI reference (see section 5 in [IETF RFC 2396]), the behavior is implementation dependent.

Interface LSLoadEvent

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

IDL Definition

interface LSLoadEvent : events::Event {
  readonly attribute Document        newDocument;
  readonly attribute DOMInputSource  inputSource;
};

Attributes

inputSource of type DOMInputSource, readonly: The input source that was parsed.
newDocument of type Document, readonly: The document that finished loading.

Interface LSProgressEvent

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 [DOM Level 3 Events].

IDL Definition

interface LSProgressEvent : events::Event {
  readonly attribute DOMInputSource  inputSource;
  readonly attribute unsigned long   position;
  readonly attribute unsigned long   totalSize;
};

Attributes

inputSource of type DOMInputSource, readonly: The input source that is being parsed.
position of type unsigned long, readonly: The current position in the input source, including all external entities and other resources that have been read.
totalSize of type unsigned long, readonly: The total size of the document including all external resources, this number might change as a document is being parsed if references to more external resources are seen.

Interface DOMEntityResolver

DOMEntityResolver Provides a way for applications to redirect references to external entities.

Applications needing to implement customized handling for external entities must implement this interface and register their implementation by setting the entityResolver attribute of the DOMBuilder.

The DOMBuilder will then allow the application to intercept any external entities (including the external DTD subset and external parameter entities) before including them.

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 URNs.

Note: DOMEntityResolver is based on the SAX2 [SAX] EntityResolver interface.

IDL Definition

interface DOMEntityResolver {
  DOMInputSource     resolveEntity(in DOMString publicId, 
                                   in DOMString systemId, 
                                   in DOMString baseURI);
};

Methods

resolveEntity

Allow the application to resolve external entities.
The DOMBuilder will call this method before opening any external entity except the top-level document entity (including the external DTD subset, external entities referenced within the DTD, and external entities referenced within the document element); the application may request that the DOMBuilder resolve the entity itself, that it use an alternative URI, or that it use an entirely different input source.
Application writers can use this method to redirect external system identifiers to secure and/or local URIs, to look up public identifiers in a catalogue, or to read an entity from a database or other input source (including, for example, a dialog box).
If the system identifier is a URI, the DOMBuilder must resolve it fully before reporting it to the application through this interface.

(ED: See issue #4. An alternative would be to pass the URI out without resolving it, and to provide a base as an additional parameter. SAX resolves URIs first, and does not provide a base. )

Parameters

publicId of type DOMString: The public identifier of the external entity being referenced, or null if none was supplied.
systemId of type DOMString: The system identifier, a URI reference [IETF RFC 2396], of the external entity being referenced exactly as written in the source.
baseURI of type DOMString: The absolute base URI of the resource being parsed, or null if there is no base URI.

Return Value

DOMInputSource

A DOMInputSource object describing the new input source, or null to request that the parser open a regular URI connection to the system identifier.

No Exceptions

Interface DOMBuilderFilter

DOMBuilderFilters provide applications the ability to examine nodes as they are being constructed during a parse. 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 DOMBuilderFilter methods, i.e. it is not possible to filter out the document element. The Document, DocumentType, Notation, and Entity nodes are not passed to the filter.

All validity checking while reading 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 content, including default attributes, must be passed to the filter methods.

Any exception raised in the filter are ignored by the DOMBuilder.

(ED: The description of these methods is not complete)

IDL Definition

interface DOMBuilderFilter {

  // Constants returned by startElement and acceptNode
  const short               FILTER_ACCEPT                  = 1;
  const short               FILTER_REJECT                  = 2;
  const short               FILTER_SKIP                    = 3;
  const short               FILTER_INTERRUPT               = 4;

  unsigned short     startElement(in Element elt);
  unsigned short     acceptNode(in Node enode);
  readonly attribute unsigned long   whatToShow;
};

Definition group Constants returned by startElement and acceptNode

Constants returned by startElement and acceptNode.

Defined Constants

FILTER_ACCEPT: Accept the node.
FILTER_INTERRUPT: Interrupt the normal processing of the document.
FILTER_REJECT: Reject the node abd its children.
FILTER_SKIP: Skip this single node. The children of this node will still be considered.

Attributes

whatToShow of type unsigned long, readonly: Tells the DOMBuilder what types of nodes to show to the filter. See NodeFilter for definition of the constants. The constant SHOW_ATTRIBUTE is meaningless here, attribute nodes will never be passed to a DOMBuilderFilter.

Methods

acceptNode

This method will be called by the parser at the completion of the parsing of each node. The node and all of its descendants will exist and be complete. The parent node will also exist, although it may be incomplete, i.e. it may have additional children that have not yet been parsed. Attribute nodes are never passed to this function.
From within this method, the new node may be freely modified - children may be added or removed, text nodes modified, etc. The state of the rest of the document outside this node is not defined, and the affect of any attempt to navigate to, or to modify any other part of the document is undefined.
For validating parsers, the checks are made on the original document, before any modification by the filter. No validity checks are made on any document modifications made by the filter.
If this new node is rejected, the parser might reuse the new node or any of its descendants.

Parameters

enode of type Node: The newly constructed element. At the time this method is called, the element is complete - it has all of its children (and their children, recursively) and attributes, and is attached as a child to its parent.

Return Value

unsigned short

FILTER_ACCEPT if this Node should be included in the DOM document being built.
FILTER_REJECT if the Node and all of its children should be rejected.
FILTER_SKIP if the Node should be skipped and the Node should be replaced by all the children of the Node.
FILTER_INTERRUPT if the filter wants to stop the processing of the document. Interrupting the processing of the document does no longer guarantee that the entire is XML well-formed.

No Exceptions

startElement

This method will be called by the parser after each Element start tag has been scanned, but before the remainder of the Element is processed. The intent is to allow the element, including any children, to be efficiently skipped. Note that only element nodes are passed to the startElement function.
The element node passed to startElement for filtering will include all of the Element's attributes, but none of the children nodes. The Element may not yet be in place in the document being constructed (it may not have a parent node.)
A startElement filter function may access or change the attributes for the Element. Changing Namespace declarations will have no effect on namespace resolution by the parser.
For efficiency, the Element node passed to the filter may not be the same one as is actually placed in the tree if the node is accepted. And the actual node (node object identity) may be reused during the process of reading in and filtering a document.

Parameters

elt of type Element: The newly encountered element. At the time this method is called, the element is incomplete - it will have its attributes, but no children.

Return Value

unsigned short

FILTER_ACCEPT if this Element should be included in the DOM document being built.
FILTER_REJECT if the Element and all of its children should be rejected.
FILTER_SKIP if the Element should be rejected. All of its children are inserted in place of the rejected Element node.
FILTER_INTERRUPT if the filter wants to stop the processing of the document. Interrupting the processing of the document does no longer guarantee that the entire is XML well-formed.

Returning any other values will result in unspecified behavior.

No Exceptions

Interface DOMBuilder

A interface to an object that is able to build a DOM tree from various input sources.

DOMBuilder provides an API for parsing XML documents and building the corresponding DOM document tree. A DOMBuilder instance is obtained from the DOMImplementationLS interface by invoking its createDOMBuildermethod.

As specified in [DOM Level 3 Core], when a document is first made available via the DOMBuilder:

there is only one Text node for each block of text. The Text nodes are into "normal" form: only structure (e.g., elements, comments, processing instructions, CDATA sections, and entity references) separates Text nodes, i.e., there are neither adjacent Text nodes nor empty Text nodes.
it is expected that the value and nodeValue attributes of an Attr node initially return the XML 1.0 normalized value. However, if the features validate-if-schema and datatype-normalization are set to true, depending on the attribute normalization used, the attribute values may differ from the ones obtained by the XML 1.0 attribute normalization. If the feature datatype-normalization is not set to true, the XML 1.0 attribute normalization is guaranteed to occur, and if attributes list does not contain namespace declarations, the attributes attribute on Element node represents the property [attributes] defined in [XML Information set] .

Issue Infoset:

XML Schemas does not modify the XML attribute normalization but represents their normalized value in an other information item property: [schema normalized value]
Resolution: XML Schema normalization only occurs if datatype-normalization is set to true.

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

Events supported by asynchronous DOMBuilder are:

load: The document that's being loaded is completely parsed, see the definition of LSLoadEvent
progress: Progress notification, see the definition of LSProgressEvent

Note: All events defined in this specification use the namespace URI "http://www.w3.org/2002/DOMLS".

DOMBuilders have a number of named features that can be queried or set. The name of DOMBuilder features must be valid XML names. Implementation specific features (extensions) should choose a implementation specific prefix to avoid name collisions.

Even if all features must be recognized by all implementations, being able to set a state (true or false) is not always required. The following list of recognized features indicates the definitions of each feature state, if setting the state to true or false must be supported or is optional and, which state is the default one:

"canonical-form"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"cdata-sections"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"certified"

true: [optional]
Assume, when XML 1.1 is supported, that the input is certified (see section 2.13 in [XML 1.1]).
false: [required] (default)
Don't assume that the input is certified (see section 2.13 in [XML 1.1]).

"charset-overrides-xml-encoding"

true: [required] (default)
If a higher level protocol such as HTTP [IETF RFC 2616] provides an indication of the character encoding of the input stream being processed, that will override any encoding specified in the XML declaration or the Text declaration (see also [XML 1.0] 4.3.3 "Character Encoding in Entities"). Explicitly setting an encoding in the DOMInputSource overrides encodings from the protocol.
false: [required]
Any character set encoding information from higher level protocols is ignored by the parser.

"comments"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"datatype-normalization"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"entities"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"infoset"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core]. Setting this feature to true will also force the feature namespaces to true.

"namespaces"

true: [required] (default)
Perform the namespace processing as defined in [XML Namespaces].
false: [optional]
Do not perform the namespace processing.

"namespace-declarations"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"supported-mediatypes-only"

true: [optional]
Check that the media type of the parsed resource is a supported media type and call the error handler if an unsupported media type is encountered. The media types defined in [IETF RFC 3023] must be accepted.
false: [required] (default)
Don't check the media type, accept any type of data.

"unknown-characters"

true: [required] (default)
If, while verifying full normalization when XML 1.1 is supported, a processor encounters characters for which it cannot determine the normalization properties, then the processor will ignore any possible denormalizations caused by these characters.
false: [optional]
Report an fatal error if a character is encountered for which the processor can not determine the normalization properties.

"validate"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"validate-if-schema"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"whitespace-in-element-content"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

IDL Definition

interface DOMBuilder {
           attribute DOMEntityResolver entityResolver;
           attribute DOMErrorHandler errorHandler;
           attribute DOMBuilderFilter filter;
  void               setFeature(in DOMString name, 
                                in boolean state)
                                        raises(DOMException);
  boolean            canSetFeature(in DOMString name, 
                                   in boolean state);
  boolean            getFeature(in DOMString name)
                                        raises(DOMException);
  Document           parseURI(in DOMString uri);
  Document           parse(in DOMInputSource is);

  // ACTION_TYPES
  const unsigned short      ACTION_REPLACE                 = 1;
  const unsigned short      ACTION_APPEND_AS_CHILDREN      = 2;
  const unsigned short      ACTION_INSERT_AFTER            = 3;
  const unsigned short      ACTION_INSERT_BEFORE           = 4;

  void               parseWithContext(in DOMInputSource is, 
                                      in Node cnode, 
                                      in unsigned short action)
                                        raises(DOMException);
};

Definition group ACTION_TYPES

A set of possible actions for the parseWithContext method.

Defined Constants

ACTION_APPEND_AS_CHILDREN: Append the result of the input source as children of the context node. For this action to work, the context node must be an Element or a DocumentFragment.
ACTION_INSERT_AFTER: Insert the result of parsing the input source after the context node. For this action to work the context nodes parent must be an Element.
ACTION_INSERT_BEFORE: Insert the result of parsing the input source before the context node. For this action to work the context nodes parent must be an Element.
ACTION_REPLACE: Replace the context node with the result of parsing the input source. For this action to work the context node must have a parent and the context node must be an Element, Text, CDATASection, Comment, ProcessingInstruction, or EntityReference node.

Attributes

entityResolver of type DOMEntityResolver: If a DOMEntityResolver has been specified, each time a reference to an external entity is encountered the DOMBuilder will pass the public and system IDs to the entity resolver, which can then specify the actual source of the entity.
If this attribute is null, the resolution of entities in the document is implementation dependent.
errorHandler of type DOMErrorHandler: In the event that an error is encountered in the XML document being parsed, the DOMDocumentBuilder will call back to the errorHandler with the error information. When the document loading process calls the error handler the node closest to where the error occured is passed to the error handler, if the implementation is unable to pass the node where the error occures the document Node is passed to the error handler. In addition to passing the Node closest to to where the error occured, the implementation should also pass any other valuable information to the error handler, such as file name, line number, and so on. Mutations to the document from within an error handler will result in implementation dependent behaviour.
filter of type DOMBuilderFilter: When the application provides a filter, the parser will call out to the filter at the completion of the construction of each Element node. The filter implementation can choose to remove the element from the document being constructed (unless the element is the document element) or to terminate the parse early. If the document is being validated when it's loaded the validation happens before the filter is called.

Methods

canSetFeature

Query whether setting a feature to a specific value is supported.
The feature name has the same form as a DOM hasFeature string.

Parameters

name of type DOMString: The feature name, which is a DOM has-feature style string.
state of type boolean: The requested state of the feature (true or false).

Return Value

boolean

true if the feature could be successfully set to the specified value, or false if the feature is not recognized or the requested value is not supported. The value of the feature itself is not changed.

No Exceptions

getFeature

Look up the value of a feature.
The feature name has the same form as a DOM hasFeature string

Parameters

name of type DOMString: The feature name, which is a string with DOM has-feature syntax.

Return Value

boolean

The current state of the feature (true or false).

Exceptions

DOMException

NOT_FOUND_ERR: Raised when the DOMBuilder does not recognize the feature name.

parse

Parse an XML document from a resource identified by a DOMInputSource.

Parameters

is of type DOMInputSource: The DOMInputSource from which the source document is to be read.

Return Value

Document

If the DOMBuilder is a synchronous DOMBuilder the newly created and populated Document is returned. If the DOMBuilder is asynchronous then null is returned since the document object is not yet parsed when this method returns.

No Exceptions

parseURI

Parse an XML document from a location identified by a URI reference [IETF RFC 2396]. If the URI contains a fragment identifier (see section 4.1 in [IETF RFC 2396]), the behavior is not defined by this specification, but future versions of this specification might define the behavior.

Parameters

uri of type DOMString: The location of the XML document to be read.

Return Value

Document

No Exceptions

parseWithContext

Parse an XML fragment from a resource identified by a DOMInputSource and insert the content into an existing document at the position specified with the contextNode and action arguments. When parsing the input stream the context node is used for resolving unbound namespace prefixes. The Document node, attached to the context node, is used to resolved default attributes and entity references.
As the new data is inserted into the document at least one mutation event is fired per immediate child (or sibling) of context node.
If an error occurs while parsing, the caller is notified through the error handler.

Parameters

is of type DOMInputSource: The DOMInputSource from which the source document is to be read. The source document must be an XML fragment, i.e. anything except an XML Document, a DOCTYPE, entities declarations, notations declarations, or XML or text declarations.
cnode of type Node: The node that is used as the context for the data that is being parsed. This node must be a Document node, a DocumentFragment node, or a node of a type that is allowed as a child of an element, e.g. it can not be an attribute node.
action of type unsigned short: This parameter describes which action should be taken between the new set of node being inserted and the existing children of the context node. The set of possible actions is defined above.

Exceptions

DOMException

NOT_SUPPORTED_ERR: Raised when the DOMBuilder doesn't support this method.

NO_MODIFICATION_ALLOWED_ERR: Raised if the context node is readonly.

No Return Value

setFeature

Set the state of a feature.
The feature name has the same form as a DOM hasFeature string.
It is possible for a DOMBuilder to recognize a feature name but to be unable to set its value.

Parameters

name of type DOMString: The feature name.
state of type boolean: The requested state of the feature (true or false).

Exceptions

DOMException

NOT_SUPPORTED_ERR: Raised when the DOMBuilder recognizes the feature name but cannot set the requested value.

NOT_FOUND_ERR: Raised when the DOMBuilder does not recognize the feature name.

No Return Value

1.4. Save Interfaces

A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values "LS-Save" and "3.0" (respectively) to determine whether or not these interfaces are supported by the implementation. In order to fully support them, an implementation must also support the "Core" feature defined in the DOM Level 3 Core specification [DOM Level 3 Core]. Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core].

Interface DOMWriter

DOMWriter provides an API for serializing (writing) a DOM document out in an XML document. The XML data is written to an output stream, the type of which depends on the specific language bindings in use.

During serialization of XML data, namespace fixup is done when possible 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.

Note: should the remark on DOM Level 2 namespace URI included in the namespace algorithm in Core instead?

DOMWriter accepts any node type for serialization. For nodes of type Document or Entity, well formed XML will be created if possible. The serialized output for these node types is either as a Document or an External Entity, respectively, and is acceptable input for an XML parser. For all other types of nodes the serialized form is not specified, but should be something useful to a human for debugging or diagnostic purposes. Note: rigorously designing an external (source) form for stand-alone node types that don't already have one defined in [XML 1.0] seems a bit much to take on here.

Within a Document, DocumentFragment, or Entity being serialized, Nodes are processed as follows

Documents are written including an XML declaration and a DTD subset, if one exists in the DOM. Writing a document node serializes the entire document.
Entity nodes, when written directly by writeNode defined in the DOMWriter interface, output the entity expansion but no namespace fixup is done. The resulting output will be valid as an external entity.
Entity reference nodes are serialized as an entity reference of the form "&entityName;" in the output. Child nodes (the expansion) of the entity reference are ignored.
CDATA sections containing content characters that can not be represented in the specified output encoding are handled according to the "split-cdata-sections" feature.
If the feature is true, CDATA sections 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 feature is false, unrepresentable characters in a CDATA section are reported as errors. 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.
All other node types (Element, Text, etc.) are serialized to their corresponding XML source form.

Note: The serialization of a DOM Node does not always generate a well-formed XML document, i.e. a DOMBuilder might through 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 &amp. The other predefined entities (&gt, &apos, etc.) are not used; these characters can be included directly. Any character that can not be represented directly in the output character encoding is serialized as a numeric character reference.

Attributes not containing quotes are serialized in quotes. Attributes containing quotes but no apostrophes are serialized in apostrophes (single quotes). Attributes containing both forms of quotes are serialized in quotes, with quotes within the value represented by the predefined entity ". Any character that can not be represented directly in the output character encoding is 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 an error. An example would be serializing the element <LaCañada/> with the encoding="us-ascii".

When requested by setting the normalize-characters feature on DOMWriter, all data to be serialized, both markup and character data, is W3C Text normalized according to the rules defined in [CharModel]. The W3C Text 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.

Namespaces are fixed up during serialization, the serialization process will verify that namespace declarations, namespace prefixes and the namespace URIs associated with Elements and Attributes are consistent. If inconsistencies are found, the serialized form of the document will be altered to remove them. The algorithm used for doing the namespace fixup while serializing a document is a combination of the algorithms used for lookupNamespaceURI and lookupNamespacePrefix .

(ED: previous paragraph to be defined closer here.)

Any changes made affect only the namespace prefixes and declarations appearing in the serialized data. The DOM's view of the document is not altered by the serialization operation, and does not reflect any changes made to namespace declarations or prefixes in the serialized output.

While serializing a document the serializer will write out non-specified values (such as attributes whose specified is false) if the discard-default-content feature is set to true. If the discard-default-content flag is set to false and a schema is used for validation, the schema will be also used to determine if a value is specified or not. If no schema is used, the specified flag on attribute nodes is used to determine if attribute values should be written out.

Ref to Core spec (1.1.9, XML namespaces, 5th paragraph) entity ref description about warning about unbound entity refs. Entity refs are always serialized as &foo;, also mention this in the load part of this spec.

DOMWriters have a number of named features that can be queried or set. The name of DOMWriter features must be valid XML names. Implementation specific features (extensions) should choose an implementation dependent prefix to avoid name collisions.

Here is a list of features that must be recognized by all implementations.

Note: Using these features does affect the Node being serialized, only its serialized form is affected.

"discard-default-content"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"canonical-form"

true: [optional]
This formatting writes the document according to the rules specified in [Canonical XML]. Setting this feature to true will set the feature "format-pretty-print" to false.
false: [required] (default)
Do not canonicalize the output.

"entities"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"format-pretty-print"

true: [optional]
Formatting the output by adding whitespace to produce a pretty-printed, indented, human-readable form. The exact form of the transformations is not specified by this specification. Setting this feature to true will set the feature "canonical-form" to false.
false: [required] (default)
Don't pretty-print the result.

"namespaces"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"normalize-characters"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core]. Unlike in the Core, the default value for this feature is true.

"split-cdata-sections"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"validate"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

"unknown-characters"

true: [required] (default)
If, while verifying full normalization when XML 1.1 is supported, a character is encountered for which the normalization properties cannot be determined, then ignore any possible denormalizations caused by these characters.
false: [optional]
Report an fatal error if a character is encountered for which the processor can not determine the normalization properties.

"whitespace-in-element-content"

This feature is equivalent to the one provided on Document.setNormalizationFeature in [DOM Level 3 Core].

IDL Definition

interface DOMWriter {
  void               setFeature(in DOMString name, 
                                in boolean state)
                                        raises(DOMException);
  boolean            canSetFeature(in DOMString name, 
                                   in boolean state);
  boolean            getFeature(in DOMString name)
                                        raises(DOMException);
           attribute DOMString       encoding;
           attribute DOMString       newLine;
           attribute DOMWriterFilter filter;
           attribute DOMErrorHandler errorHandler;
  boolean            writeNode(in DOMOutputStream destination, 
                               in Node wnode);
  DOMString          writeToString(in Node wnode)
                                        raises(DOMException);
};

Attributes

encoding of type DOMString

The character encoding in which the output will be written.
The encoding to use when writing is determined as follows:

If the encoding attribute has been set, that value will be used.
If the encoding attribute is null or empty, but the item to be written, or the owner document of the item, specifies an encoding (i.e. the "actualEncoding" from the document) specified encoding, that value will be used.
If neither of the above provides an encoding name, a default encoding of "UTF-8" will be used.

The default value is null.

errorHandler of type DOMErrorHandler

The error handler that will receive error notifications during serialization. The node where the error occured is passed to this error handler, any modification to nodes from within an error callback should be avoided since this will result in undefined, implementation dependent behavior.

filter of type DOMWriterFilter

When the application provides a filter, the serializer will call out to the filter before serializing each Node. Attribute nodes are never passed to the filter. The filter implementation can choose to remove the node from the stream or to terminate the serialization early.

newLine of type DOMString

The end-of-line sequence of characters to be used in the XML being written out. Any string is supported, but these are the recommended end-of-line sequences (using other character sequences than these recommended ones can result in a document that is either not serializable or not well-formed):

null: Use a default end-of-line sequence. DOM implementations should choose the default to match the usual convention for text files in the environment being used. Implementations must choose a default sequence that matches one of those allowed by "End-of-Line Handling" ([XML 1.0], section 2.11) if the serialized content is XML 1.0 or "End-of-Line Handling" ([XML 1.1], section 2.11) if the serialized content is XML 1.1.
CR: The carriage-return character (#xD).
CR-LF: The carriage-return and line-feed characters (#xD #xA).
LF: The line-feed character (#xA).

The default value for this attribute is null.

Methods

canSetFeature

Query whether setting a feature to a specific value is supported.
The feature name has the same form as a DOM hasFeature string.

Parameters

name of type DOMString: The feature name, which is a DOM has-feature style string.
state of type boolean: The requested state of the feature (true or false).

Return Value

boolean

No Exceptions

getFeature

Look up the value of a feature.
The feature name has the same form as a DOM hasFeature string

Parameters

name of type DOMString: The feature name, which is a string with DOM has-feature syntax.

Return Value

boolean

The current state of the feature (true or false).

Exceptions

DOMException

NOT_FOUND_ERR: Raised when the DOMWriter does not recognize the feature name.

setFeature

Set the state of a feature.
The feature name has the same form as a DOM hasFeature string.
It is possible for a DOMWriter to recognize a feature name but to be unable to set its value.

Parameters

name of type DOMString: The feature name.
state of type boolean: The requested state of the feature (true or false).

Exceptions

DOMException

NOT_SUPPORTED_ERR: Raised when the DOMWriter recognizes the feature name but cannot set the requested value.

Raise a NOT_FOUND_ERR When the DOMWriter does not recognize the feature name.

No Return Value

writeNode

Write out the specified node as described above in the description of DOMWriter. Writing a Document or Entity node produces a serialized form that is well formed XML, when possible (Entity nodes might not always be well formed XML in themselves). Writing other node types produces a fragment of text in a form that is not fully defined by this document, but that should be useful to a human for debugging or diagnostic purposes.
If the specified encoding is not supported the error handler is called and the serialization is interrupted.

Parameters

destination of type DOMOutputStream: The destination for the data to be written.
wnode of type Node: The Document or Entity node to be written. For other node types, something sensible should be written, but the exact serialized form is not specified.

Return Value

boolean

Returns true if node was successfully serialized and false in case a failure occured and the failure wasn't canceled by the error handler.

No Exceptions

writeToString

Serialize the specified node as described above in the description of DOMWriter. The result of serializing the node is returned as a DOMString (this method completely ignores all the encoding information available). Writing a Document or Entity node produces a serialized form that is well formed XML. Writing other node types produces a fragment of text in a form that is not fully defined by this document, but that should be useful to a human for debugging or diagnostic purposes.
Error handler is called if encoding not supported...

Parameters

wnode of type Node: The node to be written.

Return Value

DOMString

Returns the serialized data, or null in case a failure occured and the failure wasn't canceled by the error handler.

Exceptions

DOMException

DOMSTRING_SIZE_ERR: Raised if the resulting string is too long to fit in a DOMString.

Interface DOMWriterFilter

DOMWriterFilters provide applications the ability to examine nodes as they are being serialized. DOMWriterFilter lets the application decide what nodes should be serialized or not.

The Document, DocumentType, Notation, and Entity nodes are not passed to the filter.

IDL Definition

interface DOMWriterFilter : traversal::NodeFilter {
  readonly attribute unsigned long   whatToShow;
};

Attributes

whatToShow of type unsigned long, readonly: Tells the DOMWriter what types of nodes to show to the filter. See NodeFilter for definition of the constants. The constants SHOW_ATTRIBUTE, SHOW_DOCUMENT, SHOW_DOCUMENT_TYPE, SHOW_NOTATION, and SHOW_DOCUMENT_FRAGMENT are meaningless here, those nodes will never be passed to a DOMWriterFilter. Entity nodes are not passed to the filter.

1.5. Issue List

1.5.1. Open Issues

Issue LS-Issue-90:: The interaction and relationships between all the DOMBuilder and DOMWriter features need to be defined, i.e. setting x will set y and unset z.
Issue LS-Issue-15:: System Exceptions. Loading involves file opens and reads, and these can result in a variety of system errors that may already have associated system exceptions. Should these system exceptions pass through as is, or should they be some how wrapped in DOMExceptions, or should there be a parallel set DOM Exceptions, or what?
Issue LS-Issue-21:: Define exceptions. A DOMSystemException needs to be defined as part of the error handling module that is to be shared with AS. Common I/O type errors need to be defined for it, so that they can be reported in a uniform way. A way to embed errors or exceptions from the OS or language environment is needed, to provide full information to applications that want it.
Issue LS-Issue-106:: There is no way to query the DOMImplementation for a specific DOMBuilder. support XML 1.1? support validation? namespaces=false?

1.5.2. Resolved Issues

Issue LS-Issue-1:: Should these methods be in a new interface, or should they be added to the existing DOMImplementation Interface? I think that adding them to the existing interface is cleaner, because it helps avoid an explosion of new interfaces.
The methods are in a separate interface in this description for convenience in preparing the doc, so that I don't need to edit Core to add the methods. (The same argument could perhaps be made for implementations.)
Resolution: The methods are in a separate DOMImplementationLS interface. Because Load/Save is an optional module, we don't want to add its to the core DOMImplementation interface.
Issue LS-Issue-2:: SAX handles the setting of parser attributes differently. Rather than having distinct getters and setters for each attribute, it has a generic setter and getter of named properties, where properties are specified by a URI. This has an advantage in that implementations do not need to extend the interface when providing additional attributes.
If we choose to use strings, their syntax needs to be chosen. URIs would make sense, except for the fact that these are just names that do not refer to any resources. Dereferencing them would be meaningless. Yet the direction of the W3C is that all URIs must be dereferencable, and refer to something on the web.
Resolution: Use strings for properties. Use Java package name syntax for the identifying names. The question was revisited at the July f2f, with the same conclusion. But some discussion of using URIs continues.
This issue was revisited once again at the 9/2000 meeting. Now all DOM properties or features will be short, descriptive names, and we will recommend that all vendor-specific extensions be prefixed to avoid collisions, but will not make specific recommendations for the syntax of the prefix.
Issue LS-Issue-3:: It's not obvious what name to choose for the parser interface. Taking any of the names already in use by parser implementations would create problems when

Document Object Model (DOM) Level 3 Load and Save Specification

Version 1.0

W3C Working Draft 25 July 2002

Abstract

Status of this document

Table of contents

Expanded Table of Contents

Copyright Notice

W3C Document Copyright Notice and License

W3C Software Copyright Notice and License

1. Document Object Model Load and Save

Table of contents

1.1. Overview

1.1.1. Overview of the Interfaces

1.1.2. The DOMInputStream type

1.1.3. The DOMOutputStream type

1.1.4. The DOMReader type

1.2. Fundamental interfaces

1.3. Load Interfaces

1.4. Save Interfaces

1.5. Issue List

1.5.1. Open Issues

1.5.2. Resolved Issues