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

Anthony Ramine n.oxyde@REDACTED
Sat Mar 8 15:01:53 CET 2014


The problem is not about what is accepted, it’s about how one’s (un)parser works. Sometimes you want a streaming-like API, sometimes the whole tree, etc. The Postel principle is orthogonal here.

Furthermore, I would argue that JSON is harder to map than ASN.1 and XML. I can map any term to ASN.1 and XML with the right schemas. I can’t do that with JSON. And don’t mention JSON schemas, they don’t really exist.

-- 
Anthony Ramine

Le 8 mars 2014 à 14:42, Carsten Bormann <cabo@REDACTED> a écrit :

> It is true that different applications may need different mappings of the JSON data model into the data model of the specific application, but the following is not a valid reason:
> 
> On 08 Mar 2014, at 13:14, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
> 
>> And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield.
> 
> The “standard” has been stable since RFC 4627, which was published in July 2006.
> Since, ECMA TC39 (the committee for changing JavaScript) has decided to allow top-level numbers, primitives (false, true, null), and strings; the IETF has reluctantly followed this change and published RFC 7159 with that change.
> 
> Apart from the question whether one should accept top-level numbers/primitives/strings (and it is easy for an application to follow the Postel principle here: be liberal in what you accept and conservative in what you send), there has been no “fluctuation” in JSON.
> 
> With the acceptance of UTF-8 strings (“binaries”) into the Erlang world, there is a straightforward mapping of JSON data into the Erlang model.
> Mapping back may require a bit more application knowledge (e.g., how do you encode non-JSON concepts such as atoms?), but a basic mapping can easily be part of the standard library, certainly easier than for ASN.1 or XML.
> 
> Grüße, Carsten
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list