Discussion :

[Hinault Romaric]

XML fête ses 15 ans
que pensez-vous de l’avenir du format d’échange de données face à l’essor de JSON ?

XML (eXtensible Markup Language), le format d'échange de données entre différents systèmes et plateformes fête ses 15 ans cette semaine.

Lancé en février 1998 comme une recommandation du W3C, le langage de balisage extensible a été rapidement adopté pour l’échange des données sur le Web.

Jean Paoli, cocréateur de la spécification XML 1.0 et désormais responsable de division Microsoft Open Technologies, exprime, dans un billet de blog, sa satisfaction face au succès du standard. « Je n’aurais jamais imaginé il y a 15 ans que nous réussirions notre rêve de disposer d’un moyen d’échange libre des données entre différentes plateformes et désormais à travers divers dispositifs et le Cloud. Pour moi, cela a été le début de la révolution de l’ouverture », écrit Paoli.

Malgré ce succès, XML présente plusieurs défauts, surtout son caractère verbeux, le rendant trop lourd et peu adapté pour les échanges entre les dispositifs à ressources limitées comme les smartphones et les tablettes.

Des faiblesses qu’on ne trouve pas du côté du format JSON, qui est de plus en plus utilisé comme format d’échange de données par plusieurs organisations et dont la prise en charge est désormais effective dans la plupart des langages de programmation.

S’il est clair que le Web s’oriente beaucoup plus vers JSON, XML reste très pratique pour certains scénarios et « sa capacité unique de représenter des documents de façon homogène sera encore importante pour les 15 prochaines années », d’après Paoli.

Quoi qu'il en soit, en tant que développeurs, nous saisissons l’occasion pour souhaiter bon anniversaire à XML.



Source : Billet de blog de Jean Paoli


Et vous ?

Quel format utilisez-vous pour l'échange de données dans vos applications ?

Pensez-vous que l'avenir du XML soit menacé par l’essor de JSON ?

[thelvin]

Pour l'échange de données, c'est plutôt du JSON ou du protocol buffer dans les cas extrêmes.
XML me sert à représenter mes données de type documentaire, qui ont plus vocation à rester stockées là qu'à être échangées.

Je pense que XML n'a jamais été adapté pour les données simples, et que JSON aurait dû exister bien avant. Mais à l'époque, bien sûr, on avait pas le recul pour faire la différence. JSON sert pour la plupart des besoins, et XML pour ce que JSON ne peut pas faire.

[alex_vino]

et XML pour ce que JSON ne peut pas faire

Faut pas trop pousser le bouchon non plus... a cette vitesse tu va traiter XML de fardeau
XML bénéficie d'une excellente intégration avec les languages de programmation + frameworks, JSON beaucoup moins (ou parfois il faut payer tres cher pour des outils qui ne marchent pas toujours).
En parlant Web, Google (ainsi que ses concurrents) requiert des fichiers XML pour les sitemaps, Shopping, ... comme quoi.

Si tu dit que XML est meilleur pour le stockage alors je serais content de savoir quels sont tes arguments, parce que si tu dis que JSON est bien meilleur pour les échanges alors pourquoi devoir utiliser XML qui est plus gourmand en espace disque (pas top pour le stockage).

[thelvin]

XML bénéficie d'une excellente intégration avec les languages de programmation + frameworks, JSON beaucoup moins (ou parfois il faut payer tres cher pour des outils qui ne marchent pas toujours).

Ben, ça fait partie des choses que JSON ne peut pas faire. Your point?

En parlant Web, Google (ainsi que ses concurrents) requiert des fichiers XML pour les sitemaps, Shopping, ... comme quoi.

Ouais enfin le besoin d'extensivité ne pisse pas loin pour ces trucs-là. C'est du XML parce pour ce genre de trucs ça n'a pas d'importance, que JSON n'existait pas, et que le CSV maintient une culture d'incompétence crasse qui complique de mettre tout le monde d'accord.

Si tu dit que XML est meilleur pour le stockage alors je serais content de savoir quels sont tes arguments, parce que si tu dis que JSON est bien meilleur pour les échanges alors pourquoi devoir utiliser XML qui est plus gourmand en espace disque (pas top pour le stockage).

