Parsing JSON with duplicate keys (json-cpp)

[ksl67]

I'm using JsonCpp v0.6.0 to parse the following JSON string:

{
   "3.7":"de305d54-75b4-431b-adb2-eb6b9e546011",
   "3.7":"de305d54-75b4-431b-adb2-eb6b9e546012",
   "3.8":"de305d54-75b4-431b-adb2-eb6b9e546013"
}

as follows:

    Json::Value  root;
    Json::Reader reader;

    // value contains the JSON string

    if (!reader.parse(value, root, false))
    {
        // parse error
    }

After the call to parse, root contains two entries in a map:

[0] first = "3.7", second = "de305d54-75b4-431b-adb2-eb6b9e546012",
[1] first = "3.8", second = "de305d54-75b4-431b-adb2-eb6b9e546013",

i.e. the first JSON record has been overwritten by the second. No errors are reported.

Is this behaviour expected? Is it correct?

I thought that an error might have been reported indicating that there is a duplicate key in the JSON string.

[BillyDonahue]

This is an interesting question. I can't find anywhere in the JSON spec where duplicate object keys are disallowed.

JSON is very explicit that it specifies no behavior, so maybe duplicate keys are actually allowed, to support languages for which "object" might mean "multimap"?

json.org varies a little from the ECMA-404 spec.

While the spec says:

"Programming languages vary widely on whether they support objects, and if so, what characteristics and constraints the objects offer. The models of object systems can be wildly divergent and are continuing to evolve. JSON instead provides a simple notation for expressing collections of name/value pairs. Most programming languages will have some feature for representing such collections, which can go by names like record, struct, dict, map, hash, or object. "

The json.org summary says: "An object is an unordered set of name/value pairs.", which the spec doesn't say. If we're deduping the keys such that the first survives then order of appearance matters. I think this is fine under the spec, but then it's hard to say the object notation is "unordered" if changing the order of appearance changes the parsed object's value. So maybe json.org is overstepping?

[cdunn2001]

I hope you mean 1.6.0!

It's interesting the the JSON specs are not clear on this point.

Anyway, gason (yet another JSON parser) would "parse" that just fine, depending on what is meant by "parse". (My nim-gason version is the fastest JSON parser that I know of, in that limited sense.) But inevitably, it's the storage model which is most interesting to users.

I'd like to alter Json::Value so that the list and map are user-supplied. Then, a multimap would be the obvious solution. An ordered map would also be possible. But that would be version 2.0.

For now, we could provide a setting to issue an error on duplicate values. Should that be part of strict-mode by default? Could we call that a minor version change to strict-mode?

[ksl67]

No, I do mean 0.6.0 and I've been using it without any problems. But I have planned an update in our next release.