Hello!

Inspiré(e) de prendre part à la discussion ? Ou de poser une question ou demander de l’aide ?

Alors bienvenues dans les grands sujets des forums de La Bulle : m’inscrire.

Cette partie du forum n’est pas compatible avec les bloqueurs publicitaires

Félicitations à vous, de préférer les accès payants plutôt que la gratuité par la publicité, c’est honnorable et cohérent de votre part. Malheureusement, l’accès payant par micropaiement (qui serait d’environ 1 cent pour 20 pages consultées) n’est pour l’instant pas encore mis en place, et l’accès gratuit sans publicité, est réservé aux membres actif(ve)s du forum. En attendant, si vous souhaitez poursuivre votre visite chez nous, vous pouvez ajouter le site à votre liste blanche, ou encore mieux, désactiver le bloqueur partout. Pour ajouter le site à votre liste blanche, pour Firefox (similaire pour les autres navigateurs), rendez‑vous en bas à gauche de la fenêtre de votre navigateur, et cliquez sur le menu comme dans l’exemple de l’image ci‑dessous, puis rechargez la page, en appuyant sur F5.

JSON vs XML « The definitive answer » (lol)
Auteur Message
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 15514
Mer 14 Aoû 2013 16:51
Message 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 :

Source XML : 

<document>Bla <element>et</element> bla.</document>


Source JSON : 

{ document: [ { text: "Bla " }, { element: "et" }, { text: " bla." } ] }

(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.


Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 15514
Mer 25 Oct 2017 11:05
Message Re: JSON vs XML « The definitive answer » (lol)

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 15514
Mer 25 Oct 2017 11:18
Message Re: JSON vs XML « The definitive answer » (lol)
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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet
Administrateur
Avatar de l’utilisateur
  • Genre : Télétubbie
  • Messages : 15514
Mar 12 Juin 2018 14:13
Message Re: JSON vs XML « The definitive answer » (lol)
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.

Image
Hibou57

« La perversion de la cité commence par la fraude des mots » [Platon]
Profil Site Internet