Subject: Re: Future XSLT expansion. From: Paul Tchistopolskii <paul@xxxxxxx> Date: Mon, 20 Mar 2000 11:49:59 -0800 |
----- Original Message ----- From: David Carlisle <davidc@xxxxxxxxx> > > > But the 'node-sets' they are returning ( and RTFs also ) > > are vendor specific. > > No. If it returns something of type node-set then it is (or should be) > usable by any xslt function expecting a node-set expression. import com.jclark.xsl.sax.*; public ResultTreeFragment getSelf() { return (ResultTreeFragment) this; } 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 ? > If it is returning a vendor-specific datatype (which is allowed as well) > then that should be a variable of type other than node set, and that > variable will only be usable in extension functions that understand the > new datatype. Yes, that's about 'opaque' datatype. > There is currently no standard API for producing (or using) node-set > expressions from within an extension function, but there is no standard > API for producing extensions at all, so this seems to be a lack of > standard API for extensions rather than a problem with XSLT itself. Not realy. If I'm returning the String from extenstion - I'm fine. If I get to-node-set(String) in the core - I'm more than fine. I could write extension which is vendor-independent. Maybe that'l be not written on some paper ( no 'standard' ) - but that will work. Almost any vendor has binding of 'string' to / from java.lang.String. > Currently you have to follow the API advertised for each system and you > can't in general write an extension function that works cross platform I can write an extension function that works cross platform, if that extension function returns String. Of course, we could end defining what is 'cross-platform' e t.c., but I suggest not to start with that right now. Being possible to switch from / to Xalan from / to Oracle XSL from / to XT should be enough. > (in general that probably isn't possible anyway but hopefully the > implementors of at least the java versions will agree a common API and > namespace for extensions) Yes, that's a political workaround. Actualy I don't like when some technology is based on a hypotetical agreement between vendors. Returning Strings and allowing the typecast from Strings to node-sets is better. Much scalable. Some day I would like to use extensions written in C with Java XSLT engines. At that point it would be better to have to-node-set typecast in the core. > > Because node set *is* 'some private datatype'. > Not according to the spec, it isn't. What do you mean? As you are saying above, there is no specs about extensions, so node-set *is* 'some private datatype' ( vendor-specific ). Of course all those things are not important. XSLT is still a technology known to very small number of marginals ( growing rapidly, as I can say from monitoring DICE) and there is plenty of time to fix all the inconviniences and self-limitations that XSLT has before it will hit the market. 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: Required attribute 'version' is, Didier PH Martin | Date | How to get XML tag attribute, Loh, Huan |
Month |