DDSXTY14 — XCDR2 serialization of sequences of non-primitive elements

When serializing a sequences of non-primitive elements, the XTYPES spec requires serializing a DHEADER ahead of serializing the number of elements and each element. This is rule (12)

Arrays of non-primitive elements also serializing the DHEADER but not the number of elements. This is rule (9)

I think it would make sense to modify or at least relax these rules.
At a minimum arrays and sequeces of enumerated types and bitmask types should not have a DHEADER as it does not add information beyond what is available knowing the number of elements and size of each element. That it, they should behave as primitives (basically they are integers).

Additionally it may be better to not have the DHEADER at all for sequences and arrays. Or at least for sequences or arrays whose elements are final.

Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).

*Introduce XCDR3 with improved serialization *

9/27/2023 We agreed that if a change was to be made introducing XCDR3 would be the cleanest approach.
We took the action item to find what else people would like to improve in the serialization/deserialization process and bundle them all into the XCDR3 format.

Regarding the approach we discussed the possibility to introduce the definition of a "fixed length vs variable length" type.
These are types where the size of serialization is the same for all objects of that type.

• This includes all primitive types.
• This includes enumerated types or bitmask, or bitset?
• Also final structures whose members recursively don't contain optional members, strings, sequences, maps, unions, or any appendable or mutable types, (future any type), or typedefs of the above.

Given this definition we would not put DHEADER when serializing arrays/sequences of element-type that are "fixed-length" types.

15/Dec/23 Erik Hendriks added a comment in DDSXTY14-56 suggesting that if we go to an XCDRV3, we might want to think about allowing @must_understand and @optional to match for @appendable types

6/2025 further RTF discussion at the Denver meeting tentatively agreed that the identified changes are not sufficiently compelling to justify the complexity and interoperability issues that would be caused by having XCDR3 so we decided to close the issue as deferred. A future revision of the specification could consider doing this if sufficiently compelling serialization changes are identified.