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

Hi Karsten,

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

OK, so to support users in creating portable stylesheets, EXSLT would
have to define two namespaces for each module: one for the
vendor-implemented versions of the functions and one for the wrapper
functions that call the vendor-implemented versions if they're
available and user-defined code if not.

If you saw a call to the version in the implementation namespace in a
stylesheet, you could guarantee that either it wouldn't work at all
(because there's no built-in support for it), or it would work as
specified (given that there's not a bug in the vendor's

To get the benefit of portability, which is the whole point of EXSLT,
users would have to use the wrapper functions, but as you've said, you
can't make any guarantees about what people do in that namespace -- as
a user-defined function, it could do anything.

I think I'm still missing the point here -- what benefit does this
give? As far as I can see, all it's done is push the problem of people
doing stupid things out to another level, where if anything it's
harder to spot.

At least with a single namespace (and given that built-in functions
override user-defined functions) you have the guarantee that if you
use the stylesheet with a processor that you know has built-in support
for an extension function, that function will operate according to the
spec (barring bugs). With a separate namespace for the non-built-in
versions, you don't even have that guarantee.



Jeni Tennison

Received on Tuesday, 16 April 2002 07:35:01 UTC