Re: Future XSLT expansion

[Tom Myers <tom.myers@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

"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