RE: FW: adding addressing capabilities to the DOM

>
> > API. I see NodeList as a very *natural* implementation of the XPath
> > node-set
> > abstraction.
>
> This has been debated in the past; I'm not sure we really want to rehash
> the pros and cons of NodeLists. Brief summary of the concerns:
>

I appreciate you taking the time to describe the concerns that you've
already tried to address. I agree that we don't need to hash these out
again.

> NodeList is explicitly defiend as being a "live view". Every time the DOM
> changes, its contents may have to be recomputed, and because it's
> integer-indexed that can involve a complete walk of the DOM tree. (There
> are ways to optimize that slightly, but only slightly.) That
> computation is
> significantly expensive even when matching only against the node type and
> name, as now; it'd be much worse for XPath.
>

True, very true. I'm not tied to using NodeList - I actually thought it
would be simpler for most implementations since they already have it in
place. If most usage patterns don't mutate the returned NodeList (e.g.,
typical data extraction routines), the extra overhead wouldn't be incurred.
I can see both sides of this...

> Part of the goal of the Traversal chapter was to get rid of this global
> sensitivity and switch to localized testing, which is less expensive under
> document mutation.
>
> If you don't need a live view, you don't want NodeList -- just a vector of
> nodes. If you do need a live view, I submit that you probably won't want
> NodeList when you consider its real costs.
>
> Your milage may vary.
>

Agreed, but as I implied above, I bet XPath will be used more for
(read-only) data extraction than in mutation scenarios. So I would vote for
whatever is easier for implementations.

-aaron

Received on Tuesday, 18 April 2000 13:00:45 UTC