This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: RDDL as a delivery vehicle for XSLT extensions?
- To: Jeni Tennison <mail at jenitennison dot com>
- Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions?
- From: "Clark C. Evans" <cce at clarkevans dot com>
- Date: Sat, 3 Mar 2001 04:19:53 -0500 (EST)
- cc: xsl-list at lists dot mulberrytech dot com, Steve Muench <Steve dot Muench at oracle dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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