[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Future XSLT expansion
"Steve Muench" <smuench@xxxxxxxxxxxxx>, the "Oracle Rep to the W3C XSL Working Group", wrote that >..... a question >a Java developer might ask is: > > "What should my Java extension function return to return an > XPath node-set to my stylesheet?" > >The answer turns out to be: > > XT: com.jclark.xsl.om.NodeIterator > Saxon: com.icl.saxon.expr.NodeSetValue > Xalan: org.w3c.dom.NodeList > OraXSL: oracle.xml.parser.v2.XMLNodeList > etc. > >The spec doesn't get into the Java language bindings. > >| There is currently no standard API for producing (or using) node-set >| expressions from within an extension function, but there is no standard >| API for producing extensions at all, so this seems to be a lack of >| standard API for extensions rather than a problem with XSLT itself. > >This fact is not going unnoticed by the XSL Working Group. :-) A discussion of the options being considered by said Working Group might be nice for some of us who write such extension functions. :-) Personally I have a public static NodeIterator stringToNodeList(String xmlStr) method, e.g. select="vdoc:string-to-node-list($blip)" for use in stylesheets, and it would be just great to have it in the core, without worrying about API at all. But I also generate NodeIterators without building the corresponding XML strings, e.g. with any class that implements an interface which at the moment is just public interface NodeListData{ public void parse(DocumentHandler handler); } where the parse (parse-simulator) method simply calls on the DocumentHandler's methods as they would be called by a real parse of a real inputsource, e.g. --- public void parse(DocumentHandler handler){ try{ handler.startDocument(); for(int i=0;i<table.length;i++){ handler.startElement("row",new AttributeListImpl()); for(int j=0;j<fieldNames.length;j++){ String field=table[i][j]; AttributeListImpl attrs = new AttributeListImpl(); attrs.addAttribute("name","CDATA",fieldNames[j]); ---- and on, and on...in other words, I traverse whatever data I've got, in this case a String[][] but it could just as well be a ResultSet. It seems like an obvious technique, and I am expecting to write more and more "xsl-aware" classes which can produce themselves as nodesets. But of course they're not really "xsl-aware"...they're "xt-aware", and I'm sure other people are doing similar things and doing them better. It just seems to me that some standardization at the level of "NodeListData" (okay, with a less ad-hoc design than mine) might be easier than trying to find directly common ground between NodeListIterator, NodeSetValue, &c. Is there a collection of node-set-producing approaches somewhere? In particular, is the Working Group working with such a collection? Tom Myers XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|