
The Last JSON Spec - robin_reala
https://www.tbray.org/ongoing/When/201x/2017/12/14/RFC-8259-STD-90
======
mschuster91
I'd be happy about a JSON spec that allows for comments...

~~~
SiVal
I'd rather have trailing commas, so every line can have the same format. Other
people choose JSON for their config file format, and I don't have a say in it.
I just have to do extra editing each time I reorder the lines or add a new
one, because too bad. And I have to manually edit JSON when I'm writing code
to handle other people's JSON APIs to test my code.

I'll probably never _not_ have to manually edit JSON, so JSON's insistence
that using the same format for your final line as for all the others won't
ever be allowed will remain a never ending, unnecessary nuisance in the spirit
of JavaScript itself: the "too bad, too late now" school of design. Except
that in this case, even JavaScript corrected that particular nuisance and
allows trailing commas.

~~~
dtech
If you want a JSON-ish config format, I'd recommend to check out HOCON [1],
basically a superset of JSON that fixes all he things that make it annoying
for config files.

[1] [https://github.com/lightbend/config](https://github.com/lightbend/config)

~~~
eptcyka
If we're proposing supersets of json, why wouldn't one just use yaml?

------
bcg1
> "On the oth­er hand, we still lack a de­cent high-quality JSON Schema
> lan­guage."

This turns data integration with JSON into a total nightmare. And to make
matters worse, Swagger is a total shitshow. Combine the different flavors of
JSON schema with OpenAPI/Swagger and you have are left with a regression from
SOAP/XML that approaches the same complexity with with fewer features and no
standards.

Even mf COBOL has a standard schema definition for data. For new projects I'm
still cranking out XSD definitions and doing transformations to JSON if I have
to. Even if they come out with a decent schema format I would probably skip it
and jump straight to gRPC, Thrift, or some other IDL and just continue to
treat JSON as an "also supports".

------
1wd
"we still lack a de­cent high-quality JSON Schema lan­guage"

Yes. Why?

~~~
signalsmith
The JSON Schema spec was abandoned by its original authors, and was picked up
by a series of other people with varying levels of standards experience
(myself included).

Personally, I had some promising support from my then-employer (including an
IETF connection), but then it kind of petered out, and I was buried under
other stuff and had to pass it on. The team who picked it up since them seem
pretty on-the-ball as far as I can see, so I would still recommend it as a
useful project to contribute to.

It is supported by some tools - last I heard, Visual Studio could use JSON
Schema for autocomplete and validation, as well as a couple of databases. I
used to get a few million NPM downloads a month on my validator, so someone's
clearly using it.

~~~
alexatkeplar
As far as I know, Snowplow is one of the largest active users of JSON Schema,
and we maintain one of the larger repositories of JSON Schemas on the
internet, [https://github.com/snowplow/iglu-
central](https://github.com/snowplow/iglu-central)

After something of a hiatus, we are re-starting active work on our schema
registry technology
([https://github.com/snowplow/iglu](https://github.com/snowplow/iglu)). We'd
love to be involved in new design work on the JSON Schema spec. How do we get
the old (or new!) band back together?

------
geraldbauer
FYI: I've put together an Awesome JSON (What's Next?) page [1] collecting all
JSON next flavors incl. JSON5, HJSON, HanSON, SON, CSON, USON, JSONX/JSON11
and many more. Yes, comments (in JSON 1.1), please :-) Cheers. [1]
[https://github.com/jsonii/awesome-json-
next](https://github.com/jsonii/awesome-json-next)

------
geraldbauer
FYI: For the Microservices Austria meetup I've put together a talk titled
"Meet Jason - The Universal Data Exchange Format - What's Next?", find the
notes (transcript) @
[https://github.com/geraldb/talks/blob/master/jsonnext.md](https://github.com/geraldb/talks/blob/master/jsonnext.md)
Yes, comments (in JSON 1.1), please :-). Cheers.

------
rurban
Fine that they didn't another insecurity as in the latest updates. JSON is
still the only secure transportation protocol if you don't use the RFC 9159
simplification, [http://search.cpan.org/~mlehmann/JSON-
XS-3.02/XS.pm#SECURITY...](http://search.cpan.org/~mlehmann/JSON-
XS-3.02/XS.pm#SECURITY_CONSIDERATIONS)

~~~
viraptor
What do you mean by "only secure transportation protocol"? There's nothing
inherently insecure in XML, yaml, asn1, bson, cbor, msgpack, out whatever
other popular format. Implementations may fail, but that's a different
problem.

~~~
masklinn
* YAML is pretty much inherently insecure, custom tags are part of the YAML spec and are interpreted by default by most implementations, the YAML 1.2 spec only _recommends_ defaulting to the "core" schemaor a lesser one and (AFAIK) at no point even suggests disabling explicit tags.

* XML is most definitely inherently insecure if you don't disable or strictly limit _standard_ features (entity definition/expansion, external entity definition, DTD retrieval).

I don't know about the others, I do know that ASN.1 has a long and storied
history of vulnerable implementations (and it's unclear whether there's ever
been a secure one) which tells me that even if the format is not inherently
insecure, in practical terms it is.

~~~
jnwatson
ASN.1's main issue is that it was created in the 80's, so most implementations
were programmed before folks understood software security.

Also, it has had almost 40 years of additions, so it is now a large spec.

~~~
cryptonector
ASN.1's main issue is that BER/DER/CER are awful, and they are awful because
they are TLV (tag, length, value) encoding rules. ASN.1 itself is a bit
clunky, but has _everything_ you'll ever need.

Too many people have reinvented ASN.1 badly. Protocol Buffers, I'm looking at
you!

------
jancsika
It's a lot of fun reading the spec and realizing you can hold the entire thing
in your head, and probably also make a decent implementation in the language
of your choice.

It would be neat to take that as a model and try to compose a new type of
browser where each functional module must consist of a spec that is similarly
succinct and easy to implement, perhaps with the exception of ECMAscript.

