Re: [sdx-developers] SDX 2.0?

[Frédéric Glorieux]

| Voilà : l'objectif est, on pouvait s'en douter, de rendre SDX moins
| dépendant de Lucene :-) ou, plutôt, de rendre Lucene plus visible dans
SDX.
| Je prends l'exemple issu de docs/samples/sdx-document.xml.

Je mes souviens de la discussion et j'adhère, dans la mesure ou cela ne
complique pas trop la migration des XSL. Mais je crois qu'il ny a pas grand
chose qui s'appuie là dessus.

| <sdx:query engine="lucene" type="complex" luceneQuery="(+sdxall:1 +a*)"
| operator="or">
|
| ou :
| <sdx:query type="ComplexLuceneQuery" luceneQuery="(+sdxall:1 +a*)"
| operator="or">

Je proposerais

<sdx:query class="lucene..." name="complex" parameters="or"
string="(+sdxall:1 +a*)">
...
</query>

L'idée c'est que la chaîne string donne les résultats présentés dessous
(avec la classe précisée). Je ne pratique plus beaucoup SQL mais je crois me
souvenir qu'on peut bien lui demander ça aussi.

| Ce qui est sous-jacent, vous l'aurez compris, c'est que l'on devrait
| *également* pouvoir disposer de résultats qui ne sont pas issus d'une
| requête Lucene. Par ailleurs, il faudrait également pouvoir sortir
| luceneQuery du jeu d'attributs si l'on converse le très générique
| <sdx:query/>...
|
| Plus bas, on a :
|
| <sdx:result no="3" score="0.107960686" pctScore="83">
|
| Je préfèrerais :
| <sdx:result no="3">
|   <luceneScore>0.107960686</luceneScore>
|   <lucenePctScore>83</lucenePctScore>
|
| ou :
| <sdx:luceneResult no="3" score="0.107960686" pctScore="83">

Surtout, ne pas changer les noms d'éléments. Il me semble que score est une
info valable pour tout résultat. La question c'est de savoir quel contrat
imposer sur ce chiffre. Je proposerais de ne retenir que des pourcentages,
un relatif à la requête (résultat 1=100%), et en absolu pourquoi pas, mais
je ne sais pas trop si c'est utile. Pour des pertinences booléennes (SQL),
et bien ce sera 100%, pas de problème.


| En effet, ces notions de  pertinence sont très liées à Lucene.
| Ensuite, on aurait <sdx:luceneField /> en lieu et place de <sdx:field>.

Là je ne suis pas d'accord, cela dépend comment on implante d'autres
chercheurs. On peut très bien dire qu'un résultat est une ligne d'une table,
que les champs sélectionnés en sont les cases. Cela fait partie de la
définition même d'une base SDX.

| Corollaire, la notion de tri, telle qu'actuellement disponible est
également
| très dépendante de Lucene et est peut-être à intégrer dans
| <sdx:luceneQuery/>

Les méthodes peut-être, mais pas la logique. Il me semble bien que l'on
puisse superposer des clés de tris, en SQL, comme en sortie XSL d'un DB XML.

|
| Nonobstant l'aspect génération xsp, tout cela revient à demander également
à
| ce que Results.java remonte un peu dans, par exemple,
| fr.gouv.culture.sdx.search, mais pour ça, on peu attendre. On peut aussi
| prendre le parti de le tranforrmer en LuceneResults.java.

Tout le problème sera de définir les contrats Results ou Query.
J'aurais tendance à imposer ce qui est déjà utilisé dans la taglib, de même
que  le nécessaire pour remplir les toSax. Peut importe qu'une implantation
faible rendent des valeurs constantes, et pour des chercheurs plus fins, ils
sont autorisés à rajouter des attributs (voir des éléments).