sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [sdx-users] q comme query


From: Frédéric Glorieux
Subject: RE: [sdx-users] q comme query
Date: Wed, 12 Feb 2003 18:41:45 +0100

 > Eh non justement... c'était un piège :-))
 >
 > Qui te dit que mon <titre>, mon <résumé>, etc... viennent du
 > document ?
 > En fait, le problème est bien là : on devrait avoir la
 > possibilité de
 > greffer *ce que l'on veut* dans les results comme on a la
 > possibilité de
 > le faire dans l'indexation :

OK

 > Soit des fragments d'indexation (comme c'est actuellement le
 > cas car on
 > y met les champs brief de l'indexation)
 > Soit des fragments de document
 > Soit... autre chose.
 > Soit... un peu de tout ça en même temps.
 >
 > Peu importe ce que c'est à vrai dire : l'important est que ça
puisse
 > être généré en SAX. Dans l'état actuel des choses, on a
l'équivalent
 > hard-codé d'un <xsl:copy> du document d'indexation... je
 > souhaiterais
 > qu'on puisse avoir tout le panel des fonctions XSL.

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>

 > >    Je vois bien l'intérêt de brancher un DB:XML avec SDX, en
faire
 > > le standard livré avec, comme Lucene.
 >
 > Ca ne doit être qu'une option ! Rappelons, de plus que SDX
 > sait gérer
 > des documents non XML... ce qui n'est pas la priorité des
XML:DB.

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) ?

 > Ben eXist, c'est comme SDX. Tu copies le war et ça marche
 > :-) Dans SDX,
 > il suffirait de copier le jar... et de faire la mapping avec
 > application.conf. A la rigueur, de jouer un peu sur la
 > sitemap... qui,
 > en standard, inclut d'ailleurs le pseudo-protocole xml:db.

parfait.

 > Ceci dit, je tiens absolument à garder les 2 : eXist est
 > très bon pour
 > indexer la *structure physique* du document. Lucene est très
 > bon pour en
 > indexer une *vue*, i.e. une structure logique... parmi
 > d'autres. Je veux
 > donc fromage *et* dessert.

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.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]