This is the mail archive of the
mailing list .
RE: RDDL as a delivery vehicle for XSLT extensions?
- To: Michael Kay <mhkay at iclway dot co dot uk>
- 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 00:07:16 -0500 (EST)
- cc: xsl-list at lists dot mulberrytech dot com
- Reply-To: xsl-list at lists dot mulberrytech dot com
I present an alteranative to xsl:script at the bottom that
satisfies your reason and also is more portable.
> The primary reason is to allow users to write extension functions
> that are portable between one XSLT processor and another, as opposed
> to the current situation where extensions written for Saxon don't
> work with Xalan. I still find it hard to understand why this should
> be thought such an undesirable objective.
This is a worthy goal. However, xsl:script does not allow a Java
extension written for Saxon to work with Uche's or Alexey's processors
since they are not Java based. I think the scope of the requirement
should be either broadened to take into account non-java XSLT processors
and perhaps other W3C technologies or dropped.
How to broaden? Let's start with the example in the current WD.
<xsl:script implements-prefix="date" language="java"
Assume that "com.example.datestuff.DateRoutines" becomes very
popular indeed, copied everwhere in all of your stylesheets.
It would now be near impossible for your stylesheets to be moved
over to a XSLT processor which did not support java xsl:script.
Certainly you could go through each of them and add the
requisite Python or VB code... but you _must_ admit. There
is significant "lock-in" here. Your stylesheets are _not_
Now, consider the following.
<xbind:param name="date" type="string" />
<xbind:param name="format" type="string" />
<xbind:return type="string" />
This function formats a date in ISO 8601
according to the format string.
How is this different?
1. This language uses an opaque identifer that is
language independent. This identifier can be
associated in a python based XSLT processor,
for example, to find the required functionality
even if such functionality is not included as
code within the xbind document...
2. This binding syntax tells the W3C processor exactly
what to expect from the imported function. Much like
a Visual Basic "Declare" style to import C functions
from a DLL into the visual basic function space.
3. This clear description (Call it XMLIDL?) can be used
by others to at least try and produce an implementation
in another language...
4. This is a seperate W3C specification, and thus xbind
can be used by DOM, XQUERY, or any other language that
needs to call-out to other programming languages.
5. The above xbind module could actually be stuffed away
in RDDL or similar format so that the binding
information can be queried. In fact the language
independent URI could be a URL to fetch the xbind:module.
6. If the processor knows the xbind name, then the xbind
module isn't even needed, as the functionality can
In short, there are other options if portability of extension
fuunctions are the prime concern. If simple importation of
Java constructs is the goal, then xsl:script as it stands
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list