The syntax for an optional string (parameter_range: string [0..1]) can cause confusion to parsers of the XMI as to whether the syntax is for being optional or fixed length.
Optional strings would be better defined as an optional TypeDef.

This affects parameter_range and typical_value in the descriptor_type struct within Subsystem_Domain -> Subsystem_Control

The relationship between plot_association_type and sensor_track_type should be a composition such that the sensor track contains a collection of plot_association_type objects rather than a collection of references which can not be resolved as the plot_association_type does not have an id and is not published separately on another topic.

The plot_association_type contains both a plot_subsystem attribute and a plot_id attribute which contains a subsystem_id attribute.

These both refer to the same piece of information and therefore one is redundant and should be removed.

The class plot_summary_type was expected to be a topic type, but it isn’t mapped to an operation in the PIM – so it isn’t. We need to add a suitable operation to the Provide_Plots or Provide_Sensor_Orientation interface.

The PSM section of the document was omitted from the submission and should be re-instated

The IDL4 language introduced the @optonal annotation that indicates that a structure member is optional. This is also supported by DDS-XTYPES. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    @optional elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    @optional range_rate_type range_rate;
};

The OARIS IDL does not take advantage of this. Instead, it uses an older pre-IDL4 idiom using an extra "union" type. For example:

// radians per second
typedef double azimuth_rate_type;
// radians per second
typedef double elevation_rate_type;
// meters per second
typedef double range_rate_type;

// a simple union type, to represent an optional value
union polar_velocity_elevation_rate_type switch (boolean)       {
    // the value when present
    case TRUE : elevation_rate_type value;
};

// a simple union type, to represent an optional value
union polar_velocity_range_rate_type switch (boolean)            {
    // the value when present
    case TRUE : range_rate_type value;
};

// Velocity defined in a polar reference frame as a described by a coordinate
// specification object
struct polar_velocity_type            {
    // The rate of change in azimuth corresponding to the velocity
    azimuth_rate_type azimuth_rate;
    // The rate of change in elevation corresponding to the velocity. 
    // Optional as some sensors provide no elevation information
    polar_velocity_elevation_rate_type elevation_rate;
    // The rate of change in range corresponding to the velocity. 
    // Optional as some sensors provide no range information
    // (e.g. most passive sensors)
    polar_velocity_range_rate_type range_rate;
};

The extra union types result in more code generated to serialize and deserialize the data, increasing the size of the binary and decreasing performance.

Moreover, the use of the @optional annotation allows for a more natural and optimized language mapping. For example, the recent IDL to C++ mapping maps optional members to the standard std::optional which is more natural for a C++ programmer.

Some of the IDL files contain the construct:

#pragma keylist ...

This annotation is specific to OpenSplice. It comes from a time before there was a standardized way to indicate DDS keys. It is not standard not supported by other DDS vendors.

With the adoption of DDS-XTYPES and later IDL4 there is now a standard @key annotation supported by the recent versions of DDS from all the vendors.

Moreover, the maintainers of OpenSplice are now focused on a new codebase (Cyclone DDS) and recommending users to migrate to it (see
https://github.com/ADLINK-IST/opensplice), and Cyclone DDS also supports the @key annotation as described in https://cyclonedds.io/content/guides/supported-idl.html.

Given all this, the #pragma keylist annotation should be removed.