Hi, here's a LC comment by myself: the specification should state that SEARCH is a safe method (see <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>). BR, Julian
Julian Reschke wrote: > > Hi, > > here's a LC comment by myself: the specification should state that > SEARCH is a safe method (see > <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.1.1>). > > BR, Julian Fixed in -latest, adding: "SEARCH is a safe method; it does not have any significance other than executing a query and returning a query result (see [RFC2616], Section 9.1.1)." (<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html#rfc.section.2.1>). BR, Julian
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(Continue reading)
Hi John, thanks for the comments. The server I worked on a long time ago never truncated results, so I don't have any preference. 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. If you feel strongly about that, we *could* add a statement into the "future extensions" appendix. 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. BR, Julian 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) >(Continue reading)
> 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(Continue reading)
John Barone wrote: >> 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. I do agree that this may be more useful. I'm just skeptic about making this change many years after people have written implementations. >> 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(Continue reading)
Another comment on this; there doesn't seem to be any discussion about issuing a SEARCH and limiting on multi-valued properties, in the WHERE. Is this beyond the scope of this particular draft, or is this treated in some other specification/draft? Regards, -John -----Original Message----- From: w3c-dist-auth-request <at> w3.org [mailto:w3c-dist-auth-request <at> w3.org] On Behalf Of Julian Reschke Sent: Wednesday, July 02, 2008 9:12 AM To: w3c-dist-auth <at> 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-fro m-previous.diff.html>) take those into account.(Continue reading)
The Xythos server currently doesn't implement the limit feature. The server does truncate results based on a server setting. Making sure the truncated results are globally ordered is difficult, for the reasons you outlined and particularly when the search spans multiple data stores. Implementing the limit feature would pose the same ordering challenges. I think making 5.17.1 a MUST places a heavy burden on the server implementation. -John -----Original Message----- From: Julian Reschke [mailto:julian.reschke <at> gmx.de] Sent: Monday, August 04, 2008 9:24 AM To: John Barone Cc: w3c-dist-auth <at> w3.org; www-webdav-dasl <at> w3.org Subject: Re: getting WebDAV SEARCH ready for the IESG John Barone wrote: >> 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(Continue reading)
John Barone wrote: > The Xythos server currently doesn't implement the limit feature. The > server does truncate results based on a server setting. Making sure the > truncated results are globally ordered is difficult, for the reasons you > outlined and particularly when the search spans multiple data stores. ...another good point I forgot. > Implementing the limit feature would pose the same ordering challenges. > I think making 5.17.1 a MUST places a heavy burden on the server > implementation. One alternative would be "SHOULD", another one would be just stating that DAV:limit is optional, and servers that can't do the MUST level requirement should reject the query. Any preference? BR, Julian
John Barone wrote: > Another comment on this; there doesn't seem to be any discussion about > issuing a SEARCH and limiting on multi-valued properties, in the WHERE. > Is this beyond the scope of this particular draft, or is this treated in > some other specification/draft? > > Regards, > > -John Short answer: out of scope. Long answer: this requires a common understanding of what multivalued properties are, and how they are serialized. A proposal was contained in a draft of what later was published as RFC 4316, see <http://greenbytes.de/tech/webdav/draft-reschke-webdav-property-datatypes-06.html#rfc.section.A>. Back when we discussed this, there was a preference of keeping things simple, and so it was removed from subsequent drafts. That being said, I know that the proposal was implemented both by SAP and Xythos (although likely in different namespaces). I would be happy to resurrect that part of the spec as a separate activity, but today I wouldn't be able to update the SAP implementation anymore. BR, Julian(Continue reading)
RSS Feed2 | |
|---|---|
3 | |
3 | |
1 | |
2 | |
1 | |
3 | |
2 | |
14 | |
14 | |
2 | |
11 | |
1 | |
9 | |
21 | |
9 | |
16 | |
2 | |
3 | |
3 | |
17 | |
29 | |
39 | |
3 | |
5 | |
6 | |
14 | |
9 | |
21 | |
31 | |
6 | |
4 | |
17 | |
16 | |
19 | |
16 | |
40 | |
14 | |
116 | |
5 | |
11 | |
2 | |
4 | |
30 | |
20 | |
1 | |
8 | |
44 | |
40 | |
27 | |
24 | |
45 | |
20 | |
58 | |
27 | |
24 | |
27 | |
4 | |
54 | |
22 | |
28 | |
31 | |
18 | |
122 | |
234 | |
462 | |
695 | |
465 | |
453 | |
38 | |
33 | |
77 | |
52 | |
66 | |
28 | |
42 | |
162 | |
154 | |
190 | |
104 | |
40 | |
124 | |
28 | |
80 | |
128 | |
44 | |
82 | |
93 | |
34 | |
43 | |
60 | |
104 | |
153 | |
82 | |
71 | |
61 | |
77 | |
24 | |
53 | |
263 | |
106 | |
92 | |
19 | |
67 | |
243 | |
230 | |
42 | |
129 | |
87 | |
86 | |
75 | |
1 |
