"JSON stacks not only do that, but they do it better because the set of available data structures in JSON is constrained to a sensible subset" To my knowledge,

"JSON stacks not only do that, but they do it better because the set of available data structures in JSON is constrained to a sensible subset" To my knowledge, there is no "built-in" way to specify if a number should be parsed as an int or a float in JSON. The idea that one of JSON's strengths is it "is constrained to a sensible subset" is a naive view. Yes it is a strength if you are only using dynamic languages, which is valid given the nature of most of the projects talked about on YC. However, enterprise projects are usually loaded with formal specifications, UML diagrams, and usually use languages with static typing. A mixture perfect for SOAP. "you don't end up having to replicate complex classes in multiple different languages" SOAP and almost every SOAP stack have been designed to prevent this. Almost every SOAP stack has a tool with naming similar to wsdl2java, wsdl2perl, etc.,. Again, narrowly looking at SOAP without understanding the associated technologies, mostly WSDL and XSD, the technology as a whole cannot be effectively evaluated. I don't expect any of the Web 2.0 AJAX guys to understand the benefits of an implementation with such a formalized specification or broad scope. However, SOAP was created to fit the needs of large enterprises trying to interop with other large enterprises. It covers a huge scope and various edge cases. JSON covers a very narrow scope. The original post talked of SOAP as a dead technology. It isn't. Is it the best for AJAX style web services? Maybe not. Don't simply disregard it as a viable solution in all cases though. Yes, people use the transport layer agnostic aspect of SOAP. The first SOAP service I implemented used SMTP. It worked very well for sending messages to offline clients. SMTP provided queuing and storage of messages until a client came online and requested it.