RE : RE : [sdx-users] Petit souci et grande question (ou l'inverse)

[Frédéric Glorieux]

> -----
> 3) J'ai vu sur
> http://xml.apache.org/cocoon/userdocs/concepts/xmlsearching.html qu'il
y
> avait un moteur Lucène intégré dans Cocoon qui permet d'interroger sur
> le contenu et aussi sur la structure du doc XML avec des requetes du
> type address@hidden:terme, est-ce que SDX l'utilise ?
> -----
> 
> Non. L'indexation Lucene de documents XML dans Cocoon essaie de
> conserver toutes les informations de structure et de contenu et remet
> cela à plat dans des champs. En SDX, nous avons une approche (et des
> objectifs) différente, nous préparons une base de documents avec des
> champs, et nous effectuons une indexation spécifique pour remplir ces
> champs.

Je rajoute :

        La solution cocoon-lucene intégrée peut convenir à du XML de
structure simple (plus proches de la donnée, avec peu de contenus
mixtes). Elle devient très improductive s'il on a par exemple, des
paragraphes avec du gras. Faut-il vraiment stocker tous les éléments
"<bold/>" ? Les listes cocoon et lucene ont plus d'un mail
d'utilisateurs face à des dépassements de capacités de Lucene par effet
de récursivité (avec du docbook par exemple).

        SDX1 a proposé l'utilisation de lucene avec cocoon avant
(probablement pas d'imitation). Le parti choisi était moins évident pour
l'utilisateur (obligation d'écrire une xsl d'indexation), mais à 
l'usage, il s'avère plus performant, plus intelligent. On peut ainsi
créer des champs faciles à chercher pour toutes les dates, adresses, ou
références bibliographiques de longs documents. Ce moment de réflexion
face à une collection documentaire est pertinent pour les cas que SDX
visait au départ : du XML documentaire.

        A vous de voir ce qui vous convient.