Forking the DOM (was Re: Storing Lots of Fiddly Bits)

[Simon St.Laurent]

Given the fairly strong comments excerpted below (and Paul's not the only
one muttering like this), is it time to contemplate a very different API?
The DOM's strong suit is that it provides a standard interface; however,
that standard seems to keep running into a mismatch problem in lots of
situations.

Is a generalized object model simply not the answer?  Do we need fifteen
semi-standard models for use in different situations?  Could the current
DOM be subsetted/extended to provide such functionality, or do we need to
take a few steps back and start over, leaving the DOM for those who need
its type of functionality but defining a new set of rules for those with
different needs?

At 03:41 AM 2/3/99 -0600, Paul Prescod wrote:
>You just need an API for "tree formats". Just ask your DBMS vendor to
>provide some tree-structured API. It doesn't matter if that API is the DOM
>because making it the DOM does *not buy you anything* as a programmer.
>>From a programming point of view there is no benefit to working with a
>consistent API where everything is dumbed-down to a textual model. You
>might as well dumb everything down to an "object model." (see below)
>
>[...]
>
>The *only benefit* of unifying things as DOMs is reusing software that was
>originally supposed to work with XML (i.e. XSL implementations). If you
>are writing new software it makes NO SENSE to do it through a DOM
>interface unless your data source is *XML*. 
>
>Otherwise, you should just define a "tree node" interface and have your
>various objects implement it. You will get all of the the benefits of the
>DOM with none of the costs (i.e. how the hell do you represent complex
>properties of objects???). If you want some good hints about what a "tree
>node" interface looks like, take a look at the grove abstraction.
>
>[...]
>
>Second, Even *XSL* is not best served by a DOM representation. James Clark
>wrote an xsl-list article about that but I can't find it now. Remember
>that the DOM was invented as an extension of "DHTML." It's only half
>"there." 
>
>But if I grant that some well-thought-through API for XSL trees could
>exist (i.e. Jade's grove API) then I would propose that it only be used as
>an optimization in a system where it would otherwise make sense to pass
>around serializations of text documents. i.e. the DOM is okay for skipping
>a layer of message passing. It is not okay as a "universal API" for "all
>of the data in an organization."
>
>[...]
>
>That's not going to happen. The DOM will NOT be a core tool for that
>majority of OO programmers this year, next year, or ever. Programmers will
>try it and increasingly find that if they are not doing XSL styling for
>the Web or print that the DOM is not a core tool. "Old-fashioned" OO can
>provide the same benefits.

Simon St.Laurent
XML: A Primer / Building XML Applications (March)
Sharing Bandwidth / Cookies
http://www.simonstl.com

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)