[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sdx-developers] Conformité OAI-PMH
From: |
Pierrick Brihaye |
Subject: |
[sdx-developers] Conformité OAI-PMH |
Date: |
Wed, 12 Nov 2003 11:54:29 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 |
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
- [sdx-developers] Conformité OAI-PMH,
Pierrick Brihaye <=