Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38A0A2EE.698E1C3E@apache.org>
Date: Wed, 09 Feb 2000 00:12:46 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: disable-output-escaping
References: <OF7E50AA63.BD44229D-ON8525687F.001BC140@lotus.com>
 <38A08642.2D12662F@exoffice.com> <38A08FCD.20E2029F@exoffice.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Keith Visco wrote:
> 
> Assaf Arkin wrote:
> 
> >
> > > BTW, while I'm looking at the Cocoon code, the way Cocoon is currently set
> > > up, I don't see how any of the xsl:output options are supported.  But I
> > > could be misreading the code?
> >
> > Not supported as far as I know. We've been running into many issues with
> > encoding, etc. But Pier is in the office next to me, so I'll twist his
> > arm until he supports it :-)
> >
> 
> Stefano...the Transformer API needs some changes...

No, the Transformer API is a total piece of crap! :)

This is why I'm happy with this XSLT API definition and I've been
lobbying with Scott for pushing this (great job, dude!).

Please, consider the cocoon 1.x transformer API for what they are: a
stupid hack to make it work. It's by no means a cool or complete API,
but patching it's nonsense. In Cocoon2 we'll support whatever XSLT APi
we come up with.
 
> With the current API, the stylesheet is passed as a DOM Document to the Transformer. It's
> up to the Transformer to re-parse this Document into the internal stylesheet. It would be
> better to pass in the URI and the let the XSLT processor read in the stylesheet, which
> will be less overhead since the XSLT processor can read directly into it's internal object
> model, instead of Cocoon reading into the DOM and then the processor breaking down the
> DOM.

True. Cocoon2, being SAX based, will do much better passing the
InputSource to your transformer. That would solve the problems right?
 
> Also, the result is a Document, so all the xsl:output options, as Scott and Assaf are
> discussing above are lost. If no more processing is to be done inside of cocoon, then
> Cocoon should call a #process method with the output stream or writer so that the XSLT
> processor can handle the appropriate output formatting.

That's harder. In fact, this is something I wanted to discuss futher:
Cocoon 2 has the notion of three entities: producers, filters and
serializers.

A producer is something that produces SAX events.

A filter is something that filters SAX events.

A serilalizer is something that consumes SAX events into a ordered
stream.

So, when using xsl:output, strangely enough, XSLT becomes a serializer,
not a filter. (in the very strict design pattern sense).

I would love to distinguish between the filtering part (SAX to SAX) and
the serialization part (SAX to stream).

Question for you XSLT folks: is this possible?
 
> We also need a way to get top-level parameters initialized from FORM variables or the
> QUERY string, though this may already be in place and I am simply overlooking something.

No, you're right: it has been on the todo-list forever... I'm just too
lazy :(

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------