RE : [sdx-users] sdxall:1 et hilite

[Nader Boutros]

Bonjour,
Je reviens aux nouvelles, y-a-il maintenant un moyen d'éviter les hilite de
"1" dans l'affichage des documents? Je n'ai pas trouvé de solution simple, à
part bricoler la XSL pour ne pas prendre en compte les hilite de valeur="1".
Ce qui n'est pas pertinent pour une recherche plein texte qui contient le
chiffre 1.

A bientôt,
Nader Boutros

> -----Message d'origine-----
> De : address@hidden 
> [mailto:address@hidden De la 
> part de Pierrick Brihaye
> Envoyé : lundi 23 juin 2003 16:51
> À : address@hidden
> Objet : Re: [sdx-users] sdxall:1 et hilite
> 
> 
> Bonjour,
> 
> Marjorie Burghart a écrit:
> 
> > Une idée pour éviter ça ?
> 
> A vrai dire, je ne vois pas l'intérêt de surligner quand le champ de 
> recherche est une "métadonnée SDX" (comme sdxdocid, 
> sdxall...) car ces 
> métadonnées ne proviennent pas a priori du document. Peut-être 
> faudrait-il moduler l'utilisation systématique de "true" dans 
> l'attribut 
> highlite ?
> 
> Quoi qu'il en soit, la problématique est diablement complexe car :
> 
> 1) Lucene ne nous offre pas d'API simples pour retrouver 
> simplement les 
> termes utilisés par une Query. La version livrée par SDX est un patch 
> (apparemment incompatible avec la version actuelle de Lucene 
> : 1.3RC1).
> 
> 2) Il est par définition impossible de faire un mapping entre un 
> document d'origine car XSL ne conserve que rarement la 
> structure (quel 
> en serait l'intérêt ?). SDX utilise la flux SAX du document et, 
> lorsqu'il rencontre une valeur de terme issue de la query, il la 
> surligne. On surligne ainsi tous les 1 si la query est 
> sdxall:1... pour 
> le meilleur et pour le pire.
> 
> Note : distinguer "terme" = champ + valeur de "valeur de terme". SDX 
> surligne des *valeurs*.
> 
> Les solutions sont complexes mais relativement simples à énoncer :
> 
> 1) il faudrait que Lucene soit capable de restituer facilement des 
> listes de termes. En gros, il y a 2 écoles :
> 
> a) on va associer la liste de termes à la requête. Rapide (car une 
> requête bâtit naturellement une liste de termes à rechercher)  mais 
> gourmand en mémoire : un terme reste en mémoire même si on 
> n'en a plus 
> besoin par la suite.
> b) on va associer la liste de termes au résultat. On n'a que 
> les termes 
> pertinents mais leur recherche est longue.
> 
> Il y a eu de gros débats sur la liste lucene-dev au mois de mars 
> là-dessus mais rien de concret n'a abouti :-(
> 
> 2) quelle que soit la façon de retrouver les termes, en ce 
> qui concerne 
> le surlignement du document, il faudrait passer par une 
> *retransformation* du document et mapper les termes trouvés sur les 
> noeuds du document d'origine, probablement grâce à XPointer.
> 
> C'est lourd mais c'est le prix à payer pour un surlignage 
> "pertinent". 
> Ca pose également le problème de ce que fait réellement le pipeline 
> d'indexation. D'aucuns s'en servent pour faire autre chose que de 
> l'indexation. Relancer ce pipeline tel quel pourrait donc avoir des 
> circonstances impévues...
> 
> Pour terminer : existe-t-il des processeurs XSLT capables de 
> générer un 
> tel mapping entre un document et sa transformation ?
> 
> A bientôt,
> 
> -- 
> Pierrick Brihaye, informaticien
> Service régional de l'Inventaire
> DRAC Bretagne
> mailto:address@hidden
> 
> 
> 
> _______________________________________________
> sdx-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/sdx-users
> 
>