cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Making Xalan XSLTC work with Cocoon
Date Fri, 29 Mar 2002 10:57:49 GMT
Stefano Mazzocchi wrote:

>Sylvain Wallez wrote:
>>So what about a new VersatileTrAXTransformer that would be the "old" one
>>(i.e. doesn't use XSLTProcessor) with a configurable TransformerFactory
>>? This would then avoid a new CS used only by the TrAXTransformer and
>>the need for "hacky" subroles.
>Yeah, makes perfect sense.
>In fact, the use of XSLT 'internally' is way different than the use of
>XSLT 'externally' (that is, at the application level rather than at core


>I would go even further: I would change the *existing* TrAXTransformer
>to use TrAX directly and not add yet another transformer that
>behaviorally does the exact same thing.

Agree also. Keeping the old one only for back compatibility would 
confuse users ("Why is there 2 TrAXTransformer ?")

>So, let's see, here are the proposed changes now:
> 1) decouple TrAXTransformer from the internal Cocoon components and
>make it use TrAX directly.
> 2) remove the <xslt-processor-role> parameter
> 3) add a <trax-factory> parameter to indicate which class should be
>used as a TrAX factory.
>That's it. It is *slightly* back compatible, but I'm sure that cocoon
>users care *only* for the ability to have their own XSLT implementation
>only at user level (in fact, changing the xslt-processor component
>implementation just creates problems since we are basing our behavior on
>xalan-only features so far).
>If I don't receive any -1, I'll go ahead and patch it.
+10 ;-)


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message