[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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){
    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();
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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.