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

[Pierrick Brihaye]

Bonjour,

Martin Sevigny a écrit:

> - en 2003, c'est malheureusement encore vrai

Les extensions XPath d'eXist sont tout de même intéressantes, non ?

> SDX 2 a été conçu de manière à accepter d'autres moteurs de recherche,
> et implanter eXist serait un bel ajout. Ca permettrait de combiner les
> deux approches.

Oui. Le gros intérêt d'avoir une implémentation Xpath serait de 
permettre d'interroger la *structure* en plus du contenu.

Cela pose tout de même des problèmes de fond :

Quelle structure interroger ? Celle des documents ? Ou celle des 
documents d'indexation ? Je serais tenté de répondre : les 2 mon 
capitaine :-)

Comment concilier l'indexation telle que la conçoit eXist (indexation = 
document) et l'indexation telle que la conçoit SDX (indexation = ce que 
l'on veut) ? A titre personnel, j'apprécie réellement l'approche SDX qui 
la confie à un pipeline. Si eXist pouvait s'en inspirer... :-)

Peut-on décemment envisager des requêtes utilisateur en XPath ? Si non, 
doit-on aller jusqu'à rendre XPath "human readable" ("writable" en fait) 
dans une syntaxe où //chapter[example = 'toto'] deviendrait par exemple 
"SELECT DESCENDANT chapter HAVING CHILD example WHERE CONTENT = 'toto'" 
ou, si possible, quelque chose de moins atroce ?

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

Comment gérer l'opposition fonctionnelle qu'il y a à l'heure actuelle 
dans SDX entre "entrepôts" et "bases de documents" ("jeu d'index", cf. 
ci-dessus) ? L'approche XML:DB postule une parfaite équivalence en les 
2... Ca présente des avantages mais aussi quelques inconvénients.

[liste non exhaustive sans aucun doute]

Bref, il y aura des choix à faire...

A+

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