'expp' est un préprocesseur XML qui transforme un fichier XML en fonction des directives qu'il contient, directives permettant l'inclusion de fichiers, la gestion de macros, l'inclusion conditionnelle d'un arbre XML… Le but de 'expp' est d'être à XML ce que 'cpp' est au C/C++.
Dans sa dernière version, sortie hier, 'expp' gère les fichiers UTF-8 (avec ou sans BOM), et est disponible en 32 bits ('IA-32') et 64 bits ('x86-64'), que ce soit pour GNU/Linux (et probablement d'autres UNIXes), Windows et Mac OS.
Il est disponible sous forme d'exécutable en ligne de commande et de composant Java. Il peut facilement être intégré dans un programme C++, vu qu'il n'utilise que des bibliothèques systèmes et C standards (on peut également l’utiliser dans du code à destination d'Android, que ce dernier tourne sur une plateforme x86 ou ARM).
'expp' est publié sous GNU GPL (d'autres licences sont envisageables ; me contacter pour en savoir plus).
La page dédiée : http://zeusw.org/intl/expp/
Les deux précédents journaux sur le même sujet :
* http://linuxfr.org/users/epeios/journaux/sortie-de-la-premi%C3%A8re-version-de-expp-le-pr%C3%A9processeur-xml-du-p
* http://linuxfr.org/users/epeios/journaux/nouvelle-version-du-pr%C3%A9processeur-xml-expp
# Doc
Posté par barmic . Évalué à 7.
Tu devrais mettre plus en avant la page : http://zeusw.org/intl/expp/directives
Ce que les gens viennent voir c'est ce que va leur apporter expp, l'installer c'est après avoir découvert combien c'est bien.
Je n'ai par contre pas vu de documentation exhaustive.
Comment se place expp par rapport à XSLT qui me semble a les même objectifs ? Il est plus simple ? Plus rapide ? Il permet des choses en plus ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Doc
Posté par Claude SIMON (site web personnel) . Évalué à 2.
En effet, je vais modifier la page d’accueil en conséquence.
Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?
De l'usage que je fais d'XSLT, la finalité n’est pas du tout la même. Un document issu d'une transformation XSLT est généralement radicalement différent du document source, genre une page XHTML destinée a être affichée dans un navigateur Web avec mise en forme des données stockés dans le fichier XML auquel est appliquée la transformation.
Concernant 'expp', je m'en sers, par exemple, pour générer, pour mes applications, à partir d'un même jeu de fichiers, des fichiers de configurations différents, dont seuls quelques détails changent par rapport au contenu des fichiers d'origine. Pour cet usage, pouvoir placer directement les directives de transformation dans les fichiers sources me semble plus pratique que de maintenir un fichier dédié à part, comme c'est le cas avec XSLT.
Au final, 'expp' plus simple que XSLT ? Pour l'usage que j'en fais, oui. Plus rapide ? Étant plus simple, il y a des chances, mais je n'ai pas testé (d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux). Permet-il plus de chose ? Non, mais ce que permet 'expp' est mis en œuvre de manière différente.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Doc
Posté par barmic . Évalué à 3.
Je pense notamment a une documentation d'API. Connaître toutes les directives pour chaque langage la partie xml et des documentations d'API pour leurs utilisation en C/C++ et Java.
Je comprends, dans d'autres cas ça peut être considéré comme une contrainte. C'est à prendre en compte.
C'est pour ça que je te demandais le positionnement de l'un par rapport à l'autre. Pour quelqu'un qui découvre, quand on parle de transformation xml on a le réflexe de penser à XSL (du coup c'est peut être un point à ajouter dans ta FAQ ? :) ).
J'en demande des trucs, hein ?
En tout cas je te remercie ça m'a l'aire vraiment intéressant. Je testerais quand j'aurais l'occasion de me confronter à ce genre de choses.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Doc
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Ah oui, la doc. sur l'API… Le problème, c'est qu'une documentation là-dessus n'aurait pas de sens sans documentation sur le framework sur lequel elle s'appuie, les deux étant imbriqués (p. ex., autant le parser XML que le préprocesseur proprement dit font partie intégrante du framework). Or, cette documentation est inexistante (même moi, utilisateur quotidien de ce framework, n'en ai pas). Et rédiger une documentation sur un framework qui existe depuis plus de dix ans, et qui n'a cessé d'évoluer depuis, représente un travail titanesque, d'autant plus que les concepts mis en œuvre sont un peu particuliers.
Je ne peux entreprendre un tel travail sans être sûr d'avoir un minimum de retour sur investissement sous une forme ou une autre. Oui, je sais, c'est le serpent qui se mord la queue ; personne ne s’intéressera au code tant qu'il n'y aura pas de doc., et je ne rédigerais pas de doc. tant que personne ne s’intéressera au code. Et, en tout honnêteté, la documentation je ne sais pas (ce qui a toujours grever mes notes de projet durant mes études d’informatique) et je n'aime pas faire (les deux étant probablement liés), ce qui n'aide pas…
C'est l'éternel problème. A force d'utiliser cet outil quotidiennement, les différences entre les deux approches me paraissent tellement évidentes que j'ai du mal à concevoir que ce ne soit pas le cas pour tout le monde. Ceci dit, je pensais que l'exemple dans la page des directives était suffisamment explicite pour mettre en évidence ces différences.
Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)
Merci à toi de t'y intéresser :-) !
Pour nous émanciper des géants du numérique : Zelbinium !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.