[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: "Clark C. Evans" <cce@c...>
  • To: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Thu, 01 Mar 2001 15:29:32 -0500 (EST)

vrml playground
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.