- From: Stephen R. Savitzky <steve@rsv.ricoh.com>
- Date: 18 Nov 1998 14:43:56 -0800
- To: <www-dom@w3.org>
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