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

151–157 of 157 posts

Re: JSON5 Data Interchange Format

#151

Post by matt_kantor »

Cthulhu_ wrote: post #6

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

> Is 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?

There's a spec: https://spec.json5.org/

Re: JSON5 Data Interchange Format

#152

Post by kybernetikos »

krapp wrote: post #149
kybernetikos wrote: post #143

Earlier quoted context omitted.

I think the main difference between my suggestion and yours is that mine has more brackets. I think type hinting and 'constructors' are basically the same thing, but I like the types to be extensible, so even in your version, I'd make the type hints things that could be provided into the NuJSON.parse function. Obviously, in your version my approach would be sounds: Map { cow: "moo", fox: null }, possibilities: Set ["…

I suppose my point was that you don't have to specify types for maps and sets at all (which I didn't do in my example,) the existing syntax already does that. [] is already a set, {} is already a map. Type hints would just be used for the values. Sending type definitions seems like a good idea. Although at that point it might as well not even be called any kind of JSON.

I don't agree that you don't have to specify types for maps and sets. For example

    {true: "yes", false: "no"}
Is not valid JSON, but

    Map [[true, "yes"], [false, "no"]]
should be valid 'NuJSON'. Maps and Sets are semantically different to Objects and Arrays, and they are Javascript standard objects that should ideally be supported by the default serialisation. The other alternative of course is to force the deserialisation code to fix them up afterwards, but that is painful.

I want to be able to stringify records with Sets, Maps, Arrays and Objects in, and have that work, even if they have behavior not supported by objects and arrays, and I don't think the user should have to fix up the output after parsing of JSON containing standard javascript objects.

Re: JSON5 Data Interchange Format

#153

Post by kwhitefoot »

kevinmgranger wrote: post #127
kwhitefoot wrote: post #118

Earlier quoted context omitted.

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.

But everyone puts the whitespace in anyway so why not just make it significant?

Re: JSON5 Data Interchange Format

#154

Post by kevinmgranger »

mindless_solips wrote: post #138
kevinmgranger wrote: post #126

Earlier quoted context omitted.

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

What?!? BREH, read Effective Java on Serialization. Every serialization format has security implications . Some try to make this explicit and probably fail in capturing all conceivable holes. Some leave this implicit to give you "fun surprises."

What "fun surprises" does JSON have, aside from "the object could be arbitrarily big" ?

Re: JSON5 Data Interchange Format

#155

Post by n_e »

usrusr wrote: post #147
staticassertion wrote: post #87

Earlier quoted context omitted.

It solves the problem like 99% of the time in my experience. It's very rare that I have content with both single and double quotes.

That's exactly my point: 99% solutions are the worst. Every 99% solution will eventually find someone relying on it, willingly or not. And it's always someone else cleaning up the mess (or failing to find the cause).

There is no mess.

The 99% case is a pretty string. The 1% case is a string with escaped delimiters.

Re: JSON5 Data Interchange Format

#157

Post by mindless_solips »

kevinmgranger wrote: post #154
mindless_solips wrote: post #138

Earlier quoted context omitted.

What?!? BREH, read Effective Java on Serialization. Every serialization format has security implications . Some try to make this explicit and probably fail in capturing all conceivable holes. Some leave this implicit to give you "fun surprises."

What "fun surprises" does JSON have, aside from "the object could be arbitrarily big" ?

A serialization format is more than just how things are described on the wire. It's also about how both sides are expected to receive and transmit it. Naive processing of JSON in certain situations can run into sharp edges like this:

https://rules.sonarsource.com/java/RSPEC-4544

Serialization formats are a part of Protocols, which essentially form the software equivalent of a spoken language between two people. Like words, the bytes can have a general syntax and expected semantic, but still be open to problematic interpretation. Like the conceptual difference between a language like English and Ithkuil. (http://www.newyorker.com/magazine/2012/12/24/utopian-for-beg...)

Like Ithkuil, some formats can specify "a little more" in a way that tries to prescribe semantic meaning and syntax such that implementing according to spec limits the opportunities for issues like this to happen.

Post reply on HN