RE: JW2a, JW2b: Search Arbiter resource

I think I finally understand why you object to having the search arbiter be
a new type of resource. You seem to be assuming that resource types only
support single inheritance. The whole reason we made resource type into a
piece of XML is because the resource type supports multiple inheritance.
There should be no conflict between being both a research arbiter and a
collection. I would expect that declaring oneself to be of resource type
search arbiter just means that one supports the SEARCH method and return the
DASL header on OPTIONS responses.

		Yaron

> -----Original Message-----
> From: Jim Whitehead [mailto:ejw@ics.uci.edu]
> Sent: Monday, August 16, 1999 3:34 PM
> To: 'DASL'
> Subject: RE: JW2a, JW2b: Search Arbiter resource
> 
> 
> 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:59:36 UTC