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

Subject: [xsl] RDDL as a delivery vehicle for XSLT extensions?
From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx>
Date: Thu, 1 Mar 2001 15:37:35 -0500 (EST)
I have a question.  What is the primary reason for xsl:script?
With XSLT 1.0 we _already_ have extension functions.  With 
XSLT 1.1, we will have a Java and ECMA Script bingings (perhaps
in an appendix?).  So, what value _does_ xsl:script provide?
I think this is the answer:

  xsl:script provides a delivery vehicle for XSLT extensions.

The question becomes:  Are their other solutions to this problem
that could be more platform/language neutral? I think yes.
I think an RDDL mechanism for looking up and downloading 
extensions based on a language-nutrial interface would do it.  



---------- Forwarded message ----------
Date: Thu, 1 Mar 2001 15:29:32 -0500 (EST)
From: Clark C. Evans <cce@xxxxxxxxxxxxxx>
To: "Bullard, Claude L (Len)" <clbullar@xxxxxxxx>
Cc: Evan Lenz <elenz@xxxxxxxxxxx>, Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>,
Subject: RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

On Thu, 1 Mar 2001, Bullard, Claude L (Len) wrote:
> But I am concerned that getting rid of the extension element altogether
> tosses  the baby out with the bathwater.  This issue of extensibility 
> and component support is bedeviling a lot of web app languages these
> days.  An almost one for one duplicate of this is raging on the VRML
> list.  On one side, some want no extensions.  On the other some demand 
> extensions.  

To quote from the opening of the petition:

  XSLT provides an extension mechanism whereby additional
  functionality can be identified with a URI reference and
  implemented in a manner defined by a particular XSLT
  processor.  This mechanism provides an opaque layer between
  the extension function's usage and its implementation --
  allowing for many implementations of an extension function  
  regardless of language or platform.  This extension facility
  provides a rich playground where new features can be
  prototyped and even put into production.  However, to
  balance this much-needed flexibility, the syntax makes it
  clear that such added functionality is, in fact, an
  "extension" and therefore may not be portable across XSLT 

I don't think any of the petitioners seriously doubts the 
importance of the extension mechanism.  The difficulty is that
xsl:script does extension by "embedding" rather than through
a component interface which can be language independent.

Thus, an "extension function delivery vehicle" is the baby,
it is the embedded scripting that is the bath water....
IMHO, what we need is a way to specify extension components, 
and then a way to locate (RDDL?) an implementation of a
particular extension for a particular language/platform

> It seems best to ask for that, but expect a compromise such as relabeling 
> or rewriting to deemphasize the binding or to make it clear this is not 
> de facto standardization of two vendor products.  Results and perceptions
> will vary but I don't see a good alternative.

No.  I don't think re-writing will do it.  Embedding is the
problem.  Embedding should just be seen as a "implementation
delivery vehicle", we can do much better.

;) Clark

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

Current Thread