Discussion :

[Hinault Romaric]

Jusqu'où ira l'essor de JSON ?
Le nouveau format d'échange de données est-il en train de s'imposer face au XML ?

Le XML (eXtensible Markup Language) avait été largement adopté en tant que format d'échange de données entre différents systèmes, plates-formes et organisations.

Depuis la sortie de JSON (JavaScript Object Notation), ce format d'échange plus simple est devenu populaire à tel point que les débats JSON vs XML se multiplient depuis quelques semaines.

Comme dans ce billet de blog de Karsten Januszewski, célèbre développeur ingénieur de Microsoft, qui ne se demande pas si, mais quand JSON l'emportera sur le XML.

Karsten Januszewski constate, à l'occasion d'une rétrospective sur les différents choix pris dans le cadre du développement d'un service de prototypage, que JSON a eu une ascension rapide, au vu par exemple de l'augmentation du pourcentage d'API et de services prenant en charge JSON par rapport au XML.

Pour lui, cette popularité de JSON est dûe à la légèreté et à la simplicité du format par rapport au format XML, mais surtout à la nature non typée des flux JSON qui sont parfaitement adaptés au JavaScript.

La nature non typée des flux JSON cadrerait avec la façon dont le Web lui-même fonctionne. Le Web n'aime pas les schémas, il n'aime pas que les choses soient rigides ou trop structurées estime Karsten Januszewski.

Néanmoins, il ne rejette pas le format XML. Au contraire, il trouve que le format fonctionne parfaitement avec les langages à typages forts ou pour la représentation des objets graphiques. Pour illustrer ses propos, Karsten Januszewski s'appuie par exemple sur les couples Java/XML dans Android et .NET/XAML dans Windows Phone pour la représentation des interfaces utilisateurs.

Mais la récente prise en charge de JSON dans le Framework .NET 4.0, qui vient résoudre le problème de sérialisation sur les serveurs - véritable casse-tête des développeurs - montre clairement pour Karsten Januszewski que JSON est en plein essor.

Source : « L'essor de JSON », billet de Karsten Januszewski

Et vous ?

Que pensez-vous de cet opinion Karsten Januszewski sur la simplicité de JSON ?

Comparer JSON et XML a-t-il un sens ? Les deux formats vous paraissent-ils complémentaires ou l'un s'imposera-t-il face à l'autre ?

[salve34]

Comparer JSON et XML a-t-il un sens ?

Bien-sûr. Cela permet le débat et donc l'amélioration des technologies.

Les deux formats vous paraissent-ils complémentaires ou l'un s'imposera-t-il face à l'autre ?

Pour moi ils sont complémentaires.
-xml a comme défaut qu'il est trop verbeux mais c'est aussi sont gros avantage
-json est moins verbeux donc plus synthétique et donc plus rapide mais il est aussi beaucoup plus laxiste
donc cela permet de laisser le choix (si le webservice n'est pas développé par un tier bien-sûr )

[elmcherqui]

Je suis tous a fait daccord avec lui , avec une taille de données equivalentes le XML est beaucoup plus verbeux que le JSON et c'est le seul point fort a mon avis pour JSON contre un parsing et affectation beaucoup plus rapide pour XML car pas la peine de tester le type

[Grimly_old]

Le XML et le JSON ne répondent pas tout à fait au même besoin à mon avis.

Le JSON est de la pure information sans aucune garantie sur le contenu ou le format. Il est le format idéal pour la communication entre deux outils issus d'un même projet/groupe.
Le XML porte avec l'information un contrat qu'il respecte que ce soit un DTD, un XML Schema ou autre. C'est le seul format des deux qui a une forte composante de méta-donnée. Il est le format idéal d'un service public (SOAP par exemple se base dessus)

[Faiche]

C'est la première fois que je ne vois que des réponses intelligentes à un sujet bancal, c'est cool .

Vous me retirez les mots de la bouche : XML et JSON c'est pas la même utilisation.

[Tententai]

D'accord avec les réponses d'avant.
Je rajouterais que JSON a l'avantage (ou l'inconvénient) d'être plus laxiste au niveau des accès AJAX cross-domain.

Le must serait de continuer à utiliser les 2, et que les principaux frameworks et outils de développements offrent des classes/modules facilitant le parsing des 2 formats.

[zeyr2mejetrem]

