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

Re: W3C XML QL and DASL: 5 statelessness

From: Jim Davis <jrd3@alum.mit.edu>
Date: Sun, 14 Nov 1999 20:59:31 +0100
Message-Id: <4.1.19991114204351.00ac7100@pop.xs4all.nl>
To: Eliot Christian <echristi@usgs.gov>, www-webdav-dasl@w3.org
At 02:36 PM 11/11/99 -0500, Eliot Christian wrote:

>>In DASL's basicsearch result sets are not persistent.  This was done to
>>lower cost of implementation.
>If you feel statelessness is important, I will need to get 
>clarification about the assumptions on the XML Query side. 

We think it's important to not REQUIRE statefullness.

>My guess is that the response will be that result persistence 
>should be implementation-specific. Perhaps implementations that 
>do not persist a result set could require that the handle for 
>retrieving a set member is processed as a query with a 
>"piggy-backed" request for presentation. Does this sound 
>like what DASL would expect? 

DASL is pretty much oriented towards this kind of piggybackness.  The
client sends a query, server sends a response, and the response includes
all the information the client requested.  At this point either client or
server could close the connection and that would be fine.

there have been some requests for statefullness in the form of allowing the
client to retrieve only partial results (e.g. the first 50 matching
records).  Many people have asked for this, but to date no one has come
forward with a specific proposal for how to do it.

It's also clear to me that nothing in the protocol itself would prevent a
smart server from caching a query, such that a subsequent request that was
identical to the cached query or a provable subset of it would be handled
more quickly.

nor would the protocol prevent one from defining an (optional) boolean
valued operator that refered to the value of a previously constructed
persistent result set. so the query would be eg 
 (and (result-set 3)
        (= author "foxcroft"))

nothing hard here.

the only issue would be that there's a widely help opinion in the WG that
optional functionality is undesirable because it's difficult to use
interoperably.  that is, if it's optional than a client can't assume it is
there, so it has to either to discovery at run time to test (which incurs
an extra round trip) or it has to try the query using the optional features
(optomistic) and see whether it fails.  Many people feel it's better to
design protocols with no optional features, so at least the client can be
rock bottom sure what it will get when it send a query.  this is a point on
which reasonable people of good will can disagree.

Received on Sunday, 14 November 1999 15:12:06 UTC

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