[XML-SIG] Implementing 'live'-ness in a 4DOM fork.

[Andrew Clover]

John J Lee <jjl at pobox.com> wrote:

> Does anybody have advice on the simplest approach?

The way live collections are done in pxdom is to give each Element node
a sequence number. Every time an element is appended, inserted, removed,
replaced or renamed, the number of the parent is incremented, along with the
numbers of each of the parent's ancestor nodes.

NodeListByTagName then recalculates its internal list only when the node
that generated it (a Document or Element) has a higher sequence number than
the last time it was calculated.

pxdom is a DOM Level 3 Core implementation only; Level 2 HTML would have a
few other kinks. In particular, changing attributes on an 'a' element could
cause document.links and/or document.anchors to need updating, and smiliarly
for NodeLists returned by getElementsByName.

> However, these interfaces represent mutable collections

This only affects HTMLOptionsCollection.length, I know of no other way such
a list can be altered; there seems also to be no spec requirement to
implement writing to length (it can raise a NOT_SUPPORTED_ERR). Still, it's
not too hard to make this method alter its owner's children.

The Python DOM bindings say that a non-readonly NodeList may be written
through Python-list-style, however:

  a. this is silly, and ignored by both 4DOM and minidom;
  b. it doesn't necessarily apply to HTML[Options]Collections, which aren't
     NodeLists.

> Worse, I presume that when you remove an item from a NamedNodeMap, the
> node tree gets updated.

Yes. Normally NamedNodeMaps are implemented in such as way that there is
only one copy of the information. In pxdom, an Element's *Attribute* methods
simply delegate to Element.attributes.*Attribute*. Since it is not possible
to create a new NamedNodeMap onto the same information (like it is with
getElementsByTagName and NodeList), there is no problem with syncing
multiple views onto the same data.

> what would happen if you made changes
> from *both* the node tree *and* a collection reflecting that tree?

Collections are only lists of node references, there is no copying of
trees being done. You only have to worry about changes to the
collection itself, and the only valid change (that I know of) in
DOM Level 2 Core+HTML is HTMLOptionsCollection.length.

> BTW, in previous posts here about this, I notice that people have claimed
> that only getElementsByTagName is affected here (because it has to
> construct a NodeList that doesn't directly reflect the node tree
> structure).

That's the only method affected in DOM Level 2 Core. There are more in
DOM Level 2 HTML and Range, but these are not so commonly used.

> I don't know whether this is considered a feature or a bug by people here

It's considered a spec compliance issue by me, and listed as such at
http://pyxml.sf.net/topics/compliance.html, but it's a deliberate decision
as a trade-off for complexity and speed. And it's a decision some other
DOM implementations have made too.

-- 
Andrew Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/