Do not throw on duplicate keys about json5 HOT 6 CLOSED

I know that this issue has been long-closed, but I did want to express my preference for the other decision - repeating a key in a structure, as far as I can see, always represents an error or oversight of some kind, and it's a mistake I've made several times myself! I think it would be great if we returned to the original behaviour. This thread contains some interesting discussion: http://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object

an interesting point being that whilst ECMA-404 doesn't say anything about duplicate keys, RFC 7159 says that they "should" not occur. It would be possible in time, I guess, to have a JSON5 standard that adopted one or other of these choices without saying that we had "deviated" from the JSON behaviour which seems to mostly result from accidents in parser implementation.

I know this decision is unlikely ever to be revisited but I thought I'd put my opinion on record :)

from json5.

Agreed, thanks!

If JSON5 is not backwards compatible with JSON anywhere, that's definitely worth an issue/bug (like this) instead of the wiki I think.

from json5.

Although I'm not advocating for it, disallowing duplicates is a one word change to the JSON RFC from:

The names within an object SHOULD be unique.

To

The names within an object MUST be unique.

Now what I would advocate for is this: there's a strong argument to be made for JSON5 to disallow duplicates while guaranteeing fully backward compatible with JSON.

JSON5 should require that implementations default behavior set as "MUST", and for implementations that support it, an optional flag for "SHOULD". ( Crockford's implementation would not have an optional "SHOULD" flag since the implementation doesn't support "SHOULD" and only supports "MUST" behavior). This allows strict backward comparability while permitting all the advantages of deduplication.

Other related thoughts:

Crockford's implementation is a great example of desired behavior. Although the standard allows it, the implementation from the author precludes it.

Disallowing duplcates would conform to the very small I-JSON RFC. The author of the I_JSON RFC, Tim Bray, is also the author of the JSON RFC 8259

These are all authority figures, and I would consider it reasonable for JSON5, which makes minor "improvements" to JSON, to do this.

There's also security problems and interoperability problems with duplicates:
https://bishopfox.com/blog/json-interoperability-vulnerabilities.

from json5.

@zamicol Thank you for your suggestions. You make some interesting points. Would you be willing to echo these ideas as a new issue on the JSON5 spec repo?

Issues on this repo are now primarily for changes to this library rather than the spec.

from json5.

@amb26 I'm in agreement with you that having duplicate keys in a JSON document is bad form. However, the major ECMAScript implementations—V8, SpiderMonkey, and Chakra—all allow duplicate keys. And they should, because according to the official spec, once the parser validates that a JSON document conforms to the JSON syntax, it parses the document as ES5 (almost). Note that RFC 7159 only describes the structure of JSON documents but not the API and implementation requirements.

All this considered, one of the core values of JSON5 is being backward compatible with JSON—in document structure, API, and implementation.

I do see some value in logging a warning when duplicate keys are encountered, especially since JSON5 is meant for handwritten data documents where duplicate keys are more likely to occur.

I appreciate your opinion and research on this matter and welcome any further comments. And don't be too quick to think that these issues won't be revisited. Just look at some of the earliest issues for this repository and note how many times the community went back and forth on some pretty important features :)

from json5.

Thanks @jordanbtucker. I submitted the suggestion: json5/json5-spec#38

from json5.