[sdx-developers] RE : Representatiojn des resultats

[Martin Sevigny]

Bonjour,

> > Que l'on identifie que c'est du Lucene, très bonne idée. Je crois 
> > qu'un attribut "engine=Lucene" est idéal...
> 
> Mmmh. Ce n'est pas tant cet attribut qui me gêne, mais la 
> représentation 
> de la requête : une string n'est pas suffisante. a partir de 
> là, de deux 
> choses l'une :
> 
> 1) ou on garde le très générique <sdx:query> et on met la 
> représentation 
> de la query dans cet élément, potentiellement sous forme d'une 
> arborescence XML
> 2) ou on transforme cet élément en <sdx:luceneQuery> qui disposera de 
> son propre schéma...

Je ne comprends pas deux choses.

1) Ce qu'il y a dans l'attribut luceneQuery est (comme son nom
l'indique) quelque chose de propre à Lucene. C'est la requête qu'on peut
lui passer (parmi d'autres, notamment avec moins de parenthèses...!)
pour obtenir les résultats en question. Lucene connaît deux
représentations de requêtes : en String et en objets Java (interface
Query). Donc la sortir en String ne semble tout à fait pertinent, même
si j'avoue que je ne l'ai jamais utilisée dans une interface, seulement
pour déboguer... Pourquoi cette String dérange? Elle est bien sûr
associée à Lucene, mais si on retrouve cet attribut seulement lorsqu'il
y a un engine="Lucene", je ne vois pas le probème.

2) Il y a déjà une représentation XML de toutes les requêtes effectuées
par SDX ; c'est l'objet de l'élément sdx:query. Et cette représentation
est totalement hiérarchique. C'est le fait que ce soit des sdx:query
imbriqués qui cause problème? Moi je trouvais cela plutôt séduisant et
surtout facile à manipuler par la suite...

> > Dans une requête de type
> > Xpath ou Xquery, on retourne ce qu'on demande de retourner dans les 
> > structures XML interrogées, alors ça peut prendre une forme 
> > hiérarchique quelconque.
> 
> Oui ! Aussi bien la représentation de la requête que le 
> représentation 
> de ses résultats.

Une Xpath en arbre??? Je ne vois pas l'intérêt...

> C'est là où je coince : personnellement, je tiens à ce que 
> les résultats 
> restent encapsulés dans SDX ne serait-ce que que pour les 
> regrouper par 
> page et, surtout, à partir de requêtes sur des moteurs différents, de 
> garder la logique applicative de présentation des résultats.

Oui, dans la discussion d'il y a quelques mois, c'est cet argument qui
m'avait convaincu qu'il y avait tout de même une certaine forme de
généricité aux requêtes/résultats SDX/Lucene, pour moi c'est la
direction à prendre...

> 1) la query est un arbre XML, cf ci-dessus.
> 2) la response aussi, mais ça, on s'y attendait.
> 
> Ce que j'aimerais bien pour la response, c'est avoir un mécanisme où 
> <wfs:FeatureCollection> est remplacé par <sdx:results> et où 
> <gml:featureMember> est remplacé par <sdx:result>. Bien sûr, SDX 
> paginerait la response, pour autant qu'on le lui ait demandé, et 
> ajouterait ses propres éléments (navigation p.e.).

Bien sûr, c'est exactement l'objectif. Ce que je ne comprends pas, c'est
en quoi les structures XML sdx:results et sdx:query et sdx:sort, si on
leur ajoute des attributs engine="", empêchent d'y arriver? Je suis
conscient que l'organisation du code Java pourrait être revu pour en
arriver là, mais ça me gène moins, car c'est nettement moins "public"
que les structures XML renvoyées...

A bientôt,

Martin Sévigny