Pas pour "le stockage." Pour "des choses qui sont faites pour rester là sans bouger." Des documents, des pages, des données détaillées, organisées, et fortement extensibles.

JSON :
- est illisible dès qu'on met plus de cinq propriétés différentes, ou dès qu'il y a beaucoup de données d'un point de vue humain. Ce qui n'est pas un problème quand on communique entre applications, mais est un emmerdement de plus pour les données en fichier.
- n'est pas assez extensible.
- n'a pas de logique de flux, pourtant omniprésente dans les données avec mise en forme.
- n'a pas de technologie raisonnable de transformation, de mélange de formats, de validation a priori, et tout un tas de trucs qui sont généralement considérés lourds et peu utiles en XML, mais bien pratique pour des données statiques de niveau avancé.

[Uther]

Quel format utilisez-vous pour l'échange de données dans vos applications ?

XML si le fait que ça soit lisible peut-être utile. Binaire sinon.

Pensez-vous que l'avenir du XML soit menacé par l’essor de JSON ?

J'ai du mal a voir en quoi le JSON menacerait le XML. Les deux peuvent très bien vivre ensemble.

Personnellement je trouve JSON à l'image de son papa le JavaScript : pratique pour faire rapidement de petit truc mais une horreur des que les choses se compliquent.
Et quitte a faire quelque-chose d'illisible, je préfère un format binaire bien mieux optimisé, en taille et performance.

[Squisqui]

Le deux commentaires du dessus rassemble mon point de vue.
Par contre :

Malgré ce succès, XML présente plusieurs défauts, surtout son caractère verbeux, le rendant trop lourd et peu adapté pour les échanges entre les dispositifs à ressources limitées comme les smartphones et les tablettes.

C'est vrai que les PC, il y a 15ans, étaient beaucoup plus puissants. J'ose même pas imaginer les échanges sur Internet, à l'époque, de son "cousin" HTML.

[ulspider]

Si l'on regarde uniquement du point de vue des échanges de données, le JSON domine le XML. Plus concis, moins verbeux...

Mais avec le XML il faut aussi prendre en compte :

• XSL : Pour mettre en forme ou transformer un document XML. Bien pratique de pouvoir adapter à la voler un document qui ne correspond pas à une structure donnée.
• XSD : Permet de définir la structure d'un XML. Bien plus facile de valider un XML que des données contenus dans un JSON.
• XPath et XQuery : Du requêtage sur un ou des documents XML. Plus facile de récupérer des données dans un XML et de faire des calculs puissants sans bibliothèques annexes. (Agrégat, Tri, Filtrage...)
• ...

Bref, le XML n'est que la partie immergée d'un vaste monde

[javan00b]

XML et JSON ne devrais jamais être comparé, leur utilisation n'est pas la même du tout.

jai rien d'autre à ajouter.

[camus3]

XML et JSON ne devrais jamais être comparé, leur utilisation n'est pas la même du tout.

+1 , c'est quoi cette manie française de tout opposer juste pour créer un polémique fictive ? un bon développeur sait utiliser la technologie appropriée quand il faut sans pour autant cracher sur le reste pour faire croire qu'il est plus intelligent que les autres.

[Atem18]

XML et JSON ne devrais jamais être comparé, leur utilisation n'est pas la même du tout.

Je pense la même chose. J'avoue ne pas savoir pourquoi est-ce que les gens se battent pour savoir lequel des deux écrasera l'autre. Bon après, je n'ai que les bases de ces langages, mais pour moi, ils se complètent plus que ne se concurrence.

[thelvin]

En même temps, moi, au lieu de dire qu'ils ne devraient pas être comparés, je montre en quoi ils ne sont pas utilisés pareil. C'est bien beau de raconter qu'il ne faut pas faire des trucs, mais encore faut-il le prouver. Ça s'appelle le partage de connaissance. Un truc qui se pratique sur les forums d'entraide. Enfin...

Surtout qu'ils devraient être utilisés différemment, mais l'état de l'art, dans l'industrie, est un joyeux bordel.

[Thorna]

Malgré ce succès, XML présente plusieurs défauts, surtout son caractère verbeux, le rendant trop lourd et peu adapté pour les échanges entre les dispositifs à ressources limitées comme les smartphones et les tablettes.

