Awesome, now let's get JSON Schema standardized so I can use it in production.
ECMA-404: The JSON Data Interchange Format [pdf]
121–130 of 199 posts
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#122Earlier 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.
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?
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#123Earlier quoted context omitted.
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#124Several 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, includi…
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#125Earlier quoted context omitted.
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#126My 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
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#127Earlier quoted context omitted.
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#128Earlier quoted context omitted.
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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#129They 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.
Re: ECMA-404: The JSON Data Interchange Format [pdf]
#130Earlier quoted context omitted.
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.)