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

[Frédéric Glorieux]

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

Ce qui n'est pas le plus intéressant, il faudrait pouvoir coupler à un
CVS ou à un véritable logiciel d'administration de contenus, mais ne
rien surcoder de ce qui existe déjà.

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

L'attribut keep="true" dans un pipe d'indexation permet de conserver une
part du travail. Une requête d'export (sans éléments sdx), permet de les
retrouver enchaînés. Le résultat <sdx:field name="titre">... n'est qu'à
moitié intéressant, n'est-il pas ?

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

Cocoon sait parfois mettre ce genre de chose en cache (il faudrait qu'on
sache mieux lui demander). Dans l'état, comment peut-on stocker par
exemple un résultat de recherche ? Pour des transformations statique,
pourquoi pas ant, ou du cocoon en ligne de commande ? Pour du véritable
dynamique, je ne vois rien d'autre, à part entretenir des logs colossaux
de toutes requêtes exécutées.

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

C'est une potentialité future très intéressante mais à bien réfléchir
pour ne pas lier les documents à SDX. Comment garder trace de ces
attachements pour un navigateur, ou d'autres systèmes ?

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

OK, ce n'est pas l'architecture SDX qui pose problème, il faut se faire
une appli pour voir comment ça tourne.

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

Et la recherche plein texte !!!

> 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 moins de documents avec de bonnes consignes rédactionnelles, genre
<book>
        <title>...
        <abstract>...
        <section>
                <title>...
                <abstract>...

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

OK

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

Ne reste plus qu'à se donner l'occasion d'un exemple.

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

Si ant ne convient pas, il existe peut-être quelque part une action
cocoon qui peut convenir.

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

Je préfère confier ce boulot à cocoon, ils sont plus nombreux.

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

Mais ant c'est très bien !

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

En fait je ne vois rien là d'impossible, mais j'ai peur que les missions
de SDX sont ici étendues au-delà de ce que l'on sait bien faire, sauf à
mentir comme n'importe quel autre .com, et dire que l'on fait tout seul
ce que cocoon ou ant sait faire à notre place.

Pour ma part, j'aurais même tendance à vouloir encore plus restreindre
les missions de SDX, avec en fait cette ambition, le mettre chez Apache
en sous-projet cocoon (mais alors, oublié saxon, il faudra supporter
xalan). On pourrait voir aussi ce qu'il peut apporter à Ant (pour ses
aspects statiques), mais là à sec, je cale.