Comparer XML et JSON est, selon moi, complètement stupide

Cela me fait penser aux débats abscons et orientés qu'on voit (trop) souvent sur les forums.
Par exemple: "Quel est le meilleur langage, le seul, le vrai ?"
Ou: "Quel est la bonne architecture qui fonctionne à tout les coups pour coder son application ?"

JSON est un bon format de transport quand on veut des transmissions rapides sur des données faiblement typées.
Par contre si on doit transporter des objets complexes et fortement typés avec un contrôle de validation ....

L'efficacité d'un outil se mesure à son usage dans un environnement donné.

[marts]

A mon avis, rien de ce que permet le XML n'est impossible avec JSON.

Rien n'empêche d'intégrer des meta-données dans un flux JSON, par exemple pour indiquer le type de certaines données. Après tout est question de conventions entre les communicants, mais tout est possible.

A l'inverse, le XML n'a pas la possibilité d'être aussi léger que JSON.

[Uther]

Rien n'empêche d'intégrer des meta-données dans un flux JSON, par exemple pour indiquer le type de certaines données. Après tout est question de conventions entre les communicants, mais tout est possible.

En effet c'est possible, mais à ce moment là, c'est JSON qui va devenir bien plus lourd que XML.

[DrHelmut]

Bien qu'étant un gros noob n'ayant pas encore eu l'occasion d'implémenter du JSON sur un projet, je suis plutôt d'accord avec celles et ceux qui estiment qu'on ne peut pas vraiment les comparer et qu'ils ont chacun leur champ d'application.

Je trouve que sur le papier JSON a deux gros défaults :
- pas lisible facilement par un humain, là ou une structure xml arborescente permet facilement une analyze de flux par exemple. (Et un bon soft sait lire un xml de façon arborescente sans avoir à écrire des tabulations ni des retours chariots dans le fichier ^^)
- pas de validation du flux ni de typage des données...

Après, il est clair que pour les webservices, ça ne peut être que plus performant que via SOAP, mais offre-t-il autant de possibilité ?
Quid d'un envoie/réception de flux binaire avec JSON ??

Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !

[=JBO=]

Même si c'est parfois un peu lourd, ce qui est bien avec SOAP c'est que le wsdl est auto-suffisant ! J'ai l'impression qu'avec JSON il n'y a pas moyen de connaitre la signature exacte de la méthode apellée, et ça me choque !

Tu ne peux pas comparer XML et SOAP car le niveau d'abstraction est bien différent...
Pour la même raison, la comparaison entre JSON et SOAP n'est pas possible.

JSON est un substrat pour des protocoles alternatifs:

• JSON-RPC, à comparer avec XML-RPC
  http://en.wikipedia.org/wiki/JSON-RPC

• SOAPjr ou JSON-WSP, à comparer avec SOAP
  http://en.wikipedia.org/wiki/SOAPjr
  http://en.wikipedia.org/wiki/Jsonwsp

[thelvin]

A mon avis, rien de ce que permet le XML n'est impossible avec JSON.

Ce n'est pas une question d'avis, tu te trompes.

- JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)

- JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.

On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.

Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.

Heu le human readable de XML ....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
<PID>
  <PID.1>1</PID.1>
  <PID.3>
     <CX.1>PATID1234</CX.1>
     <CX.2>5</CX.2>
     <CX.3>M11</CX.3>
     <CX.4><HD.1>ADT1</HD.1></CX.4>

     <CX.5>MR</CX.5>
     <CX.6><HD.1>MCM</HD.1></CX.6>
   </PID.3>

On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)

[sekaijin]

Personnellement, je ne connais pas non plus JSON mais quand je lis ce que me renvoie Google sur le sujet, je remarque un sérieux désavantage par rapport à XML : Il ne convient pas pour des ressource de taille importante !

heu 2Go de données dans un fichier JSON ...
T'es sur de ce que tu avance ?
Je ne connais aucune limitation en taille à JSON
la seule que je connaisse n'est pas du à JSON outils tout comme avec XML si tu utilise DOM il te faut mettre les objets en mémoire et tu en deviens dépendant. Par contre on ne trouve quasiment pas de parser type SAX (de xml) c'est à dire au fil de l'eau. mais aucun limitation dans le format si ce n'est la taille des supports.

