RE: getting WebDAV SEARCH ready for the IESG

> However, it seems to me that the text in 2.3.1 was phrased this way on
purpose
> -- there may be cases where it's not possible to first sort, 
> then truncate. For instance, when searching can be delegated to an
underlying 
> SQL store, but ordering can not, how would you implement that? 
> Thus, I'm hesitant doing any change over here.

Completely understood.  I'm just saying a client may not want results
that aren't ordered over the entire result set.  It might be preferred
to get no results (and have to further refine the search) than to get
truncated results that aren't "globaly" ordered.


> If you feel strongly about that, we *could* add a statement into the
"future extensions" appendix.

I don't feel that strongly about this, just a nice-to-have for some
clients.


> And yes, the inconsistency with 5.17.1 is a bit awkward, but I'm
really not
> sure we can change this at this point of time.

This I think is a bigger deal.  If you acknowledge that some servers
cannot (at least easily) order a global result set and then limit the
results returned, then how can this be a MUST?  Seems like the same
issue to me.

-John


John Barone wrote:
> Some comments:
> 
> In section 2.3.1 Result Set Truncation
> 
> - Would be nice to indicate what the search limit is (after what 
> number of results was the query truncated)
> 
> - Partial results: I read this to mean whatever partial results you 
> send back, they must be ordered (within themselves) as the client 
> requested.  In many cases the client wants the full list ordered, and 
> then send back the partial results.
> Any way to indicate this in the request; i.e. if you have to send back

> partial results (a 507 condition) I want them fully ordered, not just 
> within themselves?  Perhaps the server can send back a 507 response 
> for the arbiter URI and no results, if it can't comply with ordering 
> the full result set, and sending back partial results.
> 
> 
> In section 5.17.1 Relationship to Result Ordering
> 
> - I read this to mean that the full results should first be ordered by

> the server, and then send back the requested limit.  This seems to 
> contradict what's specified in section 2.3.1, where the results are 
> limited and then ordered (if I'm reading it correctly).  I think these

> 2 sections should be consistent with each other.
> 
> 
> Regards,
> 
> -John
> 
> 
> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org]
> On Behalf Of Julian Reschke
> Sent: Wednesday, July 02, 2008 9:12 AM
> To: w3c-dist-auth@w3.org
> Cc: WebDAV
> Subject: getting WebDAV SEARCH ready for the IESG
> 
> 
> Hi,
> 
> we recently made some progress on getting WebDAV SEARCH ready for 
> publication.
> 
> We received some feedback from Chris Newman, and the latest edits on 
> the draft 
> (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.
> ht
> ml>,
> <http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest-f
> ro
> m-previous.diff.html>)
> take those into account.
> 
> Unless there's new feedback, I'm planning to submit this as draft 16, 
> which, if all goes well, will then by last called.
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> 
> 
> This email and any attachments may contain confidential and 
> proprietary information of Blackboard that is for the sole use of the 
> intended recipient.  If you are not the intended recipient, 
> disclosure, copying, re-distribution or other use of any of this 
> information is strictly prohibited.  Please immediately notify the 
> sender and delete this transmission if you received this email in
error.
> 




This email and any attachments may contain confidential and proprietary
information of Blackboard that is for the sole use of the intended
recipient.  If you are not the intended recipient, disclosure, copying,
re-distribution or other use of any of this information is strictly
prohibited.  Please immediately notify the sender and delete this
transmission if you received this email in error.

Received on Monday, 4 August 2008 15:58:19 UTC