I also don't understand why more and more REST APIs are providing support just for JSON payload. There are much more tools that can do directly something with XML then with JSON.

It would be nice to define some uniform mapping from JSON->XML and update XML parsers to automatically convert JSON structure into infoset on-the-fly during parsing.

For XML->JSON such mapping would be of course much more difficult.

I absolutely agree. XML is a markup technology. JSON is a structured data exchange format. Those are two different domains, and for a good reason: if you try to use one on the other, it will cause pain and suffering. Interestingly, XML is much easier to adapt to structured data exchange than JSON to markup/mixed content. Still, structured data is more painful in XML than it should be.

One of the compelling reasons to use JSON instead of XML in current web applications are the imposed security restrictions in modern browsers; JSON can actually be retrieved from remote websites without too much trouble (using jsonp) while XML requires one to jump through a number of loops (such as a local proxy). Go figure!

I also believe that the general all around awesomeness of XPath is under-appreciated by the JSON partisans.

See also: very good additional commentary by Noah Mendelsohn.

JSON vs. XML. Meh: agreed. I love JSON for the ease of reading and handling simple data.

You may want to check out JSON for Linked Data. It solves the problem of 'namespaces in JSON': the JSON-LD website

Totally agree. There isn't one ring to rule them all. People just need to know when its appropriate to use what. I love xml for a lot of stuff, but client-side rendering, I'm json all the way. Just gotta know when.

Hmm. You can have semi-structured data in JSON. Show us a code sample where you can do something in XML and not JSON. IRT Noah's commentary, I don't see how you "can't" use it to carry resume data.

Jakob, so you want to sell JSON (jsonp aka json-in-script) based on its insecurity?

Thanks, but I want to load external data into my app, not execute foreign untrusted code with credentials of my app.

Regarding mixed content, one can always embed (X)HTML in JSON. I don't think I've ever needed mixed content that were not meant for display.

Totally agree that XML and JSON each have their place, and neither is the killer of the the other.

I think you also hit on something that I've constantly run into over the years: despite JSON being easier to work with in JavaScript, JSON doesn't do one thing that XML does great -> mixed content.

I created JsonML specifically to be able to represent mixed content in a native JSON structure, despite what others have characterized my motivations to be. Unfortunately as you allude to, this doesn't make it simple! I've always considered it a reversible encoding rather than a format intended for humans. So for my purposes it works great, but XML-replacement it is not and never was intended to be.

I think services like Twitter are choosing JSON-only not because they think XML is going away but because it takes time and money to maintain the quality of both. They are simply putting their efforts where the most clients are going.

Here is a like-minded article by Daniel Lemire: You probably misunderstand XML.

I should also point out that this is an old debate (no surprises there, I guess). David Megginson had a pretty good article back in 2007 comparing the verbosity of the formats that I think addresses Jader's challenge. In short, the complexity of various formats converges as you add things like mixed content and namespacing.

I had never seen JSON-LD before but it strikes me at first glance as being a lot like xml namespaces (with all good and bad connotations implied).

Once they make an XPath equivalent for JSON, then we can talk about deprecating XML :) Until then, XML is king.

(I imagine that the problem with XPath, however, is that not that many people know about it. I would also wager that a lot of those who don't know about it are the kind of people who find XML excessively bloated and complex, thus seeing JSON as not just an acceptable substitute, but in fact an improvement.)

Without any bragging going on here, I have been actively developing apps since the mainframe days (yes apps on mainframes! sort of..!), and the format wars of JSON vs XML is in some ways like VHS vs BETAmax, not exactly for sure, but close. The points in this blog are very good ones. I love JSON for its Javascript simplicity, but XML is definitely a standard across mature infrastructures as well as a lot of web services that I see. In normal states, it is a case of using the correct tool for the job at hand - as always.

JSON --> Data XML --> MetaData

but Google in new API has given space to XML in the form of Atom. Yes another one is JSON. So JSON is reaching to height.

Something worth reading for those of you coming from a more data-centric angle: "Mixed Content Myopia"

Quote: "...I have been involved in debates about XML processing techniques that seemed to be going around in circles. More often than not, the disagreement stemmed from a different conceptual model of XML processing and, more often than not, that difference revolved around the important concept of mixed content in XML. If one party to a debate sees it in their mind-map of XML and the other does not, communication problems are likely to ensue..."

Jader wrote: IRT Noah's commentary, I don't see how you "can't" use it [I.e. JSON] to carry resume data.

Yes, of course you can. What JSON doesn't give you is a standard way to have markup inside of text, something that would could be valuable in a resume for several reasons: first of all, such markup is often used for highlighting, emphasis and format control. Sometimes, it's used to markup semantics inline with the text.

Can you do this in ad-hoc ways in JSON? Sure, but none of the supporting libraries, databases, or interfaces you use will understand that it's happening. With XML, such marked up text is a first class construct. The libraries, languages and binding tools that handle XML properly provide standardized facilities for querying, creating, and manipulating such markup. With JSON, you just can't have a property inside a run of text; it's not made for that.

I encourage you to read James Clark's perspective as well.

With respect to my statement that "XML wasn't designed to solve the problem of transmitting structured bundles of atomic values", James is right. The situation is more nuanced than that.

Hey. I don't understand what property of namespaces is not provided by ordinary JSON objects. If you want separate namespaces, then put things into separate objects. Have I misunderstood? Thanks.

JSON is better than XML in all respects, but one: there is no schema. Unfortunately, the XML schema have not fulfilled its promise of letting programs to understand the meaning of the data, leaving alone the faults of its design and implementation.

XML is a perfect example of a very fine strategy: promise that which is impossible and milk for money.

Sorry XML, we need a fresh promise.

I never know whether to approve comments like Andrey's or not. It's utter nonsense, but I suppose it's on-topic in a broad sense.

Andrey: let me google that for you: json schema. There exists at least one schema language for JSON. The fact that it isn't very good yet means you haven't contributed enough.

fyi, also, in the works, is JSYNC, which extends JSON to include additional data serialization features from YAML.

As much as I see SGML/XML as vital to mixed content, I personally found the XML-is-the-database ideals of 5-10 years ago a bit much. Those ideals certainly led me to do a few projects the really hard way with XML for simple data, that now I see as being more efficiently achieved with JSON.

I think this perception gap between XML and JSON has to do with how the objects are accessible / processable after the underlying text is parsed. The standard processors of XML, like XPath are great when you imagine your system as being chains of standard processors. But, if you think you just need a really specific processor for some really specific data, there's some appeal in working "directly" with data objects in the manner of JSON.

Maybe XML does offer that directness via data bindings -- I probably should play with E4X again . . .

@Joe Hilderbrand I think it works fine. There's already support for it in dojo. The nice thing is they didn't make XML's pre-schema mistake with DTD an instead went straight for JSON as the description language. You can easily take a JSON object and validate it with a JSON schema object. The dojo validation implementation also give verbose output about any validation errors.

Can JSON be used for multi-language content, to be clear non-english content. For Objective C as the programming language, I tried SBJSON Parser, but didn't found much luck to parse the non-english content yet. Please let me know if any other way to parse the JSON content over Objective-C

Being a "fan" or XML or JSON is foolishness. A wise developer uses the right tool for the right job and does not get emotionally attached to them.