Re: [Cbor] Record proposal

[Emile Cormier <[e-mail]>]

On Thu, Dec 2, 2021 at 1:34 AM Kris Zyp <[e-mail]> wrote:

> I certainly empathize with the idea of keeping tags as conceptually
> distinct in terms of just adding some extra non-transformational semantic
> description to the underlying CBOR data structure. However, there is a wide
> range of "meanings" in tags, and realistically, with many, or even most
> tags, you can't really "make sense" of a payload without the "semantic
> meaning"; the meaning is what provides the direction for how to make sense
> of the data. For many tags, something needs to understand the data beyond
> just a raw CBOR structure.
>

But it should be possible for applications to agree in advance on the
meaning of the data and still be able to interpret it in the absence of
tags. This practice of embedding an extra number via a tag range is ruining
this ability for applications to agree in advance on the meaning of the
data in the absence of tags.

Your proposed tag range of 57344 - 57599 could simply be replaced by a
single tag followed by an array of size 2. The first element of that array
would be the record ID that would otherwise be encoded via the tag value.
In this way, an application expecting a record set would still be able to
interpret the data in the absence of tags, because the record IDs appear
explicitly in the data.

In section 3.4 of the spec, it says: "If a tag requires further structure
to its content, this structure is *provided by the enclosed data item*."
(emphasis mine). This clause is being violated by tags that rely on tag
range to convey additional data.


> Without the semantic meaning, there isn't data loss; raw CBOR structures
> could always be transcoded to JSON or anything else (with conventions for
> tags and such)
>

Well, that's the problem: there is no convention for tags in JSON. A
CBOR-to-JSON converter now needs to understand your record set tags, and
generate a modified structure for JSON that contains the record IDs that
would otherwise be lost.

This practice of using a tag range to avoid the few measly bytes of a
two-element tuple is making it so that once an application adopts these
tags, it can never switch to another encoding other than CBOR.

I'm afraid CBOR can no longer be considered as the binary equivalent of
JSON plus byte arrays. Instead of tags enhancing data with semantic meaning
hints, it's effectively extending the number of data types. This is what
I've realized with signed CBOR bignums which also rely on tag ranges (a
range of two): they are now a new data type that my decoder needs to
interpret if I don't want the application layer to be concerned with tags.