Re: [sdx-users] qid multi-session

[Frédéric Glorieux]

> Qu'entendez-vous par "production"? Production de documents xml?
> Mon autre message sur l'édition de documents xml peut le laisser
> penser (mais en fait comme vous dites ce serait plutôt pour des
> modifications très ponctuelles), 


J'interprétais abusivement. J'imaginais une gestion des utilisateurs où 
chacun a son dossier de documents de travail. C'est certainement 
intéressant, mais cela concerne plutôt un "CMS".

> L'utilisateur anonyme n'a pas de dossier, ça ne me semble pas un
> problème: s'il veut un dossier il se crée.

Très bien, ce qui devient donc distinct du procédé actuel de cache de 
résultat sur la session (en sachant que la session est différente pour 
chaque fenêtre de navigateur).

Donc on peut attacher cela à la fiche de l'utilisateur ? Reste à savoir 
maintenant s'il importe de stocker
 - une requête
 - des résultats
 - des liens vers des documents

On peut utiliser la base utilisateur SDX par défaut, mais votre idée 
d'aller écrire dans un fichier XML est probablement meilleure (ce qui 
n'empêche pas d'indexer ce fichier ensuite dans votre base utilisateur 
personalisée).

> Justement, ne serait-il pas intéressant de disposer d'un endroit
> où les utilisateurs SDX pourraient échanger du code -- du code xsl
> en particulier (en plus de cette liste)?

> J'ai par exemple écrit deux petites fonctions xsl qui sont assez
> génériques, l'une pour afficher l'historique de la recherche,

?? Une analyse de <sdx:query/> ?


> l'autre pour highlighter avec une couleur différente par mot (à la
> Google) et je ne sais pas comment les "contribuer au projet" (les
> poster à la liste est un peu incongru?); d'autres sont certainement
> dans le même cas que moi (et même pour ce qui n'est pas générique,
> les idées de chacun sont toujours "inspirantes") -- sans compter que
> ça permet d'éviter de réinventer la roue tous les matins ;-)

J'avais essayé un moment de maintenir une très générique sdx2html.xsl 
(sort le xml sdx dans un html à peu près standard avec des classes CSS 
personalisables). Je ne sais pas si beaucoup ont aprécié s'y plongé. En 
effet, il vaudrait mieux procéder par "snippets" répondant rapidement à 
une question au moment où on se la pose.


> >         L'objet Results pourrait peut-être se résumer à une liste
> > d'identifiants de cette sorte idDoc-idBase-idApp-uriRMI. On peut aussi
> > considérer que pour votre application (et le client), ce n'est qu'une
> > liste d'URI.
>
> En fait les identifiants des documents devraient suffire (et c'est
> plus simple et plus sûr que de stocker littéralement l'uri?)

A vous de voir la pérennité de vos identifiants. Le seul champ d'unicité 
que SDX promet c'est la base, or une requête est autorisée entre 
plusieurs bases, plusieurs applications, et des applications distantes 
sont susceptibles de porter un identifiant d'application identique (même 
si elle ne le devrait pas).

C'est en ce sens que je me demande si dans l'esprit W3C, on n'a pas 
intérêt à concevoir ses applications de telle manière que l'URI ait 
réellement une valeur absolue. Exemple, réagir en sitemap à des URL du 
genre /app/base/docId.(xml|html|rdf...)

De cette manière, l'utilisateur a des URIs dans ses favoris, il peut 
citer ces URIs dans ses pages, et s'il on veut offrir un service 
serveur, on garde mémoire des URIs de documents consultés, voire, mais 
pour ma compréhension, il me faudrait un cas, des listes de résultats.

> Oui, je ne sais pas: l'intérêt du stockage sur le serveur c'est que
> l'utilisateur retrouve son dossier intact quelle que soit la machine
> avec laquelle il se connecte...

Quand on se souvient de son mot de passe, c'est en effet très agréable.