XSLT -> SAX -> XSLT (was Re: Feeding DOMs to XSLT Processors

> Tangi Vass wrote:
> > I would like to know if it is possible, using XT, to chain two XSL
> > processings, feeding the SAX output events of the first one to the
second.
>
> Eric van der Vlist wrote:
> Something similar is sleeping somewhere in my to-do list :)
>
> My first *** thoughts *** of how to implement this is :

> 1) Receiver part : sub class the XMLProcessorImpl class which is
> actually using an InputSource to parse it.
>
> The load method has to be extended with something that will emit sax
> events the same way.
>
> 2) Emitter part : sub class the XMLOutputHandler which is receiving sax
> events to pass them to the receiver part.

My first thoughts lead me to the same result:
- subclass XMLOutputHandler to create a proxy to XMLProcessorImpl.Builder.
- subclass com.jclark.xsl.sax.XMLProcessorImpl to add a load method
returning the product of the Builder.
- subclass XSLProcessorImpl to add a parse method which take the new
XMLOutputHandler as parameter.

> 3) Switching : James Clark has provided the possibility to select any
> output handler :
> > A result method can also have the form java:class where java is bound to
the
> > namespace URI http://www.jclark.com/xt/java and class is the name of
> > a Java class that implements the
com.jclark.xsl.sax.OutputDocumentHandler
> > interface (which extends org.xml.sax.DocumentHandler).

I don't think hardcoding an alternative (to XML) xsl:output method in the
stylesheet is a smart idea.

Tangi

P.S.: I'm not sure I'll take enough time to test this solution because I
have a working solution with DOM as the intermediate format. For that I
extended XT (sources available on ask) by :
    -  adding void transform(org.w3c.dom.Node sourceRoot,
OutputMethodHandler outputMethodHandler) to Transform interface ;
    -  creating a WriterDestination subclass of GenericDestination ;
    -  implementing XSLTransformEngine's load methods ;



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list