cbor-wg / edn-literal

Application-oriented literals for CBOR extended diagnostic notation
Other
0 stars 7 forks source link

Naming ambiguity with Extensible Data Notation #57

Closed chrysn closed 1 month ago

chrysn commented 1 month ago

There exists a format described at https://github.com/edn-format/edn that uses the same TLA (different pronunciation, eed-n vs. ee-dee-en, but that doesn't help with search engines) and that has a somewhat similar information model.

I'm having a hard time assessing how actively that other EDN is being used – the spec last changed 11 years ago, and many Rust implementation crates are deprecated, but neither is a conclusive indicator for the format being dead (the former can be b/c it is stable, the latter can be b/c it has been around for so long that the first crates just became obsolete), and a fedi chat indicated it's a big thing around Clojure.

It's really late to change the name, and had it not been for a toot I picked up by chance, it would have been missed – the ecosystems are just quite far apart, and there's only so-and-so-many three-letter acronyms. So I'd say that it's probably OK to stick with the name, especially given that disambiguation as "CBOR EDN" is easy. Nonetheless, I'd like to doublecheck that with @cabo, @OR13 and the CBOR group, to ensure it's an informed decision.

chrysn commented 1 month ago

There was fast and decisive feedback in the thread at https://mailarchive.ietf.org/arch/msg/cbor/DuJl5AH3_y9lvr2S_Wq3PQ-Ku1w -- closing this as "we discussed it, stick with EDN, and call it CBOR EDN when there is danger of confusion"