83

I'm sure lots of developers are familiar with XML and JSON, and they've used both of them. Thus no point in explaining what they are, and what is their purpose, even in brief.

If we try to map their concepts, we can say (correct me if I'm wrong):

  1. XML tags are equivalent to JSON {}
  2. XML attributes are equivalent to JSON properties
  3. XML tag collection is equivalent to JSON []

The only thing I can think of, which doesn't exist in JSON, is XML Namespaces.

The question is, considering this mapping, and considering that JSON is highly lighter in this mapping, can we see a world in future (or at least theoretically think of a world) without XML, but with JSON doing everything XML does? Can we use JSON everywhere XML is used?

PS: Please note that I've seen this question. It's something entirely different from what I'm asking here. Thus please don't mention duplicate.

11
  • 14
    We can (and should) replace all of that overbloated ill-designed stuff with S-expressions, obviously. World without XML would be a much better place indeed, but that's, unfortunately, nothing but a wishful thinking.
    – SK-logic
    Commented Sep 16, 2011 at 11:35
  • 19
    Ugh. I loathe these questions. I think this is really a case for using the right tool for the job, and not whether one can replace another entirely. There are so few absolutes in the world, even with computers. I couldn't imagine doing any of the things I do with JSON, at least where the respective technologies stand now. Commented Sep 16, 2011 at 12:17
  • 2
    @Philip, this is not a question for demolishing something. It just tries to see what JSON lacks, so that we can improve it. :) Commented Sep 16, 2011 at 14:13
  • 4
    A discussion about the differences between two technologies to see where improvements can be made is very different than asking whether one can be replaced with the other. The former is more scholarly review than the latter which sounds more antagonistic from frustration than anything Commented Sep 16, 2011 at 14:42
  • 12
    This isn't hypothetical. JSON seems to lack a feature that XML possesses.
    – S.Lott
    Commented Sep 16, 2011 at 16:46

12 Answers 12

163

The thing that gives XML its power and a lot of its complexity is mixed content. Stuff like this:

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

Don't even try to do that in JSON, or manipulate it in conventional programming languages. They weren't designed for the job.

This kind of question usually comes from people who forget that that the M in XML stands for markup. It's a way of taking plain text and adding markup to create structured text. It's quite handy for old-fashioned data too, but that's not what it was designed for or where its main strengths lie. There are plenty of ways of handling simple data, and JSON is one of them.

