W3C home > Mailing lists > Public > xsl-editors@w3.org > April to June 2002

Re: XSLT 2.0: function-available() for stylesheet functions

From: Jeni Tennison <jeni@jenitennison.com>
Date: Mon, 15 Apr 2002 18:53:13 +0100
Message-ID: <211160370114.20020415185313@jenitennison.com>
To: "Bohlmann, Karsten" <karsten.bohlmann@sap.com>
CC: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
Hi Karsten,

> Concerning the builtin-vs-user-defined issue, I would go even
> further: The spec should *require* implementations to *refuse* user
> function definitions in their own vendor namespace (which contains
> the implementation-defined extension functions). That way, the issue
> "which definition overrides?" would disappear, and so would the
> danger of obscure constructions like
>
> <xsl:function name="saxon:intersection" xmlns:saxon="http://saxon.sf.net/">
>  <xsl:param name="z1"/>
>  <xsl:param name="z2"/>
>  <xsl:result select="... something very different from intersection ..." />
> </xsl:function>

This would also make it harder for people to write stylesheets that
are portable across processors where one processor implements an
extension function natively and another processor does not.

For example, say that the date:format-date() function from EXSLT was
implemented natively in Saxon and not implemented in Xalan. A
stylesheet author could take the XSLT function implementation from the
EXSLT site and use that in their stylesheet, so that calling
date:format-date() would work in whichever processor was used in the
function.

Under your suggestion, this would cause an error in Saxon. Aside from
saving the WG from having to make a decision on the
built-in-vs-user-defined issue, I don't see how this would benefit
anyone?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Monday, 15 April 2002 13:53:14 GMT

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