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

Re: Comments on the DASL Spec

From: Jim Davis <jrd3@alum.mit.edu>
Date: Tue, 26 Oct 1999 16:42:21 +0200
Message-Id: <4.1.19991026160807.00b01870@pop.xs4all.nl>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT