Berin Loritsch wrote:
>
> > -----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.
Ok, I vote to remove the support for XT since it's dead meat.
Anybody against this?
> > 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.
Yeah, same here :/
> > 2) remove the <xslt-processor-role> parameter
>
> +100
no kidding :)
> > 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.
Exactly, probably Sylvain is the only one that uses it :)
> >
> > If I don't receive any -1, I'll go ahead and patch it.
>
> Sounds good!
Great, consider it coming.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
