I just happen to be working on JSON parsing today. What a mess. People don't even follow what is already there. I've seen several 'JSON' data files like this:
{} {}
That isn't valid JSON, is it? The Qt JSON parser doesn't handle it.
JSON with Commas and Comments
201–210 of 251 posts
Re: JSON with Commas and Comments
#202JSON is a data format. You actually want strict formalism in a data format, because the integrity of the data matters more than flexibility.
Comments would only serve to make humans edit the file by hand more than they do now, and to maintain it like a snowflake. You should not be maintaining your data in JSON, it should only be a momentary stop along the way to a more robust data storage system [with a schema].
Optional end commas would only encourage people to use shitty hacks to try to craft JSON without a real parser or encoder, which would 1000% end up with broken JSON all the time, which would then force vendors to support shitty broken JSON.
There's a reason it's designed like it is. Cutting corners is not going to result in better outcomes.
Re: JSON with Commas and Comments
#203Earlier quoted context omitted.
I think the reason JSON caught on outside of the javascript community is because it provided a succinct way to represent tree structures of common types (numbers, strings, dictionaries, and lists), using a syntax familiar to anyone who has used C, Perl, Python, Ruby, or Java. S-expressions might have caught on for this purpose, but they lacked a killer app (jquery, and later rails). Like JSON, they are easy to parse…
> I think the reason JSON caught on outside of the javascript community is because it provided a succinct way to represent tree structures of common types (numbers, strings, dictionaries, and lists), using a syntax familiar to anyone who has used C, Perl, Python, Ruby, or Java. I believe it's hard to explain JSON's popularity and wide adoption without talking about javascript. With javascript, JSON was right from the…
Oh yeah the "good old days" where one ran eval on the response to and XmlHTTPRequest.
Re: JSON with Commas and Comments
#204Earlier quoted context omitted.
What programming languages and platforms will your SDK be compatible with, will you also be around to port the SDK to new platforms in twenty or thirty years? Those are good reasons to agree on a standardized data format instead of a specific implementation. Pretty much every language on the planet has JSON parser libraries, and if not, it's fairly trivial to write your own (or convert the JSON data to something else…
> Pretty much every language on the planet has JSON parser libraries. Yes, but they all implement the JSON RFC slightly differently, or implement it in a totally non-compliant way.
As long as you set a limit on integer sizes (in most cases an arbitrary low limit should be fine) and don't expect any precision on float (each conversion between text and binary representation there is problematic) and don't use extensions (like comments or trailing commas) you should be quite fine with most JSON libraries. This won't cover all things, but a lot.
Re: JSON with Commas and Comments
#205I just happen to be working on JSON parsing today. What a mess. People don't even follow what is already there. I've seen several 'JSON' data files like this: { } { } That isn't valid JSON, is it? The Qt JSON parser doesn't handle it.
That looks a bit like NDJSON, assuming that the space between the objects is actually a newline.
There are libraries[1] that support parsing it and it's not too hard to do yourself, either. Some fairly popular projects use it to represent multiple responses in a single response body[2].
[1] http://ndjson.org/libraries.html [2] ElasticSearch uses it for msearch response bodys, for example.
Re: JSON with Commas and Comments
#206Earlier quoted context omitted.
It doesn’t improve the dev experience if the compilers don’t produce it, and this is really about dev comfort. You need to be able to modify JSON programatically and keep the comments, if the output is pretty-printed. Also, NaN numbers are an entire features, which they talk about above.
But why should re-jsoning keep //-comments? I never met the need for that personally. Comments help initial filename.json to be parsed by human eyes, and when it is sucked into a program (and possibly transformed), they lose meaning, even when pretty printed. For them to stay, one can put comments into real keys and/or structure their data appropriately. Even if one ultimately needs to keep json document’s human stru…
> they may use more structure-aware library to do that
Sure. I’m particularly thinking about mvn upgrades or “npm update”, which modify pom.xml/package.json files to upgrade the libraries, after checking rules (non-breaking changes or not, vulnerabilities or latest, etc).
For mvn, libraries never succeeded to modify the pom in-place without wrecking the file format, so mvn upgrades never became a thing. It’s also a demonstration that a DOM with comments in memory doesn’t ensure we can output the file as-is ;)
Re: JSON with Commas and Comments
#207Earlier quoted context omitted.
I use JSON Schema to validate JSON documents. https://json-schema.org/
Imho, statically typed languages are the ones that benefit most from schema. The current schema version is 12 but the implementations for Go, Rust, C++ and Java are all listed as draft 7. None of them support codegen either, just validation, so not exactly compelling.
In any language I eventually need to validate. Whether I do it early, using a validator, or during processing the data at later is a choice depending on the problem.
Existence of a schema definition file and checking responses against is signalling that I can trust an API vendor to be at least aware of the requirements for clients. (Whether they randomly change the schema definition or ignore it is a second question, but at least somebody once thought about formalising and it's not an complete adhoc dump of today's internal data representation)
Re: JSON with Commas and Comments
#208Earlier quoted context omitted.
> Pretty much every language on the planet has JSON parser libraries. Yes, but they all implement the JSON RFC slightly differently, or implement it in a totally non-compliant way.
As long as you set a limit on integer sizes (in most cases an arbitrary low limit should be fine) and don't expect any precision on float (each conversion between text and binary representation there is problematic) and don't use extensions (like comments or trailing commas) you should be quite fine with most JSON libraries. This won't cover all things, but a lot.
It's not a great standard if every program/library using it must explicitly state its limits for such basic things as number values.
It's very easy to do JSON wrong, to not even be aware of doing it wrong, and do it wrong in a way that limits its interoperability (see: the default behaviour of the json library in Python). This is not theoretical either, just google for 'json nan github' to see the hundreds of production programs accidentally emitting JSON that cannot be ingested by RFC-compliant parsers.
Re: JSON with Commas and Comments
#209I'm honestly surprised EDN hasn't taken off as a JSON alternative. It keeps all the good things about JSON but then adds the features people want like comments and more clear specification. The ability to tag elements to extend for specific types while allowing intermediaries to not care about those types is incredibly powerful.
Re: JSON with Commas and Comments
#210Earlier quoted context omitted.
I think that json is mostly a lightweight, human-readable data exchange format for machines to communicate. It's generally not meant to be written by humans.
But it's used for all kind of config files. And there I would like to comment why stuff is done the way it is.
That's not a problem with JSON, that's a problem with people choosing JSON as a configuration file format.
I remember seeing some conversation from the JSON authors around comments and specifically not allowing comments into the spec because they did not want people to use them as extension mechanisms, so the whole no comments in JSON thing was very much intentional.