- From: Jim Davis <jrd3@alum.mit.edu>
- Date: Mon, 09 Aug 1999 13:27:23 -0700
- To: Jim Whitehead <ejw@ics.uci.edu>, "Babich, Alan" <ABabich@filenet.com>, "'DASL'" <www-webdav-dasl@w3.org>
At 02:46 PM 7/20/99 -0700, Jim Whitehead wrote: >I've been thinking about this aspect of QSD, and I have some concerns. >Perhaps I'm misunderstanding, but it appears we're creating a situation >where a client A can submit a DASL query to server X and have it succeed, >and submit the same query to server Y and have it not succeed because server >Y doesn't index the same properties as server X. Is this correct? It's probably correct but to be precise it depends what you mean by "succeed" and "index". But the underlying problem is not one DASL can address. As I see it, the issue is that there are only a few standard property names in WebDAV. Thus while one might query against the DAV:getcontenttype or DAV:gencontentsize and expect this to work on all servers, there is no way to search against more interesting fields such as author, title, publisher, cost, etc. (Well, the DAV:getdisplayname property might be the title). Eventually the Dublin Core work might produce a standard set of DAV properties to encode DC values, but not yet. Given this lack of standardization, QSD is the next best thing. At least it provides a way to discover the set of searchable properties. This allows a UI to put up a list of the available properties. So DASL, as written, does not allow a robot to do interesting queries (e.g. against author) on an arbitrary server (because the robot has no way to know what property if any holds the author name). But it does allow a human to do it (assuming you can guess from the property name or associated meta-property info). Does this addess your concern?
Received on Monday, 9 August 1999 16:29:23 UTC