Re: Future XSLT expansion.
----- Original Message ----- From: David Carlisle <davidc@xxxxxxxxx> > > Exactly like document() hack works. It is turning text into node-set. > No actually, it is returning an XML tree (node-set) as a result of > passing a URI to a server. There never need have been a linearised form > of the document returned, it could be the result of a database query. > Or the parsing of some other syntax than XML that has a SAX parser. I don't understand what you are saying here. I have document(URI) in my stylesheet. The stylesheet is processed by XSLT engine. What happens inside the XSLT engine from your point of view? It takes the URI. It then sends it to the 'server' and 'server' returns the 'node-set' ? There is some standard client-server protocol which understands 'node-sets' ? How can 'server' return 'node-set' ? 'Server' returns text. String. XML file. > > Why the same could not be done with just the text ( String ) ? > Actually a string-parse() function that took a string and returned > a node set might be useful in a few special cases, but I wouldn't > like to see that all interfacing to external documents and extension > functions went through such an interface, that would appear to > lose far too much functionality. What in particular is lost after adding the node-set typecast ? > > 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. > > even if you had a function converting strings to node sets, you'd still > want the common API for node set expressions, otherwise what would you > do with _arguments_ to the extension function that were node sets, > surely you don't want to linearise them do you? Why not? That's actualy the only way just to ship one compiled .jar file with some extension and that extension will then work with *any* XSLT implementation. The only way to achive the same level of scalability without this is to ask all XSLT vendors not only to use the same name for NodeSet class, but to use exactly the same *class*. Asking vendors to use the same name only allows not changing the code of the extension, but still means that each extension should be recompiled to be used with particular engine. Not that bad, of course ( but we are still not there, BTW ). I have nothing against the unified API, but I still think that having typecasts in the core will be much easier to achive. I have nothing against passing node-set to the extension and getting node-sets back from the extension - that's more efficient. Minor downside is that in the 'typecastish' world it is a bit easier to build some part of the tree on the level of extension, then append some other parts on the level of stylesheet ( with concat(), for example), and then convert the resulting tree into node-set and to do stuff like that, but that's realy a minor advantage. Building any dataflow on top of some complex type ( node-set ) is for sure more efficient than builiding it on top of simple type ( string ), but it is also for sure more complex thing to implement and to support. I would like to have both things. Bunch of servers and clients exchanging unified node-sets, servlet session returning node-set, HTTP request provided by Apache in the form of node-set, the same NodeSet class shared by every XSLT vendor e t.c. - real interoperability - very cool. Unfortunately, I can not belive that this bright new world will happen tomorrow. In the meantime converting the simple String into node-set will do the job in most cases. > > I was bashed as a > not by me, I think Yes, and I should apologize because you got a side effect of earlier bashing. I have been waiting for appropriate moment to apologize ;-) > > after another, and still gives no way to capture the external > > text with the help of 'correct' document() ). > > The two issues are quite distinct. You still want the API for node set > (and other types) in extension functions even if you had a version of > document that returned a string (or a text node). Actually you could > import non XML text files now given a suitable server that served them > as a text node, but as noted in the spec more convenient ways would be > better To me the issues are not distinct. There are some core types in XSLT ( string and node-set in particular ). Having a conversion from one type to another is natural and easy way to solve wide range of problems in the uniform way. All I want is conversion between 2 core types to be in a core, but not in the status it has now. Some problems could be solved without such a conversion ( adding hidden typecasts to some places ), but I still think that's not a good way to do it. 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