Re: XML APIs

>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.")

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 -- so if your users don't expect to
use NodeList, or will not use it while the tree is being altered, you can
eliminate that complication. Since the DOM is explicitly single-threaded in
Level 1, locking is not necessary; anyone who tries to multitask against it
is violating its spec and whatever you do in response to that is by
definition compliant.

The result may not be of interest to anyone but your target user community,
but it would be a legitimate DOM implementation.

Those of us who aren't so sure we can predict the user's needs need to work
a bit harder. How hard depends on how unsure we are. There are some known
performance hazards in my own implementation, but I made a Decision to live
with and document them for now. If and when the users tell me I guessed
wrong, I'll iterate.

>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.
______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.

Received on Tuesday, 3 November 1998 16:44:45 UTC