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 04:11:11 GMT
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