Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <38A08FCD.20E2029F@exoffice.com>
Date: Tue, 08 Feb 2000 13:51:09 -0800
From: Keith Visco <kvisco@exoffice.com>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
CC: Scott Boag/CAM/Lotus <Scott_Boag@lotus.com>
Subject: Re: disable-output-escaping
References: <OF7E50AA63.BD44229D-ON8525687F.001BC140@lotus.com>
 <38A08642.2D12662F@exoffice.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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

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.

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.

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.

--Keith