Live data from Hacker News

JSON5 Data Interchange Format

json5.org

121–130 of 157 posts

Re: JSON5 Data Interchange Format

#121

Earlier quoted context omitted.

Having a defined, predictable behaviour in JSON5 doesn't seem like it would break backwards compatibility with JSON's undefined, unpredictable behaviour. I don't think someone with an existing JSON document would complain that a JSON5 parser behaved "too predictably" when interpreting their document.

It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.

So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."

Re: JSON5 Data Interchange Format

#122

Earlier quoted context omitted.

It could change, and therefore break, the real-world behavior of a given parser that some code is knowingly or unknowingly relying on.

So could switching to another JSON parser. The response of the parser writer should be "I detected a bug in your code for you. You're welcome."

This attitude willfully ignores real-world constraints. There are plenty of "shoulds", but at the end of the day, changing behavior is changing behavior. Maybe it's worth it, maybe it isn't. But it's never free.

Re: JSON5 Data Interchange Format

#123

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

If I had to pick one feature add, it’d be allow trailing commas. That would make serializing a bit easier and less error prone.

It would also make slightly nicer diffs

Re: JSON5 Data Interchange Format

#124
post #111

Earlier quoted context omitted.

The XML Schema standard is terrible, and its mistakes and weaknesses were what drove James Clark and Murata Makoto to develop RELAX NG (REgular LAnguage for XML Next Generation). https://en.wikipedia.org/wiki/RELAX_NG RELAX NG has a clearly focused sound mathematical underpinning: regular expressions applied to trees, while XML Schema is an ad-hoc hot mess designed by committee. https://en.wikipedia.org/wiki/XML_sche…

I know this is a stupid objection, but I suspect one of the main impedances to takeup is going to be its stupid name. It's trivial I know, bikeshedding I know, but come on, "RELAX NG"? Like, how do you pronounce that? I want to say 'Relax-ung', but it sounds odd, like you're trying to say "relaxing" but failing; or maybe 'Relax Nig', but that sounds like something you'd see in an HN thread on Timnit Gebru's firing. I…

RELAX NG was a combination of Makoto Murata's work on RELAX, an acronym for "REgular LAnguage description for Xml", and James Clark's work on "TREX", an acronym for "Tree Regular EXpressions".

They could have pulled a slick smooth move and called it "TREX-LAX", for "Tree Regular EXpressions for LAnguages of Xml", which rolls off the tongue more mellifluously!

TREX-LAX: It makes your XML nice and regular, and keeps you shit moving smoothly.

https://www.browncafe.com/community/threads/fedex-and-ex-lax...

>FedEx and Ex-Lax battle for rights to promotional slogan

Re: JSON5 Data Interchange Format

#125
Past related threads:

JSON5 – a superset of JSON with comments, multiline string, trailing comma, etc. - https://news.ycombinator.com/item?id=22598401 - March 2020 (1 comment)

JSON5: JSON for humans - https://news.ycombinator.com/item?id=17375850 - June 2018 (3 comments)

JSON5 – JSON for the ES5 Era - https://news.ycombinator.com/item?id=10956943 - Jan 2016 (8 comments)

JSON5 is a proposed extension to JSON - https://news.ycombinator.com/item?id=7325735 - March 2014 (246 comments)

Show HN: JSON5 — modern JSON - https://news.ycombinator.com/item?id=4031699 - May 2012 (84 comments)

Re: JSON5 Data Interchange Format

#126
post #101

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

And XML is a very battle-tested alternative that supports every conceivable edge case and arbitrary depths of strictness and validation. There was soooo much energy poured in to making XML the One Format To Rule Them All. It has so many advanced features like strict definitions, includes syntax, support for mixed content, entities and references, comment syntax. But it turns out that 99% of users never needed any of…

That and any serialization format that has security implications is doomed to fail (or at least be derided).

Re: JSON5 Data Interchange Format

#127
post #51

Earlier quoted context omitted.

An annoying half-solution that breaks down as soon as you encounter content with both. Better imho to have one way and become good at it. I think I might even prefer trailing commas to be mandatory.

Why does it need commas at all? What purpose do they serve?

It's either commas or significant whitespace. No matter what you'll find someone who hates one or the other.

Re: JSON5 Data Interchange Format

#128
post #21

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.

One shouldn't have to think about which features of a deserializer to enable or disable in order to avoid security issues.

Re: JSON5 Data Interchange Format

#130
post #104

Regardless of how good this is or not, every time it pops up I just wonder if anybody actually gives a crap or not. JSON is one of those formats that's "good enough" even if it's stinky and it's also universally accepted that a small iteration on it with small conveniences doesn't make that much sense imho.

JSON is "good enough" for a textual, mostly human readable data interchange format. But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough". For two reasons: no comments and no multiline strings. The latter might not be important for some types of configuration, but it is for things that need something like a description that is more than a single se…

> But as a configuration format, for example the package.json file for node/npm/yarn, it is most definitely not "good enough".

Then perhaps don't use it for a use case it was not designed to address? I understand that JSON is a very handy hammer to have, but not all things are nails.

Post reply on HN