IDL and variable metadata

6 posts / 0 new
Last post
Offline
Last seen: 4 years 6 months ago
Joined: 11/07/2014
Posts: 13
IDL and variable metadata

Is there a way specify variable metadata (unit, sign/orientation, range, ....) in an IDL?  I would like a standard means to define this metadata and to not hard code it in the application.  Also, at runtime I would like applications to learn about this metadata and make compensations to conform.  Does anybody have a recommendation?

Thanks for any assistance.

rip
rip's picture
Offline
Last seen: 1 day 12 hours ago
Joined: 04/06/2012
Posts: 316

The XTypes standard supplies a defined method for adding user-defined comments (ie, metadata) to fields, via the //@<identifier> syntax:

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.

 

Gerardo Pardo's picture
Offline
Last seen: 3 weeks 1 day ago
Joined: 06/02/2010
Posts: 589

Hi,

I agree with Rip that the DDS vendors are still not supporting custom annotations.

However DDS-XTYPES does provide a standard way to propapage annotations into the compiled code. This mechanism is the TypeObject, see section 7.3.4 "Representing Types with TypeObject" of the DDS-XTYPES specification version 1.0.  Annotations are defined on the type, not the data, so all data objects of a given type carry the same annotation values. For this reason the annotations are encoded within the type information, not the data-object itself.  This also means that once it is supported by the DDS vendors annotations  will also be propagated via DDS discovery along with the type information. 

Since custom annotations are still not supported you could "emulate" this feature creating your own syntax for the metadata and placing the information in the PropertyQosPolicy within the DataWriterQos. That way the meta-data would be propagated via DDS discovery (in the PublicationBuiltinTopicData) and associated with the DataWriter that wrote the data.  The DataReader side could get a reference to the PropertyQosPolicy for a specific DataWriter using the operation DataReader::get_matched_publication_data(). This operation takes the InstanceHandle_t of the DataWriter which is available on the SampleInfo of the samples sent by the writer and can also be found by calling DataReader::get_matched_publications()

Gerardo

Offline
Last seen: 4 years 6 months ago
Joined: 11/07/2014
Posts: 13

Gerardo,

Thanks!  That provides an approach that minimizes effort and positions for upgrading when DDS vendors do support custom annotations. 

Doug

Offline
Last seen: 4 years 6 months ago
Joined: 11/07/2014
Posts: 13

Gerardo,

I tried implementing the proposed solution using "get_matched_publication_data" but as stated below "get_matched_publication_data" does not retrieve properties.  Is this the solution that you were thinking of?  I could retrieve the information from "on_data_available", but that is not as convenient.  Thank for any assistance you can provide.

virtual DDS_ReturnCode_t DDSDataReader::get_matched_publication_data(DDS_PublicationBuiltinTopicDatapublication_data,
  const DDS_InstanceHandle_tpublication_handle 
 )  
inlinevirtual

This operation retrieves the information on a publication that is currently "associated" with the DDSDataReader.

Publication with a matching DDSTopic, compatible QoS and common partition that the application has not indicated should be "ignored" by means of the DDSDomainParticipant::ignore_publication operation.

The publication_handle must correspond to a publication currently associated with the DDSDataReader. Otherwise, the operation will fail with DDS_RETCODE_BAD_PARAMETER. Use the operation DDSDataReader::get_matched_publications to find the publications that are currently matched with the DDSDataReader.

Note: This operation does not retrieve the following information in DDS_PublicationBuiltinTopicData:

The above information is available through DDSDataReaderListener::on_data_available() (if a reader listener is installed on the DDSPublicationBuiltinTopicDataDataReader).

Parameters
publication_data<<inout>>. The information to be filled in on the associated publication. Cannot be NULL.
publication_handle<<in>>. Handle to a specific publication associated with the DDSDataWriter. . Must correspond to a publication currently associated with the DDSDataReader.
Returns
One of the Standard Return Codes or DDS_RETCODE_NOT_ENABLED
Offline
Last seen: 3 months 4 weeks ago
Joined: 12/07/2016
Posts: 10

Any updates on this?

We are also looking at dding metadata to specific fileds. It would be really convenient to have one document specifying the interfce and limits (actually with some autogenrated code to verify said limits). We'll have to write something custom and just put keys in the comments inside IDL.