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.
Sure. Guess what? A schema for JSON in JSON is pretty simple. And ... readable. Query/transformation languages? Yup. But they won't be languages built on JSON. They will be the languages we use to do our jobs; JavaScript, Java, PHP, Python, Ruby, C, C#, etc. Because JSON, like the programming languages we use, has built-in constructs for numbers, strings, arrays, hash tables, etc. With XML, you need to apply some other structure on top of the XML itself to get this level of semantic. And don't get me started on query/transformation languages. XSLT is ... hard. James Governor asked on the #redmonk irc channel the other day if anyone had thoughts on XQuery, and my response was: tried to read the docs once; much like C++, I figured it was too complex, so I decided to ignore it, and hope it will just go away.
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.
Photo 'Urban Markup' with a nice CC license, by Gord Fynes. Found using the Flickr's Create Commons Search.
Update: 2006/12/22: fixed a typo
No comments:
Post a Comment