libroxml : une bibliothèque XML qui ne fait pas le poids, mais qui fait le reste...

Posté par  (site web personnel) . Modéré par tuiu pol.
Étiquettes : aucune
21
3
fév.
2011
Linux
Je vous présente la libroxml, une petite bibliothèque (moins de 50 Ko) d'analyse XML (parsing) sous licence GNU LGPL.

L'idée de base est que dans beaucoup de cas, l'analyse d'un fichier XML par une application est très basique, et ne requiert pas forcément l'utilisation de la libxml2, très puissante, mais un peu trop complexe et lourde. La libroxml permet, à partir d'une interface de programmation (API) comprenant une vingtaine de fonctions, de naviguer simplement dans un fichier XML, ainsi que d'utiliser un moteur XPath prenant en charge les expressions les plus courantes.

Bien évidemment, cette bibliothèque « roxe » le XML, mais à la base, libroxml signifie : « LIBrary Read Only XML ». Cependant, depuis la version 2.0, il est possible de créer et de modifier des documents XML à la volée (en mémoire), puis d'enregistrer les modifications dans un nouveau fichier.

En plus de la bibliothèque, le programme « roxml » permet d'exécuter des expressions XPath depuis un script shell.

Enfin, un module FUSE sûrement inutile, « fuse.xml », permet de monter un fichier XML en lecture seule dans le système de fichiers et de le parcourir selon les principes suivants :

  • les nœuds simples sont des dossiers ;

  • les nœuds textes sont représentés par un fichier « content.data » ;

  • les attributs sont des fichiers.



Tous les commentaires et retours d'expérience sont les bienvenus.

