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

Posté par (page perso) . Modéré par tuiu pol.
Tags : aucun
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.
  • # Related work

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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/]
    • [^] # Re: pugixml

      Posté par (page perso) . Évalué à  6 .

      Si on part dans le C++, celle que j'utilise (pour écrire aussi) :
      http://www.grinninglizard.com/tinyxml/
      (+ http://tinyxpath.sourceforge.net/ pour XPath, mais je n'utilise pas donc je ne sais ce que ça vaut)

      Quelqu'un a fait des tests sur les différents parsers XML léger? On s'y perd avec toutes ces libs légères!

      PS : le module FUSE, j'adore, belle démonstration de la facilité d'intégration de FUSE!
    • [^] # Re: pugixml

      Posté par (page perso) . Évalué à  4 .

      Je conseille aussi de jeter un coup d'oeil à xeumeuleu. Ce n'est pas un parser, il utilise Xerces pour ça, mais c'est une façon naturelle de lire un fichier XML en C++:

      http://sourceforge.net/apps/mediawiki/xeumeuleu/index.php?ti(...)

      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

      • [^] # Re: pugixml

        Posté par . Évalué à  3 .

        "une façon naturelle de lire un fichier XML en C++"
        On dit que tous les gouts sont dans la nature, mais quand même...
        • [^] # Re: pugixml

          Posté par . Évalué à  5 .

          C'est vrai qu'il manque "autoconf" pour que la phrase soit parfaite.
        • [^] # Re: pugixml

          Posté par (page perso) . Évalué à  1 .

          Tu as sans doute plus "naturel" à proposer?

          Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

  • # L'histoire est un éternel recommencement

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 . É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 (page perso) . É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 . É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.

      Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

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

      Posté par (page perso) . É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 (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.