Discussion :

[epeios]

Voilà quelques années que j'utilise intensivement le format XML pour divers usages. J'ai rapidement développé un outil qui devait me faciliter l'écriture de fichiers dans ce format. Ayant besoin de l'améliorer, j'ai recherché s'il n'existait pas une alternative qui le remplacerait avantageusement. A ma grande surprise, aujourd'hui, comme à l'époque à laquelle j'ai commencé à développer cet outil, une telle alternative n'existe pas.

L'outil en question est une sorte de préprocesseur qui permet, grâce à des directives appartenant à un 'namespace' dédié, d'inclure dans un fichier XML plusieurs autres fichiers XML, de définir et d'utiliser des macros, de définir des variables et d'en tester la valeur, etc., tout cela en incluant ces directives directement dans le fichier XML source (pour plus de détails, voir http://zeusw.org/intl/expp).

Cet outil s'est révèlé extrêmement utile et il me serait très difficile de m'en passer, en particulier pour l'écriture de fichiers de configurations. En tant que développeur, notamment, il m'est souvent nécessaire de mettre en œuvre de nombreuses variantes d'une même configuration de base. Plutôt que d'avoir un fichier XML par variante, grâce à cet outil, j'ai un fichier XML qui regroupe tous les paramètres communs à toutes les variantes, fichier qui est ensuite inclus par des fichiers XML qui contiennent juste les paramètres propres à chaque variante.

Les autres personnes qui utilisent le format XML, comment procèdent-elles pour pouvoir se passer d'un tel préprocesseur ? Je sais que l'on peut parvenir au même résultat avec XSLT (bien que pas vraiment conçu pour un tel usage), ce qui nécessite cependant de recourir à un fichier à part contenant les directives XSL, alors qu'une solution permettant d'inclure les directives directement dans le fichier XML source me semble bien plus pratique ...

[Morbo]

Hello,
C'est en effet un besoin qui émerge assez vite quand on se met à utiliser XML. Pour ma part, j'ai commencé par utiliser cocoon (un portail web) qui permet de définir des chaines de transformations modulaires en fonction de requêtes HTTP.

Plus généralement, la norme XProc répond à ce besoin :
http://www.developpez.net/forums/d92...mandation-w3c/
Avec Calumet, il y a même une interface graphique assez sympa pour modéliser.

J'essaie de m'y mettre, non sans mal, avec eXist notamment et la contrainte de vouloir gérer du XSLT-2.0.

[thelvin]

En ce qui me concerne, j'ai pas tellement le problème. De temps en temps j'ai besoin d'un mécanisme similaire aux macros, et d'éclater mon information en plusieurs fichiers. Mais les formats et outils consommateurs du XML adressent ce besoin de façon simple.

Quant aux formats que je définis moi-même, rien n'a jamais justifié de faire un système similaire aux macros, et je prévois presque toujours de les rendre éclatables en plusieurs fichiers pour séparer les responsabilités et garder les tailles raisonnables.

'Faudrait que je tombe sur le problème un jour, pour mieux le comprendre.

[alain.couthures]

Bien avant que les premières implémentations de XProc n'apparaissent, j'ai développé un moteur comparable (http://sourceforge.net/projects/txs) d'abord pour .Net puis pour PHP.

Basé sur XSLT 1.0 et sur l'API DOM, il me permet de définir des langages XML spécifiques comme celui de expp. Par exemple, j'ai, grâce à lui, construit tout un environnement d'assemblage de fichiers source XSLT, Javascript et CSS pour mon implémentation XForms.

Décidément, j'apprécie de plus en plus cette non distinction programme/donnée si naturelle en XML...

-Alain

[epeios]

XProc est en effet intéressant, mais ne correspond pas à mes besoins, rien que par le fait que les instructions définies pas cette normes doivent être placées dans un fichier dédié.

Quant aux autres mécanismes évoqués dans ce fil de discussion, à supposer qu'ils répondent à mes attentes, leur mise en œuvre me semble trop contraignante pour l'usage que j'en aurais.

A titre d'exemple, prenons le fichier de configuration d'un moteur de base de données auquel on doit naturellement préciser où se situe physiquement la base. Dans mon cas de figure, toutes les bases de données se situent dans le même répertoire. Comme je dois fréquemment changer de base de données, le fichier de configuration ressemblerait, sans préprocesseur, à ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
<Configuration>
    ...
    <!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
    <DBDirectory>/home/user/DBs/Food</DBDirectory>
    <!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
    <!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
    <!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
    ...
</Configuration>

Pour sélectionner une base de données, il faut ainsi décommenter la ligne correspondante et commenter toutes les autres.

Avec le préprocesseur, le fichier de configuration ressemble à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
<Configuration xmlns:xpp="http://zeusw.org/epeios/xpp">
    <xpp:define name="DBName">
        <xpp:bloc>Food</xpp:bloc>
    </xpp:define>
    <xpp:set name="OS" value="Linux"/>
    <!--xpp:set name="OS" value="Windows"/-->
    <xpp:define name="LinuxDBRootDir">
        <xpp:bloc>/home/user/DBs</xpp:bloc>
    </xpp:define>
    <xpp:define name="WindowsDBRootDir">
        <xpp:bloc>D:/DBs</xpp:bloc>
    </xpp:define>
    <xpp:ifeq select="OS" value="Windows">
        <xpp:define name="DBRootDir">
            <xpp:expand select="WindowsDBRootDir"/>
        </xpp:define>
    </xpp:ifeq>
    <xpp:ifeq select="OS" value="Linux">
        <xpp:define name="DBRootDir">
            <xpp:expand select="LinuxDBRootDir"/>
        </xpp:define>
    </xpp:ifeq>
    ...
    <DBDirectory>
        <xpp:expand select="DBRootDir"/>
        <xpp:bloc>/</xpp:bloc>
        <xpp:expand select="DBName"/>
    </DBDirectory>
    ...
</Configuration>

Pour changer de base de donnée, il me suffit de mettre son nom comme définition de la macro "DBName". En outre, ce moteur de base de données tournant indifféremment sous Windows et sous Linux, ce fichier de configuration s'adapte facilement à l'une ou l'autre plateforme grâce à la variable "OS".

Bref, rien de bien sophistiqué, mais ô combien pratique, et cela m'étonne qu'il n'y ai pas ne fût-ce qu'une ébauche de norme définissant des mécanismes similaires ...

[Morbo]

Ben, tu pourrais formaliser la même chose assez facilement en XQuery mais ça a l'inconvénient de ne plus être du XML.

Et avec XProc tu peux avoir tes documents sources "inline" et donc dans un même document XML définir donnée et transformation à appliquer.

Avec XSL-T (et sans doute plus facilement en XSL-T 2.0), on devrait pouvoir même définir dans une feuille de style générique les traitements que font ton programme actuel pour traiter ta grammaire "xpp".

Je ne saisis pas bien ce que tu entends par "instructions définies pas cette normes doivent être placées dans un fichier dédié".

[thelvin]

Oui, bof. Chacun son truc, je suppose. Solutions similaires tout aussi pratiques sans création de processus de ce genre :

- Avoir un fichier final pour chaque configuration possible, et copier celui qu'on veut vers le nom du fichier qui sera effectivement lu par l'application.
- En général les configs et données XML sont éclatables en plusieurs fichiers, soit qui se référencent les uns les autres, soit qu'on choisit de référencer dans la ligne de commande ou autre option. Éclater les différentes confs en différents fichiers et référencer ceux qu'on veut et pas les autres.

L'exemple est un peu trop trivial pour me convaincre... Sans compter que le faire à coup de XSLT évite d'inventer son propre format et n'est pas plus contraignant. Écrire une nouvelle XSLT*à chaque fois ne me semble pas beaucoup plus compliqué qu'écrire de nouveaux xpp à chaque fois.

[wiztricks]

Salut,

Je ne fais que passer et je n'ai qu'un bout de doigt de pied dans XML.
Lorsque, je vois cela:

<Configuration>
...
<!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
<DBDirectory>/home/user/DBs/Food</DBDirectory>
<!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
...
</Configuration>

Je pense 'template' et je l'écrirai plutôt sous la forme:

<Configuration>
...
<DBDirectory>${ x.get_DBdirectory() }</DBDirectory>
...
</Configuration>

Qu'en pensez vous?
- W

[thelvin]

Ben ouais, quelque chose de ce genre, moi aussi. En général c'est disponible, et puis XSLT le permet.

[epeios]

Ben, tu pourrais formaliser la même chose assez facilement en XQuery mais ça a l'inconvénient de ne plus être du XML.

En effet, quitte à manipuler du XML, autant que ce soit avec du XML.

Et avec XProc tu peux avoir tes documents sources "inline" et donc dans un même document XML définir donnée et transformation à appliquer.

Intéressant. Néanmoins, je suppose, à tort peut-être, que ça doit être beaucoup plus intrusif qu'avec 'XPP', c'est-à-dire que les transformations à appliquer au document XML à manipuler doivent être beaucoup plus lourdes.

Avec XSL-T (et sans doute plus facilement en XSL-T 2.0), on devrait pouvoir même définir dans une feuille de style générique les traitements que font ton programme actuel pour traiter ta grammaire "xpp".

Je connais assez bien XSL, et je serais curieux de voir ce que ça donnerais; peut-être qu'un jour j'essayerais de développer une telle feuille de style. Néanmoins, ce n'est qu'une manière parmi d'autres d'implémenter ce préprocesseur, sa grammaire restant à définir.

Je ne saisis pas bien ce que tu entends par "instructions définies pas cette normes doivent être placées dans un fichier dédié".

Cela signifie que, à l'instar de XSLT, on a, d'une part, un ou plusieurs fichiers contenant les données à manipuler, et, d'autre part, un ou plusieurs fichiers détaillant les manipulations à effectuer (l'équivalent des feuilles de styles en XSL). Mais cette assertion est apparemment caduque vu ta remarque ci-dessus concernant les documents 'inline'.

Oui, bof. Chacun son truc, je suppose.

Voilà sans doute la clef de l'intérêt de 'XPP'. Sa mise en œuvre paraîtra sans doute beaucoup plus naturelle et intuitive à un développeur C/C++, familiarisé avec la notion de préprocesseur de par sa mise en œuvre systématique dans ses sources, qu'à un développeur JAVA (par exemple), qui utilise un langage qui ne fait pas usage d'un préprocesseur (du moins était-ce le cas la dernière fois que j'ai développé en JAVA ...).

