This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
xbind:module == xsl:script + an essential layer of indirection
- To: xsl-list at lists dot mulberrytech dot com
- Subject: [xsl] xbind:module == xsl:script + an essential layer of indirection
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Fri, 2 Mar 2001 18:01:47 -0500 (EST)
- cc: Steve Muench <Steve dot Muench at oracle dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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