This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
After the resolution of Bug 29277, some editorial errors crept in. Raising this as a separate bug as I think this is purely editorial and the related bug has already been sufficiently fixed. Bug marked editorial. 1) In in 3.1.5.1, list item 5.b.ii starts with "Otherwise". I think the "Otherwise" should be the last in the list. So either this item moves to 5.b.iii, or we remove it here and add it to the current 5.b.iii. 2) In in 3.1.5.1, list item 5.b.iii we say: "If F's implementation is implementation-dependent not an XQuery 3.1 expression" I think this is meant to say: "If F's implementation is implementation-dependent, that is, it is not an XQuery 3.1 expression" 3) We say in two occasions "or a partial application of such a function". I find this confusing with the term "partial function application". Though it is hyperlinked, I propose to change the wording to "or a partially applied function", which I experience as more confirmatory, and re-using the definition term seems appropriate here. 4) Examples were added (result of ACTION A-640-04 and Bug 29277 comment #20), but an example that shows the reason that issue was raised (assigning or not of the context item) is absent. I propose to add one for PFA and one for 5.b.ii, with a little explanation: <proposal> Example: using the context item in anonymous functions The following example will throw a dynamic error XPDY0002 let $vat := function() { @vat + @price } return shop/article/$vat() To resolve this, you can either bind the context to a local variable or add an argument to the anonymous function signature: let $ctx := shop/article, $vat := function() { for $a in $ctx return $a/@vat + $a/@price } return $vat() Or: let $vat := function($art) { $art/@vat + $art/@price } return shop/article/$vat(.) Example: partial function application of an anonymous function Using a partial function application, you can bind the context to the function's closure: let $vat := function($art, $perc) { for $p in $art/@price return $p div 100 * $perc }, $vatfn := $vat(shop/article, ?) return $vatfn(21) </proposal> I tested above examples and I believe they are correct with the current rules of this section ;).
Fixed, thanks. For the examples, I added the first example with with the first and third query. It seems to be a closer approximation of what was trying to be achieved in the first. I didn't add the second example because it seemed redundant/obvious to me. But if you think I am missing the point and want to push back on this, I can add it. I will update the html shortly, please review.
Thanks for fixing this. The point of the second example is that there's currently nothing in the spec that shows the effect of binding with partial function application. Since an anonymous function and partial function application are distinct (and led to a lot of discussion on the WG), I think it is fair to add it, even if it may be considered superfluous. The difference between the examples is that the first one *explicitly* binds the context through a variable binding. The second one *implicitly* does the same, but hides it through the PFA technique. I think it helps understanding this rather fuzzy part of the spec (not fuzzy per se, but fuzzy because it makes everybody's head spin) and by adding it it helps those people that understand spec prose better through examples than through the prose itself. Either way, I'll settle with what you come up with.
(In reply to Abel Braaksma from comment #0) > > 3) We say in two occasions "or a partial application of such a function". I > find this confusing with the term "partial function application". Though it > is hyperlinked, I propose to change the wording to "or a partially applied > function", which I experience as more confirmatory, and re-using the > definition term seems appropriate here. That wouldn't make sense. 5.b.ii and 5.b.iii are clearly mutually exclusive, so they can't both say "or a partially applied function". The current wording intends to describe two disjoint subsets of partially applied functions. We could maybe say: "or a partially applied function created from such a function" (though I'm not sure it's clearer than the current text).
I added your example that shows referencing the value as a nonlocal variable binding. I left the language mentioned in comment 3 alone.
Note that there is one more typo, 5.b.iii: "If F's implementation is implementation-dependent not an XPath 3.1 expression" missing a comma or "and", I think. Re comment#3, if we would change the language, it should, of course, be changed in both instances of this term. My suggestion was to do that to avoid confusion (I was confused), but if it increases confusion, let's not change it.
(In reply to Abel Braaksma from comment #5) > Note that there is one more typo, 5.b.iii: > > "If F's implementation is implementation-dependent not an XPath 3.1 > expression" What version of the spec are you looking at? The phrase "not an XPath 3.1 expression" was added to that sentence in the same commit that "implementation-dependent" was deleted. And that was 8 months ago. (Are you looking at the 'diffs' version without the highlighting?)
(In reply to Michael Dyck from comment #6) > What version of the spec are you looking at? The phrase "not an XPath 3.1 > expression" was added to that sentence in the same commit that > "implementation-dependent" was deleted. And that was 8 months ago. (Are you > looking at the 'diffs' version without the highlighting?) I was looking at the highlighted diff and for some reason "implementation-dependent" was not red and stroked-through. Looking at the non-diff version shows the correct sentence and after refreshing the diff version it looks good again (meaning, now it is red and stroked-through). No action needed, apologies for delaying this.