W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Re: DOM Level 2 Core Features

From: Mike Champion <mcc@arbortext.com>
Date: Wed, 18 Nov 1998 15:17:00 -0500
Message-Id: <>
To: steve@rsv.ricoh.com (Stephen R. Savitzky), <www-dom@w3.org>
At 09:51 AM 11/18/98 -0800, Stephen R. Savitzky wrote:
>That was me.  I agree with you: I'd really prefer simple O(1) iterators with
>no implementation impact and easily-documented conditions under which their
>behavior is undefined.
>The *also* was to mollify the crowd that wants to have robustness at any
>price.  In my opinion this should be left as an implementation decision. 

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

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.

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

Mike Champion
Received on Wednesday, 18 November 1998 15:17:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:05 UTC