W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

RE: DOM Level 2 Core Features

From: Miles Sabin <msabin@cromwellmedia.co.uk>
Date: Wed, 18 Nov 1998 12:07:45 -0000
Message-ID: <c=US%a=_%p=Cromwell_Media%l=ODIN-981118120745Z-1068@odin.cromwellmedia.co.uk>
To: "'Don Park'" <donpark@quake.net>, "'www-dom@w3.org'" <www-dom@w3.org>
Don Park wrote,
> >4. Non-live iterators for a few, well-chosen, tree
> >   traversals: over children; over descendents in
> >   pre-order (others?).
> What do you mean by non-live?  Do you mean that if an iterator
> over a document with 100 nodes should return exactly 100 nodes
> even if nodes have been inserted or removed from it during
> iteration?  I doubt this is what you want.

Err ... poor choice of words on my part.

What I meant was: lightweight iterators which are not
required by the spec to be robust in the face of
modifications to the document.

So, for example, an iterator over children could be
simply defined (tho' not necessarily implemented) in
terms of sibling operations on the current node; a
pre-order iterator could be defined in terms of
sibling and parent/child operations on the current
node. This sort of locality is required if we want
the possiblity of iterator operations being O(1).

Obviously, a traversal defined by such an iterator
could be distrupted by modifications to the tree, eg.
if the current node was removed during the traversal
(amongst other possiblities). The spec should document
that fact, and leave iterator users to take appropriate

We can already build these iterators as things stand,
but it'd be nice to have a standard iterator interface,
particularly in conjunction with a hypothetical standard
NodeVisitor (because we ought to keep traversal
algorithms separate from the visitation stuff).

Steve (was it you?) has suggested that we might *also*
(not instead) have more heavyweight iterators which
*are* robust in the face of document modifications. I'm
not sure this is a good idea, partly because defining
their behaviour looks to be very difficult, and partly
because support for them might have a negative impact on
implementations even if they're never actually used (cp.



Miles Sabin                          Cromwell Media
Internet Systems Architect           5/6 Glenthorne Mews
+44 (0)181 410 2230                  London, W6 0LJ
msabin@cromwellmedia.co.uk           England
Received on Wednesday, 18 November 1998 07:09:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC