completed action A-634-??: propose changes to "Evaluating Function Calls"

(Today's minutes haven't appeared yet, so I can't give the exact number or
wording of the action item. But I was to propose alternative text for
XQuery/XPath section 3.1.5.1 "Evaluating ... Function Calls".)

I've attached the HTML rendering for my proposal for this section
as it appears in the XQuery doc.  (The XPath version isn't much different.)
The diff-highlighting is for my changes relative to the CR text.

The following notes will walk you through the changes in the order they
appear in the attachment.

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

---------------
[5.a]

In step 5.a ("If FC is a partial function application"), where it said:

     * implementation:
         The implementation of F, associated with the same contexts as in F.
         If these contexts are absent in F, it is associated with SC and DC.

I changed this to:

     * implementation:
         The implementation of F.  If this is implementation-defined, then
         the new function's implementation is associated with a static
         context and a dynamic context: if F's implementation is associated
         with contexts, then those are used; otherwise SC and DC are used.

The insertion of "If this is implementation-defined" is because if the
implementation is a FunctionBody, you don't need to be associating it with
contexts.

The rest of the rewording is to address some of Abel's questions in comment
15 of bug 29277.

----------------------
[5.b]

In step 5.b ("If FC is not a partial function application")...

I started with the CR text for 5.b.  Recall that there, the case analysis is
just FunctionBody vs no FunctionBody (roughly speaking), as opposed to the
analysis in the current editor's draft, into various kinds of function.

To help the reader, I added a sentence introducing the case analysis.

And to address the *original* problem in Bug 29277, I swapped the
order of the two cases, as Tim Mills suggested in comment 13.

In the "FunctionBody" case:

     To help clarify the scope of this case, I added a parenthetical list of
     function kinds.

     And I added a sentence about the static context for the evaluation,
     since the reader might wonder why it's not mentioned.

In the "no FunctionBody" case:

     To help the reader, I linkified the various function kinds in the
     parenthetical list.

     To address Mike Kay's concern in comment 14 of bug 29277, I applied
     approach #2 ("the processor makes infomation available") from
     https://lists.w3.org/Archives/Public/public-xsl-query/2016Jan/0005.html
     (approved at meeting #628), with some wording changes.

     To fix a bug, I added F's nonlocal variable bindings as something that
     the processor makes available to the invocation.  (This is important if
     you have a partially applied function whose implementation isn't a
     FunctionBody, e.g., it's derived from a built-in.)

     The minutes for meeting 628 also give some normative text as an
     alternative to the Note I suggested. I've included that here too,
     so people can consider it in context.

Note that this proposal is essentially orthogonal to the matter of how
functions are partitioned into kinds, and how those kinds are named
(see https://www.w3.org/Bugs/Public/show_bug.cgi?id=29509).  The resolution
of that bug might have an effect on this text, but it would be minor.


And while I preparing this, Mike Kay made his own proposal for 5.b:
https://lists.w3.org/Archives/Public/public-xsl-query/2016Mar/0007.html
so while you read this proposal you might want to have that in mind too.

-----------------------------------------------------------------------

-Michael