[OAI-implementers] Error codes....

[Xiaoming Liu]

On Mon, 3 Jun 2002, deridder wrote:

> 
> Ummm...  So if a set name (or whatever) simply doesn't pass the
> pattern-matching test, it should get "cannotDisseminateFormat"?  Or could

>From the protocol, "cannotDisseminateFormat" will only be valid for
metadataprefix.

> possibly have 2 error conditions, one of "which is badArgument"?

In the protocol, "repositories should report all errors or exceptions that
arise from processing the request". IMO, it's fine to respond a
"badArgument"+"noRecordsMatch" if a set name doesn't pass the
pattern-matching test.

> I'm finding that in parsing through a resumption token, I could have quite
> a few errors for a single resumption token (of course all
> "badResumptionToken"--- and a set of dates can get hairy too).
> 
>  So are these the general rules (?) :
> 
> 1) any number of errors per verb/argument (could be several "badArguments")


The protocol said  "repositories should report all errors or
exceptions that arise from processing the request"

> 
> 2) list all parameters in the "<request ... " tag if no badVerb or
>          badArgument errors (Hussein, below)
> 


Yes, see 3.2 in OAI-PMH


> 3) leave them out otherwise
> 
> 4) "badArgument" is a "catch-all" to use if nothing else fits;  consider
>         all other error codes first; if another is applicable it must be
>         used

The only scenario I can think about is an unrecognized set (as mentioned
by Hussein). I am not sure it's a general rule that "badArgument" is a
"catch-all" to use if nothing else fits.

In another thing, I guess the re and other harvesters can be lenient
in  some situtations;-) For example, a repository which has strict
format requirement for set may return "badArgument" to a request with 
bad sets format; another repository which doesn't have any pre-defined
format  for sets may return "noRecordsMatch". 

let me know if I am wrong.

liu


> 
> Comments?  Rebuttals?  Free-for-alls?
> 
>   ;-)
> 
> Mon, 3 Jun 2002, Hussein Suleman
> wrote:
> 
> > hi
> >
> > regarding specificity of error, my interpretation is:
> > if a more specific error message is available, use that instead of
> > badArgument. thus, "cannotDisseminateFormat" should be used when a
> > metadataPrefix is not recognized. however, since there is no specific
> > error for an unrecognized set, you should use "badArgument".
> >
> > regarding parameters, my interpretation is:
> > when there are badVerb or badArgument errors, none of the parameters
> > should be listed in the <request> tag. otherwise, all of the parameters
> > should be listed.
> >
> > does this make sense ? feel free to reflect this to oai-implementors to
> > get more comments.
> >
> > ttfn,
> > ----hussein
> >
> > deridder wrote:
> >
> > > Hi Hussein...
> > >
> > >   I'm a bit unclear on which error codes I need to use when, I guess;  my
> > > error messages aren't succeeding in your test interface.
> > >
> > > For: (identifier, illegal mdp)
> > > http://oai.sunsite.utk.edu/cgi-bin/oai2.cgi?verb=GetRecord&identifier=oai:sunsite.utk.edu:0000000001&metadataPrefix=really_wrong_mdp
> > > I used badArgument; but your tester wants "cannotDisseminateFormat".  So
> > > for really bad sets and mdps, I should *not* use badArgument?
> > >
> > > For the others... I think I know what it is, but need to verify:  is it
> > > correct that invalid arguments should *not* be listed inside the error
> > > "<request..."  tag, but all valid arguments should?  So if the "from"
> > > value is bad, it should not be shown in the "<request ..." tag in the
> > > error response?  But any good args should be shown there?
> > >
> > > Thanks, Hussein.  Sorry if I'm a bother!!
> > >
> > >  --jody
> > >
> > > ***********************************************************
> > >    PGPKey: http://www.cs.utk.edu/~deridder/jd-pgp.txt
> > > ***********************************************************
> > >
> >
> >
> > --
> > ======================================================================
> > hussein suleman - hussein@vt.edu - vtcs - http://www.husseinsspace.com
> > ======================================================================
> >
> >
> 
> 
> ***********************************************************
>    PGPKey: http://www.cs.utk.edu/~deridder/jd-pgp.txt
> ***********************************************************
> 
> 
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>