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.
Aller plus loin
- YAML Site officiel (161 clics)
- Specification 1.2 (49 clics)
- JSON (14 clics)
# Exemple
Posté par claudex . Évalué à 9.
« 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 zerkman (site web personnel) . Évalué à 2.
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 yellowiscool . Évalué à 5.
J'écris mes pages en xhtml à la main.
Envoyé depuis mon lapin.
[^] # Re: Exemple
Posté par zerkman (site web personnel) . Évalué à 7.
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 wismerhill . Évalué à 1.
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 usbplug . Évalué à 1.
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 ckyl . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: Exemple
Posté par jm trivial (site web personnel) . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 2.
Après, c'est vrai que le format SVG n'est pas simple...
[^] # Re: Exemple
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 3.
[^] # Re: Exemple
Posté par zerkman (site web personnel) . Évalué à 1.
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 si la performance n'est pas la priorité.
# Page d'accueil en YAML ?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
[^] # Re: Page d'accueil en YAML ?
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Page d'accueil en YAML ?
Posté par Maclag . Évalué à 3.
# espaces dans XML
Posté par gautiers . É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 ckyl . Évalué à 10.
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 lasher . Évalué à 4.
# Encoder…
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
# Bof
Posté par cdvddt . Évalué à 3.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 1.
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 Larry Cow . Évalué à 8.
... la planète reconnaissante ?
[^] # Re: Bof
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Bof
Posté par Gniarf . Évalué à 3.
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 benoar . Évalué à 3.
[^] # Re: Bof
Posté par yellowiscool . Évalué à 3.
Par contre, étant basé sur javascript, la syntaxe est bien plus ancienne.
Envoyé depuis mon lapin.
[^] # CPAN de Perl
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
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 ckyl . Évalué à 8.
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 Sytoka Modon (site web personnel) . Évalué à 3.
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 wismerhill . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 1.
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 wismerhill . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 wismerhill . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 wismerhill . Évalué à 2.
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 ckyl . Évalué à 5.
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 ckyl . Évalué à 1.
- 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 Sytoka Modon (site web personnel) . Évalué à 2.
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 Thomas Douillard . Évalué à 2.
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 Bob . Évalué à 1.
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 Moonz . Évalué à 1.
[^] # Re: CPAN de Perl
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: CPAN de Perl
Posté par Antoine . Évalué à 2.
[^] # Re: CPAN de Perl
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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 yellowiscool . Évalué à 0.
Envoyé depuis mon lapin.
[^] # Re: Bof
Posté par reno . Évalué à 2.
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 Emmanuel C . Évalué à 2.
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 wismerhill . Évalué à 3.
Ce qui en fait de l'AJAJ du coup
;-)
# Google App Engine ?
Posté par DLFP est mort . Évalué à 2.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Google App Engine ?
Posté par RG_ . Évalué à 2.
[http://components.symfony-project.org]
L'un des composant est une librairie php qui lit le yaml
[http://components.symfony-project.org/yaml]
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Il y a quelques trucs qui me chiffonnent
Posté par yellowiscool . Évalué à 6.
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 steph1978 . Évalué à -1.
par contre, ça n'apporte pas grand chose par rapport à castor qui utilise lui du XML qui est plus universel.
[^] # Re: Il y a quelques trucs qui me chiffonnent
Posté par Ummon . Évalué à 2.
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 Sytoka Modon (site web personnel) . Évalué à 5.
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 forc3 . Évalué à 1.
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 Antoine . Évalué à 1.
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 gazbhan . Évalué à 3.
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 Amaury Bouchard (site web personnel) . Évalué à 3.
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 zyphos . Évalué à -1.
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 wismerhill . Évalué à 2.
AJAX c'est du javascript.
AJAX==Advanced Javascript And XML
(un buzzword quoi)
[^] # Re: YAML vs JSON
Posté par Ummon . Évalué à 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 wismerhill . Évalué à 2.
voir aussi web2.0 et autres conneries du genre.
# YAML vs INI
Posté par Amaury Bouchard (site web personnel) . Évalué à 4.
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 Alek_Lyon . Évalué à 4.
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 benoar . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.