DDS-XTypes 1.2 RTF Avatar
  1. OMG Issue

DDSXTY12 — Multiplicity mismatch between TypeName and TypeObject

  • Key: DDSXTY12-30
  • Legacy Issue Number: 18307
  • Status: closed  
  • Source: ADLINK Advanced Technology Office ( Erik Hendriks)
  • Summary:

    The builtin topics have 2 ways to identify the type to which they apply: a string called type_name and a TypeObject alled type. The string can only relate to 1 type, while the TypeObject could refer to more than 1 type.

    If the type_name is not uniquely identifying a type, then what is the use of having a type_name in the builtin topics for Reader and Writer? The topic_name already refers to a DCPSTopic sample that has a similar type_name.

    Furthermore, in the spec it is assumed that Readers/Writers just make the TypeObject refer to just 1 type, while the Topic could make it refer to more than one. This is not orthogonal, so wouldn't it be better to make a TypeObject refer to 1 type and give the DCPSTopic a sequence of TypeObjects instead?

  • Reported: DDS-XTypes 1.1 — Wed, 12 Dec 2012 05:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.2
  • Disposition Summary:

    ChangeType object to refer to a single TypeId

    Modify Annex B to correct the multiplicity of the TypeId. The TypeObject struct (Annex B) shall be updated to include just a single typeid instead of a sequence of typeids.

    The TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData already includes an optional TypeObject member. The specification shall include a guideline/warning that absent TypeObject it is not possible to ensure type compatibility

  • Updated: Thu, 22 Jun 2017 16:42 GMT