DDSXTY13 — Annotation for denoting topic types

In order to use an IDL type as a topic type, some additional methods are required to be generated (such as methods for creating DataReaders and DataWriters).

Implementations have invented their own mechanisms in this area:

• One product might support the notion that by default all structured types can be used as topic types, defining a mechanism to selectively switch off that assumption
• Another product might require a pragma to be used for switching on the additional code generation for topic types

A built in annotation should be added for distinguishing topic types from non topic types.

Introduce a @DDSTopic annotation that allows marking DDS Topic Types

Define a new annotation that can be used to indicate that certain types are intended to be used as DDS Topic Types.

There are some related precedents:

DDS-RPC

This @DDSTopic annotation parallels the @DDSService annotation defined in DDS-RPC. The definition is of @DDSService

@annotation DDSService {
    string name default "";
};

Note that DDS-RPC also defines the following annotations:

module dds { module rpc {
@annotation DDSRequestTopic {
    string name;
};
@annotation DDSReplyTopic {
    string name;
};

};};

IDL 4.2
This specification which was released after DDS-RPC introduced a new notation for marking services:

@annotation service {
string platform default "*";
};

In IDL42 there are three pre-defined values of for the platform:

• "CORBA" indicates that the service should be made accessible via CORBA.
• "DDS" indicates that the service should be made accessible via DDS.
• "*" (an asterisk) indicates any platform. This is the default value.

So a definition that follows what was done in DDS-RPC could be:

@annotation DDSTopic {
    string name default "";
};

Whereas a definition that follows what was done in IDL 4.2 could be:

@annotation topic {
   string platform default "*";
};

Or some other name instead of "topic", perhaps "message" if we consider it sufficiently generic:

Note that all MQTT (http://mosquitto.org/man/mqtt-7.html), Amazon Pub-Sub (https://aws.amazon.com/pub-sub-messaging/), and Google PubSub (https://cloud.google.com/pubsub/docs/overview) use the concept of messages sent to a Topic.

If we used a @topic definition in IDL and we wanted to be able to specify the Topic name would need to combine it with another annotation (in DDS-XTYPES, not IDL) to do this. For example @DDSTopicName. So finally we would have:

IDL4 -> @service , @topic. These allow specifying the platform, e.g. @service("DDS") or @topic("DDS"). If not parameter is specified the default is @service("*"), @topic("*").
Then in DDS-RPC we have @DDSServiceName("MyService"), @DDSRequestTopic("MyServiceRequest"), @DDSReplyTopic("MyServiceReply")
Ans in DDS-XTYPES we have @DDSTopicName("MyTopic").

Alternatively we could try to eventually push all this into the IDL annotations. For example:

@annotation service {
     string platform default "*";
     string name default "";
     string request_topic default "";
     string reply_topic default "";
};

@annotation topic {
     string platform default "*";
     string name default "";
};

So for now we could add @topic to the DDS-XTYPES and push it to IDL4 later.

How would annotations with parameters appear in XML? Is it legal to do something like:

<struct name="Shape"  topic.name="Square" topic.platform="DDS">
    <member name="color" type=string"/>
 </struct>