[sdx-developers] Sources de documents

[Martin Sevigny]

Bonjour,

Le développement et l'expérimentation OAI nous amène à réfléchir un peu
sur la manière dont SDX va chercher les documents qu'il indexe.

Typiquement (donc avant OAI et sans développement spécial pour une
appli), l'indexation de documents dans une base de documents SDX était
toujours manuelle, c'est-à-dire déclenchée par une action d'un
administrateur.

Maintenant, notamment avec l'OAI, on quitte un peu cette approche, car
lorsqu'on demande à SDX d'aller moissonner des métadonnées dans un
entrepôt OAI distant, et ce à toutes les nuits à 3h05, l'indexation
n'est pas déclenchée par un opérateur, elle est automatique et
programmée.

D'où l'idée d'une "source de documents", où SDX peut s'alimenter tout
seul comme un grand.

Des sources potentielles et "normalisées" de documents, j'en vois déjà
un certain nombre:

- OAI harvesting : déjà implanté
- Entrepôt WebDAV (protocole de gestion de documents)
- Entrepôt CVS
- Répertoire de fichiers
- Robot explorateur de sites Web

Toutes n'ont pas les mêmes caractéristiques techniques, mais à mon sens
elles en partagent un certain nombre:

- elles ont une localisation, un moyen d'accès
- elles peuvent avoir une méthode et des paramètres d'authentification
- on peut avoir une liste d'actions à effectuer pour obtenir du contenu
(des documents)
- on peut vouloir lancer une liste d'actions périodiquement, ou à un
moment précis, ou suite à une action humaine

Donc ce que j'aimerais introduire dans la structure application.xconf,
ce sont un certain nombre de concepts ou d'objets génériques, qui
seraient (les noms pourront être modifiés, ce ne sont que des
propositions):

<sdx:documentSource> => identifie une source de documents
<sdx:action> => une action
<sdx:schedule> => la programmation d'une action (de type cron)

La programmation quotidienne à 3h00 de la moisson d'un entrepôt OAI
pourrait se faire ainsi:

<sdx:documentSource type="OAIHarvester"
     adminEmail="address@hidden"
     url="http://toto/sdx/sdx/oai/sdxtest/sdxworld";>

  <sdx:schedule type="cron" id="sch1">
    <sdx:hour>3</sdx:hour>
  </sdx:schedule>

  <sdx:action type="OAIVerb" schedule="sch1"
        name="ListRecords"
        metadataPrefix="sdx"/>

  <sdx:pipeline>
    <sdx:transformation type="XSLT" src="index-oai.xsl"/>
  </sdx:pipeline>

</sdx:documentSource>

L'idée est d'utiliser le même truc que pour d'autres objets dans SDX :
l'attribut type (de sdx:action par exemple) donne une information sur la
classe à instancier, et l'objet de cette classe reçoit le XML de
configuration et se configure lui-même, d'où l'idée de mettre des
attributs spécifiques, il pourrait y avoir des sous-éléments, etc.

Au hasard, prenons un exemple de source CVS (aucune implémentation n'est
planifiée!). Ca pourrait donner ceci:

<sdx:documentSource type="CVS"
     protocol="pserver"
     server="cvs.a.com"
     repository="/cvshome"
     username="a"
     password="b">

  <sdx:schedule type="cron" id="sch2">
    <sdx:hour>4</sdx:hour>
  </sdx:schedule>

  <sdx:action type="update" schedule="sch2"
        module="my-project">
    <sdx:includes name="*.xml"/>
  </sdx:action>

  <sdx:pipeline>
    <sdx:transformation type="XSLT" src="index-oai.xsl"/>
  </sdx:pipeline>
  
</sdx:documentSource>

Il faudrait éventuellement réfléchir à des sources de documents dont
l'alimentation peut être déclenchée depuis l'extérieur, mais de façon
programmatique. Par exemple, un petit outil sur un serveur WebDAV qui
alerte la base de documents SDX que des nouveaux documents sont arrivés.

Ca pourrait se faire par un élément <sdx:callback> qui pointe sur un
objet qui fait ce qu'il veut pour "écouter" les appels externes, l'objet
ayant été construit avec un pointeur sur la source de documents, donc il
peut déclencher des actions s'il le souhaite. Tout cela est très
spécifique, mais je ne connais pas d'API ou protocoles normalisés qui me
donnerait un exemple...

Qu'en pensez-vous? Je pense qu'on peut assez aisément refactoriser le
code OAI actuel pour entrer dans ce moule, et ça laisse beaucoup de
marge pour des évolutions futures. Ce qui est le plus important
maintenant, c'est de voir si j'ai rien oublié de majeur dans la
séparation en source/schedule/action.

A bientôt,

Martin Sévigny