Discussion :

[eclesia]

Ce n'est qu'une facon de formater de la donnée.
De mon point de vue c'est un entre-deux pour xml et bxml (binary xml).

-xml est plus verbeux mais a une structure plus visible.
-json au dela de 3 niveaux de profondeur c'est illisible.
-bxml est encore plus compact et plus rapide a parser, mais n'est plus lisible tel quel.

Ce format n'a d'interet que parcequ'il est presque directement utilisable en javascript, en dehors du web, n'importe quel format binaire rempli bien mieux ce role.

wikipedia donne une bonne vision aussi :

Du point de vue du temps de traitement, évaluer une expression JSON en JavaScript est à peu de choses près aussi efficace que traiter son équivalent XML.
Du point de vue de la taille (stockage, vitesse de transmission…), une expression JSON est légèrement moins volumineuse ; la différence n’est cependant sensible que sur de gros volumes, ce qui est rarement le cas pour un usage courant.

bref c'est plus un effet de mode, rien de bien nouveau.

[teddyalbina]

Ce n'est qu'une facon de formater de la donnée.
De mon point de vue c'est un entre-deux pour xml et bxml (binary xml).

-xml est plus verbeux mais a une structure plus visible.
-json au dela de 3 niveaux de profondeur c'est illisible.
-bxml est encore plus compact et plus rapide a parser, mais n'est plus lisible tel quel.

Ce format n'a d'interet que parcequ'il est presque directement utilisable en javascript, en dehors du web, n'importe quel format binaire rempli bien mieux ce role.

wikipedia donne une bonne vision aussi :


bref c'est plus un effet de mode, rien de bien nouveau.

En effet YAML pose problème dès qu'il s'agit de structure un peu complexe ça devient imbuvable. A l'époque ou je faisais beaucoup de perl nous avions aussi des problème lors de serialisaiton/deserialisation de gros objets.

[pfeuh]

Salut,

-json au dela de 3 niveaux de profondeur c'est illisible.

Le xml au kilomètre sans retours chariot, est illisible aussi. xml ou json, généré humainement c'est très lisible. Généré par du code, ils ne sont pas plus lisibles l'un que l'autre. De mon point de vue, json est simplement une implémentation de dictionnaire (comme celui de python) dans javascript. Par contre, le fait qu'il y ait une implémentation pour de nombreux langages est intéressant.

A+

Pfeuh

[boly38]

Je trouve que la comparaison a du sens,
et trouve très pertinent le parrallèle entre un langage fortement typé avec xml, en opposition au JavaScript avec JSON.

Personnellement, pour les échanges Web ou M2M, je pense aussi que JSON va s'imposer nettement face au XML
car le JSON joue sont rôle de conteneur de manière absolue : vocabulaire limité au minimum requis.
Par contre, pour la configuration d'application lourde (graphique), la représentation de modèles, le XML peut amha
conserver une bonne place.

Pour des échanges de message, le contrôle des données portées par les réseaux doit toujours idéalement être fort (sécurité oblige).
Dans ce contexte, toute la question se porte finalement sur la différence : les meta-informations.
Aussi si les contrôles sont fortement portés par les acteurs des échanges (clients, serveurs),
il devient peut-être moins intéressant de faire porter des informations de contrôle/typage par le flux lui même
(car elle-même peuvent être faussées?).
Je ne pense pas forcément que le XML et sa DTD par exemple suffisent à améliorer sensiblement ces problématiques.
Ou alors la question de contrôle des données n'est pas une priorité. Dans ces deux cas, le JSON sera donc privilégié.

En dehors de la problématique de sécurité, c'est vrai que l'aspect "simple" du JSON par rapport au XML
permet son adoption rapide à un panel plus large.
Sur Internet, les acteurs qui ne sont pas du métier de l'informatique (qui sont certainement plus nombreux)
vont certainement adopter le format le plus simple.

[berceker united]

Bonjour,

Comme pour Pignoufy, je découvre JSON ici. Par contre, cette article me fait rappeler à un précédent sujet concernant l'utilisation inadapté/abusif du XML. Pensez-vous que JSON permet justement de réajuster l'utilisation du XML ?

[xelab]

Bonjour,

