> I feel strongly that these are two different things. I'm
> going to take one brief stab at saying why, then retire
> gracefully -- because I've had, and lost, this argument
> enough times to realise that I'm in a minority here.
> Consider a database that continually receives new records --
> for example, a news-clippings database that gets a feed from
> Reuters. You want to set up an SRW client to poll it every
> ten minutes and pick up the newly-added records. So every
> ten minutes you do your search, sorted on date-of-entry, most
> recent first. You say "give me the first ten records", but
> if there are more than ten, you need to be able to back and
> say "give me the next ten" _from the existing result set".
> This is _very_ different from re-executing the search and
> fetching records 11-20 from the resulting set.
My view on this was that the returned result set id was mandatory and
likewise I don't agree about the clients relying on sending the query
twice and expecting the same result set. It was Ralph who argued for the
result set id to be optional ("I don't want to support that in my
server" was his rough argument ;-) ) and for the repeated query bit, so
perhaps he should argue his case again (I still think he's wrong btw!)