Introduction

The comments have been divided into modules. Comments received which indicate misspellings in the text, or requests for clarification, are not necessarily in this disposition of comments, but were fixed. Most of the requests for clarification which uncovered divergence or misunderstanding are listed in this disposition of comments, some pure misunderstandings were cleared up in email. The comments are listed in no particular order.

1. Core

Issue Core-1:

ownerElement method of Attr means that attributes cannot be shared.

Resolution:

Attributes can't be shared anyway because of the way that Level 1 was specified. And adding a way to get from an attribute to the associated element was a requirement from various groups, such as XSL.

Issue Core-2:

There is no way any way to create an Iterator from a NodeList or NamedNodeMap.

Resolution:

This is correct. The major use cases that the WG can see for this are already covered by the Traversal module, so we don't consider this to be necessary at this stage. We can always add it later if use cases are described that need it.

Issue Core-3:

All methods that return NodeList should be deprecated and replaced by methods that return an equivalent Iterator.

Resolution:

The DOM WG discussed the entire NodeList/NodeIterator subject for Level 1 and made the decision to use NodeLists after consideration of all the issues. There is no wish to deprecate Level 1 in this way. This issue seemed to arise for technical reasons, and members of the DOM WG feel that sufficiently clever implementations get rid of any technical problems.

Issue Core-4:

DTDs are not modelled.

Resolution:

They will be modelled in Level 3.

Issue Core-5:

A server-side DOM would be a good idea.

Resolution:

We first need to investigate what this really means.

Issue Core-6:

DOMImplementation::hasFeature should enumerate all the possible values for feature.

Resolution:

Good idea. We have added this to the introduction.

Issue Core-7:

The DOM specification should state that only a particular range of values for exception types and node types will be used by the DOM, so implementations can add their own without clashing.

Resolution:

On the surface, this sounds like a reasonable request. However, the DOM WG considers that it is dangerous to encourage people to add new node types to the tree. We have not yet seen a use case that can't be implemented in some other way, generally by adding custom attributes to an existing node type. For exceptions, the implementation that needs other exceptions should define its own exception class to do this. Thus there will be no clashes with the DOM exceptions, which are well-defined. Runtime exceptions, of course, can always be used. The DOM specification now states specifically that other numeric values are reserved for future DOM use.

Issue Core-8:

setAttributeNS call should have qualifiedName as input parameter to be consistent with createAttributeNS.

Resolution:

We will make this change.

Issue Core-9:

How should other groups define a hasFeature string?

Resolution:

Other groups should define and use a prefix. The DOM specification won't use a prefix, therefore anything with a prefix is done by others.

Issue Core-10:

How does an application know it can work with DOM Level 2 features?

Resolution:

The hasFeature method has a version number on it. Since most of the Level 2 modules are optional, applications need to see if the module they're interested in is implemented.

Issue Core-11:

importNode doesn't sound right.

Resolution:

Discussed this again; copyNode didn't seem to have the right semantics either and we couldn't come up with a better solution that matched Level 1 usage, so we're keeping importNode.

Issue Core-12:

Document ... refers to "invalid" characters. "Illegal" would be more correct (with reference under DOMException to XML, HTML, and related specs for what that means). Of course the INVALID_CHARACTER_ERR name is grandfathered...

Resolution:

Changed the description of INVALID_CHARACTER_ERR to reference the XML spec, and changed "invalid" to "illegal" where appropriate.

Issue Core-13:

The description of "Document" should also say that there may only be a maximum of one DocumentType; it's not just true for Elements.

Resolution:

Fixed.

Issue Core-14:

DOMImplementation.createDocumentType ... the more I look at it, the less I like the notion that the document type be associated with some document "late" in the game. Every node in the doctype then needs to be able to get coupled "late" to an owning document, rather than being so coupled from day one. That basically means every type of node in the whole DOM, not just DocumentType, may need to work with a null ownerDocument. Yuck.

