Having control over client and server, in which cases is XML more preferable than JSON?

I've heard a lot about how JSON is far superior to XML. I'd like to play devil's advocate to the masses and ask 开发者_Go百科when is XML superior to JSON? Assuming you're not having to worry about using XML to communicate by some legacy system or what not and you have full control over client and server, in what case would you choose XML when JSON could also work for data transmission?

XML was designed originally for marking up text in documents. That's something JSON simply can't do.

XML has been widely adopted for a secondary role, serializing structured data into text form for messaging. That's a job which JSON can probably do just as well. In that role, XML has an advantage because of the layers of stuff that have been built around it - schema languages, namespaces, transformation and query languages, databases etc; while JSON has an advantage because it's simpler and is a better fit to traditional 3G programming languages.

XML is used as the basis of thousands of standardized vocabularies for particular kinds of data. Those vocabularies aren't going to disappear in a hurry; and I don't yet see anyone developing new industry-standard message formats using JSON rather than XML (once they do, JSON will need to add the layers of complexity that XML has accumulated). JSON, I think, is largely used today for exchanging data between two programs that were both written by the same people.

The only advantage JSON has over XML is that it is lighter weight, (meaning it is faster to send over connections and takes up less space).

XML provides strongly typed schema, validation a ridiculous amount of additional languages and systems built on top of it (go to W3C, for a list). XML can be used to build large complex systems.

JSON can represent data, but is pretty much useless without an interpreter. The two really can't be considered analogous.

The only times JSON should be used is for communication of data from a server to a client, or possibly to a data store (provided there is some strongly typed schema for interpreting the JSON, such as RavenDB).

The many uses and applications of XML are literally boundless. But, it's bigger and slower.

The approach I take is to do any processing using XML, and when it comes time to send something somewhere, to translate the XML to JSON server-side (which is fairly simple).

It's been my impression (from personal experience and talking to others) that the popularity of JSON comes mostly from its simplicity. XML can do just about anything, but that flexibility comes at the price of some complexity. For most developers (especially newer ones), getting web services up and running and really doing something with XML takes longer than with JSON.

My rule of thumb is that for really complex object graphs, enterprise-level stuff (validation, auditing, complex namespacing, etc.), you're probably going to want XML. If you're knocking out a bunch of web services that pass around simple data, JSON is a much quicker and easier development option. That last is especially true if JavaScript will be a heavy consumer of those web services.

If you're not sure that what you're doing is complex enough to warrant XML, I'd suggest going with JSON until you start hitting its limitations, then moving to XML. Obviously, there's a risk there (any decision like this poses some risk), but if you don't ultimately need XML then you save yourself a lot of time and potential developer headaches up front.

It also depends on your development team - if you've got some guys who've been creating XML web services for years and can write SAX parsers in their sleep, XML might be the right answer no matter what you're writing.

AFAIK JSON is less verbose and more human readable and hence the whole aura of "better than xml".

XML is good especially if you start going to specific implementations such as soap or wsdl to define the structure. There are a lot of libraries that make life easy but being verbose there is the fact that it does need to transfer a lot to get all the data across.

Have a look at protobuf, thrift or other binary serialization/data transfer mechanisms. They might be a perfect fit for your use case.