[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE : RE : [sdx-users] Qu'est ce que SDX ?
From: |
Pierrick Brihaye |
Subject: |
Re: RE : RE : [sdx-users] Qu'est ce que SDX ? |
Date: |
Wed, 05 Mar 2003 10:36:33 +0100 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0.1) Gecko/20020823 Netscape/7.0 |
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