Comme pour Pignoufy, je découvre JSON ici. Par contre, cette article me fait rappeler à un précédent sujet concernant l'utilisation inadapté/abusif du XML. Pensez-vous que JSON permet justement de réajuster l'utilisation du XML ?

Pour ce qui est des échanges AJAX en tout cas, ça simplifie les choses. En PHP par exemple, on utilise json_encode et json_decode et hop on a nos objets/tableaux prêts pour le javascript côté client (où on utilisera JSON.parse par exemple) ou pour le traitement en php côté serveur.

[stundman]

Moi aussi je pense que ça n'a pas la même utilisation.

Le JSON va très bien pour faire de l'AJAX où les échanges serveur/client doivent être limités en taille. Il est donc très bien pour le développement d'applications d'échange de données. C'est aussi surtout un langage de tâche de fond, et incompréhensible si on n'est pas averti.

Le XML est pour moi le standard qu'il faut continuer d'utiliser. Il est lu par les applications de bureau (Excel, Calc d'OpenOffice), on peut facilement comprendre la structure et le contenu, il est lisible par les navigateurs, on peut aussi l'interfacer avec des feuilles de style XSL pour en faire une page web. Il possède des librairies capables de développer sur tous les langages facilement, et de plus en plus d'applications de traitement de données l'utilisent comme format d'entrée.

Et sinon, il y a YAML qui lui aussi se positionne entre les deux. Mais comme il est n'est pas utilisé par le web, on l'oublie...

[robynico]

Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !

[zeyr2mejetrem]

Si tous les web-services Soap étaient migrés vers du Restful - Json, l'on pourrait fermer une centrale nucléaire rien qu'en France !

Si tous les nains de jardin du monde se donnaient la main, les brouettes tomberaient sur le côté.

Sérieusement, je pense qu'aucun des formats n'est mauvais en soi. L'implémentation qui en est faite dans un contexte donné peut l'être.

[selenith]

Ayant pas mal utilisé les deux, je ne peux que confirmer ce qui a été déjà été dit : utilisé JSON plutôt que XML, ou l'inverse, dépend de ce qu'on a besoin et du contexte dans lequel on se trouve.

Par contre pour ceux qui veulent vraiment de la légèreté a l'extrême il existe un autre format inspiré du XML mais linéaire dans l'écriture et dans la conversion: SimBa.

On y perd la possibilité d'arborescence mais on y gagne en efficacité de traitement.

[popo]

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 !

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.

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>

OK, c'est pas très lisible mais je serais curieux de voir ce que ça donnerai en JSON. Pas sur que ce soit plus lisible !

[sekaijin]

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>

pour moi les deux on leur avantage et les deux on des domaines d'usage de prédilection.

Mais cela n'empêche pas de se poser la question du choix
car contrairement à ce qui a été dit JSON est lui aussi tout comme XML un format validable et instrumentable.

on a donc an JSON des capacités comparable schémas RPC WS etc.

ce qui les différencie profondément c'est l'outillage JSON plus jeune est moins bien outillé et surtout pas complètement normalisé pour beaucoup de chose.

reste donc à savoir ce que l'on veut en faire. si je prends quelques exemple ou le réflexe du développer java sera de choisir XML se poser la question peut ouvrir des horizons.

par exemple je croise souvent dans des appli java des mécanisme de sérialisation xml d'objet soit pour se les échanger soit pour les conserver dans des fichiers.
cela demande un sérialiseur et un parser qui accepte un schéma et c'est tout chose qu'on a à l'identique avec JSON
oui la techno sur se point est nouvelle mais elle offre des avantage non négligeable à surveiller donc.

autre exemple que j'ai croisé récemment des fichier de conf dans une appli C++ qui étaient autre fois en xml et aujourd'hui en Json. avantage léger facile à lire et à éditer structuré évolutif

maintenant je dois reconnaître à xml sa maturité et dans de très nombreux cas Il a fait ses preuves.
et je l'utilise énormément.

Je pense que leurs domaines de prédilection sont distinct mais il y a des zone de recouvrement.

les comparer et une bonne chose et continuer à le faire aussi.

J'espère que JSON gardera son approche très pragmatique.

A+JYT