W3C home > Mailing lists > Public > public-qt-comments@w3.org > June 2008

[Bug 5810] [XQuery] reasoning about fn:error()

From: <bugzilla@wiggum.w3.org>
Date: Mon, 30 Jun 2008 20:13:52 +0000
To: public-qt-comments@w3.org
Message-Id: <E1KDPl2-0006qE-1H@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5810





--- Comment #9 from Michael Dyck <jmdyck@ibiblio.org>  2008-06-30 20:13:51 ---
[Personal response]

(In reply to comment #8)
> Do you have an opinion on whether 
> 
> count(fn:error())
> 
> is 1,

Under a strict evaluation, the expression always raises a dynamic error, so the
question is more like "Is an implementation allowed to rewrite the expression
into one that always returns 1?". I believe the answer is yes, but really it's
allowed to rewrite it into *anything*. That is, when the original expression
raises an error, the XQuery rewrite rules don't constrain the value/error
resulting from the rewritten expression. (The classic example being an
implementation that returns 42 for the expression 1 div 0. It's allowed, but
frowned upon.)

If the question is whether it's a "reasonable" or "defensible" rewrite, I'm not
sure. Although FS 8.4 says
    quantifier(none) = 1
it's doing so in the context of defining a particular pseudo-function for use
in particular rules. Applying it elsewhere isn't guaranteed to give meaningful
results. (Note that FS 8.4 also says
    quantifier(empty) = ?
which could lead to some bad inferences if mis-applied.)

> and whether (more generally) it is permitted to count a function whose
> argument has quantifier 1 without evaluating it?

If an implementation can prove (via quantifiers or whatever) that a particular
call to fn:count() would, if evaluated, either raise an error or return 1, then
I believe it is permitted (among other things) to yield 1 for that expression
in all cases.


-- 
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 Monday, 30 June 2008 20:14:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:52 GMT