Aller au contenu

Discussion:YAML

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

récursif

[modifier le code]

En quoi est-ce récursif ?

Dans le nom, le Y vient de YAML, dont le Y vient de YAML, dont le Y vient YAML... :)

>YAML Ain't Markup language c'est récursif comme GNU's Not Unix, être récursif c'est s'appeler >soit-même, pas seulement son initiale.

pas de balises ?

[modifier le code]

Je m'étonne de la phrase : Enfin, YAML se distingue de ces deux autres formats par le fait qu'il n'utilise pas de balise.

Je comprends par rapport au XML, je comprends moins par rapport au JSON ; sauf à considérer que les {,} et ; du JSON sont des balises, auquel cas on est en droit de considérer que les indentations et retour à la ligne du Yaml, sont aussi des balises, me semble-t-il ? Touam (d) 3 mars 2010 à 20:40 (CET)[répondre]

Je suis peut-être allé un peu trop vite sur ce point, effectivement. En fait, je voulais signaler le fait que contrairement au XML ou à JSON, YAML n'utilise pas de "balises explicites" (du genre <toto>totoised</toto> ou effectivement {"blabla": {"bloblo": 42}} ce que dit d'ailleurs son nom : YAML Ain't a Markup Language), ce qui explique en bonne. Je viens d'aller voir les articles Langage de balisage, JSON et YAML en Français et en Anglais : JSON est considéré comme un langage à balise en en:, et il est dit qu'il en utilise dans l'article fr:. Cela dit, YAML est aussi catégorisé comme markup language en en:... Je ne connais probablement pas assez JSON pour avoir une vision claire sur celui-ci. Sans doute faudrait-il effectivement revoir cette phrase, en la replaçant dans le contexte : "YAML est plus orienté vers la représentation de données que sur le formatage de document (par rapport à XML)". Par rapport à JSON, la comparaison dans l'article en: me parait claire et succincte, non ? TcheBTchev (d) 4 mars 2010 à 13:18 (CET)[répondre]
La comparaison balise / pas balise me parait très casse gueule. Ce qu'il y a de sûr est que avec Yaml on les voit beaucoup moins qu'en XML :-)
On pourrait dire, aussi, que en XML il y a un balisage sémantique ; ainsi "<client>SFR</client>" a un balisage sémantique "client", tandis qu'il n'existerait pas en Yaml... mais on pourrait très bien dire que "client: SFR" manifeste un balisage sémantique ; les "<" et ">" se remplacent par ": " et "\n"... pas facile tout ça...
Oui la version anglaise est très bonne
Touam (d) 4 mars 2010 à 14:57 (CET)[répondre]
Ok, on a qu'à supprimer ma phrase incorrecte, et partir sur ce que tu proposes + adaptation de la section en: correspondante. TcheBTchev (d) 4 mars 2010 à 16:39 (CET)[répondre]
J'ai l'impression que les différences importantes avec le "reste" sont en vrac :
- en XML, on peut mettre une donnée dans un flot de donnée ; par ex. <toto> un deux <titi>A A</titi> trois </toto> ; ceci est techniquement impossible à faire en Yaml - comme en JSON ; ce truc a un nom mais je sais plus lequel.
- Et puis aussi, le fait que il suffit d'une seule passe d'analyse pour lire un fichier Yaml, et on peut connaître un niveau d'imbrication en partant de quasi n'importe où, alors que pour XML ou JSON il faut forcément commencer au début.
- En Yaml la caractérisation des données est plus poussée qu'en JSON, mais pas forcément qu'en XML, à cause du système des schémas.
- Et tout ce à quoi j'ai pas pensé.
Touam (d) 4 mars 2010 à 22:03 (CET)[répondre]

L'histoire de la roue

[modifier le code]

Bref, c'est banalement ce qui s'appelle "réinventer la Roue". Mais avec un carré, histoire de "pas faire comme tout le monde", comme tout bon geek dénué de bon sens qui se respecte...

Alors pas de balise ? OK. Mais l'indentation EST une balise. C'est le principe même de Python. Et puis quand on utilise de #, des -, des &, etc... Bah pour moi, ça, ce sont des balises.

Après, je vois pas l'intérêt de sortir un format que SEULS quelques illuminés vont trouver génial, alors qu'ils sont les seuls à le comprendre. Et à le lire. Ils sont où les éditeurs pour l'utiliser, ce format ? Et qu'est-ce que ça a de vraiment MIEUX que xml, css ou simplement un fichier texte avec groupes ou passage de ligne ? Le tout étant PARFAITEMENT LISIBLE et EXPLOITABLE rien qu'avec un éditeur de texte de base (genre bloc-note).

Mais... pourquoi faire simple quand on peut faire compliqué, pas vrai ? Les gens qui ne sont pas dans le métier et qui n'ont jamais été habitué à travailler avec rigueur ET en pensant aux utilisateurs de ce qu'ils font, produisent immanquablement des trucs bancals et trop lourd.


L’avantage de YAML par rapport aux autres formats, c’est sa lisibilité. Okhjon (d)

Soyons précis et compréhensibles

[modifier le code]

Certaines parties de l'article semblent être une mauvaise traduction de l'article en anglais.

Par exemple: "Les commentaires sont signalés par le signe dièse (#) et se prolongent sur toute la ligne. Si par contre le dièse apparait dans une chaine, il signifie alors un nombre littéral."

Premièrement le signe (#) se nomme le croisillon (ou à la rigueur le mot-dièse). Deuxièmement, "nombre littéral" ne veut rien dire. Une traduction correcte de la page Wikipédia anglais serait que dans une chaîne de caractère, le croisillon n'annonce plus un commentaire mais n'est rien d'autre que le symbole littéral qu'il représente. --Irmo322 (discuter) 31 août 2018 à 15:25 (CEST)[répondre]

Je viens de tester sur http://yaml-online-parser.appspot.com/, il n'est pas interprété comme un nombre littéral, avec simple ou double quotes. JackPotte ($) 31 août 2018 à 19:10 (CEST)[répondre]