Journal Nouvelle version de 'expp', le préprocesseur XML du projet Epeios.

Posté par (page perso) . Licence CC by-sa
Tags : aucun
6
7
mai
2013

'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 . É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 (page perso) . Évalué à 2.

      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.

      En effet, je vais modifier la page d’accueil en conséquence.

      Je n'ai par contre pas vu de documentation exhaustive.

      Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?

      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 ?

      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.

      Freelance en ingénierie informatique.

      • [^] # Re: Doc

        Posté par . Évalué à 3.

        Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?

        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.

        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.

        Je comprends, dans d'autres cas ça peut être considéré comme une contrainte. C'est à prendre en compte.

        d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux

        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 (page perso) . Évalué à 1.

          Qu'entends-tu exactement par exhaustive, ou, plus précisément, que manque-t-il ?

          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.

          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…

          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.

          Je comprends, dans d'autres cas ça peut être considéré comme une contrainte. C'est à prendre en compte.

          d'autant que je ne sois pas convaincu qu'il soit vraiment pertinent de comparer les deux

          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 ? :) ).

          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.

          J'en demande des trucs, hein ?

          Ben si j'avais voulu qu'on ne m'en demande pas, je n'aurais pas rédigé ce journal…. :-)

          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.

          Merci à toi de t'y intéresser :-) !

          Freelance en ingénierie informatique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.