Re: [Cbor] dCBOR moving from numerically-typeless systems

[Wolf McNally <[e-mail]>]

Carsten,

When I said that not all JSON can be converted to dCBOR, I was speaking of generic JSON, not I-JSON as defined in RFC 7493.

The key difference between Gordian dCBOR and (CBOR, JSON, and I-JSON) is that none of the latter have *determinism* as a primary goal; *interoperability* in I-JSON’s case yes, but *determinism* as such, no. Therefore, dCBOR is necessarily strict about how it encodes and what it accepts as valid for decoding.

For example, I-JSON is all about what practices SHOULD be followed for maximum interoperability, and as such an I-JSON decoder may accept or reject duplicate map keys. It also specifies that that top-level objects SHOULD be arrays or objects, primarily due to the way some legacy codecs were written.

In contrast, a dCBOR decoder has no problem accepting any type at the top level, but MUST reject duplicate map keys. So neither I-JSON nor CBOR are strict subsets of the other, and this is understandable because interoperability is a non-goal for dCBOR, and determinism is a non-goal for I-JSON.

While I think conformant I-JSON should be translatable to dCBOR, there are definitely elements that cannot make the round trip. For instance, JSON (hence I-JSON) has no representation for INF, -INF, or NAN, while CBOR (hence dCBOR) does.

Notably, neither JSON nor dCBOR have a representation for `undefined`, while CBOR does.

So while I think there are good reasons to define profiles of these data representation standards as subsets of each other, and while dCBOR is in fact a strict subset of CBOR, focusing on what is a subset of what in the whole data representation ecosystem makes it easy to lose sight of dCBOR’s primary goal: determinism.

~ Wolf

> On Jun 25, 2023, at 9:29 AM, Carsten Bormann <[e-mail]> wrote:
> 
> On 2023-03-12, at 23:02, Wolf McNally <[e-mail]> wrote:
>> 
>> it *can’t* be a requirement as not all CBOR is valid dCBOR, and by extension not all JSON can be converted to dCBOR,
> 
> Non sequitur.
> 
> Of course not all CBOR is valid dCBOR.
> You could design dCBOR so that all valid CBOR can be converted to valid dCBOR, but you chose to (slightly) subset the generic data model instead.
> I’d say, quite appropriate for dCBOR’s area of application.
> 
> The part I don’t understand is about JSON: JSON’s generic data model already is a pretty heftily proper subset of CBOR.
> (JSON does not define a generic data model, but I-JSON RFC 7493 does record the common assumptions that are needed to make JSON’s generic data model interoperable).  
> What is in there that can’t be converted to your design of dCBOR?
> 
> Grüße, Carsten
>