W3C home > Mailing lists > Public > www-dom@w3.org > July to September 1999

Re: New DOM Level 2 Working Draft

From: Jonathan Robie <jonathan.robie@sagus.com>
Date: Fri, 24 Sep 1999 12:55:23 -0400 (EDT)
Message-Id: <4.2.0.58.19990924125327.02e84910@pop.mindspring.com>
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 GMT

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