Re: Walking the DOM (was: XML APIs)

Claude Zervas wrote:

> Again, I think that in light of all the severe disagreements about
> NodeList 'liveness' and iterator behaviour there should be a branching
> of the spec for applications that are not designed for naive script
> writers and where performance is of foremost importance.

I think this is a bad idea, but I won't go into my reasons now,
except to say "If the DOM isn't interoperable it's nothing."

> This 'server-or-whatever' DOM would have at least the following
> characteristics:
> 
> 1. NodeLists do not need to be 'live'

I understand the motivation for this.  But if you have real iterators,
then the only NodeList whose liveness is at all expensive is that
returned by getElementsByTagName.  Better to just deprecate this
in favor of the obvious iterator and trivial visitor.
 
> 2. Node.Next/PreviousSibling attributes are deprecated or are simply
> convenience methods that may (or may not) be horribly slow.

Why?  My (nascent) DOM implementation is based on explicit
next and previous pointers, with no explicit arrays containing
children.  The getChildren NodeList returns the node itself (or
a trivial wrapper, in some cases), and caches the most recently
retrieved child for the sake of people who use a for-loop to
iterate over the NodeList.
 
> 3. Iterators are introduced and provide behaviour that may
> be undefined if the tree is modified underneath them.
> I would also be ok with the idea that the iterators simply
> throw an exception if the tree is mutated.

I prefer the second idea.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan@ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)

Received on Wednesday, 4 November 1998 10:00:15 UTC