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

----- Original Message -----
From: Stephen R. Savitzky <steve@rsv.ricoh.com>
To: <www-dom@w3.org>
Sent: Tuesday, October 05, 1999 2:50 PM
Subject: The DOM is not a model, it is a library!


> THE DOM IS NOT AN OBJECT MODEL!  It is a specification (API) for a class
> library.  Specifically it is the API for the class library of Javascript.
> The Infoset is much closer to being a real object model, in that it
> specifies the necessary and sufficient set of interfaces that _any_
> implementation of documents must, somehow, provide.

That's quite true. On the other hand, the Infoset activity came into being
partly because the DOM working group struggled with the fact -- which was
not clear to us a couple of years ago -- that XML itself did not define a
specific object model (in your sense, the result of an analysis phase that
defines the basic set of objects and relationships, but not the API).


> For the near term I will continue
> to base my application on my partial implementation of the DOM, and
because
> of its architecture it will always be able to manipulate DOM trees, but
> eventually my internal representation will cease to look anything like the
> DOM.

I think this is more or less what EVERYONE who's implementing the DOM on top
of an existing application does. There is no assumption, or even suggestion,
that the DOM interfaces should look anything like the underlying data
structures.  That's what distinguishes one DOM implementation from
another -- the suitability of the internal representation and manipulation
of the XML data for some specific type of task, be it browsing, editing,
workflow, database, etc.  It makes sense to me to have a common API for
common operations in disparate applications, but it makes no sense to me to
try to find a common INTERNAL representation that meets such a range of
requirements.

>
> The
> reference set of applications should be specified -- applications outside
> this set _might_ be able to use the DOM, but if their requirements differ
> from those of the reference set their needs will simply not be considered.
> It should be made _very_ clear that extensions of any sort are not
> encouraged, perhaps not even permitted, and that implementors with a
> different set of requirements should seek elsewhere.

Here I pretty much totally disagree. How could one usefully specify a
"reference set of applications" in an industry that's evolving as rapidly as
the Internet?  Applications, and even the terms "e-commerce" and "portal"
were not in common use when work on the DOM began, but I submit that the DOM
is very relevant in both these areas.  Virtually all DOM implementors have
added extensions (and I respectfully disagree with Arnaud that this is
"useless"), although this obviously limits interoperability.  As many people
have noted, one must use proprietary extensions to the DOM to load and save
data!  I assure everyone that it was explicitly assumed that implementors
would extend the DOM to provide access to operations -- such as DTD
navigation -- that the DOM doesn't (yet) support.  All I suggest is that
implementors who have functionality that overlaps the DOM functionality
provide DOM interfaces, add proprietary APIs where their functionality
exceeds the DOM's, and work with the W3C to standardize the APIs as the base
of overlapping functionality grows.

Mike Champion

Received on Tuesday, 5 October 1999 16:15:45 UTC