> Date: Thu, 13 Jun 2002 15:03:28 -0400
> From: Ray Denenberg <[log in to unmask]>
>
> > I've quoted this suggestion in its entirety so I have context in
> > which to ask this question: who is looking forward to explaining
> > all this to the ZIG, the W3C or anyone else? Who's going to enjoy
> > writing tutorials for this rat's nest of logic?
>
> I don't see it as all that complicated: If the server supplies a
> result set name then it guarantees (a good faith effort) to maintain
> a positional result set. If it doesn't, then it doesn't.
>
> Is that better?
Somewhat. (So what was all the rest of that prose about?)
> > If we want to do serious IR, then we need result sets. So let's
> > have them in the protocol properly and have done. If we prize
> > simplicity over power, then let's NOT have them. But please, not
> > this wishy-washy, in-between, will-he won't-he compromise.
>
> Just to be clear: your suggesting we decide either (a) the server
> always returns a result set name, or (b) it never does.
Either of those choices would give us a protocol whose intent is easy
to understand. But no, that's not what I meant.
> I don't think we want to choose one of these alternatives. We have
> implementors who want to do "serious IR" and implementors who "prize
> simplicity over power". I think we can accomodate both.
The problem in the current spec. -- well, one of the problems -- is
that the _server_ makes the decision about whether or not a result set
is presistent: from
http://www.loc.gov/z3950/agency/zing/srw.html
at the top of the "Z39.50 Concepts Retained in SRW" section --
* Result Sets
After a server executes a query it may include in the response
a result set name (in contrast to classical Z39.50, the server
names result sets, not the client). If the server does not
intend that the result set will remain reasonably static, then
it will not supply a result set name.
How can the server possibly make that decision? It doesn't know what
the client's going to want to do with the results. So the way things
are set up at the moment, the client might want a persistent set and
not be able to use it; or it might not need one, but the server wastes
resources by unilaterally deciding to maintain it anyway.
So my concrete proposal is simply that the client should send, as a
part of the search request, a bit saying whether or not it wants the
server to maintain a persistent result set. (This approach also has
the advantage of being very easy to document :-)
(Probably doesn't need saying, but to be clear: I have no quarrel with
the server choosing what _name_ (or identifier, for Matthew) the
result set is given. That's just an on-the-wire cookie, who care how
it's spelled?)
BTW., the SRW spec goes on to say --
When the client subsequently wishes to retrieve records from
the result set, it may send a Search/Retrieve request which
includes either the same query string, or a query string that
includes the server-supplied result set name if one was
supplied.
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.
Z39.50 classic was a bit vague on that. Maybe it's because, back in
the early 90s, you could get away more often with assusming that
databases are read-only (or at least read-mostly). But if we mean
anything by SRW being an IR protocol for the 21st century, we surely
have to play nice with dynamic data.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> www.miketaylor.org.uk
)_v__/\ "I don't want no pretty face to tell me pretty lies, all I
want is someone to believe" -- Billy Joel, "Honesty"
