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

Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?
From: "Steve Muench" <Steve.Muench@xxxxxxxxxx>
Date: Fri, 2 Mar 2001 09:16:42 -0800

I'm speaking only for myself in these comments, nor for Oracle
or the XSL WG. :-)

| > 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 pointed out the similarity only to illustrate how the
existing proposal already provides the same mechanisms
that Clark finds desireable. Whether or not the
appears in its own wrapping element or not is just a
question of syntax sugar in my opinion.

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

I respectfully disagree with this. The working draft is broken down
first by "language-independent-uri-that-refers-to-functionality",
then by implementation binding. It's just using the value of
the uri as the "grouping" criteria, if you will, as opposed
to introducing an enclosing element to wrap the one or more bindings.
Does having a wrapping element which allows multiple language binding
implementations versus not having a wrapping element but just the
same allowing the exact same capability of providing multiple
language bindings based on the URI significant added value, I would
argue no.

| important extra level of modularity because a new implementation of a
| function can be slotted in without having to do anything to the
| stylesheet.

I missed in Clark's proposal how new implementations could be
added without adding an extra <xbind:implementation> element
inside the <xbind:module> element in the stylesheet.

If what you're saying is that a stylesheet could <xsl:import>
another stylesheet that contains the <xbind:module> element,
and in doing that would prevent the *importing* stylesheet
from having to change to introduce a new binding, well then
that can be accomplished with the existing proposal, too.

Just have the importing stylesheet <xsl:import> a 
(to coin a new term) "library module" stylesheet that only
consists of:

  <!-- A Library Module Stylesheet -->
  <xsl:stylesheet xmlns:xsl="..."
    <xsl:script implements-prefix="cool" language="x:XXX" src="uri"/>
    <xsl:script implements-prefix="cool" language="y:YYY" src="uri"/>
    <xsl:script implements-prefix="cool" language="z:ZZZ" src="uri"/>

Then, the importing stylesheet doesn't have to change when a
new implementation gets "slotted in" to the library module stylesheet.

Did I miss something in Clark's proposal that handles this in a
radically more productive way?

| Finally, I think there's an appeal in the fact that the code itself is
| not embedded in the stylesheet. 

Clark's proposal showed both by-ref and embedded.
It should be up to the user who knows whether this
little function that they need to write will live
in an external file or be embedded. If it's a one-line
function it's a little overkill to force the user
to save it into a separate *.js file. If you are 
a user that *hates* embedding, then none of your
stylesheets will ever, ever use embedding.

| What are the benefits that you see to the current xsl:script
| definition as opposed to the idea of a separate binding?

The current proposal already separates the notion of a URI the 
represents functionality in a language-neutral way, and the idea
of separate implementation bindings, and it supports
the ability to modularize the definition of these bindings into
a separate "library module" stylesheet, if this is desired.
Therefore, having tried to reverse-engineer your requirements
out of Clark's alternative syntax proposal, the current proposal
appears to satisfy all of these requirements to me.
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly

 XSL-List info and archive:

Current Thread