------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Hi,
A strange thing (on the eXist-snapshot-20050805.jar <http://prdownloads.sourceforge.net/exist/eXist-snapshot-20050805.jar?download>): let $a := "true" let $b := "false" return $a and $b why this query returns true ??? when a logic operator is used, the result must be a boolean and the values ($a and $b) must be cast to boolean or not ? Thanks, merci. Stéphane ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
> let $a := "true" > let $b := "false" > return $a and $b > why this query returns true ??? For the same reason this one does let $a := "black" let $b := "white" return $a and $b To cut a rather long story short, the non-empty string casts to Boolean true (which has nothing at all to do with the the string "true") Michael Beddow ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
In reply to this post by golgoth14@nonlimit.ch
Golgoth 14 wrote:
> let $a := "true" > let $b := "false" > return $a and $b > > why this query returns true ??? Because : you evaluate the *effective boolean values* of two strings - both these effective boolean values are true -- since the strings haven't a zero length See http://www.w3.org/TR/xpath20/#id-ebv > when a logic operator is used, the result must be a boolean It is. > and the > values ($a and $b) must be cast to boolean No. It is their effective boolean value that is taken in consideration. See http://www.w3.org/TR/xpath20/#id-logical-expressions What you want is probably close to this : let $a := "true" let $b := "false" return $a instance of xs:boolean and $b instance of xs:boolean Cheers, -- Pierrick Brihaye, informaticien Service régional de l'Inventaire DRAC Bretagne mailto:[hidden email] +33 (0)2 99 29 67 78 http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html. L'avez-vous lu ? ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Hi,
[hidden email] wrote: I'm not sure I'm getting your point... Never mind. > But, the fn:exists() returns a xs:boolean and the result of a > comparaison (le, ge operators) is also a xs:boolean. > Why the result of c1 and c2 condition is a xs:string instead a xs:boolean ? > > Strange no ? What do you expect them to return ? bits ? What you provide is basically the contrary of what I've just explained : You have : 1) a direct element constructor (http://www.w3.org/TR/2005/WD-xquery-20050915/#id-element-constructor) 2) with an enclosed expression 3) which is atomized (http://www.w3.org/TR/2005/WD-xquery-20050915/#dt-atomization, http://www.w3.org/TR/xquery-operators/#func-data) 4) whose lexical representation as "true" or "false" is perfectly valid (http://www.w3.org/TR/xmlschema-2/#boolean) and even canonical. Did I miss something ? Cheers, -- Pierrick Brihaye, informaticien Service régional de l'Inventaire DRAC Bretagne mailto:[hidden email] +33 (0)2 99 29 67 78 http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html. L'avez-vous lu ? ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Ah well, the first posting wasn't an accurate reduction of the actual code
that gave rise to the issue. Now we've seen that code, here's my attempt at a reducing it, and I do think it indicates a problem: VERSION 1 for $element in ("black") return <r> <c1> { $element eq "black" or $element eq "white" } </c1> <c2> { $element eq "black" and $element eq "white" } </c2> <c1_AND_c2> { ($element eq "black" or $element eq "white") and ($element eq "black" and $element eq "white") } </c1_AND_c2> </r> Now this version produces the result you were expecting: <r> <c1>true</c1> <c2>false</c2> <c1_AND_c2>false</c1_AND_c2> </r> But let's now remove the parentheses used to constrain the sequence of Boolean evaluations, giving VERSION 2: for $element in ("black") return <r> <c1> { $element eq "black" or $element eq "white" } </c1> <c2> { $element eq "black" and $element eq "white" } </c2> <c1_AND_c2> { $element eq "black" or $element eq "white" and $element eq "black" and $element eq "white" } </c1_AND_c2> </r> NOW we get what you are reporting: <r> <c1>true</c1> <c2>false</c2> <c1_AND_c2>true</c1_AND_c2> </r> I leave it to Pierrick and others more used to doing battle with the increasingly convoluted specs to decide whether each of those results is correct (AFAIK they both are). But I would say that the original code has the pattern of grouping parentheses found in VERSION1, yet it is producing the result of VERSION2. Which may well indicate a problem with eXist's XQuery compiler. Michael Beddow ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Hi,
Michael Beddow wrote: > Ah well, the first posting wasn't an accurate reduction of the actual code > that gave rise to the issue. Thanks Michael. I've got the point now :-) Such reductions are *very* helpful (an usually make good test cases). > But let's now remove the parentheses used to constrain the sequence of > Boolean evaluations, giving > > VERSION 2: > for $element in ("black") > return > <r> > <c1> > { > $element eq "black" or $element eq "white" > } > </c1> > <c2> > { > $element eq "black" and $element eq "white" > } > </c2> > <c1_AND_c2> > { > > $element eq "black" or $element eq "white" and $element eq "black" and > $element eq "white" > > } > </c1_AND_c2> > </r> > > NOW we get what you are reporting: > > <r> > <c1>true</c1> > <c2>false</c2> > <c1_AND_c2>true</c1_AND_c2> > </r> Note that Saxon gives the same results. The reason is here : http://www.w3.org/TR/2005/WD-xquery-20050915/#id-logical-expressions particularly in this statement (with parts quoted by me) : The order in which the operands of a logical expression are evaluated is *implementation-dependent*. The tables above are defined in such a way that an or-expression can return true *if the first expression evaluated is true* So... since the first result of the or-expression is true, the whole expression is itself considered as true. > I leave it to Pierrick and others more used to doing battle with the > increasingly convoluted specs to decide whether each of those results is > correct (AFAIK they both are). This is correct... if the considerations about logical expressions are. IMHO they are not from the theory's point of view but they greatly help in providing performant implementations. There are a few similar considerations in the XQuery specs that always have answers to everything :-) Cheers, p.b. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Pierrick Brihaye wrote
> > The order in which the operands of a logical expression are evaluated is > *implementation-dependent*. The tables above are defined in such a way > that an or-expression can return true *if the first expression evaluated > is true* > > So... since the first result of the or-expression is true, the whole > expression is itself considered as true. > I thought as much. But the other point I was making is that my "reduced" version #1 showed that there eXist correctly allowed me to supply my own parentheses to group the terms and constrain the evaluation order. Now so far as I can see, the functions being evaluated in the full code were grouped in the same way as in my reduction #1. So I would have expected eXist to observe the same constraints when evaluating their results. In other words, had the grouping parentheses in the original been missing, then the results returned would have been expected to correspond to my version#2. Whereas I think they ought to match my version #1. This leads me to suspect that in the non-reduced case, eXist isn't properly observing the explicit evaluation sequence dictated by the parentheses, though it does so in the reduced version. Michael Beddow ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Your discussion is greate but it's normal to make groups when some
"complex" boolean evaluations are executed. The spec http://www.w3.org/TR/xpath20/#id-logical-expressions indicates the normal boolean operations : * true OR something else gives always true * false AND something else gives always false The results of the two versions are right. I've tested your two versions on Sleepycat XMLDB: Version 1: <r> <c1>true</c1> <c2>false</c2> <c1_AND_c2>false</c1_AND_c2> </r> Version 2: <r> <c1>true</c1> <c2>false</c2> <c1_AND_c2>true</c1_AND_c2> </r> It's the same results. But in my original query, I group the conditions and the result is wrong ! It's an eXist bug ? Michael Beddow wrote: >Pierrick Brihaye wrote > > > >>The order in which the operands of a logical expression are evaluated is >>*implementation-dependent*. The tables above are defined in such a way >>that an or-expression can return true *if the first expression evaluated >>is true* >> >>So... since the first result of the or-expression is true, the whole >>expression is itself considered as true. >> >> >> > >I thought as much. But the other point I was making is that my "reduced" >version #1 showed that there eXist correctly allowed me to supply my own >parentheses to group the terms and constrain the evaluation order. Now so >far as I can see, the functions being evaluated in the full code were >grouped in the same way as in my reduction #1. So I would have expected >eXist to observe the same constraints when evaluating their results. In >other words, had the grouping parentheses in the original been missing, then >the results returned would have been expected to correspond to my >version#2. Whereas I think they ought to match my version #1. This leads me >to suspect that in the non-reduced case, eXist isn't properly observing the >explicit evaluation sequence dictated by the parentheses, though it does so >in the reduced version. > >Michael Beddow > > > >------------------------------------------------------- >This SF.Net email is sponsored by the JBoss Inc. >Get Certified Today * Register for a JBoss Training Course >Free Certification Exam for All Training Attendees Through End of 2005 >Visit http://www.jboss.com/services/certification for more information >_______________________________________________ >Exist-open mailing list >[hidden email] >https://lists.sourceforge.net/lists/listinfo/exist-open > > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
>
> But in my original query, I group the conditions and the result is wrong ! > Yes, indeed, that's exactly the point I was trying to make in my response to Pierrick I think it's one of those days! I should have gone back to bed when that strange white-spaced sensitiveness in Manuel's test case came to light. IMHO, eXist ought to treat your original query as it treats my reduction #1, not my reduction #2, though it's treatment of both of those reduced versions is correct. > > It's an eXist bug ? > On what we've seen so far, I'd say yes. Any other offers, anyone? Michael Beddow ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
In reply to this post by golgoth14@nonlimit.ch
Hi,
I have two comments to the previous answers in this thread: 1) > Pierrick Brihaye wrote > >>The order in which the operands of a logical expression are evaluated is >>*implementation-dependent*. The tables above are defined in such a way >>that an or-expression can return true *if the first expression evaluated >>is true* >> >>So... since the first result of the or-expression is true, the whole >>expression is itself considered as true. Together with your comment "This is correct... if the considerations about logical expressions are. IMHO they are not from the theory's point of view but they greatly help in providing performant implementations." it reads as if the evaluation of the logical expression would be implementation-dependent. However this is not the case. With the mentioned shortcut you are free to decide with which side of a logical expression (with 2 operands) the evaluation starts. For a complex expression with more than 2 operands the precedence order and the associativity has to be respected. So the example $element eq "black" or $element eq "white" and $element eq "black" and $element eq "white" has implicitly the meaning ( ($element eq "black") or (($element eq "white") and ($element eq "black") and ($element eq "white") ) ) (the 'and' connected operands has to be evaluated left to right) So for every XQuery implementations either the expression returns a result which is the same as the results from other implementations or it throws a dynamic error. 2) Michael Beddow wrote: > I thought as much. But the other point I was making is that my "reduced" > version #1 showed that there eXist correctly allowed me to supply my own > parentheses to group the terms and constrain the evaluation order. Now so > far as I can see, the functions being evaluated in the full code were > grouped in the same way as in my reduction #1. So I would have expected > eXist to observe the same constraints when evaluating their results. In > other words, had the grouping parentheses in the original been missing, then > the results returned would have been expected to correspond to my > version#2. Whereas I think they ought to match my version #1. This leads me > to suspect that in the non-reduced case, eXist isn't properly observing the > explicit evaluation sequence dictated by the parentheses, though it does so > in the reduced version. In the original example from Stéphane the second part in <c1_AND_c2> was not the same as in <c2> (le instead of ge). It was more like <c1> but not exactly (no xs:boolean). So it is no surprise if this example failed. Timo ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Hi,
Timo Boehme wrote: > it reads as if the evaluation of the logical expression would be > implementation-dependent. However this is not the case. With the > mentioned shortcut you are free to decide with which side of a logical > expression (with 2 operands) the evaluation starts. For a complex > expression with more than 2 operands the precedence order and the > associativity has to be respected. Indeed. > In the original example from Stéphane the second part in <c1_AND_c2> was > not the same as in <c2> (le instead of ge). It was more like <c1> but > not exactly (no xs:boolean). So it is no surprise if this example failed. Hawk eye :-) I was getting mad on this one... a better factorization would have helped. Thanks ! p.b. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
In reply to this post by Timo Boehme
I'm back :)
I'm agree with you, my original example was wrong. Sorry. BUT, the problem persist in my business application (not with a specific example). I've investigate and I've discovered a strange thing. My business query is : for $element in (/pd:folder) where ((( ((fn:exists($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateFrom/@xsi:nil)) or ($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateFrom le "2005-10-26")) and ((fn:exists($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateTo/@xsi:nil)) or ($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateTo ge "2005-10-26")) ))) The condition returns true instead of false when dateFrom is "2005-10-01" and dateTo is "2005-10-01" !!! But when I declare a dummy let statement like : for $element in (/pd:folder) let $dummy := $element where ((( ((fn:exists($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateFrom/@xsi:nil)) or ($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateFrom le "2005-10-26")) and ((fn:exists($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateTo/@xsi:nil)) or ($element/pd:organisations/pd:organisation[./pd:organisationId/@idRef eq "ORGANISATIONGROUP-000000014"]/pd:dateTo ge "2005-10-26")) ))) The query works !!! Very strange no ? Stéphane Timo Boehme wrote: > Hi, > > I have two comments to the previous answers in this thread: > > 1) > >> Pierrick Brihaye wrote >> >>> The order in which the operands of a logical expression are >>> evaluated is >>> *implementation-dependent*. The tables above are defined in such a way >>> that an or-expression can return true *if the first expression >>> evaluated >>> is true* >>> >>> So... since the first result of the or-expression is true, the whole >>> expression is itself considered as true. >> > > Together with your comment > "This is correct... if the considerations about logical expressions > are. IMHO they are not from the theory's point of view but they > greatly help in providing performant implementations." > it reads as if the evaluation of the logical expression would be > implementation-dependent. However this is not the case. With the > mentioned shortcut you are free to decide with which side of a logical > expression (with 2 operands) the evaluation starts. For a complex > expression with more than 2 operands the precedence order and the > associativity has to be respected. So the example > > $element eq "black" or $element eq "white" and $element eq "black" and > $element eq "white" > > has implicitly the meaning > > ( > ($element eq "black") or > (($element eq "white") and ($element eq "black") and > ($element eq "white") > ) > ) > (the 'and' connected operands has to be evaluated left to right) > > So for every XQuery implementations either the expression returns a > result which is the same as the results from other implementations or it > throws a dynamic error. > > > 2) > Michael Beddow wrote: > >> I thought as much. But the other point I was making is that my "reduced" >> version #1 showed that there eXist correctly allowed me to supply my >> own >> parentheses to group the terms and constrain the evaluation order. >> Now so >> far as I can see, the functions being evaluated in the full code were >> grouped in the same way as in my reduction #1. So I would have expected >> eXist to observe the same constraints when evaluating their results. In >> other words, had the grouping parentheses in the original been >> missing, then >> the results returned would have been expected to correspond to my >> version#2. Whereas I think they ought to match my version #1. This >> leads me >> to suspect that in the non-reduced case, eXist isn't properly >> observing the >> explicit evaluation sequence dictated by the parentheses, though it >> does so >> in the reduced version. > > > In the original example from Stéphane the second part in <c1_AND_c2> was > not the same as in <c2> (le instead of ge). It was more like <c1> but > not exactly (no xs:boolean). So it is no surprise if this example failed. > > > Timo > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Exist-open mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/exist-open > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Exist-open mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/exist-open |
Free forum by Nabble | Edit this page |