I have updated the Change Tracking file for the latest draft of the RPR FOM v2, draft19.2. The file contains three more (work) sheets: "Datatypes", "Encoding d17 omt", and "Encoding draft19 1516".

On the sheet "Datatypes" all datatypes from each module are listed, with information from the comparison to their equivalent v2d17 datatypes. Encoding differences identified during this comparison have been the source of many FOM comments in the previous weeks, and lead to most of them now being resolved.
The encoding differences to RFModulationSystemTypeEnum16, SpreadSpectrumEnum16, and SpreadSpectrumStruct will remain, as these originate from an updated SISO-REF-010 and the SISO-STD-002. (There may actually be more similar encoding differences in the final RPR FOM v2 due to such updates, see FC066.)

Furthermore there are a series of datatypes for which it is not entirely clear if there will be encoding differences between D17 and draft19 (indicated with D?). Most of them are due to (yet) undefined array and variant record encodings. This, and the remaining identified datatype encoding differences lead me to the main topic of this post: padding.

Listed in FC034, FC035, and FC036 an analysis had to be performed of the various datatypes that include padding. This is the purpose of the sheets "Encoding d17 omt" and "Encoding draft19 1516". The buffer content has been laid out for attributes/parameters using datatypes including padding, always explicit in D17 and both explicit and implicit in draft19. For each array with a variable number of elements (dynamic cardinality), three elements have been included (the middle one with empty cells). The differences between the D17 and the draft19 buffers can be identified by comparing to total number of octets required for the attribute/parameter. They have been indicated on the draft19 sheet with a (light) red background in the first column (also indicated with D on the "Datatypes" sheet).

With respect to the encoding HLAunpaddedLengthlessVarArray (FC034) my conclusion is that it is not needed. For also when normal array encoding is used there will already be no padding after each element. Hence I propose to replace this by the usage of HLAlengthlessVarArray.

With respect to HLApaddingTo32Array (FC035) and HLApaddingTo64Array (FC036) my conclusion is that these encoding are needed to retain buffer compatibility with D17. Also to the RecordStruct it can be applied in the same way as for the other datatypes that currently use it to obtain buffer compatibility again.
In addition it could be used to solve all other encoding differences too (with the exception of the IsPartOfStruct). The difference is that for these datatypes in v2d17 padding has been defined with an explicit cardinality, whereas the ones now using HLApaddingTo[32|64]Array have been defined with cardinality 0+. Only from the field name the number of extra padding octet could be concluded when using HLA 1.3 (including the interpretation that this also applies to the last element in the array!)

As discussed previously during one of the FOM meetings, it would be beneficial to the semantics when technical requirements such as padding do not appear in the object model. Although also the encoding is defined in the object model, I consider it worthwhile to investigate if all explicit padding fields can be replaced by using the appropriate 'padding-to' encoding in the 1516 object models. This would at hide such technical matters when looking at the datatype fields, while still enabling the same encoding (i.e. buffer compatibility) when using HLA 1.3.

To unsubscribe from the SAC-PDG-RPR list, click the following link: