YAML 1.2 est disponible !

Posté par . Modéré par Mouns.
Tags : aucun
17
30
juil.
2009
Technologie
Après plus d'un an de travail acharné (enfin...), une nouvelle spécification du langage de sérialisation YAML vient de paraître. YAML 1.2 vise principalement la compatibilité entre ce dernier et JSON (un autre langage de sérialisation plus modeste mais de plus en plus utilisé en lieu et place d'XML dans les requêtes AJAX).

En clair, cela signifie que les messages encodés en JSON seront lisibles par un analyseur YAML. Et que certains messages YAML seront également lisibles en JSON, pour peu que le message s'y prête.

Cette évolution de YAML, officiellement datée du 21 juillet 2009, reste une évolution mineure et montre la stabilité du langage. À part quelques cas spécifiques, les bibliothèques YAML 1.1 fonctionnent toujours. Cette évolution montre aussi l'indépendance de YAML vis à vis d'un langage de programmation puisqu'alors que l'implémentation de référence de YAML 1.1 était en python (PyYAML), celle de la version 1.2 est en Haskell. Bien entendue, d'autres implémentations dans différents langages existent et sont présentés sur la page de YAML.

YAML est utilisé, par exemple, en tant que format des fichiers de configuration des applications fonctionnant sur le Google App Engine.

Plus d'information sur YAML dans la suite de l'article ! YAML, acronyme récursif de YAML Ain't Markup Language ("YAML n'est pas un langage à balises", en références aux fameuses balises XML) est un langage de sérialisation faisant le pari que l'on peut encoder des données structurées de façon à la fois lisible par l'homme et analysable sans ambiguïté par une machine. Cela contraste avec XML où chaque caractère a un sens dans le document, où présenter un document sur une seule ligne ou avec multiples retours à la lignes et espaces en font de facto deux documents différents (du point de vue de XML). Entre autre, YAML a été conçu pour ceux qui n'apprécient pas le coté verbeux et contraignant d'XML.

L'idée de YAML, inspirée du langage Python et de diverses notations de wiki, est de présenter les informations structurées par une ponctuation simple, ainsi qu'un jeu d'indentation et de retour à la ligne pertinent, permettant au document d'être naturellement lisible sans toutefois introduire d'ambiguïté.

La plupart des données en informatique n'est qu'une composition de structures simples, comme une liste, un dictionnaire, une référence, ou une simple valeur (un scalaire). YAML offre une syntaxe simple pour identifier rapidement ces éléments ainsi qu'une méthode pour les composer (les imbriquer les uns dans les autres).

Le plus bel exemple est la page officielle de YAML, elle même écrite en YAML et néanmoins parfaitement compréhensible par un humain (et analysable par une machine, cela va de soit).

De plus, YAML définit également la notions de documents indépendants pouvant être chaînés, avec un marqueur de fin explicite permettant d'émettre du YAML sur une connexion TCP, sans difficulté pour connaître la fin d'un document.

Pour rappel, la sérialisation consiste à transformer un ensemble de données structurées, comme un "objet" en java, une "structure" en C, ou encore une quelconque donnée abstraite, en une suite de données simples que peuvent manipuler des outils comme les sockets servant de base aux connexions réseaux. Pour faire simple, il s'agit de "mettre à plat des données qui ne le sont pas (arbres, graphes)". La page Wikipedia Sérialisation est une excellente présentation de la technique.
  • # Exemple

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

    Bonne dépêche mais un exemple n'aurait pas été de trop je pense. Et la page d'accueil du projet manque de commentaire explicatif pour bien comprendre.

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Exemple

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

      c'est vrai que quand on connaît Python et cette bouse infâme de XML, ça aide mieux à comprendre.

      J'avoue moi aussi être tombé sur des dépêches avec plein de sigles dedans (généralement dans le domaine du génie logiciel), et n'avoir absolument pas saisi l'intérêt de tel ou tel truc version 2.42 par rapport à machin 3.11.

      Je me dis dans ces cas là qu'il doit bien y avoir du monde pour en saisir l'intérêt, et (peut-être à tort ?) que cela ne me concerne pas.

      Sinon en gros, pour comprendre l'intérêt relatif de YAML, tu peux constater que la page du projet est formatée de manière humainement compréhensible (avec des retours à la ligne, des indentations qui aident à la lecture). XML c'est le contraire, c'est formaté pour être lisible par un ordinateur, et non par un humain normalement constitué. Regarde le contenu d'un fichier gnumeric ou Inkscape (non compressés) avec un éditeur de texte pour t'en convaincre.
      • [^] # Re: Exemple

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

        Mince, je ne suis pas humain alors.

        J'écris mes pages en xhtml à la main.

        Envoyé depuis mon lapin.

        • [^] # Re: Exemple

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

          C'est pas pareil. Déjà je ne suis pas sûr que l'on puisse utiliser yaml pour écrire des documents, alors que (x)html est à la base fait pour ça.

          Autant écrire du texte avec des balises xhtml relève d'une relative simplicité, autant des données xml avec une structure de stockage un peu compliquée deviennent vite illisibles.

          En gros le (x)html écrit par un humain peut s'avérer relativement lisible, car l'humain en question va s'arranger pour placer judicieusement des retours à la ligne et indentations qui rendront la structure du document compréhensible. Mais il peut aussi tout écrire en une ligne s'il veut rendre son truc illisible. Si j'ai bien compris avec YAML, on ne peut pas faire ce qu'on veut, car la structure est justement définie par les indentations et les retours à la ligne.
          • [^] # Re: Exemple

            Posté par . Évalué à 1.

            En gros le (x)html écrit par un humain peut s'avérer relativement lisible, car l'humain en question va s'arranger pour placer judicieusement des retours à la ligne et indentations qui rendront la structure du document compréhensible.

            Ben, c'est le cas du XML en général.
            Il n'y a que pour les éléments qui sont définis avec l'attribut (hérité) xml:space="preserve" qu'il faut faire attention à ses espaces/retours à la ligne.
            En général, un document XML offre plus de possibilités de mise en forme car on met à la ligne ce qu'on veut, indépendamment de la structure logique du document.

            Mais je concède sans problème que, ne connaissant pas YAML, les documents semblent effectivement tout à fait compréhensibles.
        • [^] # Re: Exemple

          Posté par . Évalué à 1.

          Tu es sans doute humain, certains écrivent bien des documents en TeX (je ne parle pas de LaTeX).

          Mais c'est vrai que le XHTML est verbeux pour pas grand chose.

          Le HAML permet d'écrire la même chose de façon beaucoup plus simple et compacte : http://haml-lang.com/

          J'étais un peu sceptique au début, ayant aussi l'habitude d'écrire le code XHTML à la main et étant content de l'aide apportée par Vim et Textpad.

          Mais maintenant, j'adore la simplicité du HAML et ça me casse les bonbons de devoir refaire du XHTML à la main.
      • [^] # Re: Exemple

        Posté par . Évalué à 4.

        Petit exercice pratique: Prendre un "fichier inkscape". Le convertir en YAML de la manière que tu veux. Nous montrer que le fichier est devenu "humainement compréhensible" et donc que le problème était bien la technologie utilisée pour stocker les données.

        Après on pourra discuter des fonctionnalités que tu as perdu en passant au YAML, de la légèreté gagnée ou de la différence de performance etc. Voir même de l'utilité que tel format de fichier soit "humainement compréhensible".
        • [^] # Re: Exemple

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

          Mauvais exemple... un fichier inkscape n'est pas un fichier de configuration donc il n'y a pas besoin de l'éditer à la main sauf en cas de deboguage pour les développeurs du logiciel. Donc on est sur un autre problème ou justement le XML est tout aussi bien que le YAML puisqu'on serialize puis de-sérialize. On pourrait utiliser le YAML si cela apportait un plus dans ce cas. A priori, comme cela, il n'y a pas de plus donc l'un ou l'autre me sont indifférents.
          • [^] # Re: Exemple

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

            un fichier inkscape n'est pas un fichier de configuration donc il n'y a pas besoin de l'éditer à la main sauf en cas de deboguage pour les développeurs du logiciel.
            Je ne suis pas tout à fait d'accord. Il m'est arrivé d'écrire des scripts pour générer des fichiers svg (le format utilisé par inkscape), en partie en utilisant un fichier déjà existant. Et bien j'aurais aimé que le format soit plus simple d'accès. Même si au final je m'y suis retrouvé, quelqu'un qui n'est pas à l'aise avec les documents xml serait vite perdu.
            • [^] # Re: Exemple

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

              Si tu fait un programme qui génère du code, tu n'est plus réellement dans l'admniistration système mais dans la partie dev. Tu tomberas un jour ou l'autre à générer un arbre avec une syntaxe ayant des subtilités. Cela peut êre pénible à faire mais c'est un développement comme un autre.

              Après, c'est vrai que le format SVG n'est pas simple...
            • [^] # Re: Exemple

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

              En même temps, quelqu'un qui n'est pas à l'aise avec les documents xml se dit rarement "tiens, je vais écrire des scripts pour générer des fichiers SVG".
        • [^] # Re: Exemple

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

          je t'avouerai être bien incapable de faire ce genre de choses.

          De plus mon exemple était mauvais, car la structure des SVG générés par Inkscape reste relativement compréhensible. Cela dit les chemins de plusieurs centaines de points qui tiennent sur une seule ligne (sous forme de chaîne de caractères), c'est un peu dur à lire.
          La structuration XML a ses limites, apparemment. Cela dit je ne crois pas YAML permette de faire mieux.

          En fait le gros défaut dans la conception de XML a été de reprendre ce qui servait à écrire des documents (html) pour stocker tout et n'importe quoi. Autant le formatage de documents avec balises avait du sens, et permettait à des humains de modifier facilement des documents complexes à la main, autant le stockage de données, principalement destiné à des machines, n'avait pas besoin de ce genre de fioritures, notamment en raison de la complexité du parsing.

          Je ne dis pas que YAML résoud tout niveau légèreté, lisibilité, toussa. Juste que ça me paraît plus adapté au stockage et à l'échange de données informatiques, et l'accessibilité par un humain est garantie par le format.

          Par rapport à la lisibilité et l'efficacité: La lisibilité a forcément un coût: fichiers plus gros, temps CPU pour la conversion, etc. Pour une efficacité maximale, ni XML ni YAML ne peuvent rivaliser avec les formats binaires (cités plus bas dans la discussion). Donc autant utiliser un format prévu pour être humainement compréhensible si la performance n'est pas la priorité.
  • # Page d'accueil en YAML ?

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

    D'après ce que je vois, elle est en XHTML /o\
  • # espaces dans XML

    Posté par . Évalué à 5.


    Cela contraste avec XML où chaque caractère a un sens dans le document, où présenter un document sur une seule ligne ou avec multiples retours à la lignes et espaces en font de facto deux documents différents (du point de vue de XML).

    ben non justement.
    XML s'en fout des retours à la ligne, des tabulations et des espaces.
    Un document sur une seule ligne ou sur 100 lignes (avec le même contenu) seront vu comme deux documents identiques d'un point de vue XML
    Au contraire de YAML si j'ai bien compris.
    • [^] # Re: espaces dans XML

      Posté par . Évalué à 10.

      > XML s'en fout des retours à la ligne, des tabulations et des espaces. Un document sur une seule ligne ou sur 100 lignes (avec le même contenu) seront vu comme deux documents identiques d'un point de vue XML

      Dit comme cela c'est faux. Les espaces sont significatifs en XML si le document n'a pas de DTD. Il peuvent être ignoré, par défaut, que lorsqu'une DTD est spécifiée. De même il est possible de spécifier le comportement vis à vis des espaces via l'attribut xml:space.

      Bref c'est loin d'être aussi trivial que ça.

      http://www.oracle.com/technology/pub/articles/wang-whitespac(...)
      http://www.ibm.com/developerworks/xml/library/x-diff/index.h(...)
      • [^] # Re: espaces dans XML

        Posté par . Évalué à 4.

        D'un autre côté XML n'a d'intérêt (selon moi) que si les documents XML sont bien formés et bien spécifiés. S'il n'y a ni schéma ni DTD, je me demande bien pourquoi on s'embête à faire du XML.
  • # Encoder…

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

    Le terme français n'est-il pas coder, tout simplement ?
  • # Bof

    Posté par . Évalué à 3.

    Je trouve quand même JSON carrément plus simple dans sa spécification.
    Et JSON est suffisamment expressif pour pouvoir faire tout ce qu'on fait avec YAML.
    La multiplication des format de structures de données complique inutilement des choses.
    • [^] # Re: Bof

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

      Il est quand même intéressant d'avoir une certaine diversité... mais c'est toujours le même débat.
      Cependant au niveau des formats de structures de données, il serait bon de voire une certaine convergence, c'est un fait.
      Ceci étant dit, grâce à la diversité des formats, les chances de converger vers la meilleur des solutions et plus grande que si un seul format de piètre qualité était utilisé par tous.
      Le plus gros dilemme dans ce genre de cas est peut-être encore le fait que les aficionados de chaque format défendront becs et ongles leur format qui est LE MEILLEUR car les autres formats saymal !


      .... à la race humaine...

      Alexandre COLLIGNON

      • [^] # Re: Bof

        Posté par . Évalué à 8.

        .... à la race humaine...

        ... la planète reconnaissante ?
      • [^] # Re: Bof

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

        En effet, XML saymal.
      • [^] # Re: Bof

        Posté par . Évalué à 3.

        DUH !

        c'est pas les différents formats le problème, ce sont les différents besoins.

        les formats sont des solutions à ces besoins, et de la même façon qu'on n'a pas de solution unique à tous les besoins, on n'aura pas un format unique ou universel répondant à la problématique de la sérialisation de données. déjà, la meilleure solution, c'est à dire le format le mieux adapté, ça dépendra ce qu'on veut en faire...

        (cf jpeg versus png versus svg versus vrml versus...)
    • [^] # Re: Bof

      Posté par . Évalué à 3.

      Il me semble que YAML est apparu avant JSON, quand même.
      • [^] # Re: Bof

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

        Selon wikipedia, la première proposition pour le Yaml est en 2001, alors que pour le json, c'est apparemment en 2005.

        Par contre, étant basé sur javascript, la syntaxe est bien plus ancienne.

        Envoyé depuis mon lapin.

        • [^] # CPAN de Perl

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

          Je ne sais pas de quand cela date mais tous les modules Perl dans le CPAN ont un fichier de spécification en YAML. Je pense que le CPAN est donc l'utilisateur numéro 1 du YAML.

          Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)

          Moi j'ai horreur du XML dans le fichiers de conf (merci Red-Hat et Novell de nous en mettre plein en ce moment)...
          • [^] # Re: CPAN de Perl

            Posté par . Évalué à 8.

            > Après, je vois que les fanatiques de java et de Tomcat trouvent leur fichier XML lisible et super. Je voudrais voir un serveur d'application Tomcat avec autant de module que le CPAN ;-)

            Tu compares deux technologies différentes pour deux utilisations différentes. Ce n'est pas très rigoureux ni très objectif. Tout d'abord fixons l'utilisation à un module CPAN. En YAML ca donne:


            --- #YAML:1.0
            name: Module-Build
            abstract: Build and install Perl modules
            version: 0.20
            author:
            - Ken Williams<kwilliams@cpan.org>
            license: perl
            distribution_type: module
            requires:
            Config: 0
            recommends:
            Archive::Tar: 1.00
            build_requires:
            Test: 0
            urls:
            license: http://dev.perl.org/licenses/
            meta-spec:
            version: 1.3
            url: http://module-build.sourceforge.net/META-spec-v1.3.html
            generated_by: Module::Build version 0.20


            Tout d'abord on constate que l'idée de python de se servir de l'indentation, en pratique c'est pas vraiment une bonne idée. Bon courage pour retrouver le document initial maintenant que templeet à bouffer les espaces. (Soyons clair je développe en python, mais c'était vraiment une idée à la con)

            En XML ca donnerait quelque chose comme ca:


            <module>
            <name>Module-Build</name>
            <abstract>Build and install Perl modules</abstract>
            <version>0.20</version>
            <author>
            <name>Ken Williams</name>
            <email>kwilliams@cpan.org</email>
            </author>
            <license>perl</license>
            <requires>
            <module name="Config"/>
            </requires>
            <recommends>
            <module name="Archive::Tar" version="1.00"/>
            </recommends>
            </module>


            Personnellement je trouve pas ca plus ou moins lisible... META.yml décrit quelque chose de trivial. Ca s'exprime très simplement quelque soit la technologie.

            Par contre comment je vérifie que mon META.yml est correct ? Quand j'écris mon document comment je découvre la structure du document ? Pourquoi je dois spécifier "Config: 0", c'est à dire devoir spécifier une valeur à que je veux dire "je m'en fou" ?

            J'ai rien contre YAML et je trouve aussi que XML est overkill parfois et surtout pas adapté aux documents non arborescents tout comme YAML. Mais il faut pas dire n'importe quoi non plus.

            Maintenant je t'invite à nous montrer en quoi YAML permettrait de rendre les fichiers de configuration de Tomcat plus lisible mais surtout plus facile à manipuler. Personnellement je les trouves pas pire qu'un fichier de conf d'exim mais bon...
            • [^] # Re: CPAN de Perl

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

              Il est trivial de faire yaml2xml donc valider un yaml est facile...

              Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.

              Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !
              • [^] # Re: CPAN de Perl

                Posté par . Évalué à 3.

                Il est trivial de faire yaml2xml donc valider un yaml est facile...

                Si ta proposition pour valider du YAML est de passer par du XML, je préfère utiliser directement du XML avec un éditeur qui le fait à l'édition grâce au schéma/DTD et me propose une complétion automatique.

                Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.

                Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !


                Ben, je trouve ça beaucoup mieux de valider la configuration à priori, plutôt que de relancer son serveur en espérant que tout est bon.
                cf "apachectl configtest"
                • [^] # Re: CPAN de Perl

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

                  Tu n'es jamais assuré que le fichier n'a pas été modifié avant de relancer le serveur donc ton serveur doit vérifier le fichier. La validation qu'a priori est une erreur et dans la conception de site web, amène a de grave erreur si on ne vérifie pas sur le serveur tous les paramêtres POST et GET.

                  Donc, une fonction check sur le serveur est absolument nécessaire. Ce check peux te prendre le YAML, te le transformer en XML (binaire - mémoire / comme cela, il n'y a pas de XML fichier si cela te va mieux) et le valider ainsi. En fait, tu n'en seras rien. Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.

                  Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs. Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...
                  • [^] # Re: CPAN de Perl

                    Posté par . Évalué à 4.

                    Tu n'es jamais assuré que le fichier n'a pas été modifié avant de relancer le serveur donc ton serveur doit vérifier le fichier.

                    Si tu as un serveur dont les fichiers de configuration sont modifiés sans te prévenir, il faut t'inquiéter de la sécurité de celui-ci.

                    La validation qu'a priori est une erreur et dans la conception de site web, amène a de grave erreur si on ne vérifie pas sur le serveur tous les paramêtres POST et GET.

                    Uh??
                    On parle de fichiers de configuration là!

                    Ce n'est pas ton problème, toi tu es utilisateurs, tout cela est programmé / scripté.

                    Non, tu n'es pas utilisateur, tu es administrateur et tu es supposé comprendre ce que tu utilise.
                    Si tu es un simple utilisateur, tu aura une interface qui va te proposer des choix plus ou moins simples et se chargera d'écrire un fichier de configuration correct (on espère...). Et là le format exact du fichier tu t'en fous.

                    Ensuite, je veux un éditeur sans X-Window. Je ne veux pas de l'erreur de Windows d'imposer le graphique sur les serveurs.

                    Pourquoi parle-tu de X-window?
                    On peut faire des programmes de validation en console, par exemple xmllint.

                    Et puis, je ne vois pas pourquoi on ne pourrait pas complèter du YAML puisque ce n'est qu'une autre manière d'écrire un arbre...

                    C'est sûrement possible de le faire, mais je réagissait sur le fait de valider, non seulement la syntaxe mais aussi le contenu d'un document.

                    Y a-t-il en YAML un équivalent des schémas XML?
                    • [^] # Re: CPAN de Perl

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

                      Je crois qu'il y a des schémas YAML mais je n'ai jamais utilisé. Ce que je veux dire, c'est que YAML tout comme XML ne sont qu'une représentation d'un arbre. Ton validateur, si ce n'est pas du SAX mais du DOM charge tout. Dans le cas d'un fichier de config, c'est pas illogique. Donc tu valides un DOM et non directement un XML. Du coup, valider un DOM écrit en YAML plutot qu'en XML ne pose pas de problème puisque la transformation YAML->XML est facile.

                      Bref, pour moi, c'est des mauvaises raisons pour ne pas développer d'autres backend au DOM et vouloir du XML partout.

                      Un exemple pour moi de folie, c'est le XSLT... Vouloir faire des programmes, en plus de type moteur d'inférence, en XML, c'est grandiose ;-)

                      Sinon, au niveau des fichiers de conf, je parlais de modif de dernières minutes fait à l'arrache avec vi ou a une conf propagé par cfengine... Il arrive de se planter... donc le serveur doit valider son fichier de conf au chargement. A vrai dire, c'est pas cela qui lui prends non plus des heures.
                      • [^] # Re: CPAN de Perl

                        Posté par . Évalué à 2.

                        Du coup, valider un DOM écrit en YAML plutot qu'en XML ne pose pas de problème puisque la transformation YAML->XML est facile.

                        YAML gère-t-il un équivalent à la notion d'espace de noms de XML?

                        Un exemple pour moi de folie, c'est le XSLT... Vouloir faire des programmes, en plus de type moteur d'inférence, en XML, c'est grandiose ;-)

                        Je fais du XSLT quotidiennement au boulot, et je trouve ça très pratique. À partir du moment où on a compris le principe de fonctionnement par filtrage, ça permet de faire des choses très évoluées.

                        Sinon, au niveau des fichiers de conf, je parlais de modif de dernières minutes fait à l'arrache avec vi ou a une conf propagé par cfengine... Il arrive de se planter... donc le serveur doit valider son fichier de conf au chargement. A vrai dire, c'est pas cela qui lui prends non plus des heures.

                        Oui, et quand il a constaté que son fichier de configuration est invalide:
                        soit c'est un détail qu'il peut ignorer, mais alors on se rend parfois compte un mois après que le serveur ne fait pas ce qu'on croyait;
                        soit le programme est robuste et continue a tourner avec son ancienne config (et s'il est bien fait il t'envoie une notification);
                        soit il plante et ton service est interrompu.
                        • [^] # Re: CPAN de Perl

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

                          Attention, je ne dis pas que XSLT est une mauvaise chose. Ce type de programmation, de type moteur d'inférence (prolog, make) sont géniaux pour certaines taches.

                          C'est uniquement la syntaxe qui est lourding pour un langage de programmation. Sans IDE qui complète ou sans copier-coller de bout de code d'un fichier dans un autre, c'est hyper chiant... C'est uniquement ce point là qui me gène.
                          • [^] # Re: CPAN de Perl

                            Posté par . Évalué à 2.

                            Alors je suis d'accord :-)
                            Avec un simple éditeur avec coloration syntaxique (voir pas du tout) il est effectivement lourd d'écrire une feuille de style XSLT.

                            N'empêche qu'un outil comme xmlstarlet (http://xmlstar.sourceforge.net) permet de faire en vitesse des petites requètes en ligne de commande sur un document XML de façon pas plus compliquée (bien que très différente) qu'un awk.
                            Couplé avec un tidy ça permet de faire de l'analyse de pages HTML en shell script.
              • [^] # Re: CPAN de Perl

                Posté par . Évalué à 5.

                > Il est trivial de faire yaml2xml donc valider un yaml est facile...

                Où est ton schema pour décrire un document yaml ? Ou alors tu l'écris en XSD ? (oui je sais c'est facile cf. kwalify mais chacun fait son truc dans son coin).

                > Mais comme dans les formulaires, même si le client valide son fichier (formulaire), c'est au serveur de valider le fichier de conf au lncement.

                Puisqu'il faut valider côté serveur, ca n'a aucun sens de proposé une aide à la personne qui édite un document ? La logique m'échappe un peu.

                > Cette histoire de validation est à mon sens bidon. Il y a plus de 10000 modules je crois sur le CPAN et cela MARCHE !

                Version courte:

                Cette histoire de yaml est à mon sens bidon. Il y a plus de 18564 packages RPM dans fedora et cela MARCHE !
                À quoi sert yaml alors qu'un bête fichier texte fait exactement la même chose.


                Version longue:

                En XML tu définis la structure de ton document via un schema XML ou un DTD. Cette définition est non ambigüe et peut être utilisée pour: produire une documentation sur le format de fichier, vérifier que le document que l'on rédige est valide, vérifier que le document que l'on nous transmet a la structure attendue, aider l'éditeur du document en lui montrant les elements, les attributs, les valeurs acceptable et la documentation associée etc.

                En YAML, pour gagner quelques caractères et par ce que les chevrons n'ont pas l'air de te plaire tu: écris une spec ambigüe en langage naturelle ( http://module-build.sourceforge.net/META-spec-v1.3.html ) , dois humainement vérifier que ton document correspond à la spec, vérifier la structure de ton arbre avant de l'utiliser dans tes applications, doit lire la doc pour savoir ce que tu as le droit de mettre ou pas.

                Excuse moi j'ai du rater un truc quelque part...
              • [^] # Re: CPAN de Perl

                Posté par . Évalué à 1.

                Maintenant tu n'as toujours pas répondu à mes questions pourtant très simples. Il n'y a pas de piège, je te demande juste d'étayer tes affirmations:

                - En quoi YAML est plus adapté qu'XML pour le META.yml ? Les deux solutions sont parfaitement recevables (et bien d'autres); seulement tu nous expliquais que YAML était beaucoup plus adapté qu'XML pour cette tâche. Sur le plan verbosité/lisibilité tu n'as pas contesté, et pour la perte de fonctionnalité tu as proposé un traduction vers XML...

                - Tu critiques les fichiers de configuration de Tomcat en mettant en cause XML. Puisque tu es le seul à avoir parler d'XML et de fichier de configuration dans ce thread, je suppose que tu proposais d'utiliser YAML à la place ? Peux tu nous montrer en quoi cela améliorerait les choses ?
                Au cas oú tu ne parlais pas d'utiliser YAML; alors pourrait tu nous montrer rapidement comment tu verrais un fichier de configuration objectivement plus simple pour Tomcat ?
                • [^] # Re: CPAN de Perl

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

                  Je répondrais rapidement car l'heure est avancé...

                  Je préfère le YAML ou le JSON lorsque j'édite les fichiers à la main. Les fichiers XML sont très pénible à faire à la main. D'ailleurs tu le sous entend toi même en parlant d'éditeur spécialisé.

                  La règle numéro un devrait être de rester simple et donc de pouvoir faire tourner un serveur sans X. Les éditeurs en question ont besoin de X je suppose.

                  La règle numéro deux voudrait qu'on puisse configurer directement sans passer par un méta outil parfois web pour configurer...

                  Le YAML, pour quasiment une grande partie des fichiers de config (qui reste en général simple) se travaille très bien avec grep, sed, cfengine. C'est important pour faire des scripts sur un parc conséquent.

                  Je n'ai plus en tête les fichiers Tomcat car dès que je vois un serveur en java avec Tomcat, je choisis une solution équivalente sans Tomcat. Je n'en ai plus sous la main. En gros, si mes souvenirs sont bons, c'est un arbre donc en YAML, c'est juste un arbre sous forme

                  clef: valeur

                  Pas besoin de <> et "" qui alourdissent sans rien apporter. Remarque, le JSON me convient tout à fait mais la news parle de YAML...

                  Donc pour finir "En quoi YAML est plus adapté qu'XML pour le META.yml ? " Tout simplement parce que j'écris ce fichier à la main, que je le modifie à la main... C'est comme un Makefile, c'est fait pour être manipuler par des êtres humains.

                  Avec la folie du XML, l'idée est de simplifier la vie de la machine et de mettre l'homme dans une syntaxe rigide et absolument lourde. Lex et Yac ont été inventé il y a longtemps, c'est pas un soucis pour la machine de lire autre chose que du XML.
                  • [^] # Re: CPAN de Perl

                    Posté par . Évalué à 2.

                    Pour les histoires de grep/sed, pour du XML tu dois avoir des équivalents qui utilisent XPATH par exemple pour trouver des noeuds dans ton arbres.

                    Tiens genre http://xmlstar.sourceforge.net/doc/UG/ch04s03.html

                    Exemples :

                    # Rename elements
                    xml ed -r "/xml/table/rec" -v record xml/tab-obj.xml

                    Output:

                    <xml>
                    <table>
                    <record id="1">
                    <numField>123</numField>
                    <stringField>String Value</stringField>
                    <object name="Obj1">
                    <property name="size">10</property>
                    <property name="type">Data</property>
                    </object>
                    </record>
                    <record id="2">
                    <numField>346</numField>
                    <stringField>Text Value</stringField>
                    </record>
                    <record id="3">
                    <numField>-23</numField>
                    <stringField>stringValue</stringField>
                    </record>
                    </table>
                    </xml>

                    EXAMPLE

                    # Update value of an attribute
                    xml ed -u "/xml/table/rec[@id=3]/@id" -v 5 xml/tab-obj.xml

                    Output:

                    <xml>
                    <table>
                    <rec id="1">
                    <numField>123</numField>
                    <stringField>String Value</stringField>
                    <object name="Obj1">
                    <property name="size">10</property>
                    <property name="type">Data</property>
                    </object>
                    </rec>
                    <rec id="2">
                    <numField>346</numField>
                    <stringField>Text Value</stringField>
                    </rec>
                    <rec id="5">
                    <numField>-23</numField>
                    <stringField>stringValue</stringField>
                    </rec>
                    </table>
                    </xml>
                  • [^] # Re: CPAN de Perl

                    Posté par . Évalué à 1.

                    C'est comme un Makefile, c'est fait pour être manipulé par des êtres humains.

                    Ce que tu ne sais peut-être pas, c'est qu'il y a des gens un peu torturés qui font des Makefile en XML... Ça s'appelle des scripts Ant !
            • [^] # Re: CPAN de Perl

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

              Prenons comme cas d'école un très gros fichier : Est-ce que Microsoft pourrait utiliser yaml pour remplacer son infâme base de registres ? Ou est-ce que XML serait préférable ?
              • [^] # Re: CPAN de Perl

                Posté par . Évalué à 2.

                C'est une question à peu près aussi intelligente que de demander si PostgreSQL devait passer à XML pour le stockage des données... Quand on a une grosse quantité de données et qu'on veut des requêtes efficaces (y compris en écriture), on choisit un format adapté.
            • [^] # Re: CPAN de Perl

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

              > Par contre comment je vérifie que mon META.yml est correct ?

              Tu le parses.

              > Quand j'écris mon document comment je découvre la structure du document ?

              Tu as le parser.

              > Pourquoi je dois spécifier "Config: 0", c'est à dire devoir spécifier une valeur à que je veux dire "je m'en fou" ?

              Car les ambiguités dans les languages de description, c'est mal. TRÈS mal.
          • [^] # Re: CPAN de Perl

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

            Tu n'as pas choisi la facilité en prenant l'exemple de java. Bonne chance, c'est déjà parti là.

            Envoyé depuis mon lapin.

        • [^] # Re: Bof

          Posté par . Évalué à 2.

          OK, mais vu que JSON existe maintenant la vraie question est plutôt:
          pourquoi une nouvelle version de YAML au lien de dire aux gens que l'évolution de YAML c'est JSON maintenant?

          J'aurais tendance à penser que YAML et JSON joue dans la même niche et que donc il y en a un des deux qui est de trop..
          • [^] # Re: Bof

            Posté par . Évalué à 2.

            JSON ne propose pas de mécanisme de référence, et cela peut être embêtant dans certains cas. JSON ne propose pas de notions de document, et c'est très bien d'ailleurs. JSON a été conçu pour rester très simple. Mais il y a des cas ou JSON n'est pas assez avancé pour ce que l'on doit faire. Et YAML, dans ce cas, entre en jeu.

            YAML propose plusieurs manières de rentrer des chaînes de caractères de façon a conserver la lisibilité du document, propose une méthode simple de découper un flux (fichier / pipe / socket) en documents, etc.

            De façon général, YAML a été conçu dès le départ pour que la lecture et l'écriture à la main soit simple. JSON a (eu historiquement) un but tout autre : zapper XML de l'AJAX. La sortie de YAML 1.2 permet plutôt de dire que l'évolution de JSON c'est YAML, mais seulement pour ceux qui en ont besoin.
            • [^] # Re: Bof

              Posté par . Évalué à 3.

              JSON a (eu historiquement) un but tout autre : zapper XML de l'AJAX

              Ce qui en fait de l'AJAJ du coup
              ;-)
  • # Google App Engine ?

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

    Il y a de meilleurs exemples : Ruby on Rails, Symfony, …

    DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Il y a quelques trucs qui me chiffonnent

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

    Les formats textuels sont très pratiques pour les humains, c'est-à-dire pour la communication bidirectionnelle homme-machine.

    Pour de la communication machine à machine, je suis assez mitigé. Lorsque que les données échangées sont quasi uniquement textuelle, je ne vois pas de gros problèmes. C'est le cas notamment des protocoles mail (smtp, ...), web (http, ...), im (jabber, ...).

    Par contre quand les données sont à caractère binaire, cela pose des problèmes. Parmi ceux-ci, on peut relever :
    - la taille des données sont accrues (un integer 32bits devient potentiellement beaucoup plus grand)
    - les tâches sérialisations sont plus lourdes. En cas de format binaire, il faut essentiellement régler les problèmes d'endianess. Ici, il faut générer du texte avec un format déterminé ce qui est peu devenir problématique, en terme de puissance, que la quantité de donnée échangée est grosse.
    - Il y a pas mal de parsing à faire ce qui est pas non plus des moins gourmand en puissance.
    - pour aller chercher, un seul champ au milieu du texte, il faut parser l'entièreté.

    Le problème du binaire est que pour un humain ce n'est pas facile à lire. Mais quand lit-on cela ? Quand on débuggue, par exemple, dans ce cas, on peut avoir un programme de conversion des paquets en textuel (cas de communication machine-homme où ce format peut être utile car il me semble vraiment clair - voir mieux que json à ce niveau).

    Quand on fait des fichiers de confs, également, mais pour ma part, je n'aime pas trop ce genre de fichier de config générique, je préfère du custom à l'apache, exim ou autre. De plus de mon expérience avec ce genre de fichier de config, on finit par avoir un programme qui génère l'affaire (exemple, de l'xml des config jboss,struts et autres bizarries de javaïste).

    Dans les protocoles textuelles, qui ne devraient pas l'être, on peut prendre SIP. La signalisation pour la voix n'a pas beaucoup d'atout (la lisibilité par des humains n'est pas suffisament fort pour le justifier) en mode textuel. Un protocole tel que IAX est beaucoups plus efficace et ne pose pas plus de problème en débugging (tout au contraire car il n'y a pas les artifices d'ouverture d'autre port pour RTP et autres, pour compenser le format textuel).

    En conclusion, pour du machine-humain, cela peut être sympa mais il faut y réflechir au cas par cas en fonction du type de donnée et du réél besoin. Pour du machine-machine, pour le transfert de données essentiellement textuelles, un grand oui ; pour du binaire, un grand non.
    • [^] # Re: Il y a quelques trucs qui me chiffonnent

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

      Pour du transfert entre machines, un truc pas mal du tout est le format de google Protobuf.

      http://code.google.com/p/protobuf/

      En gros, on décrit le protocole dans une syntaxe bien à la mode entre le json et le yaml (mais juste la description), et un programme se charge de faire le code pour traiter tout ça en C++, java, et python.

      Les transferts se font ensuite en binaire ou en texte (aux choix). C'est performant, et compressé. Bref du bonheur si on en a besoin.

      Envoyé depuis mon lapin.

    • [^] # Re: Il y a quelques trucs qui me chiffonnent

      Posté par . Évalué à 2.

      Le mieux reste à mon avis les trucs comme Protobuf[1] qui à partir d'une définition permette de générer le code de sérialisation/désérialisation. Les messages peuvent alors être transformés en binaire pour le communication inter-machine ou en texte pour sa lecture par un humain.

      Bon maintenant c'est vrai qu'il ne supporte pas tous les langages/plateformes et donc ne favorise pas l'intercommunication dans un milieu fortement hétérogène, son but étant avant tout les performances.

      [1] : http://code.google.com/p/protobuf/
      • [^] # Re: Il y a quelques trucs qui me chiffonnent

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

        Sinon, il y a les formats comme NetCDF (limité mais simple) ou HDF qui sont fait pour cela.

        Comme je l'ai déjà il y a quelques temps ici, on aurait mis un toute petite partie de l'énergie mis sur XML a faire une API équivalente a celle d'XML sur le format HDF (ou un autre équivalent), on aurait aujourd'hui un XML binaire...

        En effet, le XML est mauvais dans les fichiers de conf mais a du bon dans d'autres cas d'utilisation, et souvent, dans ces cas la, on aurait un arbre binaire que ce serait pas plus mal.
        • [^] # Re: Il y a quelques trucs qui me chiffonnent

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

          La solution existe depuis très très longtemps, cela se nomme ASN1.

          Seulement les implémentations ne se valent pas et finalement certaines supportent plus de fonctionnalités que d'autres.

          ASN1 est mis en oeuvre dans LDAP et SNMP par exemple.

          Tant que les développeurs continuerons à trouver intéressant de faire des protocoles simples à parser pour avoir le loisir d'écrire un parseur à chaque fois, nous sommes perdus.

          Je dis cela car je l'ai fait, et le jour ou j'ai été confronté à faire évoluer un protocole, j'ai compris la difficulté et c'est là que j'ai vu que cette problématique est directement prise en charge dans ASN...

          Bref, ne chercher pas si loin, tout est déjà là et accessible...
    • [^] # Re: Il y a quelques trucs qui me chiffonnent

      Posté par . Évalué à 1.

      Par contre quand les données sont à caractère binaire, cela pose des problèmes. Parmi ceux-ci, on peut relever :

      Cela ne pose problème que si la taille des données est conséquente.
      Par contre, la lisibilité est un gain important, même pour un format machine. Quand tu dois débugger du HTTP, tu es bien content que le flux réseau soit lisible.

      (tout au contraire car il n'y a pas les artifices d'ouverture d'autre port pour RTP et autres, pour compenser le format textuel).

      SIP est mal foutu, c'est clair. Ceci dit, il est conçu comme un protocole de signalisation générique, ce qui justifie en partie que les données transitent par des flux séparés (SIP lui-même n'a aucune notion de données audio, ce sont d'autres protocoles qui s'en chargent ; SDP par exemple).

      Le gros problème de SIP est qu'il essaie de faire beaucoup de choses à la fois (signalisation, routage...) et que la spec est byzantine (probablement écrite par des gens qui n'ont jamais eu à implémenter un protocole par eux-mêmes).

      pour du binaire, un grand non.

      HTTP transporte très régulièrement du binaire ;)
  • # YAML vs JSON

    Posté par . Évalué à 3.

    Je n'ai pas compris l'intérêt de YAML par rapport à JSON.

    Quelqu'un saurait il éclairer ma lanterne ?

    Déjà, je n'ai pas compris l'intérêt de json pour d'autres utilisation que du JavaScript ... Son unique intérêt réside pour moi dans le fait que sa syntaxe est directement celle d'un objet javascript, donc très facilement "évaluable" (et c'est très pratique, j'en conviens).

    Maintenant, comme format d'échange de données, YAML ou JSON, quel intérêt ?
    • [^] # Re: YAML vs JSON

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

      L'intérêt du JSON pour autre chose que du Javascript ? Quand tu as besoin de sérialiser/désérialiser des données constituées de types scalaires (chaînes, entiers, flottants), de listes et des tableaux associatifs, c'est quand même vachement pratique.

      En PHP, par exemple, on manipule souvent des listes de hashs sans arrêt, voire des listes de listes contenant des hashs qui contiennent des listes, etc. Un petit coup de json_encode() et json_decode(), et tu peux stocker ces données très facilement.
    • [^] # Re: YAML vs JSON

      Posté par . Évalué à -1.

      Pour interfacer Javascript avec d'autres languages, Ajax par exemple.

      Pour info, petit comparatif de vitesse:
      Marshal vs. JSON vs. Eval vs. YAML (en Ruby)
      http://www.pauldix.net/2008/08/serializing-dat.html

      Info sur Marshal en Python
      http://docs.python.org/library/marshal.html

      Implémentation Marschal python en Javascript:
      http://code.activestate.com/recipes/200839/

      Il ne faut pas confondre YAML avec YAML, Yet Another Multicolumn Layout (qui est très pratique également) ;)
      http://www.yaml.de/en/home.html
      • [^] # Re: YAML vs JSON

        Posté par . Évalué à 2.

        Pour interfacer Javascript avec d'autres languages, Ajax par exemple.

        AJAX c'est du javascript.
        AJAX==Advanced Javascript And XML
        (un buzzword quoi)
        • [^] # Re: YAML vs JSON

          Posté par . Évalué à 1.

          asynchronous JavaScript and XML[1]

          C'est vraiment qu'au final ce n'est pas grand chose, mais ça permet de faire tout de même pas mal de choses (en bien et en mal) au niveau d'une page web, merci XMLHttpRequest.

          [1] http://en.wikipedia.org/wiki/Ajax_(programming)
          • [^] # Re: YAML vs JSON

            Posté par . Évalué à 2.

            Oui, mais ça le faisait déjà depuis longtemps quand on a inventé le terme marketing pour faire vendre de sous-disant nouvelles versions.
            voir aussi web2.0 et autres conneries du genre.
  • # YAML vs INI

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

    Si on dit que le YAML est super bien pour faire des fichiers de configuration simples à écrire, lisibles par un humain et rapides à parser (cf. la discussion plus haut qui disait que le YAML n'aurait pas pu servir pour stocker un équivalent du SVG), et qu'en cela c'est mieux que JSON et XML, pourquoi ne pas comparer avec un simple fichier INI ?

    Alors oui, les fichiers INI ne peuvent pas être super complexes (un seul niveau d'arborescence, des données scalaires ou des listes). Mais niveau lisibilité et simplicité, on fait difficilement mieux. Et pour la rapidité de parse, mes tests le donnent un peu plus rapide que pour du JSON équivalent, et beaucoup plus rapide que du XML équivalent.

    Alors bon, même si je ne doute absolument pas des qualités du YAML, j'utilise mon arsenal constitué de INI, JSON et XML, en fonction des besoins. Un quatrième format, ça commencerait à faire beaucoup (sauf peut-être si c'était un format binaire, il y a des cas où ça pourrait être utile).
    • [^] # Re: YAML vs INI

      Posté par . Évalué à 4.

      À mon travail, quand je suis arrivé, on m'a demandé de définir un format de messages réseaux. L'unique contrainte était que les messages soient lisibles par un humain.

      Deux formats étaient pressentis : INI ou XML. D'un côté, j'avais donc un format simple, mais mal défini et peu puissant ; d'un autre : un format rigoureux et puissant, mais plutôt complexe - et faire un parser XML sur un petit powerpc avec 16 Mo de flash et 64Mo de RAM, je ne le sentais pas.

      Ben franchement, je suis bien content d'avoir trouvé yaml (et kwalify pour la partie schémas et validation). Résultat : le format des messages est parfaitement bien défini, sans ambiguïté, et ils sont triviaux à lire :
      - et par un humain à l'œil nu ;
      - et par un programme : il fut facile en effet, à partir des schémas kwalify, de faire un programme qui génère le code C++ pour charger n'importe quel message dans un objet et produire les bons messages d'erreurs si nécessaire (champ manquant, pas du bon type, etc.).

      NB : malheureusement il est hors de question de libérer tout ce code qui appartient à mon employeur peu accoutumé au logiciel libre :-( mais peut-être quand je serai au chômage, je le referai chez moi en GPL...
      • [^] # Re: YAML vs INI

        Posté par . Évalué à 2.

        j'avais donc un format simple, mais mal défini et peu puissant
        C'est le gros problème du "INI", puisqu'il n'existe pas de norme, tout le monde le fait à sa sauce, et il y a toujours des problèmes. C'est un format à proscrire si on veut faire un truc un minimum évolutif. Même si il a l'air simple et sympa, c'est la galère dès qu'on fait des choses un minimum évoluées (comment coder les chaînes avec des espaces ? avec des caractères "spéciaux" ? quel est l'encodage ? ...)

Suivre le flux des commentaires

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