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

["Clark C. Evans" <cce at clarkevans dot com>]

On Fri, 2 Mar 2001, Kaganovich, Yevgeniy  (Eugene) wrote:
> <!-- can be made available on date-formatting-module-ns URI, 
>      e.g via RDDL -->
>
> <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:module>
> </xbind:package>
> 
> <xbind:implementation xbind="date-formatting-module-uri" laguage="java">
>   <xbind:function name="format">
> 	<class src="java:com.example.datestuff.DateRoutines"/>
>   </xbind:function>
> </xbind:implementation>
> 
> Here, I assume that anything inside xbind:implementation is specific to the
> language for which binding is defined. I'm a little unclear about namespace
> usage in attributes, but it seems cleaner to store Java-specific information
> as values inside xbind:implementation, rather than its attributes.
> 
> BTW, If it were Javascript binding, xbind:implementation may contain [a node
> with] actual Javascript code, not just external reference. Is that correct?

Yes.  Your version better encapsulates the idea, and makes it clear
that there can be more than one implementaion for a given module
and that the implementations need not come from a single point
of distribution.  So, in XSLT one would use....

  <xsl:script prefix="date" xbind="date-formatting-module-uri" />

Which binds a given module to a prefix for the stylesheet.
This has the following advantages:

  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.

As far as "identifying an implementation" I see a few methods:

  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) If both the xbind:module and a xbind:implementation is 
     included in the stylesheet that the XSLT processor can
     use then great.

  3) 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

  4) 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?

  6) Use a "fallback" if possible?

I don't know.  And I'm not an RDDL expert, so the above
is _not_ RDDL.  I'm sure the WG experts can work out
a good version of this.  The primary point is that
a language-neutral module identifier is used.  Yes?

Kind Regards,

Clark




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