W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > April to June 1998

RE: use of boolean literals

From: Saveen Reddy (Exchange) <saveenr@Exchange.Microsoft.com>
Date: Thu, 16 Apr 1998 17:58:43 -0700
Message-ID: <2FBF98FC7852CF11912A00000000000107E78551@DINO>
To: www-webdav-dasl@w3.org

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". 


-----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 20:58:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:38 UTC