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

For archive:

| The <xsl:script> proposal clearly leaves the decision to the
| processor to make. Perhaps you're simply saying that the XSLT 1.1 WD
| should make more clear that a processor can *prefer* a built-in
| implementation of functions in a given namespace, to any of
| the suggested implementations provided in the stylesheet?
| 
| This seems like a good technical point that should be clarified
| in the spec.

______________________________________________________________
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
http://www.oreilly.com/catalog/orxmlapp/

----- Original Message ----- 
From: "Steve Muench" <Steve.Muench@oracle.com>
To: <xsl-list@lists.mulberrytech.com>
Sent: Friday, March 02, 2001 2:53 PM
Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?


| | > 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.
| | 
| | First of all, the advantage is that the XBind is something that could be
| | handled by the parser not the stylesheet (ideally). This way I can implement
| | a well known extension in what ever way is best for my parser. This means
| | that I can either provide the extension myself or provide a mechanism for
| | allowing others 
| 
| The only interesting pieces of information that the <xbind:module>
| makes available for the processor to perform this hypothetical
| selection of implementation, is:
| 
|   (1) The language-neutral-uri for the functionality
|   (2) The <xbind:implementation> elements offering specific
|       examples of implementations and are hard-coded
| 
| The current <xsl:script> proposal provides exactly both
| of these same two interesting pieces of information:
| 
|   (1) A language-neutral URi for the functionality
|   (2) the <xsl:script> elements offering specific
|       examples of implementations and are hard-coded
| 
| | > Did I miss something in Clark's proposal that handles this in a
| | > radically more productive way?
| | 
| | The problem is that it is up to me, the stylesheet author, to know what
| | implementations are available. Frankly I don't want the hassle. I say leave
| | it up to the parser to do the binding. I'll do everything I can to make it
| | easy but it should be up to the parser to do the work. I may even provide
| | some help with a javascrip or even some javacode that the parser can
| | retrieve. If I'm feeling ambitous, I might build a web service that I can
| | provide a binding to as the mechanism of last resort.
| 
| The <xsl:script> proposal clearly leaves the decision to the
| processor to make. Perhaps you're simply saying that the XSLT 1.1 WD
| should make more clear that a processor can *prefer* a built-in
| implementation of functions in a given namespace, to any of
| the suggested implementations provided in the stylesheet?
| 
| This seems like a good technical point that should be clarified
| in the spec.
| 
| ______________________________________________________________
| 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
| http://www.oreilly.com/catalog/orxmlapp/
| 
| 
| 
|  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
| 
|

Received on Friday, 2 March 2001 18:29:01 UTC