About JSON grammar example - multiple same-name keys

1,841 views
Skip to first unread message

Lukáš Vlček

unread,
May 15, 2014, 4:49:12 AM5/15/14
to pe...@googlegroups.com
Hi,

to me there seems to be some confusion whether JSON is allowed to contain multiple same-name keys (like: {"key1":true, "key1":false}), the example https://github.com/dmajda/pegjs/blob/master/examples/json.pegjs states that it recognises RFC7159 as the most authoritative JSON spec source. In particular this RFC explicitly states that: "The names within an object SHOULD be unique." [1]. Should the JSON grammar example honour this as well? Or at least it should state clearly in the description that it does not follow RFC in this regard.


Regards,
Lukas

Andrei Neculau

unread,
May 15, 2014, 8:02:48 AM5/15/14
to pe...@googlegroups.com
You are taking SHOULD as MUST
 
3. SHOULD. This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

-> the pegjs parser follows the RFC

the parser behaves just like the browsers' native parser - try
JSON.parse("{\"asd\":1,\"asd\":2}")

PS: one scenario where duplicate keys may be nice to have is streaming

David Majda

unread,
May 30, 2014, 3:06:04 AM5/30/14
to Lukáš Vlček, pe...@googlegroups.com
Hi!

2014-05-15 10:49 GMT+02:00 Lukáš Vlček <lukas...@gmail.com>:
to me there seems to be some confusion whether JSON is allowed to contain multiple same-name keys (like: {"key1":true, "key1":false}), the example https://github.com/dmajda/pegjs/blob/master/examples/json.pegjs states that it recognises RFC7159 as the most authoritative JSON spec source. In particular this RFC explicitly states that: "The names within an object SHOULD be unique." [1]. Should the JSON grammar example honour this as well? Or at least it should state clearly in the description that it does not follow RFC in this regard.

RFC 7159 talks about JSON documents, not parsers. It recommends (but not requires) the JSON documents to have unique object keys. This means documents with non-unique keys are still valid.

RFC 7159 doesn't seem to bind parsers to any behavior in this regard. In fact, it notes that parser behavior differs in the wild:

When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates.

There is also no mention of this issue in section 9 ("Parsers").

Given all this, I think it would be a mistake to enforce unique keys in the JSON grammar in any way (it would then reject valid JSON documents). The current behavior, which is compatible with JSON.parse, is perfectly fine and I don't think it makes sense to change it, nor do I see a need to explicitly document it.

--
David Majda
Entropy fighter
http://majda.cz/

Lukáš Vlček

unread,
May 30, 2014, 4:34:43 AM5/30/14
to David Majda, pe...@googlegroups.com
Fully agree on this. Based on some discussions on StackOverflow it also seems that consuming JSON objects with multiple same-named fields can be assumed "ok" in some languages and some situations.

In my case I wanted to force field name uniqueness in my grammar and I wanted to take some inspiration about how to do it (and was expecting this would be in JSON grammar itself). I found a way how to do it in the meantime (though I am not very satisfied with error reporting in this case but I will probably ask about this later on ML).

Thanks,
Lukáš

Lukáš Vlček

unread,
Jul 17, 2014, 6:49:48 AM7/17/14
to pe...@googlegroups.com, da...@majda.cz
One thing I realized today and I thought it would make sense to follow up on this for completeness.:

ECMAScript 5 spec [1] says the following in chapter "16 Errors":

"An implementation must report most errors at the time the relevant ECMAScript language construct is evaluated. An early error is an error that can be detected and reported prior to the evaluation of any construct in the Program containing the error. [...]

An implementation must treat any instance of the following kinds of errors as an early error:

[...]
- Attempts in strict mode code to define an ObjectLiteral that has multiple data property assignments with the same name.
[...]
"

What the "Program" means in this context is defined (I think) in the same spec starting from "5.1.4 The Syntactic Grammar" followed by chapter "5.1.5 The JSON Grammar" stating that:

"The JSON grammar is used to translate a String describing a set of ECMAScript objects into actual objects. [...]"

So to me it seems that JSON grammar in strict mode should not allow for "multiple data property assignments with the same name". In other words, I think the peg.js JSON grammar example [2] should state that it is not ECMAScript 5 "strict mode" compliant :-)


Regards,
Lukáš
Reply all
Reply to author
Forward
0 new messages