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

["Clark C. Evans" <cce@xxxxxxxxxxxxxx>]

On Sat, 3 Mar 2001, Jeni Tennison wrote:
> >  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.

Yes, but with the <xsl:import at least with "good style" 
one can move common scripts into single import module.
 
> >  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.

I'd be nice if there was a single mechanism that was widely
accepted across W3C technologies.

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

Yes.  Correct once again.  I know this too  ... I being VeryDense.
So.  A community based set of extension functions could be 
dreamed up, and implemented.  And, if some processors support
the xsl:script mechanism and perhaps Javascript, perhaps some
rudamentary implemetations can be given.

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

Right, as nothing precludes the addition of this later.
 
> >  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.

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

I think there is a good amount of "best practices" that can
be brought out of this.  

...

Jeni, thank you very much.   

clark


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