unsubscribe

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

unsubscribe

Alexandre Liduena



-------------------------------------------------------
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
Reply | Threaded
Open this post in threaded view
|

Boolean or not Boolean ?

golgoth14@nonlimit.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Michael Beddow-2

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Pierrick Brihaye-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Pierrick Brihaye-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Michael Beddow-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Pierrick Brihaye
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Michael Beddow-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

golgoth14@nonlimit.ch
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Michael Beddow-2
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Timo Boehme
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

Pierrick Brihaye
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
Reply | Threaded
Open this post in threaded view
|

Re: Boolean or not Boolean ?

golgoth14@nonlimit.ch
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