[OAI-implementers] Results for various sites trying POST requests

[Leo]

> > (It's a shame that many repositories seem to code their own
implementation.
> > Perhaps OAI should be more pro-active in promoting the development of,
and
> > use of standard APIs, including standard error messages)

I'm pretty new to OAI, but my use of it has primarily been as a protocol
layer for my project's cataloging and webcrawling interface for standards
like dublin-core or dublin-core extended and MARC.  Enough of that though.
Since I use it as a protocol, I would rather not expect it to deliver
anything else (like standard error messages or handling through an API);
however, it would be very nice to see those things.

I noticed a few postings back there was talk of a skeleton or base framework
for implementing OAI. Whatever did happen to that, I wonder?

-Leo

----- Original Message -----
From: "Alan Kent" <ajk@mds.rmit.edu.au>
To: "OAI Implementors" <oai-implementers@oaisrv.nsdl.cornell.edu>
Sent: Monday, February 11, 2002 18:18
Subject: Re: [OAI-implementers] Results for various sites trying POST
requests


> On Mon, Feb 11, 2002 at 12:21:04PM -0000, Tim Brody wrote:
> > What would be very interesting would be to correlate your results with
how
> > OAI-PMH has been implemented at the repository - whether the admin has
used
> > one of the available APIs, languages, and so on.
>
> Maybe as part of OAI 2.0 the Identify command could have a standard
> slot (if its not there already) identifying the toolkit implementation.
> Sort of like User-Agent in HTTP or implementation in Z39.50. I certainly
> noticed some consistent errors which I *assume* are toolkit implementation
> issues.
>
> > (It's a shame that many repositories seem to code their own
implementation.
> > Perhaps OAI should be more pro-active in promoting the development of,
and
> > use of standard APIs, including standard error messages)
>
> I am in two minds here. I think a good thing about OAI is that it is
> a relatively simple protocol. Wide adoptance I think is better based
> on easy implementation and easy verification. SOAP for example has
> benefited greatly from an interoperability testbed. People put up
> test servers strictly for the purpose of interop testing. People
> agree what the answers should be, and then fire their clients against
> each other's servers to see if the results are correct. This may
> be out of scope for OAI - it depends on the scale you want to achieve
> for OAI.
>
> For example, my personal current interest in OAI is not for digital
> libraries. I see that it has potential for any site with metadata
> to reduce their traffic from web crawlers.
>
> I do not know what OAI 2.0 is going to be like. If it is XML request
> and response packets (as distinct from HTTP variables and XML responses)
> then you can easily come up with 'doing OAI with SOAP' documents.
> It might not be the ideal way to do it, but SOAP supports the concept
> of document/literal encoding where XML can be (almost!!) verbatim
> dropped in wrapper SOAP elements. Basically there would be a mechanism
> to get it more widely noticed.
>
> > All the best,
> > Tim.
>
> Thanks for the above and all your other comments.
>
> Alan
>
> ps: I have done another pass over various sites using POST having fixed
> bugs in my client. Things worked better. Full results are at
>
>     http://www.mds.rmit.edu.au/~ajk/oai/interop.htm
>
> Summary of failures (remember, bugs may be my client!):
>
>     XML parse errors: aim25, anlc, cogprints, NSDL-DEV-CU, SUUB
>     POST not supported: cimi, HUBerlin, lacito, physdoc
>     Resumption related: ethnologue, hsss
>     Other: aisri, CPS, EKUTuebingen, ibiblio, in2p3, mit.etheses, ota,
> thesis, tkn UDLAthesis, yea
>
> But on the success side, I have managed to collect 381,000 metadata
> records so far. I wonder what our next internet bill is going to be! :-)
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>