You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sebastien Sahuc <ss...@imediation.com> on 2000/10/02 20:41:20 UTC
XSP engine based on SAX
Hi,
2 weeks ago we had a thread highlighting the fact that with a SAX based XSP
engine we would speed up the overall process and reduce the memory
footprint.
see :
http://archive.covalent.net/xml/cocoon-dev/2000/09/0554.xml
Unfortunately, I would prefer to wait for the Xalan2 integration before
jumping in since we should move directly to TRAX IMHO, and since the
Extension isn't fully supported in the Xalan2...
Scott we're ready on our starting block, waiting for your GO signal :-)
Sebastien
Original thought on using SAX based XSP engine instead of DOM :
When the SAX events for the original XSP document is submitted to the XSP
transformer, then when the 'processing intruction SAX event' is thrown,
the method 'processingInstruction(target, data)' acts as a controller and
set a new transformer on the fly that correspond to the stylesheet
declared in the PI. Therefore all the following SAX events are forwarded
to the new transformer we've just set up.
Then this later transformer send its result SAX events to the XSP
transformer which acts one more time as a controller. And we repeat the
loop until there is no more PI to handle.
Re: XSP engine based on SAX
Posted by Stefano Mazzocchi <st...@apache.org>.
> Sebastien Sahuc wrote:
>
> Hi,
>
> 2 weeks ago we had a thread highlighting the fact that with a SAX
> based XSP engine we would speed up the overall process and reduce the
> memory footprint.
>
> see :
> http://archive.covalent.net/xml/cocoon-dev/2000/09/0554.xml
>
> Unfortunately, I would prefer to wait for the Xalan2 integration
> before jumping in since we should move directly to TRAX IMHO, and
> since the Extension isn't fully supported in the Xalan2...
>
> Scott we're ready on our starting block, waiting for your GO signal
> :-)
>
> Sebastien
>
> Original thought on using SAX based XSP engine instead of DOM :
>
> When the SAX events for the original XSP document is submitted to the
> XSP
> transformer, then when the 'processing intruction SAX event' is
> thrown,
> the method 'processingInstruction(target, data)' acts as a controller
> and
> set a new transformer on the fly that correspond to the stylesheet
> declared in the PI. Therefore all the following SAX events are
> forwarded
> to the new transformer we've just set up.
> Then this later transformer send its result SAX events to the XSP
> transformer which acts one more time as a controller. And we repeat
> the
> loop until there is no more PI to handle.
what the hell are you talking about??
are talking about C2 or C1? C2 doesn't have any PI reaction and we won't
touch C1 with big changes... am I missing something here?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: XSP engine based on SAX
Posted by Giacomo Pati <Gi...@pwr.ch>.
> Sebastien Sahuc wrote:
>
> Hi,
>
> 2 weeks ago we had a thread highlighting the fact that with a SAX based XSP engine we would speed up the overall process and reduce the memory footprint.
+1
> see :
> http://archive.covalent.net/xml/cocoon-dev/2000/09/0554.xml
>
> Unfortunately, I would prefer to wait for the Xalan2 integration before jumping in since we should move directly to TRAX IMHO, and since the Extension isn't fully supported in the Xalan2...
But if we jump in now (with TrAX of course) we are able to support Scott with what we urgently need :)
>
> Scott we're ready on our starting block, waiting for your GO signal :-)
>
> Sebastien
>
> Original thought on using SAX based XSP engine instead of DOM :
>
> When the SAX events for the original XSP document is submitted to the XSP
> transformer, then when the 'processing intruction SAX event' is thrown,
> the method 'processingInstruction(target, data)' acts as a controller and
> set a new transformer on the fly that correspond to the stylesheet
> declared in the PI. Therefore all the following SAX events are forwarded
> to the new transformer we've just set up.
> Then this later transformer send its result SAX events to the XSP
> transformer which acts one more time as a controller. And we repeat the
> loop until there is no more PI to handle.
Yes, this is exactly what we've discussed
Giacomo
--
PWR GmbH, Organisation & Entwicklung Tel: +41 (0)1 856 2202
Giacomo Pati, CTO/CEO Fax: +41 (0)1 856 2201
Hintereichenstrasse 7 Mobil: +41 (0)78 759 7703
CH-8166 Niederweningen Mailto:Giacomo.Pati@pwr.ch
Web: http://www.pwr.ch