[OAI-implementers] Lists/Flow-control/Emptiness

[Michael L. Nelson]

On Thu, 11 Jul 2002, Tim Brody wrote:

> Dear all,
> 
> 1) empty resumption token in complete list
> 
> Where a result set is returned without flow control (e.g. a small list), can
> an empty resumption token be appended to this list, even if it is
> "complete"?

I guess its not explicitly stated in the protocol as "must not"... 

But resumptionTokens are for incomplete lists, and including an empty
resumptionToken would seem likely to confuse harvesters.  Or maybe it
wouldn't confuse them, but at a miminum it is superfluous (below).

> (The logic to cope with determining the difference between the completing
> list and a complete list is not trivial)
> 

check for the existence of a resumptionToken in the CGI vars.  if the
harvester passed in a resumptionToken, then it is the final incomplete
list.  if not, it is a complete list all by itself.

> 2) no-records+resumption token
> 
> An empty list won't validate, e.g. ListRecords without any records.
> 
> It is possible that flow control may result in an incomplete list that does
> not contain any records, e.g.:
> Harvester requests (until=2002-03-04)
> Performs flow control, gets to last page-1
> Records on last page move out of result set
> Harvester requests final token, for which no records can be returned
> 
> An empty token by itself will not validate, and "noRecordsMatch" means that
> no records could be returned for the query, not for the resumption token.
> 
> Change schema or return noRecordsMatch?
> 

this would seem to be covered in section 3.5.1:

[...] In cases where there are substantial changes to the repository, it
may be appropriate for a repository to return a badResumptionToken error,
signaling that the harvester should restart the list request sequence.


if you have a resumptionToken *and* no records match, then something ugly
did happen:  either the harvester is trying to "forge" the
resumptionTokens, or the repository had (potentially significant) changes.

I think returning both noRecordsMatch and badResumptionToken would be the
safe way to handle it.  

regards,

Michael

> Regards,
> Tim
> 
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> 

---
Michael L. Nelson
NASA Langley Research Center		m.l.nelson@larc.nasa.gov
MS 158, Hampton, VA 23681		http://www.ils.unc.edu/~mln/
+1 757 864 8511				+1 757 864 8342 (f)