RE: UC&R 1.47 (Was: Re: Comments on UseCases v1.46)

Farrukh, Steve,

I understood "3.10 Result Limits" to be about having LIMIT in queries, that
is "get a maximum of N results even if there are more", not cursors and
chunking nor OFFSET.  We had the requirement:

""" from the F2F:
The query language/protocol supports limit, offset and ordering of results.

But it didn't get as much support.  It got 5 yes, 3 no: whereas just "limit"
got 9/2.

OFFSET is problematic in RDF (no ordering) and also gets into stability of
the result sets over a period of time which is difficult in a federated, web
environment.  The phrase "fetching it in chunks" still seems to be cursors
to my reading.

Farrukh - Could you say some more about your experience with ebXML Registry
etc?  It is a problem if the results are large - just as if a web page is a
large PDF or a database backed URL generates huge amounts of HTML.  It just
that machine processing makes it worse as they don't hit the "stop" button.


-------- Original Message --------
> From: <>
> Date: 11 May 2004 14:12
> On Tue, May 11, 2004 at 09:04:03 -0400, Farrukh Najmi wrote:
> > 3.10 Result Limits
> > I think this requirement should be replaced with a requirement for a
> > database cursor like requirement. This is essential for scalability
> > according to my experience with ebXML Registry etc.
> Cursors are explictly utside the charter:
>> charter#protocol
> but
> > 
> 3.10 Iterative Query Support
> > The
> query language or protocol must be able to handle large result
> > sets
> > of any size by iterating over the result set and  fetching it in
> > chunks. 
> this seems reasonable and does not require cursors, per se.
> To me the important distinction is that cursors require sone
> inter-query state, whereas limit and offset are explictly coded into
> the query. 

> - Steve

Received on Tuesday, 11 May 2004 10:03:23 UTC