3 Rollback to Revision 1
source | link

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>

<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>

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>

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>

2 Tweak xml format. Its pretty now!
source | link

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>

<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>

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>

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>
1
source | link

XML is an eXtensible Markup Language. That's important to understand: It's designed to be essentially like HTML--a document markup language--but a bit more formalized. Problem is, document markup isn't what anyone uses it for. People abuse it for data storage and data exchange, which is a really bad idea because data storage isn't anything like document markup.

A typical HTML document has a pretty high content-to-markup ratio. It's quite possible to write entire pages without needing to insert a single tag beyond the occasional <p>, for example. But in data storage, every data element needs to be defined in some formal way. With XML, that turns everything into a mess of tag soup very quickly. For example:

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>

We see that the content can very easily end up completely drowned out by all of the tags. (This is often true even when the XML has been pretty-printed.)

Also, XML requires that every <tag> must be closed by a corresponding </tag>. It also requires that tags be closed in strict LIFO (ie. Stack) order. This is redundant: if the only tag that's valid to close is the last one that hasn't been closed yet, every closing tag could theoretically be a simple </> with no loss of semantic information. (It would be harder to follow if you didn't pretty-print it, but who wants to try to read non-pretty-printed XML anyway?) This makes XML files larger and bulkier than they need to be.

The XML DOM model is also incredibly complex. Just for starters, you have two distinct ways to represent sub-data on a node: nodes between the opening tag and its closing tag, and Attributes inside the opening tag. Again, this is an idea that makes a lot of sense in document markup (<a href="http://example.com">) but a lot less for data storage. Then you've got all sorts of additional complexities like namespaces, schemas and validation, XSLT, and so on...

The principal difference between XML and JSON is that JSON is just a data storage format. It's optimized for expressing serialized data, not for document markup, and so it does a much better job of expressing serialized data. Douglas Crockford calls it "the fat-free alternative to XML."

The really interesting thing is, it manages to do this without actually losing any power. You want schemas and validation? Use JSON Schema. Queries? There's JSONPath for that. (And if, on the other hand, you don't care about those things, you don't need any code for it bloating up your program.) You want comments and namespaces, or even attributes? {"namespace": "MyNamespace", "attributes": {"attrib1": "value1", "attrib2": "value2"}, "data": "Insert content here", "comment": "It's that simple"}

To answer the original question, there's no data that can be represented in either system that the other can't also do. It's just a lot smaller and cleaner in JSON, almost every time, because JSON was specifically designed for data storage and XML wasn't. It's a simple matter of "use the right tool for the job."