Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 74085 invoked from network); 24 Jan 2000 18:37:33 -0000 Received: from dnai-216-15-97-206.cust.dnai.com (HELO kali.betaversion.org) (216.15.97.206) by 63.211.145.10 with SMTP; 24 Jan 2000 18:37:33 -0000 Received: from apache.org(firewall-95.exoffice.com[207.33.160.95]) (2577 bytes) by kali.betaversion.org via smail with P:esmtp/R:internet/T:smtp (sender: ) id for ; Mon, 24 Jan 2000 10:37:37 -0800 (PST) (Smail-3.2.0.106 1999-Mar-31 #3 built 1999-Sep-21) Message-ID: <388C9C16.57AC3F07@apache.org> Date: Mon, 24 Jan 2000 10:38:14 -0800 From: Pierpaolo Fumagalli Organization: Apache Software Foundation X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [Moving on] SAX vs. DOM part II References: <388B876D.B87D7761@apache.org> <388B96EB.444E15B0@apache.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. Pier -- -------------------------------------------------------------------- - P I E R - stable structure erected over water to allow the docking of seacraft -------------------------------------------------------------------- - ApacheCON Y2K: Come to the official Apache developers conference - -------------------- --------------------