Subject: RE: Future XSLT expansion From: "Didier PH Martin" <martind@xxxxxxxxxxxxx> Date: Tue, 21 Mar 2000 16:12:13 -0500 |
Hi Tom, Tom said: 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. Didier replies: So if we want a standard way we'll have to wait for the next recommendation. Until then, a note could be made that says that Ecma script is the language of choice for XSLT scripting and even specify some functions. At least, we can have all the implementation that can adapt to it. But if I understand well your point, you want this new function to be added to the core language not as a function available through a script language. Tom said: 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. Didier replies: These are off course implementation specific problems, what is important though is that we have a standard script language and that the language has standard functions (like the DOM for instance). [... long example about extensions implementation ...] Each time you add new functionality outside of the recommended script language (if we say that ECMA script is the official XSLT script language) or the recommended XSLT language itself you augment the risk to have a non portable style sheet. Tom said: 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.... Didier replies: Data base access with other methods than the one proposed by Oracle and Microsoft and that are based on XML are more problematic and are probably non portable from XSLT a particular engine to an other XSLT engine. This said, I am not against extensions, as long as we are concious that our resulting style sheet are proprietary. This is the same thing as having a standard script language and a set of specified object/function. In this latter case, the script or the script library is portable to any engine compliant to a recommendation. Cheers Didier PH Martin ---------------------------------------------- Email: martind@xxxxxxxxxxxxx Conferences: Web Chicago(http://www.mfweb.com) XML Europe (http://www.gca.org) Book: XML Professional (http://www.wrox.com) column: Style Matters (http://www.xml.com) Products: http://www.netfolder.com XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Future XSLT expansion, Tom Myers | Thread | PIs with XT, Beckers, Marc |
How do you test for "if something e, Jonathan Asbell | Date | Re: fo:block formatting question, Nikolai Grigoriev |
Month |