>Getting the updates to work properly requires working down at the DOM2DTM
>level. Joe may have more thoughts on this.
Not a lot of thoughts...
The problem is that current implementaitons of DTM use such a tightly
packed representation. Actuallly adding or removing nodes in the middle of
a document could be ... interesting.
If your document mutations don't actually change the tree structure -- if
you're just altering the content of text nodes -- I think DOM2DTM may
actually survive those changes now.
Removing nodes: The simplest solution might actually be to invent an "I'm
Not Here" nodetype, and specialcase DTM to know how to skip over it.
Downside: That means another test on every navigation, which would have
peformance costs. In some cases we may also be able to get away with
patching the nextSibling/previousSibling to skip over nodes... though there
is some code which relies on specific sequencing (for example, we assume
that Attrs immediately follow the element they apply to).
Adding nodes is tough. DTM's use of numeric indices into tightly-packed
arrays means that inserting a node in the current representation would be
fairly expensive -- both from the point of view of recopying large portions
of the array so you could do the insertion, and in having to fix up
crossreferences. Switching to relative node references probably wouldn't
eliminate the latter but might reduce its impact. Another solution would be
similar to the "I'm Not Here" nodetype -- introduce what amount to a
breakpoint node, which refers DTM off to secondary storage -- but then we'd
lose the simple mapping between node number and document order.
