Re: Missing exception in treeWalker

I just realized that a similar situation occurs if you call
DocumentTraversal.createTreeWalker with a root node from another document.
This is also tricky since the DocumentTraversal interface and Document
interface dosn't neccessailiy have to be implemented from the same object.

/ Jonas Sicking

----- Original Message -----
From: "Joseph Kesselman" <keshlam@us.ibm.com>
To: "Jonas Sicking" <sicking@bigfoot.com>
Cc: <www-dom@w3.org>
Sent: Monday, May 21, 2001 15:19
Subject: Re: Missing exception in treeWalker


>
> > in the treeWalker interface. When setting the currentNode
> > shouldn't a WRONG_DOCUMENT_ERR be raised if currentNode is
> > set to a node in another document.
>
> Good question. I can argue both sides, and this needs more thought, but
> overall I think I'm inclined to agree with you.
>
> Because TreeWalker needs to be aware of only one node at a time --
behavior
> the Traversal team referred to as "pure current-node semantics" -- it is
> perfectly possible to write a TreeWalker which navigates using only the
> public DOM APIs. Such an implementation would be perfectly happy when
> applied to any DOM, and could be moved from one document to another quite
> happily. (By contrast, NodeIterator's maintain-relative-position semantics
> currently tie it to a specific DOM implementation, though when DOM Level 3
> brings us event-listener grouping capabilities it should be possible to
use
> mutation events to write a simiilarly interoperable NodeIterator.)
>
> Of course setting currentNode to a different document would mean traversal
> would never encounter the root and hence not be bounded by it. We already
> discuss a similar case when currentNode is set to a node outside the
root's
> subtree, so I don't see that as a major problem.
>
>
> ON THE OTHER HAND, a TreeWalker may want to reach past the DOM APIs and
> access the underlying data representation, for efficiency reasons. Such a
> TreeWalker would _not_ interoperate with other DOMs... unless it include
> the code for both modes of operation, which might be argued to be an
> unreasonable imposition on implementations.
>
> And to discourage nonportable DOM applications, I would much prefer to
> avoid wording suchn as "may throw an exception if this implementation does
> not support".
>
> And, to top it off, TreeWalker should be a relatively lightweight object;
> creating a new one in the new document shouldn't be unreasonably
expensive.
>
>
> So on balance, I'm inclined to agree that we should add WRONG_DOCUMENT_ERR
> to TreeWalker#setCurrentNode. But the DOM WG will have to talk this over
> and decide whether to issue an erratum, and if so decide whether the
> phrasing is "thrown when the proposed currentNode belongs to a different
> document than the root node does" or "....different document than the one
> which created this TreeWalker." Some folks may want to implement
> stand-alone TreeWalker implementations for special purposes (again, using
> the public DOM interface), and those may not be created directly by a
> document, so the latter wording might not be optimal.
>
>
>
> ______________________________________
> Joe Kesselman  / IBM Research
>

Received on Monday, 21 May 2001 09:57:14 UTC