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

[Wolf McNally <[e-mail]>]

Carsten,

> On Mar 12, 2023, at 1:47 PM, Carsten Bormann <[e-mail]> wrote:
> This can get way more complicated, even with 0xf7 “undefined” being around as well.
> 
> Exhibit 1:
> 
> https://github.com/svaarala/cbor-specs/blob/master/cbor-absent-tag.rst
> 
> But, yes, in CBOR we can always invent more values to express various forms of not-being-there, being-mostly-absent, keeping-a-position-occupied-but-not-taken, …
> (Harder to do in JSON.)  We even have NaN :-)

One of the goals of dCBOR is to encode semantically equivalent information the same way. So far I haven’t implemented `undefined` in my code, so it is rejected as not well-formed. I see `undefined` as a run-time Javascript artifact, and the only place I could see it being useful would be in, for example, reporting the result of remote execution of JavaScript code. This is such a domain-specific use case that I don’t see much point in dealing with it in dCBOR directly. Likewise with the “absent” tag you refer to above. I can see why all this might be necessary if absolute fidelity in round-tripping is a requirement, but this is a non-goal for dCBOR; indeed it *can’t* be a requirement as not all CBOR is valid dCBOR, and by extension not all JSON can be converted to dCBOR, so round-tripping is out, unless you’re also going to specify a compatible profile for dJSON.

~ Wolf