One patch is to have DocumentType.getEntities/getNotations be able to throw an appropriate exception if they're called without having the DocumentType bound to a document yet; that eliminates all the cases where nodes (perhaps many, many, many of them!) will need to be patched up or try to lie about their owner document. Of course all that still leaves open the question of when contents get stuffed into a DocumentType object. Though construction seems to be out of scope for DOM, the spec does need to ensure there's a workable answer. And I don't clearly see one now, unless it's to stick to the DOM L1 model without the DocumentType special cases.

Resolution:

We agreed not to allow addition or removal of a DocumentType node from a document. A newly created DocumentType can only be used for creating a new Document.

Issue Core-15:

Node.cloneNode ... clones are always mutable, yes? Needs stating; else a conformant implementation couldn't support the process that was outlined with Entity nodes (mutating clones of readonly nodes).

Resolution:

Clarified by adding "Note that cloning an immutable subtree results in a mutable copy".

Issue Core-16:

NamedNodeMap.*ItemNS ... what should this do when being used to access items (notations and entities from the DTD) that aren't scoped with namespaces? How about if the namespace URI is null?

NamedNodeMap.setNamedItemNS ... no such method; why? Everywhere else there are both namespace-naive and namespace-aware methods, but this one (very important!) case is omitted.

NamedNodeMap.removeNamedItem ... should be able to report an error (NO_MODIFICATION_ALLOWED_ERR) for readonly maps, just like the setNamedItem method.

NamedNodeMap.item ... negative indices should return null too.

Resolution:

If the *ItemNS methods are used to access items that aren't scoped with namespaces, they should return null. If the namespace URI is null and the prefix isn't xml or xmlns, it's an error to use the *ItemNS methods. We added setNamedItemNS. removeNamedItem should indeed throw an exception when you try to remove a read-only item; thanks for catching this bug. Negative indices are not valid, so NamedNodeMap.item does return null for negative values of item.

Issue Core-17:

DocumentType ... please change the "publicID" and "systemID" to match the case ("Id" not "ID") in Notation and Entity nodes.

Resolution:

Fixed.

Issue Core-18:

Need a getElementByID method.

Resolution:

Added.

Issue Core-19:

Need a way to add user-defined data to nodes.

Resolution:

The DOM WG agrees, but hasn't yet been able to come up with a design that doesn't have a lot of pitfalls.

Issue Core-20:

DOM level 2 should provide better support for ID attributes. This could be done by

• creating a new constant for the whatToShow attribute of the nodeIterator interface called SHOW_ELEMENT_WITH_ID, or
• adding a required iterator+filter to the document and documentFragment interfaces.

• Also, some method such as "getElementByID()" should be provided on the document and documentFragment nodes.
• Also, some method such as "setElementID()" should be provided on element nodes.

Resolution:

Added getElementByID to Document node. We would need a good use case for the DocumentFragment node (or other nodes), since the cost could be high. After discussion we decided to defer the others until we do full DTD support in Level 3.

Issue Core-21:

DOM level 2 should not require lexical-checking for URIs, system and public identifiers, and XML names, except at some user-supplied option.

Resolution:

Currently the DOM Level 2 does not check whether URIs, system or public IDs are legal (this will be part of Level 3), though those strings defined to be XML Names are expected to be checked.

Issue Core-22:

How does one access the XML declaration?

Resolution:

This was a bug in Level 1 that now will take some time to fix, since different DOM Level 1 implementations model it in different ways (e.g., as a PI, or not at all). We will be modelling the XML and text declarations in Level 3.

Issue Core-23:

Am I correct to assume that when splitText() is called on a CDATASection node, the return value (new node created) should be a CDATASection node rather than a simple Text node? Should this be noted in the spec?

Resolution:

Correct. Fixed the spec.

2. HTML

Issue HTML-1:

You should state that the following are 0-based (if they are):

