This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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