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

[Emile Cormier <[e-mail]>]

RFC8746 has this to say about homogeneous arrays:

Which CBOR data items constitute elements of the same application type is
> specific to the application.
>

I think this interpretation of "homogenous" should be the same for this
proposal.

On Tue, Mar 16, 2021 at 2:36 PM Emile Cormier <[e-mail]>
wrote:

> 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
>>
>>
>>