• HTMLOptionElement::index (which makes a few other things 0-based since they refer to it, i.e., HTMLSelectElement::selectedIndex and the index argument to HTMLSelectElement::remove())
• HTMLTableCellElement::cellIndex
• HTMLTableRowElement::rowIndex
• HTMLTableRowElement::sectionRowIndex

Resolution:

They are 0-based (as are all indexes in the DOM). Fixed the spec to add this.

Issue HTML-2:

Does the DOM2 HTML not guarantee interoperability when the strict DTD is used?

Resolution:

Changed the wording to "Interoperability between implementations is only guaranteed for elements and attributes that are specified in the HTML 4.0 DTDs." to clarify that all the DTDs defined in HTML 4.0 are meant.

Issue HTML-3:

2.5.1 - What happens if the attributes are unspecified and they have no default value? I assume "" for those that are DOMString, but what about boolean and number?

Resolution:

Boolean should return false, since the attribute has not been set. Number returns a default of 0.

Issue HTML-4:

2.5.1 - In the table, "e. g., border" is very misleading for the one-value value list example. There is no boolean border attribute. How about "e.g., disabled"?

Resolution:

Good catch. We changed the example (which dated from an older draft version of the specification).

Issue HTML-5:

2.5.4 - These elements are missing the X'ed attributes, and thus aren't really fit for HTMLElement (at least in 4.0 Strict):

          T C
          I L L
          T A A D
        I L S N I
  Attr. D E S G R
Elem.
BR            X X
PARAM     X X X X
HR            X X
HEAD    X X X
TITLE   X X X
BASE    X X X X X
META    X X X
STYLE   X X X
SCRIPT  X X X X X
HTML    X X X

Resolution:

Since there's nothing that precludes the modification or access of these attributes (or any other attribute) for an arbitrary element, the conveniences provided in HTMLElement translate to setAttribute() and getAttribute() calls for these elements.

Issue HTML-6:

HTMLSelectElement::add() - what happens when element is not an HTMLOptionElement? when before is not in the list? can element be an HTMLOptGroupElement? can before?

Resolution:

Since the DOM doesn't enforce HTML validity, the method does not throw an exception if the element is not an HTMLOptionElement. The method is equivalent to Node::appendChild() on the HTMLSelectElement if before is NULL. It is equivalent to a Node::insertBefore() on the parent of before for any type of element. The method should throw a DOMException with error code NOT_FOUND_ERR if the before parameter is not a descendant of the HTMLSelectElement. We added the relevant prose and the exception to the IDL for the method

Issue HTML-7:

The definition of HTMLTextArea::defaultValue doesn't explicitly say that changing the defaultValue changes the child text Node of the element. I think it should, to be equivalent to the defaultValue, defaultChecked, and defaultSelected attributes.

Resolution:

Added "Changing this attribute changes the contents of the form control, but does not change the contents of the element. " to clarify.

Issue HTML-8:

How does HTMLTableCellElement.cellIndex deal with rowspans and colspans? That is, is it the child number of the cell within its row or is it the column where the cell starts? Similarly, how does rowIndex treat TFOOT? Does it give the index in document tree order or display order?

Resolution:

The cellIndex is the child number of the cell within its row in document tree order. The rowIndex attribute is the index in document tree order. We made this more explicit.

Issue HTML-9:

Similarly, what exactly do the index parameters in the following functions mean:

 * HTMLTableElement::insertRow
 * HTMLTableElement::deleteRow
 * HTMLTableSectionElement::insertRow
 * HTMLTableSectionElement::deleteRow
 * HTMLTableRowElement::insertCell
 * HTMLTableRowElement::deleteCell

Resolution:

The HTMLTableElement methods: The index is relative to all TR elements in the table in document order, regardless of the existence or absence of table sections. The HTMLTableSectionElementMethods: The index is relative to all TR elements in that table section in document order. The HTMLTableRowElement methods: The index is relative to all TD and TH element in that table row in document order.

