Re: Future XSLT expansion.
> What should I write if I want to return some 'node-set' from the extension > and I want that to be portable across different vendors engines ? As you know, you can't. > If I'm returning the String from extenstion - I'm fine. You might be fine (well you almost certainly will be but you can't be sure) > Being possible to > switch from / to Xalan from / to Oracle XSL from / to XT should be > enough. > Yes, that's a political workaround. Actualy I don't like when some > technology is based on a hypotetical agreement between vendors. Even if teh API's for extensions were brought into line, it won't ever be really convenient to do this unless the extensions are all in the same namespace which means either an agreement between implementors (short term) or an official w3c extension namespace. > Returning Strings and allowing the typecast from Strings to node-sets > is better. ?? How in general would you get from a string to a node set? Parse it as XML? In that case why not just return the node set directly, why force the internal tree to be linearised as a string and > reparsed? > At that point it would be better to have to-node-set > typecast in the core. You obviously have something in mind since youve posted so many messages in this thread all asking for the same thing, but I don't see it. If the extension function is handling trees then it makes far more sense to pass back a tree (aka node set) than a string. If it is not I don't see how in general you can convert to a node set. David 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