Subject: [xsl] xbind:module == xsl:script + an essential layer of indirection From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx> Date: Fri, 2 Mar 2001 18:01:47 -0500 (EST) |
Steve, Thank you for your consideration. I'd like to try and explain a bit better. On Fri, 2 Mar 2001, Steve Muench wrote: > The proposal above is identical to <xsl:script> except > for the fact that your more formally defining the functions > and returns. Use Eugene's syntax instead, it is far more clear. | datemodule.xml | | <xbind:module name="date-formatting-module-uri"> | <xbind:function name="format> | <xbind:param name="date" type="string" /> | <xbind:param name="format" type="string" /> | <xbind:return type="string" /> | <xbind:comment> | This function formats a date in ISO 8601 | according to the format string. | </xbind:comment> | </xbind:function> | </xbind:module> | | <xbind:implementation xbind="date-formatting-module-uri" laguage="java"> | <xbind:function name="format"> | <class src="java:com.example.datestuff.DateRoutines"/> | </xbind:function> | </xbind:implementation> | | ... | | myxslt.xsl | | <xsl:stylesheet ...> | <xsl:script prefix="date" xbind="date-formatting-module-uri" /> | ... | </xsl:stylesheet> Take this syntax PLUS this or a similar "binding" mechanism: | 1) If the XSLT processor already knows the | module name (the language independent URI) | then the binding can be supported as a built-in | and no dynamic implementation resolution is required. | | 2) Otherwise, the XSLT processor can look in a local | catalogue file (think of this as a first-level cache). | If a sutable implemention is found there, wonderful. | For example, one could abuse the Windows registry on | an NT box to store the xsl:bind and xsl:implementation | pointing to an OLE object which implements the | langauge independent functionaltiy identifier. | Yes, not a great example, but it demonstrates | the idea of a local catalog which "install" | programs can update/modify | | 3) Otherwise, if both the xbind:module and a xbind:implementation | is included in the stylesheet that the XSLT processor can | use then great. | | 4) Otherwise, the xslt processor tries to de-reference the | module name, using RDDL to try and down load | an implementation in a language known by | the XSLT processor. | | 5) Optionally.. Ask the user for an implementation? Compare to... > <xsl:stylesheet xmlns:foo="a-language-independent-uri-that-refers-to-functionality"> > > <xsl:library implements-prefix="foo" language="XXX" src="uri"/> > <xsl:library implements-prefix="foo" language="YYY" src="uri"/> > > </xsl:stylesheet> > > Modulo the additional info about args and return types, > see your <xbind:module> plus multiple <xbind:implementation> > children as isomorphic to the sample number of <xsl:library> > elements. Certainly I am borrowing a great deal from xsl:script, however, I disagree that they are isomorphic. There is a trivial injection of functionality from <xsl:script into this <xbind:module notation, however, the injection does not bring with it the key limitation of xsl:script (tight language to functionality coupling). > They both have "a-language-independent-uri-that- > refers-to-functionality". They both list multiple implementations > of that functionality. Ok. Perhaps I wasn't being clear. Substitute a-language-independent-uri-that-refers-to-fucntionality with a-globally-unique-language-independent-uri-that-refers-to -functioality-and-may-possibly-even-be-used-as-an-rddl-url Now this (the globally unqiue requirement) makes this not anywhere near the same as implements-prefix since implements-prefix is local to a stylesheet. Furthermore: | | 0. The module identifier is opaque, allowing multiple | implementations in different languages. Even implementations | well past the authoring date of a particular style-sheet. | | 1. The xbind:module becomes primarly a declaration... and | can be used to validate the well-formedness of an xpath | expression using a module without requiring any specific | language binding. | | 2. The xbind mechanism can be a seperate specification and | used by other W3C recommendations. | | 3. This supports the "communtiy" based effort to define | extension modules. | | 4. As Jeni pointed out, it is a bit "harder" to use, due to | the layer of indirection, so perhaps it may slow down | 'casual use of the feature. For the record, I'd like to re-iterate Alexey's points: | First of all, <xsl:script> is an integral part of the XSLT stylesheet. | In contrast, <xbind:module> is intentionally an external resource. It is | never embedded into a stylesheet; it is always referenced by it. Two | layers - the stylesheet logic and the available language bindings - are | completely separated - in contrast to the XSLT 1.1 proposal where these | layers are deliberately mixed. The XBIND resources are relatively | independent on XSLT stylesheets - it is possible, for instance, | implement some mechanisms for cascading XBIND definitions (as CSS | stylesheets are cascaded) - some proposals already appeared on this | list. | | You can throw <xbind:param>, <xbind:return>, etc. away - they are very | important. They are not *additional* - they are *essential* features. | The XBIND vocabulary provides the platform-independent description of | interfaces (it is a kind of light-weight XML-based IDL). This | information may be used by XSLT processor to provide early bindings, | handle type checking and type coercion, provide platform-specific | optimization, even to generate interface reference manuals. The stubs | can be generated for platforms that do not allow dynamic function calls | (for instance, C and C++). A lot of useful things can be done with XBIND | - this is why it is moved to the separate layer. | | Unfortunately, XSLT 1.1 draft does not even try to address all these | issues, concentrating on the brutal and straightforward binding between | XSLT and Java/JavaScript. And, Adam's points: | First of all, the advantage is that the XBind is something that could be | handled by the parser not the stylesheet (ideally). This way I can | implement a well known extension in what ever way is best for my | parser. This means that I can either provide the extension myself or | provide a mechanism for allowing others | | The problem is that it is up to me, the stylesheet author, to know what | implementations are available. Frankly I don't want the hassle. I say | leave it up to the parser to do the binding. I'll do everything I can to | make it easy but it should be up to the parser to do the work. I may | even provide some help with a javascrip or even some javacode that the | parser can retrieve. If I'm feeling ambitous, I might build a web | service that I can provide a binding to as the mechanism of last resort. I hope this helps. Note, I'm not trying to "kill" xsl:script now, I'm trying to make it palatable for those who currently object to it. The primary reason why xsl:script is bad is that it binds functionality+stylesheet+language too tightly. Think of this as a 'minor layer of indirection that solves this issue, and not only that, but a layer that can be truely seperated from XSL core and used by other recommentations who also require language binding services... Kind Regards, Clark XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] RDDL as a delivery vehicl, Alexey Gokhberg | Thread | Re: [xsl] xbind:module == xsl:scrip, Steve Muench |
Re: [xsl] RDDL as a delivery vehicl, Steve Muench | Date | [xsl] FW: Coordination of <script> , Adam Van Den Hoven |
Month |