RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1

["Clark C. Evans" <cce@clarkevans.com>]

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

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

> 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