16
  • 34
    +1: This is the distinguishing feature. Excellent point.
    – S.Lott
    Commented Sep 16, 2011 at 12:42
  • 7
    @Michael, you just taught me something valuable. This is a great answer. +1. Commented Sep 16, 2011 at 14:15
  • 9
    .... There's 3 nodes indie of P, A , the B element, and ` mess we're in!`. It's an array, which you can simply explain in JSON.
    – Incognito
    Commented Sep 16, 2011 at 18:38
  • 5
    @Rob No, but I'm explaining that you could define things expressed by HTML in greater clarity, and perhaps faster parsing via JSON (as less parsing of the text is required to find the different types of nodes). If HTML were JSON-ML, we might have more devs that actually understand the DOM, text nodes, and bindings.
    – Incognito
    Commented Sep 19, 2011 at 3:29
  • 5
    @ByrneReese: yes it's XML, and yes it's valid. That it’s also HTML is beside the point; in fact, XHTML is also valid XML. :-)
    – Martijn
    Commented Sep 22, 2011 at 17:19
32

The main difference, I think, is in the fact that XML is designed to be self-explaining with its dtd's and everything.

With JSON, you have to assume alot about the data you are receiving.

17
  • 8
    "XML is designed to be self-explaining". Can you provide a link or a reference for this? I don't see it in the W3C standards for XML, and I'm wondering where this notion comes from. I seems like an urban legend more than a stated design goal.
    – S.Lott
    Commented Sep 16, 2011 at 12:43
  • 6
    @S.Lott: I think what he means by that is the nature of XML tags, in and of themselves, allows tagged content to be self-explanatory, i.e., DTDs are optional so well-formed XML can be parsed without one. But I agree with your take on the issue because, technically, JSON has the same capability, so I don't see self-explanation being the main difference at all (I'm not sure why this keeps getting voted up), but rather Michael Kay is more on the mark. Commented Sep 16, 2011 at 12:51
  • 5
    @S.Lott agreed. I'd have to say the JSON here json.org/example.html is easier to understand and better self documented than the associated XML due to its lack of verbosity.
    – Doug T.
    Commented Sep 16, 2011 at 13:00
  • 4
    @Michael Borgwardt: Without a full XSD (including some kind of ontology support) tag names tell me nothing. "meaningful" is hard to accomplish in general. That leaves me unclear on what "self-explaining" is supposed to mean in the answer. And I don't have evidence that it was even a design goal for XML.
    – S.Lott
    Commented Sep 16, 2011 at 13:11
  • 4
    @Philip Regan: As with "self-explaining code", it appears not to be a feature of XML. If it's just a universal implementation objective that applies to all software languages (code, data access, markup, whatever) then perhaps folks shouldn't mention it around XML specifically.
    – S.Lott
    Commented Sep 16, 2011 at 14:10
22

A literal translation to JSON is often less succinct and less clear. Consider:

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

The most effective JSON representation I have seen of this:

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

Now, imagine that for an entire XML file. I am not saying that JSON does not have its place, but XML should not be ruled out.

9
  • 8
    Now consider SXML: (foo (x:bar (@ (x:prop1 "g")) (quuz)))
    – SK-logic
    Commented Sep 16, 2011 at 11:48
  • 2
    @SK-Logic: That's great for a trivial example, but I couldn't imagine doing deeply nested, mixed content—like a book—with that. I think SXML is as much an academic exercise as anything. Commented Sep 16, 2011 at 12:22
  • 3
    @Philip Regan: How can be writing an S-Exp any harder then using chevronitis, when it's a trivial 1:1 transformation into a less verbose form?
    – maaartinus
    Commented Sep 16, 2011 at 12:48
  • @maartinus: My field of expertise is in book publishing: textbooks of any kind are deep, complex beasts with a wide array of content that requires explicit management. DocBook and DITA are much more readable than the example given above. Commented Sep 16, 2011 at 12:54
  • 1
    @Philip Regan, SXML is very easy to edit, quite unlike XML. And of course it is a much better choice for protocols, needless to mention the superiority of the available tooling.
    – SK-logic
    Commented Sep 16, 2011 at 12:56
14

JSON and XML are both ways of formatting data. Both are capable of doing it perfectly well, so can JSON do everything XML does? Yes.

But..... A more relevant question might not be what XML/JSON can do, but rather, what can you do with XML/JSON.

There are several things you can do with XML that I don't think you can with JSON, such as translate with XLST, search with XPath and validate with schemas. All very, very useful.

1
  • 5
    Except for mixed-content where the data contains tags. JSON doesn't do that very well at all.
    – S.Lott
    Commented Sep 16, 2011 at 12:44
11

There's a lot of functionality using XSLT that may not be possible with JSON. So, if they're not functionally equivalent they couldn't replace each other.

7
  • 3
    That said, you could use another language to deserialise, manipulate and serialise JSON, and XSLT isn't XML, so this point is moot really.
    – StuperUser
    Commented Sep 16, 2011 at 10:52
  • 3
    XSLT is XML -- see the schema here
    – treecoder
    Commented Sep 16, 2011 at 12:19
  • Thanks @greengit, I have only had a brief expose to it, updated the answer.
    – StuperUser
    Commented Sep 16, 2011 at 12:21
  • 2
    @StuperUser: How could be it "impossible" with JSON? It's just a transformation, maybe the tools are missing yet. Or is the problem related to the lack of attributes in JSON?
    – maaartinus
    Commented Sep 20, 2011 at 12:57
  • 1
    @StuperUser: XSLT is an language (subset of XML) for which some interpreters were written in at least one another language (probably in C, Java, ...). The same could be done for JSON (define some JSON-T, write the intepreter), couldn't it?
    – maaartinus
    Commented Sep 20, 2011 at 15:45
8

The fact is, we're going to have to live with both for a long time, and being a JSON bigot is "considered harmful."

7

JSON is fairly new and legacy systems wont support it. Upgrading legacy systems is expesive and introduces bugs. JSON wont replace XML any time in the near future.

2
  • 2
    thanks for your reply. What I have in mind, is a technical review, rather than an implementation strategy. I just want to know for example, for new versions of those legacy systems, can we drop XML entirely and use JSON? If not, what we miss in JSON? Commented Sep 16, 2011 at 10:42
  • On the other hand, I haven't used any XML, just JSON, in the last few years. And good riddance. Of course XML is more enterprisy. Which is great for job security, not so great for efficiency.
    – gnasher729
    Commented Jan 14, 2017 at 12:35
6

I'd say that cwallenpoole makes an excellent point. While most XML can be translated to JSON, whether doing so is better for it is a separate point.

JSON lends itself to data structures at least as well as XML and probably better, but XML reads much more naturally than JSON when marking up textual documents, where tags are used within a larger flow of text rather than simply as a way to delimit a hierarchy of fields.

While HTML 5 may have its own parser, that still leaves applications like DocBook.

1
  • JSON can obviously contain strings which can contain HTML.
    – gnasher729
    Commented Jan 14, 2017 at 12:36
6

It depends on the domain. In terms of web services? Absolutely. It's utterly shameful that vendors are still pushing SOAP on their customers. REST + JSON all the way.

Now, when you're talking about complex, structured data with style information like Docbook or other implementation? That's a proper domain for XML.

4

Why limit yourself to JSON when YAML is a super set and much more expressive and therefore powerful than XML or JSON.

That said, if you use the correct serialization frameworks you should be able to serialize and de-serialize all the above mentioned formats with a couple of simple lines of code.

3

It gets ugly when you try to model these two objects in JSON:

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

Using JSON as it is used to in 99% cases one gets lost with:

{ name: "John Doe" } 

And now you have to add some meta-structures and all the beauty of JSON is gone while you are left with the downsides.

11
  • 12
    the equivalent JSON to your provided XML is { customer: { name: 'John Doe' }, employee : { name: 'John Doe' } }. So technically, your answer is not correct. :) Commented Sep 20, 2011 at 3:57
  • Sure, the only thing lacking in JSON are the attributes, and there are useless for modeling objects (unlike for markup). Sometimes attributes get used as a shortcut for what can be expressed using nested data (e.g., in Hibernate config files), which is handy but actually the existence of choice makes it harder. Config files and modeling objects are two places where JSON is clearly superior.
    – maaartinus
    Commented Sep 20, 2011 at 13:03
  • 2
    @SaeedNeamati, so how would you model <customer><name>John Doe</name></customer><customer><name>John Doe</name></customer> in JSON?
    – svick
    Commented Sep 22, 2011 at 19:26
  • 6
    { customers : [ { name: 'John Doe' }, { name: 'John Doe' } ] } ?
    – scrwtp
    Commented Sep 22, 2011 at 19:59
  • 2
    @Stijn -- right, and that works, but it confirms the comment from the original answer, that "you have to add some meta-structures" to model certain things that fall out more naturally in XML.
    – Matt R
    Commented Jul 30, 2013 at 8:11
3

I don't know if such a facility exists for JSON, but in .NET at least you can validate XML against a given schema. That's a valuable advantage of XML in my eyes.

1

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