Issue HTML-10:

Also, the following fixed error should probably be added to the DOM1 Errata (I was working on a list of DOM1 errors): HTMLOptionElement::selected should not be readonly. I think this is clear from the prose in the errata, but it should be stated for those using the IDL

Resolution:

Correct. We fixed this.

3. StyleSheets

Issue Style-1:

If no media are specified, what is the media attribute? I suggest it be created automatically with one item: "all". If not, then it could have length 0 and cssText of "". I think making it null would be a bad idea.

Resolution:

The MediaList could be empty : 'An empty list is the same as a list that contains the medium "all".'

Issue Style-2:

How do media and disabled interact?

Resolution:

A stylesheet only applies if both an appropriate medium definition is present and the disabled attribute is false. So, if the media doesn't apply to the current user agent, the disabled attribute is ignored.'

Issue Style-3:

MediaList has a property: cssText StyleSheet has a property: media. I understand that both must belong to the style sheet dom and not the css dom; yet the MediaList property 'cssText' breaks the implementation independent nature of the stylesheet DOM.

Resolution:

cssText has been renamed to mediaText.

4. CSS

Issue CSS-1:

CSSStyleDeclaration::cssText shouldn't have "{" and "}" since it is used for HTMLElement::style. Thus "including" should be changed to "excluding" in CSSStyleDeclaration-cssText

Resolution:

Correct.

Issue CSS-2:

There are messy issues with the border-color property. See http://lists.w3.org/Archives/Public/www-style/1999Sep/0082.html http://lists.w3.org/Archives/Public/www-style/1999Sep/0085.html

Resolution:

The border-color gets its value from the color property when the border property doesn't contain a color, but the value of the color is the _specified_ value of the color property and not the value in the style sheet. Since we don't compute the inheritance in the CSS OM (except for the computed style declaration), the border color should be empty. We can't invent a new value for this case. The border-color will be only effective in the computed style but the specified style will give you an empty string.

Issue CSS-3:

I think the following statement in CSS2Properties is unnecessary because the special system font shorthand values *can* be decomposed (and must, since some of the equivalent longhand properties can be changed, leaving others intact). I think it should be removed: "If the value of a shorthand property can not be decomposed into its component longhand properties, as is the case for the font property with a value of "menu", querying for the values of the component longhand properties should return the empty string." Furthermore, I think it would be good if CSS2Properties explicitly said that querying a longhand property when a corresponding shorthand property has set the value of that longhand property should return the appropriate value rather than the empty string. That seems to be implied, but not clearly so.

Resolution:

For these issues, the DOM WG decided to leave the spec as it is. The special system font shorthand issue is: "system fonts can only be specified with this property, not with 'font-family' itself, so 'font' allows authors to do more than the sum of its subproperties." You can't set a longhand font property to a system value. And if we allow returning a system value on a longhand font property, then the following example will throw an exception if the shorthand font property (on myElement2) has a system value: myElement1.style.fontSize = myElement2.style.fontSize;

5. Events

Most of the comments were for clarification; these have been made, even if they're not listed here.

Issue Events-1:

In 6.6.2, UIEvent::detail in relation to mouse events seems vague. What is it for the mouseup and mousedown? When is it incremented, exactly?

Resolution:

Added "The detail attribute inherited from UIEvent indicates the number of times a mouse button has been pressed and released over the same screen location during a user action. The attribute value is 1 when the user begins this action and increments by 1 for each full sequence of pressing and releasing. If the user moves the mouse between the mousedown and mouseup the value will be set to 0, indicating that no click is occurring. "

Issue Events-2:

In 6.6.2, what do the different values of button mean?

Resolution:

Added "The values for button range from zero to indicate the left button of the mouse, one to indicate the middle button if present, and two to indicate the right button. For mice configured for left handed use in which the button actions are reversed the values are instead read from right to left."

Issue Events-3:

