Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON5 Data Interchange Format

json5.org

Post reply on HN
Print view View original

111–120 of 157 posts

Re: JSON5 Data Interchange Format

#111

Post by samhw »

DonHopkins wrote: post #56
Deukhoofd wrote: post #27

Earlier quoted context omitted.

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.

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. It doesn't feel like the naming was considered from a normal human point of view, as opposed to from the golden mountain of abstraction.

Re: JSON5 Data Interchange Format

#112

Post by brundolf »

lucideer wrote: post #103
brundolf wrote: post #93

Earlier quoted context omitted.

Agreed. Every single feature here complicates parsing, and the only two that are worth it IMO are comments and multi-line strings (though I'm sure others disagree on which ones are most important, which is how we end up with something like this)

Comments maybe. Multi-line strings though I don't really see as very valuable. Lack of multi-line strings in JS was a very large , but infrequent pain for years before it was added. That infrequency tends toward zero for JSON: most of it is generated, and even when it is hand-authored, long strings are very much an exception in those cases (in my experience).

Two use-cases come to mind:

a) Short series' of shell commands in package.json

b) Longform content

I disagree that JSON is rarely hand-authored. You could argue it isn't the best medium for these usecases, but it definitely gets used for them either way

Re: JSON5 Data Interchange Format

#113

Post by cryptonector »

q3k wrote: post #18

… 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…

Those are fightin' words you know...

I've seen some of the endless flamewars about removing that.

The problem is ultimately that you kinda can't remove duplicate keys. You can only explain the ways in which handling them varies. I'm glossing over a lot of stuff though and I'll understand your skepticism.

Re: JSON5 Data Interchange Format

#114

Post by kybernetikos »

pitaj wrote: post #102
kybernetikos wrote: post #95

These days, JS has moved on while JSON has remained stuck in the past. There are some fairly important ones it'd be great to get a standard format for in JSON. e.g. JSON.stringify({z: 1n}) Also, round tripping ArrayBuffers, Maps, Sets, Symbols and Dates would be really useful. Sadly JSON5 doesn't address those. I'd quite like a next gen JSON not to get upset on circular references too, although that would most likely…

Bigints, dates, and buffers I can understand to a degree. Sets can easily be serialized as a json array. Maps can be serialized as a json array of arrays or as a single json dictionary if the key types are compatible.

Everything can be serialised as something else with various degress of difficulty, but one of the beauties of JSON was that it had support for most of the native types of javascript. It's nice not to have to write special logic to serialise / deserialise the way you want. In particular, the ability to round trip all the standard types would be really useful.

Re: JSON5 Data Interchange Format

#117

Post by lucideer »

brundolf wrote: post #112
lucideer wrote: post #103

Earlier quoted context omitted.

Comments maybe. Multi-line strings though I don't really see as very valuable. Lack of multi-line strings in JS was a very large , but infrequent pain for years before it was added. That infrequency tends toward zero for JSON: most of it is generated, and even when it is hand-authored, long strings are very much an exception in those cases (in my experience).

Two use-cases come to mind: a) Short series' of shell commands in package.json b) Longform content I disagree that JSON is rarely hand-authored. You could argue it isn't the best medium for these usecases, but it definitely gets used for them either way

JSON is often hand-authored as small config formats (in which your use-case (a) is relevant*), but I have never seen it hand-authored for readable "content".

Firstly longform content is often rich-text; if that's hand-authored in something that's not a wysiwyg UI, it's typically a dedicated separate file (.html or .md) which may-or-may not be later programmatically compiled to JSON.

For longform content that's not rich-text, and doesn't warrant a separate dedicated .txt file: how long is it? Do you really need multiline strings?

The only real use-case I've seen is i18n string map files, where some translations can contain a newline or two, but these are an exception; the majority of strings in those files are short.

----

* On use-case (a), this is a personal preference but I tend to prefer referencing single independent executables in these use-cases, to the modern trend of having long unreadable bash one-liners in config files.

Re: JSON5 Data Interchange Format

#118

Post by kwhitefoot »

usrusr wrote: post #51
itsibitzi wrote: post #35

Earlier quoted context omitted.

It allows you to put double quotes in the string without escaping them, which is pretty nice.

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?

Re: JSON5 Data Interchange Format

#119

Post by jagger27 »

skowron wrote: post #99
jagger27 wrote: post #96

Earlier quoted context omitted.

This is why I like backticks. ` should almost never show up in normal English text.

And, luckily, all transmitted text is normal English.

I'd be interested to see a counter example where a standalone backtick is part of normal non-computing related text. I really don't find your comment helpful. The strings where I see single and double quotes being used most frequently is with normal, yes, English text. The backtick is useful there, and that's all I wanted to say. French doesn't really have the same issue, since guillemets (« and ») are often used in place of double quotes, for example.

According to this Stack Exchange answer[0], the backtick is strictly for use in computing. I understand that it represents the grave accent, but that isn't of concern as a string delimiter, because once it is applied to a letter, for example è, it has its own unique representation.

0: https://english.stackexchange.com/questions/249406/are-backt...

Post reply on HN