[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Future XSLT expansion.
----- Original Message ----- From: David Carlisle <davidc@xxxxxxxxx> > If XSLT 1.0 had wanted to allow this usage (and I am not sure why it > didn't) then it is fairly clear that it would not have been done by > putting node-set()function into the core, but rather just by not having > the concept of result tree fragment at all, (as in the current microsoft > implementation). Such a view solves one particular problem with variables but still requires extensions which are generating node-sets to be vendor-specific ( each vendor has his own vendor-specific node-set datatype) Having node-set typecast in the core allows writing XSLT-vendor-independent extensions. The borders between variable, document, and text are mythical. If typecast could not be done - throw the exception. Forbidding typecast in principle is not a solution. It is a limitation. Another 'workaround' could be that all XSLT vendors will agree on common format of node-set ( looks impossible to me ). Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|