cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: Making Xalan XSLTC work with Cocoon
Date Fri, 29 Mar 2002 13:40:27 GMT
> -----Original Message-----
> From: Stefano Mazzocchi [] 
> 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 level).
> 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.

:) In that case we should also decide whether we will officially
support the XT package.  It has not been maintained since 1999,
and is behind the times in both SAX conformance (it is level 1 and
Cocoon2 is level 2), and in XSLT spec conformance.

If we get rid of it, we can get rid of the cruft that we have to
wrap SAX1 XMLParsers with SAX2 XMLReaders.  Which also means that
we can say we require all SAX2 compliant components.  We can get
rid of some deprecation messages, and simplify the cocoon.xml

> So, let's see, here are the proposed changes now:
>  1) decouple TrAXTransformer from the internal Cocoon 
> components and make it use TrAX directly.


Actually I would like to see a complete rewrite of the compiled
XSP/Sitemap section, but since I can't put in the cycles, I can't
force it to happen.

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

The people it affects most are ones who used the <xslt-processor-role>
which are few in number.

> If I don't receive any -1, I'll go ahead and patch it.

Sounds good!

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

View raw message