> Concernant la linéarité des pipes Cocoon, les récentes expériences que
> j'ai pu faire pour XMLfr me conduisent à penser que l'utilisation du
> protocole "cocoon:" est un contournement extrêmement efficace pour gérer
> des entrées multiples.
>
> Par contre, je vois moins comment gérer les cas où on pourrait avoir
> besoin de sorties multiples.
Dès lors qu'on accepte qu'une sortie soit une URI appelable, je ne vois
pas la difficulté ou alors je manque le problème. Une sortie de pipe me
donne un état, que d'autres pipes peuvent utiliser en entrée. Soit cet
état à un intérêt à être publié (ex, un docbook après xinclude) et il
faut s'y efforcer, soit il peut toujours ne pas être exposé (<pipeline
@internal-only="true"/>). Ensuite avec un générateur en @src="cocoon:"
je peut démarrer autant de fois que je veux sur cette sortie (ex
docbook, pour >html, ou >fo>pdf). Cela ne suffit pas ? Je suis trop
engagé pour être objectif mais cela rends mon sitemap comme une
collection de segments, les aiguillages se faisant en entrée et en sortie.
En contexte ligne de commande, cela revient à laisser une trace fichier
d'un état (conservable ou supprimable), sur laquelle d'autres peuvent
repartir.
> * Le langage de pipeline Cocoon s'interdit d'accéder au contenu de
> ce qui passe dans le pipe (il agit comme un facteur qui ne
> regarde pas ce qui est contenu dans les enveloppes qu'il
> achemine) alors que XPL est intrusif et donne accès (par XPath)
> au contenu des documents qui passent dans le pipe.
Si on veut intercepter une étape d'un tuyau, est-ce qu'on ne quitte pas
l'idée de tuyau ? Est-ce que cela ne signifie pas qu'il faut arrêter un
tuyau plus tôt et d'en recommencer un autre ailleurs ?
--Frédéric
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "dev@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie au developpement du site XMLfr.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a dev-request@xmlfr.org
(mailto:dev-request@xmlfr.org?Subject=unsubscribe)
Received on Sat Sep 25 23:01:18 2004