In 6.6.3, keyCode and charCode are listed in the "Context Info" for all event types, but nothing else is listed in the "Context Info" even though other things are valid.

Resolution:

The key event set will be provided later.

Issue Events-4:

The meaning of relatedNode on the mouseout Mouse Event should be explicitly stated. My guess is that it should contain the node into which the mouse has moved. However, this node may or may not be receiving a mouseover event because of that movement (i.e., it won't if it's the parent). Should it be null in those cases?

Resolution:

Added "Currently this property is used with the mouseover event to indicate the Node which the pointing device exited and with the mouseout event to indicate the Node which the pointing device entered."

Issue Events-5:

what is the point of MutationEvent::relatedNode? The only thing it is used for duplicates event.target.parent. (It could be more useful if it were used for more of the events, I think.) Or are there some things missing in "Context Info" sections? (It seems that this is the case from the description of relatedNode.)

Resolution:

Added "For example, if a mutation event is dispatched to a node indicating that its parent has changed, the relatedNode is the changed parent. If an event is instead dispatch to a subtree indicating a node was changed within it, the relatedNode is the changed node. "

Issue Events-6:

When are mousemove events fired? If the mouse moves while it is over a p (pElem) inside a div (divElem) inside body (bodyElem), do you get three mousemove events (one with event.target==pElem, one with event.target==divElem, and one with event.target==bodyElem) or just one on the most deeply nested element? Having three can be useful for out-of-flow children, but that's a lot of events (especially with bubbling), so I'm not sure if that is what is meant.

Resolution:

Added "In the case of nested elements mouse events are always targetted at the most deeply nested element. Ancestors of the targetted element may use bubbling to obtain notification of mouse events which occur within its descendant elements." to clarify.

Issue Events-7:

If an event is at the target, are both capturing and non-capturing event listeners called? Is event.eventPhase AT_TARGET in both cases?

Resolution:

Added "A capturing EventListener will not be triggered by events dispatched directly to the EventTarget upon which it is registered." The definition of AT_TARGET is "The event is currently being evaluated at the target node." so the eventPhase is AT-TARGET.

Issue Events-8:

Is the order of events for keypresses: keydown, (keypress,)* keyup, keypress Or is it: keydown, [ (keypress,)+ keyup | keyup, keypress ] Or is it UA-dependent? I think this should be explicitly stated (even if it's UA-dependent).

Resolution:

The key event set will be provided later.

Issue Events-9:

In what order are onmouseout/onmouseover fired when the pointer moves simultaneously out of one node and into another? What about when it moves simultaneously into two nodes (parent/child) or out of two?

Resolution:

Moving out of a node happens before moving into the next node, so that determines that order. Since mouse events only apply to the most deeply nested element (the child node), there is no "simultaneous" moving into or out of parent/child nodes.

Issue Events-10:

Are the ECMA bindings for {add,remove}EventListener correct? Should it take a function pointer or an EventListener object?

Resolution:

EventListener is an ECMAScript function reference.

Issue Events-11:

The DOM Event system needs to be able to hold onto multiple named groups of listeners to be able to independently handle events for a single document with multiple views.

Resolution:

This would provide useful functionality that the model can benefit from. However it is possible to add this functionality in a later version of the DOM and it requires deeper discussion so this will not be added to this spec for Level 2.

Issue Events-12:

The DOM EventListener interface should instead be a typed grouping of events (i.e. all mouse events grouped into a single typed mouse event listener interface). This would improve compatibility with Java and potentially improve performance in the case of multiple listener registrations.

Resolution:

The EventListener interface was chosen to allow the greatest language neutrality. Many scripting languages do not have interfaces and while a mapping of an interface with a single method into these languages is easy, mapping multi-method typed interfaces is hard. In addition, the non-typed EventListener interface provide for simple expansion of support event sets.

Issue Events-13:

6.2 It appears that there's no way to guarantee that an ancestor will get an event -- both capturing and bubbling permit other nodes to interfere with event reporting. This seems ungood in general; there ought to be _one_ mechanism whereby event reporting isn't subject to interference.

Resolution:

The best current answer to that need is to have the target node's event handler (which can't be blocked) or a capture handler on the tree's root (which ought to run before capturing gets turned off) respond to the event by sending out a separate custom event which, presumably, nobody else is going to discard before your "unblockable" handlers hear it. This is entwined with issue Events-11: named listener groups (or some such solution) may address some of the concern about unintended cancellation.

