W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2002

next steps / open issues in DASL framework

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 7 Mar 2002 10:41:59 +0100
To: <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEMBECAA.julian.reschke@gmx.de>
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 Thursday, 7 March 2002 06:41:22 GMT

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