[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: Future XSLT expansion
Subject: Re: Future XSLT expansion From: Tom Myers <tom.myers@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 21 Mar 2000 09:23:11 -0500 |
"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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
errors when validating stylesheets , Carsten Ullrich | Thread | RE: Future XSLT expansion, Didier PH Martin |
Re: Future XSLT expansion., David Carlisle | Date | PIs with XT, Beckers, Marc |
Month |