cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: [Moving on] SAX vs. DOM part II
Date Tue, 25 Jan 2000 05:28:12 GMT
On Tue, 25 Jan 2000, Scott Boag/CAM/Lotus wrote:

> 
> > Although, you know, it's not DOM that my processors might want so much,
> > anyway, but a _good_ tree-based API. Personally, I think DOM is a poorly
> > designed API and that one could do much better (hell, we could even come
> > up with the new de facto replacement for tree-based XML API).
> 
> In some ways I agree 100%.  The DOM API was made for things like JavaScript
> and VB access, not high performance usage.  Ask my opinion about getting
> the owner of an attribute, being able to discover node order, polymorphic
> ability of methods, etc.
> 
> On the other hand, you're scaring the hell out of me.  I think XML has some
> pretty bad limitations as a markup language, but I don't think we or anyone
> should go off and design a new one.

Mua ha ha. The fearsome slacker strikes again. No, I don't think XML needs
overhauling, or even reall much minimalizing (ala SML).

> Having been privy to some of the DOM design process, I can tell you that it
> is meant to be a generic API to satisfy a lot of constituencies, and every
> API in there was done under the weight of a lot of considerations.  I don't
> agree with many of the decisions they made, but do agree on the need for
> comprimise and collaboration.  If you have something as generic as the DOM,
> it's not going to make a lot of people happy, especially considering
> people's different attitudes towards any collection classes.  (That said,
> DOM2 is a good step forward).
> 
> You don't want to create a new tree-based XML API.  What you should do is
> use the DOM, complain and moan about it, make the W3C DOM WG listen to your
> complaints, and wait about 3 years 'till it evolves, or is broken badly
> enough with things like namespaces, schema, and query, that it will be
> truly time to design another API from scratch.  Believe me, there are
> enough open issues with XML right now that no one can come up with the
> right design until those issues are settled.

Might it not be better to go ahead and add the nice friendly methods we
really want to have (if, god forbid, we can actually decide on _those_ on
the cocoon list :)), change the interfaces to what they should be, and
test it out and see how nice a non-DOM tree-based XML API could be? It's
not like we'd be expecting other programs to interoperate with our, uh,
YATBXA (yet another tree based xml api), we'd just be using it internally.

(note i'm willing to be overruled here, it's just so painful to work with
DOM when i can just feel what a good API would be like)

- donald


Mime
View raw message