ECMA-404: The JSON Data Interchange Format [pdf]
ecma-international.orgNo 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.
Why do you ask him without the stubborn and arrogant comment on G+ and about trailing commas? Or is indirect better?
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):
The above code looks okay, but if the json is just spec conforming, then you are exposed to a potential XSS attack.<script> var prefs = <%= user_prefs.to_spec_conforming_json() %>; ...Most people that write json encoders are aware of the problem, but why publish a a spec that can potentially create serious security problems?
> If you allow trailing commas then you would break json parsing in all old version of IE.
No, you would break the evaluation of json as javascript in old versions of IE.
Use a real parser already.
I do use a real parser, but it is not possible for JSON-P.
I've always avoided JSONP, but this would seem doable. What am I missing?
Or even directly parsing the string inside of the callback.callback(JSON.parse('{ "key":"value" }'))Don't use JSONP.
I suppose you have a better way to do cross-platform cross-domain APIs? Enlighten us. Facebook and Google use this method, and I assume it is because there isn't a better way.
You can use CORS [1] on browsers that support it. [2] You really should use it if at all possible given your application's constraints, so you don't have to abuse GET requests and can use a JSON parser.
[1] http://en.m.wikipedia.org/wiki/Cross-origin_resource_sharing
Unfortunately CORS is not really doable if you have to support IE and need non-cookie authentication, as my company recently discovered to our sorrow. No custom headers, so goodbye to your X-Auth-Token. That has only been fixed in IE10.
Cross platform?
> you would break json parsing in all old version of IE
Why do people still care about old versions of IE?
~22% of China still uses IE6: http://www.ie6countdown.com/
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.
> Developing nations have a tendency to not use the latest and greatest.
Attention developing nations: Chromium and Firefox are completely foss. No excuse, unless you don't have an internet connection.
In which case, what do you need a web browser for?
I'm not sure about this but a lot of software might have been written specifically for IE6 and IE6 only, which might not translate well to Chrome/Firefox, and could cost businesses a lot of money, more money than they deem its worth. There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.
This is based on my experience at UPS which used a single machine using IE6 and some form of web app to control start up and shut down procedures, or something to that effect. It had no Internet connection, only LAN I believe.
I did ask myself this question too and it does seem peculiar. After some thought, my only guess is the above!
> There could be ActiveX controls and such which can't be ported to Chrome/Firefox without money.
South Korea is a huge example of this. When online banking first came to market, the only way to do it legally in South Korea was through ActiveX controls embedded in Internet Explorer because they had specific encryption requirements in the 1990s versus what IE or other browsers supported natively.
Even as recent as last year [1] it was a big deal in elections, with at least one candidate promising to end the legal requirements and allow banks to enter the modern age of browsers.
[1] http://blogs.wsj.com/korearealtime/2012/11/13/ahn-pledges-to...
Don't they have another browser around for dealing with the rest of the world though? It's not like many modern sites are going to render correctly on IE6 these days...
But all their apps work with IE6, and who cares about people trying to view Facebook while working?
If they are off in their own totally isolated little IE6 only world, I don't get why we care about them then.
Because their workers do go view Facebook. If that's a market you need to target, you need to make it work with IE6.
(There's also the whole "they get infected with everything under the sun and make the rest of us deal with them", but that's not a visual issue.)
And if the internet stops working for them because they use IE6, will they somehow manage to upgrade?
IE10, IE11 in non-standards mode also don't accept trailing commas. I don't care if you accept trailing commas, but dear god, never emit them.
They don't, it's just convenient to make their point. Pretty much any new technology isn't directly compatible with old technology.
Probably because he's very aware of it already and people here may not be.
(Meta: Why have any conversation on an HN back-channel when there are comments open at the source?)
Meta: because the comments are closed to people with a Google account that have no problems in sharing their comment on G+ publicly
> that have no problems in sharing their comment on G+ publicly
Specially now that giving in to G+ means showing up on ads.
Isn't this a design mistake in JavaScript rather than JSON?
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 was a standard MIT license with one change:
"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."
http://www.gnu.org/licenses/license-list.html#JSON
However, the current versions of json.js and json2.js on GitHub contain only this public domain dedication and disclaimer:
Public Domain.
NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.
So it's no longer an issue. You can feel free to use json2.js for good or evil.
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.
"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?
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 moved far away from family and friends to stop paying US taxes for exactly these reasons.
Vote with your tax dollars.
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.
No, I think people understand that. They just don't care, and find it amusing that other people do care/must care.
Consider it an "anti-'people who take licensing seriously' license".
Yeah, people trying to comply with laws are just hilarious. Sigh.
You can't please everybody (particularly when you are having a laugh at somebody's expense.)
That was a million dollar laugh.
Yes, a million dollars.
We have testimony in this very thread from tedivm who had to rewrite JSMin because of this laugh. That has to have been a multi-thousand-dollar project right there.
Think about the time IBM alone spent on this issue. Developers, managers, lawyers. Five grand? Easily. Maybe more.
Play out this scenario a few hundred times across the globe, and there's your million dollars.
The problem is, when you have a laugh at somebody's expense, it isn't free. It comes at somebody's expense.
And ultimately the laugh wasn't worth a penny, because the license was finally changed to a true open source (public domain) license.
> It comes at somebody's expense.
Bullshit. You are not entitled to any particular piece of software, not a single thing is taken from you when you find a software license intolerable. So something isn't licensed how you like... so what? Negotiate new terms, or move on with your life and use something else.
Bitching that something is 'Do no evil' licensed so that you cannot use it is no better than bitching that something is GPLv3'd so you cannot use it, or something is only licensed under proprietary licenses so you cannot use it.
People getting upset over licenses that render software unenjoyable to themselves is the sort of entitled bullshit that makes me want to seek out the most obnoxious license possible. Somebody should make a AGPLv3/Do no Evil hybrid license and write some mildly useful piece of software to use it for, then refuse to duel-license for any earthly fee. That should make some people squirm.
Who's bitching or acting entitled?
I made a simple economic statement, and I stand by it: The "shall be used for Good, not Evil" episode had a very real cost to it.
People did exactly what you say: negotiated new terms (like IBM) or moved on with their lives and found or wrote something else (like tedivm).
Sure, my million dollar estimate could be way off. But the cost wasn't a small one, and it wasn't just money.
Consider the many developers who saw what looked like an ordinary MIT license and didn't notice the change in the middle or understand the problem with it - maybe thought it was just a cute sentiment. So they made plans and commitments based on being able to use the code. Then their managers made commitments to their bosses and customers. And finally, they all got shot down by Legal and had to scramble to find another solution.
This cost people time and reputation.
GPL and proprietary licenses are different, because they would never be mistaken for the MIT license. A developer could easily find out if they were on the company's approved list or not. And as you know, the GPL itself forbids any changes to its text. So the same problem would be much less likely to happen with those kinds of licenses.
Not being able to use 'Do no Evil' software does not "cost" somebody who cannot use it anything. There is no "charge" going on there, nothing is being taken from them. Crockford has "cost" anybody shit. He has only chosen not to give them something on a silver platter. If Crockford is not involved in any sort of transaction, then he is not responsible for any costs incurred during tenuously related translations between other parties.
Some developer that cannot be bothered to read and understand a license does not somehow mean that Crockford is "costing" them anything. These hypothetical people fucked up, and they should fucking responsibility for themselves for god's sake. What a pathetic dodge.
Do you also think that NASA has "cost" the North Korean space program anything by not freely giving away rocket designs? Entitled to the absurd.
In this discussion I have tried to disagree like a gentleman: to be polite and respectful while making a case for something I believe to be true.
In return, you have sworn at me, called my argument "a pathetic dodge" and "entitled to the absurd," and came very close to putting words in my mouth with the North Korean strawman.
That makes it difficult to have a polite discussion, but I do want to clarify one thing.
I didn't say that Crockford was responsible for the economic cost of the old json.js license. Of course he had every right to release his code under any license he chose.
I'm simply saying that there was a cost, compared with the situation that would have existed had the code been originally released with a standard MIT license. People spent time and money that they wouldn't have if that had been the case.
Since "cost" seems to be a loaded word here, let me put it another way. It should be clear that there would have been a benefit to the world if the original json.js, JSMin, etc. had used a standard MIT license, because many more people could have used the code. That benefit was lost because of the "Evil" clause.
And, to his credit, I think Crockford eventually realized this when he re-released the code with a pure public domain dedication.
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.
That is the best Good vs. Evil story of all!
That's great news. It has been a major inconvenience to remember to use XML in all of my evil applications.
I switched a few of mine to JSON but the clients complained that this undermined the final deliverable. I was forced to switch back.
I suppose it explains how SOAP came about ...
You can feel free to use json2.js for good or evil.
The NSA breathes a sigh of relief.
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.
>But since there's no specification for the format to use, cross-browser date parsing is a mess
Wrong! Since ECMAScript 5 there is a single, standard format that all browsers will try to parse first and can predictably output: ISO 8601.
-- [02:49:29.621] (new Date()).toISOString() [02:49:29.623] "2013-10-12T01:49:29.623Z" -- [02:49:40.233] JSON.stringify(new Date()) [02:49:40.245] ""2013-10-12T01:49:40.246Z""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...
... Or if maybe they're getting everyone else's misattributed mail.
HAHAHAHA! I was scanning the comments hoping that I'd be the first to drop the 404 joke :D
I swear the moment I glanced at the title I thought it was an error message that someone accidentally posted.
My faint hopes for trailing comma support are now crushed.
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.
A) Wat.
B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.
C) You can't .join data streams without buffering, which defeats the purpose.
D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.
E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.
It's fine to disagree, but you need to calm down.
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.
Why do you manually code json?
I built a game that uses JSON for metadata and config files.
You could have used yaml.
... 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.
because that is what json is for
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.
We can't have everything as binary, because us humans can't even agree on which bit is most significant out of a list of 64/32/16/8 bits.
Also becoming commonplace as a config file format.
Yeah. On the other hand, I find YAML much better for this kind of thing. JSON is readable and writable by hand, but it's not terribly nice.
No doubt they both have their benefits, however in an environment particularly suited for working with JSON, like node.js, the additional overhead of a YAML (or other) parser may not be desirable.
Why not? After all, since JSON is not a proper Javascript subset, you still need to parse it somehow. And as JSON is a proper subset of YAML, you should get by with a YAML parser.
I think JSON being a subset of yaml is one of THE biggest mistakes YAML made, second only to making YAML a serialization format.
If so, use Protobuf, BSON and jump in the wagon for SPDY.
Why JSON at all if you don't care about reading it?
I'm not against Protobuf, BSON, SPDY and the likes, my argument is just that JSON is used over binary formats only because it's readable.
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.
I should like to visit that world one day.
json.org:
> JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write.
The primary purpose of JSON is to exchange data between machines. You may have missed that part.
Sure, it's easy to read and write by humans, because it's simple, but that's not what it is for (which is what I was disagreeing with). Humans communicate better using a natural language, not JSON, as evidenced by the fact that both our comments are in English, not JSON.
And 'easy' is relative anyway. Some of my users have to write JSON (they're not developers). It would be much easier for them if the UI had built the JSON for them, while they click on buttons.
I frequently use it for settings.
What does trailing comma support get you?
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.
Join doesn't help to stream to JSON from a database cursor. Unless you buffer the response first which is pretty horrid.
Fair point.
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 why you prepend the comma before every succeeding item in a list or map.
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.
This seems to only move the problem to the first item instead of the last one, not solve it.
The ability to be lazy.
Doesn't seem like a good reason for a spec. Laziness is partly why Javascript as a language is so messed up.
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.
It is a terrible language, though. That's common knowledge.
It is, however, wrong to say it's terrible because of laziness.
I really don't think it's fair to say it's a terrible language. It does have some terrible, horrible parts. But it also has some wonderful, awe-inspiring, mind-blowing parts. It's just not a MOR language - you have extreme lows and awesome highs.
I would say that Javascript is not too bad a language because it has those nice parts. But overall, it's still a language that feels weird given all the bad parts.
I still don't get around how `this` can be so broken.
"wonderful, awe-inspiring, mind-blowing parts"
Honest question: Such as?
closures, prototypical inheritance, the syntax for object/array literals. and I know it's not strictly part of the language, and it's deeply unfashionable to say so, but I'm quite a fan of the DOM, too.
Closures and literals are pretty basic things for many languages and very well-known.
Prototypical inheritance may have gotten much more exposure via JS, but I'm not overly impressed with it, and I hardly think it makes up for the rest of the language.
fair enough; JS introduced me to closures, so I'm a bit biased.
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.
The ability to use a for-each loop rather than an iterator or iterated for loop.
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...
ECMAScript 3 did not allow trailing commas in object literals, its section 11.1.5 is:
whereas ES5's is:ObjectLiteral : { } { PropertyNameAndValueList }
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).ObjectLiteral : { } { PropertyNameAndValueList } { PropertyNameAndValueList , }
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.
For instance, there's a standard for measuring computer equipment in controlled rooms: http://www.ecma-international.org/publications/files/ECMA-ST...
And here's an important one, DVD-RAM discs: http://www.ecma-international.org/publications/files/ECMA-ST... and their cases: http://www.ecma-international.org/publications/files/ECMA-ST...
Plus, NFC: http://www.ecma-international.org/publications/files/ECMA-ST...
It's all new to me!
Where this might be important: governments and bureaucracies which have a fondness for formally specified standards. Now they can adopt JSON.
Does this mean we can now use it for evil?
No, only for eval ;-)
That license issue wasn't about the spec, it was about the implementation. Alas.
What's so awesome about JSON? Its standard documentation is 5 pages. So simple, so awesome.
It's not XML
XML has its time and place. I'm currently doing medical data processing and I'm really glad it's XML instead of JSON.
And a lot of that's fluff (the rails diagrams, boilerplate); you could probably fit it quite comfortably on 1 side of A4 / US letter.
Why can the solidus (/) be escaped?
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 ...
thanks. was wondering the same...
Excellent standard: Contains not a single example of what actual JSON looks like in text.
"So for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E""
eww, UTF-16 surrogate pairs. Die, die, die, you scourge. (Yes, I've been working with the win32 api lately, which was designed for UCS2/UTF-16).
when has 16 bit anything been a good idea, really. TCP port ranges, looking at you too.
Char can be anything not " or \.
You don't have to escape unicode. If you want to just use Unicode and encode as UTF-8 then go nuts.
This is valid JSON:
{ "äöü": "大家好", "clef": "𝄞" }
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.
Does this mean comments will be added to the spec?
Nope, sorry.
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.
It is easy to create a json-schema by conversion in current json. How about { scheme: {}, instance: {} } ?
Not really... just add a "comment" key and then ignore it when processing.
That's pretty ugly in practice.
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.
That's an ugly workaround, not a solution. It helps breed half-baked "solutions" like the "pipe through jsmin" Crockford himself suggests.
Ultimately, it makes JSON unsuitable for configuration files (there are other reasons for that, to be fair, like over-verboseness)
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.
"simple config files" implies an optimist. Good for you, sir.
Yes, that solution OBVIOUSLY removes the need to spend an extra minute adding comments to the spec.
Also, I hope, trailing commas and binary types.
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.
I mean, JSON itself is rather silly in that it's a horrible serialization language. Its main boon is its C-style syntax, which is why it's so readable to all of us who read similar syntaxes all day. Even just a syntactical change noting which strings were base64 encoded would be nice.
It takes a minute to add anything to a spec. It increases the cost of implementing the spec a lot more than a minute though.
That's such a terrible response. "Use JSON, but then use another parser first." Sorta defeats the purpose.
The reasoning is also incredibly short-sighted.
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.
That sounds smart on first pass, but doesn't really help. If people were going to use /* @annotations / and instead put them in keys, either way, the other side gets a document that isn't the one intended*. So regardless if it parses or not, it doesn't really help.
Let's assume JSON supports comments, and `foo` is a JSON document with comments, what should happen here?
Presumably you'd say that it should return a plain JSON object without comments, right? However, with the current implementation this will return a JSON document that is identical to the input, modulo whitespace. This makes it easy to write tools that can, for example, increment the version number in a nodejs package.json file programatically. Doing this in a world where comments exist becomes extremely awkward or at the very least annoying, because either you have to write your own JSON parser that preserves comments, or you have to simply discard the comments when you're writing the file.JSON.stringify(JSON.parse(foo))If you go with the first option, you'll inevitably run into a scenario where you have a document like this contrived example:
And your tool goes off and increments the version number, so you end up with:{ // this is the first ever version! "version": "1.0.0" }
and now your comment is a lie.{ // this is the first ever version! "version": "2.0.0" }If you go with the second option, you destroy all comments whenever you write data back to the file, so they can be deemed temporary at best.
What benefit do you actually get from having comments in either scenario?
Comments are appropriate in JSON which is written by humans. If it's written by a machine, of course comments are irrelevant. Situations where you need to automatically make changes to JSON which is primarily maintained by humans are a bit of a special case that I don't think is worth optimizing for; if you feel putting comments in object fields is a better choice in this situation, you can still do that even if comments are supported.
Supporting comments makes JSON more convenient to use in more situations, and it doesn't prevent you from doing anything you can do now.
At least you can inspect the document you got with normal tools. Not so if you include comments.
And this may even encourage people into separating the data payload from the metadata, who knows?
That sounds like a "no true scotsman" argument. If comments were added to the spec then normal tools would support them just fine.
Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.
> That sounds like a "no true scotsman" argument.
I don't see how this is a "no true scotsman". Maybe a non-true "no true scotsman"?
> If comments were added to the spec then normal tools would support them just fine.
Plain comments, sure. Comments with custom annotations in them, not so much.
> Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.
Maybe this wasn't such a good idea in the first place?
How not? Comments with annotations would be ignored, just like a special annotation key. Either way, you'd end up with a parsed document that isn't what the original creator intended.
If you had /* @annotations */ and JSON allowed comments, it would still be valid JSON to do so. Using "special" keys is identical then - both require special parsers / post-processors to properly reconstruct the data.
Can anyone go into the detail of the impact ,if any, of this?
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.
the kind that correctly uses XML for everything.
Why do you believe that using XML is better than JSON in every case? Or am I misinterpreting your comment?
I took it as sarcasm. The "for everything" was the tell.
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.
Do you know any of these?
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.
"Dave" being recognised as generic name for any developer.
Out of interest, does anyone know the most common first name for a developer?
Alex
OK, could you ask Alex what the most common name for a developer is then?
I'd be interested to know if this has any impact on the "don't be evil" clause in the JSON license.
That's just a license for software available on json.org, so no impact at all.
Where is it on json.org? I can't seem to find it.
The current versions of json.js and json2.js do not have the "evil" license clause. See my other comment:
json.org/license
Thanks, I couldn't actually find a link to that page.
To summarize the top HN complaints: No date format, no comments, needlessly strict commas.
Is it too late for edn? https://github.com/edn-format/edn
Symbols that aren't "strings" are kinda neat too, and you get downright attached to arbitrary key-value mappings once you have them.
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 }
A jpg base64 encoded and gzipped is similar in size to the original jpg. It isn't as bad as you might think.
The slash and the solidus are two separate entities. I am not aware of any use of the actual solidus being used for escaping.
I am talking about BACKslash (REVERSE solidus). This says they are the same: http://en.wikipedia.org/wiki/Backslash
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.
I can't imagine why they changed the name, given that the forward slash and the solidus are not interchangeable. http://www.fileformat.info/info/unicode/char/5c/index.htm
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.
<span style="font-size:125%"><span class="Unicode">\</span></span>Ah, thanks. I was on my phone and didn't think to check the source.
EDIT: Actually, this explanation is enlightening: http://en.wikipedia.org/wiki/Slash_(punctuation)#Encoding
No Infinity and NaN :-(
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.
One problem: the standard doesn't say whether the names in an object should be UNIQUE.
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?
http://jsonlint.com/ expects [ or { first. http://zaach.github.io/jsonlint/ does not and seems to comply to the standard as I interpret it.
Figure 5: String, seems to allow actual newlines strings, that's not a subset of javascript.
Awesome, now let's get JSON Schema standardized so I can use it in production.
404 Standard Not Found
Spec not Found? ;-)
Why 404.
JSON is a great way to make your data accessible to deep packet scanning systems. Define all your protocols with JSON!
You may as well make this argument against human speech. We need secure transport, not gibberish protocols.
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.
Some DPI software also processes English, should we stop using it?
If you want security, you need encryption, not obscure encoding formats.
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.
That is the license on just one of dozens, perhaps hundreds of JSON implementations. It has nothing at all to do with standardization of the format.