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

[Xiaoming Liu]

On Mon, 15 Jul 2002, Tim Brody wrote:

> >
> > 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.
> 
> Ok. This is kinda "overloading" errors though. An error hasn't occurred - a
> change occurred in the repository that resulted in an empty list.


I agree with Tim that using badResumptionToken is a bit of dangerous here.
It looks like this situation most likely will happend at the end of
harvesting, a badResumptionToken will simply invalidate all previous works
in same session. For a large archive, it means a lot of work.

regards,
liu



> 
> noRecordsMatch is defined as resulting from the original query, not as a
> side-effect of flow-control, and the resumption token in question is valid?
> 
> So logic is now:
> 
> if( no records ) {
>     if( CGI resumption token ) {
>         add noRecordsMatch ("no records match resumption token")
>         add badResumptionToken ("because it doesn't match any records")
>     } else {
>         add noRecordsMatch
>     }
> } else if( no resumption Token ) {
>     add empty token
> }
> 
> All the best,
> Tim.
> 
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>