« Je parle de la virgule en fin de ligne. Qui n’est pas toujours systématiques. »
Comme dans le cas des arguments de fonctions, d’où la mise en parallèle des deux.

« Parce que moi j’ajoute/supprime/réordonne souvent des items dans des listes »
Moi aussi, mais dans ce cas, tu bouges les éléments, pas les virgules. Et encore, ça c’est encore et toujours quand tu fais tes modifications « à la main » ce qui est pas conseillé, que ce soit en XML ou en JSON.

« C’est bien ce que je te dis. Dans des cas concrets, la façon de faire en XML t’ouvre plus d’opportunités »
Non. Je l’ai prouvé  dans mes exemples précédents ! JSON permet de faire la même chose également mais ne l’impose pas !

« C’est peut être vrai mais ça ne retire pas le critère de ma grille de choix et de ses implications. »Ben si parce-que moi je n’ai pas ses problèmes là vu qu’on utilise sans doute pas les mêmes outils. Donc si le problème concerne certains outils, ça ne concerne pas JSON en soit. Si j’utilise le bloc note Windows pour modifier le XML et que je dis que XML est pourri parce-que sous le bloc note Windows c’est vite illisible et ça entraîne des problèmes de charset et encoding, il serait injuste d’imputer la faute à XML.

« J’ai quand même le droit d’avoir mes opinions mais là aussi je ne le sors pas de mon chapeau, je l’entends et vis assez souvent. »

Tu as le droit en effet de donner ton opinion, mais pas d’en faire une vérité générale. Dans ceux qui commentent ton billet, je ne vois personne qui trouve le JSON moins lisible que l’XML par exemple.

« Sauf que 1- Google a des contraintes très différentes de la plupart des gens »
Ben si à qualité égale j’ai le choix de faire un truc léger ou lourd, j’aurai tendance à prendre le léger, même si ce n’est pas une obligation.

 » 2- Twitter l’a abandonné « parce que JSON était plus utilisé » et pour ne pas maintenir les deux (j’ai vérifié) et pas pour des questions de perf. » 
C’est un choix politique de la part de Twitter, vu qu’ils ont mis fin au support après avoir recommandé aux développeurs d’utiliser JSON (http://groups.google.com/group… ) ce n’est donc pas une conséquence mais une volonté. Mais bon, j’ai pris ces exemples comme j’aurai pu en choisir d’autres comme Freebase, MongoDB etc.

« Oui, si tu t’appelles Google une différence de poids peut faire une grosse différence au final. Pour l’essentiel des gens, y compris les très gros, les échelles que je donne ne sont pas significatives par rapport aux autres critères. Pour les différences de perf côté navigateur, entre une analyse DOM et un eval(), le DOM est plus performant. J’avais aussi fait les tests pour des lib JS de parsing JSON, mais il faudrait les refaire, les moteurs JS ayant bien changé depuis. »
« Tu te trompes. J’ai fait des tests (il y a pas mal de temps, je l’avoue) et ça concorde avec les autres tests que j’ai lu chez d’autres. »

Toujours pas.
Pour les vrais tests bien plus précis, factuels, tenant compte du fait qu’il existe différents parseurs (et ne faisant ni la promotion de JSON ni celle d’XML), c’est par ici : https://github.com/eishay/jvm-

Et encore, c’est en admettant que tu veuilles utiliser le DOM sans autre transformations dans ton code (coûteuse en ressources) et donc accéder à l’information avec ce genre de codes
person.getElementsByTagName(« name »)->item(0)->innerText(); //ou equivalent
plutôt que
person->name;

Mais dans tout les cas, il ne faut pas être un ingénieur pour savoir qu’un fichier plus lourd chargé en mémoire prendra plus de place qu’un fichier plus léger.

« Quels avantages ? »
Souplesse, poids, simplicité, possibilité d’avoir des propriétés composées sans avoir à modifier tous les codes qui en dépendent (voir mon exemples précédent concernant l’ajout d’un auteur)Maintenant que j’ai répondu à ta question, je t’invite à répondre aux miennes (précédemment écrites) à savoir me citer un langage où JSON n’est pas utilisable (et où il faut réinventer la roue comme tu l’as dis) et un moyen de pouvoir ajouter une propriété composée à ta liste de chaines de caractères sans devoir modifier ton code.