Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Mon, 20 Mar 2000 10:20:46 -0800

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

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

 XSL-List info and archive:

Current Thread