Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECMA-404: The JSON Data Interchange Format [pdf]

ecma-international.org

Post reply on HN
Print view View original

91–100 of 199 posts

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#91

Post by MichaelGG »

phpnode wrote: post #82
swift wrote: post #76

Earlier quoted context omitted.

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.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#92

Post by logician76 »

logician76 wrote: post #89

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.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#93

Post by eliben »

angersock wrote: post #49
eliben wrote: post #40

Earlier quoted context omitted.

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.

Not really... just add a "comment" key and then ignore it when processing.

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)

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#94

Post by Touche »

undershirt wrote: post #64
Jare wrote: post #8

My faint hopes for trailing comma support are now crushed.

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?

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#95

Post by flatline »

MichaelGG wrote: post #86
tedivm wrote: post #71

Earlier quoted context omitted.

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.…

"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).

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#97

Post by jcampbell1 »

xnxn wrote: post #31
jcampbell1 wrote: post #14

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.

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.

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#99

Post by tedivm »

flatline wrote: post #95
MichaelGG wrote: post #86

Earlier quoted context omitted.

"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

Re: ECMA-404: The JSON Data Interchange Format [pdf]

#100

Post by duaneb »

angersock wrote: post #49
eliben wrote: post #40

Earlier quoted context omitted.

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.

Not really... just add a "comment" key and then ignore it when processing.

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.

Post reply on HN