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

[Carsten Bormann <[e-mail]>]

On 2023-03-12, at 12:49, Wolf McNally <[e-mail]> wrote:
> 
> Carsten,
> 
>> On Mar 12, 2023, at 3:26 AM, Carsten Bormann <[e-mail]> wrote:
>> ...maybe you can explain your “no `null` in map entry values” rule next.  Isn’t that really very much about how the application processes these values?
> 
> Just like numeric values have multiple equivalent CBOR representations, map entries with “no value” also have two semantically-equivalent representations:
> 
> • omit the entry entirely, or
> • encode the entry, but give it a `null` value.
> 
> If these representations are semantically equivalent,

Big assumption.

I think you are assuming that all map entries have default values, and that all default values are `null`.

What if your default value is 10?

If course, you can use `null` as a secondary representation of that default value, unless the map entry actually has defined semantics for (non-default) `null`; you may choose to exclude such application data models, and you are.

However, if 10 is the actual default value, it is the application that needs to ensure it never expresses this value (as default values must never be expressed in deterministic representation). 

You are essentially doing half of the work in the encoder (the part that suppresses `null` if it is the default value), and leaving the other half to the application (suppressing 10).  This is at the cost of not supporting data models at all where `null` is not the default value.

I find this weird.

Grüße, Carsten