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

Re: RDDL as a delivery vehicle for XSLT extensions?

Subject: Re: RDDL as a delivery vehicle for XSLT extensions?
From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx>
Date: Fri, 2 Mar 2001 21:45:20 -0500 (EST)
implementation of date.js
On Sat, 3 Mar 2001, Jeni Tennison wrote:
> Clark's original proposal broke them down by:
> 
> * namespace contains many
>   * functions has many
>     * implementations in different languages
> 
> All of the implementations of the num:min() function are grouped
> together, as are all the implementations of the num:max() function and
> so on.
> 
> Under XSLT 1.1, the functions are broken down as:
> 
> * namespace has many
>   * implementations in different languages which involve many
>     * functions
> 
> All the implementations in Javascript (for the particular namespace)
> are grouped together, as are all the implementations in Perl.
> 
> Of course that's changed in the more recent summaries, so obviously
> this wasn't as important as I thought it was ;)

What is important, from my perspective is:

 a) The functionality is the primary object, and it
    identified by an opaque, language independent URI
    that is unique in the current context.

 b) That the implementations and/or instructions for
    binding to an implementation need not be in 
    the stylesheet itself, perferably it is a
    seperate xml structure independent of XSLT and
    re-useable by other specifications.

 c) The the method for obtaining an implementation of
    this functionality not be singluar, that is, only
    provided via xsl:script.  Perhaps even allowing for
    functions to be used with only a namespace binding;
    assuming that an implementation is either built-in,
    in a local catalogue, or perhaps downloadable via RDDL.
    
 d) That the identifying URI also be coupled with a
    IDL like description of the module.  

 e) Perhaps even the identifying URI is required to be a
    a globally unique URL that can be used to fetch via RDDL 
    a catalogue of implementations, etc.  But this may 
    be too restrictive.

> As far as I understand it, the idea in Clark's proposal is that in the
> stylesheet you have something along the lines of:
> 
>   <xsl:script implements-prefix="namespace-prefix" binding="URL" />

Yes, actually, you could go one step further.  The binding 
could be done entirely through xmlns:prefix="binding-url",
skipping the need for xsl:script altogether.

In the example below it is not

>   <xsl:script implements-prefix="date" src="date.js" />
> 
> There is a tight binding here between the namespace for the function
> and the implementation of it.
> 
> With Clark's proposal, I put:
> 
>   <xsl:script implements-prefix="date" binding="date.xml" />

  Right, or even, perhaps just the following.  

   <xsl:stylesheet xmlns:date="date.xml" ... /> 

> where date.xml is an XML file that holds various information about the
> date functions, including a pointer to the JScript implementations that
> I've constructed (or those functions embedded) (i.e. the xbind:module
> element is the document element).

Right.  Here the "date.xml" uri isn't globally unique, which
is what I'd rather have.  And then use a catalogue solution
or built-in resolution to bind the functionality. 

> With XSLT 1.1 xsl:script, I have to go through those 50 stylesheets
> and replace all the xsl:script elements (or add a new one).
> 
> Under Clark's proposal, I only have to edit date.xml - I add links to
> the Java implementations of the functions.  I don't have to touch the
> stylesheets at all.
> 
> Yes, all the hassle could have been avoided if I'd put the xsl:script
> in an imported stylesheet. But if it's good practice to place the
> binding between a namespace and an implementation in a separate
> stylesheet in case of this kind of eventuality, and that stylesheet
> isn't going to hold anything else, then it isn't really a stylesheet
> anyway - you may as well create a different kind of file to hold that
> kind of information.  You can even get it to hold other interesting
> info as well...

Exactly.

> > Clark's proposal showed both by-ref and embedded.
> 
> Yes, but the embedded code wasn't embedded in the stylesheet, but in
> the separate file containing binding information, as far as I
> understood it. That seems to be important to the no xsl:script
> petitioners.

Yes, this is important.  But what is also important to me is 
that an implemenation be obtainable through multiple methods, not
just relying on one local-lookup method.

> But having said that, you could say that the reference from xsl:script
> in Clark's model could be a local link to a local module definition
> that held embedded code, in which case it's right there in the
> stylesheet and ask why that's so different. I don't think there's a
> good answer to that.

The difference is that in the proposal I was trying to explain
(which is why Eugene's syntax is nicer) is that the binding file
need not contain every possible implementation.  That other
mechanisms may be used by the xsl processor to obtain the 
implementation.   

Thus, the focus is really on the opaque functionality identifier
and this is the primary difference. 

Thank you Jeni!

;) Clark


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


Current Thread

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