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


78

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 .


14
Nous pouvons (et devrions) remplacer tous ces éléments mal conçus et surexprimés par des expressions S, évidemment. Un monde sans XML serait un endroit bien meilleur, mais ce n’est malheureusement qu’un voeu pieux.
SK-logic le

19
Pouah. Je déteste ces questions. Je pense que c'est vraiment un cas pour utiliser le bon outil pour le travail, et non pas pour savoir si on peut en remplacer un autre entièrement. Il y a si peu d'absolus dans le monde, même avec des ordinateurs. Je ne pouvais pas imaginer faire ce que je fais avec JSON, du moins là où se situent les technologies respectives.
Philip Regan

2
@Philip, il ne s'agit pas de démolir quelque chose. Il essaie juste de voir ce qui manque à JSON, afin que nous puissions l'améliorer. :)
Saeed Neamati

4
Une discussion sur les différences entre deux technologies pour voir où des améliorations peuvent être apportées est très différente de demander si l'une peut être remplacée par une autre. Le premier est plus une revue savante que le dernier qui semble plus antagoniste de frustration que n'importe quoi
Philip Regan

12
Ce n'est pas hypothétique. JSON semble manquer d'une fonctionnalité que XML possède.
S.Lott

Réponses:


153

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.


33
+1: C'est la caractéristique distinctive. Excellent point.
S.Lott

7
@ Michael, vous venez de m'apprendre quelque chose de précieux. C'est une excellente réponse. +1
Saeed Neamati

9
.... Il y a 3 noeuds indépendants de P, A l'élément B et `` mess nous sommes dedans !`. C'est un tableau, que vous pouvez simplement expliquer en JSON.
Incognito

5
@Rob Non, mais j'explique que vous pouvez définir plus clairement les éléments exprimés par HTML et peut-être accélérer l'analyse via JSON (une analyse moins complexe du texte étant nécessaire pour rechercher les différents types de nœuds). Si HTML était JSON-ML, nous aurions peut-être plus de développeurs qui comprennent réellement le DOM, les nœuds de texte et les liaisons.
Incognito

5
@ByrneReese: oui, c'est XML et oui, c'est valide. Que ce soit aussi HTML est à côté du point; En fait, XHTML est également valide XML. :-)
Martijn

31

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.


7
"XML est conçu pour s'expliquer de lui-même". Pouvez-vous fournir un lien ou une référence pour cela? Je ne le vois pas dans les normes W3C pour XML, et je me demande d'où vient cette notion. Je ressemble plus à une légende urbaine qu’à un objectif de design déclaré.
S.Lott

6
@ S.Lott: Je pense que ce qu'il entend par là, c'est la nature des balises XML, en soi, permet au contenu étiqueté de s'expliquer de lui-même, c'est-à-dire que les DTD sont facultatives, de sorte que le XML bien formé peut être analysé sans. Mais je suis d'accord avec votre point de vue sur la question parce que, techniquement, JSON a la même capacité, je ne vois donc pas l'auto-explication comme étant la principale différence (je ne sais pas pourquoi cela continue à être voté), mais plutôt Michael Kay est plus sur la marque.
Philip Regan

5
@Lott accepté. Je dirais que le JSON ici json.org/example.html est plus facile à comprendre et à mieux se documenter que le XML associé en raison de son manque de verbosité.
Doug T.

