This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Future XSLT expansion.
----- Original Message -----
From: David Carlisle <davidc@nag.co.uk>
>
> > But the 'node-sets' they are returning ( and RTFs also )
> > are vendor specific.
>
> No. If it returns something of type node-set then it is (or should be)
> usable by any xslt function expecting a node-set expression.
import com.jclark.xsl.sax.*;
public ResultTreeFragment getSelf() {
return (ResultTreeFragment) this;
}
What should I write if I want to return some 'node-set' from the extension
and I want that to be portable across different vendors engines ?
> If it is returning a vendor-specific datatype (which is allowed as well)
> then that should be a variable of type other than node set, and that
> variable will only be usable in extension functions that understand the
> new datatype.
Yes, that's about 'opaque' datatype.
> 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.
Not realy. If I'm returning the String from extenstion - I'm fine.
If I get to-node-set(String) in the core - I'm more than fine.
I could write extension which is vendor-independent.
Maybe that'l be not written on some paper ( no 'standard' ) - but
that will work. Almost any vendor has binding of 'string' to / from
java.lang.String.
> Currently you have to follow the API advertised for each system and you
> can't in general write an extension function that works cross platform
I can write an extension function that works cross platform, if that extension
function returns String. Of course, we could end defining what is 'cross-platform'
e t.c., but I suggest not to start with that right now. Being possible to
switch from / to Xalan from / to Oracle XSL from / to XT should be enough.
> (in general that probably isn't possible anyway but hopefully the
> implementors of at least the java versions will agree a common API and
> namespace for extensions)
Yes, that's a political workaround. Actualy I don't like when some
technology is based on a hypotetical agreement between vendors.
Returning Strings and allowing the typecast from Strings to node-sets is better.
Much scalable. Some day I would like to use extensions written in C with Java
XSLT engines. At that point it would be better to have to-node-set
typecast in the core.
> > Because node set *is* 'some private datatype'.
> Not according to the spec, it isn't.
What do you mean? As you are saying above, there is no specs about
extensions, so node-set *is* 'some private datatype' ( vendor-specific ).
Of course all those things are not important. XSLT is still a technology
known to very small number of marginals ( growing rapidly, as I can say from
monitoring DICE) and there is plenty of time to fix all the inconviniences and
self-limitations that XSLT has before it will hit the market.
Rgds.Paul.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list