Il y a 25 à 30 ans, lorsqu'on suivait un "cours d'informatique" en entreprise, on apprenait à quelles adresses mémoire se trouvaient des octets libres dans les 640 (ou 512) ko dont on disposait à l'époque. Un octet par ici et deux octets par là, et on trouvait que c'était génial de pouvoir en disposer !
Depuis ce moment-là, la puissance des processeurs à augmenté vertigineusement, tout comme la taille de la mémoire disponible et celle des disques, et pendant ce même temps, les vendeurs de système se sont éreintés à trouver comment gaspiller toutes ces ressources : OS de 40 Go, fichiers C qui affichent "coucou" compilés en .EXE qui dépassent 10 Mo parfois, etc.
XML est dans la tendance : alors que les fichiers .INI étaient tout autant lisibles (quoi que bien moins performants, il faut le reconnaitre), XML utilisé pour tout et pour rien ne sert qu'à encombrer les répertoires de fichiers longs et indigestes, inutilement verbeux et gros, alors que bien souvent un de ces fameux .INI de 10 lignes suffirait.
On pourrait donc penser maintenant à une prise de conscience : "ah mais on n'a pas la place dans les smartphones : pourquoi donc gaspiller autant ?" ! D'où JSON, bien plus compact que XML, ouf... mais trouvez-vous réellement qu'il soit lisible ? Et est-ce que remplacer des <balises> par des [ ou des ] ou des { ou des } ou... est vraiment une évolution ? Ok, ça fait "c-style", et alors ?
Je pense que tout ça, c'est une affaire de mode qu'on pousse inutilement au premier plan en ce moment. Voyons : il suffit d'attendre tranquillement 2 ou 3 ans, rien de plus ! A cette époque future mais proche, tous les smartphones auront les 32Go de mémoire et leur téra de stockage. Pourquoi donc se fatiguer à améliorer un système peu performant de fichiers descriptifs, alors qu'on aura bientôt les moyens de l'utiliser sans effort ?

[alex_vino]

Il y a 25 à 30 ans, lorsqu'on suivait un "cours d'informatique" en entreprise, on apprenait à quelles adresses mémoire se trouvaient des octets libres dans les 640 (ou 512) ko dont on disposait à l'époque. Un octet par ici et deux octets par là, et on trouvait que c'était génial de pouvoir en disposer !
Depuis ce moment-là, la puissance des processeurs à augmenté vertigineusement, tout comme la taille de la mémoire disponible et celle des disques, et pendant ce même temps, les vendeurs de système se sont éreintés à trouver comment gaspiller toutes ces ressources : OS de 40 Go, fichiers C qui affichent "coucou" compilés en .EXE qui dépassent 10 Mo parfois, etc.
XML est dans la tendance : alors que les fichiers .INI étaient tout autant lisibles (quoi que bien moins performants, il faut le reconnaitre), XML utilisé pour tout et pour rien ne sert qu'à encombrer les répertoires de fichiers longs et indigestes, inutilement verbeux et gros, alors que bien souvent un de ces fameux .INI de 10 lignes suffirait.
On pourrait donc penser maintenant à une prise de conscience : "ah mais on n'a pas la place dans les smartphones : pourquoi donc gaspiller autant ?" ! D'où JSON, bien plus compact que XML, ouf... mais trouvez-vous réellement qu'il soit lisible ? Et est-ce que remplacer des <balises> par des [ ou des ] ou des { ou des } ou... est vraiment une évolution ? Ok, ça fait "c-style", et alors ?
Je pense que tout ça, c'est une affaire de mode qu'on pousse inutilement au premier plan en ce moment. Voyons : il suffit d'attendre tranquillement 2 ou 3 ans, rien de plus ! A cette époque future mais proche, tous les smartphones auront les 32Go de mémoire et leur téra de stockage. Pourquoi donc se fatiguer à améliorer un système peu performant de fichiers descriptifs, alors qu'on aura bientôt les moyens de l'utiliser sans effort ?

