Re: Future XSLT expansion.

----- Original Message ----- 
From: David Carlisle <davidc@xxxxxxxxx>


> 
> > 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