Re: [Cbor] Consolidated set of tags for map-like entities

[Emile Cormier <[e-mail]>]

Hi Kio,

I'll add an information section on how the various tags relate to
programming language data structures. I could start with JS and C++ data
structures, and allow other folks to send or PR me the ones for other
languages.

For homogeneous key/values, it was actually my intention that the first
key/value encountered "establishes" the type for the remainder. A decoder
could reject a homogenous map where a key/value does not match the type
established by the first.

You've made me realize that the interpretation for "homogenous" could be
tricky for numeric types. For example, if the first homogenous key is a
positive integer, can the decoder assume that the following keys may also
include negative integers and floats? I'll check what it says for
homogenous arrays in https://tools.ietf.org/html/rfc8746 . It may have
already been settled there.

This also begs the question: what does "homogeneous" mean for key/value
types that are themselves arrays or maps?

Thanks for the feedback!
Emile

On Mon, Mar 15, 2021 at 4:36 PM Kio Smallwood <[e-mail]>
wrote:

> Hi Emile,
>
> Thanks for enumerating all of the possibilities. I have a few thoughts:
>
> * Would it be worth noting which programming languages and environments
> already make use of each type? For example, users of the cbor2 python
> library would only see tag 128 (equivalent to major type 5) tag 129, 130,
> for ordered and multimaps, and 132 when inter-operating with
> javascript/json. The rest would be very strange to encounter in a Python
> datastructure.
>
> * For the Homogeneous keys/values, should we (codec implementers) assume
> that the type of the first key/value encountered in the data item
> determines the type of the remainder?
>
> Thanks,
>
> Kio
>
>
> On 2021-03-12 23:50, Emile Cormier wrote:
>
> Hi Everyone,
>
> I've been corresponding privately with Prof. Bormann about a new tag I
> proposed for encoding multimaps as arrays or pairs. He's made me aware of
> your recent discussion about another proposed tag for encoding "ordered"
> maps, where the insertion order must be preserved. Carsten has indicated to
> me his desire to consolidate all of these map-related tags together.
>
> I would like to contribute to this endeavor of consolidating map-related
> tags. To get the discussion started, I would like to share with you a draft
> proposal I've written to serve as a starting point:
> https://github.com/ecorm/cbor-map-like
>
> Here's a brief summary:
>
>
>>
>> This document proposes a consolidated set of CBOR tags for map-like
>> entities involving key-value pairs. These tags encode the following
>> meta-data concerning map-like entities:
>>
>>    - the homogeneity of the key and value types,
>>    - the preservation of the insertion order of the key-value pairs,
>>    - the uniqueness of the keys, and,
>>    - the major type used to encode the key-value pairs.
>>
>>
> My interest in CBOR stems from my work on a new C++ serialization library
> that can support any JSON-like encoding. This library is closed source for
> now, but I may be able to convince my employer to make it open source in
> the future.
>
> I'm also involved with the WAMP protocol, which allows CBOR as one of its
> encodings.
>
> I'm looking forward to collaborating with you and I hope that we can come
> to a solution that satisfies everyone's needs.
>
> Cheers,
> Emile Cormier
>
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor
>
>
>