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 18:38:14 GMT
Mike Williams wrote:
>   >>> On Sun, 23 Jan 2000 16:03:55 -0800,
>   >>> "Pier" == Pierpaolo Fumagalli <> wrote:
>   Pier> I still think it's SAX as a transport, and hooks should be given to
>   Pier> COCOON components to translate a set of sax events in DOM trees
>   Pier> (because they're easier to manage).
> This would certainly make it possible to create very lightweight processing
> layers, and reduce the latency in the processing stream (as well as memory
> usage, etc.)
> As you say, complex processors might end up building a DOM from the SAX
> input, 'cos it's easier to deal with.  The worst case scenario is when two
> processors that use DOM internally are stacked together: the first ends up
> unwinding it's output DOM into SAX events, which the second uses to
> re-create a DOM.  I wonder how much overhead there actually is in doing
> this ... it's not going to be any worse than "Node.cloneNode(true)", is it?

Exactly... I am already doing this for the NRG rasterizer (converting
XML to images) and it consumes less memory, and takes less time, than
having the whole DOM parsed and built.

And anyway, even if two stacked processors create a full DOM tree of
their input and their output, they will end up building two instances of
the two DOM documents. Probably it could take slightly more time to
build the DOM from SAX events, but, even in the worst case, the memory
is the same.


-          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