Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
Currently the DataRepresentation (XCDR1, XCDR2, XML) is controlled by a Qos Policy on the DataWriter. This is good to allow run-time configurability and enable systems to evolve.
However when defining data models for systems that will be deployed it may be important to allow that representation to be declared and restricted in the data-model. This may be needed such that the users of that data model can be sure to interoperate with the deployed system. This also supports the use-case where systems are deployed with code that support only one representation as may be the case in some resoure-constained systems.
A proposed solution is to add an annotation:
If @data_representation is not specified then the default is XCDR_AND_XCDR2. This allows the representation to be configured on the DataWriter and DataReader DataRepresentationQos policy.
If a value other than XCDR_AND_XCDR2 is specified, then that setting overrides the DataRepresentationQos that may have been set on the DataWriter or DaraReader.
In addition the terminology for 7.4.x could be cleaned up a bit. Fist it cases about XCDR and XML as being "Data Representations" however later on it talks about PLAIN_CDR and DELIMITED_CDR, PL_CDR2 also as "representations". It may be better to use a different word for this to avoid confusion.
Keep "Representation" for XCDR, XCDR2, XML, etc. This is consistent with the Qos policy and the main definitions. Use another word. For example "encoding" to talk about PLAIN_CDR, PL_CDR, etc.
Reported: DDS-XTypes 1.2 — Tue, 27 Nov 2018 02:31 GMT
Disposition: Resolved — DDS-XTypes 1.3
Define a @allowed_data_representation annotation
Add an annotation that can be applied to types and modules that restricts the data representations that a type may use.
The definition should be as proposed in the issue description.
Updated: Tue, 8 Oct 2019 17:55 GMT