- From: <bugzilla@jessica.w3.org>
- Date: Fri, 29 Oct 2010 23:35:23 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11171 --- Comment #2 from Michael Dyck <jmdyck@ibiblio.org> 2010-10-29 23:35:23 UTC --- (In reply to comment #0) > I suggest that we should change this to consider only the evaluation of > the QueryBody. Our spec would now say: > > "Independently of whether the Static Typing Feature is in effect, if an > implementation can determine during the static analysis phase that the > evaluation of the QueryBody would necessarily raise a type error or a > dynamic error, the implementation may (but is not required to) report > that error during the static analysis phase. So, e.g., if the QueryBody were if ($condition) then 1 + "red" else "foo" static analysis would not be allowed to raise a type error (for 1 + "red") unless it either: a) could prove that $condition was always true, or b) implemented the Static Typing feature. --- It occurs to me that the phrase "evaluation would necessarily raise an error" is somewhat ambiguous when there's more than one possible evaluation (i.e., when evaluation depends on not-statically-known factors such as the content of documents or the value of external variables). It could mean: there exists an error such that all possible evaluations would raise that error vs: each possible evaluation would raise an error, but different evaluations may raise different errors. The subsequent phrase "report that error" suggests the first interpretation, but I wonder if we're okay with the second interpretation. (This ambiguity exists in both the existing wording and the proposed new wording.) > However, the fn:error() function must not be evaluated during the static > analysis phase." With the change to QueryBody, that sentence would perhaps be unwanted. I.e., if static analysis can prove that running the query would necessarily raise an error, then I imagine the user would like the error reported statically, regardless of whether it arises from a call to fn:error(). > Section 3.11 Conditional Expressions has special rules for propagating dynamic > errors: (and 3.15.2 has special rules for Typeswitch Expressions) > We should add similar wording to 3.14 Try/Catch Expressions: I'm not sure that these rules really are "special". They seem to boil down to "Don't raise errors from evaluations that the spec doesn't tell you to do." Do we similarly need "special rules" to say that implementations must not raise a dynamic error in cases such as: for $i in () return $i/0 or: some $i in () satisfies $i/0 > 2 or: (1,2)[false][. div 0] ? > I believe that with these rules, the following query would not be allowed to > raise an error. > > declare variable $v := 1 div 0; > declare function local:f () { 1 div 0}; > > "No problem here!" Well, the shift to QueryBody would mean that no error could be reported during static analysis. However, I'm pretty sure an implementation would be allowed to raise a divide-by-zero error during dynamic evaluation, because there's no rule to say that you mustn't evaluate the initializer of an unused variable. (In fact, the wording in 4.16 seems to say that you must, but I imagine people will claim that 2.3.4 says you needn't.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Friday, 29 October 2010 23:35:25 UTC