Issue Events-14:

6.3.1 I'm curious in general why EventListener.handleEvent() is defined to handle _all_ events rather than having separate interfaces that directly handle the different sorts of events (a MouseEventListener, MutationEventListener, etc). That's how Swing does this stuff, and it's generally handy to have such "pre-dispatched" frameworks -- it can be faster, too!

Resolution:

Swing can get away with this because Swing doesn't attempt to pass generic events; specific events are tied to specific registration calls and specific listeners. Since we intend to let application-specific events pass through our engine, we can't really hardcode event types into the dispatch/listener APIs.

Issue Events-15:

6.2.2 Event capture ... the text is unclear what preventCapture() achieves. The third para says that if you call it, no further targets lower in the tree will get events, which seemingly includes both the "deliver to target" phase (which is elsewhere said to be "guaranteed") and event bubbling. It makes sense to me to see the preventCapture() method only have effect during the capture phase. If so, its description in 6.2.2 needs updating (no further targets will capture).

Resolution:

We reworked the whole "prevent" method group, replacing it with the new stopPropagation method .

Issue Events-16:

6.6.4 DOMSubtreeModified ... insufficiently specified. What event batching is supposed to be performed? In what sense may it be used "instead of the more specific events"? And for that matter, which "more specific events"? I couldn't make any sense of this description at all. And there was the hint that it's another one of those really expensive events (like DOMNode**Document) noted below ...

Resolution:

the intent is that any document mutation generates its specific event and also "eventually" triggers this event... but there may not be a 1:1 relationship. If you take a node that's already in the tree and give it a new parent (which is a removal plus an insertion, each generating its own event), the hope is that a sufficiently clever DOM might generate only a single DOMSubtreeModified message for the combined operation, sent to the lowest common ancestor of the old and new parents. It's hoped that this might reduce the load if "realtime" response is not required. The definition of "sufficiently clever", and what granularity the batching occurs on, have been left to the implementation

Issue Events-17:

6.6.4 DOMNodeRemovedFromDocument ... seems horrendously expensive. After delivering an DomNodeRemoved event, that node and all of its descendants (!!!) get one of these. Must this really be done? It'll increase the cost to support the mutation events substantially.

Resolution:

There were a few use cases advanced where folks had active processes associated with nodes, which only wanted to run while the node was part of the Document. All we can suggest is not dispatching these unless there's a listener for them.

Issue Events-18:

6.6.4 DOMNodeInsertedIntoDocument ... correspondingly expensive. General There's no way for applications to define their own events and thus use the event mechanism for any purpose except those that are built in. I'd like to see such a standard, perhaps part of the basic "Events" mechanism. In the same way that DOM events all have "DOM" prefixes, perhaps they could have a "USER." prefix. And it'd be desirable for such user events to have a way to include information ... maybe a UserEvent interface could have an Object parameter set in its initUserEvent() method, which has application defined semantics.

Resolution:

See above issue.

Issue Events-19:

Events ordering is largely undefined and the spec should make this clear.

Resolution:

The spec now says: "Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget."

Issue Events-20:

MutationEvents in 6.6.4 ... consider a Document, with one Element. That Element has an Attr object which has one child, a Text node. Now let's say that text node gets modified. What events will fire?

In the Attribute's tree
	- DOMCharacterDataModified, delivered to the text node
	- DOMSubtreeModified, delivered to the attribute

   In the Element's tree
	- DOMAttrModified, delivered to the element
	- DOMSubtreeModified, delivered to the element

