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

Re: xslt2 issues

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 4 Jan 2002 13:26:10 +0000
Message-ID: <19266742490.20020104132610@jenitennison.com>
To: xsl-editors@w3.org
Dave Pawson wrote:
>> I think the counter-example that was put forward was where the
>> stylesheet imports a third-party library such as exslt:math, where
>> the vendor has inbuilt implementations of some of those functions.
>
> If I (rightly or wrongly) import something from exslt, then its
> still my prerogative as 'user' to make use of it, despite the fact
> that Microsoft or 4xslt or Saxon may 'do it better' ?
>
> I can see the frustrated responses of end users when they 'don't get 
> what they wanted (more likely expected)' ?

What would you expect to happen in this case? I'd expect that if the
processor has a built in function of the same name and namespace, then
it would use it. A function with the same name and namespace should be
doing the same thing (otherwise you should be using a different
function!), and an implementation built into a processor is virtually
guaranteed to be more efficient at doing it than an implementation you
build yourself.

I don't want to be forced to omit the import of the EXSLT module
because I happen to be using a processor that implements the functions
- to do so would prevent my stylesheet from being portable.

I think the argument *for* allowing user-overrides of built-in
functions rests on cases where the built-in functions do something
in a way that causes I18N problems. There are places where this
might happen:

  - sorting strings
  - formatting numbers
  - formatting dates

However, XPath/XSLT seems to support locale-specific processing in the
first two cases (through collations and decimal formats), and there is
no facility to format dates in XPath anyway (thus far at least).

I'd also argue that users can always write their own functions, with
their own names, if they wish to do something different than that
supported within XPath, rather than overriding the existing functions.
I think that forcing them to do this will prevent there from being
requests such as 'I want to call the built-in function from my
overriding function'.

On the other hand, since reasonable people can obviously differ so
markedly in their expectations over which should win, a switch sounds
like a good idea (though I'd prefer that it was defined within XSLT,
perhaps allowed on a function-by-function basis through an attribute
on xsl:function, rather than left up to vendors).

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Friday, 4 January 2002 08:26:12 GMT

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