6 ms·

It wasn’t “people” who saved JSON from this nonsense. It was Douglas Crockford, alone. I have been frequently annoyed at him for not allowing comments in JSON,

by oofbey 4y ago

It wasn’t “people” who saved JSON from this nonsense. It was Douglas Crockford, alone. I have been frequently annoyed at him for not allowing comments in JSON, but the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters. And Crockford very much did not want JSON to be compatible with XML - he wanted it to be a simpler alternative. So good on him.

kstrauser 4y ago
I hadn’t heard that explanation for not having comments, but if true, I want to buy him a drink.
kortex 4y ago
> the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters Oh is that why. I had heard that comments were taken out because people were using it for "parser directives" or something vague. This makes a lot more sense (although I'm sure there were all manners of hacks in the comments). Definitely a bullet dodged there.
jillesvangurp 4y ago
Oh many people have tried adding namespaces to json. It's just that these people and their solutions are consistently ignored by most developers. If you consider that Json came out of the javascript world where people tend to prefer to not specify a lot of types, it's perfectly obvious that they would probably not want or need any namespaces. Never was a thing in Json. And good on Douglas for keeping Json simple. The comment thing is annoying indeed. Using a good parser, you can usually configure it to not freak out over stuff like that. But sadly that is not very common. Elasticsearch is a positive exception. It will happily accept comments.
vbezhenar 4y ago
I don't understand why is it hard to build a JSON/XML converter? XML is represented by a DOM and DOM should be easy to convert to JSON. Actually I did just that. I made a service which uses XML for inputs and outputs and those JavaScript people kept asking me about JSON. Not sure if they were happy in the end, JSON is too verbose to my taste, but whatever. So some simple XML like <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <detail> <ns2:SendMessageFault1_SendMessageFault xmlns:ns2="http://bip.bee.kz/SyncChannel/v10/Types"> <errorCode>SCE013</errorCode> </ns2:SendMessageFault1_SendMessageFault> </detail> </soap:Fault> </soap:Body> </soap:Envelope> is represented by the following JSON monstrosity: { "name": "soap:Envelope", "attributes": [ { "name": "xmlns:soap", "value": "http://schemas.xmlsoap.org/soap/envelope/" } ], "children": [ "\n ", { "name": "soap:Body", "children": [ "\n ", { "name": "soap:Fault", "children": [ "\n ", { "name": "faultcode", "children": [ "soap:Server" ] }, "\n ", { "name": "detail", "children": [ "\n ", { "name": "ns2:SendMessageFault1_SendMessageFault", "attributes": [ { "name": "xmlns:ns2", "value": "http://bip.bee.kz/SyncChannel/v10/Types" } ], "children": [ "\n ", { "name": "errorCode", "children": [ "SCE013" ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n" ] }
- jillesvangurp 4y ago
  Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope is 99% just telling you it's a SOAP envelope, which technically is completely redundant because presumably you'd be aware of the fact that you are talking to a SOAP API. And apparently they had no schema for actually telling you anything meaningful about the error. Which is why it is represented as a string with an error code. That string is the only useful bit of information in the message. Basically the SOAP equivalent of Internal Server Error. From a parsing point of view it's horrible because all those namespaces need to be resolved and the schemas need to be processed. And of course a lot of those namespace urls don't actually have servers behind them that serve those schemas. Most of those urls never resolved to anything useful at all. The servers that were supposed to host those schemas never existed. Alternatively you just ignore all that crap and pick the message apart with XPath or a regular expression. That's what I used to do when dealing with SOAP APIs. Most of those APIs were just stupendously convoluted RPC wrappers anyway from some bit of enterprise crap ware. I never could be bothered to treat those systems with the respect they demanded from me. Way faster to just sidestep all that nonsense. Send a message, pick apart what comes back to determine success / failure and move on with your life. That's why SOAP died. Because as soon as people caught up to this being the optimal way to deal with SOAP, the next logical thing was to get rid of it entirely.
the_biot 4y ago
Not a super fan of JSON, not least because it has no comments, but that was totally the right call on his part. We'd have a ton of semi-de-facto crap to parse out of comments by now.

by oofbey 4y ago

kstrauser 4y ago

I hadn’t heard that explanation for not having comments, but if true, I want to buy him a drink.

kortex 4y ago

> the explicit reason was that people were using json comments to encode all the metadata and crap from XML like namespaces to make fully reversible JSON/XML converters Oh is that why. I had heard that comments were taken out because people were using it for "parser directives" or something vague. This makes a lot more sense (although I'm sure there were all manners of hacks in the comments). Definitely a bullet dodged there.

jillesvangurp 4y ago

Oh many people have tried adding namespaces to json. It's just that these people and their solutions are consistently ignored by most developers. If you consider that Json came out of the javascript world where people tend to prefer to not specify a lot of types, it's perfectly obvious that they would probably not want or need any namespaces. Never was a thing in Json. And good on Douglas for keeping Json simple. The comment thing is annoying indeed. Using a good parser, you can usually configure it to not freak out over stuff like that. But sadly that is not very common. Elasticsearch is a positive exception. It will happily accept comments.

vbezhenar 4y ago

I don't understand why is it hard to build a JSON/XML converter? XML is represented by a DOM and DOM should be easy to convert to JSON. Actually I did just that. I made a service which uses XML for inputs and outputs and those JavaScript people kept asking me about JSON. Not sure if they were happy in the end, JSON is too verbose to my taste, but whatever. So some simple XML like <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <detail> <ns2:SendMessageFault1_SendMessageFault xmlns:ns2="http://bip.bee.kz/SyncChannel/v10/Types"> <errorCode>SCE013</errorCode> </ns2:SendMessageFault1_SendMessageFault> </detail> </soap:Fault> </soap:Body> </soap:Envelope> is represented by the following JSON monstrosity: { "name": "soap:Envelope", "attributes": [ { "name": "xmlns:soap", "value": "http://schemas.xmlsoap.org/soap/envelope/" } ], "children": [ "\n ", { "name": "soap:Body", "children": [ "\n ", { "name": "soap:Fault", "children": [ "\n ", { "name": "faultcode", "children": [ "soap:Server" ] }, "\n ", { "name": "detail", "children": [ "\n ", { "name": "ns2:SendMessageFault1_SendMessageFault", "attributes": [ { "name": "xmlns:ns2", "value": "http://bip.bee.kz/SyncChannel/v10/Types" } ], "children": [ "\n ", { "name": "errorCode", "children": [ "SCE013" ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n " ] }, "\n" ] }

jillesvangurp 4y ago
Actually, that's what an automated translation would look like. A human would likely represent this as follows: { "errorCode "SCE013" } That SOAP envelope is 99% just telling you it's a SOAP envelope, which technically is completely redundant because presumably you'd be aware of the fact that you are talking to a SOAP API. And apparently they had no schema for actually telling you anything meaningful about the error. Which is why it is represented as a string with an error code. That string is the only useful bit of information in the message. Basically the SOAP equivalent of Internal Server Error. From a parsing point of view it's horrible because all those namespaces need to be resolved and the schemas need to be processed. And of course a lot of those namespace urls don't actually have servers behind them that serve those schemas. Most of those urls never resolved to anything useful at all. The servers that were supposed to host those schemas never existed. Alternatively you just ignore all that crap and pick the message apart with XPath or a regular expression. That's what I used to do when dealing with SOAP APIs. Most of those APIs were just stupendously convoluted RPC wrappers anyway from some bit of enterprise crap ware. I never could be bothered to treat those systems with the respect they demanded from me. Way faster to just sidestep all that nonsense. Send a message, pick apart what comes back to determine success / failure and move on with your life. That's why SOAP died. Because as soon as people caught up to this being the optimal way to deal with SOAP, the next logical thing was to get rid of it entirely.

the_biot 4y ago

Not a super fan of JSON, not least because it has no comments, but that was totally the right call on his part. We'd have a ton of semi-de-facto crap to parse out of comments by now.