Altova Mailing List Archives

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

From: "Clark C. Evans" <cce@-------------->
Date: 3/2/2001 11:15:00 PM
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.   


 XSL-List info and archive:


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.