4
@Michael Borgwardt: Sans un nom de balise XSD complet (avec une sorte de support d'ontologie), rien ne me dit. "significatif" est difficile à accomplir en général. Cela ne me permet pas de savoir ce que "l'auto-explication" est censé signifier dans la réponse. Et je n'ai aucune preuve qu'il s'agisse même d'un objectif de conception pour XML.
S.Lott

4
@Philip Regan: comme avec le "code à explication automatique", il ne semble pas être une fonctionnalité de XML. S'il ne s'agit que d'un objectif d'implémentation universelle s'appliquant à tous les langages logiciels (code, accès aux données, balisage, etc.), il est peut-être préférable de ne pas le mentionner spécifiquement dans XML.
S.Lott

21

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.


8
Considérons maintenant SXML:(foo (x:bar (@ (x:prop1 "g")) (quuz)))
SK-logic le

2
@ SK-Logic: C'est parfait pour un exemple trivial, mais je ne pouvais pas imaginer créer un contenu mélangé profondément imbriqué, comme un livre, avec cela. Je pense que SXML est autant un exercice académique qu’autre chose.
Philip Regan

3
@Philip Regan: Comment peut-il être plus difficile d'écrire une S-Exp que d'utiliser la chevronite, alors qu'il s'agit d'une simple transformation 1: 1 en une forme moins verbeuse?
Maaartinus

@maartinus: Mon domaine d'expertise est dans l'édition de livres: les manuels de tous types sont des bêtes profondes et complexes, avec un large éventail de contenus nécessitant une gestion explicite. DocBook et DITA sont beaucoup plus lisibles que l'exemple présenté ci-dessus.
Philip Regan

1
@Philip Regan, SXML est très facile à modifier, contrairement à XML. Et bien sûr, c'est un choix bien meilleur pour les protocoles, il va sans dire que la supériorité de l'outillage disponible.
SK-logic

14

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.


5
Sauf pour les contenus mixtes où les données contiennent des balises. JSON ne le fait pas très bien du tout.
S.Lott

11

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.


3
Cela dit, vous pouvez utiliser un autre langage pour désérialiser, manipuler et sérialiser JSON, et XSLT n’est pas du XML, ce point est donc sans objet.
StuperUser

3
XSLT est XML - voir le schéma ici
treecoder

Merci @greengit, je n'ai eu qu'un bref exposé, mis à jour la réponse.
StuperUser

2
@StuperUser: Comment pourrait-il être "impossible" avec JSON? C'est juste une transformation, peut-être que les outils manquent encore. Ou le problème est-il lié au manque d'attributs dans JSON?
Maaartinus

1
@StuperUser: XSLT est un langage (sous-ensemble de XML) pour lequel certains interpréteurs ont été écrits dans au moins un autre langage (probablement en C, Java, ...). La même chose pourrait être faite pour JSON (définir un JSON-T, écrire l’interpréter), n’est-ce pas?
Maaartinus

8

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


7

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.


2
Merci pour votre réponse. Je pense à un examen technique plutôt qu’à une stratégie de mise en œuvre. Je veux juste savoir, par exemple, pour les nouvelles versions de ces systèmes hérités, pouvons-nous supprimer complètement XML et utiliser JSON? Sinon, qu'est-ce qui nous manque dans JSON?
Saeed Neamati

D'autre part, je n'ai utilisé aucun code XML, uniquement JSON, au cours des dernières années. Et bon débarras. Bien sûr, XML est plus une entreprise. Ce qui est génial pour la sécurité d'emploi, pas si génial pour l'efficacité.
gnasher729

6

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.


JSON peut évidemment contenir des chaînes pouvant contenir du HTML.
gnasher729

6

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.


4

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.


3

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.


11
le JSON équivalent au XML fourni est { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. Donc, techniquement, votre réponse n'est pas correcte. :)
Saeed Neamati

Bien sûr, la seule chose qui manque à JSON, ce sont les attributs, et il est inutile de modéliser des objets (contrairement au balisage). Parfois, les attributs sont utilisés comme raccourci pour ce qui peut être exprimé à l'aide de données imbriquées (par exemple, dans les fichiers de configuration Hibernate), ce qui est pratique, mais l'existence d'un choix le rend plus difficile. Les fichiers de configuration et les objets de modélisation sont deux endroits où JSON est clairement supérieur.
Maaartinus

2
@SaeedNeamati, comment feriez-vous la modélisation <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer>en JSON?
svick

6
{clients: [{name: 'John Doe'}, {name: 'John Doe'}]}?
scrwtp

2
@Stijn - c'est vrai, et cela fonctionne, mais cela confirme le commentaire de la réponse d'origine, selon lequel "vous devez ajouter des méta-structures" pour modéliser certaines choses qui tombent plus naturellement dans XML.
Matt R

3

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.


2
json a aussi des schémas: json-schema.org
lordvlad
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.