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

[Michael L. Nelson]

(combining emails)

> If the repository implementation is simpler by always including a resumption
> token element, and it doesn't cause a problem with the protocol, then it
> should be ok to do this?

i suppose its a moot point:  for good or bad, its already in version 2.0
of the protocol

> 
> I came up with the same solution. But I wouldn't class this as "trivial", as
> the logic intersects with other aspects of the protocol (below...).
> 

> > 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.

yeah, its not really an error; but "error" in the protocol doc has always
been shorthand for "errors & exceptions" (cf. title of section 3.6).  this
is clearly an exception condition.

> 
> 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?

badResumptionToken is defined as:  "The value of the resumptionToken
argument is invalid or expired.  "

in this case, the repository has simply decided to expire the
resumptionToken, which is well within its right (see 3.5.1)

(from Liu):

> 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.

yes, that could be the case.  of course, this condition was always present
-- even 1.1, if a harvester recvd a resumptionToken, and if it got an
empty list when it used that resumptionToken, then something funny
happened at the repository didn't it?  the fact that this condition was
prevoiusly more slightly obscured doesn't remove the danger.

> 
> 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 && CGI resumption token ) {
>     add empty token
> }

rewriting the block inside the first if yields a more compact:

if (no results) {
	error(noRecordsMatch);
	if (CGI resumptionToken) {  	# 1
		error(badResumptionToken)
	}
} else if ( no resumptionToken && CGI resumptionToken ) { # 2
	empty resumptionToken
}

#1 handles the case where you want to flag if your incomplete list has no
results.  #2 handles distinguishing between the final incomplete list and
a complete list.  I don't think this would make my top 10 list of "things
wrong in OAI"  ;-)

regards,

Michael

> 
> All the best,
> Tim.
> 
> 

---
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)