Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?

[Alexey Gokhberg <alexei@xxxxxxxxxx>]

Steve Muench wrote:
> 
> Clark,
> 
> |<xbind:module
> |  name="a-language-independent-uri-that-refers-to-functionality">
> |  <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:implementation
> |       language="java"
> |       package="java:com.example.datestuff.DateRoutines#format"
> |    />
> |    <xbind:implementation language="javascript">
> |      ...
> |    </xbind>
> |  </xbind:function>
> |</xbind:module>
> 
> The proposal above is identical to <xsl:script> except
> for the fact that your more formally defining the functions
> and returns.
> 

I do not agree. It is not identical at all. There is a fundamental
difference.

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.

> Imagine for a moment that <xsl:script> were named
> <xsl:library> instead, but went otherwise unchanged.
> 
> You then have:
> <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>
> 

This probably demonstrates that with <xsl:script> one can *emulate* some
functionality provided by XBIND. However, the well designed technology
must *enforce* use of correct design principles, not just *allow* that.

> 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. They both have "a-language-independent-uri-that-
> refers-to-functionality". They both list multiple implementations
> of that functionality.
> 

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.

Regards,

Alexey Gokhberg
Unicorn Enterprises SA

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list