Mike Champion's blog entry, XML 2006 Observations, ends with some thoughts/questions on JSON. Here are my answers.
Will we see JSON substituting for XML in SOAP messages, RSS feeds, etc.?
Kind of, and no. I don't think we'll see a JSON flavored SOAP, but there's already such things as JSON-RPC, so for those SOAP usages that are RPC in nature, the answer is yes. For those SOAP usages that are document-oriented in nature, there are such things as RESTful JSON.
But it's a stretch to imagine taking on the work to enable JSON-flavored [XML-thing]. For those things that XML works well for, follow the old adage: if it ain't broke, don't fix it.
Asking about feeds is telling also. Markup (XML) is fantastic for augmenting text. I have a bias; I've been doing text markup for 20 years (nroff, tex, GML, BookMaster, HTML, XML). Nothing better than to be able to in-line visual or semantic augmentation with your text, because it's sooo inline. Readable. Imagining writing a document as a big JSON object, with text strings littered with objects indicating augmentation is ... horrifying.
But that's just the text. Feeds don't neccessarily carry just text (well, at least in the future they won't). If the feed content is data, then sure, why not JSON. And the feed meta-data itself probably also better lends itself to a data layout than XML.
So, my take is: XML for text, JSON for data. Until the day the computers take over the world, we'll always be needing text, somewhere, and XML is the answer. But I'd rather be specifying my data in a data definition language like JSON, compared to doing it in XML as wonky marked up narratives.
Will people store JSON persistently?
Yes. If folks are storing XML persistently, and that XML is used to describe data in some way, I will argue that you'll save space by converting to JSON. Unless you perhaps take into consideration the fantastic compression you can get on XML, because of the extreme verbosity (what ever happened to anonymous end tags?).
That will require JSON-flavored APIs, schema/"data contract" languages, query/transformation languages, apps, etc.
I'm sure that lots of us at in the MS Data Programmability team are pondering what we should think and do about JSON.
Excellent. Keep us informed.
Update: 2006/12/22: fixed a typo