This is what Douglas Crockford said about removing comments from JSON.
I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't.
Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
What does he mean by "people using comments in JSON, to hold parsing directives"? Am I correct in assuming it means giving directions to the parser? Any idea on how that would have been done, and the cons for doing so, and how would it have destroyed interoperability?
Sourced from plus.google.com/+DouglasCrockfordEsq/posts/RK8qyG…
Thanks for sharing this question with us. If you want to play any online card game then we suggest you to play online euchre game it is the multiplayer card game played between two team and have to take more hands.
solitaire freecell is one of most famous and classic solitaire game. You can play this game online on your computer without downloading.
soliatire games are single players game if you like to play visit to click here freecell play
Comments (in languages, configuration formats etc.) are often used to encode metadata that only specific parsers can understand.
Perhaps the most well known example of this is Internet Explorer conditional comments where you can write markup targeting specific versions of internet explorer.
<p class="accent"> <!--[if IE]> According to the conditional comment this is IE<br /> <![endif]--> <!--[if IE 6]> According to the conditional comment this is IE 6<br /> <![endif]--> <!--[if IE 7]> According to the conditional comment this is IE 7<br /> <![endif]--> <!--[if IE 8]> According to the conditional comment this is IE 8<br /> <![endif]--> <!--[if IE 9]> According to the conditional comment this is IE 9<br /> <![endif]--> <!--[if gte IE 8]> According to the conditional comment this is IE 8 or higher<br /> <![endif]--> <!--[if lt IE 9]> According to the conditional comment this is IE lower than 9<br /> <![endif]--> <!--[if lte IE 7]> According to the conditional comment this is IE lower or equal to 7<br /> <![endif]--> <!--[if gt IE 6]> According to the conditional comment this is IE greater than 6<br /> <![endif]--> <!--[if !IE]> According to the conditional comment this is not IE 5-9<br /> <!-- <![endif]--> </p>So not only the final parsed DOM that IE would construct would differ from what other browsers would construct, the parsed DOM could be entirely different among different versions of Internet Explorer.
This makes the job of people writing programs to parse HTML documents difficult because there is possibility that the program is throwing away valuable information as comments. Fortunately other browsers have not chosen to follow this trend.
JSON is intended primarily as an interchange format - that is simple, fast and decidedly NOT extendable. So it would make things complex if there were a mechanism to target specific implementations.
You can, however, always implement your custom extended JSON implementation (like MongoDB does for internal storage) and write your specialised parsers to handle that. Also you are more than free to build custom formats that are represented in JSON (like Falcor JSON graph which supports wrappers called atoms). But it is widely accepted in industry that if you are using something that claims to be a JSON parser and throw any document at it that claims to be valid JSON then the parsed outcome is exactly the same if neither of the claims are incorrect.