Date:         Sun, 14 Jul 2002 19:23:51 +0100
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Matthew Dovey <[log in to unmask]>
Subject:      Re: questions
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>,
          [log in to unmask]
Content-Type: text/plain; charset="us-ascii"

> I've been working on an implementation of SRW for the ARTISTE 
> project and have been puzzling over a couple of points in the 
> draft Request Definition. I'd be interested to whether there 
> are actually answers to the questions below or perhaps the 
> specification is still in development to the extent that such 
> things haven't be exactly pinned down.

We hope to have a firm specification available in the very near future plus a
more informative commentary which addresses the issues you have raised.

> In the informal service specification the way 
> 'RequestedRecords' is described, and referred to, suggests a 
> single parameter ('requestedRecords') composed of two 
> integers ('startRecord' and 'maximumRecords'). However in the 
> Sample SRW request 
> (http://www.loc.gov/z3950/agency/zing/soap1.html) the message 
> contains two distinct parameters - 'startRecord' and 
> 'maximumRecords'. This is how I would expect the request to 
> be structured and is how the service I have implemented 
> expects to receive the information. Does 'requestRecords' 
> really exists as a parameter or is it a convenient way to 
> talk about 'startRecord' and 'maximumRecords'?

Yes - requestRecords does not exist as a real parameter just a "virtual"
grouping for discussion. The informal service spec on the website is just an
aid in checking we've haven't missed issues in the spec.

> Again in the informal service specification the description 
> of 'recordSchema' includes the fragment "If records are 
> wanted (requestedRecords is supplied) ...". This implies that 
> a request which omits both startRecord and maximumRecords 
> should be interpreted as a request for no records. However 
> given that the specification also states that  "If 
> maximumRecords is omitted, the server decides how many 
> records to return. If startRecord is omitted, 1 is assumed" 
> I'd suggest that a request which omits both startRecord and 
> maximumRecord should return records 1 through to the default 
> maximumRecords value chosen by the server.

Correct. If ommitted startRecord is taken to be 1. If ommitted maximumRecords
is taken to be server choice (although this default would be exposed via the
explain service we are currently devising). To request no records you must
explicitly ask for maximumRecords=0 (at which point startRecord and
recordSchema are effectively meaningless parameters if supplied, although
someone has suggested that recordSchema could in such circumstances be used
by an implementation as a hint as to what recordSchema may be about to be
asked for).

> I've imposed an upper limit on the maximumRecords a client 
> can request. For example one of the databases I intend to 
> expose using the SRW Service contains over 100,000 images the 
> full record each of which runs to 50+ lines of XML. I don't 
> want to cripple my underlying application by allowing a 
> client to request all of them! A upper limit need not be the 
> same as the default maximumRecords value - for example the 
> ARTISTE SRW returns 50 records by default and imposes a limit 
> of 100 records returned to any single request. (The client is 
> expected to iterate over the result set using the startRecord 
> parameter to get the entire resultSet). 

This seems fine.

> What should the 
> default behaviour for an SRW server should be if it receives 
> a request for more records than allowed? Should the server 
> ignore the supplied maximumRecords value return as many 
> records as allowed or return an error message to the client 
> informing them about the restriction and inviting them to 
> resubmit a request?

The response should include diagnostic 12 (Too many records retrieved)
including the maximum allow - also we will consider being able to discover
this maximum via the explain service.

Returning just the diagnostic, or returning the max. records allowed plus a
diagnostic would both be legal behaviour although I think the latter may be
preferable.

> 
> Is SortKey(s) parameter optional? 

Yes

> Finally a quick question about the resultSet parameter in the 
> Response. The numberOfRecords sub-element presumably refers 
> to the total numberOfRecords in the result set rather than 
> the numberOfRecords returned in the response?

Yes

Matthew