Et puis si JSON devient plus populaire que XML, j'aimerai pas être à la place de microsoft. Pour rappel, les fichiers de microsoft office sont en réalité des fichiers XML. En renommant un fichier docx en zip et en regardant à l'intérieur de l'archive on s'en aperçoit très bien.

je ne vois pas en quoi cela remets en cause ce choix XML est un bon choix et même si JSON devient populaire il le restera.

- JSON ne peut pas gérer d'organisation en flux, comme le HTML, le DocBook, et certains besoins d'Atom et RSS (qui ne sont jamais utilisés d'accord, mais c'est simplement parce qu'aucun informaticien influençant ces utilsiations ne se donne la peine de comprendre.)

Là j'avoue ne pas comprendre. je ne vois aucune raison qui empêche d'utiliser JSON à la place de ces flux c'est même se que je fais je n'utilise plus HTML mais JSON est mon moteur de rendu lit des flux JSON bien plus concis et léger.

- JSON n'est pas extensible, sauf à obliger le concepteur des formats de données à prévoir pour extension future, ce qui n'est pas impossible, juste rendu trop compliqué par le fait qu'il ne sert absolument pas à ça.

Là encore je ne comprends pas. XML c'est des symboles <> = " organisé et des string rien de plus XML n'est pas plus extensible que JSON. si tu entant par extensible qu'on peut mettre dans un XML la balise de son choix, il en va de même en JSON ou tu peux ajouter le membre de ton choix. si tu entends par là qu'un peut inclure dans XML d'autre XML c'est pareil en JSON. la seule différence entre les deux c'est qu'en XML tu a une norme (deux en fait) pour typer plus fortement ton XML.

On pourrait aussi ajouter que JSON n'a pas de truc comme les entity references ni les character references ni les valeurs par défaut, mais bon, c'est pas des trucs que j'aime beaucoup personnellement.

Les entity sont un pi aller créer pour XML à fin de pouvoir inclure les éléments non supporté par le flux. le seul qu'on ne peut pas utiliser en JSON est " pour cela on a été obligé d'introduire \ du coup pour mettre \ il faut mettre \\ à quoi servent les entity dans un pareil cas ?
pour les référence c'est effectivement un choix de JSON de ne pas mettre utiliser les références JS dans un flux
mais XML fait de même. je ne peux pas écrire

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<user>
  <name>Dupond</name>
  <id>user.name</id>
</user>

pour désigner dans la valeur de mon id l'élément name de user user.name ou tout autre forme n'est qu'une chaîne de caractère et non une référence. avec XML je vais pouvoir créer une string qui est le chemin vers l'élément de mon choix.

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<user>
  <name>Dupond</name>
  <id>/user/name</id>
</user>

XML n'interprétera l'élément id que comme une chaîne. il faudra ajouter une passe supplémentaire d'interprétation XPATH pour résoudre les références et obtenir Dupond dans le champs id. avec JSON on est exactement dans la même situation.

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
"user":{
  "name" :"Dupond",
  "id":"user.name"
}

JSON fera de l'élément id une string contenant le chemin et il faudra une passe d'interprétation de cette chaîne pour obtenir Dupond
la différence entre JSON est XML sur ce point est encore une fois que la façon de décrire le chemin est normalisé. en JSON on utilise soit la notation pointé de javascript soit les sélecteurs CSS mais rien de normalisé.

Enfin, bien que ça ne soit pas infaisable sur le principe, par nature JSON est un très mauvais candidat pour des choses comme le XML Transform et le XML Process. Pas assez expressif, pas assez extensible, matchers et selectors trop naïfs.
On va me dire que ce n'est pas indispensable, mais les cas ne manquent pas où c'est mieux qu'autre chose. XML le peut, JSON ne le peut pas.

La encore tu te trompe lourdement. XML ne permet rien de plus que JSON Les outils XML sont disponible et normalisé ceux de JSON non. encore une fois XML n'est que format autour de lui gravitent des normes et des outils les implémentant. pour XSLT par exemple rien de plus simple à faire en JSON t fais un JSON qui définit le pattern en utilisant la syntaxe sélecteurs css3 et le résultat à obtenir en JSON le moteur s'écrit en quelques lignes de JS.
Mas question est simplement pourquoi le faire lorsqu'avec XML on a déjà les outils. il faut savoir être pragmatique et évaluer l'usage avant le format de support. je pense que des moteurs de transformations arriverons dans le monde JSON que si dans l'ensembles des point à évaluer qui font qu'on choisit se format seul ou persque la transformation est absente. si dans ton dev tu fait deux colonne et pour chaque critères tu mets des points à XML ou a JSON et qu'au final tu as 80% pour JSON et qu'il te manque une fonctionnalité dans JSON tu va l'implémenter. et si tu obtients 80 en faveur de XML et qu'il ne manque une fonctionnalité supporté par JSON tu vas aussi l'implémenter en XML. ça ne change rien.

On n'a pas dit que XML a le pouvoir d'obliger à faire du lisible, les gens suffisamment déterminés à produire de l'illisible.

Simplement qu'il y encourage. (Encore que la mode d'avoir soixante namespaces différents dans un même document n'aille pas vraiment en ce sens, j'en conviens.)

