Date:         Mon, 24 Jun 2002 13:22:48 +0200
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Theo van Veen <[log in to unmask]>
Subject:      several subjects
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII

I have been away for a few days so I respond to all the subjects and messages in a single message.

1.
I agree (and am even glad) with resultsetId and query being mutually exclusive parameters. I got the impression that this was decided  now.

2.
How are ttl's used in different implemenatations? As it is only a hint our client would try using the resultsetid  before the ttl expired and re-issue the query in case of an error, but it would do the same after the ttl expired  because the resultset could still be available. So we do not really use the ttl. How do other implementors deal with the ttl?

3.
I agree with resultsets being independ sessions as far as the client concerns. If the server wants to relate them, it  is up to the server, as long as the client not needs to be aware.

4.
Sorting existing resultsets is OK for me. Does the server return a new resultsetid after sorting, keeping the previous resulset available under is old name?

5.
By adding recordnumbers to records from a resultsets the recordnumbers would automatically be a surrogate or placeholder when a record is missing. When there are no record numbers this may be interpreted as there being no persistant resultset. 
I was the one from the SRU camp that requested recordnumbers to aid XSLT transforms, but if we can't count on recordnumbers in persistant resultsets, we will probably not use them at all. 
Not having recordnumbers makes the implementation more complicated because we need to know which records count and which don't. See Matthew's example with the different record schemas in a single response.

6.
I agree with Ralph that sort fields should be related to what is in a retrieved record, but it is not always known a priori what is in a record. I would prefer that clients may specify whatever sortfields they want and that the server returns which fields were actually used for sorting. In addition it would help to have a "a-sortid" and a "d-sortid" to distinguish between ascending and descending.
In 99% of the cases I expect "d-sortid=date" or "a-sortid=author&a-sortid=title". When a client asks for some sortfield that is not supported, the server decides how to sort and indicates in the response which fields could be used to do the sort. Maybe it could use some, but not all,  of the specified sortfields.  
Being flexible, not returning an error message and making clear that the client cannot rely on sorting is the best we can do to keep interoperability.

Theo