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

[Pierrick Brihaye]

Salut,

Quelques précisions...

Martin Sevigny a écrit:

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

Oui... et c'est un peu ce que je déplore :-)

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

On est d'accord. Je mentionnais ça pour la symétrie de conceptualisation 
: toute vue, quelle que soit sa finalité, devrait être :

1) accessible en lecture/écriture
2) générable dynamiquement ou statiquement.

Je sais, c'est une vue de l'esprit : certaines vues ne seront jamais 
lues (vue d'indexation p.e.) et d'autres n'ont aucun intérêt à être 
dynamiques.

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

Mmmh... j'ai du mal à comprendre ou tu veux en venir. En fait, ce que je 
voudrais pour les vues de résultats, c'est de la structure :
<sdx:result id="xxx">
  <titre>Un titre</titre>
  <resume>Ceci est un <motcle>résumé</motcle>.</resume>
</sdx:result>

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

Certes. Mais ça, c'est l'option dynamique. Une option statique devrait 
être possible. Imaginons par exemple des PDF sur de gros documents : on 
a peu de chances de bénéficier du cache et on va bouffer toutes les 
performances. Certes, ces vues statiques seraient grosses consommatrices 
de disque et, *une seule* fois, de ressources... A générer quand la 
charge serveur est faible.

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

J'entends bien.

> (ce qui n'empêche pas de le devenir).

IMHO, c'est souhaitable. J'envisage sérieusement de coupler SDX à des 
outils de production...

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

Bien sûr. Et la 4 aussi d'ailleurs !

1) tu as complètement raison sur le fait qu'on doive avoir un "S". Pour 
un document natif, on pourrait avoir N indexations (stockées dans des 
repository ad hoc), N présentation de résultats, N présentations de 
documents. Je crois qu'Emmanuel Bégué devrait apprécier :-)

2) Par transformation, XSLT est bien sûr privilégié, mais on pourrait 
concevoir n'importe quel type de transformateur (l'analyseur d'Echelon 
par exemple qui crée un résumé en américain administratif à partir d'un 
mail en ourdou :-))

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

Oui. Mais, *aujourd'hui*, ça n'existe pas :-)

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

Si tu veux ; je parle de ce que je connais et de ce qui est libre :-)

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

1) Il y aura peut-être un bémol à mettre si certains projets du W3C 
aboutissent : http://www.w3.org/TR/xmlquery-full-text-requirements/

2) Entendons-nous bien : il paraît difficile de proposer des requêtes 
XPath, mais on peut tout à fait concevoir des analyseurs de requêtes 
permettant de transcrire une requête "human-readable" ("writable" en 
fait) en XPath. Il y a là, selon moi, un gros enjeu !

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

L'indépendance des vues : SDX serait un moteur qui aurait 
essentiellement à gérer des *relations* entre vues différentes (dans 
leur nature comme dans leur finalité).

En SGDB, tu as une équivalence *totale* entre vue native (des valeurs 
dans des champs dans des tables) et vue cherchable (des valeurs dans des 
champs dans des tables, certaines d'entre elles, les index, bénéficiant 
d'un accès plus rapide)

En XML:DB, tu as une équivalence totale entre vue native (des documents 
XML dans des collections dans des bases) et vue cherchable (idem). Par 
contre, cette équivalence disparait à la diffusion : tojours ça de gagné.

Sous SDX : une vue cherchable peut ne rien avoir à voir avec le document 
natif. Tu peux stocker une pièce de Shakespeare et indexer des 
métadonnées générés à l'upload à parti d'un formulaire par exemple. Idem 
pour *toutes* les autres vues dans l'idéal.

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

Je suis, disons archiviste :-)

Je transcris mes documents en XML (Docbook, TEI...)
J'indexe des métadonnées (côte) : mon boulot consiste simplement à créer 
ces métadonnées ; les données en tant que telles ne m'intéressent pas.
Je propose une vue PDF pour impression, mais comme j'ai des documents de 
plusieurs centaines de pages, je préfère les générer une fois pour 
toutes et, bien sûr, je les sotcke sur mon serveur.

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

On n'en est pas loin :-) Dans mon scénario, cependant, l'élément central 
de l'arcitecture n'est plus la "base de documents" mais... le repository :

<sdx:application>
  <sdx:repository usedfor="storage"/>
  <sdx:repository usedfor="search"/>
  <sdx:repository usedfor="results"/>
  <sdx:repository usedfor="publishing"/>
  <sdx:repository usedfor="relations"/>
</sdx:application>

Ca, c'est la version simple où on a tout en statique. Je pense que 
l'attribut usedfor est explicite, mais je peux développer :-)

Ensuite, on a des actions SDX.

<sdx:upload> travaillera bien sûr avec un sdx:address@hidden"storage"]

ensuite...

<sdx:makesearchview docid="xxx" storein="indexationrepository"/>
<sdx:makeresultsview docid="xxx" storein="resultsrepository"/>
<sdx:makepublishingview docid="xxx" storein="resultsrepository"/>

Bien sûr, on peut faire plus élégant. Basiquement, il "suffit" de 
prendre un flux en entrée et de ressortir un flux en sortie avec, au 
passage, toutes les transformations (XSLT ou pas) que l'on veut.

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

Oui :-)

Je termine là dessus :

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

1) ce choix est tout à fait honorable :-) et doit *absolument* être conservé
2) je vous propose de faire de SDX un outil de *recherche* avec une 
indexation *structurée* qui élminerait le bruit de fond (à condition que 
la requête soit bonne, évidemment).

Recherche/Documentation : je suis payé pour ça :-)

La discussion est plus que jamais ouverte. A bientôt,

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