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

[Martin Sevigny]

Bonjour,

Quelques commentaires précis et des remarques générales à la fin...

> 1) SDX permet de stocker/mettre à disposition des documents dans des 
> entrepôts (repositories)

Je ne crois même pas qu'il peut faire cela actuellement. Il ne peut le
faire qu'à traver la base de document / jeu d'index, qui est l'interface
obligée d'accès aux documents des entrepôts.

> 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 :-)

Je serais curieux de mettre un keep=true à la dernière transformation
d'un pipeline d'indexation... Mais bon, je sais, c'est un détail...

> 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...

... et aussi l'ancienne architecture SDX 1 / Cocoon 1. Aujourd'hui,
grâce à la nouvelle architecture Cocoon 2, cet aspect a beaucoup moins
d'intérêt.

> 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.

Et la (spectaculaire) cache de Cocoon? C'est exactement ce qu'elle fait
si on lui demande, non?

> 1) des vues sur les documents *natifs*.  En termes de finalités, ça 
> permet le stockage.

Ce qui n'a jamais été un objectif de SDX (ce qui n'empêche pas de le
devenir).

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

Pour moi, 2 et 3 de résument à "vues transformées" ou les "s" sont
importants...

> 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.

Un plus tout de même très temporaire... Et facile à contourner en SGBD
XML (encoder en Base64 le binaire dans des XML bidons en attendant que
les SGBD XML s'y mettent).

> 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).

Oui, voilà, c'est, je le répète et le répèterai, le principal choix
conceptuel de SDX dès les premières _heures_ de son existence :
utilisation de la structure au moment de l'indexation, pas de la
recherche.

> 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 !

En fait, Pierrick, ne serait-il pas plus sage de parler de "SGBD XML"
plutôt que XML:DB qui fait référence à un protocole précis et défini? Ou
parce que tu veux volontairement limiter à XML:DB? Dans ce cas pourquoi?
Conceptuellement XML:DB/Xpath n'est pas du tout approprié pour du
documentaire et tout le monde le sait...

> 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.

Oui, faire de SDX une interface à moteurs de recherches documentaires
XML, cela a déjà été évoqué par un certain PB de ma connaissance ;-)

> - 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 :-)

Je comprends bien l'exemple SGBD, mais sa relation avec la première
phrase?

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

OK, maintenant les questions et commentaires généraux.

A) Pour mon bénéfice et, je crois, pour celui d'autres lecteurs
attentifs de tes messages, pourrais-tu nous donner des contextes
d'utilisation où une telle architecture apporterait quelque chose, par
rapport à SDX et aux autres outils ?

B) Si on suppose que SDX évolue légèrement vers une meilleure
terminologie, quelques corrections de dissymétrie dans son architecture
appli/index/entrepôts, que les différentes étapes d'indexation soient
toutes récupérables comme autant de vues, que l'on apprenne à utiliser
correctement la cache de Cocoon et que soient ajoutés quelques autres
moteurs de recherche (XML:DB / Xpath, XML Query, ...) ou types
d'entrepôts (CVS, XML:DB, ...) ... Que manquerait-il pour arriver au
scénario que tu évoques ici?

C) Je pense qu'il est grand temps de relancer le débat sur l'évolution
de SDX et la prise de décision ;-)

A bientôt,

Martin Sévigny