W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2002

Re: Congrats on the latest WD ::: http://www.w3.org/TR/2001/WD-xs lt20 -20011220/

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 18 Jan 2002 12:23:34 +0000
Message-ID: <122963950577.20020118122334@jenitennison.com>
To: "Kay, Michael" <Michael.Kay@softwareag.com>
CC: "'xsl-editors@w3.org'" <xsl-editors@w3.org>, Raja Cherukuri <raja.cherukuri@telera.com>
Hi Mike,

> A common <xsl:script> element to define mappings to external
> implementations only makes sense if the external implementations are
> likely to work with any processor. If different implementations are
> needed for different processors, an implementation-dependant binding
> mechanism is more appropriate.

Sure. But I think this will lead to more trouble than it's worth when
(and I mean *when*!) two implementations *do* adopt the same language
binding.

What I imagined was that xsl:script would have a language attribute
that takes a qualified name that indicates the language binding for
the relevant implementation. Taking the example you gave, I'd like it
to be:

<xsl:script namespace="some" language="saxon:java"
            class="my.extension.class.SaxonWrapper" />
            
<xsl:script namespace="some" language="xalan:java"
            class="my.extension.class.XalanWrapper" />

<xsl:script namespace="some" language="msxsl:jscript">
  function extension {
    do it!
  }
</xsl:script>

In other words, let the language attribute determine what language
binding is used, not the name of the element that's used to point to
the implementation.

Then, say that EXSLT defines a Java language binding. Then you can
simply have:

<xsl:script namespace="some" language="exsl:java"
            class="my.extension.class.Function" />

and whatever processors support that language binding would be able to
use the implementation.

This has three advantages for me as the author:

  - I don't have to worry about whether I've added the correct
    extension elements for all the processors that I know support the
    exsl:java language binding.

  - I don't have to worry about updating the stylesheet every time a
    new processor comes out that supports the exsl:java language
    binding.

  - I don't have to worry about what happens if someone tries to run
    this stylesheet with an older version of Saxon (say) that doesn't
    support the exsl:java language binding, because the older version
    of Saxon will just use the implementation indicated by the
    saxon:java language binding instead.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Friday, 18 January 2002 07:23:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:52 GMT