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.

Well, actually, until my latest round of posts I was in favor of having them
be a new resource type.

> You seem to be assuming that resource types only
> support single inheritance.

It's true, I was making this assumption.  Mostly because it didn't seem
necessary to me to have multiple inheritance.

>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.

... and also returning something like <D:searcharbiter> inside the
DAV:resourcetype property.

I could really go both ways on this one, since operationally it comes down
to whether DAV:resourcetype reports D:searcharbiter, along with something
else (or potentially by itself).

Still, if a resource is only of type D:searcharbiter, then we need to answer
the questions of whether it also supports other methods. We could, perhaps
state that search arbiters must also be some other type of resource (i.e.,
its a basic resource and a search arbiter, or a collection resource and a
search arbiter), and address the question this way.

- Jim

>
> 		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 19:51:50 UTC