[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: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Sat, 3 Mar 2001 01:10:56 +0000
xslt namespace prefix bindings
Hi Steve,

> I'm speaking only for myself in these comments, nor for Oracle
> or the XSL WG. :-)

Naturally :)  I'm speaking only for myself, and not for the no
xsl:script petitioners.  I probably shouldn't have said anything,
particularly as I don't feel strongly either way at the moment...

> | Most important, I think, is that the provision of functions in
> | different languages is broken down *first* by functionality and
> | *second* by language rather than (with xsl:script in the XSLT 1.1 WD)
> | *first* by language and *second* by functionality.
> |
> | This is comforting because it puts the emphasis on portability, on
> | having multiple implementations of the same function.
>
> I respectfully disagree with this. The working draft is broken down
> first by "language-independent-uri-that-refers-to-functionality",
> then by implementation binding. It's just using the value of the uri
> as the "grouping" criteria, if you will, as opposed to introducing
> an enclosing element to wrap the one or more bindings. Does having a
> wrapping element which allows multiple language binding
> implementations versus not having a wrapping element but just the
> same allowing the exact same capability of providing multiple
> language bindings based on the URI significant added value, I would
> argue no.

I think that you've misunderstood me (or I've misunderstood you). The
grouping that I was referring to was the fact that within a particular
(namespace-identified) set of functions, 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 ;)

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

I'm not sure, but I think that the above and the rest of what you said
imply that we have different pictures of what Clark's proposal
involves.

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" />

The XSLT processor resolves the prefix to identify the namespace for a
bunch of functions. It then uses (e.g.) RDDL to identify the module
definition, which has the links to the various implementations - it
isn't situated in any stylesheet, but in a separate file.

Let's take an example.  I author 50 stylesheets for an organisation on
the understanding that they're going to be using them client-side with
MSXML.  Each of these stylesheets involves some basic date
manipulation functions that I write in JScript.  With xsl:script, I
place the following in each of my files:

  <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" />

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

Now the organisation turns round to me in the way that organisations
do and says that they're not using MSXML any more, they've decided to
use Saxon and the stylesheets don't work no more. That's because Saxon
doesn't support JScript, I say. Fix it, they say.

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

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

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.

> It should be up to the user who knows whether this little function
> that they need to write will live in an external file or be
> embedded. If it's a one-line function it's a little overkill to
> force the user to save it into a separate *.js file. If you are a
> user that *hates* embedding, then none of your stylesheets will
> ever, ever use embedding.

Well, one of the issues that's been raised about xsl:script is the
fear that it will lead to users always reverting to a language they
can handle rather than coming to know the joys of using XSLT. So I
think that, to the no xsl:script petitioners, the fact that you have
to jump through all those hoops for your one little function is a
benefit because it will discourage people from opting out to other
languages when they could use XSLT.

I guess it's a bit of a libertarian issue - should you allow people to
do all the things that they want to do or make it harder for them to
do the things that aren't good for them? Personally, I'm a libertarian
at heart so don't find this a particularly persuasive argument (though
sometimes when I see yet another post about disable-output-escaping I
think about reviewing my philosophy).

Anyway, I only wrote to object to your assertion that the two
approaches were basically the same - there must be some differences or
the no xsl:script petitioners wouldn't find xsl:script so
objectionable (even if the differences are in terms of structure and
language rather than anything to do with functionality). Now I'm just
trying to understand the pros and cons of these two possibilities so
that I can make an educated decision about whether to sign this
petition.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/



 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.