- From: Andrew Goodchild <andrewg@dstc.edu.au>
- Date: Fri, 8 Oct 1999 13:34:40 +1000 (EST)
- To: www-webdav-dasl@w3.org
Hi, I have been reading the DASL spec, and I have a few comments on it: 1) The requirement that a SEARCH method MUST respond with a text/xml entity matching the PROPFIND reponse, should be weakend. As has been noted on this list before by Jim Whitehead, the Z39.50 Implementers Group (ZIG) have a proposal for shipping XER encoded Z39.50 PDUs via the SEARCH request. However, the XER encoded response PDU will not be able to conform to the PROPFIND spec. A similiar problem happens with other query types. I could submit an XQL query, for which you cannot guarantee that it will be able to respond with a PROPFIND response conformant spec. Perhaps the spec should be restricted to something along the lines of: "a DAV:basicsearch request must repond with a PROPFIND response" 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. 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. 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. 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. Another operation worth considering is deletion of result sets. Also it might be worth considering whether queries upon result sets should be supported. 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. 6) Consider adding a UNIQUE operator to basicsearch to enable filtering out duplicate results from the query. 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. 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. 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. I hope these comments are helpful. Let me know if you would like to see any point elaborated upon. regards, Andrew _-_|\ Andrew Goodchild / * DSTC Pty Ltd \_.-._/ Brisbane, Australia v http://www.dstc.com/
Received on Thursday, 7 October 1999 23:34:46 UTC