IDL identifiers may not reuse the same names (disregarding case) of types already in scope. This is a problem for "instanceName" in the RPC spec:

struct RequestHeader {
  SampleIndentity_t requestId;
  InstanceName instanceName;
};

And SampleIndentity_t is misspelled. It should be SampleIdentity.

This issue has also been entered into DDS-Security as the solution could also involve changes to that specification. See:
https://issues.omg.org/browse/DDSSEC12-31

DDS-RPC maps each DDS-Service to a single (unkeyed) Topic-pair (request topic & reply Topic).

DDS-Security provides access control per Topic and per Instance (Key). Moreover, the builtin plugins only provide access control per Topic.

With these mappings is it not possible to configure access control per operation/method in the service. This is a common requirement for many service definitions.

One way to overcome this would be to provide a mapping where each a Service would map to multiple Topic pairs. E.g. one Topic pair per method/operation. That way it would be possible to separately grant permissions to call operations on a service or to implement operations on a service.

The mapping of a Topic pair per method/operation would also setting different Qos per operation...

Alternatively one could

The DDS-RPC added a @Choice annotation (see 7.5.1.2.1.1 @Choice Annotation) to indicate a Structure with the "single-member" semantics of a union. As stated in the aforementioned section the reason was:

Using unions to indicate which operation is being invoked is brittle. Operations in an interface have set semantics and have no ordering constraints. Union, however, enforces strict association with discriminator values, which are too strict for set semantics. Further, use of unions leads to ambiguities in case of multiple inheritance of interfaces.

However XTYPES 1.2 enhanced unions which now support inheritance and are not so brittle anymore. For this reason it makes sense to re-evaluate this decision.

An advantage of using unions (beyond avoiding a extraneous annotation) is that their API is better oriented to identifying the one branch that is present; whereas in the case of structures there is no standard API available to determine which member is present other than iterating over every member. This would be unnatural for processing the RPC calls.

Section 7.5.1.1.4 Mapping of Interfaces to the Request Topic Types, and Section 7.5.1.1.5 Mapping of Interfaces to the Reply Topic Types, each define a union and specify that the union should have a 'default:' case.

This makes it difficult to extend the union to support interface inheritance.

The 'default:' case should be removed.

Section 7.5.1.2.3 Mapping of Operations to the ReplyTopic Types cotntains the following IDL:

@Choice @Autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};@Choice @Autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};
};@Choice @Autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};
};@Choice @Autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};

This IDL is not correct. It contains extra "};" preceding the @Choice annotations in several places.

In Addition in IDL42 all annotations are lower case. Specifically @autoid is defined there.

Therefore the correct IDL would be:

@choice @autoid
struct RobotControl_command_Result { 
    RobotControl_command_Out result;
};

@choice @autoid
struct RobotControl_stop_Result { 
    RobotControl_getSpeed_Out result;
};

@choice @autoid
struct RobotControl_setSpeed_Result {
      RobotControl_setSpeed_Out result;
      TooFast toofast_ex;
};

@choice @autoid
struct RobotControl_getSpeed_Result {
      RobotControl_getStatus_Out result;
};