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

RE: comment on issues in DASL draft: truncation

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 28 May 2002 09:17:16 +0200
To: "Jim Davis" <jrd3@alum.mit.edu>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCMEKMEKAA.julian.reschke@gmx.de>
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Jim Davis
> Sent: Tuesday, May 28, 2002 1:53 AM
> To: www-webdav-dasl@w3.org
> Subject: comment on issues in DASL draft: truncation
>
>
> Comments on issues in the DASL draft
> (http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-late
> st.html),
> in the order they appear in the draft
>
> Issue result-truncation
> http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-lates
> t.html#rfc.issue.result-truncation
>
> Is really two issues
>
> 1. the response body ... should also contain a *different*
> element stating
> that the results were incomplete and the result set was truncated by the
> server.
>
> I don't understand how this is different from the current
> proposal.  Isn't
> the response element with status 507 exactly this?  If not, it
> needs to be
> explained.

I think the issue here that there's a possibility that the URI of the search
arbiter may appear both with status 507 (truncation) and as a search result
(which would be a bad thing).

> 2. "may also be a need to report that the results were incomplete and the
> result set was truncated at the choice of the *client*" [emphasis mine].
>
> I agree that this could be useful, but I think this issue should be
> consolidated with issue JW5 (see below), which proposes that DASL
> basicsearch ought to have a way for client to request additional result
> sets.  It should be moved because there is little or no value in
> allowing a
> client to distinguish between the case where "N results were
> requested, and
> there are exactly N available" and "N results were requested, and
> there are
> more than N available" if there is no way for client to get the
> next batch
> of results.

Agreed.
Received on Tuesday, 28 May 2002 03:17:50 GMT

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