cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <>
Subject Re: [Moving on] SAX vs. DOM part II
Date Wed, 26 Jan 2000 00:24:30 GMT

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

Any collection classes, like string classes, often have to be passed from
program to program.  I would think there is a need for interoperability


View raw message