- From: Jim Davis <jrd3@alum.mit.edu>
- Date: Tue, 26 Oct 1999 16:42:21 +0200
- To: Andrew Goodchild <andrewg@dstc.edu.au>, www-webdav-dasl@w3.org
At 10:34 PM 10/8/99 +1000, Andrew Goodchild wrote: > >Hi, > >I have been reading the DASL spec, and I have a few comments on it: Thanks for your comments. They are much appreciated. Sorry to have been so slow to reply. >1) The requirement that a SEARCH method MUST respond with a text/xml > entity matching the PROPFIND reponse, should be weakend. > ...Perhaps the spec should be restricted to something along the lines > of: "a DAV:basicsearch request must repond with a PROPFIND response" I guess I don't see how we'd have any interoperability at all, if a server could give a reply that was not a PROPFIND response. But I also don't care much about the point. I mean, you're assuming that query is not basicsearch (so the only way the client could have known to send it was by some out-of-band private arrangement with the server). So what's the problem if the reply is also not interoperable? I guess it's no big deal. But rather than change the spec, I'd just as well say that in such cases the client and server are not using DASL, they are using some proprietary protocol that shares some pieces of DASL, but is not DASL. So my point is that making the change you ask would not help DASL meet any of the design goals in its charter, so I see no benefit to DASL in doing so. Does this make sense? >2) Consider weakening the requirement that every server must support > dav:basicsearch to a recommendation that every server should support > dav:basicsearch. I could imagine that some developers may wish to use > DASL as a mechanism for transporting other queries and responses, and not > wish to have the overhead of having to implement DAV:basicsearch. I will conceed that that would make sense from the standpoint of making life easier for experimenters, but not from the standpoint of making an interoperable search protocol. If it isn't implemented everywhere the same, if there isn't an omni-present lowest-common-denominator fallback (basicsearch) than there's no way for a client to know how to search a server except by polling or something. Also, the design of basicsearch is quite simple. Is it really true that implementing it would be an unreasonable burden? If so, then perhaps there are things we should remove from basicsearch. Basicsearch is supposed to be BASIC. >3) There needs to be some mechanism for scrolling through result sets. > For example, you should be able to request 10 results, then latter > on request another 10 results, and so on. Jim Whitehead and Alan > Babich have raised this issue before in thier discussion of partial > result sets. You are not the first to request this. the problem is that no one has stepped up to task of actually defining the mechanism. So let me ask If DASL did not support this as a mandatory feature, would it still be useful? Or, put another way, if you had a DASL client, and were about to do a search on some server Foo, and discovered that Foo did not support partial results (ie it says "If you send me a query I send you back ALL the results, take it or leave it") would you still run the query? > A way of supporting this would be to have a result set naming > mechanism. You could then refer to the result set name in a > later request for a range of records. Note the interaction with the desire that basicseach be dead easy to implement and cheap to run. We heard lots of complaints about the idea that servers be *required* to store results sets (which could be large) for an indefinite time. > Naturally, you would also need to have additional diagnostic > error messages to report that a user has requested records out of > the range, or that a result set no longer exists or has expired. Yes. I am afraid this gets complicated quickly. > Another operation worth considering is deletion of result sets. > > Also it might be worth considering whether queries upon result sets > should be supported. Again, this is a really cool idea but we want to keep basic search simple. >4) A way of returning a result count would be useful. For example, you > may only ask for the first 10 records, but it would be handy to know > that there are another 38 records available as well. >5) A way of stopping a query that is already running is very important. > It is often the case that a user will mis-specify a query, and wish > to stop it and restart a new one. How important is this, and how often does it happen? are you talking about the case where the human hits Okay, then notices an error on the form? I suppose the client could just close the connection. Because there's no way, in DASL as it is, for the server to return an "early warning" of a problem (e.g. "Your query matched 300,000 records, here they come...") >6) Consider adding a UNIQUE operator to basicsearch to enable filtering > out duplicate results from the query. This one we already cover, because WebDAV 12.9.1 says (of the response element) " A particular href MUST NOT appear more than once as the child of a response XML element under a multistatus XML element. This requirement is necessary in order to keep processing costs for a response to linear time." hence even if duplicate results could occur (and I am not sure I see how they could), the server would be required to merge them. >7) Consider adding the count aggregate operator to basicsearch. > I am not sure if other aggregate operators such as: sum, max, min, > avg, etc are relevant, but maybe worth looking at as well. That's also a really cool idea, but not for basicsearch. Seems like you have quite a few good ideas for a non-basic search. Would you like to take on the task of defining a second DASL query grammar? >8) Consider adding the notion of predefined brief list of properties to > basic search. In Z39.50 there is the notion of element sets. Examples > include full and brief records. Where a brief record is usually > defined as a subset of elements from a full record. Being able to > request a brief record is a handy feature. From your explanation, it seems that the main benefit is that the query uses fewer bytes, because it need not list the set of properties desired. Is this worth the added complexity? > A similiar feature could be added basicsearch. For example, > <D:select> <D:briefprop> </D:select> could be used to select a > small set of commonly used properties. This would be hard to make interoperable. WebDAV defines only a handful of well-known properties (there is nothing in WebDAV like Bib-1 in Z39.50) So, while we could define "briefprop" to be just that set, it would not be useful. And if we leave it up to each server, it would not be interoperable. >I hope these comments are helpful. Let me know if you would like to see >any point elaborated upon. they are very much appreciated.
Received on Tuesday, 26 October 1999 12:08:31 UTC