Boolean effective value tests

The test:

http://www.w3.org/2001/sw/DataAccess/tests/#test-boolean-effective-value-opt
ional

implies that the boolean effective value of an unknown datatype is false (by
not including #x3 in the results). 

The next test:

http://www.w3.org/2001/sw/DataAccess/tests/#test-boolean-effective-value-unk
nown-types

implies that boolean effective value of an unknown datatype is true (by not
including #x3 in the results)

Which is correct?

Similarly, the first test implies that the boolean effective value of an
unbound variable is either false or a non-match (i.e. solution is discarded)
while the second test implies that it is either true or a non-match. So it
appears that it is meant to be a non-match. Is that correct? If so, I'll
just relate that I've found that in order to produce expected results in all
situations, I've had to take the approach that a constraint function always
succeeds but signals an error (e.g. invalid parameter) by returning a
distinguished value and the boolean effective value of that distinguished
value is false. 

For example if the filter clause of:

SELECT  ?title ?price 
WHERE
    { ?book dc:title ?title .
      OPTIONAL
        { ?book x:price ?price } .
      FILTER ( ! bound(?price) ) || ( ?price < 15 ) .
    }

is understood to mean:

  sop:logical-or(
	fn:not(sop:bound(?price)), 
	op:numeric-less-than(?price, 15)))


If an unbound value of price causes op:numeric-less-than to fail (as in
discard the solution as opposed to returning a value of false), then the
solution is tossed despite the fact that the sop:logical-or would return
true given the chance (since the other leg is true). Now if sop:logical-or
behaved logically (i.e. passed the solution when true, failed it when false)
this wouldn't be a problem, but it doesn't behave that way - e.g.  the ebv
of:
	 sop:str(sop:logical-or(false, false))

is true.

I'm not sure if this is an implementation difficulty or a spec difficulty (I
know it's at least a difficulty with implementing the spec on a logic
platform). My guess is, though, that it is a general problem due to the
slightly differing models between constraints and the rest of the language.

So just to reiterate, the solution I found was to make the Boolean effective
value of an unbound variable to be false. 

Geoff

Received on Tuesday, 29 March 2005 21:15:34 UTC