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

RE: JW2a, JW2b: Search Arbiter resource

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 16 Aug 1999 15:33:33 -0700
To: "'DASL'" <www-webdav-dasl@w3.org>
Message-ID: <NDBBIKLAGLCOPGKGADOJEEBICDAA.ejw@ics.uci.edu>
Yaron Goland writes:
> Why would we want to force DASL search arbiters to be WebDAV
> compliant? The purpose of the arbiter is solely to provide search
capabilities for WebDAV
> stores. This does not seem to require that the arbiter itself be WebDAV
> compliant.

Good point -- I had naturally been assuming that the search arbiter also had
to be DAV compliant.

> I also do not believe that there will be any interoperability
> problems with down level clients as such clients MUST NOT make any
functional
> assumptions regarding a resource which does not return a DAV compliance
header in its
> OPTIONS response. Since DASL arbiters are not required to return the DAV
> header then there is no danger that down level clients can become
> confused.

OK.

> Even if the DASL search arbiter is in a DAV tree there should still be no
> problem as WebDAV clients are already required to deal with the situation
> that the child of a DAV compliant resource may not necessarily be
> itself DAV
> compliant.
>
> As Alan says, it is fine for a DASL search arbiter to be DAV compliant. It
> just shouldn't be required.

But, this still hasn't addressed my original comment, which was:

* This specification essentially defines a new type of Web resource,
  of type "search arbiter".  This raises a number of questions
  regarding how this kind of resource interacts with existing HTTP
  methods.  I would expect to see a section which goes through and
  details the interactions between HTTP and WebDAV methods and search
  arbiters. For example, it seems reasonable to me to allow a search
  arbiter to potentially reply to GET (perhaps with a human-meaningful
  description of the capabilities of the arbiter), and for this GET
  response to potentially be authorable using PUT, and locked using
  LOCK.  However, I wouldn't expect COPY, MOVE, or DELETE to work,
  although I would expect PROPPATCH and PROPFIND to work OK.  Another
  issue is what kind of resource type a search arbiter returns in the
  resourcetype property (I'd expect a <searcharbiter/> element).


I think we're still dancing around the issue of whether a search arbiter is
a new type of Web resource, or whether a search arbiter is just a fancy name
for any existing type of resource that also supports SEARCH.  Since a search
arbiter can exist within a DAV-capable hierarchy, and hence must then itself
be DAV capable, this issue does need to be answered one way or the other.

A WebDAV collection hierarchy can potentially have each collection act as a
search arbiter for its descendents (or perhaps even the entire hierarchy).
In this case, each collection is also a search arbiter, and hence the type
of the resource is a collection, and there is no need for a special search
arbiter type (in fact, it would be detrimental to have a search arbiter
resource type in this case).

Based on this example, it seems to me the response to the issue I brought up
is:

A search arbiter is any resource that supports SEARCH.  A search arbiter is
not a new resource type.

In general, if a resource is a search arbiter, no conclusions can be made
concerning what other methods it supports.

If people agree with this, I'm happy to close down this issue.

- Jim
Received on Monday, 16 August 1999 18:42:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT