Subject: Standard API to XSL processors From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Mon, 11 Jan 1999 15:37:21 +0200 |
I've switched some code from using Koala to XT lately, and it got me to wonder why there's no standard interface to XSL processors - something like SAX for XML. Building on top of SAX seems reasonable; something along the lines of: public interface XSLProcessor { public void parseXSL(InputSource xslInputSource); public void parseXML(InputSource xmlInputSource, DocumentHandler xmlOutputHandler); } I suppose everyone would agree this is a good thing - witness SAX's success. God (and the devil) are in the details, though... For example: public interface XSLProcessor { public DocumentHandler getXSLHandler(); public DocumentHandler getXMLHandler(); public void setDocumentHandler(DocumentHandlet outputHandler); } Separates the XSL processor from the XML parser - the caller should obtain a parser on his own and the XSL processor takes it from there. This might be awkward for providing access to non-Java XSL processors (such as these built into some browsers), but there's something to be said for encouraging such processors to expose the XML parser part to Java as well. Defining such an interface does not seem to be a job for the XSL WG. Given that SAX is registered under xml.org, I checked whether there's an xsl.org - it seems that www.xsl.org exists but is under construction. Can anyone say anything about what xsl.org is going to be, and whether this issue is appropriate for it? Defining an org.xsl.sax package which would build upon org.xml.sax seems like the natural way to go... Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Processing Modes..., Geoff Nolan | Thread | Re: Standard API to XSL processors, Rick Ross |
RE: Processing Modes..., Ed Nixon | Date | Re: The XSL-List Digest V1 #266, keshlam |
Month |