- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 25 Jan 2002 21:58:05 +0100
- To: "Jim Whitehead" <ejw@cse.ucsc.edu>, <www-webdav-dasl@w3.org>
> From: www-webdav-dasl-request@w3.org > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, January 25, 2002 8:54 PM > To: www-webdav-dasl@w3.org > Subject: RE: Call for Participation: new internet draft for WebDAV > SEARCH method > ... > > Q1) Should the draft attempt to define Query Schema Discovery for > > DAV:basicsearch? Has anybody actually *implemented* QSD? > > Well, on the surface it seems reasonable to allow a client to discover > whether a given query will be fast/slow, based on the > implementation of the > server. But, that said, I'm not sure what a client woudl do with the > information. If a client's operation depends on executing a given query, > even if it discovers the query is inefficient against a given server, it's > still going to execute the query. > > Discovering new operators might be useful, but only for clients > that expose > the entire search syntax to a human operator. I don't see how we could > provide enough information that a computational agent could learn about a > new operator in sufficient detail to know how to use it > effectively. Either > such a client alreadyy knows about the operator, or it doesn't. A client might automatically take advantage of a specific extended operator if it's available (without having to test for it using a test query). Similarily (for properties), it may make sense to give an interactive client the options to display a list of searchable properties. However, this might be hard to use if we don't have also a textual description of the property. Seems that we have an overlap with genereric metadata issues.
Received on Friday, 25 January 2002 15:58:38 UTC