xbind:module == xsl:script + an essential layer of ind

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