DDSXTY12 — All IDL should use local interfaces

All IDL should be using local interfaces, not regular interfaces, please add the keyword local to all interfaces

No change needed as local interfaces are being deprecated in IDL4

The use of IDL in XTYPES needs to be re-examined in light of IDL4. Specially features that are not part of the "DDS Profiles" defined in IDL4.

XTYPES uses local interfaces to define the DynamicData and DynamicType interfaces. It also uses them to define annotations. XTYPES uses regular interfaces to define the TypeSupport interface. IDL4 local interfaces belong to the CORBA-Specific building block. They are not part of the "DDS Profiles"
XTYPES uses (non-local) interfaces to define TypeSupport. This is in the RPC over DDS profile of IDL4.

XTYPES uses valuetypes to describe parts of the DynamicData and DynamicType interfaces. These are part of the Building Block ValueTypes which is not in any of the the "DDS Profiles"
Note that the fact that XTYPE uses a specific IDL building block (BB) does not mean that implementations of XTYPES that would end up having to support that BB. As long as that dependency on the BB is limited to describing interfaces that are "built into" the XTYPES DDS APIs there is no problem. If however they form part of the code being generated from user-defined datatypes then we would really have an issue.
The issue with "local" interfaces is that IDL4 considers them deprecated and for that reason it included them in the CORBA module.

The IDL4 view is that interfaces are just a contract specification, whether they are local or not is more up for interpretation by a particular use of the IDL. Hence this is specified via annotations like @service(DDS) or @service(CORBA). Therefore if an interface does not state anything it can be interpreted as a "local" interface...

So while the current use of local interfaces and valuetypes on XTYPES appears fine, it may make sense (in light of IDL4) to actually remove all use of "local" interfaces replacing them with regular interfaces...

However at this point it seems best to leave things as they are and wait for the alignment with IDL4...