Subject: [Cbor] 0 vs 0.0 in latest draft CBOR bis draft

From: Burt Harris <[email-masked]>
Date: Wed, 26 Dec 2018 17:08:42 +0000

Under the heading of "Specific Data Models" in the current draft, the spec says:

  *   Specific data models can also specify what values (including values of different types) are equivalent for the purposes of map keys and encoder freedom. For example, in the generic data model, a valid map MAY have both 0 and 0.0 as keys, and an encoder MUST NOT encode 0.0 as an integer (major type 0, {{majortypes}}).  However, if a specific data model declares that floating point and integer representations of integral values are equivalent, using both map keys 0 and 0.0 in a single map would be considered duplicates and so invalid, and an encoder could encode integral-valued floats as integers or vice versa, perhaps to save encoded bytes.

I'm concerned this goes too far by contradicting the JSON/JavaScript data model.      There simply is no way for an encoder written in JavaScript to distinguish between 0.0 and 0.

At a higher level, the idea of developing a CBOR specific data model still strikes me as introducing technical risk.   I think I understand the (and appreciate) intent, but if it's going to take a "special data model" for the most broadly implemented language on earth perhaps we should consider the wisdom of basing CBOR bis on still uncertain data model.    Well tested language-independent data models exist already, e.g. IDL.   Have you considered adopting one of them?