- From: Mike Champion <mcc@arbortext.com>
- Date: Mon, 9 Mar 1998 09:12:51 -0500
- To: Andrew n marshall <amarshal@usc.edu>, "W3C DOM List (E-mail)" <www-dom@w3.org>
At 11:27 PM 3/8/98 -0500, Andrew n marshall wrote: > >Thanks to all who replied to my last batch. The following is just a need for >some clarifications: > > * Is the NodeEnumerator of a "live" NodeList, such as getChildren, also >considered "live"? After 6 months of arguing back and forth, getChildNodes (the *new* getChildren) returns a NodeIterator (the *new* NodeEnumerator). So, there are no more node lists, live node lists, editable node lists, etc., only NodeIterators. The compromise is to allow NodeIterators to have various "array-like" methods that let you randomly access nodes by the "position" in the enumeration at which they would lie, and to allow them to be accessed by name via the iterator. NodeIterators are always "live" in the sense that they instantly reflect all changes to the tree, and the Nodes returned from a NodeIterator may be used to modify the tree. > * Is an empty NodeList a valid response to getChildren for a Node that has >no children (instead of null)? Hmmm. I can't remember our previous position on this, but it is now moot. getChildNodes will return a non-NULL iterator, which itself will always return NULL when accessed. But as I said above, if someone added a Node that WOULD be a child AFTER the iterator was created, calling toNext on the iterator would return the new child. Sorry for all the changes to the core model, but I hope you understand how these little details were bedeviling us, and fundamental changes seemed like the best solution. Mike Champion
Received on Monday, 9 March 1998 09:14:12 UTC