I know it’s not trendy but consider XML and schema at this point. XML allows all this to be expressed and more and schema allows the creation of integration contracts that can be validated at both ends. Tooling and libraries are mature.
JSON5 Data Interchange Format
21–30 of 157 posts
Re: JSON5 Data Interchange Format
#22I have to admit that I once used python repr() as a way to pass json data. It worked. I think.
Re: JSON5 Data Interchange Format
#23… could’ve at least disallowed for one of the most batshit crazy aspects of JSON, the legal but undefined behaviour of duplicate keys in objects. > An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpre…
It would lose its "backwards compatible" property though.
Re: JSON5 Data Interchange Format
#24Is there an official standard body behind this (and json 6 mentioned in another comment), or is it a kind of loose / informal standard left up to libraries to implement? I mean comments and trailing commas will make JSON a bit more human friendly when used in e.g. configuration (package.json), but as a pure data exchange format it doesn't add much. Mind you, there's better data exchange formats than json, like XML (y…
Msgpack and protobuf do that too. I believe the rise of JSON is attributed to that it's easily human-readable, and because Javascript.
Not sure human-readability was a major consideration of JSON really, but maybe.
One of the major considerations that many seem to miss today though was simplicity of parsing: it's a much more strict syntax than actual JS so there's a lot less ambiguity in parsing it. E.g. there's no need to have layered logic for recognizing unquoted identifiers, no need to check for multiple quote types on IDs & strings, consistent comma-ing etc. In general giving the author less options will make your parser simpler.
This is notably the exact opposite of YAML's approach.
JSON5 is nowhere near as bad as YAML, but it does seem to leaving behind some of the raison d'être of JSON. Like, I hate double-quoting in JS/JSON (personal bike-shed colour preference), but surely variable quoting characters is the worst of both worlds.
Re: JSON5 Data Interchange Format
#25> "Strings may be single quoted." What's the point? I cringe every time a project uses both double quote and single quote, a mix of semicolon and no semicolon and a mix of tabs and space, .... Which one to pick isn't relevant as soon as the code base is consistent
Maybe they don't think it should be up to them to decide which one you should go with.
Re: JSON5 Data Interchange Format
#26The syntax for line breaks make it incompatible with JavaScript.
Probably not terrible because doing an eval of untrusted json would be a bad idea but they could have used back ticks which would have these useful properties:
- still JavaScript
- fewer characters
Re: JSON5 Data Interchange Format
#27I know it’s not trendy but consider XML and schema at this point. XML allows all this to be expressed and more and schema allows the creation of integration contracts that can be validated at both ends. Tooling and libraries are mature.
I want to love XML schemas, but to call them mature is a stretch. There's a bunch of important features hidden behind XSD 1.1, which is almost 10 years old by now, yet most software that validates XML on schemas does not support that yet.
Re: JSON5 Data Interchange Format
#28Couple of gripes: - Still no date type - Why make it more loose? Like "Strings may be single quoted." doesn't bring any value.
Because: ‘I am “really” angry’ Is much nicer than: “I am \”really\” angry”
and now you have two problems
is this any better?
'I\'m "really" angry, don\'t do it again!'
Re: JSON5 Data Interchange Format
#29Re: JSON5 Data Interchange Format
#30Killer feature: comments.
Sure, for APIs comments are bad. However, for configuration things are so much better when you can document or temporarily remove things, without having hacks which pollute the data.
Trailing commas are also nice to have - although we have linters for that, unfortunately some people think they're too good to need a linter.