Re: XML APIs

keshlam@us.ibm.com writes:

> >There is no way to make locking local in the presence of live NodeLists
> and
> >of iterators that are ``robust'' over arbitrary changes in the tree.
> 
> I take it you've tried to do this and failed, or have a good theoretical
> paper to cite in support of that statement? ("Absolutes are always false,
> including this one.")

No, and point taken.  However, it seems probable: live nodelists are
themselves non-local, and I don't see how to protect them from changes
without locking the entire tree.  

Structurally-aware iterators are somewhat different; one could lock an
individual node by setting a lock flag on it and all of its ancestors, and
then check for locks in its descendents by walking up the tree.  Neither of
these operations is local, however, and are at best O(log N).

Operations that change structure can, of course, be designed to keep
nodelists and iterators up to date, but this is _different_ from locking,
and is also non-local.

> >I would like to see _some_ variant of the DOM that does _not_ require
> >locking, caching, lazy evaluation, and all the other machinery that is
> >required by Level 1.
> 
> You don't have to deal with any of that. A DOM can expand entity references
> immediately, avoiding the lazy-evaluation issue; a non-validating DOM can
> decline to expand them at all.  Caching NodeList is unnecessary if you
> aren't concerned about its performance.

    ...for a given EntityReference node, it may be that there is no Entity
    node representing the referenced entity; but if such an Entity exists,
    then the child list of the EntityReference node is the same as that of
    the Entity node. As with the Entity node, all descendants of the
    EntityReference are readonly.

I'm operating in an environment in which Entity and EntityReference nodes
_do_ exist, because I'm _constructing_ documents as well as processing them.
My particular application is never going to try to look at the children of
an EntityReference, but in order to have a compliant implementation I would
have to at least be able to produce them on demand.

I also didn't mention things like the O(log N) test required to throw
HIERARCHY_REQUEST_ERR in replaceChild, and so on.

> >INTERFACES, BUT NOT THE BEHAVIOR
> 
> would not guarantee interoperability. And if the DOM doesn't deliver that,
> it doesn't deliver anything worth the effort of standardizing.

I don't think the DOM would be any less interoperable if a static NodeArray
replaced all the live NodeList's.  It would even be possible, by defining
NodeCollection as a common parent and having childNodes and
getElementsByTagName return _that_, to make it an implementation decision
which could then be reflected in hasFeature.

Conversely, I don't think the DOM is made significantly _more_ interoperable
by offering, e.g., the choice between efficient NodeList's and efficient
replaceChild, especially if there's no way for an implementor to determine
which choice was taken by the library his application is dynamically linked
with at the moment.  

A sane application developer is probably going to say something like: ``If
you use the DOM library that ships with this application, it will work
efficiently.  Use someone else's and you risk an order-of-magnitude
performance hit.''  A sane user is not likely to be impressed, especially
after making the experiment once or twice.  

-- 
 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 Tuesday, 3 November 1998 18:56:54 UTC