cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierpaolo Fumagalli <>
Subject Re: [Moving on] SAX vs. DOM part II
Date Mon, 24 Jan 2000 00:03:55 GMT
Stefano Mazzocchi wrote:
> [...]
> - Scott Boat

Scott "The Mississippi SteamBOAT" Boag :) hahahahaha :)
(Sorry Scott!)

> [...]
> - Pierpaolo Fumagalli, he'll play the static XML guru role.

"Guru wannabe" please :)

> [...]
> On the other hand, key issues about web operation (like content-length,
> expiration headers and such) or internal operation pose a great deal of
> problems when the DOM model is abandoned.

I don't see how, when you're using DOM, you solve the issue of the
content length.
The Content-Length must be written before the content is passed, and I
don't see how DOM can help on calculating it. I can see the memory
footprint of my in-memory dom, but that's far from being the content
The content length can be issued only when the processed document is
already in the cache (and so properly formatted), but not on the first
hit, in both cases: DOM or SAX.

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

> [...]
> 1) the adoption of W3C standards is not under discussion. We should work
> with what it's standardized "today". Proposals that rely on
> yet-to-be-finalized features or new ideas will be evaluated one by one,
> but as a general rule, we should play with the rules we already have.

Like SAX2?

> 4) this discussion will be orthogonal to the sitemap design, meaning
> that the sitemap will not make assumptions on the underlying API
> architecture used inside Cocoon.


> Ok, I'll start with my personal and very brief comment:
> "I like DOM because I'm lazy and I don't want to rewrite Cocoon, but I
> also know that Pier needs SAX support for static operation and we need
> better links between Cocoon and X*L components than DOM 1 provides. I'd
> be glad to make everyone happy without rewriting the whole thing,
> removing this debate once and forever"

I am willing to rewrite the whole thing :) I have to earn my salary
somehow :)


-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<>    <>
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <> --------------------

View raw message