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

[Bug 4446] [XQuery] 2.3.4 Equivalent expressions

From: <bugzilla@wiggum.w3.org>
Date: Mon, 18 Jun 2007 23:06:14 +0000
To: public-qt-comments@w3.org
Message-Id: <E1I0QIY-0004h3-JX@wiggum.w3.org>


------- Comment #9 from hrennau@yahoo.de  2007-06-18 23:06 -------
(In reply to comment #7)

> For example, it is legitimate to return "true" as the result of
> (if (EXPR) then 1 else 2) instance of xs:integer 
> without evaluating EXPR

Yes, I see. So my error was to apply your constraint

> Conditional and typeswitch expressions MUST NOT ... must not return the
> value delivered by a branch unless that branch is selected.

to the count(EXPR) example, ignoring that EXPR is not *evaluated*.

Apparently, I got confused what the word 'evaluating' means. I think that "to
evaluate an expression" means to replace the expression by its value. And I now
see that in the count(EXPR) - example one has done "something" with the
argument expression - extracted information from it - but not evaluated it. 

Trying to arrive at a crystal clear understanding of what the constraint which
you propose means, I now think:

"must not return the value delivered by a branch unless that branch is
selected" applies only to those cases where the (conditional/typeswitch)
expression is fully evaluated, that is, replaced by its value.

I added "fully" because sometimes a  conditional expression might be partially
evaluated in the sense of determining a value set guaranteed to contain the
real value. For example let EXPR denote the expression "if ($x eq 0) then 23
else 45". Then the expression: 
   EXPR < 100
can be evaluated, not replacing EXPR by its value, but analyzing the set of
possible values. These cases are not limited to where the superset is
statically known. (An example is given by replacing '23' and '45' by $a and

I believe you would not want your constraint to apply to such cases - hence
Received on Monday, 18 June 2007 23:06:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:33 UTC