Proposal: subsets of JSON5

[DonaldTsang]

If it is possible, I would like to see one of two things:

• a subset of JSON5 that is explicitly either an Object or Array, such that the file can have a "file signature" or a set of file signature that is 2 bytes or more (preferably 4 bytes)
• a formalized subset of JSON5 that only allows for "beautified"/"formatted" version of JSON5 with stricter grammar

[jordanbtucker]

What are the reasons or use cases for these subsets?

[DonaldTsang]

@jordanbtucker for bullet point No.1 that would be for .json5 file recognition using "magic bytes" (since Objects can be defined by its signature { followed by whitespace, } or a opening quote or double quote, and Arrays [ followed by data, whitespace or ]), and for bullet point No.2 that would be for creating a strict subset that is both aesthetically pleasing and easier to parse for those parsers with less resources to handle complex parsing.

[jordanbtucker]

What are the real world use cases for these suggestions? Why is implementing these subsets worth the issues of fragmenting JSON5 and making the syntax more complex?

[DonaldTsang]

@jordanbtucker for No.1 not more complex, rather less since we are restricting a subset within the standard e.g. the outer most layer MUST be an object or it MUST be a list, which is well defined. for No.2 though it is a matter of linting and formatting, so if there is a standard that allow weaker parsers to handle that would be useful (got the idea from https://hitchdev.com/strictyaml/ where a stricter subset actually make the standard more concrete)

[jordanbtucker]

Sorry for taking so long to get to this. I still don't know why you're proposing a subset for JSON5 documents where the top level value is an object or array. What real word problem is this trying to solve. Give me a use case where a new subset specification is necessary.

As for the formatted spec, I see several problems with this. First, no one is going to agree on what is "formatted". Does that mean two spaces or four, or maybe tabs?

Which is better?

{abc: 123}
{ abc: 123 }
{
  abc: 123
}

Should all arrays be multi-line, or is there some breakpoint?

[ 'is', 'this', 'okay?' ]
[
  'or',
  'should',
  'it',
  'be',
  'like',  // also, single quotes or double quotes?
  'this?', // trailing commas or not?
]

The list goes on. It's these types of restrictions that led to the development of JSON5.

Formatting a JSON5 document is the domain of formatting tools, like Prettier. You cited StrictYAML as an example of this. The difference here is that StrictYAML removed features of YAML (most notably flow mode) that were mostly superfluous. (Why was there ever a need for YAML to be a superset of JSON?) However, most features of JSON5 exist because they're useful. Single quoted strings can contain unescaped double quotes. Trailing commas allow for easy copy-pasting. Unquoted keys are smaller and easier to read.

If you start removing features, then you're just reverting back to something that more closely resembles JSON, so you might as well just use that. And again, formatting is something that people just don't agree upon. I use Prettier, which is very opinionated, but I still tweak it because I don't like some of its choices.

[DonaldTsang]

Yeah Prettier is the exact thing I was referring to. A standard Prettier format for JSON5 would be good.

[jordanbtucker]

Prettier already supports JSON5.