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

181–190 of 199 posts

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

#181

Post by MichaelGG »

mercurial wrote: post #174
bronson wrote: post #153

Earlier quoted context omitted.

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…

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.

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

#182

Post by sneak »

rogerbinns wrote: post #144
flatline wrote: post #95

Earlier quoted context omitted.

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

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

I moved far away from family and friends to stop paying US taxes for exactly these reasons.

Vote with your tax dollars.

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

#183

Post by jlgreco »

Stratoscope wrote: post #179
jlgreco wrote: post #169

Earlier quoted context omitted.

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

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

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

#184

Post by optymizer »

VMG wrote: post #147
optymizer wrote: post #115

Earlier quoted context omitted.

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

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.

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

#185

Post by optymizer »

mercurial wrote: post #123
optymizer wrote: post #115

Earlier quoted context omitted.

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

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.

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

#186

Post by zenojevski »

jcampbell1 wrote: post #85
masklinn wrote: post #45

Earlier quoted context omitted.

> 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?

    callback(JSON.parse('{ "key":"value" }'))
Or even directly parsing the string inside of the callback.

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

#187

Post by enko »

bdisraeli wrote: post #163
jcampbell1 wrote: post #156

Earlier quoted context omitted.

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 [2] http://caniuse.com/cors

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.

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

#188

Post by pinxue »

TeeWEE wrote: post #127
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.

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: {} } ?

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

#190

Post by phpnode »

MichaelGG wrote: post #91
phpnode wrote: post #82

Earlier quoted context omitted.

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?

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

If you go with the first option, you'll inevitably run into a scenario where you have a document like this contrived example:

    {
      // this is the first ever version!
      "version": "1.0.0"
    }
And your tool goes off and increments the version number, so you end up with:

    {
      // this is the first ever version!
      "version": "2.0.0"
    }
and now your comment is a lie.

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?

Post reply on HN