W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2001

Re: Missing exception in treeWalker

From: Joseph Kesselman <keshlam@us.ibm.com>
Date: Mon, 21 May 2001 09:19:39 -0400
To: "Jonas Sicking" <sicking@bigfoot.com>
Cc: <www-dom@w3.org>
Message-ID: <OF5AFD1489.57CE3711-ON85256A53.00470486@pok.ibm.com>

> 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:20:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:48 GMT