JSON vs XML « The definitive answer » (lol)

(le titre met JSON avant XML, pour l’ordre alphabétique seulement)

Ma compréhension personnelle du débat JSON vs XML, seulement dans un contexte où le choix n’est pas imposé par ce qui est pré‑existant.

Sur la détestation d’un bord et de l’autre

(pour ceux/celles qui, littéralement, disent détester l’un ou l’autre)

Les inconditionnels de JSON, pourraient avoir des boutons rien que de penser que les pages web sont écrites dans un langage de balisage. Ont–ils/elles déjà essayé d’imagier le résultat du remplacement de, disons XHTML (qui est un dialecte XML), par JSON ?

Les inconditionnels d’XML pourraient remarquer que EXI a été inventé parce que la question du poids d’une sérialisation est une considération qui parfois pèse, et que EXI est moins bien implanté que le XML texte classique.

Sur la nature plus native de JSON

XML est un littéral natif pour au moins deux langages informatiques courants : le VisualBasic moderne (pas le traditionnel) et Scala.

Même quand XML n’est pas un littéral natif, il est facilement un littéral, indirectement, par l’intermédiaire d’une chaîne de caractère, qui est un littérale dans pratiquement tous les langages. Ceci dit, ce dernier argument vaut autant pour JSON.

JSON n’est natif qu’à la réception, pas à l’émission. Et dans un contexte JavaScript, la sérialisation la plus naturelle est même celle des langages à balisages, HTML ou XHTML. La sérialisation native, dépend en pratique de la direction : émission ou réception, et il ne pourrait être dit natif, qu’en réception.

Même en réception, JSON n’est, ou ne devrait pas être pris pour natif, sauf si l’on a une complète confiance dans la source (parce exemple qu’elle est son propre serveur). En effet, le caractère natif en réception, est le résultat d’un interprétation directe des données reçues comme étant un source JavaScript, ce qu’il est impensable de laisser faire avec une source que l’on ne maitrise pas. Dans ce sens, les langages disposant de littéraux XML, supportent XML plus nativement, que JavaScript ne dispose d’un support natif pour JSON, car les littéraux XML ne présentent pas de risque d’injection d’instructions dans le programme.

Sur la voie évidente, de l’allégement de l’écriture prise par JSON

SGML était compliqué et inconstant, parce qu’il voulait économiser le plus de caractères possibles; une inconstance à laquelle il fallut remédier en inventant XML, plus verbeux, mais plus constant.

Il n’est pas impossible que se restreindre à JSON, aboutisse à la répétition de la même histoire, s’il arrive de vouloir faire passer dans le domaine de JSON, ce qui est du domaine d’XML.

Sur le défaut d’XML d’être trop verbeux

En pratique, la question de la verbosité d’XML est un faux problème, parce que les flux JSON ou XML, ne sont pas principalement lus et édités par des gens, autant que le sont par exemple les mails. La verbosité d’XML est en pratique une redondance, et la redondance est très bien prise en charge par tous les formats de compression existants (c’est même dans leur nature), ce qui implique que les formats XML ont un meilleur ratio de compression que les formats JSON, et que après compression, la différence de poids entre des données XML et des données JSON et nettement moins importante qu’avec la forme plein‑texte.

Aucun d’XML ou JSON n’est universel

XML et JSON on tout deux des limites propres. Il est important de savoir s’arrêter à temps pour ne pas pousser en force l’un ou l’autre là où il n’est pas le plus approprié.

Si l’on veut exprimer en JSON, ce que pour quoi XML a été fait, on réinvente XML; Il est sûrement préférable d’utiliser XML dans ce cas. Par exemple, pour exprimer du contenu mixte, on devra utiliser un tableau d’objets, qui auront au moins deux champs, un pour le contenu et un pour la classification (et on devra même le faire pour le texte qui en XML n’aurait pas été enveloppé dans un élément en particulier et qui aurait existé comme simple nœud‑texte), ce qui est équivalent à réinventé les éléments XML, le seul rappel du nom de l’élément dans la balise de fermeture en moins.

Exemple minimaliste :



(un exemple amusant avec lequel la forme JSON est d’ailleurs plus lourde que la forme XML)

Réciproquement, si on raccourci les noms d’éléments XML et/ou utilise des attributs à la place d’éléments, dans le seul espoir d’économiser la bande passante sur un canal de transmission, il est sûrement préférable d’utiliser JSON dans ce cas.

Deux articles éclairés

Heureusement, il n’y pas que des positions idolâtres sur cette question. Voici deux articles de « blog », que j’ai apprécié pour leur sagesse et bonne mise en balance des réalités pratiques et sans parti‑pris par principe.

• The JSON vs XML debate begins in earnest (msdn.com). Décembre 2006.
• Web Services: JSON vs. XML (digitalbazaar.com). Novembre 2010.

Déplacé de Informatique, Réseaux et Internet à Standards Informatiques & Numériques.

XPath 3.1 ajoute le support pour les tableaux associatifs, et cet ajout a été fait pour simplifier l’interopérabilité avec JSON. Aussi, XSLT 3.0 peut recevoir en entrée, un document JSON au lieu d’un document XML, via la fonction json-to-xml(). Pour le besoin de cette dernière traduction, le W3C a défini un espace de nom, http://www.w3.org/2013/XSL/json.

Il existe une proposition de schéma XML pour représenter les données JSON (qui ont un schéma simple implicite) : JSON XML Schema — JXML (calldei.com).

Mais ce n’est pas un standard, c’est une proposition.