W3C home > Mailing lists > Public > public-xsl-wg@w3.org > February 2016

Re: Polyfills

From: Florent Georges <fgeorges@fgeorges.org>
Date: Fri, 19 Feb 2016 11:21:48 +0100
Message-ID: <CADyR_r2f2_YTDdnYjic8Km-nV-G16wWPna2WL+AMOcbuH95UmA@mail.gmail.com>
To: "Liam R. E. Quin" <liam@w3.org>
Cc: Michael Kay <mike@saxonica.com>, Public XSLWG <public-xsl-wg@w3.org>

We discussed this briefly earlier this week in Prague, and the
consensus was something like: "it is going to be very costly if the
user can override any standard function."  The typical example is that
an optimisation such as replacing fn:true() with the actually constant
value "true" (whatever it is in the implementation) during parsing or
compiling would become illegal.  A user could always override it to
return false.  Not even mentioning a sequence of nodes.

This is all very sensible.  There is one specific case we might want
to consider though...

I was trying to use the XPath 3.0 function fn:unparsed-text-lines()
yesterday on MarkLogic.  But it is not implemented.  And it would have
been nice to be able to provide my own.

So maybe, if we do not want the user to override existing fn:*
functions, we still might consider to allow users to define a function
in the fn:* namespace, but *only if it is not a function implemented
by the processor*.

That would solve the problem of partial standard library
implementation, as well as functions defined in the future or outside
F&O (note: "new functions" includes indeed "new arities" for an
existing function name).  Without sacrificing intensive optimisation
in early stages of the static phase.

The one issue I see to be solved though: what to do in case the
function already exists?  Is it an error or does the processor ignore
it?  In XSLT, an error would make sense as we can have use-when to
prevent the processor to even see it in case it provides the function.
But would be harder to achieve in XQuery, if they ever wanted to adopt
the same mechanism.

Florent Georges

On 8 February 2016 at 11:26, Liam R. E. Quin wrote:
> On Mon, 2016-02-08 at 08:47 +0000, Michael Kay wrote:
> [...]
>> Because this change does not require any changes to existing
>> implementations or stylesheets (it permits such changes but does not
>> require them), I see no difficulty with making it during CR.
> +1 -- although it should be tested for.
> Liam
Received on Friday, 19 February 2016 10:22:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:27 UTC