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

[ePrints Support]

<shame> cogprints has that bad XML glitch. I'm not sure how someone managed
to input such whacky data, but still the XML library it uses didn't handle it
in any clever way :(

cogprints is runing the latest version of eprints 1, and I plan to upgrade it
to eprints 2 when I find the time. If anyone else has got a problem with 
eprints 1 OAI I'll work it out. Probably a couple of lines to change.

I think the naming & shaming is a good idea as it will save serious harvestors
dealing with messy services and will encourage us naughty providers to clean
up our act!

chris/eprints.org

On Mon, Feb 11, 2002 at 12:21:04PM -0000, Tim Brody wrote:
> Hi Alan,
> 
> I don't believe the issue of "naming and shaming" repositories has come up
> before in OAI. I believe the theory is that the validation carried our
> during registration should make sure that publicly-accessible repositories
> are sufficiently error-free to be harvested.
> (so I don't know whether your results reflect more upon repository's
> implementations, or the OAI testing process ...)
> 
> 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.
> (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)
> 
> 
> Might I suggest an addition to your testing, that should be relatively
> simple (from the last new problem I found with a repository):
> Do records have an identifier and datestamp?
> 
> I noticed there were some problems with resumptionTokens - how does the
> repository behave when its given escaped/unescaped resumptionTokens?
> 
> I guess the verb problem is related to POST (and a misleading error
> message).
> 
> The required metadataPrefix/resumptionToken problem is because the protocol
> document isn't very clear. No arguments, apart from the verb, should be
> given when a resumptionToken is used. This exclusivity is confusing when the
> document says metadataPrefix is required.
> (perhaps a note should be added, making this clear?)
> 
> All the best,
> Tim.
> 
> ----- Original Message -----
> From: "Alan Kent" <ajk@mds.rmit.edu.au>
> To: "OAI Implementors" <oai-implementers@oaisrv.nsdl.cornell.edu>
> Sent: Monday, February 11, 2002 1:08 AM
> Subject: [OAI-implementers] Results for various sites trying POST requests
> 
> 
> > I have built up a HTML page of interop tests of a simple client
> > I was trying to write (ie: might be buggy from my end) when trying
> > to POST to various other servers out there. I have not tried GET
> > requests instead. I supply the VERB in the POST data (not on the
> > URL) which I think caused many of the faults.
> >
> > There are several sites that I have not yet sucesfully completed
> > a download of. A network problem or similar occurs before they
> > finish, so I have to restart from scratch.
> >
> > If people are interested, the results can be found at:
> >
> >     http://www.mds.rmit.edu.au/~ajk/oai/interop.htm
> >
> > In the SOAP interop test bed (which I have been involved a little bit
> > in), people with clients and servers tend to host such pages which
> > has helped a lot in achieving interoperability. Nothing like airing
> > dirty laundry to get people to clean up their act! :-) From my
> > reading so far of OAI, I suspect there may not be the same push
> > behind OAI.
> >
> > If I have missed a site, please let me know and I will add it.
> > The table is currently manually maintained - I am still investigating
> > OAI to see if its worth pursuing further. If people are interested
> > (including me! :-), I could investigate generating such tables
> > automatically including more detail (wire dumps). A sample page
> > for SOAP interop is at
> >
> >     http://www.mds.rmit.edu.au/~ajk/soap/interop-results.htm
> >
> > Alan
> >
> > ps: The product I work on is currently undergoing a name change from
> > SIM to TeraText, so I probably will mix up the names until I brainwash
> > myself to the new name! :-)
> > _______________________________________________
> > 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

-- 

 Christopher Gutteridge                   support@eprints.org 
 ePrints Developer                        +44 23 8059 4833