[erlang-questions] No JSON/MAPS interoperability in 17.0?

Carsten Bormann <>
Thu Mar 13 21:31:16 CET 2014


On 12 Mar 2014, at 00:31, Richard A. O'Keefe <> wrote:

> RFC 7159 is ambiguous on a number of key points, and
> existing parsers differ on those points.  To give just
> one example, if you are given
> 	{"foo": 1, "foo": 2}
> should this be (a) an error, (b) equivalent to {"foo": 1},
> (c) equivalent to {"foo": 2}, or (d) something else?

The example you cite is using JSON’s syntax, but not compatible with JSON’s data model.

RFC 7159 is not ambiguous at all here (even if the spec language is slightly broken):

   An object whose names are all unique is interoperable in the sense
   that all software implementations receiving that object will agree on
   the name-value mappings.  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.

So don’t generate something like this if you want to be able to predict what the receiver will do with it.

The more interesting question is indeed how to react to input of this form.
For Erlang, “let it crash” philosophy should direct the implementer to generating an error.

However, RFC 7159 does not overspecify the behavior because detection of the error may be expensive.
So, for instance, the behavior specified in recent ECMAScript documents (use only the last value received for a duplicate key) may be more efficiently implementable than throwing an error.

> I used to believe in Postel's principle

Postel’s principle is fine (it is essentially expressing the cleverness antipattern).
It is just often misunderstood as a mandate to “accept all soup” (which is not compatible with “conservative what you send” at all!).
It should be well known in this community that failing fast is much better then trudging on with questionable interpretations of murky data.

Grüße, Carsten




More information about the erlang-questions mailing list