W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1999

RE: JW10: QSD usage

From: Jim Davis <jrd3@alum.mit.edu>
Date: Mon, 09 Aug 1999 13:27:23 -0700
Message-Id: <4.1.19990809131558.00a4ef10@>
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

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