Re: [sdx-users] q comme query

[Pierrick Brihaye]

Re,

>Tu veux qu'une interface Results fournissent un contrat minimal,
>genre
><sdx:results ...>
><sdx:query>
>selon l'engin de recherche
></sdx:query>
><sdx:result>
>selon l'en gin
></sdx:result>
>...
></sdx:results>

Ouaip :-)

Ca pose le problème de l'architecture : il devrait être assez facile de
passer du SAX dans un sdx:result. C'est plus délicat de le passer dans des
sdx:results... à cause du tri. Pas encore trop clair dans ma tête pour le
moment... sauf à générer un document temporaire sur une XMLDB
hyper-optimisée.

>Un DB:XML dans les jars, utilisable comme entrepôt XML (pas pour
>les images), utilisable aussi en requête (parce qu'il est
>entrepôt, ou qu'il a indexé, ici c'est tout même) ?

Oui... mais :

1) ce type d'entrepôt devrait être capable de *tout* gérer (sauf le binaire)
: documents, indexations, lookups, relations (v.
http://sdx.culture.fr/sdx/journeeSDX/pres/brihaye/brihaye.html ;-) Bref, si
on cable une XML:DB, autant pouvoir l'utiliser partout.
2) il faudrait mettre le focus sur le QueryParser : hors de question de
proposer des requêtes XPath à l'utilisateur lambda. Contributions bienvenues
!

>D'accord. C'est en ce sens que je dirais qu'une appli xml modèle
>c'est xml:db entrepôt, indexation lucene, et recherche lucene ou
>(mais pas de et) xml:db.

OK.

A+

p.b.