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

Re: Missing exception in treeWalker

From: Jonas Sicking <sicking@bigfoot.com>
Date: Mon, 21 May 2001 16:00:06 +0200
Message-ID: <009101c0e1fe$57442380$d1ee42d5@kermit>
To: <www-dom@w3.org>
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 --
> 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
> 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
> 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
> 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

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