The JSON vs XML debate begins in earnest

re: The JSON vs XML debate begins in earnest

Soumitra — Thu, 21 Dec 2006 22:14:59 GMT

Good to hear your level headed assessment of this issue. I have a few observations:

a. Aside from AJAX apps and API's that support these apps, where else is JSON being used?

b. Interop is a whole lot more than just serializing data structures. For example, I for have not found an easy way to serialize graphs using JSON. The serialization format is the least of our problems.

c. Cross domain scripting has nothing to do with XML or JSON.

d. Any standard that has no path to support change will die.

Having said all these, one reason I love JSON is that it will get all us XML geeks riled up and thinking about how we can simplify XML. And that will be a good thing.

re: The JSON vs XML debate begins in earnest

mikechampion — Thu, 21 Dec 2006 22:49:09 GMT

" one reason I love JSON is that it will get all us XML geeks riled up and thinking about how we can simplify XML" Yes!

I think that cross domain scripting is easier with JSON because browsers will let code within a <script> tag pull from multiple domains, but XmlHttpRequest will not. I only know what I read in comment threads, I don't have first hand experience.

re: The JSON vs XML debate begins in earnest

Dave — Sat, 23 Dec 2006 18:12:44 GMT

The ability to cross domains using <script> with JSON is very handy. Also, since most uses of JSON are with Javascript, it's an easy-to-understand format.

As for serializing graphs, don't! You serialize the data, and then the client can choose how to use that data once deserialized. What would it mean to serialize graphs, anyway? Do you mean somehow serialize the presentation details and send it over the wire?

re: The JSON vs XML debate begins in earnest

Jeremy Bowers — Sun, 24 Dec 2006 00:29:32 GMT

Serializing graphs is one specific reason that I take the position that you really ought to stick to looking at JSON as "a technology to output something that can be 'eval'ed in a browser really quickly and efficiently". If you do that, then you can actually ship down psuedo-JSON that looks something like

{nodes: [{node1: {children: []}}, {node2: {children: [node('node1'), node('node13')]}]}

(Forgive me if I got the delimiters wrong.) Then, if you have a 'node' function in the namespace you run the 'eval' in, that function can provide services to tie the graph together at the end, without a separate post-processing phase. (In this case that may not be such an advantage but there can be some cases where it is.)

And I don't guarantee that there is *still* a 100x speed advantage over XML, just that there was in Mozilla in the summer of 2005 (IIRC). But I would expect there to still be some difference as creating Javascript objects is much easier than creating DOM nodes, so even with fully optimized versions of both parsers it would make sense that eval(JSONstring) would be faster.

re: The JSON vs XML debate begins in earnest

h3 — Sun, 24 Dec 2006 03:44:31 GMT

This is a question that I had to ask myself at some point. At the begining I liked XML, but after trying JSON it's hard to tell yourself that there's nothing wrong with XML's over complexity.

I still have not chose one over the other, I just use my intuition to decide which onoe would do the better job in current context. But to be honest, I tend to choose JSON more often for it's simplicity. Why ? Because most of the tasks I need to do are simple, but for a configuration file I happily use XML :)

The bottom line is use the right tool for the right job.

And for the hardcore XML lovers who'd like to simplify it, you are not the firt. YAML is a nice alternative, the symfony PHP framework use it.

re: The JSON vs XML debate begins in earnest

fishbane — Tue, 26 Dec 2006 05:30:41 GMT

I find it hard to believe that someone would locate difficulty in marshalling a graph in the JSON-ish fashion. It is just a hash of (possibly) more complex datatypes.

I don't even care for these sorts of wars. (XML, I deal with, whatever. Sometimes the notation is handy, usually it is a pain. JSON, whatever. One link in the chain is "solved". Good job, here's a cookie. Go trade it into a career with ISO over at that desk.) I mean, other than Winer and corporate product managers, who cares about this sort of crap?

re: The JSON vs XML debate begins in earnest

mikechampion — Tue, 26 Dec 2006 20:34:00 GMT

I'm not sure if I count as "corporate product manager", but I care because we need to figure out where to invest our resources to make data programmability better/faster/easier. If JSON is going to be used in a lot of the ways XML is used today, we should probably be doing more. If, on the other hand,it's clear that JSON has intrinsic limits that most people who try this will stumble over, maybe we should discourage its use outside the AJAX realm.

