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

["Steve Muench" <Steve.Muench@xxxxxxxxxx>]

| 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" />
:
| 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).
:
| Yes, all the hassle could have been avoided if I'd put the xsl:script
| in an imported stylesheet.

Correct. So the only thing you would have in your 50 stylesheets is:

  <xsl:import href="common-date-functions.xsl"/>

or, you might depend on some web-hosted version of the library stylesheet,
at your discretion.

  <xsl:import href="http://somesite.org/xslt/ext/common-date-functions.xsl"/>

And so you have the same simplicity of maintenance as the other proposal.

| 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

I don't follow this.

An imported stylesheet that just has:

   <xsl:stylesheet>
     <xsl:output encoding="Shift_JIS"/>
     <xsl:param name="foo"/>
   </xsl:stylesheet>

seems just as much or as much *not* a stylesheet as a stylesheet
that just has <xsl:script> top-level elements in it. Both are
legal. Neither seems weird. You could, of course, adopt a personal
usage style of calling your library stylesheets something with
a different extension like *.xsltlib in which case your
<xsl:import> statements would look like:

  <xsl:import href="common-date-functions.xsltlib"/>

or

  <xsl:import href="http://somesite.org/xslt/ext/common-date-functions.xsltlib"/>

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

To me, making <xsl:script> "consciously inconvenient" would only
mean is that developers will continue using the proprietary
extension function binding mechanisms which already make this easy.

Some may feel that this is EXACTLY the way it should stay. :-)
I'm just don't count myself among them.
______________________________________________________________
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