Possiamo sostituire completamente XML con JSON? [chiuso]

Sono sicuro che molti sviluppatori hanno familiarità con XML e JSON e li hanno usati entrambi. Quindi inutile spiegare cosa sono e quali sono i loro scopi, anche in breve.

Se proviamo a mappare i loro concetti, possiamo dire (correggimi se sbaglio):

1. I tag XML sono equivalenti a JSON {}
2. Gli attributi XML sono equivalenti alle proprietà JSON
3. La raccolta di tag XML è equivalente a JSON []

L'unica cosa che mi viene in mente, che non esiste in JSON, è XML Namespace .

La domanda è, considerando questa mappatura e considerando che JSON è molto più leggera in questa mappatura, possiamo vedere un mondo in futuro (o almeno teoricamente pensare a un mondo) senza XML, ma con JSON che fa tutto ciò che XML fa? Possiamo usare JSON ovunque sia utilizzato XML?

PS: Nota che ho visto questa domanda. È qualcosa di completamente diverso da quello che sto chiedendo qui. Quindi, per favore, non menzionare il duplicato .

La cosa che dà a XML la sua potenza e molta della sua complessità è il contenuto misto. Roba del genere:

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

Non provare nemmeno a farlo in JSON, o manipolarlo in linguaggi di programmazione convenzionali. Non sono stati progettati per il lavoro.

Questo tipo di domanda di solito viene da persone che dimenticano che la M in XML sta per markup. È un modo per prendere testo semplice e aggiungere markup per creare testo strutturato. È abbastanza utile anche per i dati vecchio stile, ma non è quello per cui sono stati progettati o dove risiedono i suoi principali punti di forza. Esistono molti modi per gestire dati semplici e JSON è uno di questi.

La differenza principale, credo, sta nel fatto che XML è progettato per essere autoesplicativo con il suo dtd e tutto.

Con JSON, devi assumere molte informazioni sui dati che stai ricevendo.

Una traduzione letterale in JSON è spesso meno concisa e meno chiara. Tener conto di:

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

La rappresentazione JSON più efficace che ho visto di questo:

{"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"}
         ]
     }
 ]}

Ora, immaginalo per un intero file XML. Non sto dicendo che JSON non abbia il suo posto, ma XML non dovrebbe essere escluso.

JSON e XML sono entrambi modi per formattare i dati. Entrambi sono in grado di farlo perfettamente bene, quindi JSON può fare tutto ciò che XML fa? Sì.

Ma ..... Una domanda più rilevante potrebbe non essere ciò che XML / JSON può fare, ma piuttosto, cosa puoi fare con XML / JSON.

Ci sono diverse cose che puoi fare con XML che non penso tu possa fare con JSON, come tradurre con XLST, cercare con XPath e convalidare con schemi. Tutto molto, molto utile.

XSLT offre molte funzionalità che potrebbero non essere possibili con JSON. Quindi, se non sono funzionalmente equivalenti, non potrebbero sostituirsi a vicenda.

Il fatto è che dovremo convivere con entrambi per molto tempo, ed essere un bigotto JSON è "considerato dannoso".

JSON è abbastanza nuovo e i sistemi legacy non lo supporteranno. L'aggiornamento dei sistemi legacy è costoso e introduce bug. JSON non sostituirà XML in qualsiasi momento nel prossimo futuro.

Direi che cwallenpoole è un punto eccellente. Mentre la maggior parte degli XML può essere tradotta in JSON, se è meglio farlo perché è un punto separato.

JSON si presta alle strutture di dati almeno oltre che a XML e probabilmente meglio, ma XML legge molto più naturalmente di JSON quando contrassegna documenti testuali, in cui i tag vengono utilizzati all'interno di un flusso di testo più ampio anziché semplicemente come un modo per delimitare una gerarchia di campi.

Mentre HTML 5 può avere un proprio parser, che lascia comunque applicazioni come DocBook.

Dipende dal dominio. In termini di servizi web? Assolutamente. È assolutamente vergognoso che i fornitori stiano ancora spingendo SOAP sui loro clienti. REST + JSON fino in fondo.

Ora, quando parli di dati complessi e strutturati con informazioni di stile come Docbook o altre implementazioni? Questo è un dominio appropriato per XML.

Perché limitarti a JSON quando YAML è un super set e molto più espressivo e quindi potente di XML o JSON.

Detto questo, se si utilizzano i framework di serializzazione corretti, si dovrebbe essere in grado di serializzare e deserializzare tutti i formati sopra menzionati con un paio di semplici righe di codice.

Diventa brutto quando provi a modellare questi due oggetti in JSON:

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

Usando JSON come è abituato nel 99% dei casi ci si perde con:

{ name: "John Doe" } 

E ora devi aggiungere alcune meta-strutture e tutta la bellezza di JSON è sparita mentre rimani con i lati negativi.

Non so se esiste una tale funzione per JSON, ma in .NET almeno puoi convalidare XML su un determinato schema. Questo è un prezioso vantaggio di XML ai miei occhi.