cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Making Xalan XSLTC work with Cocoon
Date Fri, 29 Mar 2002 15:50:04 GMT
Berin Loritsch wrote:
> 
> > -----Original Message-----
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > 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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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


Mime
View raw message