Date:         Tue, 18 Jun 2002 10:40:00 +1000
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Alan Kent <[log in to unmask]>
Subject:      Re: Betr.: Re: session ids and result set ids
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
In-Reply-To:  <[log in to unmask]>; from Theo van Veen on Mon, Jun 17,
              2002 at 10:41:27AM +0200
Content-Type: text/plain; charset=us-ascii

On Mon, Jun 17, 2002 at 10:41:27AM +0200, Theo van Veen wrote:
> Search Request Parameters
> - CQL query string
>              OR
> - Resultsetid
> - Session id ...
...
> With respect to having meaningful names for resultsets (I do not
> remember who mentioned it): the client can save previous queries and
> link them to server-supplied resultsetids (which are hidden for the
> user). For what reason should resultsets have menaingfull names?

One clarification please to make sure we are on the same wave length.
I can see two reasons for supporting result sets. Are both wanted?

(1) To be able to fetch a record from a previous query (this is why
    you would specify a resultsetid above instead of a CQL query)

(2) To be able to refine previous search results in a followup query.
    Eg: First query:  title="Session ids"        (given set name "1")
    Followup query:   set="1" AND author="Theo"

I think (1) is clearly a goal. Is (2) a goal too though? *If* it is
a goal, then I can see benefits if result sets have nice names. The CQL
query has to contain the set name. If people do not want to be able
to refine queries in this way (for example, you can do it by substituting
the previous query text in instead: title="Session ids" AND author="Theo"),
then I agree result set names can be anything the server feels like
generating.

Alan