Peut-on remplacer XML par JSON entièrement? [fermé]

Je suis sûr que de nombreux développeurs connaissent bien XML et JSON , et ils les ont utilisés tous les deux. Il ne sert donc à rien d’expliquer ce qu’ils sont et quel est leur but, même brièvement.

Si nous essayons de cartographier leurs concepts, nous pouvons dire (corrigez-moi si je me trompe):

1. Les balises XML sont équivalentes à JSON {}
2. Les attributs XML sont équivalents aux propriétés JSON
3. La collection de balises XML est équivalente à JSON []

La seule chose à laquelle je puisse penser, qui n'existe pas dans JSON, est les espaces de noms XML .

La question est de savoir, en considérant cette cartographie, et en considérant que JSON est très clair dans cette cartographie, pouvons-nous voir un monde à l'avenir (ou du moins théoriquement penser à un monde) sans XML, mais avec JSON faisant tout ce que XML fait? Pouvons-nous utiliser JSON partout où XML est utilisé?

PS: S'il vous plaît noter que j'ai vu cette question. C'est quelque chose de totalement différent de ce que je demande ici. Donc, s'il vous plaît ne mentionnez pas dupliquer .

Ce qui donne à XML sa puissance et beaucoup de sa complexité est un contenu mixte. Des trucs comme ça:

<p>A <b>fine</b> mess we're in!</p>

N'essayez même pas de faire cela en JSON, ni de le manipuler dans des langages de programmation conventionnels. Ils n'étaient pas conçus pour le travail.

Ce type de question provient généralement des personnes qui oublient que le M en XML est synonyme de balisage. C'est une façon de prendre du texte brut et d'ajouter du balisage pour créer du texte structuré. C'est assez pratique aussi pour les données à l'ancienne, mais ce n'est pas pour cela qu'elles ont été conçues ou ses forces principales. Il existe de nombreuses façons de gérer des données simples, et JSON en fait partie.

La principale différence, je pense, réside dans le fait que XML est conçu pour s'expliquer de lui-même avec ses DTD et tout le reste.

Avec JSON, vous devez assumer beaucoup de choses sur les données que vous recevez.

Une traduction littérale en JSON est souvent moins succincte et moins claire. Considérer:

<foo>
   <x:bar x:prop1="g">
      <quuz />
   </bar>
</foo>

La représentation JSON la plus efficace que j'ai vue à ce sujet:

{"localName":"foo",
 "children": // you need to have a special array to hold all children
 [
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 
        "attributes":[
            {"localName":"prop1",
             "namespace":"x",
             "value":"g"}
        ],
         "children":[
             {"name":"quux"}
         ]
     }
 ]}

Maintenant, imaginez cela pour un fichier XML complet. Je ne dis pas que JSON n'a pas sa place, mais XML ne doit pas être exclu.

JSON et XML sont les deux moyens de formater les données. Les deux sont capables de le faire parfaitement, alors JSON peut-il faire tout ce que XML fait? Oui.

Mais ..... Une question plus pertinente pourrait ne pas être ce que XML / JSON peut faire, mais plutôt, que pouvez-vous faire avec XML / JSON.

Il y a plusieurs choses que vous pouvez faire avec XML que je ne pense pas pouvoir faire avec JSON, telles que traduire avec XLST, rechercher avec XPath et valider avec des schémas. Tout cela est très utile.

De nombreuses fonctionnalités utilisant XSLT peuvent ne pas être possibles avec JSON. Donc, s'ils ne sont pas équivalents du point de vue fonctionnel, ils ne peuvent pas se remplacer.

Le fait est que nous allons devoir vivre avec les deux pendant longtemps, et être un JSON bigot est "considéré comme dangereux".

JSON est relativement nouveau et les systèmes hérités ne le prendront pas en charge. La mise à niveau des systèmes existants est coûteuse et introduit des bogues. JSON ne remplacera pas XML à tout moment dans un avenir proche.

Je dirais que cwallenpoole est un excellent argument. Bien que la plupart des fichiers XML puissent être convertis au format JSON, il est préférable de procéder autrement.

JSON se prête aux structures de données au moins aussi bien que XML et probablement mieux, mais XML lit beaucoup plus naturellement que JSON lors du balisage de documents textuels, où les balises sont utilisées dans un flux de texte plus important plutôt que comme un simple moyen de délimiter une hiérarchie des champs.

Bien que HTML 5 puisse avoir son propre analyseur, cela laisse toujours des applications comme DocBook.

Cela dépend du domaine. En termes de services Web? Absolument. Il est tout à fait honteux que les fournisseurs continuent d'imposer SOAP à leurs clients. REST + JSON jusqu'au bout.

Maintenant, quand vous parlez de données complexes et structurées avec des informations de style comme Docbook ou une autre implémentation? C'est un domaine approprié pour XML.

Pourquoi vous limiter aux JSON alors que YAML est un super ensemble, beaucoup plus expressif et donc puissant que XML ou JSON.

Cela dit, si vous utilisez les cadres de sérialisation appropriés, vous devriez pouvoir sérialiser et désérialiser tous les formats mentionnés ci-dessus avec quelques lignes de code simples.

Cela devient moche quand vous essayez de modéliser ces deux objets en JSON:

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

En utilisant JSON comme dans 99% des cas, on se perd avec:

{ name: "John Doe" } 

Et maintenant, vous devez ajouter des méta-structures et toute la beauté de JSON a disparu pendant que vous restez avec les inconvénients.

Je ne sais pas s'il existe une telle installation pour JSON, mais au moins .NET permet de valider XML sur un schéma donné. C'est un avantage précieux du XML à mes yeux.