XML è un eXtensible Markup Language . È importante capire: è progettato per essere essenzialmente simile all'HTML, un linguaggio di markup del documento, ma un po 'più formalizzato. Il problema è che il markup del documento non è quello per cui nessuno lo usa. La gente lo abusa per l'archiviazione dei dati e lo scambio di dati, che è una pessima idea perché l'archiviazione dei dati non è qualcosa come il markup del documento.
Un tipico documento HTML ha un elevato rapporto content-to-markup. È abbastanza possibile scrivere intere pagine senza dover inserire un singolo tag oltre il <p>
occasionale, ad esempio. Ma nella memorizzazione dei dati, ogni elemento di dati deve essere definito in un modo formale. Con XML, tutto si trasforma in un pasticcio di zuppa tag molto velocemente. Ad esempio:
Some people, when presented with a problem, think “I know, I’ll use
XML.”
<Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription> </Problem:Worsening>
Vediamo che il contenuto molto facilmente finisce completamente sommerso da tutti i tag. (Questo è spesso vero anche quando l'XML è stato stampato a caratteri cubitali.)
Inoltre, XML richiede che ogni <tag>
debba essere chiuso da un corrispondente </tag>
. Richiede inoltre che le tag vengano chiuse in rigoroso ordine LIFO (cioè Stack). Questo è ridondante: se l'unico tag valido per chiudere è l'ultimo che non è stato ancora chiuso, ogni tag di chiusura potrebbe teoricamente essere un semplice </>
senza perdita di informazioni semantiche. (Sarebbe più difficile da seguire se non lo stampassi bene, ma chi vuole comunque provare a leggere l'XML non-pretty-stamp?) Ciò rende i file XML più grandi e ingombranti di quello che devono essere.
Il modello DOM XML è anche incredibilmente complesso. Solo per i principianti, hai due modi distinti di rappresentare i sotto-dati su un nodo: nodi tra il tag di apertura e il suo tag di chiusura e Attributi all'interno del tag di apertura. Di nuovo, questa è un'idea che ha molto senso nel markup del documento ( <a href="http://example.com">
) ma molto meno per l'archiviazione dei dati. Allora hai tutti i tipi di complessità aggiuntive come spazi dei nomi, schemi e convalida, XSLT e così via ...
La principale differenza tra XML e JSON è che JSON è solo un formato di archiviazione dei dati . È ottimizzato per esprimere i dati serializzati, non per il markup del documento, e quindi fa un lavoro molto migliore di esprimere i dati serializzati. Douglas Crockford lo chiama "l'alternativa senza grassi a XML."
La cosa veramente interessante è che riesce a farlo senza perdere alcun potere. Vuoi schemi e convalida? Usa schema JSON. Interrogazioni? C'è JSONPath per quello. (E se, d'altra parte, non ti importa di queste cose, non hai bisogno di alcun codice per farlo gonfiare il tuo programma.) Vuoi commenti e spazi dei nomi, o anche attributi? {"namespace": "MyNamespace", "attributes": {"attrib1": "value1", "attrib2": "value2"}, "data": "Insert content here", "comment": "It's that simple"}
Per rispondere alla domanda originale, non ci sono dati che possono essere rappresentati in entrambi i sistemi che l'altro non può fare anche. È molto più piccolo e pulito in JSON, quasi ogni volta, perché JSON è stato specificamente progettato per l'archiviazione dei dati e XML non lo era. È una semplice questione di "utilizzare lo strumento giusto per il lavoro".