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 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Future XSLT expansion., David Carlisle | Thread | Re: Future XSLT expansion., David Carlisle |
RE: Required attribute 'version' is, Kay Michael | Date | Re: Future XSLT expansion., David Carlisle |
Month |