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

"Stephen R. Savitzky" wrote:
> 
> keshlam@us.ibm.com writes:
> 
> > 	code written to the DOM API will run, and
> > (eventually) generate the expected results, and that's all that DOM
> > compliance promises.
> 
> That's nowhere near minimal enough.  I'm thinking of streaming applications
> and processors with limited or no secondary storage, where the whole
> document tree simply will not fit in memory no matter how far you shrink it.

Point being that DOM, which guarantees access to a large tree of data,
provides too much functionality for some typical XML applications.

This is not at all controversial.  Servers can't always afford to spend
memory like DOM requires, and are not alone in being resource constrained.


> > The DOM is interfaces. It's only interfaces. What's going on behind those
> > interfaces doesn't matter to the DOM as long as the expected results come
> > back.
> 
> This is simply false.  If the DOM were only interfaces it wouldn't be
> specifying behavior, for example live nodelists.

That's extreme.  Interfaces aren't just call syntax, they are fundamentally
about what those calls do -- which is "behavior".

On the other hand, specifying that "all nodelists are live" goes beyond
specifying what any given call does -- it talks about behaviors which
don't relate to a particular call.  "The NodeList returned by {this call}
is live" is a statement that doesn't bother me beyond knowing the costs
of what such "liveness" are.  "All NodeLists everywhere are live" does
bother me -- it precludes using a generic data structure in many places
it should be usable.


> 	Some applications, like mine, may come to depend on nonstandard
> behavior of the standard interfaces (like the fact that EntityReference
> nodes have no children, or that EntityReference nodes are not automatically
> expanded in the values of Attr nodes).  Or they may come to depend on
> features of the implementation that aren't specified by the DOM, such as the
> fact that my implementation of a NamedNodeMap can be cast to a NodeList.

That's what's called nonportable application code.  The goal of an API
like DOM is to ensure that you don't _have_ to write such code.  In fact
it was your choice to rely on such behaviors -- you didn't need to.

 
>	I believe that there are many applications
> that are better served by a simple, custom parse tree implementation than
> they are by the DOM ...

Again, not controversial at all.  I'd actually prefer to see some
widely adopted "simple" API than see lots of custom ones, but it's
no big deal for most of my purposes.


> 	fully implementing
> the DOM is a major undertaking, and rest assured that if you only do a
> subset _somebody_ will come back in the future and demand the rest.

Permit me to disagree.  Learning DOM well enough to implement it correctly
is a notable undertaking.  After you've done that, implementing a DOM is just
a day or two's worth of work -- though you'll suffer from (a) functionality
in the interface which precludes some kinds of efficiency, and (b) incomplete
APIs, where some DOM functionality can't be implemented without proprietary
capabilities.

- Dave

Received on Wednesday, 6 October 1999 13:40:55 UTC