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

RE: next steps / open issues in DASL framework

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 11 Mar 2002 13:28:43 +0100
To: <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCIEBCEDAA.julian.reschke@gmx.de>
Hi,

a new version of the draft is available at:

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

It (hopefully) resolves all open issues in chapters 1 through 3 (the
"framework").

The IETF won't (completely) process submissions before March 22, after which
I'd like to submit is as draft version 00.

Julian


> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> Sent: Thursday, March 07, 2002 10: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 Monday, 11 March 2002 07:29:19 GMT

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