Re: xbind:module == xsl:script + an essential layer of

On Fri, 2 Mar 2001, Steve Muench wrote:
> The only difference is that with the current <xsl:script>
> proposal, if you list three languages for the same
> namespace uri, then you save a little typing by doing:
> 
> <xsl:stylesheet xmlns:date="http://datestuff.com/xslt/extensions">
>    <xsl:script implements-prefix="date" language="lang:yyyy"
>                src="http://datestuff.com/xslt/extension/impl/dates.xyz"/>
>                src="http://datestuff.com/xslt/extension/impl/dates.xyz"/>
> 
> whereas with your proposal, you repeat the namespace uri
> each time instead of using its shortcut/prefix name:
> 
> <xsl:stylesheet> 
>    <xsl:script implements="http://datestuff.com/xslt/extensions" 
>                language="lang:yyyy"
>                src="http://datestuff.com/xslt/extension/impl/dates.xyz"/>

First, this syntax makes a big difference, it is not merely
syntax sugar.  With implements="a-unique-uri" I can now put 
all of my scripts in a module and share this module across the
organization.  With implements-prefix="prefix", I have to 
coordinate prefixes across my enterprise in order to 
have a central set of scripts?  Yuck.  Talk about a 
maintance nightmare.

Second, more than just this syntax change is needed.  I had 
posted earlier an entire "resolution" mechanism, from built-in,
to local-catalogue, to in-stylesheet, to rddl-download, to ask-user.
This syntax only addresses one part of the resolution, the in-stylesheet
type resolution (and perhaps the local-catalogue method).  In this
proposal, a <xsl:script isn't even needed.  Just a xmlns:prefix="..".
If the processor understands the built-in prefix, then great, no
implementation required!  Otherwise, this uri could be used to
search for local implementations in a local catalogue (for instance,
the window's registry). Failing that, it could always use the
RDDL or similar protocol (and, once again, I refer you to those
discussions for the relevant arguments and counter arguments).

Third, I would also ask that the "script" element is given a 
prefix of "bind" and a completely different URI.  Why?  So that
this same mechanism can be re-used by other specifications.
This does not have to be a XSLT only solution, I'm sure every
specification needs some sort of function binding.

Fourth, this bind element should also have a IDL version which
describes the signature of the module being imported.  This
is needed to syncronize an interface across multiple implementations
from different languages.

As a whole, the extension *functionality* is what is primary,
not a particualr implementation *script*. 

Is this at all clear?  

Clark



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