Re: Future XSLT expansion.

 
> > Having node-set typecast in the core allows writing 
> > XSLT-vendor-independent extensions. 
> 
> I can't see any use for a node-set typecast within xslt, except
> for the one special case of result-tree to node set.
> 
> Extension functions may return node-sets, if they return some other
> vendor-specific datatype, how would casting to node-set work?

Extension functions may return node-sets.
But the 'node-sets'  they are returning ( and RTFs also ) 
are vendor specific.

You can not write the Java function, returning node-set
and then just use that function with any engine.

> in general it is not at all clear what the conversion `should' be

Convert anything to node-set. 'Anything' could be RTF or simply 
text ( String ). If conversion could not be done - fire the exception.
This allows writing Java function returning String - and then 
typecasting the String into node-set not on the level of extension, 
but on the level of XSLT core. That allows writing vendor-independent 
extensions. 

> and if you wanted a node set why not use an extension function
> that returns a node set rather than one that returns some private
> datatype that needs to be coerced to a node set.

Because node set  *is*  'some private datatype'.
 
Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list