[sdx-developers] SDX 3 : approche conceptuelle

[Pierrick Brihaye]

Salut,

Pour les archives :-)

Je pense que vous avez tous lu, au moins les grandes lignes, les 
échanges du thread "Qu'est-ce que SDX ?" dans [sdx-users]. Du point de 
vue du développement, voici ce que ça donnerait.

Note importanten : je ne préjuge en rien d'une 
compatibilité/incompatiblité avec le code existant ; cette préoccupation 
est, pour moi, prématurée pour l'instant, en tout cas, dans son aspect 
global.

Voilà :

A) SDX est un gestionnaire de vues sur des documents (essentiellement 
XML mais pas seulement).

B) Ces vues sont générées par des transformateurs tels que les entend 
Cocoon (fichiers XSLT mais pas seulement).

C) J'ai, pour l'instant, identifié 5 types de vues (en fait, la 3ème 
vient de Fred :-) :

1) vue native des documents (stockage)
2) vue d'indexation
3) vue de jeu de résultats
4) vue de résultat
5) vue de publication

D) Toutes ces vues doivent idéalement être accessibles en lecture/écriture

E) Toutes ces vues doivent idéalement pouvoir être :

1) statiques
2) dynamiques

F) Si je me place pour l'instant dans une perspective entièrement 
statique, toutes ces vues doivent pouvoir prendre place dans des 
repositories.

En dynamique, on est assez proche du concept de générateurs Cocoon (à 
ceci près qu'un générateur sert a priori à lire plutôt qu'à écrire). Ci 
après veuillez considérer que les vues dynamiques sont confiées à des 
repositories... en mémoire.

G) Evidemment, on aurait un repository supplémentaire pour stocker les 
relations entre vues.

H) Le nombre de relations inter-vues est potentiellement illimité. On 
peut donc avoir N indexations pour un même document natif.

I) En principe, SDX devra savoir gérer la combinatoire relationnelle 
entre entre les vues "canoniques". Si un utilisateur utilise une vue, il 
devra s'engager à mettre en place les relations dont il a besoin. On 
peut bien sûr lui faciliter la tâche en lui proposant des API ad hoc.

J) il est à noter que les relations, au moins certaines d'entre elles, 
doivent pouvoir être *typées*. Actuellement, on a un typage "document 
attaché" ou "sous-document" dans les repositories de stockage. On peut 
imaginer des tas d'autres types : ancien état CVS, réplication DBMS, URL 
alternative...

K) la taglib devra proposer des API génériques de gestion du contenu des 
repositories. Typiquement, on pourrait avoir des trucs comme ça :

<sdx:insert>
  <sdx:from id="stockage"/>
  <sdx:pipeline src="indexation.xsl"/>
  <sdx:to id="indexation" />
</sdx:insert>

ou

<sdx:update>
  <sdx:from url="http://server/documents/mydoc.xml"/>
  <sdx:to id="stockage">
    <sdx:pipeline src="idgenerator.xsl"/>
  <sdx:to>
</sdx:update>

Note : exemples provocateurs. En fait, on a là de beaux pipelines Cocoon 
n'est-ce pas ?

Bien sûr, on peut aussi aliaser. Le deuxième exemple pourrait par 
exemple s'aliaser en <sdx:uploadDocument> ;-)

L) Les fichers de config pourraient ressembler à çà :

<sdx:application>
  <sdx:storagerepository id="storage" type="JDBC"/>
  <!-- ;-)) -->
  <sdx:indexationrepository id="indexation" type="LUCENE">
    <sdx:pipeline src="indexation.xsl" default="true"/>
  </sdx:indexationrepository>
  <sdx:resultsrepository id="results" type="MEMORY"/>
  <sdx:resultrepository id="results" type="XMLDB"/>
  <sdx:publishingrepository id="result" type="FS">
    <sdx:pipeline src="doc2html.xsl" default="true"/>
    <sdx:pipeline id="pdf" src="doc2pdf.xsl"/>
  </sdx:publishingrepository id="result" type="FS">
  <sdx:relationsrepository id="relations" type="JDBC"/>
</sdx:application>

Note : les pipelines de publication ne sont qu'une proposition. Il n'est 
a priori pas question de refaire une sitemap Cocoon quand on peut en 
profiter.

M) Ces repositories devront autant que faire se peut être génériques. 
idéalement, il devraient pouvoir stocker/exploiter de la structure sinon 
on lance une TooMuchStructuredException :-) Au développeur 
d'applications de fournir du contenu gérable par le type de repository 
qu'il aura choisi.

Les repositories auraient donc impérativement une interface 
insert/update/delete. Certains, en particulier le resultsrepository 
pourraient bénéficier d'une méhode search... et cette méthode pourrait 
s'interfacer avec des QueryParsers dont le rôle serait de transcrire une 
requête (utilisateur ou système) dans le langage de requête natif du 
repository (SQL, XPath, Lucene...)

Voilà. Qu'en pensez-vous ?

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