[Joeri]

XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end. JSON on the other hand is duck typing in web service form. You can shove any data structure in on one end, and get it back out the other end, without writing any custom code, and without actually knowing the type of the data you've sent. You could say that JSON itself is weakly typed.

The popularity of JSON is tied to the popularity of weak typing. You can more rapidly iterate your API design and codebase without those bothersome types getting in the way. The flip side of that is the end result isn't "done done". It lacks full validation of input and it lacks complete documentation. In short it's more difficult to use and more prone to bugs and security issues. I suspect that if you compare "done done" API's JSON and SOAP are probably equally productive.

Having said that, I use JSON myself. It's too easy to get going in.

[jerf]

"XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end."

This is a characteristic of the encoding and decoding layer, not the data format. Haskell's aeson library [1] is a JSON serialization library that is perfectly well strongly typed. And yes, that's strongly typed with your local domain datatypes and a relatively-easy-to-specify conversion back and forth, not merely strongly typed by virtue of having a "JSONString" type here and a "JSONNum" type there.

[1]: http://hackage.haskell.org/packages/archive/aeson/0.6.0.2/do...

[Joeri]

That's an impressively succinct way of mapping types to JSON, but it's still a mapping. There's one step for the developer between obtaining the JSON and using its data. In weakly typed languages there is no such step, the JSON data is the object you interact with in your business logic.

[jerf]

There's always a serialization step. The type of the resulting data is a consequence of the serialization technique, not the data format. I demonstrated the part you seemed to most strongly claim didn't exist, JSON <-> strong typing, but I can show you "weakly-typed" XML too. In addition to the DOM, which is a standardized "weak type" XML representation, you also have things like ElementTree http://effbot.org/zone/element-index.htm .

It is the case that JSON has a simple default weak serialization in many popular languages, and that it is a great deal of the reason for its popularity, but it is worth pointing out this is a local effect in the Javascript/Python/Perl/Ruby space, and that it hasn't got anything to do with strongly or weakly typed but rather what the target languages shipped with. There is no natural mapping for JSON in C++, C#, Erlang, Haskell, Prolog, SQL, or a wide variety of other languages (and Erlang and SQL are both fairly "weakly typed"), and even in JS/Python/Perl/Ruby there are some edge cases that can bite you if you aren't careful about exactly what the "just_decode_some_json_man()" is really doing with Unicode and numbers that may not fit into 32 bits.

(Also, I scarequote all my "weakly typed" because the term is basically ill-defined. I'm coming around to prefer "sloppy type", which is a language where all values are perfectly well strongly typed but the language and/or library is shot through with automatic coercions and/or extensive duck typing. A sloppy type language considers it a feature that a function may have a a value and not really know or care what it is.)

[6ren]

In another sense, XML is strongly typed, in that it has a schema language (XML Schema - and DTDs are part of the XML spec itself).

[mindslight]

I think part of the reason "weakly typed" is ambiguous is because it's a bit pejorative, and "sloppy type" certainly isn't helping that. Maybe just "less typed" ? It really is an engineering tradeoff of how many assumptions you want to make explicit.