IDL and variable metadata

struct Gadget {
 long my_integer;//@MyAnnotation1(greeting="Hello")  
}; 

In theory, this would allow you to define the meta-data tags for things like units, etc:

@Annotation
struct Unit {
    string<32> value;
};

and then use it like this

struct TemperatureType {
    string<32> devID; //@key
    double t; //@Unit("Celsius")
};

Issues:

1) No known DDS-vendor provided IDL compiler understands that XType ability. Known implementations currently ignore custom annotations.

2) Edited in line with Gerardo's comment below There is no standardized method for propagating that meta-data information into the compiled code, for use at runtime.

3) There is no standardized way to define how/what the meta-data should look like.  You're IDL will carry the meta-data information in a format designed by you, there is no standards-based method for defining how/what a meta-data "tag" should look like or what information it should contain.

A Standards-based method would be to construct an IDL struct that could be used to send information around about fields.  Next, build an XML schema that defines an XML structure that can be managed by hand or auto-generated by an IDL compiler.  The XML instances would then be parsed at runtime and the metadata published via DDS on a well-known topic.

<TypeDescriptor>
    <Type name="ShapeTypeExtended" constraintSetName="MyCircleTopicConstraints">
        <fieldconstraint name="x_range" field="x" minValue="0" maxValue="248"/>
        <fieldconstraint name="y_min" field="y" minValue="0"/>
        <fieldconstraint name="shapesize_max" field="shapesize" maxValue="45"/>
    </Type>
    <Type name="TemperatureType" constraintSetName="MyOilTemp">
        <fieldconstraint name="t" convert="CelsiusToFahrenheit"/>
    </Type>
    ...
</TypeDescriptor>

When a DataWriter or DataReader application starts up it could subscribe to the TypeDescriptions topic, filter on the constraintSetName to get just the settings that it is interested in, and then configure its internal behavior based thereon, to include min, max, range, conversions (F to C, M to Ft, etc) and so on.

But, this is all done in Application space, there isn't a standardized method for this inside the middleware. 

Building out this capability (keeping in mind issue #2 above, which I've highlighted for conventience :) ) is certainly something we could do for you, let us know if you'd like to talk to our Services department.