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

Arnaud Le Hors <lehors@w3.org> writes:

> I don't want to sound offending in any way, but I really think you
> misunderstood what the DOM is all about. We've never claimed that we're
> going to solve every possible problem in the world. For one thing, we
> stated from the beginning that we would only care about XML and HTML. If
> this isn't enough for you and you want to use SGML, you're very welcome.
> But it doesn't make any sense to then come to us and complain that the
> DOM doesn't work for SGML, because it doesn't preserve information such
> as omitted end tags. You're just wasting your time and some bandwidth.

End tags can be omitted in HTML as well as in generic SGML.  Although SGML
is an eventual target of my application, I'm not currently using anything
that isn't in HTML right now.  It's important for my application to be able
to process documents without damaging the parts it doesn't affect; that
involves being able to recover an input document from the parse tree.
Exactly.  The DOM doesn't do that, although it's straightforward to extend
it so that it does.

But a DOM with defined extension capability would allow an implementation to
be fully compliant and still be able to handle such things as SGML,
round-tripping documents, and applications that need to attach arbitrary
random metadata to nodes.

> Now, if you have any constructive comment on the DOM spec, there are
> very welcome.

My main suggestion (and the entire thrust of this thread) is that subsetting
and extending the DOM should be either explicitly allowed for, or explicitly
forbidden.  My current bias, given the DOM in its current state, is toward
the latter (as I believe yours is as well).  The DOM should specify a
totally portable API, take it or leave it.

I have made a number of other suggestions, mainly in the direction of
extensibility, in other threads; it was very clear that they were _not_
welcome.  I have recently come to understand the reasoning behind that, and
I'm now inclined to agree.  It will save _everyone_ a lot of time and
bandwidth if the DOM specification makes it clear that its primary goal is
to specify a stable API with rich functionality and wide, but by no means
universal, applicability.

Application-writers like me whose code requires contortions or extensions
to fit it into the DOM framework should, as I've said, go their own way and
leave people like you alone, and perhaps evolve a different standardized API
that embodies a different set of requirements and design decisions. 

This philosophy will, of course, leave a lot of "near-DOM" and "partial-DOM"
and "extended-DOM" implementations in limbo for a while, but at least we
will have a clear path to follow instead of beating our heads against the
extensibility vs. interoperability issue. 

-- 
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 Wednesday, 6 October 1999 15:17:45 UTC