Document Object Model (DOM) Open Issues List

23 October 2001


This document is a "wish list" of enhancements to and concerns about the DOM that were not addressed in Level 1, Level 2, or Level 3. Note that the DOM Working Group has not committed to work on most of these points.

If you know of something that should be included here, please let us know so we can update the document. If you can provide a summary, and citations of past discussion, that would help the DOM Working Group a lot.

Comments on this document are invited and are to be sent to the public mailing list www-dom@w3.org. An archive is available at http://lists.w3.org/Archives/Public/www-dom/.

This document has been produced as part of the W3C DOM Activity. The authors of this document are the DOM WG members.

1. Deferred major functions

1.1 Views, Formatting

As raised by the CSS discussions. There may be multiple views of a document; access to data for each view. (Editor, for example, may have source and tree and rendered views active simultaneously. Might be aural etc.) Batching of events and minimizing reformatting costs plays into this. Also, accessing formatting results of applying style, after rendering (but not including the render itself). Presentation-specific. Partly a browser/engine-standardization issue; see what we've got that we can agree on. Browser users looking for standards beyond DOM Level 0. WAI wants selections/highlighting ideas, view-specific computed values from CSS (which is why abstract View went into CSS support -- but not Actual, i.e. final-rendered, values). Note that the XSL folks also want us to start incorporating XSL support.

Note: see also Document Object Model Level 3 Views and Formatting.

1.2 Transactions, batching of operations

E.g. roll-back if an operation fails. Database-style (failure) and/or editor-style (rollback). May have to be able to handle complex compound operations; may need to allow users to aggregate on top of that.

1.3 XSLT stylesheets and/or transformation support

Members of the XSL Working Group has strongly requested that we support XSL at least to the degree that we do CSS. On a simple level that isn't hard. It becomes much more complex if we attempt to allow mapping nodes in the generated Document back to nodes in the source, for selection and the like.

1.4 Repository interface

There is a significant amount of interest in providing tools to manage a group of documents within a repository. There is not yet a clear consensus on what a repository is or whether the DOM is the right place to define an API for accessing it. Jeroen van Rotterdam has proposed the following characteristics; they are included here for discussion, but the DOM WG has neither endorsed or rejected them. For example, one of the open questions in defining a repository is whether it contains "DOM Documents", XML documents, or simply documents which may be XML-based.

  1. A Repository should be able to contain several DOM Documents.
  2. A Repository should be able to contain a collection of Repositories which is a recursive structure much like directories in an operating system.
  3. A repository should be able to retrieve, add, delete or update DOM Documents
  4. A repository should be able to retrieve, add. delete or update its child Repositories
  5. A repository should be able to handle checking out and checking in of DOM Documents
  6. A repository should be able to hold a collection of DTD interfaces
  7. Every Document which is valid according to a DTD should be able to access its DTD from the collection of DTD interfaces of its corresponding Repository or any ancestor Repository.
  8. Repositories should be part of the DOM tree structure.
  9. Query languages should be able to execute their queries relative to a Repository node.

1.5 Query Language interface

More input desired from XML Querying Working Group. Known issues: query representation (string or object), response representation (iterator/treewalker?), and whether querying is a DOM API or a more general API that XML models, including DOMs, might implement. See also the "XPath Support" item later.

1.6 Multi-threading support

Old description: "Subclassing of objects is not supported at level 1. Higher order locking will not be included in level one. Question of how to have some people with read access at the same time as others have write access while maintaining predictable results across implementations. Minutes of 19971003 talk about handling concurrency problems in level two."

1.7 Security

From DOM requirements (October 9, 1997 version) document: "an external security API will be provided after level one." Unclear whether this means digital signatures, protecting an in-memory DOM fragment from being written out to storage, controlling document-to-document scripting access, or other.

1.8 Additional event sets

Sense-of-the-group is that we'd like others to design these, but we may want to "bless" some of the most critical ones.

2 Individual Issues and Enhancements

2.1 Lightweight DOM

Sometimes called "server DOM", this is intended to be a "core of the core" subset, reducing power but gaining performance/efficiency.

2.2 isReadOnly test

It might be useful to have the opportunity to test whether a node is currently readonly or not, without having to attempt to modify it and catch the resulting exception or modify it back. Proposed solution: adding an isReadonly flag to the Node interface.

2.3 Read-only DOM

There have been requests for a way to make part or all of the DOM tree read-only. One use case would be when an immutable data structure wishes to permit users to view its contents via a DOM API. Another would be if a standard DOM was to be used to present a document that the users should not be permitted to alter. The latter state might be either transient or permanent.

For example: XSLT's extension mechanism wants to expose the source document via the DOM API, but does not want to permit extensions to alter that document... even if the input was provided as a read/write DOM.

2.4 Enhance Traversal to merge adjacent Text Nodes

Ability to traverse a normalized view of an un-normalized document. Same issues as "Text Node Amelioration"

2.5 Should NodeIterator be cloneable>

