Re: [sdx-developers] RE : [sdx-developers] RE : Métadonnées systèmes

[Pierrick Brihaye]

Salut,

>Si on postule que ce format est le cœur de SDX, alors nous n'avons pas
>besoin d'autre moteur de recherche que Lucene car celui-ci le fait très
>bien.

La réponse est claire et pertinente. Dans ce cas, getFields n'a pas sa place 
dans indexableDocument... ou alors, on réserve ces documents à Lucene.

>Si on définit aussi une base de documents XMLDB avec le _même_ entrepôt
>de documents (ce sera possible bientôt!) et qu'on fait des recherches
>Xpath dessus, on pourra répondre aux requêtes sur la structure.

On est d'accord.

>Dans un entrepôt XMLDB, les champs n'existent pas (toute la structure
>XML est disponible en requêtes) et les index sont des index à la SQL :
>de simples améliorations de performance. Donc je ne crois pas que la
>définition des index XMLDB soit similaire à la définition des champs
>Lucene.

Là , on pourrait discuter. Je reste persuadé que le document d'indexation 
(collection de <sdx:field>) a vraiment sa place. De but en blanc, je m'en 
servirais pour faire ce que j'ai appelé des "métaindex", c.a.d. diminuer plus 
ou moins le niveau de granularité de la structure.

>Ca pourrait l'être ou pas. En XMLQuery, j'espère que l'on pourra avoir
>comme résultat un document XML qui reprend, par exemple, la hiérarchie
>de ce qu'il a trouvé. Par exemple, si tu fais une recherche (dans un
>grand document de type DocBook) telle que "//section[title[contains(.,
>'test')]], ça pourrait être intéressant d'avoir comme résultat :

OK. Je vois. Là encore on touche à un postulat de SDX (en tout cas, ça l'était 
pour moi) : l'unité atomique n'est plus forcément le document. C'est 
intéressant, mais jusqu'où ça va nous mener ? :-))

p.b.