Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3E398121.9030705@yahoo.de>
Date: Thu, 30 Jan 2003 20:46:41 +0100
From: "J.Pietschmann" <j3322ptm@yahoo.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: XSL Security question
References: <1043835062.15080.46.camel@guru.ddd.co.za>
	 <3E37EF84.90501@apache.org>  <3E383B08.50602@yahoo.de>
 <1043908233.31031.12.camel@guru.ddd.co.za>
In-Reply-To: <1043908233.31031.12.camel@guru.ddd.co.za>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Timberlake wrote:
> Could I turn the handle the URIResolver specificaly for certain
> Transformers or would any changes effect the entire cocoon application?

In Cocoon the transformer's URIResolver is already used by
Cocoon's own resolver, and AFAIK there is no easy way to
hook in there.

>>Certain extension elements and functions already provided by
>>the XSLT processor are also a concern, in Saxon you can turn
>>them off summarily by a configuration setting.
> 
> Again, would this end up being application wide or could you deal with
> this for on Transformer only.

This can be handled by a slightly hacked XSLTTransformer
which can be used side-by-side with unmodified transformers,
the same way you can use multiple serializers and parsers
in your application.
But who needs XSLT extensions anyway? :-)

J.Pietschmann


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org