Re: Simple API for XSL?

A method with that accepted streams would probably be a good approach

#process(InputStream xmlInput, InputStream xslInput)

where xslInput could be null if the xmlInput refereced the stylesheet
using the stylesheet pi. If xslInput was not null, the processor should
use the given stylesheet regardless of any references in the xml
document.

I imagine those using SAX to read the XML document are reading it once
from the file and storing the document in a proprietary way in
memory...I could be way off-base here, but if this is the case then the
SAX approach you are indicating would be fairly tricky without some
level of collaboration or coordination on the way the document is being
stored.

--Keith

based approach would probably be a

Tyler Baker wrote:
> 
> Tim McCune wrote:
> 
> > I went ahead and wrote an interface that lets us switch XSL processors by
> > changing one line of code.  The interface is pretty simple so far:
> >
> > public String process(Document xml, String stylesheetName) throws
> > XSLProcessorImplException;
> >
> > I then wrote implementations of this interface for LotusXSL and XSLP.  What
> > other methods would be useful in such an interface?
> 
> A lot of XSL processors I would suspect won't use the DOM for the source tree
> or even the stylesheet, one popular case in point is XT.  This simple XSL API
> had quite a lot of discussion for a while and then degenerated into SAX vs. DOM
> debates about what to use for both the input interfaces as well as the result
> interfaces.  I suggested having the XSLProcessor be able to use DOM, SAX or
> both for both the input and output.
> 
> Someone suggested recently that XSL Processors are in a sense a black box.  I
> think that is a relatively accurate description.  For simple processing needs,
> an API like Tim is suggesting I think makes sense here.
> 
> Comments?
> 
> Tyler
> 
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


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