Subject: RE: Future XSLT expansion From: Tom Myers <tom.myers@xxxxxxxxxxxxxxxxxxxxxxxxxxx> Date: Tue, 21 Mar 2000 15:15:56 -0500 |
I'd said: >Personally I have a > public static NodeIterator stringToNodeList(String xmlStr) >method, e.g. select="vdoc:string-to-node-list($blip)" >for use in stylesheets, and it would be just great to have it >in the core, without worrying about API at all. Didier replies: >Or a less language dependant way would be .... >..... that ECMA script be part of XSLT. ... >This way, an extension would work in any environment. The problem with a >Java centric solution is that it is not a) standard b) practical for >implementations realized with other languages like, for instance, C++. Well, at the moment (with the courage of ignorance) I'm (3) in favor of ECMAScript as part of XSLT. (Though I'm not sure how far this would solve the problems I'm talking about now.) And I'm (2) in favor of having string-to-node-list($blip) in the _core_, i.e. no language dependence at all and no ECMAScript required, just an extension to the expressions supported in the standard. And I'm (1) in favor of an API, indeed I'd like to see a Java API and a C/C++ API, preferably defined in such a way that calls-across (via JNI) are not too-too-terribly horrible, indeed ECMAScript calling Java calling C++ calling back the Java and ECMAScript should work with just the minor mindless contortions that JNI requires -- most of which can be done in advance, with a little C++ wrapper library for each Java xslt implementation and a little Java wrapper library for each C++ xslt implementation. Do you know that this is not feasible? Is there anybody on the list who works with both C++ and Java extensions to some (probably not the same) XSLT system? I don't want to push universality too far, I'm not greatly concerned with writing VBA extension functions for example, but Java and C++ should both be supported and should intercommunicate. Certainly if you wanted to call my public static NodeIterator MyNa.jspUtil.VirtualDoc.stringToNodeList(String xmlString) you shouldn't have to say ClassClass* virDocClass=FindClass(EE(), "MyNa/jspUtil/VirtualDoc",TRUE); char xmlString[]="<it><might>work</might><orelse>not</orelse></it>"; Hjava_lang_String* hxmlString = makeJavaString(xmlString, strlen(xmlString)); Hcom_jclark_xsl_om_NodeIterator* hnodeList= (Hcom_jclark_xsl_om_NodeIterator*) execute_java_static_method(EE(),virDocClass,"stringToNodeList", (Lcom/jclark/xsl/om/NodeIterator;)Ljava/lang/String;", hxmlString); which I admit is probably approximately what you'd have to say to call on my code without some standardized wrapper-work. (And I've probably gotten it slightly wrong; I'm editting an example from the "Native Methods" chapter of _Core Java_, which I used as a reference when working out the native methods -- JavaScript calling Java calling C++ -- of _JavaScript Objects_ (Wrox 98), which didn't get quite that far.) But I think that the standardized wrapper-work should be feasible, and should make it feasible for you to call on my code or for me to call on yours reasonably cleanly, C++ -> Java or Java -> C++, not on the level of NodeIterator which would restrict it to a single XSLT implementation, but on the level of an abstract class (in C++) or interface (in Java) which you subclass (in C++) or implement (in Java), defining how you want to call on a DocumentHandler. And I was calling that class[interface] "NodeListData" because all it does is wrap the data for a nodelist (nodeset, NodeIterator, whatever). And that could be done by adding a few lines of code to each XSLT implementation; they would still be generating their NodeIterators, NodeSetValues, NodeLists or whatever. Am I blathering? Yeah, maybe. Sorry. But I really want to hear people thinking about it, and this is about all I can do. ... >If I where to put a priority on the agenda of the XSLT WG this would be the >question of scripting (what is the standard script language that can be made >part of the recommendations - What are the basic functions/objects added to >the core scripting language that make sense in the context of XSLT). Maybe >the XSLT WG needs the equivalent of the DOM WG (for the objects/functions >added to the "official" script language - this, in addition to the actual >DOM objects). > >This whole discussion just emphasize the fact that a script language is >badly needed to fulfill our so diverse processing needs. This also shows I dunno; it is not obvious to me that ECMAScript should know about data base query results, or that it should try to encompass any large part of the range of possible objects to be, as I was saying, "xsl-aware", able to feed themselves into a DOM tree by talking to a DocumentHandler. That's something they should do themselves. But maybe I'm not following the scope of your proposed use/extension of ECMAScript. (I'm usually not following something.) Say on.... Tom Myers XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Future XSLT expansion, Didier PH Martin | Thread | RE: Future XSLT expansion, Didier PH Martin |
Re: document() runs out of memory, Myriam_Midy | Date | How do you test for "if something e, Jonathan Asbell |
Month |