Le site ne donne pas d'argument en faveur de SDLang ou en défaveur de JSON ou YAML. Quel problème cherche-t-il à corriger, quelle amélioration apporte-t-il ?
J'ai parcouru les exemples, je n'ai rien vu d'attirant au premier regard. Je me suis arrêté au format des dates, en me demandant pourquoi l'auteur n'avait pas repris le format ISO…
Qu'est-ce qui te fais dire que c'est poussé par Oracle ? À part qu'ils sont listé comme utilisateurs je ne vois rien les concernant. Au contraire les diverses implémentations sont des priors arts par rapport à ça.
TOML est conçu comme une amélioration de INI (plutôt orienté configuration que sérialisation de données structurées comme JSON)
C'est vrai qu'il a aussi les bénéfices mentionnés en plus d'être plus facile et bien supporté/intégré par/avec les divers langages.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je trouve que JSON5 est une meilleure solution alors.
Notamment, je trouve que les attributs sont une mauvaise idée. Cela donne deux manières de renseigner une valeur, avec les dérives qui vont avec et la complexité pour naviguer dedans (cf Xpath).
JSON et YAML représentent de la donnée universelle qu'on peut directement manipuler dans les types de bases de tous les langages de haut-niveau : dictionnaire, liste, etc. Tu parse et après tu oublie le format pour utiliser les API natives du langage.
XML requiert une API spécifique pour manipuler les éléments, leurs enfants et leurs attributs. C'est un vrai fardeau à l'usage. SDLang a la même API DOM avec element.getTagAttribute, element.getTagValue, element.getTag, etc.
En fait, SDLang est à XML ce que le YAML est au JSON, un variante plus facile à rédiger manuellement. Donc c'est bien quand on est payé à la ligne de code.
Gérer N versions d'un format pas forcément compatible plutôt que N formats différents ? (qui n'ont pas prévu de versionement au passage) Ça ne change pas grand chose.
Mais ça dépend de l'objectif.
S'il s'agit d'un format d'échange comme l'est json tu as besoin d'avoir pleins de choses qui le gèrent.
Si c'est le format de configuration de ton logiciel tout le monde s'en fou. Personne ne se pleins que nginx, apache httpd, vim ou autres ont des formats de configuration dédiés.
json5 est très peu supporté donc tu ne peux pas t'en servir pour une api publique par exemple et les parseurs ne peuvent pas déduire le format (il faut des heuristiques qui valent ce qu'elles valent). Si demain json++ sort avec des choix différents de json5, ça va devenir compliqué par exemple.
// Tags may contain certain non-alphanumeric characters
this-is_a.valid$tag-name
OK, mais quand juste après on a :
// Namespaces are supported
renderer:options "invisible"
physics:options "nocollide"
ça me pose souci parce-que les balises peuvent contenir n'importe quel caractère …y compris les deux points non ? Au passage, je me demande quel est l'équivalent de cet exemple, avec les espaces de noms, en XML !
De même, bien plus tôt on a :
// Anonymous nodes are supported
"This text is the value of an anonymous node!"
c'est sympa, mais pareil : les balises pouvant contenir n'importe quels caractères, pourquoi ce ne serait pas une balise avec une valeur vide ? Et sinon, dans quel cas a-t-on des valeurs qui flottent comme ça ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
ça me pose souci parce-que les balises peuvent contenir n'importe quel caractère …y compris les deux points non ?
Non, c'est dans la doc :
Names and namespaces are identifiers.
[…]
An SDLang identifier starts with a unicode letter or underscore () followed by zero or more unicode letters, numbers, underscores (), dashes (-), periods (.) and dollar signs ($).
les balises pouvant contenir n'importe quels caractères
Non des lettres et quelques caractères et pas les espaces du coup.
Ah, pas vu cette doc. Mais du coup, ça fait moins que JSON et YAML mais bon ça se positionne par rapport au XML.
Y a des restrictions sur les attributs ?
Et le coup des valeurs sans identifiants ? (nœuds anonymes…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Intérêt ?
Posté par Boa Treize (site Web personnel) . Évalué à 10.
Le site ne donne pas d'argument en faveur de SDLang ou en défaveur de JSON ou YAML. Quel problème cherche-t-il à corriger, quelle amélioration apporte-t-il ?
J'ai parcouru les exemples, je n'ai rien vu d'attirant au premier regard. Je me suis arrêté au format des dates, en me demandant pourquoi l'auteur n'avait pas repris le format ISO…
Forcément, le XKCD qui s'impose : https://xkcd.com/927/
[^] # Re: Intérêt ?
Posté par woffer ✅ . Évalué à 1.
Peut-être pousser par Oracle pour attaquer les utilisateurs par la suite pour récupérer des sous ?
[^] # Re: Intérêt ?
Posté par barmic 🦦 . Évalué à 3.
Qu'est-ce qui te fais dire que c'est poussé par Oracle ? À part qu'ils sont listé comme utilisateurs je ne vois rien les concernant. Au contraire les diverses implémentations sont des priors arts par rapport à ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intérêt ?
Posté par Jean Gabes (site Web personnel) . Évalué à 2.
Ce n'est pas lié à Oracle en effet: https://github.com/s-ludwig?tab=repositories
[^] # Re: Intérêt ?
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à -1.
Je n'en vois aucun en pratique non plus. Par contre j'en vois un stratégique : diviser pour mieux régenter.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Intérêt ?
Posté par barmic 🦦 . Évalué à 3.
Régenter ? Qui ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intérêt ?
Posté par Dave Newton 🍺 (site Web personnel) . Évalué à 7.
Je vois les avantages suivants:
Effectivement le choix du format des dates non iso est curieux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Intérêt ?
Posté par ff9097 . Évalué à 7.
Toml
[^] # Re: Intérêt ?
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à 3. Dernière modification le 17/09/21 à 00:14.
TOML est conçu comme une amélioration de INI (plutôt orienté configuration que sérialisation de données structurées comme JSON)
C'est vrai qu'il a aussi les bénéfices mentionnés en plus d'être plus facile et bien supporté/intégré par/avec les divers langages.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Intérêt ?
Posté par barmic 🦦 . Évalué à 3.
Le format c-style est sympa, mais du coup il est plus faible qu'un DSL fais en groovy/ruby
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intérêt ?
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à 2.
ça se présente comme un dérivé human-friendly de XML : c'est déjà un DSL agnostique de tout langage de programmation, un peu comme recfiles…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Intérêt ?
Posté par Étienne BERSAC (site Web personnel) . Évalué à 5.
Je trouve que JSON5 est une meilleure solution alors.
Notamment, je trouve que les attributs sont une mauvaise idée. Cela donne deux manières de renseigner une valeur, avec les dérives qui vont avec et la complexité pour naviguer dedans (cf Xpath).
JSON et YAML représentent de la donnée universelle qu'on peut directement manipuler dans les types de bases de tous les langages de haut-niveau : dictionnaire, liste, etc. Tu parse et après tu oublie le format pour utiliser les API natives du langage.
XML requiert une API spécifique pour manipuler les éléments, leurs enfants et leurs attributs. C'est un vrai fardeau à l'usage. SDLang a la même API DOM avec
element.getTagAttribute,element.getTagValue,element.getTag, etc.En fait, SDLang est à XML ce que le YAML est au JSON, un variante plus facile à rédiger manuellement. Donc c'est bien quand on est payé à la ligne de code.
[^] # Re: Intérêt ?
Posté par Ysabeau (site Web personnel, Mastodon) . Évalué à 6.
C'est pas mieux d'améliorer, si nécessaire, les formats existants plutôt que de complexifier (et de bordelifier) en en rajoutant un ?
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Intérêt ?
Posté par barmic 🦦 . Évalué à 4.
Gérer N versions d'un format pas forcément compatible plutôt que N formats différents ? (qui n'ont pas prévu de versionement au passage) Ça ne change pas grand chose.
Mais ça dépend de l'objectif.
S'il s'agit d'un format d'échange comme l'est json tu as besoin d'avoir pleins de choses qui le gèrent.
Si c'est le format de configuration de ton logiciel tout le monde s'en fou. Personne ne se pleins que nginx, apache httpd, vim ou autres ont des formats de configuration dédiés.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Intérêt ?
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à 3.
Que fais-tu du syndrome nih ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Intérêt ?
Posté par Dave Newton 🍺 (site Web personnel) . Évalué à 3.
Pour json c'est faisable (exemple: https://json5.org/).
Pour xml, il suffit de ne l'utiliser que là où il est strictement nécessaire (documentation).
Pour yaml, la seule amélioration possible c'est de le mettre à la poubelle.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Intérêt ?
Posté par barmic 🦦 . Évalué à 4.
json5 est très peu supporté donc tu ne peux pas t'en servir pour une api publique par exemple et les parseurs ne peuvent pas déduire le format (il faut des heuristiques qui valent ce qu'elles valent). Si demain json++ sort avec des choix différents de json5, ça va devenir compliqué par exemple.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# inconsistances
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à 2.
Quand je vois :
OK, mais quand juste après on a :
ça me pose souci parce-que les balises peuvent contenir n'importe quel caractère …y compris les deux points non ? Au passage, je me demande quel est l'équivalent de cet exemple, avec les espaces de noms, en XML !
De même, bien plus tôt on a :
c'est sympa, mais pareil : les balises pouvant contenir n'importe quels caractères, pourquoi ce ne serait pas une balise avec une valeur vide ? Et sinon, dans quel cas a-t-on des valeurs qui flottent comme ça ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: inconsistances
Posté par barmic 🦦 . Évalué à 3.
Non, c'est dans la doc :
Non des lettres et quelques caractères et pas les espaces du coup.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: inconsistances
Posté par Gil Cot (site Web personnel, Mastodon) . Évalué à 2.
Ah, pas vu cette doc. Mais du coup, ça fait moins que JSON et YAML mais bon ça se positionne par rapport au XML.
Y a des restrictions sur les attributs ?
Et le coup des valeurs sans identifiants ? (nœuds anonymes…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: inconsistances
Posté par barmic 🦦 . Évalué à 2.
La référence du format peut probablement répondre.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# très mal nommé
Posté par David Demelier (site Web personnel) . Évalué à 7.
Le nom du projet (son acronyme) entre en conflit avec la vénérable SDL.
git is great because linus did it, mercurial is better because he didn't
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.