1

I'm wondering about the differences between XML and JSON.

Without any regard to existing processing tools and backend systems and merely as a means of representing data is there anything JSON does better than XML or vice versa? Or can they both be used to the same extent ?

I.e. is there anything that could be represented by JSON that XML could not represent or vice versa?

7

XML and JSON are both capable of transmitting the same data, but which is better depends mostly on what you want to do with it.

This does touch on existing tooling, but you're not likely to be hand rolling parsers for either, so it is relevant.

XML

  • Has better tooling for verifying schema.
  • Has built in support for namespaces.
  • Can be more easily restructured into HTML.
  • Can be queried with XPath, which is really exceptional query language - think SQL for XML. I haven't really seen an equivalent for JSON - but I'd love to hear about it if I'm wrong on this one.

JSON

  • Has significantly lower ceremony (and, at least in my experience, better pretty printers), so when a human has to look at it, it can be easier to read.
  • Is, unsurprisingly, the best format when one end of the transfer is written in JavaScript.
  • Has less legacy, so the chance of being forced to accept malformed JSON is lower. There is also no cultural expectation that you should have to accept malformed input.

Because one is capable of storing anything that can be stored in the other, usability and tooling is about the only criteria that is useful for comparing what it's like to use them.

If all that were wiped away, I'd probably use neither, and transmit the data as chunks of Lisp.

It's lower ceremony than JSON (barely), much easier to transform than XML, and easier to write a parser for than either (which I'd have to do if all the tooling were gone).

  • 2
    XML has namespaces, and is generally better for complex hierarchies. See also programmers.stackexchange.com/a/108764 – Robert Harvey Nov 11 '15 at 15:27
  • There's been some recent activity related to idioms for this is JSON, but you're right that it is easier to do in XML. – Morgen Nov 11 '15 at 15:29
  • Are you kidding? Lisp has immense amounts of ceremony, precisely because it's so trivial to parse: all of the useful semantic data built into a richer language's parse tree isn't there in Lisp, so all that burden gets shifted onto the developer's shoulders. – Mason Wheeler Nov 11 '15 at 15:35
  • 2
    I think we are using different definitions of 'ceremony'. I meant this in the sense of “that which is done because that's the way it's done”. For example, a list. In psudo XML it would be <list><item>one</item>...<item>n</item></list>, there's a bunch of stuff in there that adds very little actual value. In JSON that same list would be ["one",..., "n"] , much less stuff there that doesn't directly add value. In Lisp it would be ("one" ... "n"), even less so. Granted, similar to how JSON is a subset of JavaScript, I would not advocate for a full Lisp implementation for data transfer. – Morgen Nov 11 '15 at 15:54
5

It's a bit of apples and Oranges. They are both used for the same task yes, but they are distinctively different.

XML is Extensible Markup Language. The main benefit of it is that it can cary meta data. In short:

<tag attribute="something">data</tag>

So having attributes on your elements allows you to be more explicit.

More on that you can have predefined schema that enforces your defined rules of the structure. For e.g. certain elements might use certain attributes, but if others try to use it, schema validation would give you an error.

This gives a lot of power. But with great power comes great responsibility. Often these XML's represent structures and relations more than the data it self. Thus it becomes hard to read for a human because of all of the additional information it carries. So for some operations it causes more of a bloat since you want to save 5 lines of data while having 20 or more lines of xml because you need to satisfy the schema.

Wikipedia has quite a good summary of it: https://en.wikipedia.org/wiki/XML

JSON on the other hand is only meant to represent data and nothing more. You get main types of data:

  • Integers
  • Strings
  • Booleans
  • Arrays
  • Dictionaries

Thats it. You can nest them in any manner you want but thats your limitation. You only use those data types. More here: http://www.json.org/

Sure you can move attributes to their own array within the dictionary or so and you could achieve most of the same, and thats why there is this comparison often is mentioned. But at the core of it these are 2 tools for different uses. Just when you get a hammer everything becomes a nail.

XML is great when you have complex structures, relations between objects, maybe even overrides of one file by another (handled by another answer mentioned XPath).

JSON is great when you need to communicate with small objects that could have their own validation done in code. Also it's human readable and dead simple.

4

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.