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

Hi Jeni, Michael,

this is a combined reply to both of you, and I promise it'll be my last one
on the matter :)

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Monday, April 15, 2002 11:38 PM
> To: Bohlmann, Karsten
> Cc: 'xsl-editors@w3.org'
> Subject: Re: XSLT 2.0: function-available() for stylesheet functions
> 
> You could still write a
> user-defined function for date:format-date() with completely different
> semantics and as long as you don't use it in a processor that natively
> supports date:format-date() then you'll be just fine.

Not quite. Under my suggestion, the situation would be as follows: Given
that I see a stylesheet using date:format-date(), and I know that this is a
function implemented natively at least by some processors (and I do know
that if I know EXSLT, or if I browse to the exslt.org page), I would be able
to conclude that

- either the stylesheet is using the function exactly as it is specified by
the corresponding standard (EXSLT)

- or it is not portable XSLT.

I could draw that conclusion without even going looking for a nasty
re-definition, because the spec would say it's illegal to
xsl:function-define natively defined functions. It's extremely unlikely that
an XSLT programmer would dream up a vendor namespace, or
http:://exslt.org/..., without bad intentions. (Repeating myself: After all,
what are namespaces for?) My suggested regulation is as far as we can get to
prevent such abuse: A user re-defining date:format-date() would *know* that
the fallaciousness of his program would be revealed at least by some
processors (or by someone finding the re-definition).

> there's nothing stopping me from writing an XSLT processor that works
> completely differently from how XSLT is described in the
> Recommendation.

That processor would be termed non-conformant. The problem I'm talking about
is a loophole in the language definition.


> -----Original Message-----
> From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
> Sent: Monday, April 15, 2002 11:23 PM
> To: Bohlmann, Karsten; 'xsl-editors@w3.org'
> Subject: RE: XSLT 2.0: function-available() for stylesheet functions 
> 
> 
> > 
> > (1) function-available-as-part-of-the-language-implementation()
> > 
> > while your interpretation is
> > 
> > (2) function-call-will-be-successful()
> 
> No, there's nothing about function-available that guarantees 
> that a function
> call will be successful. It's relevant to test availability 
> of functions in
> the core library, in vendor libraries, and in third-party 
> libraries such as
> EXSLT.
> 
> The important thing is that some of these third-party libraries may be
> implemented using xsl:function. The stylesheet writer 
> shouldn't care whether
> the function is written in Java, in Javascript, or in XSLT;
> function-available() should return true for all these cases.
> 
> Michael Kay

The important thing, from my viewpoint, is that function-available() with
its single string parameter only makes sense if the set of strings for which
it may return TRUE is clearly defined by a set of documents. It is useless
for program-defined functions, including EXSLT functions pasted into a
program with xsl:function (because the pasting may be erroneous for whatever
reason). That's because nothing is said about the *signature* or *semantics*
of the function name in question. If function-available('foo:bar') gives me
TRUE, this is of absolutely no use to me, *unless* it implies a guarantee
about the signature and semantics of foo:bar(). That guarantee can only come
from a standard or vendor document.

Therefore, it's my conviction that function-available() should return TRUE
only for function names implemented by the processor; and it should be
forbidden to over-define these functions by xsl:function.

Best regards,
Karsten Bohlmann

Received on Tuesday, 16 April 2002 06:47:18 UTC