[OAI-implementers] error reporting

[deridder]

How about for when the database is down, or other low-level
problems?
  I for one would like to use something like:

<error code="ServerDown">Service unavailable.  Retry in one
hour</error>

 with a 503 code, but obviously that's not in the protocol.

  --j.

On Sun, 23 Jun 2002, Irina Dijour
wrote:

> Hi Michael,
>
> I think that if we don't have error codes for low-level errors your solution
> #2 (some lower level bound)
> is the most suitable.
>
> Thanks,
> Irina
>
> -----Original Message-----
> From: Michael L. Nelson [mailto:mln@ils.unc.edu]
> Sent: Sunday, June 23, 2002 4:43 PM
> To: oai-implementers@oaisrv.nsdl.cornell.edu
> Subject: RE: [OAI-implementers] error reporting
>
>
> On Sun, 23 Jun 2002, Irina Dijour wrote:
>
> > >What error condition do you wish to report that is not covered
> > >by the existing error codes? I did not find any when writing
> > >my server.
> > For example: One record in my database is wrong and I can not obtain
> > datestamp information for this record.
> > I could say "cannotDisseminateFormat" but in truth I can disseminate
> format,
> > I just cannot get datestamp.
>
> interesting...  all of the errors defined in OAI-PMH are about OAI-based
> errors / exception conditions.  there is no provision for lower-level
> errors, such as problems in the database.
>
> I think the lack of a datestamp might be enough to say that this record
> does not exist in an OAI-context.
>
> from section 2.5:
>
> A record is identified unambigiously by the combination of the unique
> identifier of the item from which the record is available, the
> metadataPrefix identifying the metadata format of the record, and the
> datestamp of the record.
>
>
> so if you don't have 1 of {id,metadataPrefix,datestamp}, I don't think you
> have a record.  I would either:
>
> 1.  ignore this record for OAI purposes
>
> or
>
> 2.  make up a datestamp for the record.  it should not be hard to define
> some lower bound for the record; use whatever you put in earliestDatestamp
> in your Identify response.
>
> regards,
>
> Michael
>
> >
> > BR
> > Irina
> >
> > -----Original Message-----
> > From: Simeon Warner [mailto:simeon@cs.cornell.edu]
> > Sent: Thursday, June 20, 2002 11:16 PM
> > To: Irina Dijour
> > Cc: 'oai-implementers@oaisrv.nsdl.cornell.edu'
> > Subject: Re: [OAI-implementers] error reporting
> >
> >
> >
> >
> > What error condition do you wish to report that is not covered
> > by the existing error codes? I did not find any when writing
> > my server.
> >
> > My feeling is that 503 is not to be used for errors in the
> > same sense as <error> replies. 503 is for cases when the
> > service is unavailable -- it may be used for flow control
> > or perhaps temporary outages such as might occur with large
> > updates.
> >
> > Cheers,
> > Simeon.
> >
> >
> > On Thu, 20 Jun 2002, Irina Dijour wrote:
> > > I have a small suggestion concerning error reporting.
> > >
> > > We have several error codes in OAI 2.0 protocol ("badArgument",
> > > "badResumptionToke" etc).
> > > If I understand correctly, if none of these error codes fits for an
> error
> > > that should be reported,
> > > the OAI data provider should return HTTP Error code "503 Service
> > > unavailable".
> > > 1. If the OAI data provider uses HTTP Error code 503 it cannot specify
> > what
> > > exactly has happened.
> > >     And sometimes it's useful.
> > > 2. There are situations when the OAI Data provider wants to report a
> > > specific error for a specific record.
> > >     I think that sending HTTP Error code 503 in this case is too
> general.
> > >
> > > Therefore I propose to add additional error "unspecifiedError" (as it's
> > done
> > > in Z39.50 protocol).
> > > In the "error" element content OAI data provider may specify the error.
> > >
> > >
> > > Irina
> > >
> > > -----------------------------------
> > > Irina Dijour
> > > Software Development
> > > Ex Libris ltd.
> > > Malha Technology Park
> > > Jerusalem 91481, Israel
> > > Tel: +972-(0)2-6798-222  ext. 142
> > > Fax: +972-(0)2-6798-634
> > > Irina.Dijour@exlibris.co.il
> > >
> > > _______________________________________________
> > > OAI-implementers mailing list
> > > OAI-implementers@oaisrv.nsdl.cornell.edu
> > > http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> > >
> > _______________________________________________
> > 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)
>
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>


***********************************************************
   PGPKey: http://www.cs.utk.edu/~deridder/jd-pgp.txt
***********************************************************