- 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