- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Fri, 4 Jan 2002 14:09:57 +0000
- 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 UTC