SUGGESTION: The text should make clear that a document isn't the only example given of the "top of a subtree". DocumentFragments and Attributes, plus disconnected elements, are other common cases.

Resolution:

The events listed are correct, and bubbling and capturing do apply. "Subtree" refers to any subtree within the document; if there were a restriction we would detail what it is.

Issue Events-21:

The listener that actually handles the event invokes the ::preventBubble() method on the event to prevent it from bubbling upwards and causing unneeded redisplay. However, in the current DOM2 spec, this method prevents bubbling in _all_ attached listeners. Thus, it's entirely plausible that you'll have two views with different patterns of attached listeners. The one that handles the event lower in the tree will prevent the event from bubbling up to the correct level in the other one, thus resulting in a missed update.

Resolution:

It's correct that to fully use an MVC model would require an extra feature in the DOM event module, namely the use of event groups. This is, however, a specific application of the model and we don't think the problem will affect everyone using the events module. The DOM WG likes the idea of making this addition, which can be made on top of the current model, but is wary of adding more at this late stage before the basic events framework has been more widely implemented and tested.

6. Traversal

Issue Traversal-1:

A Document should be able to import a TreeWalker.

Resolution:

We haven't yet had a use case to make this necessary. If we find one, we can easily add this later.

Issue Traversal-2:

The semantics of nextSibling on TreeWalker are unclear if the next sibling exists but does not match the filter criteria.

Resolution:

Changed to "If the current node has no next sibling, returns null, and retains the current node. " to clarify.

Issue Traversal-3:

Consider the consequences if Iterator and TreeWalker added the following methods derived from attributes of the reference Node:

	unsigned short getNodeType()
	DOMString getNodeName()
	DOMString getNodeValue()
	NamedNodeMap getAttributes()
	NodeIterator getAttributeList()
	DOMString getNamespaceURI()
	DOMString getPrefix()
	DOMString getLocalName()

Resolution:

Implementations are free to add such methods if they choose.

Issue Traversal-4:

Why doesn't the Traversal spec use the Visitor pattern?

Resolution:

The question was brought up, but not strongly motivated. And the Traversal team had its hands full; robust tree iterators with user-provided filtering are a surprisingly difficult design problem. The fact that we can't prevent the users from changing the state of the universe within the filter wasn't the largest challenge, but it didn't make life easier. Note that Gamma et al does list negative as well as positive consequences of implementing a Visitor. One of Visitor's advantages over Iterator is that Visitor can handle structures where the objects don't share a common ancestor class, which is not an issue when everything you're looking at is derived from Node. This might be worth revisiting in a future level of the DOM. Meanwhile, it looks like most of the things a Visitor could do can be emulated with a switch statement driven by an iterator, so we think we're safe in deferring it.

Issue Traversal-5:

Delete the words "simple and efficient" from the description.

Resolution:

Done

Issue Traversal-6:

Motivate liveness

Resolution:

This was a design decision, to provide an iterator that is robust to changes.

Issue Traversal-7:

Put explanations of how the iterator moves in terms of the reference node, and not "betweenness".

Resolution:

Clarified more in terms of the reference node, though the position is still considered to be between nodes.

Issue Traversal-8:

Add a new method to NodeIterator (and TreeWalker) which is defined more or less as follows: void finished () Marks the traversal object as no longer needed, permitting the DOM to release all resources that are associated with it. Subsequent calls to nextNode and previousNode() will report an exception.

Resolution:

We added a method called detach with this functionality. Also added it to Range.

7. Appendix

Issue Appendix-1:

Java Binding ... I REALLY think it'd be useful to define a standard way to get access to a DOM implementation, so that only parser connectivity really needs to be left to nonstandard APIs.

Resolution:

The simple way to solve this problem didn't fit enough scenarios, and it quickly became obvious that the complete solution was going to take a lot of time.