This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: RDDL as a delivery vehicle for XSLT extensions?
- To: "'xsl-list at lists dot mulberrytech dot com'" <xsl-list at lists dot mulberrytech dot com>
- Subject: RE: [xsl] RDDL as a delivery vehicle for XSLT extensions?
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Fri, 2 Mar 2001 06:39:51 -0500 (EST)
- Reply-To: xsl-list at lists dot mulberrytech 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