- From: Michael Dyck <jmdyck@ibiblio.org>
- Date: Wed, 23 Mar 2016 00:28:06 -0400
- To: Public Joint XSLT XQuery XPath <public-xsl-query@w3.org>
In IRC during today's telcon, Jonathan Robie said:
> ACTION A-636-06 - done and checked in
To recap:
> ACTION A-636-06: Jonathan to ensure that the classification of functions
> implemented by an XQuery expression covers the case where the function
> body is empty.
(rev 1.129 of xquery-31/src/expressions.xml)
I'm pretty sure this commit does not address the action item at all, and
should be undone. The only change in wording is in "Evaluating Function
Calls", in the branch concerning partial function applications, which
doesn't actually have a problem with empty FunctionBodies.
Besides that, the new text has a few editorial problems:
In an XQuery 3.1 function without a 'content expression',
/F/ is the expression ().
If /F/ is not an XQuery 3.1 expression
then the new function's implementation is ...
(a)
The phrase "an XQuery 3.1 function" is not a defined term. If the reader
interprets it as meaning "any function that this spec talks about", then the
phrase "an XQuery 3.1 function without a 'content expression'" will include
more functions than you intended.
(b)
"/F/ is the expression ()". No, this text does not get to define /F/. /F/
was already defined several steps ago. Moreover, /F/ is a function, but the
expression () is not a function.
(c)
"If /F/ is not an &language; expression". This is always true, because a
function is a value, not an expression. (A function's *implementation* can
be an expression.)
--------------------------------------------
The current text's problems with an empty FunctionBody occur in the
"Evaluating Function Calls" section, in 5.b.ii:
(1)
While the test used to be
"if F's implementation is a FunctionBody"
which is easily true of an empty FunctionBody, the test is now
"if F's implementation is an XQuery 3.1 expression"
which isn't really true (or isn't obviously, clearly true) of an empty
FunctionBody. (I think this problem is what the action item is talking
about, that 5.b's case analysis doesn't clearly handle this case.)
(2)
When the text says "F's implementation is evaluated", it's not immediately
clear what that means when there isn't an Expr to evaluate.
----
I believe there are two possible ways to address these problems: either at
creation time or evaluation time.
(I)
At the point where an implementation that is an empty FunctionBody could be
created (i.e., in 3.1.7 Inline Function Expressions and 4.18 Function
Declarations), you could add text that says something like: if it's an empty
FunctionBody, instead use the FunctionBody `{ () }`. However, this is kind
of hacky, because it fabricates a FunctionBody out of thin air.
or:
(II)
In "Evaluating Function Calls",
re (1): In 5.b.ii, either reinstate the "impl'n is a FunctionBody" test,
or add something to include the empty FunctionBody possibility.
re (2): In 5.b.ii.A, add text to say that if it's an empty FunctionBody,
the value is an empty sequence. Or this could be a separate step
before the-step-that's-currently-A, but then you'd need to
slightly alter the wording of the-step-that's-currently-B.
-Michael
Received on Wednesday, 23 March 2016 04:33:41 UTC