RE: [sdx-users] q comme query

[Frédéric Glorieux]

 > <sdx:result>
 >    <h>Titre</h>
 >    <p>Résumé</p>
 >    <liens>
 >      <lien>Document "supérieur"/<lien>
 >      <lien>Document "inférieur"/<lien>
 >    </liens>
 > </sdx:result>

Si je veux ça, je m'inclus les documents dans les résultats ?

 > Hmmmm. Voire : avec des entrepôts URL, on a une pérénnité...
variable
 > :-) C'est d'une puissance phénoménale !

Là, je vois un autre problème. Des tâches d'indexations
automatiques et paramétrables.

Toi aussi tu as besoin d'être détypé Lucene :-) Ce que tu nommes
"champ"
(org.apache.lucene.document.Field), j'appelle ça un "index". Peu
importe...

        Non, pour moi ce sont des champs répétables dont on a
distinctement défini le contenu avec une XSL tissée main. Qu'il y
ait derrière un analyseur qui indexe mot ou tout, en tant que
concepteur d'appli, c'est d'abord une source de confusion
(l'intérêt d'indexer des chaînes exactes vient après).
        Des index SQL, je n'y vois pas du tout la même chose, je n'ai
jamais trop compris, à part que je demanderais bien à mon SGBD de
cs'optimiser lui-même en fonction des requêtes qu'il rencontre.
        Pour un index DB:XML, je l'imagine plus que je ne l'ai essayé,
je suppose un fichier de configuration optimisant à l'avance
certaines requêtes xPath. Mais là encore, la totalité du document
me reste accessible, contrairement aux champs lucene.

        Je vois bien l'intérêt de brancher un DB:XML avec SDX, en faire
le standard livré avec, comme Lucene. Il faut par contre
s'assurer que le déploiement reste aussi simple (de ce que j'ai
lu, Exist le prétend).
        Par défaut, on utiliserait le DB:XML comme entrepôt, on
garderait Lucene pour le plein texte, et on pourrait aussi faire
des requêtes xPath a posteriori, ça me convient très bien. Je
vois déjà une application concrète, Bib-X, ou toutes sortes de
serveurs de documents XML faiblement rédactionnels mais fortement
structurés. On peut changer la recherche avancée sans devoir
changer application.xconf et son indexation.xsl.
        Dans l'esprit, application.xconf ne doit pas être trop
dynamique, cela permettrait par exemple d'utiliser à peu près la
même syntaxe, pour configurer un DB:SQL (pour documents plats à
champs non répétables mais haute exigences de performances).