[sdx-developers] Conformité OAI-PMH

[Pierrick Brihaye]

Re,

Comme prévu, voici quelques tests sur un repository OAI géré par SDX 
(version inconnue, ce qui peut expliquer certains bugs). Merci à celui 
qui m'offre cet espace ;-)

http://trantor.sisib.uchile.cl:8080/sdx/sdx/oai/uchile/documents?verb=Identify

Réponse :

<Identify>
  <protocolVersion>2.0</protocolVersion>
  <repositoryName>oai</repositoryName>
  <granularity>YYYY-MM-DDThh:mm:ssZ</granularity>
  <deletedRecord>transient</deletedRecord>
</Identify>

Conformité :

The response *must* include one instance of the following elements:
OK : repositoryName : a human readable name for the repository;

Pas OK : baseURL : the base URL of the repository;

OK : protocolVersion : the version of the OAI-PMH supported by the 
repository;

Pas OK : earliestDatestamp : a UTCdatetime that is the guaranteed lower 
limit of all datestamps recording changes, modifications, or deletions 
in the repository. A repository must not use datestamps lower than the 
one specified by the content of the earliestDatestamp element. 
earliestDatestamp must be expressed at the finest granularity supported 
by the repository.

OK : deletedRecord : the manner in which the repository supports the 
notion of deleted records . Legitimate values are no ; transient ; 
persistent with meanings defined in the section on deletion .

OK : granularity: the finest harvesting granularity supported by the 
repository. The legitimate values are YYYY-MM-DD and 
YYYY-MM-DDThh:mm:ssZ with meanings as defined in ISO8601.

The response must include one or more instances of the following element:

Pas OK (sur le "or more") : adminEmail : the e-mail address of an 
administrator of the repository.

The response may include multiple instances of the following optional 
elements:

compression : a compression encoding supported by the repository. The 
recommended values are those defined for the Content-Encoding header in 
Section 14.11 of RFC 2616 describing HTTP 1.1.  A compression element 
should not be included for the identity encoding, which is implied.

description : an extensible mechanism for communities to describe their 
repositories.  For example, the description container could be used to 
include collection-level metadata in the response to the Identify 
request. Implementation Guidelines are available to give directions with 
this respect. Each description container must be accompanied by the URL 
of an XML schema describing the structure of the description container.

Pas testable en l'état.

Essai avec un mauvais argument :
http://trantor.sisib.uchile.cl:8080/sdx/sdx/oai/uchile/documents?verb=Identify&klkmlk

Ici, la réponse ignore purement et simplement ce "argument". C'est un 
choix... les specs ne sont pas claires (ou je n'ai pas trouvé). Doit-on ?

Condamner une réponse si un de ses arguments n'est pas valide ?
Faire avec ce qui est valide et ignore le reste ?

Il semble que ce soit le 2ème parti qui a été pris.

Je suis étonné que les specs ne soient pas plus précises sur ce point.

A bientôt pour d'autres verbes...

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden