Re: RE : RE : [sdx-users] présence d'un champ d'indexation dans le document

[Pierrick Brihaye]

Re,

Martin Sevigny a écrit:

> Oui, justement, c'est ce que je disais, mais c'est loin d'être
> suffisant. Et de toutes façons, dans l'esprit W3C ce n'est pas Xpath la
> solution à vos problème, c'est XML Query, qui de son côté va adresser le
> problème de la recherche de type plein texte. Ca va prendre encore
> quelques années...

Je vois parfaitement ce que tu veux dire ;-)

> > Oui. Le gros intérêt d'avoir une implémentation Xpath serait de 
> > permettre d'interroger la *structure* en plus du contenu.
>
> Tout le monde est d'accord là-dessus.

C'était un rappel pour les nouveaux contributeurs de cette liste... Je 
conçois que ça soit insistant pour les autres :-)

> > Quelle structure interroger ? Celle des documents ? Ou celle des 
> > documents d'indexation ? Je serais tenté de répondre : les 2 mon 
> > capitaine :-)
>
> Interroger des documents d'indexation serait un apport non négligeable
> de SDX, car parfois ça peut être drôlement intéressant.

Je le reprécisais car j'avais cru comprendre dans ce thread (et dans un 
autre BTW) que j'ai pris en cours de route qu'il avait été postulé au 
départ que document = indexation. Grâce à l'approche SDX, ceci n'a aucun 
caractère obligatoire. *Gros* avantage à SDX dans ce domaine... et 
j'insiste !

> Faut quand même pas oublier ce qu'est eXist : un SGBD XML, pas un outil
> de recherche. Donc je ne vois pas pourquoi ils s'inspiraient de ce
> mécanisme de pipeline.

A l'usage, ça aurait un intérêt : on a deux approches d'indexation sous 
eXist : inclusion ou exclusion de noeuds. Avec des documents un tant 
soit peu complexes, on arrive vite à des dizaines d'expressions (XPath, 
naturellement) de restriction de l'indexation si on veut un tant soit 
peu d'optimisation dans les fonctionnalités et la performance. Un 
pipeline aurait été très utile, et élégant, IMHO.

Sur ce point, j'ai fait quelques requêtes "de la mort" sur le serveur 
d'eXist : même s'il rame, il répond le bougre !

> Je ne vois pas en quoi la seconde syntaxe est plus claire,

A vrai dire... moi non plus :-)

Ceci dit, si on peut faire passer "en douceur" (hum !) des gens du monde 
 des requêtes "en langage naturel" ou du monde SQL à des 
implémentations XPath (ou XQuery), le jeu en vaut peut-être la chandelle.

Note humoristique : SQL (Structured Query Language) est-il si structuré 
que ça ? :-)

> Mais il ne
> fait pas oublier les "experts" et les recherche préenregistrées, dans
> les deux cas la syntaxe Xpath ne pose aucune problème.

J'en suis arrivé au même constat que toi... mais il faudrait voir à 
l'usage. J'ai sous la main une population qui a potentiellement de gros 
besoins de recherche sur la structure : mon problème est de savoir si 
les assistants que je pourrais leur fournir dans une appli SDX bien 
léchée ne vont pas les barber à la longue...

Exemple pratique : je me fais généralement une xsp "SimpleQuery" pour 
tester mes applis quand bien même mes formulaires "utilisateurs" sont, 
eux, très dirigistes.

> > Comment concilier la génération des résultats qui est différente sous 
> > Xpath (qui renvoie un choix de noeuds) et sous SDX qui renvoie un jeu 
> > déterministe d'éléments (champs "brief") ?
>
> En fait, je pense que c'est assez semblable, car un moteur Xpath renvoit
> donc un ensemble de nœuds qui dépend de la requête, SDX renvoit un
> ensemble de nœuds sdx:result. Ca me semble très conciliable, non?

Mmmh... je ne sais pas. Ici, je pense que l'avantage n'est pas forcément 
dans le camp SDX. J'apprécierais par exemple d'avoir de la structure 
dans mes résultats. De plus, j'aimerais bien avoir des champs "brief" 
dynamiques sans avoir à disposer de N jeux d'index. Accesoirement, la 
gestion de ces champs brief par Lucene semble inutilement complexe, mais 
ça, c'est de la cuisine interne.

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