- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Fri, 19 Feb 2016 11:21:48 +0100
- To: "Liam R. E. Quin" <liam@w3.org>
- Cc: Michael Kay <mike@saxonica.com>, Public XSLWG <public-xsl-wg@w3.org>
Hi, 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 http://fgeorges.org/ http://h2oconsulting.be/ 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