Il n'y a pas que la programmation bas-niveau en C dans la vie
Tout dépend de ce pour quoi tu développe.
Si tu fait une application smartphone qui prend une photo et nécessite d'ajouter de nouvelles métadonnées en local il n'y a pas besoin de passer des mois a trouver le format de stockage.
Par contre si tu fait un WebService qui doit distribuer beaucoup de données simultanément a des milliers d'utilisateurs sur un serveur mal dimensionné il faudra peut-etre dans ce cas bien étudié la problématique.
Dire que demain les machines seront plus puissantes est une mauvaise direction. A moins de dépenser des milliers d'Euros, les ordinateurs portables / smartphones / tablettes sont bien moins puissantes que les traditionnels PC. Imagine que demain Google sort ses Glasses et Apple son iWatch ce te fera bizarre de devoir développer tes application, les porter, ou supporter ce type de client.
Code léger et optimisé = performance = machines (client/serveur) moins puissantes = bande passante améliorée = durée dans le temps = objectif

[Julien Bodin]

Il y a 25 à 30 ans, lorsqu'on suivait un "cours d'informatique" en entreprise, on apprenait à quelles adresses mémoire se trouvaient des octets libres dans les 640 (ou 512) ko dont on disposait à l'époque. Un octet par ici et deux octets par là, et on trouvait que c'était génial de pouvoir en disposer !
Depuis ce moment-là, la puissance des processeurs à augmenté vertigineusement, tout comme la taille de la mémoire disponible et celle des disques, et pendant ce même temps, les vendeurs de système se sont éreintés à trouver comment gaspiller toutes ces ressources : OS de 40 Go, fichiers C qui affichent "coucou" compilés en .EXE qui dépassent 10 Mo parfois, etc.
XML est dans la tendance : alors que les fichiers .INI étaient tout autant lisibles (quoi que bien moins performants, il faut le reconnaitre), XML utilisé pour tout et pour rien ne sert qu'à encombrer les répertoires de fichiers longs et indigestes, inutilement verbeux et gros, alors que bien souvent un de ces fameux .INI de 10 lignes suffirait.
On pourrait donc penser maintenant à une prise de conscience : "ah mais on n'a pas la place dans les smartphones : pourquoi donc gaspiller autant ?" ! D'où JSON, bien plus compact que XML, ouf... mais trouvez-vous réellement qu'il soit lisible ? Et est-ce que remplacer des <balises> par des [ ou des ] ou des { ou des } ou... est vraiment une évolution ? Ok, ça fait "c-style", et alors ?
Je pense que tout ça, c'est une affaire de mode qu'on pousse inutilement au premier plan en ce moment. Voyons : il suffit d'attendre tranquillement 2 ou 3 ans, rien de plus ! A cette époque future mais proche, tous les smartphones auront les 32Go de mémoire et leur téra de stockage. Pourquoi donc se fatiguer à améliorer un système peu performant de fichiers descriptifs, alors qu'on aura bientôt les moyens de l'utiliser sans effort ?

Désolé mais je trouve ton message complètement surréaliste.
L'informatique d'il y a 25 - 30 ans n'existe plus, j'en suis désolé pour toi.

Tu ne peux pas dire que ces vieux machins que sont les fichiers .INI sont mieux que les XML/JSON. C'est tout aussi lisible (moins pour le JSON qui compense par sa taille), plus performant, plus fonctionnel.

Il faudrait écrire combien de fichiers INI pour décrire la même chose qu'un XML juste "un peu" évolué ?

Concernant l'évolution des besoins de stockage je ne comprend pas le lien avec les formats de fichiers... Quand tu parles de vouloir se fatiguer à améliorer un système peu performant de fichiers descriptifs tu parlais pas des .INI rassure-moi ?

[thelvin]

Désolé mais je trouve ton message complètement surréaliste.
L'informatique d'il y a 25 - 30 ans n'existe plus, j'en suis désolé pour toi.

À mon humble avis il y avait quand même moyen d'utiliser moins d'espace disque, de mémoire, et de temps processeur, tout en avançant les OS et autres systèmes critiques de l'informatique à son niveau d'aujourd'hui. Ça aurait pris plus de temps, mais je ne suis pas sûr que ça aurait été une mauvaise chose. Cette précipitation n'est pas souvent utilisée pour résoudre des problèmes réels, et au final, le matériel s'améliore, mais les effets, non. Un SI d'aujourd'hui est à peine meilleur qu'un SI d'il y a quinze ans. C'est pas que de leur faute, le secteur n'a pas évolué pour que ça s'améliore.

