Re: New DOM Level 2 Working Draft

Jonathan Robie <jonathan.robie@sagus.com> writes:

> 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().

In that case, they ought to return an indication of which way they went, and
you need a way of controlling whether you want to see nodes twice (on the
way up as well as down the tree) -- most tree-processing operations expect
this (i.e. you do something at the start of an element, and something else
at the end).  In any case, it has to be better documented so as to remove
this ambiguity.

> 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.

Problem is you might want different filtering for nextNode and the other
methods. 

>  >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.

That's almost exactly what I do; the problem is that now everyone will do this
differently.  Actually, what I do is define completely different interfaces
for tree traversal and construction that behave the way my application needs
them to, and extended interfaces for Node and so on that add the extra
metadata the application needs.  It means that I'm only giving lip service
to the DOM, but at least the application runs efficiently.

> 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.

Actually, I'd be tempted to start over with a clean slate.  There's too much
of ECMAScript in the current DOM.  An alternative would be to just keep the
Level 2 interfaces and allow any implementation-selected subset of the
methods to throw an exception if it's not supported. 

-- 
Stephen R. Savitzky  <steve@rsv.ricoh.com>  <http://rsv.ricoh.com/~steve/>
Quote of the month:  Death is nature's way of telling you to slow down.
Chief Software Scientist, Ricoh Silicon Valley, Inc. Calif. Research Center
 voice: 650.496.5710  front desk: 650.496.5700  fax: 650.854.8740 
  home: <steve@theStarport.org> URL: http://theStarport.org/people/steve/

Received on Monday, 27 September 1999 11:48:47 UTC