1.1.1. General Characteristics

In the October 9, 1997 DOM requirements document, the following appeared: "There will be a way to determine the presence of a DTD. There will be a way to add, remove, and change declarations in the underlying DTD (if available). There will be a way to test conformance of all or part of the given document against a DTD (if available)." In later discussions, the following was added, "There will be a way to query element/attribute (and maybe other) declarations in the underlying DTD (if available)," supplementing the primitive support for these in Level 1.

That work was deferred past Level 2, in the hope that XML Schemas would be addressed as well. It is anticipated that lowest common denominator general APIs generated in this chapter can support both DTDs and XML Schemas, and other XML content models down the road.

The kinds of information that a Content Model must make available are mostly self-evident from the definitions of Infoset, DTDs, and XML Schemas. Note that some kinds of information on which the DOM already relies, e.g., default values for attributes, will finally be given a visible representation here, however.

1.1.2. Use Cases and Requirements

The content model referenced in these use cases/requirements is an abstraction and does not refer solely to DTDs or XML Schemas.

For the CM-editing and document-editing worlds, the following use cases and requirements are common to both and could be labeled as the "Validation and Other Common Functionality" section:

Use Cases:

1. CU1. Associating a content model (external and/or internal) with a document, or changing the current association.
2. CU2. Using the same external content model with several documents, without having to reload it.

Requirements:

1. CR1. Validate against the content model.
2. CR2. Retrieve information from content model.
3. CR3. Load an existing content model, perhaps independently from a document.
4. CR4. Being able to determine if a document has a content model associated with it.
5. CR5. Associate a CM with a document and make it the active CM.

Specific to the CM-editing world, the following are use cases and requirements and could be labeled as the "CM-editing" section:

Use Cases:

1. CMU1. Clone/map all or parts of an existing content model to a new or existing content model.
2. CMU2. Save a content model in a separate file. For example, if a DTD can be broken up into reusable pieces, which are then brought in via entity references, these can then be saved in a separate file. Note that the external subset of a DTD, which includes both an internal and external subset, is a special case of dividing a content model into entities.
3. CMU3. Modify an existing content model.
4. CMU4. Create a new content model.
5. CMU5. Partial content model checking. For example, the document need only be validated against a selected portion of the content model.

Requirements:

1. CMR1. View and modify all parts of the content model.
2. CMR2. Validate the content model itself.
3. CMR3. Serialize the content model.
4. CMR4. Clone all or parts of an existing content model.
5. CMR5. Create a new content model object.
6. CMR6. Validate portions of the XML document against the content model.

Specific to the document-editing world, the following are use cases and requirements and could be labeled as the "Document-editing" section:

Use Cases:

1. DU1. For editing documents with an associated content model, provide the guidance necessary so that valid documents can be modified and remain valid.
2. DU2. For editing documents with an associated content model, provide the guidance necessary to transform an invalid document into a valid one.

Requirements:

1. DR1. Be able to determine if the document is well-formed, and if not, be given enough guidance to locate the error.
2. DR2. Be able to determine if the document is namespace well-formed, and if not, be given enough guidance to locate the error.
3. DR3. Be able to determine if the document is valid with respect to its associated content model, and if not, give enough guidance to locate the error.
4. DR4. Be able to determine if specific modifications to a document would make it become invalid.
5. DR5. Retrieve information from all content models. One example might be getting a list of all the defined element names for document editing purposes.

General Issues:

