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

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

| On Fri, 2 Mar 2001, Steve Muench wrote:
| > | 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.
| 
| Not quite so fast. 
| 
| 1) Now you need to now syncronize all of the
|    prefixes across your organizaiton.

Clark,

I think Jeni's response to your other mail hopefully
cleared up this confusion. The prefix is nothing
more than a local nickname for the namespace URI.
There is nothing sacred about the nickname, and
you can use any nickname you want. The only thing
that's important is the namespace URI for which
it's a shortcut. It's only a vehicle to avoid 
typing. Imagine writing an XSLT stylesheet like
this:

  <{http://www.w3.org/1999/XSL/Transform}:stylesheet version="1.0">
    <{http://www.w3.org/1999/XSL/Transform}:template match="/">
      <{http://www.w3.org/1999/XSL/Transform}:for-each select="foo">
        <{http://www.w3.org/1999/XSL/Transform}:copy-of select"."/>
      </{http://www.w3.org/1999/XSL/Transform}:for-each>
    </{http://www.w3.org/1999/XSL/Transform}:template
  </{http://www.w3.org/1999/XSL/Transform}:stylesheet>
      
To save all that typing, we assign a nickname to represent
the namespace uri:

  <x:stylesheet xmlns:aaa="http://www.w3.org/1999/XSL/Transform"; version="1.0">
    <x:template match="/">
      <x:for-each select="foo">
        <x:copy-of select"."/>
      </x:for-each>
    </x:template
  </x:stylesheet>

The XSLT processor recognizes <x:template> because the prefix "x"
maps in the current scope to the unique URI for the XSLT 1.0 spec
http://www.w3.org/1999/XSL/Transform.
  

| 2) You are still limited to implementations in the 
|    languages referenced in this imported style-sheet
|    since there are no other resolution mechanisms.  

Correct. The ability to reference this imported stylesheet
from a central, agreed-upon web resource would mean that
"someone else" could update the definition of supported
languages for the "library stylesheet" and your stylesheets
would never need to know. All I'm trying to point out is
that the current <xsl:script> mechanism contains all of
the ingredients necessary to push off the maintenance of
that "library stylesheet containing <xsl:script> bindings
to some central place, or it can be locally read from
your own disk, totally up to what URI you use in your
<xsl:import> statement. If you're using the JAXP 1.1
TRAX api to process the stylesheet, I believe you can
provide your own entity resolvers so that your stylesheet
might contain the URL to a centrally-maintained library
stylesheet but your "smart resolver" might realize that
it has the library stylesheet in a cache locally already.

My point is that the current proposal has been engineered
to be no more complicated than necessary to enable most
of the scenarios that you are thinking about.

| The question is, why can't the "script" element belong to 
| another, non-XSLT specification.
:
| If it is just an XSLT specification then every
| other W3C spec which needs extension function binding will go
| out and invent their own mechansim rather than re-use a 
| common mechanism.

The way this has worked in the past is that
one working group approaches another and says,
"Hey, we want to use part of what you're doing"
This is how XPath got "factored out" of XSLT
to be shared by XPointer and XSLT (also by XQuery now).
If this dynamic were in set in motion, it might make
sense to factor it out in this way.

______________________________________________________________
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