RE: Simple API for XSL?

The advantage to using a stylesheet name as opposed to an input stream is
that it allows your implementation to cache stylesheets internally.  Passing
a Document makes a lot of sense to me because it can be built
programmatically, but I can see where a Reader (isn't this better than an
InputStream?) would be a valuable alternative.  So how about this:

public String process(Document xml, String stylesheetName) throws
XSLProcessorImplException;

public String process(Reader xml, String stylesheetName) throws
XSLProcessorImplException;

-----Original Message-----
From: Keith Visco

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

#process(InputStream xmlInput, InputStream xslInput)

--Keith

Tyler Baker wrote:
> 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


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