1. I1. Some concerns exist regarding whether a single abstract Content Model structure can successfully represent both namespace-unaware, e.g., DTD, and namespace-aware, e.g., XML Schema, models of document's content. For example, when you ask what elements can be inserted in a specific place, the former will report the element's QName, e.g., foo:bar, whereas the latter will report its namespace and local name, e.g., {http://my.namespace}bar. We have added the isNamespaceAware attribute to the generic CM object to help applications determine which of these fields are important, but we are still analyzing this challenge.
2. I2. An XML document may be associated with multiple CMs. We have decided that only one of these is "active" (for validation and guidance) at a time. DOM applications may switch which CM is active, remove CMs that are no longer relevant, or add CMs to the list. If it becomes necessary to simultaneously consult more than one CM, it should be possible to write a "union" CM which provides that capability within this framework.
3. I3. Content model being able to handle more datatypes than strings. Currently, this functionality is not available and should be dealt with in the future.
4. I4. Round-trippability for include/ignore statements and other constructs such as parameter entities, e.g., "macro-like" constructs, will not be supported since no data representation exists to support these constructs without having to re-parse them.
5. I5. Basic interface for a common error handler for both CM and Load/Save. Agreement has been to utilize user-registered callbacks but other details to be worked out.

2.1.1. General Requirements

Requirements that apply to both loading and saving documents.

2.1.2. Load Requirements

The following requirements apply to loading documents.

2.1.3. XML Writer Requirements

The fundamental requirement is to write a DOM document as XML source. All information to be serialized should be available via the normal DOM API.

2.1.4. Other Items Under Consideration

The following items are not committed to, but are under consideration. Public feedback on these items is especially requested.

2.2.1. Open Issues

Issue LS-Issue-10:

Error Reporting. Loading will be reporting well-formedness and validation errors, just like CM. A common error reporting mechanism needs to be developed.

Issue LS-Issue-12:

Definition of "Non-validating". Exactly how much processing is done by "non-validating" parsers is not fully defined by the XML specification. In particular, they are not required to read any external entities, but are not prohibited from doing so.
Another common user request: a mode that completely ignores DTDs, both and external. Such a parser would not conform to XML 1.0, however.
For the documents produced by a non-validating load to be the same, we need to tie down exactly what processing must be done. The XML Core WG also has question as an open issue .
Some discussion is at http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000JanMar/0192.html
Here is proposal: Have three classes of parsers

• Minimal. No external entities of any type are accessed. DTD subset is processes normally, as required by XML 1.0, including all entity definitions it contains.
• Non-Validating. All external entities are read. Does everything except validation.
• Validating. As defined by XML 1.0 rec.

Tentative resolution: use the options from SAX2. These provide separate flags for validation, reading of external general entities and reading of external parameter entities.

Issue LS-Issue-14:

Should there be separate DOM modules for browser or scripting style loading (document.load("whatever")) and server style parsers? It's probably easy for the server style parsers to implement the browser style interface, but the reverse may not be true.

Issue LS-Issue-16:

Loading and saving of content models - DTDs or Schemas - outside of the context of a document is not addressed.

Issue LS-Issue-17:

Loading while validating using an already loaded content model is not addressed. Applications should be able to load a content model (issue 16), and then repeatedly reuse it during the loading of additional documents.

Issue LS-Issue-20:

Action from September f2f to "add issues raised by schema discussion. What were these?

Issue LS-Issue-22:

What do the bindings for things like InputStream look like in ECMA Script?

Issue LS-Issue-27:

How is validation handled when there are multiple possible content models associated with the document? How is one selected?

Issue LS-Issue-31:

We now have an option for fixing up name space declarations and prefixes on serialization. Should we specify how this is done, so that the documents from different implementations of serialization will use the same declarations and prefixes, or should we leave the details up to the implementation?

Issue LS-Issue-32:

Mimetypes. If the input being parsed is from http or something else that supplies types, and the type is something other than text/xml, should we parse it anyhow, or should we complain. Should there be an option? My preference - always parse, never complain. Reasons: 1. This is what all parsers do now, and no one has ever complained, at least not that I'm aware of. 2. Applications must have a pretty good reason to suspect that they're getting xml or they wouldn't have invoked the parser. 3. All the test would do is to take something that might have worked (xml that is not known to the server) and turn it into an error.

Issue LS-Issue-33:

Unicode Character Normalization Problems. It turns out that for some code pages, normalizing a Unicode representation, translating to the code page, then translating back to Unicode can result in un-normalized Unicode. Mark Davis says that this can happen with Vietnamese and maybe with Hebrew.
This means that the suggested W3C model of normalization on serialization (early normalization) may not work, and that the receiver of the data may need to normalize it again, just in case.

2.2.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 URL. 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 URLs 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 trying to support both the new API and the existing old API. That leaves out DocumentBuilder (Sun) and DOMParser (Xerces).
Resolution: This is issue really just a comment. The "resolution" is in the names appearing in the API.

Issue LS-Issue-4:

Question: should ResolveEntity pass a baseURI string back to the application, in addition to the publicId, systemId, and/or stream? Particularly in the case of an input stream.
Resolution: No. Sax2 explicitly says that the system ID URI must be fully resolved before passing it out to the entity resolve. We will follow SAX's lead on this unless some additional use case surfaces. This is from the 9/2000 f2f, and reverses an earlier decision.

Issue LS-Issue-5:

When parsing a document that contains errors, should the whole document be decreed unusable, or should we say that portions prior to the point where the error was detected are OK?
Resolution: In the case of errors in the XML source, what, if any, document is returned is implementation dependent.

Issue LS-Issue-6:

The relationship between SAXExceptions and DOM exceptions seems confusing.
Resolution: This issue goes away because we are no longer using SAX. Any exceptions will be DOM Exceptions.

Issue LS-Issue-7:

Question: In the original Java definition, are the strings returned from the methods SAXException.toString() and SAXException.getMessage() always the same? If not, we need to add another attribute.
Resolution: No longer an issue because we are no longer using SAX.

Issue LS-Issue-8:

JAXP defines a mechanism, based on Java system properties, by which the Document Builder Factory locates the specific parser implementation to be used. This ability to redirect to different parsers is a key feature of JAXP. How this redirection works in the context of this design may be something that needs to be defined separately for each language binding.
This question was discussed at the July f2f, without resolution. Agreed that the feature is not critical to the rest of the API, and can be postponed.
Resolution: The issue is moving to core, where it is part of the bigger question of where does the DOM implementation come from, and how do multiple implementations coexist. Allowing separate, or mix-and-match, specification of the parser and the rest of the DOM is not generally practical because parsers generally have some degree of private knowledge about their DOMs.

Issue LS-Issue-9:

The use of interfaces from SAX2 raises some questions. The Java bindings for these interfaces need to be exactly the SAX2 definitions, including the original org.xml.sax package name.
The IDL presented here for these interfaces is an attempt to map the Java into IDL, but it will certainly not round-trip accurately - Java bindings generated from the IDL will not match the original Java.
The reasons for using the SAX interfaces are that they are well designed, widely implemented and used, and provide what is needed. Designing something new would create confusion for application developers (which should be used?) and make extra work for implementers of the DOM, most of whom probably already provide SAX, all for no real gain.
Resolution: Problem is gone. We are not using SAX2. The design will borrow features and concepts from SAX2 when it makes sense to do so.

Issue LS-Issue-11:

Another Error Reporting Question. We decided at the June f2f that validity errors should not be exceptions. This means that a document load operation could encounter multiple errors. Should these be collected and delivered as some sort of collection at the (otherwise) successful completion of the load, or should there be some sort of callback? Callbacks are harder for applications to deal with.
Resolution: Provide a callback mechanism. Provide a default error handler that throws an exception and stops further processing. From July f2f.

Issue LS-Issue-13:

Use of System or Language specific types for Input and Output
Loading and Saving requires that one of the possible sources or destinations of the XML data be some sort of stream that can be used with io streams or memory buffers, or anything else that might take or supply data. The type will vary, depending on the language binding.
The question is, what should be put into the IDL interfaces for these? Should we define an XML stream to abstract out the dependency, or use system classes directly in the bindings?
Resolution: Define IDL types for use in the rest of the interface definitions. These types will be mapped directly to system types for each language binding

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?
Resolution: Introduce a new DOMSystemException to standardize the reporting of common I/O errors across different DOM environments. Let it wrap an underlying system exception or error code when appropriate. To be defined in the common ErrorReporting module, to be shared with ContentModel.

Issue LS-Issue-18:

For the list of parser properties, which must all implementations recognize, which settings must all implementations support, and which are optional?
Resolution: Done

Issue LS-Issue-19:

DOMOutputStream: should this be an interface with methods, or just an opaque type that maps onto an appropriate binding-specific stream type?
If we specify an actual interface with methods, applications can implement it to wrap any arbitrary destination that they may have. If we go with the system type it's simpler to output to that type of stream, but harder otherwise.
Resolution: Opaque.

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 CM. 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.
Resolution: Duplicate of issue #15

Issue LS-Issue-23:

To Do: Add a method or methods to DOMBuilder that will provide information about a parser feature - is the name recognized, which (boolean) values are supported - without throwing exceptions.
Resolution: Done. Added canSetFeature.

Issue LS-Issue-24:

Clearly identify which of the parser properties must be recognized, and which of their settings must be supported by all conforming implementations.
Resolution: Done. All must be recognized.

Issue LS-Issue-25:

How does the validation property work in SAX, and how should it work for us? The default value in SAX2 is "true". Non-validating parsers only support a value of false. Does this mean that the default depends on the parser, or that some sort of an error happens if a parse is attempted before resetting the property, or what?
The same question applies to the External Entities properties too.
Resolution: Make the default value for the validation property be false.

Issue LS-Issue-26:

Do we want to rename the "auto-validation" property to "validate-if-cm"? Proposed at f2f. Resolution unclear.
Resolution: Changed the name to "validate-if-cm".

Issue LS-Issue-29:

Should all properties except namespaces default to false? Discussed at f2f. I'm not so sure now. Some of the properties have somewhat non-standard behavior when false - leaving out ER nodes or whitespace, for example - and support of false will probably not even be required.
Resolution: Not all properties should default to false. But validation should.

Issue LS-Issue-28:

To do: add new parser property "createEntityNodes". default is true. Illegal for it to be false and createEntityReferenceNodes to be true.
Is this really what we want?
Resolution: new feature added.

Issue LS-Issue-30:

Possible additional parser features - option to not create CDATA nodes, and to merge CDATA contents with adjacent TEXT nodes if they exist. Otherwise just create a TEXT node.
Option to omit Comments.
Resolution: new feature added.

2.3.1. Interface Summary

Here is a list of each of the interfaces involved with the Loading and Saving XML documents.

• 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 source of the XML 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.

2.3.2. Interfaces

Interface DOMImplementationLS

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

IDL Definition

interface DOMImplementationLS {
  DOMBuilder         createDOMBuilder();
  DOMWriter          createDOMWriter();
};

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.

Return Value

DOMBuilder

The newly created parser object.

No Parameters

No Exceptions

createDOMWriter

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

Return Value

DOMWriter

The newly created DOMWriter object.

No Parameters

No Exceptions

Interface DOMBuilder

A parser interface.

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 createDOMBuilder()method.

DOMBuilders have a number of named properties that can be queried or set. Here is a list of properties that must be recognized by all implementations.

• namespaces
  true: perform Namespace processing.
  false: do not perform name space processing.
  default: true.
  supported values: true: required; false: optional
• namespace-declarations
  true: include namespace declarations (xmlns attributes) in the DOM document.
  false: discard all namespace declarations. In either case, namespace prefixes will be retained.
  default: true.
  supported values: true: required; false: optional
• validation
  true: report validation errors (setting true also will force the external-general-entities and external-parameter-entities properties to be set true.) Also note that the validate-if-cm feature will alter the validation behavior when this feature is set true.
  false: do not report validation errors.
  default: false.
  supported values: true: optional; false: required
  
• external-general-entities
  true: include all external general (text) entities.
  false: do not include external general entities.
  default: true.
  supported values: true: required; false: optional
  
• external-parameter-entities
  true: include all external parameter entities.
  false: do not include external parameter entities.
  default: true.
  supported values: true: required; false: optional
• validate-if-cm
  true: when both this feature and validation are true, enable validation only when the document being processed has a content model. Documents without content models are parsed without validation.
  false: the validation feature alone controls whether the document is checked for validity. Documents without content models are not valid.
  default: false.
  supported values: true: optional; false: required
  
• create-entity-ref-nodes
  true: create entity reference nodes in the DOM document. Setting this value true will also set create-entity-nodes to be true
  false: omit all entity reference nodes from the DOM document, putting the entity expansions directly in their place.
  default: true.
  supported values: true: required; false: optional
• entity-nodes
  true: create entity nodes in the DOM document.
  false: omit all entity nodes from the DOM document. Setting this value false will also set create-entity-ref-nodes false.
  default: true.
  supported values: true: required; false: optional
• white-space-in-element-content
  true: include white space in element content in the DOM document. This is sometimes referred to as ignorable white space
  false: omit said white space. Note that white space in element content will only be omitted if it can be identified as such, and not all parsers may be able to do so.
  default: true.
  supported values: true: required; false: optional
• cdata-nodes
  true: Create DOM CDATA nodes in response to the appearance of CDATA sections in the source XML.
  false: Do not create CDATA nodes in the DOM document. The content of any CDATA sections in the source XML appears in the DOM as if it had been normal (non-CDATA) content. If a CDATA section is adjacent to other content, the combined content appears in a single TEXT node. The DOM Document produced by the DOMBuilder will not have adjacent TEXT nodes.
  default: true
  supported values: false: optional; true: required
• comments
  true: Include XML comments in the DOM document
  false: Discard XML comments, do not create Comment nodes in the DOM Document resulting from a parse.
  default: true
  supported values: false: required; true: required
• charset-overrides-xml-encoding
  true: If a higher level protocol such as http provides an indication of the character encoding of the input stream being processed, that will override any encoding specified in the XML or TEXT declaration of the XML. Explicitly setting an encoding in the DOMInputSource overrides encodings from the protocol.
  false: Any character set encoding information from higher level protocols is ignored by the parser.
  default: true
  supported values: false: required; true: required

IDL Definition

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

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.

errorHandler of type DOMErrorHandler

In the event that an error is encountered in the XML document being parsed, the DOMDcoumentBuilder will call back to the errorHandler with the error information.

Note: The DOMErrorHandler interface is being developed separately, in conjunction with the design of the content model and validation module.

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 or to terminate the parse early.

Methods

canSetFeature

query whether setting a feature is supported.
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, 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

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

parseDOMInputSource

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

Parameters

is of type DOMInputSource

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

Return Value

Document

The newly created and populatedDocument.

Exceptions

DOMException	Exceptions raised by parseDOMInputSource() originate with the installed ErrorHandler, and thus depend on the implementation of the DOMErrorHandler interfaces. The default ErrorHandlers will raise a DOMException if any form of XML validation or well formedness error or warning occurs during the parse, but application defined errorHandlers are not required to do so.
DOMSystemException	Exceptions raised by parseDOMInputSource() originate with the installed ErrorHandler, and thus depend on the implementation of the DOMErrorHandler interfaces. The default ErrorHandlers will raise a DOMSystemException if any form I/O or other system error occurs during the parse, but application defined ErrorHandlers are not required to do so.

parseURI

Parse an XML document from a location identified by an URI.

Parameters

uri of type DOMString

The location of the XML document to be read.

Return Value

Document

The newly created and populatedDocument.

Exceptions

DOMException	Exceptions raised by parseURI() originate with the installed ErrorHandler, and thus depend on the implementation of the DOMErrorHandler interfaces. The default error handlers will raise a DOMException if any form of XML validation or well formedness error or warning occurs during the parse, but application defined errorHandlers are not required to do so.
DOMSystemException	Exceptions raised by parseURI() originate with the installed ErrorHandler, and thus depend on the implementation of the DOMErrorHandler interfaces. The default error handlers will raise a DOMSystemException if any form I/O or other system error occurs during the parse, but application defined error handlers are not required to do so.

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, which is a DOM has-feature style string.

state of type boolean

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

Exceptions

DOMException

Raise a NOT_SUPPORTED_ERR exception When the DOMBuilder recognizes the feature name but cannot set the requested value. Raise a NOT_FOUND_ERR When the DOMBuilder does not recognize the feature name.

No Return Value

supportsFeature

query whether the DOMBuilder recognizes a feature name.
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. For example, a non-validating parser would recognize the feature "validation", would report that its value was false, and would raise an exception if an attempt was made to enable validation by setting the feature to true.

Parameters

name of type DOMString

The feature name, which has the same syntax as a DOM has-feature string.

Return Value

boolean

true if the feature name is recognized by the DOMBuilder. False if the feature name is not recognized.

No Exceptions

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 parseDOMInputSource method, or as the return value of the DOMEntityResolver.resolveEntity method.

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.

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

IDL Definition

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

Attributes

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 property. 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 values (utf-16 encoded characters).
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 (see section 4.3.3 of the XML 1.0 recommendation).
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 or text declaration of the XML, or an encoding obtained from a higher level protocol, such as http.

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.

systemId of type DOMString

The system identifier 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 open a connection to the URI 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 URL, it must be fully resolved.

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 property 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 URI types other than URLs.

DOMEtityResolver is based on the SAX2 EntityResolver interface, described at http://www.megginson.com/SAX/Java/javadoc/org/xml/sax/EntityResolver.html

IDL Definition

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

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 URL, the DOMBuilder must resolve it fully before reporting it to the application through this interface.

Note: See issue #4. An alternative would be to pass the URL out without resolving it, and to provide a base as an additional parameter. SAX resolves URLs 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 of the external entity being referenced.

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.

Exceptions

DOMSystemException

Any DOMSystemException, possibly wrapping another exception.

Interface DOMBuilderFilter

DOMBuilderFilters provide applications the ability to examine Element nodes as they are being constructed during a parse. As each elements is examined, it may be modified or removed, or the entire parse may be terminated early.

IDL Definition

interface DOMBuilderFilter {
  boolean            endElement(in Element element);
};

Methods

endElement

This method will be called by the parser at the completion of the parse of each element. The element node will exist and be complete, as will all of its children, and their children, recursively. The element's parent node will also exist, although that node may be incomplete, as it may have additional children that have not yet been parsed.
From within this method, the new node may be freely modified - children may be added or removed, text nodes modified, etc. This node may also be removed from its parent node, which will prevent it from appearing in the final document at the completion of the parse. Aside from this one operation on the node's parent, the state of the rest of the document outside of this node is not defined, and the affect of any attempt to navigate to or 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.

Parameters

element of type Element

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

boolean

return true

No Exceptions

Interface DOMWriter

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

Three options are available for the general appearance of the formatted output: As-is, canonical and reformatted.

• As-is formatting leaves all "white space in element content" and new-lines unchanged. If the DOM document originated as XML source, and if all white space was retained, this option will come the closest to recovering the format of the original document. (There may still be differences due to normalization of attribute values and new-line characters or the handling of character references.)
• Canonical formatting writes the document according to the rules specified by W3C Canonical XML Version 1.0. http://www.w3.org/TR/xml-c14n
• Reformatted output has white space and newlines adjusted to produce a pretty-printed, indented, human-readable form. The exact form of the transformations is not specified.

DOMWriter accepts any node type for serialization. For nodes of type Document or Entity, well formed XML will be created. 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 by the XML rec seems a bit much to take on here.

Within a Document 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 DOMWriter.writeNode(), output a Text Decl and the entity expansion. The resulting output will be valid as an external entity.
  No output is generated for any entity nodes when writing a Document.
• Entity References nodes are serializes 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 handled according to the "split-cdata-sections" option.
  If the option 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 option 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.
• All other node types (Element, Text, etc.) are serialized to their corresponding XML source form.

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, 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 &quot;. 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

Unicode Character Normalization. When requested by setting the normalizeCharacters option on DOMWriter, all data to be serialized, both markup and character data, is normalized according to the rules defined by Unicode Canonical Composition, Normalization Form C. The 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. The W3C character model and normalization are described at http://www.w3.org/TR/charmod/#TextNormalization. Unicode normalization forms are described at http://www.unicode.org/unicode/reports/tr15/

Name space checking and fixup during serialization is a user option. When the option is selected, the serialization process will verify that name space declarations, name space prefixes and the name space 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 exact form of the alterations are not defined, and are implementation dependent.

Any changes made affect only the name space 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 name space declarations or prefixes in the serialized output.

DOMWriters have a number of named properties that can be queried or set. Here is a list of properties that must be recognized by all implementations.

• normalizeCharacters
  true: Perform Unicode Normalization of the characters in document as they are written out. Only the characters being written are (potentially) altered. The DOM document itself is unchanged.
  false: do not perform character normalization.
  default: true.
  supported values: true: required; false: required.
• namespaceFixup
  true: Check namespace declarations and prefixes for consistency, and fix them in the serialized data if they are inconsistent.
  false: Perform no special checks on name space declarations, prefixes or URIs.
  default: true;
  supported values: true: required; false: required.
• split-cdata-sections
  true: Split CDATA sections containing characters that can not be represented in the output encoding, and output the characters using numeric character references.
  false: Signal an error if a CDATA section contains an unrepresentable character.
  supported values: true: required; false: required.

IDL Definition

interface DOMWriter {
           attribute DOMString        encoding;
  readonly attribute DOMString        lastEncoding;
           attribute unsigned short   format;
  // Modified in DOM Level 3:
           attribute DOMString        newLine;
  void               writeNode(in DOMOutputStream destination, 
                               in Node node)
                                        raises(DOMSystemException);
};

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 includes an encoding declaration, 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.

format of type unsigned short

As-is, canonical or reformatted. Need to add constants for these.
The default value is as-is.

lastEncoding of type DOMString, readonly

The actual character encoding that was last used by this formatter. This convenience method allows the encoding that was used when serializing a document to be directly obtained.

newLine of type DOMString, modified in DOM Level 3

The end-of-line character(s) to be used in the XML being written out. The only permitted values are these:

• 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 the XML Recommendation, http://www.w3.org/TR/REC-xml#sec-line-ends
• CR
• CR-LF
• LF

The default value for this attribute is null.

Methods

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

Parameters

destination of type DOMOutputStream

The destination for the data to be written.

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

Exceptions

DOMSystemException

This exception will be raised in response to any sort of IO or system error that occurs while writing to the destination. It may wrap an underlying system exception.

No Return Value