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

RE: DOM Level 2 Core Features

From: Jeff Mackay <jmackay@vtopia.com>
Date: Wed, 18 Nov 1998 22:09:39 -0600
To: <www-dom@w3.org>
Message-ID: <000001be1372$6e2572a0$03000004@soho.enteract.com>
>> 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.

I agree completely. In other environments this might be called a "quality of
service" issue.  The majority of users require the "robust" quality of
service. A vocal minority requires a less robust quality of service
for this feature.

Other services--such as ODBC and JDBC for relational databases--support
multiple quality of service features.  In order to use a feature, you can
check to see if the driver (or in our case DOM implementation) supports that
feature. If you check and take appropriate action, you're safe. If you
don't, you are subject to different (albeit predictable) behavior for
different implementations.

The point here is that there are applications for which a "live" iterator is
unnecessary and could even be considered harmful because of the extra work
and space required to implement. Web crawlers, robots, spiders come to mind.
As do any number of specialized interfaces in embedded or handheld devices.
Should
a hand-held book reader really be able to update a text while it is being
read? In some cases, the answer may be yes.  In others, a definite no.

Different quality of service levels could be implemented as separate APIs,
but that isn't a very maintainable approach from an implementor's point of
view. I believe it makes more sense to allow applications to dynamically
query the capabilities of an implemementation.

As an example, let's assume that I have two iterator classes: a LiveIterator
and a StaticIterator. I have an application that needs to traverse the tree,
and I occasionally need to insert nodes into the hierarchy while I'm
traversing. When I use the LiveIterator, I can insert nodes while I'm
traversing.  If I'm using a static iterator, I'll queue the inserts for
processing when I'm through with the traversal.

-------------------
Jeff Mackay
Vtopia, Inc.
e-mail: jmackay@vtopia.com <mailto:jmackay@vtopia.com>
url: http://www.vtopia.com/
Received on Wednesday, 18 November 1998 23:10:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT