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

Hi Jeni,

the answer to your argument is right below the paragraph you quoted. Quoting
myself: :)

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

The reason why allowing user definitions to conflict with vendor definitions
is a bad idea is that there is no guarantee whatsoever that the semantics is
the same. Instead of grabbing the date:format-date() function from EXSLT, I
could just as well implement something slightly (or outrageously) different
under this name (in some well-hidden include), giving readers/users of my
stylesheet a hard time understanding/debugging it.

The way I understand EXSLT, it is an aspiring standard that strives to be
implemented (natively) by as many vendors as possible. For example,
http://exslt.org/dates-and-times is one of the namespaces that EXSLT has
reserved. So we should consider functions  http:://exslt.org/... to be in
the same league as XSLT and XPath functions; processors will report their
implementation status for these functions through function-available(). And
it should *not* be possible to supply, with xsl:function, arbitrary
(re-)definitions of these functions. Btw, the situation is not improved by
the regulation "vendor definitions override" because implementation status
is vendor-dependent, resulting in a porting nightmare.

Thus, I would refuse your suggested mechanism, which is: "Add
date:format-date() via xsl:function, and then it will be available
vendor-independently". This is a classical case of optimistic design. But
the proper approach in language design is pessimism. Expect programmers to
pull dirty tricks you didn't even dream of.

My wish for "guaranteed unique semantics of standard function names" is
satisfied if the user is forced to keep her own definitions out of standard
namespaces (which then should include http:://exslt.org/...). So, I would be
happy with

<xsl:function name="my:format-date" xmlns:my="FUNCTION"
xmlns:date="http://exslt.org/dates-and-times">
 <xsl:param name="d"/>
 <xsl:param name="p"/>
 <xsl:result
  select="if (function-available('date:format-date')) then
date:format-date($d,$p)
          else ...hand-coded implementation..." />
</xsl:function>

One might think of a special XSLT 2.0 construct to make this both prettier
and more efficient, by avoiding the run-time conditional:

<xsl:function name="my:format-date" xmlns:my="FUNCTION"
xmlns:date="http://exslt.org/dates-and-times>
 <xsl:param name="d"/>
 <xsl:param name="p"/>
 <xsl:use-builtin-if-available name="date:format-date"/>
 <xsl:result select="...hand-coded implementation..." /> <!-- not evaluated
if date:format-date() is available -->
</xsl:function>

Cheers,
Karsten

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Monday, April 15, 2002 7:53 PM
> To: Bohlmann, Karsten
> Cc: 'xsl-editors@w3.org'
> Subject: Re: XSLT 2.0: function-available() for stylesheet functions
> 
> 
> 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 19:00:20 UTC