Re: Implementing NodeList

You and Don Park need to get together on what ``liveness'' means, and when
it's required by the spec. 

Mike Champion <mcc@arbortext.com> writes:

> Neither of these are consistent with the spec.  Sorry, but this *is* going
> to be hard to implement efficiently.
> 
> I think the best implementation is to lazily evaluate the NodeList, i.e.,
> make the NodeList be an interface that really has what we used to call a
> NodeIterator under the covers.  That way, you only see nodes in the tree
> when the user asks for them.  That puts the burden of capturing changes to
> the tree on the call to item().

This means that every call on item() involves a complete traversal of half
the tree (on average) to make sure that a new node of the type selected by
getElementsByTagName hasn't snuck in behind your back.  In the case of large
documents, possibly containing references to external parsed entities, this
could take a *very long time*.

ON THE OTHER HAND, "Don Park" <donpark@quake.net> writes

> This confusion stems from the movement of words between different versions
> of the spec.  If you read the latest spec more carefully, you will see that
> the word "live" is used only in the description of the attribute
> "childNodes".  This means that the NodeList itself is not always live and
> that the NodeList returned by getElementsByTagName is not live.  Only the
> NodeList returned by getChildNodes is "live".

I think this suggests that the spec is ambiguous, and should be rewritten to
clarify the situation, preferably in the direction of Don Park's commonsense
interpretation.

-- 
 Stephen R. Savitzky   Chief Software Scientist, Ricoh Silicon Valley, Inc., 
<steve@rsv.ricoh.com>                            California Research Center
 voice: 650.496.5710   fax: 650.854.8740    URL: http://rsv.ricoh.com/~steve/
  home: <steve@starport.com> URL: http://www.starport.com/people/steve/

Received on Monday, 27 July 1998 19:21:41 UTC