RE: "contains" must be optional

My position is that we must do both of the following two things:

(1) Collections must advertise the query operators that they
support along with their properties and query grammars. 

Advertisement of the query capabilities is required by our
charter. I don't feel we have fulfilled it unless we advertise
everything. I'm also sure the wisdom of doing so initially
will become apparent, because it will become obvious as
a requirement in the future. Advertising them is almost
trivial, because all an implementation has to do is to
output a short string constant that lists the operators (and,
I would propose, any restrictions on the form of their
operands, but that is for another proposal).

(2) We must use three valued elimination to prune undefined
expressions from the query condition, and we must use ANSI 
standard three valued logic (the same three valued logic that all 
conformant SQL engines have been using for years)  to
evaluate the resulting query.

Alan Babich

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	June 30, 1998 6:18 PM
> To:	www-webdav-dasl@w3.org
> Subject:	Re: "contains" must be optional
> 
> At 03:16 PM 6/30/98 PDT, Babich, Alan wrote:
> 
> Yes, of course 'contains' must be optional.  I do not think anyone
> disagrees with that.  (Speak up if you do.)
> 
> What we have yet to agree on is the MEANS by which such optionality is
> provided.  There are at least two alternatives:
> 
> 1) the operator itself is optional.  A server need not recognize it
> and MUST return an error if it is used.
> 
> 2) Every DASL server MUST recognize every operator, and MUST treat the
> results of applying unimplemented operators as unknown.  So
> implementation
> is optional, but the syntax isn't.
> 
> To elaborate:  Consider a server with no CBR, and the search 
>  (and
>    (= author  "Gates")
>    (contains "I love Janet"))
> 
> In case 1 you get back an error (probably 400, perhaps with a reply
> body
> containing an explanation of the problem in natural language), in case
> 2
> you get back an empty list because contains returns unknown.  You may
> also
> get back an explanatory text in the statusdescription, maybe.
> 
> For case 2, one could re-write the query above to be
> (and
>    (= author  "Gates")
>    (or (contains "I love Janet")
>        (= (contains "I love Janet") unknown)))
> 
> On servers without CBR, this becomes just a test on the author
> property
> alone, which is the best you can do.  On servers with CBR, it applies
> the
> additional test.  I have no idea whether this re-writing would be good
> idea.  (Clearly it's bad if it causes the contains predicate to run
> twice!)
> 
> We should pick exactly one of these two alternatives, unless there's a
> third one.  I don't know which one is better.
>

Received on Wednesday, 1 July 1998 14:33:13 UTC