No thanks to Mr. Crawford for not fixing the \u2028-9 issue. JSON as defined is not a subset of javascript. It is a design mistake that was pointed out to him years ago, but he is too stubborn or arrogant to fix it.
Trailing commas would make the problem worse! If you allow trailing commas then you would break json parsing in all old version of IE. The unicode line ending problem is more subtle.
I have seen people write code like (mix javascript and some templating):
<script>
var prefs = <%= user_prefs.to_spec_conforming_json() %>;
...
The above code looks okay, but if the json is just spec conforming, then you are exposed to a potential XSS attack.
Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?
Developing nations have a tendency to not use the latest and greatest. If reaching them is important for you/your product then you have to keep tracking this stuff.
No, not really. The JSON standard says you can't put raw newlines in strings, and you must write \n. Why does it say it is okay to put raw unicode line_separator rather than requiring \u2028 ? Two more lines to the spec, and DC's variant of JSON would actually be a subset of Javascript. Instead we are left with an edge case that we are going to have to worry about for the next 20 years.
Several comments mention the "Software shall be used for Good, not Evil" licensing issue in the JSON code from json.org.
The original json.js file from json.org had this copyright and license:
Copyright (c) 2005 JSON.org
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The Software shall be used for Good, not Evil.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
"This license uses the Expat [MIT] license as a base, but adds a clause mandating: “The Software shall be used for Good, not Evil.” This is a restriction on usage and thus conflicts with freedom 0. The restriction might be unenforcible [sic], but we cannot presume that. Thus, the license is nonfree."
You mean Douglas Crockford broke down and gave into the "pro-evil fanatics"?
For context, after Mr. Crockford gave IBM permission to use the license without the clause a few open source projects (mine included), also asked, and Mr. Crockford's response was a bit over the top-
> I released to free use for all with the only condition that it not be used for evil. If that is unacceptable to you, then you may not use it. Your options are to bend to the pro-evil fanatics, or to find a more reasonable hosting solution.
It's nice to see he's become a bit more reasonable.
I suspect that quite a few people wanted to use it for projects that had a high likelihood of being considered "evil" by some people, so while the licensing restriction is ridiculous, I wonder if it didn't actually serve its intended purpose? (I'm thinking DoD/intel stuff primarily).
It's not just a matter of being ridiculous, it's a matter of being unenforceable and impossible to comply with. If I created an open source project that used a "no evil" library then how am I supposed to restrict the actions of my users? How do we even define "evil" (which has no legal definition)?
That last bit is the tough one. Some people define homosexuality as evil, others define it with things like women going to school. DC obviously isn't that extreme, but he's using a term in a legal setting that can be defined by different people in completely different ways. This makes it so no business can use this code, and even things like open source projects should be extremely weary.
What this essentially did was allow Douglas Crockford to claim that he open sourced his code while actually keeping it closed and forcing people to go through him if they actually wanted to legally use it. While I'm sure plenty of people use it regardless, there's nothing preventing DC from simply stepping in and forcing them to stop. If he had used a real open source license that would be impossible, but as it stands all he has to do is walk over and say "I consider that evil" and you need to rip his library out.
This isn't just hypothetical. I had to remove code from an open source project because of this. It's why I wrote JShrink, as an open source replacement for the JSMin libary. https://github.com/tedivm/JShrink
As Richelieu said "Give me six lines written by the most honourable of men, and I will find an excuse in them to hang him."
I pay US taxes and the US government kills people around the world. They also subsidise farmers which puts others around the world at a disadvantage contributing to poorer economic circumstances for them. The US incarcerates a large number of people. If the project benefited me or anyone else paying US taxes, then hasn't it benefited the US government, and hence evil?
I believe that's quite the point. It makes you actually question whether what you're doing could possibly be construed as evil. Ridiculous, yes, and legally troubling, but thought provoking for sure.
Not really thought provoking at all. Just opens legal issues as anyone can construe anything as evil. It's not like moral relativism is anything special or novel or needed to be brought into a software license.
As others have pointed out, this is just the license on one implementation, not the spec, so it's not really as big a deal.
I don't know how thought provoking it really is. It's so general, and the range of human opinion is so vast, that it could cover almost anything. For some people, typing up this comment on a fairly power-hungry computer, in an area where most of the electricity comes from burning coal, could be considered evil. Sitting here could be evil. Not sitting here could be evil.
I actually enjoyed going to my boss at TIM Group (financial services software, in the City of London) and asking him whether he was comfortable asserting in our open-source audit that we did Good rather than Evil. He thought for a moment - and knowing him, he really did think about it - and then opined that he was, indeed, comfortable that we were doing Good. We proceeded to use JSON happily for years.
I really (really really) wish they'd added a way to represent dates. Dates were left out of the original JSON spec since javascript doesn't define a syntax for date literals. You have to execute the Date() constructor to make them. Since JSON was supposed to be a subset of non-executing javascript, dates were excluded from JSON.
That left serialization to a string as the only way to transfer dates. But since there's no specification for the format to use, cross-browser date parsing is a mess (see http://dygraphs.com/date-formats.html ). JSON + dates = sadness.
The non-executing constraint on JSON was a good idea in its early days, when eval was the most common way to parse JSON, but now that there are dedicated parsers for all environments, it's not as much a priority. But we're still stuck with kludgy workarounds for the lack of native date support in JSON.
If there's still concern about using the Date constructor, the spec could require that the date be prefixed to avoid execution: "0 || new Date(...)". Real parsers would extract the date correctly, eval would just return 0.
No, not all browsers, and not all of ISO 8601. Safari only added ISO 8601 Zulu parsing in the last few months, and IE only at version 9. Neither support explicit timezones yet. Which means there's still a large population of browsers that will choke. As I said, date parsing is a mess.
In any case, my general point still stands: dates are the only "data" type (i.e. not a function, regex, etc.) which is not supported by JSON. So even if there were a usable universal serialization format, you'd still need to post-process the results of the JSON parser to convert the strings into dates.
Hilarious! ECMA-404. My neighbor's address is 404 West Whatever Street and I can't look at their mailbox without wondering if mail is correctly delivered there...
Trailing comma's, really?? Its is so fucking ugly and inconsistent. Either ALWAYS have traling commas, or never have it. And since the meaning of a comma is separate two items, a trailing comma makes no semantical sense, the only reason you want it because
A) youre lazy
B) you dont know howto properly serialize to json (youre doing string manipulation probably
C) you never heard about the .join function
D) you dont know how to read a diff
E) you dont do syntax checks before you deploy your code
Trailing commas reduce cognitive load. I don't need to consider whether an element I'm adding is the last item in a set; there isn't an edge case. Also, I can more quickly scan a DIFF and see the change in a file.
I was crossing my fingers for that too. I create JSON files a lot. It's annoying when I'm _reordering_ elements separated by newlines. It's annoying when I'm generating JSON files and I have to code in a special case to skip the comma. It breaks the consistency that I just desire as a programmer.
... The irony of yaml being human and version control friendly but including massive amounts of serialization mechanism vs. json being for data exchange and having extremely rudimentary serialization features aside.
no, that's not what json for. JSON is for exchange data between machines. We already have data interchange formats for humans, we call those 'languages'.
Yes, yes. And we could also have everything as binary. Now, UNIX people decided long ago to use plain text to communicate between processes, mostly because it's infinitely easier to read - and makes it possible to edit by hand if you need to. Have to interface with a REST API which consumes JSON and you want to do some testing? Open your text editor anywhere curl is installed, and you're done. That's pretty damn convenient.
It must be nice to live in a world in which you never have to read JSON. Or, for that matter, any other format which is used to exchange data between machines - binary included. Worse, sometimes even XML.
It simplifies generating JSON, since you don't need a special case for the last item, and it simplifies editing it, since you don't need to do something special when adding a new item at the end. I can't see any benefit to not having it, honestly.
> It simplifies generating JSON, since you don't need a special case for the last item
In which language can't you do array.join(",")? You can even do that in Java with one of the myriad of string libraries. I haven't hand-coded joins since (at least) six or seven years.
For large code bases, you don't break git blame by adding in new arguments. And it's one less thing to think about when editing your code: always add a comma, never worry about errors because you need to add a comma to the line above.
This is what I do, but it basically just has the effect of making the first item special instead of the last. That's usually better in practice, though.
You've slightly improved the problem by moving it away from the last item on the list, but you've now screwed up the first item. You can no longer insert a first-item using the same format, and instead of a trailing comma bug you can get a starting comma bug.
If I could down-vote this lazy, drive-by, language bashing I would. Back up 'so messed up' or keep comments like this to yourself, they don't help the discussion.
LOL! Obviously I struck a nerve. I thought it was obvious to everyone the problems of Javascript as a language. For laziness, how about weak typing and defining a class using a function. Plenty more examples, but you can do your own research if you are curious. BTW I like and use Javascript, but it is still a crap language.
Anyone compiling a list of talking points for why s-expressions aren't so crazy after all, should add this to the list. (Just append it to the list, no comma required; i.e. pun sorta intended.)
I'm actually very confused by it - I thought the specification for ECMAScript 3 already specified trailing comma support for JSON. Will need to look it up...
And while JSON is strongly inspired by javascript's object notation, it is not actually javascript: their strings are subtly incompatible (JSON allows U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR in quoted strings, javascript does not).
Great stuff. On a side note, this ECMA website is fantastic. I've never seen it before, but it's really quite interesting to change the URL to random numbers to find out what other standards ECMA has done.
Oh, god - apparently, it's to support IE5.5 and to allow "</script>" to be embedded in a "<script></script>" pair and not be interpreted as closing the script. I wish I hadn't asked, and I wish I hadn't then gone and found out ...
I realize that. I'm just sad to see UTF-16 vestiges living on, in current specs. Who can fathom how much misery and billions of dollars in wasted productivity (byte order marks - fun!) that wrought upon the IT landscape....
Python has an upper case \UXXXXXXXX literal that seems a lot cleaner.
This sucks, because it limits the usability of JSON. It should interfere with its being a serialization and interchange format, but for configuration files anything without comments is useless.
JSON is a data interchange format, you dont want comments in data that is interchanged. HTTP headers dont have comments. Put your comments in your doc explaining your json data format... which sucks for json, cause json doesnt have a formal schema language, ok json-schema, but thats sucky.
A better solution is to use YAML for things like configuration files. It's more pleasant for a human than JSON would be even if it supported comments, and there are nice parsing libraries available for every popular language.
Not necessarily. If you're naming your keys nicely, and using an easily-understandable structure, for simple config files, you shouldn't really need comments.
Shoving binary into JSON is rather silly--base 64 encode it, or consider using a binary format better suited to your need.
As for adding comments to the spec--again, the idea is to prevent shadow information showing up that isn't obvious to a conformant parser.
If you give people the ability to smuggle data in comments, that's exactly what they'll do. At least this way people know that what they're doing isn't "to spec" and that their sneaky parsers are not following the rules.
That's the syntax equivalent of removing guardrails from a dangerous mountain pass to scare drivers into slowing down.
This is probably going to sound like asking someone to catch sunlight in a teacup, but wouldn't it have been more productive to stress the importance of syntax adherence and consistency rather than remove it altogether? There's really nothing stopping someone from abusing the rest of JSON for silly things so leaving comments out seems a bit redundant.
That's pretty laughable. What exactly prevents people from putting parsing directives in a special object key or list entry at the beginning of the file?
that would be valid JSON, so it's not a problem. Standard tools can still parse it and reliably turn it into native objects. The same is not at all true when comments exist. People will start putting /* @annotations */ that can only be ready by certain tools which breaks the whole point of JSON - it's a data interchange format.
I'm guessing it may help bring JSON to use in the more restrictive companies that are scared of 'nonstandard' file formats. The kind that currently uses XML for everything.
Poe's Law; it's impossible to tell. There are presumably some companies who think that using XML for everything is appropriate, so it stands to reason that there actually are people who believe that as well.
More of a formality than anything else. Since JSON was already defined by Javascript, formalizing it doesn't really engrave the standard, it just gives it the recognition that its not just some whacky thing created by Dave.
They say JSON is not for binary and won't change. With a backslash (oops reverse solidus) you could send binary data - eg an image. { myimage: "\01\02\03" } of course, not efficient. You could base64-encode it and put that in a string. I think some syntax for binary would be useful - eg { myimage: 0x010203 }
Interesting. It says they're the same thing, but then the two characters listed on the page (the regular backslash and the Unicode variant) are rendered noticeably differently.
Look at the HTML. The "unicode variant" is rendered differently because the code tells the browser to render it differently, not because it's a different character.
Would have been nice if a standard format for hyperlinks were added. This lacks the elegance of pure JavaScript but it would make it possible to create strict RESTful APIs that don't violate HATEOAS or includes links as some sort of extension.
JSON is a subset of JavaScript (a few bugs notwithstanding) so you must conform to it's spec and then JSON adds further restrictions on the language in it's spec.
So the standard says a valid JSON text complies to the JSON value grammar. So a valid JSON text can be just one JSON value, like a number or true or false.. however JSON linters always say they expect a { or [ ... who is right?
Not really even a close metaphor, since human speech isn't a internet standard I could build devices against and sell to customers as compliant.
Considering that DPI devices are already sold to parse json-desribed protocols dynamically, I think you are a bit uninformed about my statement. It is not hypothetical.
If he want to be formalis JSON e he should use a standard license for the software.
I accept "The Software shall be used for Good, not Evil." is amusing and "good" but must cause difficulties for people wanting to package with other software under standard licenses.