RE: NodeList interface

>I'm not quite sure why this has only just appeared

As I understand it, some old comments from folks who weren't registered
participants of the Interest Group got hung up in transit and only got
processed a few days ago.

>After much head scratching I've come to the conclusion
>that there's no sensible way of implementing the DOM spec
>that supports *both* efficient editing *and* indexed
>access.

If you make that "efficient indexed access while editing is in progress", I
agree with you. Editing blows live indexing out of the water. But indexing
is what the Level 1 spec calls for; all we can do as implementers is try to
hide as much of the pain as possible.

You can fairly easily achieve code which indexes reasonably efficiently
during periods when no editing is in progress, via the approaches
discussed. Handling editing efficiently, as far as I can tell, would
require that each node have a count of all its descendents of any type as
well as a last-change timestamp, so that offsets could be recalculated
without having to walk unchanged subtrees.

I've chosen to declare the latter more coding work, and more computational
overhead, and more storage, than it's worth for my anticipated applications
-- I expect relatively few calls to getElementsByTagName() in XML
originating programs, and relatively few edits in tools which are likely to
use get-by-name. Call it an engineering compromise.

______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Monday, 28 September 1998 09:01:31 UTC