Dédier des ressources à déléguer le travail aux machines pour construire des choses plus complexes plus vite, c'était un choix technique qui se justifie. Mais il n'était pas obligatoire et a réussi aussi souvent qu'il a échoué.

Tu ne peux pas dire que ces vieux machins que sont les fichiers .INI sont mieux que les XML/JSON. C'est tout aussi lisible (moins pour le JSON qui compense par sa taille), plus performant, plus fonctionnel.

Il faudrait écrire combien de fichiers INI pour décrire la même chose qu'un XML juste "un peu" évolué ?

Tout de même, XML et JSON sont souvent utilisés comme des fichiers plats, et avec CSV, c'est exactement ce à quoi sert .INI.
XML et JSON peuvent faire plus, mais tout le monde s'en sert et presque personne n'a besoin de faire plus.
Quand c'est pas le cas c'est pas le cas, ok. Mais c'est rare.

Une autre différence, qui me semble plus significative, c'est l'aura d'incompétence qui tourne autour de CSV et INI. Jamais moyen de mettre tout le monde d'accord sur le format, dès qu'il y a une fin de ligne ou un accent. JSON et XML ont aussi leurs branques, mais eux au moins ils viennent pas nous emmerder sur l'encodage ni la syntaxe (ou en tout cas c'est infiniment plus rare).
Normal donc qu'on veuille plus perdre du temps avec ces vieux formats, si les nouveaux nous dédouanent de ces problèmes.

Je ne dis tout ceci que pour nuancer. Je peux voir pourquoi on a inventé des formats plus lourds : pour ce qu'ils apportent par rapport à autre chose. Mais il faut pas oublier qu'il s'agit d'un choix technique. Et qu'assez souvent, ce qu'on voit dans l'état de l'art a juste suivi un effet de mode et fait le mauvais choix.

[Zefling]

En tout cas XML n'est pas forcement plus lourd dans 100% des cas, tout dépends du type de structure, de la taille de l'arbre des nœuds. De plus permet les blocs <![CDATA[...]> qui sont bien pratique pour transmettre du HTML.
Perso, pour le transfère de données, je suis restés sur du XML, c'est pas beaucoup plus lourd et bien plus lisible (JSon dépassé 3 niveaux il faut s'accroche).

XHTML ça reste du XML, c'est heureusement que si c'était du Json ça serait l'enfer de faire des structures de pages.

Après j’utilise un format ou l'un autre, je n'ai pas de préférence, tout dépends si je pense qu'un format et plus adapté que l'autre suivant la circonstance.

[MagnusMoi]

Bonjour,

Ce que je vais écrire ne va pas vraiment être teinté d'un grand professionnalisme et je m'en excuse

Si le XML a fait ses preuves pour d'écrire des métas-data ou pour faire des fichiers de sauvegarde de nombreuses applications, je ne puis m'empêcher de vouloir le mettre au placard

Pour ma part, je préfère faire mes propres fichiers de sauvegarde binaire pour mes applications, ce à quoi l'on me rétorque justement, qu'un être humain ne pouvait pas comprendre mes fichiers (est-ce la finalité d'un être humain ?)

Mais si l'on prend un exemple jeu vidéo-ludique comme les sims 3 (peut-on vraiment parler de jeux vidéo ? ), qui peut être vérifier dans d'autre domaine cependant, nous noterons que les fichiers de sauvegardes sont tellement lourd, qu'il y a la nécessité de les compresser

Alors pourquoi faire du verbeux, si au final il faut « binariser » le tout
Pourquoi m'embêter avec des node et autre next sibling alors ?

Pour le JSON, je l'utilise en développement WEB et il est assez pratique, notamment pour formater une réponse de BDD, mais je vais bientôt faire comme pour mes projets en C, passer par un CSV ( indémodable ce format ^_^, utile en phase de développement, je le remplace par un fichier binaire au format personnel en version finale pour mes projets desktop.)

Mais une fois de plus, il n'y a pas une méthode, une solution pour un problème. Je peux comprendre l'utilité des 2 conteneurs, mais je souhaiterais plus de tolérance pour les païens comme moi, qui les fuient, sous couvert de gain d’espace, et d'un peu de mauvaise fois

Merci de m'avoir lu.

Bonne journée !

[thelvin]

Pour ma part, je préfère faire mes propres fichiers de sauvegarde binaire pour mes applications, ce à quoi l'on me rétorque justement, qu'un être humain ne pouvait pas comprendre mes fichiers (est-ce la finalité d'un être humain ?)

Ce que moi je te rétorque à ça, c'est qu'on a toute une histoire d'informatique à base de fichiers binaires, et qu'on sait parfaitement ce que ça donne : interopérabilité médiocre et chiantissime à mettre en œuvre, débuggage et maintenance plus compliqués.
De plus, pendant que tu concevais ton format binaire, moi je faisais quelque chose que la machine ne peut pas faire à ma place.

Mais si l'on prend un exemple jeu vidéo-ludique comme les sims 3 (peut-on vraiment parler de jeux vidéo ? ), qui peut être vérifier dans d'autre domaine cependant, nous noterons que les fichiers de sauvegardes sont tellement lourd, qu'il y a la nécessité de les compresser

... Ce qui est en effet une limitation qui peut justifier de ne pas utiliser de format trop verbeux, quels que soient les avantages qu'on en tirerait.

Alors pourquoi faire du verbeux, si au final il faut « binariser » le tout

Penser non-binaire puis binairiser derrière n'est qu'un outil pour l'humain, qui lui permet de penser les choses comme ça l'arrange et de confier les détails d'optimisation à la machine.

Pourquoi m'embêter avec des node et autre next sibling alors ?

Binaire et XML ont un mapping 1:1 sur ce dont tu parles. Si tu préfères faire du binaire et tu estimes que tel ou tel mécanisme est plus chiant qu'un autre, ce n'est qu'un sentiment. Décoder des données est chiant, par nature. Mais c'est obligatoire si on veut qu'elles soient interopérables.

Mais une fois de plus, il n'y a pas une méthode, une solution pour un problème. Je peux comprendre l'utilité des 2 conteneurs, mais je souhaiterais plus de tolérance pour les païens comme moi, qui les fuient, sous couvert de gain d’espace, et d'un peu de mauvaise fois

Nous sommes d'accord.
Mes raisons à moi sont l'analyse, totale, théorique et pratique, de ce qu'on gagne et ce qu'on perd. Au final XML a ses utilités, et surtout JSON n'a pas toujours existé. Le binaire a ses défauts. En plus il y a la question de l'usage qui en a été fait dans l'industrie, du coup JSON n'est pas aussi universel que XML, et CSV et INI ne marchent pas très bien. N'empêche qu'assez souvent, quand on rencontre du XML il a mal été utilisé ou choisi.

[alex_vino]

Si le XML a fait ses preuves pour d'écrire des métas-data ou pour faire des fichiers de sauvegarde de nombreuses applications, je ne puis m'empêcher de vouloir le mettre au placard

Un des grand avantages du XML est son universalité et sa simplicité d'utilisation.
J'ai aussi utilisé le binaire, mais le probleme c'est que tout des etre "sérialisable" et ce n'est pas toujours multi-language / multi-plateforme.
Tout dépend donc des besoins de ton projet. Pour les Sims, ce serait un peu bete qu'ils mettent a disposition toutes les données de leur application en utilisant le XML, d'autant plus que les jeux-vidéos ont besoin de performance et donc le XML est rarement adapté (sauf dans quelques rares cas).

Pour le JSON, je l'utilise en développement WEB et il est assez pratique, notamment pour formater une réponse de BDD, mais je vais bientôt faire comme pour mes projets en C, passer par un CSV

Bon courage

[Reward]

Bonjour

Personnellement je travaille en .NET/C# et je suis très satisfait du format XML.

Le framework me permet d'être productif et m'offre beaucoup de possibilité de travail avec du XML. J'aime la sérialisation, la possibilité d'implémenter un héritage en XML (xsi:type), les fonctions me permettant simplement de valider un XML par un XSD, ou bien encore les modes permettant soit un travail précis sur un noeud, avec un XDocument ou bien alors une recherche rapide sur un XML très volumineux.

Je pourrais éventuellement lui reprocher d'être verbeux, mais bon, on ne peut pas tout avoir.