Re: New DOM Level 2 Working Draft

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

> Thanks - I was kind of wondering what you would think, since we received a 
> great deal of feedback from you earlier on. The current draft has benefited 
> greatly from the time and attention that Joe Kesselman and Andy Heninger 
> gave to it.

Thanks, Joe; thanks, Andy!  I'd kind of dropped out of the discussion
because at the time it looked as though the semantics of iterators had gone
totally off the deep end, and nobody seemed to be listening.

>  >2. There doesn't seem to be any way to create an Iterator from a NodeList or
>  >   NamedNodeMap.  In this regard it is also unfortunate that NamedNodeMap is
>  >   not an extension of NodeList.
> 
> This is a valid critique, and I expect that there will be DOM 
> implementations that *will* create Iterators from NodeLists or 
> NamedNodeMaps, or that return collections of Iterators as results of queries.

They should really be in DocumentTraversal from the start.  This would
encourage implementors to construct efficient, special-purpose iterators and
give programmers a consistent way of getting to them.  So instead of using
the result of getElementsByTagName directly, for example, you'd use
aDocumentTraversal.CreateNodeIterator(aNode.getElementsByTagName(...),...).
The actual NodeList could then be arbitrarily inefficient, because nobody
would use it directly.

>  >3. Ideally, all methods that return NodeList should be deprecated and
>  >   replaced by methods that return an equivalent Iterator.
>  >
>  >4. A Document should be able to import a TreeWalker.
> 
> That would require a decision to put Iterator in the core. 

I remember a draft in which it _was_ in the core, and I was _very_ unhappy
when the live nodelists came in to replace it.  I'm sure there was a good
reason, but it made life a lot harder for the implementors. 

>  >5. The semantics of nextSibling on TreeWalker are unclear if the next
>  >   sibling exists but does not match the filter criteria.
> 
> To make it clearer, perhaps I should change the text "If the current node
> has no next sibling, returns null, and retains the current node" to read
> "If the current node has no next sibling in the logical view, returns
> null, and retains the current node". Would that wording do the trick? I
> could make parallel changes to the other navigation methods for
> TreeWalker.

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).
 
>  >7. Consider the consequences if Iterator and TreeWalker added the following
>  >   methods derived from attributes of the reference Node:
> [SNIP!]
>  >   It would then be possible to traverse and process a document of arbitrary
>  >   size without ever instantiating the whole tree, and indeed without
>  >   creating any Node objects at all!
> 
> Yes. And there is nothing to prevent an application from doing so. Since my 
> main work since 1995 has been with XML repositories, this kind of 
> processing was one of my goals.

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.

-- 
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 Friday, 24 September 1999 12:24:51 UTC