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

Hi,

Most languages do not 'police' namespace usage, largely because they have no
mechanism to do. Java being one example, where the namespace for a class is
just an arbitrary string, and if I wanted to, I could put all my code in a
com.ibm package.

As XSLT processors provide groups of functions under specific namespaces,
they are in the unique position of being able to protect those namespaces
from abuse. I agree with Karsten that processors should enforce namespaces
known to them.

For example, if I import a stylesheet using an EXSLT function, it is
probably my expectation that that the funbction I am using is an EXSLT
function. If there is a bug in the function, who do I send an email to?
Probably EXSLT or the processor implementer...

A simple way of ensuring processor-independence is to wrap the (eg) ESLT
function as Karsten suggests. 

Regards,

Agnes Clarke
www.agslin.net



-----Original Message-----
From: Bohlmann, Karsten [mailto:karsten.bohlmann@sap.com]
Sent: Monday, April 15, 2002 8:41 PM
To: xsl-editors@w3.org
Cc: 'xsl-editors@w3.org'
Subject: 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/
> 


-- 
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

Received on Tuesday, 16 April 2002 06:49:56 UTC