Re: XSLTInputSource

[Keith Visco <kv...@exoffice.com>]

Scott,

Scott Boag/CAM/Lotus wrote:

> > I have an application which generates SAX events,
> > these events should be used as the Source document. I didn't see any
> > "easy" way of getting Xalan to handle this properly.
>
> The XSLTProcessor interface extends DocumentHandler, and should serve your
> needs.  You can do parser.setDocumentHandler(processor).  Take a look at
> the "pipe" sample for cool things you can do with chaining trainsforms.

Ok, I didn't notice that XSLTProcessor implemented DocumentHandler. We should move this to XSLTInputSource
to make it more clear or intuitive.

>
> I hadn't thought about makeing a XSLTInputSource that implements a
> DocumentHandler.  Also, you could make XSLTDocumentHandler have a
> setDocumentHandler method (and a constructor), like the result class does.
> Do you think these are needed in light of what I said above?
>

I think we should remove the DocumentHandler interface from the processor. The XSLTProcessor, should  only
process, but not implement the DocumentHandler..
As long as we make XSLTDocumentHandler extend or implement XSLTInputSource then we will be in good shape I
think. Do you think it would be difficult to move the DocumentHandler interface out from XSLT processor?

>
> > Also I think we should revise the API
>
> Yep.
>
> > it's not the easiest API to use
> > with all the different places in which #process can be called
> > (XSLTProcessor, StylesheetRoot) and that a StylesheetRoot can be passed
> > to an XSLTProcessor
>
> Well, the XSLT file can be passed to the processor, not the compiled
> stylesheet.
>

Personally I think all the process methods should be in XSLTProcessor, since that's where it makes the
most sense. Of course both XSLTProcessor and a compiled stylesheet can both implement a generic Processor
interface, if it makes sense to do so. But I don't think the one process method in XSLTProcessor is
sufficient until we have the above DocumentHandler version of XSLTInputSource.

> > , and a Processor can be passed to a StylesheetRoot,
> > and so on...
>
> Yep.
>
> We could remove the XSLTProcessor.process, and perhaps do a static
> "compile" method on Stylesheet.  So this would look like:
>
> StylesheetRoot stylesheet = Stylesheet.compile(new XSLTInputSource
> ("foo.xsl"));
> stylesheet .process( new XSLTInputSource("foo.xml"),
>                                          new XSLTResultTarget(System.out));
>

It's ok to keep the #process method on Stylesheet, but we should not remove  #process from XSLTProcessor.

>
> Which would hide the processor altogether.  I think you have to settle on
> StylesheetRoot.process, because it would be very ugly to do a stylesheet
> property for XSLTInputSource to handle compiled stylesheets, and I would
> hate to do a XSLTStylesheetSource (I think...).    Also:
>

Yes, I agree somewhat. But it might make more sense to do an

XSLInputSource(Stylesheet stylesheet)

and the XSLTProcess can simply call a protected #process method on stylesheet

XSLTProcessor#process {
    _stylesheet.process();
}

In which case we "hide" the process method on stylesheet instead, making it look like the XSLTProcessor is
doing all the work.

In my opinion it's a cleaner API, the Processor should be doing the processing, the Stylesheet should be
used by a processor. One typically doesn't percieve a self-applying stylesheet.

>
> XSLTProcessor processor = XSLTProcessorFactory.getProcessor();
> setParamValue("arg1", "blah");  // etc., in other words, session values.
> StylesheetRoot stylesheet = Stylesheet.compile(new XSLTInputSource
> ("foo.xsl"));
> stylesheet .process(processor , new XSLTInputSource("foo.xml"),
>                                          new XSLTResultTarget(System.out));
>
> On the other hand, I hate to do away with processor.process, because it
> makes sense that a processor would be able to process.

I agree...we leave this method as it stands.

> OTOH, if we change
> XSLTProcessor to XSLTExecutionContext or something like that, this might
> make more sense sense:
>

I'm not sure, I still think we should leave this alone. Though we may need an XSLTExcuctionContext, or
merely a ProcessorContext (this is what I have in XSL:P) if there isn't already one. I thought I saw
something like that when I was looking through the source though.

>
> XSLTExecutionContext execContext = new XSLTExecutionContext ();  // Using a
> factory makes less sense in this case?
> execContext .setParamValue("arg1", "blah");  // etc., in other words,
> session values.
> StylesheetRoot stylesheet = Stylesheet.compile(new XSLTInputSource
> ("foo.xsl"));
> stylesheet .process(execContext, new XSLTInputSource("foo.xml"),
>                                          new XSLTResultTarget(System.out));
>
> I kind of like that.  The only problem is that it looks to be a bit further
> from what other processors are already doing, and so might have a harder
> time being in the direction of a standard XSLT interface (which is what we
> need to move towards, IMHO).
>
> We also need to review the other methods on XSLTProcessor (or
> XSLTExecutionContext)... the interface has far too many methods.
>

Well, removing the DocumentHandler methods will help reduce that.

>
> (In the spirit of open source, shouldn't this discussion take place on the
> xalan-dev list?)
>

ok, I'm forwarding the reply to the list, hopefully there is enough context for people to get the gist of
the conversation.

--Keith