re: The JSON vs XML debate begins in earnest

rogerv — Wed, 27 Dec 2006 23:54:10 GMT

Hey Michael, ran across this link where this debate is being reported:

Debate: JSON vs. XML as a data interchange format

http://www.infoq.com/news/2006/12/json-vs-xml-debate

They site this comment attributed to you:

<quote>

Mike also commented his own opinion that he sees JSON as a good solution for browser-server communication, "but not a serious contender for interoperability purposes

</quote>

Hmm, I tend to agree with this.

The Google GWT AJAX-toolset is an excellent example of where its use of JSON for the GWT async RPC (built on top of XmlHttpRequest) is very well suited. It's rather straight forward to serialize JSON as Java objects on the server-side and as JavaScript objects on the client-browser side.

However, am not tempted to switch over from XML to JSON for the messaging format in my behind-the-firewall enterprise distributed applications. What I like about XML in that regard is that can be even more loosely coupled by avoiding direct object serialization altogether and instead using a technique that I refer to as "XML data duck typing".

http://www.javalobby.org/java/forums/t78239.html%2392053977

Such is more facile to evolve a distributed application when coupling between nodes is not overly rigid. Object serialization too tightly couples and causes a distributed app to be too brittle.

Yeah, didn't take long to learn that the ease of evolving distributed app software far out-weighs any so-called convenience factor derived from object serialization.

correct link to "XML data duck typing"

rogerv — Thu, 28 Dec 2006 03:56:29 GMT

XML data duck typing

http://www.javalobby.org/java/forums/t78239.html#92053977

re: The JSON vs XML debate begins in earnest

Matt Stark — Mon, 15 Jan 2007 23:06:19 GMT

This post is limited to developing RIA's ... I am an application developer, and an architect, and a technical lead. Have many of you ever explained to a Jr. Javascript developer how to use Http requests and parse XML inside different browsers? Have you tried to explain the <script> tag? Which causes more confusion?

Points:

1) You do not require a JSON parser, nor do you need the eval statement to "process" JSON ... this is done for secuirty, the same flaws that would be prevail in JSON could surely prevail in XML depending on your 100% manditory parser requirement in the XML space.

2) Serialization is done at the data level, data is then serialized into interface UI's. Hence these graph serialization issues are mentioned here have no validity. You continue to have to "deserialize" XML into JavaScript data structures or JSON Objects. With JSON you eliminate this pointless and mutually redundant processing of your requests.

3) The purpose of JSON is the same as developing .Net Generics & as Yukon spits out custom .Net types. It talks to and how you load, manipulate and work with data in your Web Client Application layer. All we are asking for is that it spits out a pre-serialized JavaScript object rather than a huge XML file. This makes sense.

4) JSON isn't a replacement for XML and infact I'm sure most all programmers would rather work with Widget API's (EX// JavaScript API's) than understand service contracts and complexities which are inherit in working with Web Services. JavaScript is a simple 'standardized' do what you want language. Please don't standardize our data structures as it's this flexibility that allowed us to come up with this approach in the first place.

5) JSON is not a replacement for Service based stand alone applications - nor for situations where a web application consumes back end business systems VIA web services. I'd actually prefer that to be XML as there are ton's of tools avail for that approach already.

There are a lot of people here who are totally confusing this stuff as a replacement for XML. It isn't that, it's just another option for the Web Based RIA transport layer ...

Cheers,

Matt

XML and JSON - To debate, or not to debate?

Persistently Different — Tue, 23 Jan 2007 01:16:47 GMT

XML and JSON - To debate, or not to debate?

Persistently Different — Tue, 23 Jan 2007 19:13:28 GMT

JSON as I see it

Mike's Blog of Some Things IS Integration — Tue, 10 Apr 2007 16:20:35 GMT

I missed lecture on JSON last week, so I'm trying to teach myself the basics. From the book, and from a blog I was reading, it looks like JSON does the same thing as XML using the Javascript language. If...

mikechampion's weblog : The JSON vs XML debate begins in earnest

Relationship Compatibility — Sun, 08 Jun 2008 17:15:17 GMT

After seeing Douglas Crockford's talk on JSON at XML 2006 recently, I figured that some sort of great debate between XML and JSON advocates was brewing. I had been waiting for Elliotte Harold's rebuttal of what Crockford is missing, but haven't seen i