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

Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Sat, 3 Mar 2001 08:34:18 +0000
Hi Clark,

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

The functionality (of a whole bunch of functions) is a primary object
in both methods, as far as I can see.  Both use a namespace URI to
identify a set of functions in a bunch of languages. Perhaps it's the
opacity that's the issue.  With XSLT 1.1 the implementation is *right
there* (or one step away) whereas with your proposal the
implementation is several steps away.

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

I think you should push the reuse in other specifications - that's
something that xsl:script element doesn't do. After all, there are
lots of languages that it would be handy to have access to scripts
from - HTML and SVG we've already seen, and I'm sure there are others.

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

There's nothing in the XSLT 1.1 WD that mandates that xsl:script is
the only method used to identify what extension functions to use - in
fact it specifically says that xsl:script doesn't preclude any other
method.  I'm sure that some XSLT processors will continue to provide
their regular service, e.g. resolving Java classes through namespace
declarations.

>  d) That the identifying URI also be coupled with a
>     IDL like description of the module.  

That's an issue about resolving namespaces, I think.  I think it would
be great to have a standard description format for script modules, but
I don't think that xsl:script *precludes* that.  An XSLT processor can
always use the namespace URI to get a functional description if it
wants - or you can go there and look around.  Just like getting a
schema for an XML vocabulary.

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

Yes.  I think there's a lot of potential there, but it does make it
quite a bit harder for someone to just use a little script on their
sample stylesheet.

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

Personally, I don't like automatic resolution of namespace URIs
(anything bound with xmlns:prefix="URL" is a namespace URI) because I
don't think anything should be mandated about what you find at the end
of it.  How does the XSLT processor know that a particular namespace
declaration is one for a script?  What if there *isn't* a nice bit of
RDDL that leads on (eventually) to an implementation?

Hmm... perhaps this is part of the problem.  The XSLT WG probably
don't want to start mandating things that are outside the purview of a
stylesheet.  To do so would go outside XSLT - spark up another WG,
spend another year in discussion and so on - and that's time that's
awasting.

So, what about having a community based best practice that involves
having the namespace URI used for a module eventually resolve to an
xbind:module document.  XSLT processors should use that to identify
the implementations of the functions in multiple languages.

If the processors can't use that, then they can use xsl:script
elements (or xsl:implementation elements - some term that doesn't
conjure the horrors of HTML). These indicate specific implementations
for the module. Best practice is to place these xsl:script elements in
a separate stylesheet, and to use the src attribute to point to the
code rather than embed it.

Cheers,

Jeni

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



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


Current Thread