[sdx-users] Qu'est ce que SDX ?

[Pierrick Brihaye]

Bonjour,

Pour celles et ceux que ça intéresse, voici mes réflexions actuelles sur 
la nature de SDX et donc sur les possiblités d'amélioration et, surtout, 
sur son positionnement par rapport à d'autres logiciels.

J'espère qu'elle seront matière à débat et ce, d'autant plus que tout 
n'est pas encore bien clair de mon côté...

Voilà :

1) SDX permet de stocker/mettre à disposition des documents dans des 
entrepôts (repositories)
2) SDX permet de stocker des documents d'indexation dans des jeux 
d'index (documentbase). Une mise à disposition de ces documents 
d'indexation est possible si on repasse le document dans la XSL 
d'indexation... mais ce n'est pas très orthodoxe :-)
3) SDX permet de stocker/mettre à disposition des documents de résumé 
dans des index pour la présentation de résultats (champs "brief" des 
documents d'indexation). En l'état actuel des choses, ce point est 
étroitement associé au point 2) à cause/grâce à l'architecture Lucene 
sous-jacente...
4) SDX permet de mettre à disposition des documents préalablement mis en 
forme grâce aux XSL. Etant donné le mécanisme actuel, on ne peut pas 
stocker ce type de documents : ils sont générés dynamiquement grâce à la 
sitemap.
5) SDX permet de stocker/mettre à disposition des relations entre 
documents, qu'ils soient XML ou non. Pour l'instant, seuls trois types 
de relations sont possibles : documents originaux, documents attachés et 
sous-documents.

Mettons tout cela à plat en introduisant un concept générique pour les 4 
premiers points : les *vues*. Voici ce que ça donne :

1) des vues sur les documents *natifs*.  En termes de finalités, ça 
permet le stockage.
2) des vues sur les documents *d'indexation*. En termes de finalités, ça 
permet l'interrogation.
3) des vues sur des *résumés*. Finalités évidentes.
4) des vues de *diffusion*. Finalités évidentes également.

Réordonnons tout cela :

1) vue native
2) vue cherchable
3) vue de résumés
4) vue de diffusion

Pour le point 1), une XML:DB sait faire ça très bien. SDX apporte tout 
de même un plus : il sait stocker des documents non-XML.

Pour le point 2), une XML:DB sait aussi le faire mais SDX introduit 
beacoup plus de souplesse car une XML:DB postule que l'indexation doit 
se faire à partir de la structure du document. SDX permet de définir ce 
que l'on veut, que se soit à partir du document... ou non ! En revanche, 
pour l'instant, on perd la structure (document à 2,5 dimensions).

Pour le point 3) une XML:DB sait aussi le faire... à condition de poser 
la bonne requête, ce qui n'est pas forcément pratique en XPath. A vrai 
dire, c'est même très coton ! A noter, que comme on est étroitement lié 
au point 2), on n'a pas énormément de structure. Dommage !

Pour le point 4), c'est Cocoon qui prend cela en charge. Une XML:DB 
comme eXist (http://exist.sourceforge.net/) propose un cadre Cocoon très 
sympathique pour gérer ça.

En résumé, SDX va généralement au-delà de ce qui existe (jeu de mots). 
Il peut arriver qu'il soit en retrait.

Voyons comment on peut améliorer les choses :

1) vue native : bien que l'architecture actuelle soit déjà très 
générique, il faudrait pouvoir proposer plus de repositories ; je pense 
à des repostories CVS ou XML:DB comme le font certains éditeurs XML... 
du commerce.

2) vue cherchable : il faudrait pouvoir garder de la structure et, 
idéalement pouvoir stocker les documents dans des entrepôts tout à fait 
comparables à ceux qui viennent d'être évoqués, Lucene n'en étant qu'un 
parmi d'autres.

3) vue de résumés : voir le point 2... qui nous ramène au point 1 :-)

4) vue de diffusion : il faudrait pouvoir générer une vue *statique* des 
documents et... les stocker dans des repositories. Encore une fois, on 
en revient... au point 1).

Moralité :

- SDX permet de stocker ces vues sur différentes architectures. Plus il 
y en aura de disponibles, mieux cela sera. Mais ça, on le savait déjà...

- SDX est un système de gestions de vues sur différents types documents, 
chaque type disposant d'une finalité précise :
1) stockage
2) recherche
3) résumés
4) présentation

- SDX se démarque des autres produits dans le sens où chaque vue est 
potentiellement indépendante des autres. Essayez un peu de faire une 
recherche SGDB sur un champ qui n'existe pas dans vos données d'origine 
pour voir :-)

Ceci dit, on a selon moi quelques faiblesses de design et ceci, selon 
deux angles d'attaque :

Premièrement, l'aspect écriture/lecture.

1) vue native : pas de problème réel.
2) vue cherchable : pas de lecture possible nativement. Facile à faire 
avec une petite manipulation dans la sitemap. Intérêt limité à vrai dire...
3) vue de résultats : on a évidemment une possibilité de 
lecture/écriture même s'il faut jongler à cause l'étroite imbrication 
avec le point précédent. Il faudrait clairement séparer les 2 logiques.
4) vues de diffusion : ici manque la possibilité de les écrire, ce qui 
revient à dire qu'on pourrait les définir *statiquement*. Pas si 
complexe non plus... si on utilise un entrepôt et des relations ad hoc.

Deuxièmement, l'aspect statique/dynamique

1) vue native : les entrepôts URL proposent, par définition, une 
résolution dynamique des documents (pour le meilleur et pour le pire), 
les autres entrepôts sont, toujours par définition, statiques. Bien :-)
2) vue cherchable : statique, par définition. Il paraît inconcevable de 
générer dynamiquement ces vues en mémoire. Mais bon, pourquoi pas ? 
C'est ce que fait eXist dans ses recherches de *contenu* (vs. de 
structure) après tout...
3) vues de résultats : statiques dans le sens où elles sont générées au 
moment de l'indexation, dynamiques dans le sens où c'est Lucene qui les 
fournit à l'exécution des requêtes. IMHO, on peut améliorer...
4) vues de diffusion : voir ci-dessus ; on en revient au débat 
lecture/écriture.

Bien sûr, certaines vues sont intrinsèquement statiques alors que 
d'autres (moins) sont intrinsèquement dynamiques. J'ai abordé cette 
problématique pour faire de jolis schémas bien symétriques :-)

Voilà où j'en suis. Je suis preneur de tout autre type de vue... et de 
tout commentaire en général.

A bientôt,

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