TreeWalker and document changes

> It seems to me a more natural behaviour when any in some way critical
> modification of the DOM-tree is answered by invalidating the Treewalker
> or by re-initializing it (setting it to 'root' or to the node "above"
> the modification), because otherwise the TreeWalker.current is working
> in a branch of the tree that "normally" would have been ignored.  So a
> TreeWalker must allways pay attention to modifications that appear
> between (including) the 'root' and the 'current' node, and not only to
> those immediately before or behind the 'current' node.  The problem is

I agree that the TreeWalker would need to be adjusted.  I'm mostly
interested in whether or not currentNode should be NULL after the node it
points to is deleted.  I think that the TreeWalker should behave like the
Iterator in that the position remains unchanged relative to the remaining
nodes - its siblings and parent (two cursors on each side of the node).

Though it's somewhat strange that parentNode, previousSibling, and
nextSibling are non-NULL when currentNode is NULL.  But if I am processing
the children of a node and deleting some nodes as I go then I don't want the
iterator to jump around.

The DOM2 spec doesn't explicitly state how the TreeWalker should behave when
the document is being modified.

Back to your original example of inserting node C between A and B (perhaps
adding C as a child of A then moving B from A to C).  If the TreeWalker
behaves as I described above then parentNode returns A, currentNode returns
NULL, and nextSibling returns C - except that it gets rejected.

Another note:
The 'view' that the tree walker presents can be changed by the filter, not
just document changes.  The filter may reject a node that it earlier
accepted.  You won't know until you query the filter.  Seems like a bad idea
to me, but the TreeWalker still has to handle it.


Tim Bryant 
[mailto:tbryant@objfactory.com]