This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Future XSLT expansion


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@netfolder.com
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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]