Subject: Re: Future XSLT expansion. From: Paul Tchistopolskii <paul@xxxxxxx> Date: Mon, 20 Mar 2000 13:26:19 -0800 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Future XSLT expansion., David Carlisle | Thread | Re: Future XSLT expansion., David Carlisle |
Re: Future XSLT expansion., Steve Muench | Date | passivetex, son of (XSL FO formatti, Sebastian Rahtz |
Month |