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

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

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

Bien sûr ! Ce que je mentionnais c'est que as de la structure dans les 
vues natives et dans les vues de publication alors que tu n'en a pas 
dans les vues d'indexation et de résultats ? Pourquoi un tel ostracisme 
:-))) ?

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

Evidemment.

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

Injecter les documents produits dans SDX. SDX devient donc leur *seul* 
lieu de *stockage*.

> Ca ne veut pas nécessairement dire
> que ça demande un changement à SDX...

Nous sommes bien d'accord.

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

Bien sûr ;-) Le gros problème de Cocoon, c'est que ça donne des goûts de 
luxe :-)

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

Très juste ! ...et très bon jeu de mots au demeurant :-)

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

OK. V. cependant les extensions XPath de eXist : c'est également un bon 
angle d'attaque IMHO... En fait, c'est surtout à elles que je pensais 
parce que je les pratique pratiquement au quotidien.

> > 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 va en reparler...

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

Tout le monde est d'accord :-)

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

Mmmh... on peut peut-être le faire en 15 jours, mais, IMHO, on est quand 
même très dépendants de LuceneDocumentBase.java et, dans les config, de 
<sdx:documentbase>. Pour être clair, je pense que cet élément n'est pas 
à pas à la bonne place : pour moi, c'est un repository d'indexation qui, 
contrairement aux autres types de repositories, dispose d'une interface 
de recherche...

Je reprécise que lorsque le schéma a été proposé, je n'ai rien trouvé à 
redire et j'assume donc ma responsabilité.

> Tout le reste n'est que détail architectural, mais:
>
> - demanderait plus de développements

Certes, mais ça aurait le mérite de les recentrer sur l'essentiel :

- les repositories (l'essentiel du travail est fait... et bien fait !)
- les parseurs de requêtes
- le jeu d'actions qu'on peut offrir

En fait, dans mon optique, SDX serait essentiellement un gestionnaire de 
repositories (pour le statique) et proposerait un jeu "canonique" de 
générateurs Cocoon (pour le dynamique). La taglib se chargerait 
essntiellement de faire communiquer les repositories entre eux.

> - rendrait la migration des applications existantes plus difficile

J'en suis hélas aussi persuadé que toi.

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

Je comprends bien ; mais je suis prêt à accepter une transition "en 
douceur". En l'état actuel de ma reflexion, il m'est encore difficile de 
passer du "conceptuel pur" au code.

A bientôt,

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