Open topic with navigation

7.5.3 DATA_REPRESENTATION QosPolicy

The DATA_REPRESENTATION QosPolicy is used to indicate which versions (version 1 and version 2) of the Extended Common Data Representation (CDR) are offered and requested. A DataWriter offers a single representation, which indicates the CDR version the DataWriter uses to serialize its data. A DataReader requests one or more representations, which indicate the CDR versions the DataReader accepts. If a DataWriter's offered representation is contained within a reader’s sequence of requested representations, then the offer satisfies the request, and the policies are compatible. Otherwise, they are incompatible.

The DATA_REPRESENTATION QosPolicy includes the member in Table 7.37 DDS_DataRepresentationQosPolicy. For defaults and valid ranges, please refer to the API Reference HTML documentation.

Table 7.37 DDS_DataRepresentationQosPolicy

Type

Field Name

Description

DDS_DataRepresentationIdSeq

value

A sequence of two-byte signed integers corresponding to representation identifiers. The supported identifiers are DDS_XCDR_DATA_REPRESENTATION (Extensible CDR version 1), DDS_XCDR2_DATA_REPRESENTATION (Extensible CDR version 2), and DDS_AUTO_DATA_REPRESENTATION. An empty sequence is equivalent to a sequence with one DDS_XCDR_DATA_REPRESENTATION element. The default value, however, is a sequence with one DDS_AUTO_DATA_REPRESENTATION element.

For plain language binding, the value DDS_AUTO_DATA_REPRESENTATION translates to DDS_XCDR_DATA_REPRESENTATION if the @allowed_data_representation annotation either is not specified or contains the value XCDR. Otherwise, it translates to DDS_XCDR2_DATA_REPRESENTATION. For FlatData language binding, DDS_AUTO_DATA_REPRESENTATION translates to XCDR2_DATA_REPRESENTATION. (See below for further explanation.)

For additional information on the @allowed_data_representation annotation, see "Data Representation" in the RTI Connext DDS Core Libraries Getting Started Guide Addendum for Extensible Types.

7.5.3.1 Properties

This QosPolicy cannot be modified after the Entity has been enabled.

You can view data representation as a two-step process:

  1. As described above, DDS_AUTO_DATA_REPRESENTATION translates to the value DDS_XCDR_DATA_REPRESENTATION or DDS_XCDR2_DATA_REPRESENTATION depending on a few factors. Or you can explicitly set the value to DDS_XCDR_DATA_REPRESENTATION or DDS_XCDR2_DATA_REPRESENTATION. If you let DDS_AUTO_DATA_REPRESENTATION set the value, the following table shows how it will be set, depending on your IDL:

    2. Table 7.38 How DDS_AUTO_DATA_REPRESENTATION Sets the Value

    IDL looks like ...

    AUTO value translates to ...

    		 
    Struct Point {
    }

    which is equivalent to:

     
    @allowed_data_representation(XCDR | XCDR2)
    Struct Point {
    }

    XCDR

    		 
    @allowed_data_representation(XCDR2)
    Struct Point {
    }

    XCDR2

    		 
    @language_binding(FLAT_DATA)
    Struct Point {
    }

    XCDR2
  2. Once the value is set (either by DDS_AUTO_DATA_REPRESENTATION or explicitly by you), that value determines what the DataWriter writes or the DataReader reads. (Recall that the DataWriter offers one representation; the DataReader requests one or more representations.) The next step is how the DataWriter and DataReader match based on the QoS value. The QoS must be compatible between the DataWriter and the DataReader. The compatible combinations are shown in Table 7.37 DDS_DataRepresentationQosPolicy.

    3. Table 7.39 Valid Reader/Writer Combinations of DataRepresentation

    DataWriter-offered DataRepresentation

    DataReader-requested DataRepresentations

    XCDR

    XCDR

    XCDR

    XCDR and XCDR2

    XCDR2

    XCDR2

    XCDR2

    XCDR and XCDR2

If this QosPolicy is set incompatibly, the ON_OFFERED_INCOMPATIBLE_QOS and ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.

7.5.3.2 Applicable Entities

© 2020 RTI

Open topic with navigation