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

"Michael Champion" <michael_champion@ameritech.net> writes:

> ----- Original Message -----
> From: Stephen R. Savitzky <steve@rsv.ricoh.com>
> 
> > 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
> ;~)

I'm too busy coming to grips with my wasted time to disagree. :-(

> 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.

I think we're in considerable agreement about which parts of the DOM are
suitable for what.  But given the recent trend of DOM implementations it's
not clear that it's ever going to get to where a usefully-stripped-down
implementation will ever be compliant, or that somethng like hasFeature can
ever be made fine-grained enough to allow it without becoming too cumbersome
to use. 

I think the place where we disagree is whether the utility of a mere subset
of the DOM API, or a DOM-like API, is going to outweigh the expectations of
its users who are going to _expect_ it to be a ``real'' DOM, and who will be
very surprised and annoyed when their applications don't port (in whichever
direction). 

I had that experience recently.  We had a summer intern who wanted to rip
out our (well, my) carefully-crafted DOM-like classes and drop in someone
else's DOM so he could use someone's XML database.  It turned out to be
basically impossible -- the best he could do was read and write the
database's trees; too much of our internals depended on non-standard
behavior and extended interfaces. 

> 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. 

Many people, and I'm sure _all_ web page authors, would like to go as far as
possible in the opposite direction.  They want a compliance test suite, and
they want all browsers to pass it; they want total interchangeability and no
caveats.  No application writer wants the field confused by a hundred
``near-DOM'' implementations with a mass of features they have to explicitly
test for.

> 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.

There are two kinds of specifications: those that specify only an interface,
and those that attempt to completely specify the intended behavior of each
function in that interface.  The DOM is explicitly in the latter category.

Most application writers would be quite upset if they found that
aTreeWalker.getNextSibling().getPreviousSibling() returned null, even if the
nodes _are_ coming out of a stream and aren't being kept in a tree at all,
and the parser's documentation _does_ specify that only document-order
traversal is supported.

>       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.

Unfortunately, the DOM isn't that kind of standard.  I wish it was.  It's
the other kind.  I'd _like_ a DOM level 0; really I would.  I'm tired of
waiting for it.  I'm _really_ tired of having what some of us called
``server-side functionality'' promised in the next level, only to see more
constraints instead of fewer.  The DOM's specification process is monotonic;
it can only become more constrained and more bloated.  The early drafts
specified something I could use.  The final version didn't.

I think there's room in the world for both kinds of specification, but I do
NOT think there's room in the DOM for them.  

-- 
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 20:52:37 UTC