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

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

From: Bohlmann, Karsten <karsten.bohlmann@sap.com>
Date: Mon, 15 Apr 2002 13:23:52 -0400 (EDT)
Message-ID: <67B8CED503F3D511BB9F0008C75DAD660E5453@dbwdfx17.wdf.sap-ag.de>
To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
> -----Original Message-----
> From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
> Sent: Monday, April 15, 2002 4:47 PM
> To: Bohlmann, Karsten; 'xsl-editors@w3.org'
> Subject: RE: XSLT 2.0: function-available() for stylesheet functions 
> I don't think function-available() is especially useful in 
> conjunction with
> stylesheet-defined functions (because the user knows 
> statically whether the
> function exists or not). On the other hand, it either has to 
> return true or
> false when the argument is the name of a stylesheet-defined 
> function, and it
> seems more logical to return true.

Doesn't seem logical to me. It depends on how you understand this function.
I understand it as

(1) function-available-as-part-of-the-language-implementation()

while your interpretation is

(2) function-call-will-be-successful()

but that is not even true because nothing is said about the arity or
required types.
In contrast, (1) allows at least those functions which are defined by a
standard to be identified uniquely by their name, so implementations have a
way to indicate their level of conformance.

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 ..." />

This function definition would be refused by Saxon. At first sight, this
interdiction prevents a mechanism for porting stylesheets from Saxon to
other implementations, but on second thoughts, this is not the way porting
should be done. Instead, the user should define my:intersection() and
replace occurrences of saxon:intersection() with it. For example, he might

<xsl:function name="my:intersection" xmlns:my="FUNCTION">
 <xsl:param name="z1"/>
 <xsl:param name="z2"/>
 <xsl:result xmlns:saxon="http://saxon.sf.net/"
  select="if (function-available('saxon:intersection')) then
          else $z1[count(.|$z2) = count($z2)]" />

So in order to be portable, users should keep their function definitions
strictly *out of* vendor namespaces (which isn't hard to do). After all,
what are namespaces for? Nobody (except Michael Kay) should expect he can
achieve anything by defining a function in namespace "http://saxon.sf.net/".

Karsten Bohlmann
Received on Monday, 15 April 2002 13:31:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:22 UTC