Solutions similaires tout aussi pratiques sans création de processus de ce genre :

- Avoir un fichier final pour chaque configuration possible, et copier celui qu'on veut vers le nom du fichier qui sera effectivement lu par l'application.

La macro donnée en exemple n'est qu'une parmi plusieurs autres. S'il fallait un fichier pour chaque combinaison possible de valeurs de ces macros, il en faudrait plusieurs dizaines au bas mots, ce qui est loin d'être pratique !

- En général les configs et données XML sont éclatables en plusieurs fichiers, soit qui se référencent les uns les autres, soit qu'on choisit de référencer dans la ligne de commande ou autre option. Éclater les différentes confs en différents fichiers et référencer ceux qu'on veut et pas les autres.

A charge pour chaque logiciel d'implémenter un mécanisme permettant ce référencement de fichiers, ce qui fait qu'on risque d'avoir autant de mécanismes que de logiciels ayant besoin d'un tel mécanisme. Si c'est tellement courant, autant normaliser ce mécanisme et proposer des outils standards pour le mettre en œuvre (ce qui est le cas à ma modeste échelle, chacune des mes applications ayant besoin d'un fichier de configuration, ou, plus largement, manipulant des fichiers XML, profitant automatiquement du préprocesseur 'XPP').

L'exemple est un peu trop trivial pour me convaincre... Sans compter que le faire à coup de XSLT évite d'inventer son propre format et n'est pas plus contraignant. Écrire une nouvelle XSLT*à chaque fois ne me semble pas beaucoup plus compliqué qu'écrire de nouveaux xpp à chaque fois.