C'était une boutade pour l'argument sur la lisibilité. pour moi XML dès sa définition à voulu pousser vers le "Human Readable" mais nous sommes tous face à des choix et il arrive souvent que le meilleur choix même en XML ne soit pas "Human Readble". face à ça JSON à pour sa part cherché à sa naissance à être "Machine Readable" mais transportable en string. et nous sommes ainsi fait lorsque nous choisissons des nom nous les choisissons de préférence lisible par nous. du coup JSON à parcouru le chemin inverse.
Au final je dis que mettre dans la balance lorsqu'on doit choisir entre JSON et XML le fait que XML est "Human Readable" je réponds que ce n'est pas recevable.

pour moi il existe des point bien plus fondamentaux dans les différence entre XML et JSON si je dois mixer deux structures de données en XML je peux utiliser les namespaces et la norme comme les outils me garantissent une claire distinction. je n'ai rien de tel en JSON ou par définition de base tout est faiblement typé. se sera à moi développeur de garantir cette distinction.
ce n'est pas impossible ce n'est pas difficile est juste à faire.
il existe des contextes d'utilisation où la distinction entre attribut et élément est un plus important. (je ne connais pas de cas où on ne peut s'en passer
uniquement des cas ou ça rends les chose beaucoup plus claires et faciles) dans ces cas là XML m'offre cette distinction alors que JSON non. là encore ce n'est pas insurmontable, ce n'est pas difficile mais c'est à moi développer de le faire.

A+JYT

[barmic]

Personnellement j'utilise XML quotidiennement et quasiment pas JSON.

De ce que j'ai l'impression JSON s'utilise pour un nombre plus limité de cas qu'XML. XML on l'utilise pour des formats de fichier (OpenDocument, SVG, OOXML par exemple), des configurations de logiciels (maven, ant, etc), des configurations internes des applications (java et les descripteurs) et pour la sérialisation (et donc la communication réseau).

D'après ce que j'ai pu en voir JSON ne s'utilise que pour ce dernier cas et il me semble bien mieux conçu pour ce cas d'utilisation : plus léger en terme de poids, mais aussi de traitement et conçu pour être traité au fil de l'eau.

Dans les autres cas d'utilisations d'XML, JSON ne me semble pas être une alternative pertinente surtout car il n'y a pas de possibilité de validation et le manque de métadonnées le rend moins lisible pour un humain.

[abriotde]

XML et JSON ont certes des domaines applications distinct mais aussi beaucoup plus de domaine commun... à l'avantage selon moi de JSON. C'est à dire que dans beaucoup de cas on peut utiliser l'un comme l'autre. La différence principal est comme dit plus haut que l'XML est plus verbeux que JSON. Il manque encore à JSON l'équivalent des DTD et XMLShema.

La lisibilité est meilleur en JSON qu'en XML lorsqu'il il y a peu de donnés ou des données simple à l'inverse lorsque la structure de donnée est très complexe et le fichier volumineux, on préférera lire du xml (on sait ce que ferme une balise (un "</humain>" est plus explicite qu'un "}")). Alors certes le xml se compresse mais on ralentit encore le traitement du fichier.
Un petit exemple avec de la cartographie:
XML
<point><abscice>10.123</abscice><ordonnee>1.123</ordonnee></point> x10000
=> long à parser, lourd, cela fini même par devenir difficile à lire (on arrive même plus à ouvrir le fichier)
JSON
[10.123, 1.123], x10000.
=> lisible, léger, rapide à parser

