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

Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Fri, 2 Mar 2001 16:50:06 +0000
Hi Steve,

> 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.

Then you wouldn't object to changing XSLT 1.1 so that it uses Clark's
idea instead? ;)

I agree that they do the same thing, and I'm pleased about that
because there are aspects of xsl:script that would be really cool. But
I think that there are several differences that make *all* the
difference to the no xsl:script petitioners.

Most important, I think, is that the provision of functions in
different languages is broken down *first* by functionality and
*second* by language rather than (with xsl:script in the XSLT 1.1 WD)
*first* by language and *second* by functionality.  This is comforting
because it puts the emphasis on portability, on having multiple
implementations of the same function.

Next is the redirection that's required - from an xsl:script (or
xsl:library) element to an implementation-independent library
(xbind:module), to the implementations themselves.  That adds an
important extra level of modularity because a new implementation of a
function can be slotted in without having to do anything to the
stylesheet.  Again, that aids portability.

Finally, I think there's an appeal in the fact that the code itself is
not embedded in the stylesheet. I think there's an aesthetic appeal to
that, but it can also make it easier to understand what's going on.
I've lost count of the times that people who write Javascript
functions within (HTML) script elements think that they think are
accessible within the stylesheet. It would be nice to be able to just
be able to say 'no Javascript in your stylesheet is executable'.

What are the benefits that you see to the current xsl:script
definition as opposed to the idea of a separate binding? There are
obviously a couple: all this redirection will make the stylesheet a
little slower, and it's quite a bit more tedious to use an extension
function (although some might count that as a good thing). Why else is
xsl:script better?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



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


Current Thread