Source: Airbus Group ( Oliver Kellogg)
DDS-XTypes 1.2 section 220.127.116.11.3 (Collection Types) on page 30 bottom states:
> * Element type: The concrete type to which all elements conform. (Collection Elements
> that are of a subtype of the element type rather than the element type itself may be
> truncated when they are serialized into a Data Representation.)
> In the case of a map type, this attribute corresponds to the type of the value elements.
> Map types have an additional attribute, the key element type, that indicates the type of the
> may key objects.
I believe there is a typo in "type of the may key objects" - drop the word "may" ?
The paragraph continues:
> Implementers of this specification need only support key elements of
> signed and unsigned integer types and of narrow and wide string types; the behavior of
> maps with other key element types is undefined and may not be portable.
Is there a particular reason why enums were excluded from the supported key types?
Reported: DDS-XTypes 1.2b1 — Fri, 15 Sep 2017 13:51 GMT
Disposition: Closed; No Change — DDS-XTypes 1.3
Corrections were already applied in the formal document
The typo mentioned in the description was already corrected in the formal DDS-XTYPES 1.2 document.
Allowing enum to be used as key discriminator would introduce problems with type interoperability or data reception. Given that a similar behavior can be achieve at the application level (using the ordinal value associated with each enumeration literal) it seems better to leave the specification with the existing limitation.
Updated: Tue, 8 Oct 2019 17:55 GMT