cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: [Moving on] SAX vs. DOM part II
Date Wed, 26 Jan 2000 02:23:22 GMT
points well taken. i have my opinions, and i know that they're right, but
i see your point. so ignore my suggestion of supplying layers with YATBXA.

so far, it seems that pier's suggestion of SAX preferred for transport
between layers/filters, with the option of DOM access at the layer/filter
level is winning the voting. if so, what's the next series of steps to

- donald

On Tue, 25 Jan 2000, Scott Boag/CAM/Lotus wrote:

> Donald Ball <> wrote:
> > 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?
> Are you so sure you know the answer to this?  Beyond the current open
> issues in the W3C concerning XML: itterators vs. counters?  Are you going
> to supply me with an document-order index?  Are you going to require that
> all XML-collections be read-write?  Should the query API be part of the
> collection classes or an external program?  Should I be able to get the
> "owner" of an attribute?  Should getParent return the element that owns an
> attribute?  If I ask a Document for it's "owner document", what should it
> return?  Do you have a object model for DTDs?  etc.
> I have opinions about these things, and so do you, and only in a few cases
> are we going to agree.  That's how the DOM came into being.  I just think
> the folks programming in have better things to do this year
> than trying to decide all these issues all over again.
> > 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.
> Any collection classes, like string classes, often have to be passed from
> program to program.  I would think there is a need for interoperability
> here.
> -scott

View raw message