meilleur rapport signal / bruit (moins d’octets perdus)
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
pas de différentiation entre attribut et valeur du nœud
Je ne comprends pas ce que tu veux dire.
encodage fixé par la norme
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
types de base existants dans le langage (liste, flottants, chaînes), faisant partie de la norme, là où XML n’a que des chaînes
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
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.
Le XML (comme tout format texte avec syntaxe répétitive) est très compressible, rendant l'argument obsolète. Tous les formats ou protocoles qui sont basés sur XML le compressent dans l'usage "normal" (hors débuggage où on désactivera la compression temporairement).
Je ne comprends pas ce que tu veux dire.
Si c'est pour de l'échange de fichier, le fichier XML définit simplement son codage dans sa déclaration. Ensuite le décodage est quand même un truc de base sur tous les systèmes. La seule problématique est lorsqu'un format de fichier ne déclare pas le codage donc il faut faire de la détection (ce qui n'est pas du 100% de réussite). Mais comme XML le fait, y a pas de problème ici.
En plus dans les faits, très souvent les sous-formats vont imposer un codage unique (souvent UTF-8). C'est le cas par exemple de XMPP.
Si tu fais du XML bête et méchant, sans schéma, oui il n'y a pas vraiment de types. Mais un format XML est fait pour être défini (en fait XML en soi est un format générique pour faire des formats spécifiques!), par exemple dans un schéma XML et là tu as tous les types que tu veux.
En outre, là où XML va avoir une étape de validation générique au niveau de ton parseur (que tu n'as donc en général pas à implémenter dans le code; en utilisant une bibliothèque XML externe, on se contente de fournir le schéma et la validation est faite pour nous), tu dois en général implémenter de la validation spécifique pour un format json.
Sans compter la reprise sur erreur: comme XML a une étape de validation du schéma, il est capable d'ignorer tout erreur de contenu (mauvais type, attributs inconnus, etc.), mais en le prenant en compte, avec par exemple simplement un avertissement dans le programme qu'il y a une corruption possible du fichier. En très peu de ligne (encore une fois, en se reposant sur une bibliothèque générique), on va définir de la gestion d'erreur précise pour divers cas et on ne sortira en erreur complète que sur les problèmes majeurs. C'est même la base de certains sous-formats de XML, par exemple XMPP encore, qui est extensible par nature, a certaines caractéristiques obligatoires mais peut aussi accueillir des extensions (et un client/serveur peut les ignorer s'il ne les prend pas en charge mais sans jamais casser la connexion ou le transfert fiable et complet des données).
Json pourrait faire tout cela bien sûr, mais nécessite beaucoup de code spécifique et sera donc bien plus prompt aux erreurs de programmation. Surtout en gestion d'erreur, on sait tous que c'est exactement le genre de trucs chiants que beaucoup vont laisser "pour plus tard"; et le manque dans le code ne se voit pas pendant longtemps — puisque logiquement en général le contenu utilisé est valide — jusqu'au jour où on tombe sur un bout de données corrompu et là, le programme risque de vraiment mal le prendre!
Ensuite XML est clairement beaucoup plus lourd à mettre en place et ce n'est pas à utiliser selon moi pour des usages simples. Genre effectivement pour une API web, on va peut-être éviter de la compression (quoique ça dépend; même pour du json, si l'API est faite pour transporter pas mal de données, cela peut être rentable de compresser). De même pour plein de petits formats très courts (typiquement dans une API web, on peut considérer que chaque réponse à une fonction a potentiellement un format différent), on veut peut-être pas écrire plein de mini-schémas XML. Ce serait vite ennuyeux.
Dans plein de cas, json est bien plus léger, simple et flexible. Donc c'est plus agréable pour tous ces petits usages simples. Par contre dans le cas de la création d'un format long et complexe, beaucoup utilisé et structuré, je ne choisirai probablement jamais json. C'est juste le moyen idéal pour se retrouver avec des fichiers invalides sans même s'en rendre compte pendant des semaines (jusqu'au jour où notre programme a besoin de parser ce bout du fichier et saute à notre figure).
Quant à des fichiers de conf (si on prévoit édition par un humain), je n'utiliserais ni json ni XML, mais un format simple "attribut: valeur" ou "attribut = valeur", type fichiers INI. Parce que quand on parle d'édition et lisibilité possible par un humain, je suis désolé mais ni json ni XML ne sont de bons choix. Typiquement c'est très facile de casser un fichier de l'un ou l'autre format (classique: oublier le tag fermant en XML ou le crochet fermant en json).
Par contre lisibilité par un développeur (pour débugguer par exemple), je trouve les 2 aussi lisibles du moment qu'ils indentés pour faciliter le débuggage (et les 2 aussi illisibles s'ils sont pas indentés ou sans retour à la ligne).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]