Re: [sdx-users] q comme query

[Pierrick Brihaye]

Re,

Frédéric Glorieux a écrit:

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

Eh non justement... c'était un piège :-))

Qui te dit que mon <titre>, mon <résumé>, etc... viennent du document ? 
Pourquoi ne viendraient-ils pas du super analyseur-traducteur-rapporteur 
d'Echelon quand il sera en GPL ? Ou d'un document XML (ou XML-like) 
rendu disponible par *la logique applicative* ?

En fait, le problème est bien là : on devrait avoir la possibilité de 
greffer *ce que l'on veut* dans les results comme on a la possibilité de 
le faire dans l'indexation :

Soit des fragments d'indexation (comme c'est actuellement le cas car on 
y met les champs brief de l'indexation)
Soit des fragments de document
Soit... autre chose.
Soit... un peu de tout ça en même temps.

Peu importe ce que c'est à vrai dire : l'important est que ça puisse 
être généré en SAX. Dans l'état actuel des choses, on a l'équivalent 
hard-codé d'un <xsl:copy> du document d'indexation... je souhaiterais 
qu'on puisse avoir tout le panel des fonctions XSL.

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

Oui. On les a évoquées...

>         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.

Ben, tu as le même problème avec SDX, non ?

>         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.

On est d'accord. Dans eXist, l'indexation concerne la *structure* (si tu 
connais le nom du noeud et sa filiation, tu l'obtiens *très* vite). 
eXist propose également une indexation pour les noeuds texte mais là, je 
préfère SDX qui est nettement plus puissant :-) (car plus abstrait).

>         Je vois bien l'intérêt de brancher un DB:XML avec SDX, en faire
> le standard livré avec, comme Lucene.

Ca ne doit être qu'une option ! Rappelons, de plus que SDX sait gérer 
des documents non XML... ce qui n'est pas la priorité des XML:DB.

> Il faut par contre
> s'assurer que le déploiement reste aussi simple (de ce que j'ai
> lu, Exist le prétend).

Ben eXist, c'est comme SDX. Tu copies le war et ça marche :-) Dans SDX, 
il suffirait de copier le jar... et de faire la mapping avec 
application.conf. A la rigueur, de jouer un peu sur la sitemap... qui, 
en standard, inclut d'ailleurs le pseudo-protocole xml:db.

>         Par défaut, on utiliserait le DB:XML comme entrepôt, on
> garderait Lucene pour le plein texte,

Bonus : eXist utilise certains composants Lucene... et je pense que le 
reste va suivre.

Ceci dit, je tiens absolument à garder les 2 : eXist est très bon pour 
indexer la *structure physique* du document. Lucene est très bon pour en 
indexer une *vue*, i.e. une structure logique... parmi d'autres. Je veux 
donc fromage *et* dessert.

> 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.

Des arbres de concepts par exemple ;-)) ?

> On peut changer la recherche avancée sans devoir
> changer application.xconf et son indexation.xsl.

Grmf : *ses* indexation.xsl :-)

Ce clarifie-ce ?

A bientôt,

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