RE: next steps / open issues in DASL framework

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Donnerstag, 7. März 2002 10:42
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?


<martin>
for my understanding the term "search arbiter" is an abstract term for a
piece of software, that suplies the SEARCH funcionality. As DASL is an
extension of WEBDAV, this piece of software will always be a complete WebDAV
server with the well defined behavior of GET, PROPFIND and so on. So no
additional definition is necessesary IMHO.
</martin>



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?

<martin> agreed (with out of scope) </martin>

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?

<martin> 
of course this issue is legitim. However, as basicsearch should be as simple
as possible, I tend to say out of scope as well. But perhaps this could be
an optional feature (is it that, what you mean by extension to
DAV:basicsearch)? 
</martin>

Julian

Received on Friday, 8 March 2002 03:32:33 UTC