W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 1999

Comments on the DASL Spec

From: Andrew Goodchild <andrewg@dstc.edu.au>
Date: Fri, 8 Oct 1999 13:34:40 +1000 (EST)
To: www-webdav-dasl@w3.org
Message-ID: <Pine.SOL.4.05.9910081103000.9545-100000@sunburn.dstc.edu.au>


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.



  _-_|\    Andrew Goodchild	
 /     *   DSTC Pty Ltd
 \_.-._/   Brisbane, Australia
      v    http://www.dstc.com/
Received on Thursday, 7 October 1999 23:34:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:41 UTC