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

[Emile Cormier <[e-mail]>]

I've updated the GitHub repo with a new section describing how the tags
relate to programming language containers. I only have Javascript, Python,
and C++ there for now. I'm not fluent in Python and had to consult online
documentation. It's entirely possible I got things wrong in the Python
subsection.

I have the following new thoughts:

1. We should consider adding similar tags for lists of discrete values (not
key-value pairs). For example, the homogeneity, ordering, and uniqueness
properties could be associated with programming language lists, sets, and
multisets. I think this would add eight additional tags, for a total of 20.

2. I'd like to replace the terms "homogenous/heterogeneous" with the terms
"uniform/arbitrary" for better readability.

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

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