161–170 of 251 posts
Earlier 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.
Earlier quoted context omitted.
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.
Do you really want generated code to manipulate JSON? I'm not sure there is a demand for that.
Earlier 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.
It's actually 2020-12, which is two versions after Draft 7 (they shifted from Draft n to YYYY-MM after Draft 7, and since then have had 2019-09 and 2020-12.)
And that's true of most languages, though there is some 2019-09 support. (It really doesn't help that there is also OpenAPI which baked in a variant—“extended subset”—of Draft 5 JSON Schema.)
Earlier quoted context omitted.
I've used BER encoded ASN.1 at work quite a bit, and the reason you won't see it much are pretty much: - HORRIBLE schema format. - Very few FOSS libraries, most of which are terrible. I used Lev Walkins asn1c[0], which I patched slightly and coupled with some semi-generic code that walks the generated data structures to emit JSON (for debugging purposes). [0] https://github.com/vlm/asn1c
I've implemented (a subset of) ASN.1 for an SNMP server I wrote for an embedded monitoring system, so I know the pain, but it was one thing to implement it for a compact binary format. Inflicting it on a text-based format just seems like it'd multiply the pain...
It was very handy to be able to use jq on the data.
Earlier quoted context omitted.
There are both JSON [1] and XML [2] encoding rules specified for ASN.1... I have never seen it used in the wild, but realising it's a thing is horrifying enough. [1] https://www.itu.int/rec/T-REC-X.697/en [2] https://www.itu.int/rec/T-REC-X.693/en
I've used BER encoded ASN.1 at work quite a bit, and the reason you won't see it much are pretty much: - HORRIBLE schema format. - Very few FOSS libraries, most of which are terrible. I used Lev Walkins asn1c[0], which I patched slightly and coupled with some semi-generic code that walks the generated data structures to emit JSON (for debugging purposes). [0] https://github.com/vlm/asn1c
Earlier quoted context omitted.
There are both JSON [1] and XML [2] encoding rules specified for ASN.1... I have never seen it used in the wild, but realising it's a thing is horrifying enough. [1] https://www.itu.int/rec/T-REC-X.697/en [2] https://www.itu.int/rec/T-REC-X.693/en
I've used BER encoded ASN.1 at work quite a bit, and the reason you won't see it much are pretty much: - HORRIBLE schema format. - Very few FOSS libraries, most of which are terrible. I used Lev Walkins asn1c[0], which I patched slightly and coupled with some semi-generic code that walks the generated data structures to emit JSON (for debugging purposes). [0] https://github.com/vlm/asn1c
The page addresses that there are other alternatives/supersets. I think the most common one that has decent adoption is JSON5. I would like to see why the author chose to do yet another format, vs adopt JSON5.
> Yes, Doug Crockford deliberately removed comments from JSON but people keep putting them back in. If we’re going to have comment-enriched JSON (e.g. for human-editable configuration files), we might as well have a standard one. The text "deliberately removed comments from JSON" links to https://web.archive.org/web/20150105080225if_/https://plus.g... where Doug not only explains the reason, but also a solution which…
> Doug not only explains the reason Just because he had a reason to give doesn't mean it wasn't a bad reason. His stated reasoning failed with hindsight. (a) People already do what he thought was preventing (custom parser behavior) by removing comments, (so his choice failed to prevent what he wanted to prevent) (b) people have already created dozens of JSON parser variants that accept comments, because we really wan…
For comments in plain JSON a common approach is to use keys like "comments" or "description" in object literals. As for trailing comma the only real issue in practice is noisy unified diff output. But for JSON word diff or similar works better in any case when the trailing comma is not an issue.
Earlier quoted context omitted.
> Rather than keep making new variants of JSON, it'd be nice if somebody could convince some mainstream language maintainers to just update their built-in JSON parser to add optional features like skipping over comments and not caring about trailing commas. I think the most correct way to deal with this problem is to get IETF and ECMA to update the JSON standard first. Honestly, comma-after-final-element and comments…
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.
- There is no minimum/maximum number/integer value (or sizes) defined in the RFC [1] - you have no guarantee that a number you emit will be readable by all RFC-compliant parsers, so the only safe option is to emit all numbers as strings. There is also no behaviour mandated for parsers that encounter numbers/integers outside of their supported size range, so you can't rely on any fail-safe behaviour.
- There is no standardized behaviour for repeated dictionary keys (which are allowed but 'discouraged' per spec), and different implementations will treat them in different ways. This is especially painful when trying to build JSON middleware that does a parse/check/modify/emit of arbitrary data.
- Implementations in some languages (eg. Python) are non-RFC compliant by default (`python.dumps` will emit NaN/Inf/-Inf, even though the RFC forbids that), and generally all implementations are similar-but-different-enough to trip you up [2].
All three of these have bitten me in the past when trying to interface with something that spoke JSON, and as such I refuse to design new systems that use JSON as any source of truth.