EEP-68: JSON library

Erlang/OTP Proposals Proposals: RFC
1

A new EEP (EEP68 - JSON by michalmuskala · Pull Request #59 · erlang/eep · GitHub) has been added, describing support for adding a json encoding/decoding library to Erlang/OTP. The plan is to make this part of the next RC and then OTP27.

Comments and suggestions very welcome!

22 Likes
2

Hi :wave:, a few comments on the subject.
https://www.reddit.com/r/elixir/s/UHjfZsF7C4

Thank you.

1 Like
3

Sounds like a great idea.

1 Like
4

The idea I’ve had for many years was seemingly dismissed once, but it should be more secure this time.

5

How does the new EEP-0068 relate to the long existing EEP-0018? A
section comparing the two would not go amiss.
I would like to see some mention of

MENTION as in discussion of why they are or are not in scope.

  • JSON5 features like comments, additional white space characters,
    unquoted keys, trailing commas, single-quoted strings,
    <newline> in strings, &c should at least be optionally allowed.
    None of these extensions should be generated in output.
  • STON I mention because it’s an extension of JSON5 I have to deal
    with a lot. I strongly suspect that most Erlang
    programmers don’t, so it should be mentioned as out of scope.
  • BSON is worth handling, but it really deserves its own module, so it
    should be mentioned as out of scope…
  • JSONPath isn’t as horrible as it could be, and I think it is in
    scope, at least to the point of belonging in any ‘json’ module.
    Perhaps a separate but cross-referenced EEP. But I do think it is
    worth mentioning because there is an argument for
    filter-as-you-read instead of read-then-filter so that you don’t
    have to build parts of a JSON term you don’t want, and
    conversely filter-as-you-write instead of convert then filter then write.
  • JSON Schema is something I personally dislike. In some fairly
    fundamental sense it misses the point of JSON.
    But it does exist, some Erlang programmers have had a use for it,
    and it’s worth mentioning and saying whether it should
    be accepted in the ‘json’ module at a later date or kept out.
4 Likes
6

It’s a real pity that the reddit comments aren’t here.

JSON isn’t going away AND it’s tiny.
As just one example, if I want to convert currencies in a program, I use
OpenExchangeRates.org, which returns the result as JSON.
Then there are the NoSQL data bases using JSON, like MongoDB.

Heck, IBM have extended COBOL (yes, COBOL!) with a ‘JSON PARSE’ statement
so that Enterprise COBOL for z/OS programs can process JSON data.

Sorry, I’m still chortling over this. COBOL and JSON! A marriage
made in Purgatory.
Not a library you can link. Not a subprogram you can call.
Now part of the SYNTAX of the COBOL programming language.
I think this gives us a very clear idea of what IBM think about the enduring
importance of processing JSON data to their customers…

5 Likes
7

Having been using Elixir for a number of years and have only recently started becoming acquainted with the erlang side of the things, I’m extremely excited about this! This seems like a big win!

8

Note that hot-off-the-press RFC9535 provides a standards base for JSONPath.

1 Like
9

It would be good to see a json CODEC module, implemented in Erlang, included in OTP. It would be awesome to have JSONPath support!

We use the REST Collection pattern, with advanced queries, extensively and our use cases include very large Collections. Currently we use yecc and leex to parse JSONPath query filters and implement handlers for the specific queries we support by mapping to Match Specifications used in ets or mnesia select/3,4 calls.

1 Like
10

Integration into the existing (experimental) jer encoding rules (ITU-T X.697) in the asn1 application would be nice.
Also a more complete support of the JER encoding instructions from ITU-T X.697 would be most welcome.

11

Yes, we plan to do that as soon as the pull request for JSON is merged.

3 Likes