On Mon, 2004-09-27 at 00:43, Frédéric Glorieux wrote:
> > Mais a chaque langage sa specifite. Si on s'assied autour d'une table
> > pour definir un langage qui s'occupe de regler le flot de documents
> > XML de et vers des composants qui les consomment et les produisent, on
> > arrive rapidement a un ensemble de requirements qui couvrent les cas
> > les plus frequents. Pour moi, l'exemple ci-dessus est un cas trivial
> > qui doit etre gere. Si on dois recourir a XInclude ou Java (argh !)
> > pour l'implementer, c'est pour moi une lacune importante du langage de
> > pipeline.
>
> JAVA est probablement incontournable pour génération sur source non XML.
Disons plutôt qu'un langage de programmation classique est
incontournable, Java ou un autre...
Lorsque j'ai le choix, je préfère nettement travailler en Python pour
manipuler des documents XML et je suis également avec intérêt les
tentatives de considérer les fragments XML comme des types de données
natifs de JavaScript et C#...
Pour être honnête, j'utilise Java pour ce projet essentiellement parce
que je n'ai pas trouvé l'équivalent de Cocoon ou Presentation Server en
Python :-) ...
> Un cas d'il y a quelques semaines, j'ai des images avec métadonnées
> IPTC, il me faut un bout de JAVA pour générer un XML. Cas de xmlfr ici,
> générer des réultats depuis Lucene, il vaut mieux le faire en JAVA, ou
> alors ça prends un autre langage avec sa logique propre (là c'est une
> autre histoire,
> <http://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/reference/actions/recherche/requetes.html>,
> je suis coupable d'une bonne part du code derrière cette doc)
Je pense qu'il faut relativiser la notion de "tout XML" de Cocoon ou
Presentation Server : un pipeline ne peut être défini "tout XML" que
parce que les composants qu'il utilise ont déjà été implémentés en Java.
A partir du moment où j'écris un LucenTransformer (ou Processor), les
personnes qui utiliseront ce composant auront l'impression que faire du
"tout XML" en l'utilisant alors que moi j'ai eu l'impression de faire du
Java!
Presentation Server pousse simplement les choses un peu plus loin en
permettant d'inclure du XSLT et des expressions XPath dans le pipeline.
> XInclude est tellement minimaliste, et surtout portable, que je peux
> même imaginer transposer ma logique dans d'autres environnements (ex:
> sxpipe :o). Si la chose reste lisible et ne chantourne pas trop dans
> tous les sens, je préfère personnellement en rester là.
Minimaliste? Je ne dirais pas cela!
Le problème de XInclude est qu'il est à la fois minimaliste et
maximaliste.
Minimaliste dans ses fonctionnalités propres et maximaliste dans la
mesure où il s'appuie sur XPointer qui lui même peut s'appuyer sur
XPath.
Cela veut dire qu'un processeur XInclude (que l'on pourrait à priori
imaginer être quelque chose qui appartient au parsing) doit incorporer
un moteur XPath qui est traditionnellement implémenté à un autre niveau
(même si DOM Level 3 gomme également un peu la frontière).
Et les choses ne devraient pas s'améliorer avec XPath 2.0 qui s'appuiera
sur le PSVI W3C XML Schema et imposera donc plus ou moins aux
processeurs XInclude d'implémenter également W3C XML Schema.
Le problème de ces spécifications est que l'on est en train de
transformer une architecture logicielle en couches en un plat de
spaghetti où chaque module (parsing, transformations, schéma) appelle
les autres.
Eric
--
Tired of typing XML tags?
http://wikiml.org
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(ISO) RELAX NG ISBN:0-596-00421-4 http://oreilly.com/catalog/relax
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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 Mon Sep 27 08:24:13 2004
