cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: [Moving on] SAX vs. DOM part II
Date Tue, 25 Jan 2000 05:12:07 GMT

> 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.

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.

-scott




                                                                                         
                         
                    Donald Ball                                                          
                         
                    <balld@websli        To:     cocoon-dev@xml.apache.org            
                            
                    ngerZ.com>           cc:     John Milan <jmilan@DataChannel.com>,
"Clark C. Evans"             
                                         <clark.evans@manhattanproject.com>, Ted Leung
<twleung@sauria.com>, Scott 
                    01/24/00             Boag <Scott_Boag/CAM/Lotus@lotus.com>, (bcc:
Scott Boag/CAM/Lotus)        
                    11:11 PM             Subject:     Re: [Moving on] SAX vs. DOM part II
                         
                    Please                                                               
                         
                    respond to                                                           
                         
                    cocoon-dev                                                           
                         
                                                                                         
                         
                                                                                         
                         




On Sun, 23 Jan 2000, Pierpaolo Fumagalli wrote:

> > This discussion should be focused on answering this question:
> >  "what is the best architecture for Cocoon2?"
>
> I still think it's SAX as a transport, and hooks should be given to
> COCOON components to translate a set of sax events in DOM trees (because
> they're easier to manage).
>
> > in answering this question, we should consider both dynamic and static
> > operativity, performance, memory usage, scalability, availability of
> > implementations, degree of standardization, degree of usability, ease
of
> > use, cost of operation and time to market of a possible solution.
>
> As I said. Let's use SAX on the transport (between
> producer/filters/serializer), and each of this components is given hooks
> to translate a serie of SAX events in dom fragments.

I concur. We need SAX for fast transport between layers and DOM access
routines for use by layers if the layer prefers to work in DOM. How hard
could this be? The algorithm seems to be pretty simple. If a layer knows
that it's going to be accessed by DOM, then it could just catch incoming
SAX events and store them in a list. If and when DOM access occured, you'd
wait for all SAX events to com in and then either just scan through the
list looking for nodes or turn the list into a tree. Events would be sent
out either as incremental processing was done (for SAX processors), or the
node tree would be serialized as SAX events once DOM processing was
complete (unless you know the next layer wants DOM access, in which case
you could maybe just pass on the DOM object.

(sorry to be so pedantic, but I'm trying to convince myself as much as
anyone else)

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).

- donald






Mime
View raw message