Issue 18301: Type system severely underspecified (dds-xtypes-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Clarification Severity: Critical Summary: In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead. 1) Where does the hash that identifies the typeID of a constucted type come from? It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives. There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here. 2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead. Resolution: Revised Text: Actions taken: December 12, 2012: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 12 Dec 2012 08:04:05 -0500 To: Subject: Issue/Bug Report X-Brightmail-Tracker: AAAAARyBzJw= X-Brightmail-Tracker: AAAAAA== ******************************************************************************* Name: Erik Hendriks Employer: PrismTech mailFrom: erik.hendriks@prismtech,com Terms_Agreement: I agree Specification: Extensible and Dynamic Topic Types for DDS Section: 7.3.4.1.2 FormalNumber: ptc/2012-03-26 Version: 1.0 Doc_Year: 2012 Doc_Month: February Doc_Day: Day Page: 96 Title: Type system severely underspecified Nature: Clarification Severity: Critical CODE: 3TMw8 B1: Report Issue Description: In section 7.3.4.1.2 it is specified how to calculate the type ID for a given type. However, this algorithm heavily depends on the Type layout presented in Appendix B, which is not further explained. I have lots of questions about this algorithm, and am wondering if alternative mechanisms should not be considered instead. 1) Where does the hash that identifies the typeID of a constucted type come from? It states that it comes from the Big Endian CDR respresentation of the type, which is an IDL representation of the model specified in Appendix B. However, this data model is not further explained, and far from mature and orthogonal. It looks like we created a pretty ad-hoc type system rather than deriving one from a well-designed meta-model with a minimal set of powerful transformation primitives. There is a lot of existing documentation on how to set up a proper type-system. I suggest we consult some best-practices instead of re-inventing the wheel here. 2)The basis of the TypeObject consists of 2 fields, each having their own sequence. How the 2 sequences correlate is not further explained. The only thing that is explained in section 7.6.2.2 is that the the_type member of the TypeObject contains all types associated with the corresponding entity (1 for reader/writer, more for topic). I think it would be better to take this sequence outside TypeObject and give Topic a sequence of TypeObjects instead.