si c'est pour une édition par des humains, je préfère YAML.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers .desktop (donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.
Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: XML sapu et autres billevesées
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 2.
J'ai eu une fois à implémenter un parseur YAML. C'était vraiment l'horreur. Ils ont fait des choix vraiment bizarres et ont défini plein de façons de noter la même donnée. On ne s'en rend pas compte côté utilisateur car on va en général utiliser la même notation partout. Mais quand on fait un parseur, il faut être exhaustif (pour ce 1% de gens qui vont envoyer des fichiers avec cette syntaxe). Très mauvaise expérience.
Si pour une édition par des humains, je préfère quelque chose de bien plus simple encore, type fichiers clé-valeur simple. Il y a des formats de ce type standardisés, typiquement celui de FreeDesktop qui fut défini pour les fichiers
.desktop(donc utilisés par la plupart des — sinon tous les — bureaux libres). Ce type de format reste simple à parser (et en général, y a même pas besoin de faire soi-même, si on utilise une bibliothèque de bureau, par exemple glib). Ce format peut contenir des chaînes de caractères, nombres, booleans et des listes, des sections (même la localisation est prise en charge si besoin est, et elle peut être automatisée avec extraction du texte original par gettext puis génération de fichiers qui contiennent toutes les localisations; c'est ce qui est fait en général pour localiser les fichiers desktop!) et il n'emploie pas 10 variantes par type ni de logique super-compliquées.Sinon y a aussi des formats encore plus simples, plus proches du INI de Microsoft (le format standardisé par Freedesktop est d'ailleurs très proche, bien qu'avec quelques différences) qui est aussi beaucoup utilisé, même sur nos systèmes libres.
Ces formats sont souvent suffisants et je ne vois pas l'utilité d'apporter la complexité du YAML pour un fichier destiné à être édité par des humains. Ensuite je dis pas, YAML a des fonctionnalités plus avancées et peut-être dans des cas d'usage très particuliers, il convient de monter d'un cran et d'utiliser ce format. Mais je n'ai jamais eu le cas. En général, lorsque le besoin devient vraiment complexe, ce n'est plus un format que je destine à l'édition par des humains, mais par un programme (et à ce moment, ce n'est pas non plus le YAML que je vais choisir).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]