RE: Future XSLT expansion

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