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

Re: The DOM is not a model, it is a library!

From: Michael Champion <michael_champion@ameritech.net>
Date: Tue, 5 Oct 1999 19:48:37 -0400
Message-ID: <007201bf0f8c$71c64300$061d12d1@mccdell>
To: <www-dom@w3.org>

----- Original Message -----
From: Stephen R. Savitzky <steve@rsv.ricoh.com>
To: Michael Champion <michael_champion@ameritech.net>
Cc: <www-dom@w3.org>
Sent: Tuesday, October 05, 1999 4:55 PM
Subject: Re: The DOM is not a model, it is a library!


> That's not what I mean by the reference set.  I mean the types of programs
> for which the API is suitable: scripting languages, mostly in browsers,
> operating on a limited number of small documents all of which use the same
> well-known DTD.  The DOM contains many components, features, and
behavioral
> constraints that are not merely useless but totally wrong for applications
> that involve databases, large documents, small memory, streaming, editing,
> and so on.

Well, having represented both an editor company and a database company on
the DOM WG, either I've got to come to grips with the fact of having wasted
a good bit of the last couple years or we're gonna have to disagree on this
;~)

But I think the disagreement is pretty much on the level of definitions, not
pragmatics.  It would be "totally wrong" for Software AG to redesign their
database to fully meet every feature of the DOM API (probably crippling
performance, footprint, etc. in the process) but we believe that some API
that is quite similar to the DOM API (minus some irrelevant interfaces, plus
some needed extensions) will be very useful to our customers. Similarly, the
rise of ulta-light internet clients like PDAs and cellphones will tend to
lead to DOM implementations that contain only the bare minimum set of
interfaces.  I agree that there should be some approved way to limit
features and still be "DOM compliant", and the hasFeature() method in Level
2 goes part of the way toward this goal.

In practice, developers will have to figure out what platforms they want to
run on, figure out what APIs are supported on which platforms, and design
their apps accordingly. Likewise, implementors will have to make tradeoffs
between supporting everything that developers might like (or the WG might
specify) and getting their implementation to fit into the time/space
constraints of their platform.  The DOM spec can make the hasFeature()
mechanism more fine-grained than it is now,  (but only at the cost of adding
to the footprint!) but I'm not sure this would really help much in the real
world.  "DOM compliance" is going to be a rather fuzzy concept, driven by
market forces more than anything the W3C can mandate.

I don't think we need to say "if it's in the specification, it ABSOLUTELY
MUST be in the implementation".  Obviously that's an ideal, and the
marketplace will select out implementations that stray too far from the
ideal.  My bottom line is "standard functionality should be accessible by
the standard API";  that REALLY helps people write apps that work across
implementations, but offers no guarantees of universal interoperability.
That's all I want from our suppliers, and all I'll promise to our customers.

Mike Champion
Received on Tuesday, 5 October 1999 19:51:56 GMT

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