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

[Martin Sevigny]

Bonjour,

Rapidement...

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

Justement, si (supposons) que SDX est capable de t'envoyer cela, c'est
parce que tu as été préalablement capable, via un pipeline
(d'indexation) SDX (XSLT...), de créer ton <titre>, <resume>... Etc.
depuis ton document, non?

Alors rien ne t'empêche de reprendre ce pipeline pour afficher des
résultats brefs.

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

Justement, que signifie "coupler"? Ca ne veut pas nécessairement dire
que ça demande un changement à SDX...

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

Une transformation au sens Cocoon/SDX. Déjà plus large que XSLT... C'est
une interface Java à implémenter.

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

Ah!

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

Justement, ce n'est pas un bémol à ce que je dis, c'est plutôt un dièse,
c'est exactement ce à quoi je pensais. XMLQuery arrivera (un jour) à
faire du bon documentaire/plein texte. Mais pour moi ce n'est pas
XML:DB/Xpath. C'est pour cela que je voulais apporter la précision.

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

Je rejoins Frédéric là-dessus et je clame haut et fort : ANT!

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

OK, je vois.

> Ensuite, on a des actions SDX.

Idem.

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

Je ne pense pas qu'il est honorable, il a été dicté par les
circonstances. Pour moi, ce fut douloureux (et ça l'est encore dans un
certain sens). Quand à être conservé, soit, comme une option, mais pas
la seule.

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

Oui, ça fait longtemps qu'on est convaincu de cela (théoriquement, et
pratiquement récemment grâce à toi), mais ce que je ne comprends pas,
c'est qu'on peut faire cela en disons 10-15 jorus de développement en
ajoutant une nouvelle implémentation de DocumentBase utilisant XML:DB
dans le SDX actuel. Et un jour avec un moteur XMLQuery, etc.

Tout le reste n'est que détail architectural, mais:

- demanderait plus de développements
- rendrait la migration des applications existantes plus difficile

C'est là que je ne suis pas...

A bientôt,

Martin Sévigny