Rejecting duplicate property names

[Joshua Boelter]

The IETF spec says that "The names within an object SHOULD be unique." However, I can't figure out how to actually generate this constraint in a schema.

2.2.  Objects

   An object structure is represented as a pair of curly brackets
   surrounding zero or more name/value pairs (or members).  A name is a
   string.  A single colon comes after each name, separating the name
   from the value.  A single comma separates a value from a following
   name.  The names within an object SHOULD be unique.

Given a document like below, I can construct a schema that validates that each instance of 'foo' is valid, but I've unable to determine how to reject duplicates. I'd prefer to not wrap items in an array to gain access to the 'uniqueItems' keyword.

{

   "foo" : { /* some object */ },

   "foo" : { /* some object */ },

   "bar" : { /* some object */ }

}

Appreciate any insights.

Thanks,

-Josh

[Eric G]

Err... isn't your JSON parser either going to spit out an error or silently swallow one of the keys?  The keys have to be unique to even be parsed as an object. So it makes no sense for JSON Schema to validate 'uniqueKeys', that's guaranteed by JSON itself.  But maybe I don't understand the question. 

[Joshua Boelter]

That's the crux of the issue.  A document with redundant keys isn't illegal per the spec, but it's also not detectable via a schema, nor particularly meaningful. It is parser dependent on just how duplicates are dealt with. In my case, I'm creating some static content that is fed into other software as configuration input. I'd like to be able to verify a collection of json documents is valid (including no duplicate keys) with a schema.

There's another curious problem that just struck me.  How do you validate a json document with a parser that changes the input and validates something other than the actual input. Different parsers could yield different results.

[Geraint]

It's not detectable via a schema because JSON Schema places constraints on JSON data.

Something like multiple keys is actually an issue with the JSON representation - the data that results from parsing that is actually not defined (and is even inconsistent across tools).

They really are separate concerns - would it work to use a JSON linter to make sure that you have sane JSON, and then use a schema to check that the data itself is OK?  That seems like it would be a good solution to me.

Geraint