- From: Jonathan Robie <jonathan.robie@sagus.com>
- Date: Fri, 24 Sep 1999 12:55:23 -0400 (EDT)
- To: www-dom@w3.org
Stephen Savitzky <steve@rsv.ricoh.com> writes: >Yes, that would help. Actually, there's no reason to have nextSibling at >all; as far as I can tell it always returns the same thing as nextNode. >(unless nextNode is intended to do a full traversal, in which case it should >return, not a new node, but a flag to tell the caller which direction it >ended up moving -- otherwise it's almost useless). nextNode() and previousNode() do a document order traversal, and can walk the entire document, so they are not the same as nextSibling() and previousSibling(). I believe that the notion of document order traversal should abstract out the actual steps taken in the navigation. Typically, nextNode() and previousNode() might be used to locate "interesting" nodes, and the other TreeWalker methods would be used to navigate explicitly once these nodes are located. >The main problem with the DOM is that it's currently impossible to do >something like this with the present semantics. The live nodelists and >things like previousSibling and ownerDocument almost completely determine >the implementation. TreeWalker as it's presently defined doesn't remove >enough of the constraints (though it helps). Because TreeWalker is required >to return an ordinary Node from currentNode and so on, which the application >can then do anything at all with, you're still stuck with potentially >disastrous inefficiencies. > >Oh, well... I'll take what I can get, and continue using my own >interfaces that do what my application needs. Actually, I do not believe that the DOM precludes you from *adding* methods, so you can legitimately add these other node methods in your implementation, and use them instead of instantiating Node. Of course, if someone chooses to call the navigation methods defined on Node (or any other methods defined on Node), you would have to instantiate a node, but you can at least tell your users this has performance implications. It would be nice to have a well-defined, leaner subset of the DOM that is appropriate to server-side applications, and one thing that it might leave out would be navigational methods on Node. However, that's not something that is at all likely to happen for Level 2. Jonathan
Received on Monday, 27 September 1999 05:20:23 UTC