Re: XML APIs

John Cowan <cowan@locke.ccil.org> writes:

> Stephen R. Savitzky wrote:
> 
> > It's actually rather easy to implement TreeIterator using the various
> > parent, child, and sibling attributes of Node.  It is also trivial to
> > implement a NodeIterator for the children of a node.
> 
> In such a way as to be robust against arbitrary adds, deletes, and
> moves in the tree?  Enlighten us, if you would.

This points out _precisely_ the problem that the people working on the DOM
spec seem to have.  You want node lists, iterators, and so on to do ``the
right thing'' in all possible circumstances -- deletions, additions, moves,
multithreading, and so on.  The problem is that ``the right thing'' varies
with the use you're putting the thing to.

Nodelists want to be ``live'' when you're executing Javascript inside a
browser and you want to start executing the script while the document is
loading.  Never mind that using getNextSibling would be more appropriate.
Under _all_ other circumstances, nodelists that behave like static arrays
are more useful.  Under _all_ circumstances, node arrays are more efficient,
more predictable, easier to understand, and easier to implement.

Simple iterators that keep track of the current node and perform a
depth-first left-to-right traversal are useful, efficient, and predictable
when used for tree traversal, searching, and so on.  They behave
_predictably_ when the tree is modified during an iteration; whether this
behavior is ``correct'' or not depends entirely on what the programmer has
been led to expect.  Iterators that keep track of both the current node and
the ``next'' node in the traversal work better for deletion, but have to be
more careful about insertion.  It's perfectly acceptable, in my opinion, to
state that the behavior of an iterator or a nodelist is undefined under
certain circumstances, or to provide multiple iterator types for multiple
purposes.

At this point I'm probably going to stop hoping that iterators get back into
the DOM at some point, and instead count on programmers to design
appropriate classes of their own that don't depend on whatever bizarre
single-application-specific behavior somebody decides to throw into the spec
because they think they know better than I do what my application wants to
do with a parse tree.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Monday, 2 November 1998 16:05:29 UTC