Re: Future XSLT expansion.
> 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. That is changing the stylesheet. That is easy ( of course, I would be happy if vendors will agree on a common namespace, but if not - changing a few lines in the stylesheet header is not a big deal). Changing the Java code of extension is much harder. > > 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? Exactly like document() hack works. It is turning text into node-set. Why the same could not be done with just the text ( String ) ? > In that case why not just return the node set > directly, why force the internal tree to be linearised as a string and > > reparsed? To have it portable means vendors should agree on the common NodeSet class. That is possible, but that is harder than placing to-node-set( String ) into the core. > > 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. I have the same thing in mind right from the beginning. That's not my problem than instead of reading my letters I was bashed as a student, who has to read XPath specifation, address everything in this world with URIs and ignore the ( de-facto existing ) node-set() typecast. I had to repeat my explanations. ( and I still have to, because all the arguments for to-node-set() typecast are already in the thread in my first or second letter ). > If the extension function is handling trees then it makes far more sense > to pass back a tree (aka node set) than a string. Yes. So instead of introducing to-node-set typecast into the core you suggest: a. Add one more 'hidden' typecast ( variable -> node-set ). b. Ask all vendors to use a common NodeSet class ( 'political' typecast ). That could be done ( but that's solving one particular problem after another, and still gives no way to capture the external text with the help of 'correct' document() ). I need to review some other places in the specs - there could be some more problems with missing typecast. When system has some non-obvious datatypes and the typecast from/to core datatype is missing in the system - the system should have some more problems with that. to-node-set typecast() still will be more scalable, because it at least gives some chance to use C extension ( returning String ) with Java XSTL engine. > If it is not I don't see how in general you can convert to a node set. Exactly like document() works ( because the real semantics of document() is to convert some text to node-set ). 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