DDS-XTypes 1.3 RTF Avatar
  1. OMG Issue

DDSXTY13 — Annotation for denoting topic types

  • Key: DDSXTY13-17
  • Status: closed  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.2b1 — Mon, 12 Feb 2018 06:46 GMT
  • Disposition: Resolved — DDS-XTypes 1.3
  • Disposition Summary:

    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>
    
  • Updated: Tue, 8 Oct 2019 17:55 GMT