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.

(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 00:37:24 UTC