- From: <bugzilla@jessica.w3.org>
- Date: Sat, 30 Oct 2010 20:54:45 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11171 --- Comment #5 from Michael Kay <mike@saxonica.com> 2010-10-30 20:54:44 UTC --- >That paragraph originally only mentioned type errors (actually, it /originally/ talked about "type-related warnings", but then shifted to type errors), but dynamic errors have been there since 2005-03-28. That explains a lot. At any rate, it explains why the rules for XSLT and XQuery are different - XSLT has never allowed dynamic errors to be reported early except as an optimization when they would inevitably be reported anyway. In considering early reporting of dynamic errors, we should look not only at compile-time reporting of such errors, but also at the closely related problem of premature dynamic reporting. For example let $N := count(//orders) for $x in 1 to $N return $x + 1 div $N should not fail in the case where $N=0, but the XQuery rules allow the implementation to raise an error here. (Because of the infamous sentence "Other than the raising or not raising of errors, the result of evaluating an equivalent expression must be the same as the result of evaluating the original expression.") Really this is no different from the conditional expression case: it should not be necessary for users to rewrite this as if ($N = 0) then () else for $x in 1 to $N return $x + 1 div $N I think that with the advent of try/catch, we need to get much stricter about such matters. Experience with the test suite has shown that this area is a frequent cause of interoperability problems even without try/catch. -- 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 Saturday, 30 October 2010 20:54:46 UTC