Print

Print


Thanks for those clarifications Matthew. 

You mentioned returning diagnostic 12 in response to too many records being requested. This is presumably from the list of Bib-1 Diagnostics defined within the Z39.50-1995 Standard. Is it the intention to use the same set of diagnostic codes for SRW?

I also have a couple more questions ..  :-)

Given that SortKey(s) is optional, what is the default behaviours for a server which does not support sortKeys? Such a server receiving a request containing a sortKey could either immediately return an error or it could execute the search request and return unsorted results. The former seems the better choice to me since otherwise there is no way to inform the client that the results they receive have not been sorted.

Moving on to response parameters, the draft specification lists queryStatus and resultSetStatus. 

First of all queryStatus:  is this always returned as part of a response? There is a question mark beside this suggesting the intention is to provide a limited list of possible values. Will these be simple strings along the lines of "Completed", "Failed", "Active" or something more complex?

Secondly resultSetStatus: again there is a question mark suggesting a list of values but I'm not sure what these might be. Is the intention that if the SRW Server receives a request for records from a non-existent resultSet the response (rather than an diagnostic message) is a message containing <resultSetStatus>Not Found</resultSetStatus>? Perhaps this is covered in the diagnostics?

Regards

Alison

Alison Stevenson
IT Innovation Centre
2 Venture Road
Chilworth Science Park
Southampton SO16 7NP 
 
Tel: +44 23 8076 0834
Fax: +44 23 8076 0833

mailto:[log in to unmask]
http://www.it-innovation.soton.ac.uk





> -----Original Message-----
> From: Matthew Dovey [mailto:[log in to unmask]]
> Sent: 14 July 2002 19:24
> To: [log in to unmask]
> Subject: Re: questions
> 
> 
> > 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
>