Aller plus loin

  • # Related work

    Posté par  (site web personnel) . Évalué à 3.

    C'est vachement sympa comme outil, et c'est une bonne idée de réutiliser XPath pour ça: les malheureux qui sont déjà pervertis par xml doivent connaître, ça leur évitera d'apprendre une nouvelle syntaxe.

    Comment ça se compare avec xmltools (http://blog.huoc.org/xmltools/), qui fournit des outils comme xmlsed et xmlgrep ?

  • # Xpath

    Posté par  (site web personnel) . Évalué à 3.

    Xpath nous avait été présenté à la truelle pendant un enseignement donc je n'avais pas compris comment ça marchait. Avec ces exemples, ça devient parfaitement clair. Merci pour les exemple !

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Xpath

      Posté par  (site web personnel) . Évalué à 3.

      Oui mais xpath, c'est lourd et moche, je crois que tous ceux qui ont taté du jquery préfère des API jquery «like» pour parser le xml comme :
      http://pypi.python.org/pypi/pyquery
      (il existe évidemment des projets similaires en perl, ruby, php, et java ....)

      • [^] # Re: Xpath

        Posté par  . Évalué à 2.

        Sauf que les syntaxes à la jQuery c’est pour du HTML, pas du XML générique (recherches sur les classes CSS par exemple), et qu’il y a un paquet de choses que tu peux faire en XPath et pas en jQuery.

        • [^] # Re: Xpath

          Posté par  (site web personnel) . Évalué à 2.

          on est pas vendredi, donc je ne relèverais pas l'énormité.
          J'incite juste à lire la man page http://api.jquery.com/category/selectors/

          jquery fait plus que seulement sélectionner par classe, on sélectionne par attributs (sur les noms ou les valeurs), par éléments , hiérarchie, positions pour les cas multivalués, intersection, compléments ...
          Bref, rien qui ne manque. C'est peut être pour ça que des développeurs ont fait les portages de syntaxe à la jquery pour le XML, non ? À moins que des devs aiment perdre du temps à faire des projets inutiles.

          • [^] # Re: Xpath

            Posté par  . Évalué à 4.

            J’ai pas dit que jQuery était inutile. J’ai dit que jQuery était orienté HTML (ce qui est vrai, puisqu’il a des raccourcis orientés HTML: .class, :checked,…) et qu’il était plus limité que XPath (allez, au pif, traduis-moi ces expressions en sélecteur jQuery: "div[not(contains(@id, 'alpha'))]", "a[@href='x' or @href='y']", "div[@title='truc' and .//a]", ou des choses plus amusantes comme "div[@id=fn:concat(..//div[@class='container']/@id,'-1')]")

            > À moins que des devs aiment perdre du temps à faire des projets inutiles.
            Moins puissant ≠ inutile, hein. Par rapport à XPath, la syntaxe jQuery a l’avantage d’être plus simple, plus légère et plus claire — surtout en HTML grâce aux nombreux raccourcis. C’est en soi un avantage qui justifie largement son existence — je suis d’ailleurs passé de xpath à jquery dans certains de mes projets justement pour ça.

            P.S.: ok, après relecture de mon premier message, le « c’est pour du html » était légèrement exagéré ;)

            • [^] # Re: Xpath

              Posté par  (site web personnel) . Évalué à 0.

              div[not(contains(@id, 'alpha'))]
              $("div:not(#alpha)")

              a[@href='x' or @href='y']
              $(a[href=x],$a[href=y])

              mais on peut aussi intégrer le "regexp filter" ou passer une fonction de map qui retourne que les href = x ou y

              $("a").grep( function(el) { href= $el.attr("href"); return inArray( href, [ "x", "y" ] ); });

              Pour les autres selecteurs je m'attarderais pas à les traduire car elle me pique les yeux comme une regexp utilisée pour parser du xml.

              jquery est très rubiesque/erlangesque dans son approche des données.

              La beauté de jquery est de s'appuyer sur du map reduce avec des fonctions anonymes, et de très puissantes fonctions de manipulations du DOM qui rend le code lisible. Ce n'est pas un hasard si ce sont les non informaticiens qui se sont emparés de ce langage, car cela leur permet de faire la même chose que xpath de manière intuitive.

              • [^] # Re: Xpath

                Posté par  . Évalué à 4.

                > div[not(contains(@id, 'alpha'))]
                > $("div:not(#alpha)")
                Pas la même chose : ne fonctionne que pour l’attribut id (et si je veux title ou href pour un lien ?), et c’est contains, pas equals.
                Au passage, je viens de retester, et la solution div:not([@id*="alpha"]) fonctionne enfin (il y a quelques temps, il n’aimait pas cette syntaxe)

                > a[@href='x' or @href='y']
                > $(a[href=x],$a[href=y])
                Pas la même chose: si ton sélecteur "a" est en fait un truc long comme un bras, tu es content de pouvoir faire un ou juste dans ton […]. Sans compter que dans ta version jQuery, tu parcoures l’arbre deux fois — en xpath, tu le fais qu’une fois. Et plus important, pour certains usages, l’ordre des résultats ne sera pas le même : dans le premier cas, tu as les liens dans l’ordre dans lequel ils apparaissent dans l’arbre DOM ; dans le second cas, tu as tous les liens "x" dans l’ordre d’apparition puis tous les éléments "y".

                > La beauté de jquery est de s'appuyer sur du map reduce avec des fonctions anonymes, et de très puissantes fonctions de manipulations du DOM qui rend le code lisible.
                Tu confonds l’API jQuery et la syntaxe de sélecteur jQuery. Tu peux très bien faire une API jQuery-like qui utilise xpath pour exprimer les sélecteurs, tout comme tu peux faire une syntaxe de sélecteurs jQuery-like qui n’ait pas une API jQuery-like (avec du map-reduce, comme tu dis).
                Tout ce que je te dis, moi, c’est que la syntaxe des sélecteurs de xpath est plus lourde mais permet de faire plus de chose que celle de jQuery.

                > Ce n'est pas un hasard si ce sont les non informaticiens qui se sont emparés de ce langage
                Non informaticiens ? Des développeurs Javascript/PHP/Python/Ruby/… ?
                Tu me fais peur là.

  • # pugixml

    Posté par  . Évalué à 6.

    Un autre dans le genre, en C++, hyper léger (30ko), bien plus rapide que libxml2, plus clair, et tout XPath 1.0 est supporté.

    [http://pugixml.org/]

  • # L'histoire est un éternel recommencement

    Posté par  (site web personnel) . Évalué à 10.

    Dans 3 ans, à force d'avoir rajouter des fonctionnalités à cette nouvelle bibliothèque, elle sera devenu lourde et lente et un nouveau challenger s'annoncera comme rapide et léger. 4 ans plus tard cette dernière aura elle aussi rajoutée plein de fonctionnalités "voulues par les utilisateurs" et sera aussi devenu un bloatware.

    Bref, le syndrome pas fait par moi a encore frappé !


    Je rappelle que quand la libxml, puis la libxml2 est sorti, c'était aussi la plus puissante et rapide des bibliothèque XML. qui a fini par manger expat qui était la référence de l'époque.

    Des benchs de bibliothèques XML sur ces dernières années...
    http://xmlbench.sourceforge.net/index.php?page=results.php

    • [^] # Re: L'histoire est un éternel recommencement

      Posté par  . Évalué à 5.

      Eh oui, c'est la course à l'échalotte: ajoute des trucs, sort une nouvelle version, etc. Sinon t'es obsolète et tu disparais.
      Ça fait penser à la réflexion sidérante - très souvent lue ou entendue:
      "le projet à l'air mort, sur le site il n'y a pas de nouvelle version depuis ... (suit un nombre de mois, d'années etc.)."
      Alors qu'un programme, une lib, une doc, ... qui fonctionnent bien n'ont pas besoin de fréquentes nouvelles versions.

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  . Évalué à 2.

        bwah ! tout ce qu'on veut c'est la dernière librairie à la mode, la sélection naturelle fera le reste.

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  (site web personnel) . Évalué à 2.

        Ben la très vénérable «numerical recipies» en fortran 77 fait le bonheur des rédacteurs de GNU/Linux mag qui nous parle de matplotlib qui bind sur cette bibhale de bonne qualité.

        Pour info, numpy implique l'installation des sources en fortran pour être recompilé :) Donc faut pas dire que ces bibliothèques sont oubliées. Une bonne bibliothèques n'est jamais remplacée o/

        FORTRAN ROX......... (je déconne on est pas vendredi)

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  (Mastodon) . Évalué à 3.

        c'est le cas de la vénérable zlib qui n'évolue plus mais que tout le monde utilise...

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  . Évalué à 2.

        Bah ça dépend, parce que sans mise à jour, une lib peut ne plus fonctionner, notamment si le langage hôte a évolué.

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  . Évalué à 5.

        « Alors qu'un programme, une lib, une doc, ... qui fonctionnent bien n'ont pas besoin de fréquentes nouvelles versions. »

        Tu me fais penser à WindowMaker là...

    • [^] # Re: L'histoire est un éternel recommencement

      Posté par  (site web personnel) . Évalué à 3.

      C'est aussi quelque chose que j'avais bien remarqué.
      Le but n'est pas de rajouter des fonctions à l'infini, mais plutôt d'avoir un accès simple et performant aux fonctions de base, et c'est pour ça que je me suis fixé une limite à 20 fonctions d'API. Pour l'instant il en existe 19, il ne reste donc de la place que pour une seule fonctionnalité en interne.

      La suite du projet sera alors plus de la correction de bugs / amélioration des perfs / support d'expression xpath.

      Pour les killer features, si vraiment je (ou quelqu'un) veux se lancer la dedans, ce sera des modules séparés...

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  (site web personnel) . Évalué à 9.

        J'ai déjà le proto de la 20ème fonction:

        int anything_else_xml(int what, ...) ;

        Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

        • [^] # Re: L'histoire est un éternel recommencement

          Posté par  . Évalué à 0.

          Raaaah le truc qui me herisse.

          Pourquoi un int pour le what ? Il y a un sens a avoir des valeurs negatives ?

          C'est un size_t qu'il faut mettre (et pour le retour je dirais un enum)

          • [^] # Re: L'histoire est un éternel recommencement

            Posté par  . Évalué à 3.

            pas un Variant ? je suis déçu.

          • [^] # Re: L'histoire est un éternel recommencement

            Posté par  . Évalué à 3.

            Parce qu'il veut blinder sa fonction et pas se retrouver avec des valeurs aux alentours de INT_MAX en cas d'erreur de l'utilisateur ?

            Le pire c'est que la solution que tu donne un type qui contient une sémantique qui n'a rien à voir avec la fonction.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: L'histoire est un éternel recommencement

            Posté par  (site web personnel) . Évalué à 4.

            Parce que ça fait juste 3 caractères, c'est plus rapide à saisir. D'ailleurs, le what pourrait être raccourci en w, ou simplement _. Et oui, ça peut avoir un sens de mettre des valeurs négatives - c'est à l'écrivain du code de décider qui est le coupable et où le crime a eu lieu.

            Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

          • [^] # Re: L'histoire est un éternel recommencement

            Posté par  . Évalué à 5.

            Si tu ne veut pas de valeurs négatives, c'est un unsigned int qu'il te faut.
            Le size_t, comme son nom l'indique, c'est fait pour les tailles / longueurs.

          • [^] # Re: L'histoire est un éternel recommencement

            Posté par  . Évalué à 2.

            "size_t" indique sémantiquement une taille. Comment peux-tu prédire qu'il aura besoin d'une taille en premier paramètre si tu ne sais pas à quoi elle va servir ?

            • [^] # Re: L'histoire est un éternel recommencement

              Posté par  . Évalué à 2.

              Je viens de m'apercevoir que la remarque a déjà été faite. Pour me faire pardonner, je vais ressortir l'antédiluvien article de Joel Spolski qui montre que des types peuvent être "sous-typés" juste afin de détecter plus de bugs. Il prend en exemple la très haïe notation hongroise, qui était une bonne idée à l'origine avant d'être mal comprise et détournée jusqu'à en devenir un boulet : http://www.joelonsoftware.com/articles/Wrong.html

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  (site web personnel) . Évalué à 2.

        Si elle reste réellement légère et performante, elle trouvera surement sa place dans l'embarqué ou dans des applis spécifique.

      • [^] # Re: L'histoire est un éternel recommencement

        Posté par  . Évalué à 4.

        Je ne vois pas trop en quoi la limitation du nombre de fonction est un gage en performance..
        Si tu pense a l'occupation mémoire, tu pourrais découper une librairie existante en plusieurs librairies chargée uniquement en fonction des besoins..

        • [^] # Re: L'histoire est un éternel recommencement

          Posté par  (site web personnel) . Évalué à 3.

          En fait, ce n'est pas du tout un gage de performance, mais plutôt un gage de simplicité. en limitant le nombre de fonctions d'API, on limite le temps de lecture de la documentation, de compréhension et donc de prise en main de la lib...

          Ensuite, la limite à 20 fonctions n'a pas été fixée arbitrairement, mais c'est plutôt un compromis entre : pas trop de fonctions pour rester simple et suffisamment pour que chaque fonction fasse une chose et pas 36.

    • [^] # Re: L'histoire est un éternel recommencement

      Posté par  . Évalué à 4.

      Oui, c'est le syndrome XFCE.

      Aujourd'hui, le bureau léger est LXDE, mais pour combien de temps ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Même léger, c'est lourd

    Posté par  . Évalué à 9.

    [je sais, ça fait troll du vendredi, un jour trop tôt. Mais je connais plein de gens qui pensent comme moi !]

    Bonjour,

    Je tiens à faire entendre un son de cloche peu relayé : celui de ceux qui n'aiment pas le XML et ne comprennent pas la "folie" qui tourne autour.

    Combien de développements ai-je vu blindés de XML, de couches et de sur-couches, au point que plus personne de se rend compte de la lourdeur induite par tout ce qu'il faut pour digérer ce format.

    Et un format soit disant lisible ! Ah ah ah, je me marre ! Qui sait lire le XML avec ses yeux ? Pas celui qu'on bricole avec son vim/emacs (ou son notepad plutôt, c'est plus le profil). Non, le velu, celui qui utilise toutes les lourdeurs^Wsubtilités ?
    Et qui écrit le machin (DTD, c'est bien ça ?) qui vérifie la validité de ce qu'on a écrit ?
    Et arrivé là, on a même pas encore commencé à l'utiliser !

    Bon, j'arrête là, J.P. Troll l'a beaucoup mieux expliqué que moi dans Linux Magazine n°127. Parce qu'y'en a marre !

    Bon amusement quand même !

    • [^] # Re: Même léger, c'est lourd

      Posté par  . Évalué à 3.

      "Je tiens à faire entendre un son de cloche peu relayé"

      Au contraire je n'entends que de ça des critiques contre le XML, même les développeurs Java n'aiment pas (ils passent aux annotations le plus possible).

      Le seul endroit où je n'ai pas entendu de critique sur l'utilisation du XML c'est pour les OpenDocument et le OOXML.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Même léger, c'est lourd

        Posté par  . Évalué à 2.

        Le problème ne vient pas forcément du XML en lui même, mais plutot le cadre dans lequel on l'utilise.

    • [^] # Re: Même léger, c'est lourd

      Posté par  (site web personnel) . Évalué à 5.

      Le problème n'est pas tant dans le format XML mais dans les formats définis en XML.

      Si on regarde un flux RSS ou Atom par exemple, c'est du XML et c'est assez simple à lire et comprendre.
      Si on prend par contre les fichiers de conf d'une application Android, c'est verbeux, lourd et chiant à lire.

      Et puis XML reste une bonne façon de représenter des données de façon arborescente de façon normée avec un panel d'outil incroyable pour les manipuler et les lire.

      Et éditer du XML directement ça reste assez rare et réservé à des développeurs. Tu édites souvent du SVG à la main ? Du OpenDocument ? Tu fais tes flux RSS à la main ?

      Perso, oui je trouve le XML facile à lire si bien pensé. Et je préfère cela que 15 façons différentes de stocker une configuration arborescente à réapprendre à chaque nouvelle application / framework /...

      L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

      • [^] # Re: Même léger, c'est lourd

        Posté par  . Évalué à 1.

        Je prends comme exemple la configuration de Log4J [http://wiki.apache.org/logging-log4j/Log4jXmlFormat] : vers la fin de cette page il y a quelques exemples de transformations de fichiers "properties" en fichiers XML. Et bien je trouve le "properties" un peu lourd, mais le XML est carrément indigeste. Et pourtant c'est là un fichier avec des données arborescentes, à destination d'humains.

        En général, je n'ai aucun problème avec les fichiers de configuration non-XML, car la plupart des formats permettent d'intégrer des commentaires suffisants pour comprendre ce que l'on fait. Dans mon expérience personnelle, la lourdeur de XML n'a jamais apporté quoi que ce soit.

  • # Module FUSE

    Posté par  (site web personnel) . Évalué à 8.

    À propos du module FUSE fuse.xml, GNU/Hurd a un translator xmlfs depuis 2006 :)

    • [^] # Re: Module FUSE

      Posté par  . Évalué à 10.

      Bah voilà, c'est pour ça qu'il n'avance pas : ils s'occupent des trucs inutiles avant les trucs utiles…

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Multiplateforme

    Posté par  . Évalué à 1.

    Cette librairie m'intéresse mais j'ai une question :
    est-elle multi-plateformes ?

Suivre le flux des commentaires

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