[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 #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Re Michael and Michael,

> "(e.g., it is a built-in function ...". It seems like that should have been 
> enough to answer the original question.

I must have read it a dozen times, but it didn't click for me. What is a
built-in function in light of XPath? XPath does not have built-in functions. I
truly didn't get it and thought it was an omission. Does it make sense to
specifically *define* what an "implementation defined function" is?

In fact, I would even prefer to distinguish the two and specifically mention
functions defined by specifications and functions defined by implementations.

> an expression E1's dynamic context "comes from" whatever expression E0 caused 
> E1 to be evaluated

Makes sense to my common understanding. Still, an example I gave in bug 4378,
comment 30, which I think follows this reasoning, is contested by Michael Kay.
To stick to XPath:

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

1) Using my understanding of Michael Dyck's reasoning:
Here c sets the context of $f and it should return the name of "c".

2) Using Michael Kay's comment from bug 4378, comment 30
The context is "captured" on assignment, which means that the result of the
assignment is not focus-dependent anymore and will return the name of whatever
is in the context (probably the parent of "a").

I can understand the merits of either, but I can only find in the spec the
reasoning of Michael Dyck.

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

Received on Thursday, 12 November 2015 08:56:29 UTC