RE: next steps / open issues in DASL framework

> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Babich, Alan
> Sent: Monday, March 11, 2002 1:10 AM
> To: www-webdav-dasl@w3.org
> Subject: RE: next steps / open issues in DASL framework
>
>
> (1) The search arbiter is a piece of software, not a normal resource.
> Consequently, it doesn't have to respond to COPY, MOVE, DELETE, etc..
>
> (2) I think the spec. should clarify what a search arbiter is.

I currently have:

--
2.2.1  The Request-URI

The Request-URI identifies the search arbiter. Any HTTP resource may
function as search arbiter. It is not a new type of resource (in the sense
of DAV:resourcetype as defined in [RFC2518]), nor does it have to be a
WebDAV-compliant resource.
--

> (3) Searching across multiple heterogeneous repositories is very
> valuable. I
> had always thought that after the first draft, the committee
> would add cross
> repository searching. Cross repository searching is too much for the first
> draft. If and when cross repository searching happens, it would be time to
> get serious about the search arbiter. That would force the issue, I think.
> For the first draft, hopefully we can say it's out of scope. I suspect
> there's more work involved than would be good for a first draft.
>
> Alan
>
> P.S.:  I have been involved in a successful architecture for cross
> repository searching. I believe we have anticipated cross repository
> searching to the extent that that is necessary. QSD will allow the arbiter
> to discover what operators are supported by each target repository. The
> arbiter will formulate legal queries for each repository involved in the
> query, by massing the query for each repository separately using an
> extension of three valued logic called three valued elimination. (In
> general, that involves eliminating unsupported operators.) The
> arbiter will
> then merge the results from each repository and return them to
> the client as
> one set of results. In the case of ordered results, the arbiter might have
> to do some sorting for some of the repositories, but not others. The fact
> that we have required that null (i.e., missing) values sort first makes
> ordered results possible. Without that requirement, ordered results would
> not work.
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Thursday, March 07, 2002 1:42 AM
> To: www-webdav-dasl@w3.org
> Subject: next steps / open issues in DASL framework
>
>
> Hi,
>
> we still have three open issues in the DASL framework (= complete
> spec minus
> DAV:basicsearch minus Query Schema Discovery). I'd like to close
> these, and
> then to submit a version "00" of the draft. In the next iteration
> we should
> then try to get DAV:basicsearch (minus QSD) cleaned up.
>
> The open issues are:
>
> JW3:
> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-
> latest.htm
> l#rfc.issue.JW3>
>
> ejw@ics.uci.edu 1999-04-26 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).
>
> ejw@ics.uci.edu 1999-04-26 How does a search arbiter respond to
> searches, if
> the search arbiter URI is within a search scope? The answer to this is
> related to the answer to whether a search arbiter has its own properties,
> body, etc.
>
> --> I think there is an agreement that the SEARCH arbiter isn't a special
> resource type (except for it's ability to respond to search
> messages). Do we
> have agreement on this? Does the spec need to be clarified somewhere?
>
>
> The second one:
>
> JW9:
> <http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-
latest.htm
l#rfc.issue.JW9>

ejw@ics.uci.edu 1999-04-26 How does a DAV client discover which search
arbiter can be used to search a portion of the DAV namespace? At present,
the specification seems to imply two things (a) that "/" might be a typical
arbiter, and (b) that other arbiters can exist and you can get redirected to
them. If this issue isn't addressed in the specification, it might lead to
clients having hard-coded search arbiter locations, thus forcing servers to
put an arbiter at those locations or be non-interoperable. Or, it will
require clients to be configured with the search arbiter location, which
also seems bad. It seems far better to have a predefined mechanism which
clients can use to discover the location of the search arbiter. One simple
mechanism would be to define a property on each collection (but not each
resource) which gives the location(s) of appropriate arbiters.

--> I currently can't think of an easy method for the general case (in which
a resource doesn't have any knowledge about the SEARCH arbiter resources
that could search it). So, I'd say it's out of scope. Should the spec say
anything about this problem?


The last one:

JW5:
<http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.htm
l#rfc.issue.JW5>

ejw@ics.uci.edu 1999-04-26 On the topic of partial search results, DASL
currently has no way for a client to request the next chunk of a set of
search results. Since *every* search service I've interacted with on the
Internet has a feature for returning the next set of search results, I
really would expect this feature to be in DASL. An explanation for why this
feature isn't present should be in the protocol specification if it is not
going to be supported.

--> My position is "out-of-scope", because nobody seems to have asked for
this feature since it was raised. But I'm also willing to propose an
extension to DAV:basicsearch that would allow it. Feedback?


Julian

Received on Tuesday, 12 March 2002 10:27:44 UTC