Re: RE : [sdx-users] Qu'est ce que SDX ?

[Pierrick Brihaye]

Salut,

Frédéric Glorieux a écrit:

> > 1) SDX permet de stocker/mettre à disposition des documents dans des
> > entrepôts (repositories)
>
> Ce qui n'est pas le plus intéressant

Mmmh... qu'en pensent les utilisateurs SDX ? Pour moi, c'est fondamental !

> il faudrait pouvoir coupler à un
> CVS ou à un véritable logiciel d'administration de contenus, mais ne
> rien surcoder de ce qui existe déjà.

Mmmmh... pas trop d'accord non plus :-) Moi j'aimerais bien avec une 
taglib avec des fonctions CVS : retour à la version un tel, 
branchement... Ou bien des fonctions de réplication, backup... pour des 
SDGB. Liste non exhaustive !

> L'attribut keep="true" dans un pipe d'indexation permet de conserver une
> part du travail. Une requête d'export (sans éléments sdx), permet de les
> retrouver enchaînés. Le résultat <sdx:field name="titre">... n'est qu'à
> moitié intéressant, n'est-il pas ?

On est d'accord. Mais ça peut aider pour, par exemple, le débogage.

> Cocoon sait parfois mettre ce genre de chose en cache (il faudrait qu'on
> sache mieux lui demander). Dans l'état, comment peut-on stocker par
> exemple un résultat de recherche ?

Le sujet est d'actualité : réponse, qui doit aller chercher un peu de 
lumière auprès des autres réponses de ce thread, dans un repository : 
"jeux de résultats", voilà une jolie 5ème vue !

> Pour des transformations statique,
> pourquoi pas ant, ou du cocoon en ligne de commande ?

Mmmh... cette sortie de SDX me gêne. L'apprentissage de SDX n'est déjà 
pas évident alors pourquoi imposer en plus celui de Ant et de Cocoon ? 
idéalement, j'aimerais bien :

<sdx:generateplubishingview iddoc="xxx" torepository="yyy">
  <sdx:pipeline src="myxsl.xsl">
</sdx:generateplubishingview>

Ceci dit, si tu peux expliquer plus, je verrais peut-être mieux où tu 
veux en venir...

> C'est une potentialité future très intéressante mais à bien réfléchir
> pour ne pas lier les documents à SDX. Comment garder trace de ces
> attachements pour un navigateur, ou d'autres systèmes ?

Euh... c'est de la logique applicative, non ? Au développeur de ce 
débrouiller avec...

> > Pour le point 1), une XML:DB sait faire ça très bien. SDX apporte tout
> > de même un plus : il sait stocker des documents non-XML.
>
> OK, ce n'est pas l'architecture SDX qui pose problème

Non :-)

> > la bonne requête, ce qui n'est pas forcément pratique en XPath. A vrai
> > dire, c'est même très coton !
>
> A moins de documents avec de bonnes consignes rédactionnelles, genre
> <book>
>         <title>...
>         <abstract>...
>         <section>
>                 <title>...
>                 <abstract>...

Même ! On ne peut infliger (copyright Chateaubriand) du XPath à un 
utilisateur...

> Ne reste plus qu'à se donner l'occasion d'un exemple.

v. mon intervention à la journée SDX. Ou un document plus complet mais 
encore très embryonnaire sur ce sujet : 
http://www.ajlsm.com/projets/sdapa/reflexions/sribzh/index.html. Tu 
connais ? ;-))

> Si ant ne convient pas, il existe peut-être quelque part une action
> cocoon qui peut convenir.

Explique-nous où tu veux en venir ? Beaucoup de lecteurs de cette liste 
auront sans doute au mal à suivre sur ces points, non ?

> > - SDX permet de stocker ces vues sur différentes architectures. Plus
> > il y en aura de disponibles, mieux cela sera. Mais ça, on le savait
> > déjà...
>
> Je préfère confier ce boulot à cocoon, ils sont plus nombreux.

Pourquoi pas ? Mais réussiras-tu à faire passer le concept d'entrepôt 
tel qu'il existe dans SDX dans le monde Cocoon ? Pas gagné... Je me suis 
fait rembarrer sur une demande de structures de contrôle en XSP avec des 
arguments pour le moins légers. J'en suis vexé et très déçu !

> Mais ant c'est très bien !

V. ci-dessus :-)

> En fait je ne vois rien là d'impossible

Moi non plus : c'est bien pour ça que je les propose :-)

> mais j'ai peur que les missions
> de SDX sont ici étendues au-delà de ce que l'on sait bien faire

Et pourquoi donc ? Dans mes popositions, on va juste un peu plus loin 
que ce qui existe avec les repositories. Ensuite, on aura besoin de 
queryparsers "multilingues" et des bonnes actions SDX. Tout ça, on sait 
faire, non ?

> sauf à
> mentir comme n'importe quel autre .com, et dire que l'on fait tout seul
> ce que cocoon ou ant sait faire à notre place.

Mmmh... l'intérêt majeur est de proposer ça dans une taglib et d'avoir 
des fichiers de configuration "humains". Cocoon, Ant ou machin, c'est 
très bien, mais on doit d'abord se farcir 2.000 pages de doc.... quand 
elle existe :-)

> Pour ma part, j'aurais même tendance à vouloir encore plus restreindre
> les missions de SDX

Tu seras brulé en place publique par le comité scientifique de SDX :-)

> avec en fait cette ambition, le mettre chez Apache
> en sous-projet cocoon (mais alors, oublié saxon, il faudra supporter
> xalan).

Oui, mais autant arriver avec du conret et une approche conceptuelle en 
béton.

> On pourrait voir aussi ce qu'il peut apporter à Ant (pour ses
> aspects statiques), mais là à sec, je cale. 

Bien moins que moi :-)

A+

--
Pierrick Brihaye, informaticien
Service régional de l'Inventaire
DRAC Bretagne
mailto:address@hidden