[Bug 29277] [XP31] Evaluating function calls does not mention evaluation of dynamic or static function calls that have no FunctionBody

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29277

--- Comment #4 from Michael Kay <mike@saxonica.com> ---
The definition of the phrase "functions with an implementation-defined
implementation" is in XDM §2.8.1:

*implementation*: This enables the function, when it's called, to map instances
of its parameter types into an instance of its result type. The implementation
is either:
a host language expression, which is always associated with a static context,
or
an implementation-dependent function implementation, which is optionally
associated with both a static and a dynamic context.

Now, as I say, it's very unfortunate choice of terminology, because there's
nothing implementation-dependent about a function like "name", except of course
for the internal implementation; and whoever chose this phrase had some kind of
twisted logic that says "the implementation of name#1 is different for each
XPath implementation, therefore we will refer to it as a function with an
implementation-dependent implementation". But it's a classic case where 95% of
readers, if they get this far, will misunderstand what we are saying because of
a poor choice of language.

On the second point:

self::a / 
  let $f := name#0
  return b/c/d/$f()

the value returned by $f() is "a", not "d".

The explanation is in XP31 §3.1.6

<quote>
Furthermore, if the function referenced by a NamedFunctionRef has an
implementation-dependent implementation, then the implementation of the
function returned by the NamedFunctionRef is associated with the static context
of this NamedFunctionRef expression and to the dynamic context in which it is
currently being evaluated.
</quote>

Again, a horrible sentence (especially the use of "associated to"). The
antecedent of the last "it" is unclear: it is referring to the NamedFunctionRef
being evaluated, not to the function being evaluated. We spent many happy
Tuesday afternoons deciding these matters and the spec is sometimes
disappointing in the way it reflects the outcome.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 12 November 2015 09:20:03 UTC