This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(para 1 vs para 2 and the rule) More subtly, in para 1, Expr is "evaluated within" Expr1, whereas in para 2 and the rule, Expri is a subexpression of Expr. The difference occurs with functions, where the body of the function *is* evaluated within the function-call that invoked it, but is *not* a subexpression of that call. This distinction wouldn't be so important if function calls "manually" propagated errors from the function body to the call, but it looks like they don't. "There are several expressions, such as [4.6 Logical Expressions] and [4.11 Quantified Expressions], that do not necessarily propogate an error raised by some sub-expression." But actually, that's true of *all* expressions, as 3.3.4 explains. "For each such expression, we give specific error inference rules." And those rules include something like the rule given in this section. (In fact, the rules in 4.6 are exactly equivalent to this rule.) So 4.6 and 4.11 are not exceptions to the default rule. The problem with this rule, however, is that it allows me to infer an error where you don't want me to. Consider it with these bindings: Expr is let $v := 3 return $v+5 Expri is $v+5 (so Expri is a subexpression of Expr) dynEnv is dynEnvDefault If we evaluate $v+5 in dynEnvDefault, we'll get an error, because $v is unbound. So we have dynEnv |- Expri raises dynError This then allows us to conclude dynEnv |- Expr raises dynError i.e., the whole query raises an error. Which of course it shouldn't. The problem is that the rule uses the same dynEnv to evaluate the subexpression as the expression, which is not always appropriate. So some of the places that refer to 3.3 for their error propagation shouldn't: 4.7.3 Computed Constructors 4.7.3.2 Computed Attribute Constructors 4.8.3 Let Expression 4.12.2 Typeswitch
This is a very good comment. We have clearly some inconsistencies in at least two ways. First there are cases where we give special case rule instead of relying on the general rule, at least 4.6 and 4.11 that you point out. Second there are cases where we should give special cases instead of relying on the general rule: 4.7.3 Computed Constructors 4.7.3.2 Computed Attribute Constructors 4.8.3 Let Expression 4.12.2 Typeswitch In addition, we should make sure that: 3.3.4 is consistent with the XQuery spec 3.3.3 should be changed to point to the error and optimization section directly. A more drastic approach would be to remove the material on error propagation entirely from the Formal Semantics document. This would be ok considering that this part of the text is not necessary for static typing and therefore is non normative. Do you have preferences either way? Thanks, - Jerome and Michael
(In reply to comment #1) > > A more drastic approach would be to remove the material on error propagation > entirely from the Formal Semantics document. Including the removal of all "Dynamic Errors" sections? That is drastic! But I'm inclined to think it's a good idea: -- The FS doesn't attempt to be complete on errors *anyway* (i.e., it doesn't refer to specific error codes, and it totally ignores static errors). -- I suspect that most of the 'Dynamic Error' rules cover cases where the Dynamic Evaluation rules would simply fail to hold, and the inference would fail to yield a value. So in a sense, the 'Dynamic Error' rules are redundant. (Interestingly, I have a feeling that this is *not* true of many/most? static errors.) -- It would eliminate a fair bit of bulk, and some of the ickier rules.
Thanks for the feedback. Yes, obviously that would include removing the (sub-)sections on dynamic errors throughout the document. - Jerome
The WG decided to remove the sections on dynamic errors since they are non- normative and incomplete. The cost to make them correct and complete is too big. The WG also thinks that this will help improve the future maintainability of the document. Please close the bug if you accept our resolution. If you disagree, feel free to reopen it.
Fine with me.