En laissant de côté les arguments subjectifs évidents (c'est verbeux, les analyseurs sont complexes et lents, la spécification est énorme, le rapport entre les données et le marquage est mauvais), je vais parler du modèle de données de XML par rapport à JSON.
Premièrement, le modèle de données correspond aux données. Les paires clé/valeur (hachages), les listes et les scalaires sont les principaux moyens d'organisation. Ce sont des structures de données naturelles avec lesquelles les humains travaillent bien. Regardez le monde qui vous entoure, vous les trouverez partout. Considérez un simple formulaire, une liste de courses, une description de vous-même, une liste des choses que vous avez faites aujourd'hui ou un courriel dans votre boîte de réception. XML aime les arbres, et c'est gênant. Vous pouvez consulter le site peut modéliser tout comme un arbre. D'un point de vue informatique, il s'agit d'une structure très flexible, mais elle n'est pas naturelle. Les choses ont tendance à avoir un peu de structure hiérarchique, mais pas en tant que primaire les moyens d'organisation.
Deuxièmement, le modèle de données correspond aux structures de données natives des langages de programmation dynamiques. Je ne saurais trop insister sur ce point. La lecture d'un document JSON dans Perl, Ruby, Python ou Javascript est triviale car il correspond directement aux variables natives. Il suffit de l'ingurgiter. Le XML doit être transformé, car la plupart des langages ne font pas bien les arbres et les graphes. Et vous devez décider comment vous allez gérer les attributs par rapport aux balises internes. Allez-vous obtenir <person eyes="blue">Joe</person> ou <person><eyes>blue</eyes><name>Joe</name></person> ? Chaque organisation aura sa propre façon de procéder avec ses propres balises et ses propres particularités, ce qui implique un codage supplémentaire pour les développeurs. Regardez l'abomination que sont Listes d'Apple pour un exemple.
JSON, de par sa simplicité et son modèle de données qui correspond à la nature des données qu'il représente, ne peut représenter des données données données que de quelques manières plausibles. Il n'est donc pas nécessaire d'avoir un schéma, il suffit d'y jeter un œil. Et comme son modèle de données correspond au modèle de données natif du langage, la transformation des données d'un document JSON est aussi simple que la transformation de n'importe quelle autre donnée. Aucune manipulation d'arbre n'est nécessaire.
JSON est terriblement limité, et il y a beaucoup de choses qu'il ne peut pas faire. Mais ce n'est pas grave, il est naturellement contraint par ses limites. Vous ne pouvez pas faire faire à JSON ce qu'il ne peut pas faire (pas sans beaucoup de travail). XML est le contraire. Il est générique et sans contrainte. Vous pouvez prendre presque n'importe quel problème de données et l'appliquer à XML. Des fichiers de configuration ? Fichiers journaux ? Courrier électronique ? Fichiers de construction de projet ? Bien sûr ! Mettez tout ça en XML ! Ajoutez à cela que pendant un certain temps, le XML était le seul format de données générique sérieux, et qu'il était présenté comme le format universel, et vous obtenez une génération de technologies construites avec le XML qui sont surdimensionnées.
Le XML a été introduit lorsque j'ai commencé à programmer. Il a été salué comme le grand sauveur de l'échange de données ! Il n'était plus nécessaire d'écrire des analyseurs personnalisés pour les formats de données inventés que vos partenaires commerciaux utilisaient, il suffisait de faire circuler des documents XML ! C'est générique ! Vous n'avez besoin que d'un seul analyseur ! C'était un grand pas en avant, mais ce n'était pas la solution miracle annoncée. Il fallait toujours interpréter les données, ce qui signifiait (si vous aviez de la chance) un fichier de schéma et la transformation de cette structure arborescente maladroite en quelque chose que vous pouviez réellement utiliser. Vous vous retrouvez avec un cadre imposant de technologies XML.
Beaucoup d'entreprises se sont laissées convaincre, ont écrit des documents XML comme bon leur semblait et s'attendaient à ce que leurs problèmes de données disparaissent. Ce n'est pas ce qui s'est passé.
Cette réponse a commencé à être rationnelle et est naturellement devenue frustrée. Je vais essayer de résumer. Le XML a un modèle de données maladroit, il est souvent excessif et il a été survendu. Si vous avez besoin de données typées, hiérarchisées, générées et consommées par une machine, c'est génial ! Mais en général, ce n'est pas le cas et il n'est donc pas adapté à la tâche.
Cela dit, je préfère YAML .
