Food fight!

@Dan,

As long as its apples against apples... I'm in! ;) :D

Ah, a debate about what to debate... a meta-debate?

As of SOAP 1.2, the SOAP acronym no longer stands for anything. This reflects the intention that SOAP simply be an XML-based message exchange framework. It's completely possible to define a JSON-based message exchange framework, but JSON itself does not do that.

Viewing JSON as lightweight XML makes more sense to me than as lightweight SOAP.

@Michael.

>>Ah, a debate about what to debate... a meta-debate?

That sounds about right ;)

>> As of SOAP 1.2, the SOAP acronym no longer stands for anything. This reflects the intention that SOAP simply be an XML-based message exchange framework.

Hmmm... not sure that one is going to fly to well. SOAP, no matter how its later defined, will always be SOAP in the mind of the developer.

I do recongize that things very much evolve past what their original acronym was intended to suggest (e.g. PHP doesn't exactly equate to Personal Home Page like originally intended) but I have a hard time buying into the idea that a protocol originally designed as a form of remote object serialization can successfully pull off the "Don't let the acronym fool you. It's about messages, not objects."

Guess time will tell.

>> It's completely possible to define a JSON-based message exchange framework, but JSON itself does not do that.

Agreed. If I was suggesting it as a replacement for SOAP, this would then require a much more elaborate system of checks and balances. I'm not suggesting that at all. Thus the lightweight comparison.

>> Viewing JSON as lightweight XML makes more sense to me than as lightweight SOAP.

How so? For example, how would one go about using JSON to create a document that could be parsed and rendered (without help from a Javascript function) by a browser that reflects the same functionality provided by direct rendering of an XML document, whether that be XHTML or raw XML that uses an xml-stylesheet PI?

XML does a great job of representing documents. JSON does a great job of representing objects. Sorry, but I just don't see the comparison.

I'd put the kibosh on this one right now. SOAP has, IMHO, become an extraordinarily heavy-weight object with very clearly defined semantics for identifying message transport information. Such information makes a great deal of sense in areas where SOAP is used heavily (financial transactions, primarily) where being able to authenticate, audit, and maintain some sense of transactional integrity are all very important.

The danger I see with pitting SOAP against JSON is that JSON is, to me, simply a somewhat anemic XML format with neither attributes nor namespaces - simpleXML with curly braces, essentially. To express what SOAP is capable of expressing in JSON would entail a clearly defined schema with all kinds of potential for namespace collision in a language that doesn't even recognize formal schemas, and would have enough security holes that you could drive a few Mac trucks through.

I see JSON messages as being roughly the equivalent of an IM message (or SMS) while SOAP is the equivalent of a special couriered Fed-Ex package carrying contracts. Yes they are both messages, but the similarity ends there.

@Kurt,

>> The danger I see with pitting SOAP against JSON is that JSON is...

Ummm... I guess the chosen title was simply too hard to overcome the fact that I happen to agree... You can't pit them against each other.

That said, you can't pit XML and JSON against each other either (I know we both agree with this point), though if you are going to make an attempt at clarifying what JSON should be used for, the comparison againsts XML makes absolutely no sense (again, I know we both agree with this), yet the comparison against SOAP, in terms of a *lightweight* alternative when you don't want or need the contract-first approach and all of the validation that comes along for the ride, does make sense when you are attempting to invoke remote processing of objects.

You wouldn't use SOAP for marking up a document (though you could easily use it to wrap a document up and send it to somewhere else as part of the payload) in the same way you wouldn't use JSON to markup a document. You would, however, use JSON to represent a lightweight serialization of an object that can be packaged up and sent to a remote location for processing, and in the same sense, you would use SOAP to perform the same functionality, yet SOAP (obviously) goes WELL beyond what JSON would even want to attempt.

So, once again... Use SOAP for heavyweight processing of objects, JSON for lightweight.

Seems pretty clear cut to me...

I lose it with the 'don't need no stinkin' binaries' arguments. These people don't work with graphics or where they have, they fail and can't figure out why.

Binary XML is a fact of life in the 3D market particularly when the data goes to the mobile systems.

JSON is a simple solution for simple problems. Because a lot of network messaging is pretty simple, it will find a broad but shallow pool to breed in. Just don't call it The Ocean and start building boats.

Multiple formats are a fact of evolution. Bray is wrong. He wishes he were right and if he keeps saying it long enough to enough crowds, some percentage will accept it and selling into the CIO markets will be easier for him but he's wrong and the IT guys will take long lunches while the CMO guys work long hours.

This is the market warping the design. Joshua Smith from KAON made an astute observation on the www-vrml list in response to my question as to why one would consider building a separate network (yes, babs, abandon the Internet and the Web) for virtual reality:

"Multicasting is fundamentally incompatible with the current business model of the internet. Since the net is built on a bunch of point-to-point POTS style connections, to implement multicasting across the backbone, the ISPs need to do LOTS more transmitting. It frees a single server to swamp the ISPs outbound channel with far more traffic than that server could ever produce over a unicast connection."

So when I see these replies to JSON vs XML and 'the fight is over', I know I'm reading a marketing blog.

It's NEVER over. Just managed to one goal or another depending on who has the upper hand at some particular tick in the simulation.

@len,

>> I lose it with the 'don't need no stinkin' binaries' arguments. These people don't work with graphics or where they have, they fail and can't figure out why.

Binary XML is a fact of life in the 3D market particularly when the data goes to the mobile systems.

I think there are other aspects to the JSON vs. (fill in the blank) that will change the balance considerably. One of the bigger ones is E4X. JSON has made significant inroads at this point less because of its size and more because of its parseability. DOM parsing is ... unpleasant at best, and once parsed, DOM structures are a pain to navigate without fifteen letter commands and a fairly in-depth knowledge of XML structure.

E4X on the other hand is making some serious inroads in that space , however. E4X parsing of XML is much faster than the equivalent DOM parsing, the objects are considerably lighter weight, yet the navigation is not all that radically different from the Javascript objects, one of the big advantages that JSON offers. For instance:

var car = <:automobile>
<:geartrain>automatic<:/geartrain>
<:color>Electric Blue<:/color>
<:make>Saturn<:/make>
<:model>Ion<:/model>
<:year>2007<:/year>
<:/automobile>;
var ccar = {
geartrain:Automatic,
color:Electric Blue,
make:Saturn,
model:Ion,
year:2007
}
print(car.color);
=> Electric Blue

print (ccar.color);
=> Electric Blue

car.engine = "Dual Cam"
ccar.engine = "Dual Cam"

print (car.engine == ccar.engine)
=> true
for ([key,value] in ccar){
print(key+":"+value);
}
=> geartrain:Automatic
=> color:Electric Blue
=> make:Saturn
...
for ([index,value] in car.*){
var key = car.*[index].localName();
print(key+":"+value);
}

The bit of clunkiness in the first line:
var key = car.*[index].localName();

is more than made up in searchability:

car.(year == 2007)

will return the car instance while

car.(year == 2006)

won't. There is no corresponding capability within JavaScript objects.

Downside, for now, is that E4X isn't yet supported in IE, only Firefox and ActionScript, but I suspect that it will end up in the IE 7.5 release, and you're seeing similar structure appearing in languages such as PHP, Ruby, Java, and in slightly different form Microsoft' Linq. It's an ECMA standard, it reasonably lets you bridge the lightweight nature of JSON with more complex structures such as SOAP, and it keeps you in the XML paradigm.

Over the years, I've found that when you have two technologies of roughly equal capabilities, it will be the one that can better bridge to the emerging infrastructure that will be dominant, regardless of any other superiority. I've also found that betting against XML is generally a way to end up broke - it causes an underlying phase shift in development that usually ends up altering the architecture of the entire system. So even though at the moment I would give the edge to JSON by its ubiquity, I think this will likely end up shifting pretty dramatically even within the next year as e4X or other objective XML technologies gain traction.

Binary XML is pretty much a foregone conclusion in terms of need, the only question is whether you can get enough people in the same room at the same time to agree on WHAT that binary format is going to look like. John Schneider (who not coincidentally was one of the key people, along with Mozilla architect Brendan Eich to develop E4X) also put together a binary XML format that now appears to be the best candidate, and once you write serializers to other XML formats (such as Java or .NET XML streams), then you can reasonably provide at least a front-gate portability until such time as Java or .NET create the corresponding general binary format into their parsers and processors.

@Kurt,

You know, why is it that I keep getting all excited about E4X and then forgetting that it exists? Force of habit?

E4X, ROCKS!!! I guess the point you bring up regarding lack of support in IE is pretty significant, though if what you are suggesting turns out to be the case (in regards to IE7.5), I can easily see E4X becoming the defacto standard that bridges the gap that in which makes JSON such an attractive lure in the first place.

In other words, I think you're spot on with your analysis... Thanks for the reminder!!!

>> Binary XML is pretty much a foregone conclusion in terms of need, the only question is whether you can get enough people in the same room at the same time to agree on WHAT that binary format is going to look like. > John Schneider (who not coincidentally was one of the key people, along with Mozilla architect Brendan Eich to develop E4X) also put together a binary XML format that now appears to be the best candidate, and once you write serializers to other XML formats (such as Java or .NET XML streams), then you can reasonably provide at least a front-gate portability until such time as Java or .NET create the corresponding general binary format into their parsers and processors.

XML is
1) DOCUMENT centric
2) Well known with lots of tools
3) FAT (SOAP is)

JSON is
1) SERIALIZATION of a structure
2) Less known and not so many tools
3) Thin (No client side libraries needed)

JSON is also a form of remote scripting (no XmlHttp request)

Xml is much more mature: quite a LOT of thought on namespaces, unicode, schemas, external file inclusions, and binary attachments (I am working on Base64 encoding in JSON, so that should be not an issue.)

@Ric,

Nice summary! Thanks!

>If you need it, use it, if you don't, don't.

That's the war. SOAP'sters ~always~ need it!

@Taylor,

> That's the war. SOAP'sters ~always~ need it!

:D Point well taken :D

Thanks for this link - I posted a reponse at http://www.json.com/2007/01/08/pay-no-attention-to-the-man-behind-the-curtain/ - but it looks like the trackback does not work.
If anyone want to participate on JSON - let me know!

@Ric,

Right on... Am looking forward to where you take the site/content!