Pour faire maths : Les domaines d'applications d'XML et JSON sont des ensemble dont l'intersection n'est pas l'ensemble vide même s'il ne sont pas équivalent.

[zeyr2mejetrem]

La lisibilité est meilleur en JSON qu'en XML lorsqu'il il y a peu de donnés ou des données simple à l'inverse lorsque la structure de donnée est très complexe et le fichier volumineux, on préférera lire du xml (on sait ce que ferme une balise (un "</humain>" est plus explicite qu'un "}")). Alors certes le xml se compresse mais on ralentit encore le traitement du fichier.
Un petit exemple avec de la cartographie:
XML
<point><abscice>10.123</abscice><ordonnee>1.123</ordonnee></point> x10000
=> long à parser, lourd, cela fini même par devenir difficile à lire (on arrive même plus à ouvrir le fichier)
JSON
[10.123, 1.123], x10000.
=> lisible, léger, rapide à parser

Pour faire maths : Les domaines d'applications d'XML et JSON sont des ensemble dont l'intersection n'est pas l'ensemble vide même s'il ne sont pas équivalent.

Je suis désolé de contredire mais l'équivalent JSON de ton XML serait
{"point":{"abscice":10.123,"ordonnee":1.123}} car sinon tu ne transporte pas l'info concernant l'ordre ou la hiérarchie de tes données.
Si ton ordre (entre abcisse et ordonnée) et ta hiérarchie sont implicites en XML tu peux écrire aussi
<p>10.123,1.123</p>, rien ne l'en empêche.

D'un ordre général XML est verbeux par rapport à JSON car il transporte les méta-données et JSON non.
Un objet complet bien écrit en JSON est presque aussi verbeux qu'en XML sauf qu'il ne contient pas de DTD.

[Pignoufy]

Bonjour à tous,

Je ne connaissais pas JSON jusqu'à aujourd'hui (c'est bien les discussions ). Après un vite coup d'oeil sur Wikipédia, je trouve que la structure XML est humainement plus compréhensible qu'une structure JSON (notamment pour des "non développeurs").

Qu'en est-il des DTD ou XSD ? Y'a-t-il des équivalents en JSON ?
Si ce n'est pas le cas, voici un gros avantage du format XML...

Autre question, j'utilise XML dans mes applications (non Web, je précise) alors que JSON semble être très utilisé (seulement ?) pour ce genre d'appli... Je ne vois donc pas la plus-value de ce format dans ce cas...

[teddyalbina]

Bonjour à tous,

Je ne connaissais pas JSON jusqu'à aujourd'hui (c'est bien les discussions ). Après un vite coup d'oeil sur Wikipédia, je trouve que la structure XML est humainement plus compréhensible qu'une structure JSON (notamment pour des "non développeurs").

Qu'en est-il des DTD ou XSD ? Y'a-t-il des équivalents en JSON ?
Si ce n'est pas le cas, voici un gros avantage du format XML...

Autre question, j'utilise XML dans mes applications (non Web, je précise) alors que JSON semble être très utilisé (seulement ?) pour ce genre d'appli... Je ne vois donc pas la plus-value de ce format dans ce cas...

Concrètement JSON n'est que YAML utilisé depuis des lustres (Perl par exemple possède de fabuleuses bibliothèque pour cela). Donc tu peux utiliser YAML Heu Json (c'est à la mode) pour serialiser n'importe quel objet. Concrètement YAML résoud le problème du à la sérialisation binaire et permet donc l'interopérabilité.

[beegees]

Je développe depuis deux ou trois ans en utilisant la technologie AJAX, je dois dire que json m'a déjà beaucoup aidé.

XML ne sert (pour ma part) à pas grand chose

beegees

[authchir]

<point><abscice>10.123</abscice><ordonnee>1.123</ordonnee></point> x10000

mais ton point peut être écrit en xml plus simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<point absice="10.123" ordonnee="1.123" />

Ce qui nous donne, dans un gros fichier:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
<point absice="1" ordonnee="11" />
<point absice="2" ordonnee="22" />
<point absice="3" ordonnee="33" />
<point absice="4" ordonnee="44" />
<point absice="5" ordonnee="55" />
...
<point absice="999" ordonnee="9999" />

ce qui, à mon avis, est très lisible tout en n'étant pas si lourd.