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

Christian Roth <rothc@informatik.tu-muenchen.de> writes:

> >Virtually all DOM implementors have
> >added extensions (and I respectfully disagree with Arnaud that this is
> >"useless"), although this obviously limits interoperability.
> 
> I agree with everything you said except for the last portion, which have 
> brought up others as well and I just don't get it:
> 
> Why does adding proprietary extensions limit the DOM's interoperability? 
> Because after an _extension_, the 'core' (not in the sense of the DOM 
> specification core) is still there, and this part still works in 
> accordance with the DOM API as set forth in the W3C documents.
> 
> Nobody choosing a DOM implementation is forced to use its proprietary 
> extensions: if you don't need it, don't use it!

I'll answer for the "no extensions" folks here (in my new role as a recent
convert) by explaining that the point of the DOM specification is to allow
people to write portable applications over a totally interchangeable set of
libraries.  In fact the "reference application" is a chunk of Javascript
built into a web page.  The author has no control whatever over the DOM
implementation running underneath his application; all they can hope for is
that the implementation follows the specification.  Exactly.

The DOM is designed for a situation in which you do not "choose" a DOM
implementation, you have one handed to you.  

> Leaving this door explicitly open might help get implementors to adopt 
> the DOM API as the basis of their implementation efforts. Closing it by 
> reserving everything to W3C could (IMHO) lead to the contrary: "Why 
> should I support the DOM API at all, if I have to find clumsy 
> work-arounds to be conforming and reach my goals? Then, I can as well 
> settle on a fully proprietary solution." And there goes _any_ 
> interoperability...

If you have the luxury, as you probably do and I certainly do, of designing
your document-processing interfaces to fit your application, there _is_ no
reason to support the DOM API if you find the necessary work-arounds
burdensome.  It would be nice if there were a document _requirements_
specification that would define what your interfaces _had_ to include in
order to handle any (XML/HTML/SGML/whatever) document, and that would guide
you toward a good, clean implementation that fits your application without
getting in your way.

Any competent programmer could start with such a requirements specification,
select the portions required by their application, and implement the whole
thing in a week.  Contorting an application to fit the demands of the DOM so
you can use someone else's library just isn't worth the time and effort it
would require.  Building a fully-compliant DOM implementation just for your
own application would practically insane.  (I feel much better now.  Really.)

It would be nice, in fact, if there were a sort of ``Document Object
Toolkit'' that was modularized to the point that you could pick exactly the
set of features you needed, turn the crank, and get nice clean Java (or C)
source code out that implemented exactly those features.  I sincerely doubt
whether any application developer in their right mind would select all of
the features of the DOM, but that's another matter.

It's also not what the DOM is intended for.  The DOM is the specification
for the Javascript document-processing library.  Best to leave it alone.

-- 
Stephen R. Savitzky  <steve@rsv.ricoh.com>  <http://rsv.ricoh.com/~steve/>
Platform for Information Applications:      <http://RiSource.org/PIA/>
Chief Software Scientist, Ricoh Silicon Valley, Inc. Calif. Research Center
 voice: 650.496.5710  front desk: 650.496.5700  fax: 650.854.8740 
  home: <steve@theStarport.org> URL: http://theStarport.org/people/steve/

Received on Tuesday, 5 October 1999 19:20:03 UTC