Re: DOM Level 2 Core Features

Mike Champion <mcc@arbortext.com> writes:

> Maybe I'm missing something, but leaving "robustness" as an implementation
> decision would seriously impede interoperability, would it not?  That is,
> if a script encounters one of the conditions in which an iterator (or
=====> ^^^^^^ Please note!!!!!  I am writing APPLICATIONS, not scripts.

That's really the crux of the whole argument.  I believe that the DOM should
be of use not only to the authors of tiny browser scripts, but to
professional programmers writing real, and sometimes very large,
applications that deal with real, and sometimes _extremely_ large,
documents.  Live nodelists and handholding iterators simply aren't
acceptible if you're indexing the Web (to take a real, though not personal,
example). 

> NodeList, etc.) is undefined, it will probably crash on some
> implementations and run on "robust" implementations.  I don't think that's
> in the spirit of what the W3C working groups are trying to accomplish,
> although I understand that many of you are writing specialized applications
> for which interoperability is not an issue.

In any case, the issue is not so much crashing as returning a value which,
while not invalid (for example, the value of toNextNode returned by an
iterator is going to be either a Node or null under all circumstances), is
not easily determined. 

Personally, I consider a simple iterator that keeps a current node and
navigates using links to be perfectly "robust" -- it will never crash as
long as the programmer tests for nulls in the right places, and will produce
deterministic results no matter what happens to the underlying document.

Some people, however, seem to think that an iterator must return an
exception whenever its "current node" is affected by a structural change.
That way lies madness, as the behavior under exceptional conditions becomes
harder and harder to specify, and has a more and more serious affect on the
efficiency of the implementation (e.g. live nodelists).

> I *would* advocate (and have recently raised it yet again to the DOM IG/WG)
> that we define a "minimal" or "non-handholding" DOM API that could be used
> in environments where size/efficiency is more important than robustness
> e.g., servers, specialized network appliances, high-volume message
> processing applications, etc.  Implementors could decide which flavor of
> the DOM to support, and there should be interoperability *within* that
> flavor, but would still have to fully implement the behavior specified by
> that DOM flavor.

I think perhaps that "robustness" is not the correct word, though I don't
know what is.  "Handholding" comes close.  It's really a scalability
problem; certain features are useful in small scripting applications, but
don't scale to larger documents or higher speeds.

> Would such an approach help anyone who's been wrestling with efficiently
> implementing the various convenience "features" in DOM Level 1?

Yes.  This is _exactly_ the kind of thing I want. 

-- 
 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 Wednesday, 18 November 1998 17:41:24 UTC