Un exemple se doit d'être un peu trivial pour être clair, non ? En tout cas, pour être trivial, l'exemple n'en est pas moins tiré d'un de mes fichiers de configurations que j'utilise quotidiennement. Sinon, j'ai également un fichier de configuration de plus de 5000 lignes avec plus de 1000 directive 'XPP'; je crois qu'à cette échelle, on ne peut plus parler de trivialité !

Au risque de me répéter, XSLT (que je connais bien, et que j'ai donc écarté en connaissance de cause) est plus contraignant dans la mesure ou l'on est obligé d'avoir au moins deux fichiers, l'un contenant les données à manipuler, et l'autre la manipulation à réaliser

Salut,

Je ne fais que passer et je n'ai qu'un bout de doigt de pied dans XML.
Lorsque, je vois cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
 <Configuration>
...
<!--DBDirectory>/home/user/DBs/Test</DBDirectory-->
<DBDirectory>/home/user/DBs/Food</DBDirectory>
<!--DBDirectory>/home/user/DBs/Wine</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Cactus</DBDirectory-->
<!--DBDirectory>/home/user/DBs/Flower</DBDirectory-->
...
</Configuration>

Je pense 'template' et je l'écrirai plutôt sous la forme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
 <Configuration>
...
<DBDirectory>${ x.get_DBdirectory() }</DBDirectory>
...
</Configuration>

Qu'en pensez vous?
- W

Et comment définit-on les différentes valeurs que peut contenir la balise 'DBDirectory' ? Et de manière plus générale, de quel 'langage' s'agit-il ?

Ben ouais, quelque chose de ce genre, moi aussi. En général c'est disponible, et puis XSLT le permet.

cf plus haut concernant XSLT.