On Aug 14, 2019, at 11:38, Chris Angelico
Side point: Does anyone else think it was an egotistical idea to create JSON as a non-versioned specification? "I can't possibly get this wrong". And now look what's happened.
Well, it was supposed to be an antidote to complicated specifications like XML. The syntax fits on a yellow sticky note (sort of), the semantics are “whatever your browser’s eval says”, and nobody’s ever going to use it for anything but passing around DHTML info. Even though Crockford and friends were using it to pass that info from Java services to a JS client pretty early on, they didn’t even have a JSON library for Java, just hand-written format strings they filled with the data. So, the idea that there might one day be a series of three RFCs (plus ECMA and ISO specs) was probably not so much horrifying as laughably implausible. Of course now the world has learned its lesson, so nobody will ever do that again. YAML and TOML have version numbers, even if they don’t mean what you expect and there’s no way to tell what version number a given document is. BSON has 1.0 and 1.1, each of which matches some specific version of JSON., even if that version isn’t specified anywhere, and, while there’s no way to tell which version a given document was written in, 1.1 is “mostly” backward compatible, so that’s good enough, right? The various non-XML RDF/semantic-triple notations mostly don’t have their own versions, but at least if you search hard enough you can find which version of RDF they currently notate and hope that hasn’t changed since the document was created. MessagePack has a version field, even if it’s optional and deprecated and version numbers were localtimes that couldn’t be looked up anywhere. Avro is intentionally unversioned because it will never change, according to version 1.8 of the spec. And so on. We’re in great shape for the future. :)