# EEP-68: JSON library **URL:** \ **Category:** Proposals: RFC\ **Tags:** erlang-otp\ **Created:** [February 22, 2024, 11:59am UTC](https://erlangforums.com/t/eep-68-json-library/3322 "2024-02-22T11:59:43Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![garazdawi](https://erlangforums.com/user_avatar/erlangforums.com/garazdawi/32/175_2.png) [@garazdawi](https://erlangforums.com/u/garazdawi)\ **Post date:** [February 22, 2024, 11:59am UTC](https://erlangforums.com/t/eep-68-json-library/3322/1 "2024-02-22T11:59:43Z")
A new EEP ([EEP68 - JSON by michalmuskala · Pull Request #59 · erlang/eep · GitHub](https://github.com/erlang/eep/pull/59)) 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! ---
**Author:** ![dowusu](https://erlangforums.com/user_avatar/erlangforums.com/dowusu/32/664_2.png) [@dowusu](https://erlangforums.com/u/dowusu)\ **Post date:** [February 22, 2024, 5:27pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/2 "2024-02-22T17:27:54Z")
Hi 👋, a few comments on the subject. [https://www.reddit.com/r/elixir/s/UHjfZsF7C4](https://www.reddit.com/r/elixir/s/UHjfZsF7C4) Thank you. ---
**Author:** ![nhpip](https://erlangforums.com/letter_avatar_proxy/v4/letter/n/3bc359/32.png) [@nhpip](https://erlangforums.com/u/nhpip)\ **Post date:** [February 22, 2024, 8:01pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/3 "2024-02-22T20:01:51Z")
Sounds like a great idea. ---
**Author:** ![wangcw](https://erlangforums.com/user_avatar/erlangforums.com/wangcw/32/2065_2.png) [@wangcw](https://erlangforums.com/u/wangcw)\ **Post date:** [February 22, 2024, 10:16pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/4 "2024-02-22T22:16:15Z")
The idea I’ve had for many years was seemingly dismissed once, but it should be more secure this time. ---
**Author:** ![nzok](https://erlangforums.com/letter_avatar_proxy/v4/letter/n/4af34b/32.png) [@nzok](https://erlangforums.com/u/nzok)\ **Post date:** [February 24, 2024, 11:47am UTC](https://erlangforums.com/t/eep-68-json-library/3322/5 "2024-02-24T11:47:03Z")
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 - JSON5 [https://json5.org/](https://json5.org/) - STON - BSON - JSONPath [JSONPath -- XPath for JSON](https://www.ietf.org/archive/id/draft-goessner-dispatch-jsonpath-00.html) and [GitHub - ostrovok-team/ejsonpath: JSONPath Erlang implementation](https://github.com/ostrovok-team/ejsonpath) - JSON Schema (see Jesse for example, [GitHub - for-GET/jesse: jesse (JSon Schema Erlang) is an implementation of a JSON Schema validator for Erlang.](https://github.com/for-GET/jesse)) 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, \ 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. ---
**Author:** ![nzok](https://erlangforums.com/letter_avatar_proxy/v4/letter/n/4af34b/32.png) [@nzok](https://erlangforums.com/u/nzok)\ **Post date:** [February 24, 2024, 12:32pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/6 "2024-02-24T12:32:01Z")
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](http://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. > **[Processing JSON input](https://www.ibm.com/docs/en/cobol-zos/6.4?topic=services-processing-json-input)** > > You can process JSON text input in a COBOL program by using the JSON PARSE statement. The statement identifies the source data item containing the JSON text, and the receiving data item that is populated by the parser. 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… ---
**Author:** ![gregors](https://erlangforums.com/user_avatar/erlangforums.com/gregors/32/2234_2.png) [@gregors](https://erlangforums.com/u/gregors)\ **Post date:** [February 24, 2024, 10:26pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/7 "2024-02-24T22:26:47Z")
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! ---
**Author:** ![vances](https://erlangforums.com/user_avatar/erlangforums.com/vances/32/710_2.png) [@vances](https://erlangforums.com/u/vances)\ **Post date:** [February 25, 2024, 6:25am UTC](https://erlangforums.com/t/eep-68-json-library/3322/8 "2024-02-25T06:25:17Z")
Note that _hot-off-the-press_ [RFC9535](https://datatracker.ietf.org/doc/rfc9535/) provides a standards base for JSONPath. ---
**Author:** ![vances](https://erlangforums.com/user_avatar/erlangforums.com/vances/32/710_2.png) [@vances](https://erlangforums.com/u/vances)\ **Post date:** [February 25, 2024, 6:49am UTC](https://erlangforums.com/t/eep-68-json-library/3322/9 "2024-02-25T06:49:47Z")
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](https://www.erlang.org/doc/man/yecc) and [leex](https://www.erlang.org/doc/man/leex) to parse JSONPath query filters and implement handlers for the specific queries we support by mapping to [Match Specifications](https://www.erlang.org/doc/apps/erts/match_spec) used in `ets` or `mnesia` `select/3,4` calls. ---
**Author:** ![sg2342](https://erlangforums.com/user_avatar/erlangforums.com/sg2342/32/1233_2.png) [@sg2342](https://erlangforums.com/u/sg2342)\ **Post date:** [February 27, 2024, 9:34pm UTC](https://erlangforums.com/t/eep-68-json-library/3322/10 "2024-02-27T21:34:00Z")
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. ---
**Author:** ![bjorng](https://erlangforums.com/user_avatar/erlangforums.com/bjorng/32/174_2.png) [@bjorng](https://erlangforums.com/u/bjorng)\ **Post date:** [February 28, 2024, 4:49am UTC](https://erlangforums.com/t/eep-68-json-library/3322/11 "2024-02-28T04:49:54Z")
> [@sg2342](#): > > Integration into the existing (experimental) `jer` encoding rules (ITU-T X.697) in the `asn1` application would be nice. Yes, we plan to do that as soon as the pull request for JSON is merged.