This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Future XSLT expansion
- To: xsl-list at mulberrytech dot com
- Subject: Re: Future XSLT expansion
- From: Tom Myers <tom dot myers at postoffice dot worldnet dot att dot net>
- Date: Tue, 21 Mar 2000 09:23:11 -0500
- Reply-To: xsl-list at mulberrytech dot com
"Steve Muench" <smuench@us.oracle.com>, 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