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.
ECMA-404: The JSON Data Interchange Format [pdf]
191–199 of 199 posts
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#192Earlier quoted context omitted.
> 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…
> 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...
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#193My 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 k…
It's fine to disagree, but you need to calm down.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#194Earlier quoted context omitted.
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 frequently use it for settings.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#195Earlier quoted context omitted.
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.)
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#196Earlier quoted context omitted.
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. Co…
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 betwe…
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#197Earlier quoted context omitted.
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? JSON.stringify(JSON.parse(foo)) 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 th…
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#198Earlier quoted context omitted.
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.