RE: use of boolean literals

(1) Testing for the existence of a property is testing for null.
In the context of an RDBMS, that means that the property
is defined, but on the particular resource, it has no value.
In contrast, if the property is not DEFINED anywhere, that is
generally treated as a query syntax error.
I have no objection to an operator that tests for whether
a particular property has a value for the current resource
under scan. In SQL, that would be expressed as
"x IS NULL". Generally, the "IS NULL" operator returns
TRUE or FALSE. However, is x is not defined anywhere,
it should return UNKNOWN. Whether "IS NULL" should be in
the required set of operators as opposed to merely
being a well known operator is a subject for discussion.

(2) There are lots of cases where the value of the property
is defined, but you have no idea what the value of the
expression is. Consider "x/y > 3". Suppose x and y
are properties that are not only defined, but have a value
on the current resource under scan. To be specific,
suppose the value of x is zero, and the value of y is
zero. What, then, is the value of "x/y > 3" for that
resource? Any mathematician will tell you that division
by zero is an undefined operation. ANSI SQL will
tell you that the value of that expression is UNKNOWN.

(3) BTW: ANSI SQL 92 allows you to write the three
truth value constants in WHERE conditions so that
you can test if expressions are equal to them. They
are spelled TRUE, FALSE, and UNKNOWN.

(4) Extending three valued logic to three valued
elimination so that you can query across multiple
repositories means that sometimes you have to
replace an entire subtree of a query by the
truth value constant UNKNOWN. If you don't
have this literal, you have to resort to some
kludge like replacing the subtree with "x/0 = x/0". 
(This expression has the value
UNKNOWN, because the value of x/0 is
u (for the undefined number), and u is unequal
to u. Unfortunately, we cannot resort to this
kludge, because we have no arithmetic
operators in DASL (yet). So we would be 
stuck -- we wouldn't be able to massage the 
query to prune out operators not defined in a 
particular collection in order to pass it a valid query.

(5) Sauveen: Why do you object to putting in typing into 
DASL? I personally thought it would be an advantage.
What does 3 > "cow" mean? To me, it means
"syntax error". I believe in returning errors as early
as possible to minimize end user confusion. Type 
mismatches can cause syntax errors to be returned, 
rather than odd results. What are your concerns?

Alan Babich
> -----Original Message-----
> From:	Saveen Reddy (Exchange) [SMTP:saveenr@Exchange.Microsoft.com]
> Sent:	April 16, 1998 5:59 PM
> To:	www-webdav-dasl@w3.org
> Subject:	RE: use of boolean literals
> 
> 
> For boolean literals ... I suppose we could use a new XML element for
> this
> but that seems like overkill (and this drag us into defining typing
> for XML
> -- which I think we should avoid.)
> 
> I didn't intend "unknown" as a value that could be used in the
> criteria --
> but rather a mechanism that DAV:simplesearch would employ to deal with
> evaluating certain expressesions. This is all based on what Alan
> described
> in the first DASL BOF concerning the use of an "unknown" in SQL.
> Although I
> could see the use, it seems *much* more likely that someone will test
> for
> the existence of a specific property rather than test whether its
> value (or
> the value of an expression) is "unknown". 
> 
> -Saveen
> 
> 
> -----Original Message-----
> From: Jim Davis [mailto:jdavis@parc.xerox.com]
> Sent: Thursday, April 16, 1998 10:41 AM
> To: www-webdav-dasl@w3.org
> Subject: use of boolean literals
> 
> 
> The draft in secton 8.7.5 uses lowercase t and f as representations
> for
> boolean values.  I don't like these much.  What would be better?
> 
> First I ask, does any other HTTP protocol already define a string
> representation for boolean values, e.g. I recall seeing upper case T
> and F
> in DAV, but I think it's gone now.  If there is already a precedent we
> should follow it.
> 
> Actually I think it likely that we will need to define a tag that
> represents the "unknown" value (so that we can construct searches for
> properties with unknown values), we may as well define tags for True
> and
> False, too.  In that case we should be these tags in 8.7.5 as well.
> But
> see also my note about the casesensitive tag.
> 
> I realize that, conceptually, one could distinguish between boolean
> values
> in the context of a search filter expression, and boolean values that
> are
> just controlling options such as case sensitivity, but it's not clear
> to me
> that making this distintinction wouldn't add confusion to the spec, as
> in
> "why is 'true' written as 'T' here and as '<DAV:TRUE/>' there?"

Received on Thursday, 16 April 1998 21:57:59 UTC