> -----Original Message----- > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] > > 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 package. > So, let's see, here are the proposed changes now: > > 1) decouple TrAXTransformer from the internal Cocoon > components and make it use TrAX directly. +1 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 +100 > 3) add a <trax-factory> parameter to indicate which class > should be used as a TrAX factory. +1 > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
