Re: [Cbor] Record proposal

[Kris Zyp <[e-mail]>]

I have updated my tag registration proposal/submission at
https://github.com/kriszyp/cbor-records to use 1+2 tag entries, which
hopefully makes this a much less intrusive registry entry. I have also
updated the proposed tag definitions to also support up-front
declaration of a set of record structure definitions for a data item
("around" that data item, like the packed approach, as you suggested),
in addition to the current inline record definitions (which can be
scoped with record definitions and should follow a well-specified
order for when they can be referenced by subsequent references). I
hope this offers flexibility for encoders that have all structures
known a-priori and streaming encoders (that do not), while still
maintaining nearly the same mechanics for decoders. Let me know if you
think this looks reasonable.
Thank you!
Kris

On Thu, Nov 11, 2021 at 9:15 PM Kris Zyp <[e-mail]> wrote:
>
> > Actually, stats would be very interesting.
> > I was assuming that the 1+1 setup comes with a number of 1+2 referencing records, the hit from going to 1+2 there as well would be relatively insignificant.
> > Number are better than assumptions!
>
> You are definitely right, using 1+2 tag for defining records is pretty
> insignificant (around a quarter of percent in my tests). Anyway, I put
> together some tests comparing CBOR packed, record structures, and
> combinations with a couple test data structures, with my library, for
> the sake of further comparisons:
> https://gist.github.com/kriszyp/b623b85d2dc25ac9e3b07d8f39df9307
>
> Anyway, seeing this, I am happy to go ahead and update my proposal to
> use a 1+2 tag for defining records. And thinking about this, I don't
> think my proposal necessarily even needs to mandate the tag ids used
> for referencing records since those are dynamically assigned and
> explicitly specified by the encoder itself (encoder obviously must not
> conflict and use tag ids that will be used for other purposes), albeit
> can encourage a certain range (presumably from the first-come
> first-serve range).
>
> Do you have any preference for a tag id to use? It looks like 279 is
> the next in the contiguous block, but sounds like choosing aesthetic
> characters is the new preference (29299/"rs" perhaps).
>
> Anyway, thanks again for the helpful feedback, really appreciate it!
>
> Thanks,
> Kris