Since NodeIterator doesn't have the ability to setCurrentNode, saving and reusing an iteration state is difficult; one has to create a new iterator, then step it until it reaches the right place. The suggestion has been made to add NodeIterator.clone().

2.6 Pseudo-attributes on Processing Instructions

While the value of a processing instruction is defined by XML as being an unstructured string, one approach to using that to contain multiple parameters is to borrow XML's Attribute syntax. If this turns out to be a common usage, the DOM might want to facilitate it.

2.7 Attr.getValue() containing unresolved EntityReference

As of DOM2, what should happen in this case is undefined. The definition of Attr.getValue() refers to the "value" of the EntRef -- but EntRefs have no node value.

2.8 getElementsByAttributeValue()

getElementsByID() has been added to DOM Level 2, but evaluating this depends on DTD support (non-DOM, in Level 2) to determine what attributes are or aren't IDs. It was suggested that for non-validated documents or other situations where the document's author didn't declare the attribute as ID, we offer a lookup by attribute value (falling back on the possibly-optimized ID retrieval when possible). There is some sense that this more general search might be independently useful even if it can't be optimized.

2.9 Allow event to suppress capture phase

Level 2 allows us to turn off bubbling of events (by setting "bubbles" to false), but there is no corresponding capability to suppress capture on an event-by-event basis. In the public list, John Ky has suggested that there are times when this would be desirable. While it is certainly possible to simply not register any Capturing listeners, and a sufficiently clever implementation may be able to avoid spending cycles on the Capture phase unless listeners exist which need it, it may be useful to be able to say "This specific event really is intended specifically for the stated Event Target and should not be captured."

2.10 Make TreeWalker attributes writable

Since TreeWalker follows strict current-node semantics, it could arguably be made safe to alter its filter, whatToShow, or even root node properties. Miles suggests this as an alternative to generating/maintaining multiple TreeWalkers. We currently recommend against this change; it seems to have significant risk for minimal benefit:

2.11 Iterator.beforeFirst()/afterLast()

Quick reset to initial/final states. See last paragraph of http://lists.w3.org/Archives/Member/w3c-dom-ig/1999Aug/0088.html and follow-ups.

2.12 Diamond inheritance proposed

Architecturally, many (not all) of the additional interfaces added in DOM Level 2 should inherit from the base classes that will implement them -- for example, DocumentTraversal should inherit from Document -- to document and enforce that association, and to avoid unnecessary typecasting. This introduces "diamond inheritance" (B is-an A, C is-an A, D is both a B and a C), which was a problem for some object-oriented languages.


The OMG wants a way to represent XML content as a datatype... with or without "data binding" to application-specific datatypes. The request, and proposals, should be available at http://www.omg.org/techprocess/meetings/schedule/XML_Value_RFP.html.

At least one proposal based on the DOM API has been submitted. Essentially, this provides an IDL binding for the DOM which emphasizes access to local documents.

2.14 I18N Indexing

The DOM is currently expressed as storing data in 16-bit "units". Unicode permits characters longer than this, via diacritics and so on. The I18N folks requested that the DOM provide mapping between character-offsets and unit-offsets for text we have stored. We seem to agree that there's a legitimate need to do this, but have doubts about whether it's an operation that should be defined by and within the DOM.

2.15 Encoding support

The DOM is currently expressed as storing data in UTF-16. Some annoyance has been expressed with the need to convert data from an environment's native string encodings into this one, especially when there may be multiple encodings within a country (EBCDIC and ASCII, several Japanese encodings, etc.)

2.16 Non-Well-Formed Entities

Currently createDocument can only be used to create an XML document with a single Document Element. Some applications want to use the DOM to create a text document, or an external parsed entity, not contained in a single root. Essentially, they would like to broaden the concept of "document".

Use case: XSLT is now able to output things other than well-formed XML. Our own spec, with non-XML bindings generated from XML, is an example of that sort of processing. It would make a certain amount of sense for the DOM to be able to capture XSLT's output even in this case.

2.17 Visitor design pattern

We get periodic requests to implement the Visitor pattern [Design Patterns, 1994, Gamma et al].

Visitor is a standard object design which allows you to execute a unique method based on two object types. This is known as "double-dispatching". The intent in this case would be to execute different code based on the combination of a specific Node subtype and a specific Operation type. (The Operation would correspond to the Visitor).

In order to synthesize double-dispatching in a language that only supports single-dispatching (e.g. C++, Java, Perl) a method must be defined in the Operation interface which corresponds to each Node type, and each Node must implement an Accept(Operation) method which invokes the appropriate support method.

2.18 Error reporting

A list of error codes could be developed for USLs and other languages that don't support exceptions

2.19 Meta data

"For level 1, just have all meta data be of type string/UTF-8 (for the 5 minimal things), but the type system must be extensible in the long run. Level two will have more on meta data."

2.20 URis and systemIds

(from David Brownell's list.)

For nodes exposing a SystemId, there are cases where it needs to be a fully resolved URI; and there are cases where it needs to be unresolved.