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 14:09:57 +0000
Message-ID: <969369307.20020104140957@jenitennison.com>
To: DPawson@rnib.org.uk
CC: xsl-editors@w3.org
Hi Dave,

>> 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'.
>
> If we class an exslt function as 'user', via import or otherwise,
> I'd still put the user preference first, without any hesitation,
> whilst accepting your argument re speed etc. The case above (call
> the vendor from a user function of same name) I would take as an
> exception.
>
> The initial issue was:
> Issue (user-functions-vs-vendor-functions): Should user-defined
> functions override vendor-defined functions of the same name, as
> specified here, or should it be the other way around?

As I understand it, the "user functions" are those functions that are
defined by the XSLT author using xsl:function.

When you say "an exslt function... via import or otherwise", you imply
that "user functions" includes functions that are implemented by the
vendor, if they come from EXSLT. These would actually count as vendor
implementations.

Say I define math:sqrt() using xsl:function in my stylesheet (which is
nasty, deep, recursive XSLT). Say Mike has implemented math:sqrt() in
Saxon. If I run the stylesheet with Saxon, I expect the better
function to be used, and that has to be Mike's because Java is a lot
better at doing square roots than XSLT (which can only estimate them).

Also, I think it's important to recognise that "end users" (the people
actually seeing the results of the transformation) do not define their
own functions. It seems to me that the the 'end user wins' argument is
really an argument between the rights of those who view the result of
the transformation and the rights of those who are authoring the
stylesheet, which isn't really applicable in this case.

>> On the other hand, since reasonable people can obviously differ so
>> markedly in their expectations over which should win,
>
> W3C WAI never has done, nor found any reason so to do.

I might be wrong, but my feeling is that this is not an accessibility
issue. I don't think that it is in the same league as the division
between user stylesheets and author stylesheets, which seems to be
where you're drawing your analogy from. I absolutely agree with the
choice that WAI makes about stylesheets, I just don't think you're
right to apply the same reasoning to this case.

But please go ahead and prove me wrong. Can you provide an example of
a function (in existence or imaginary) that you would want to override
in your stylesheet by writing an implementation using XSLT instead,
where it's impractical to write your own function in your own
namespace instead, and use that?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Friday, 4 January 2002 09:09:58 GMT

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