Section 7.6.1 states that every component only uses 1 representation of a topic type.
Some generic services (e.g. durability service or a logger) might discover a topic from another node but will still be able to handle all representations of it, without ever having type specific knowledge hardcoded into them.

Corrected paragraphs:
Typically, in application code, a topic is associated with a single type (as has always been the case in the [DDS] API) . Therefore, multiple API topics may correspond to (different views of) the same network topic. A given reader or writer endpoint is associated with one of them. See Section 7.6.3, “Local API Extensions”, for definitions of the programming interfaces that support this polymorphism.
Generic services (e.g., logger, monitor) may discover a topic associated with one or more types. Such services may be able to handle all representations of the types, without ever having type specific knowledge hardcoded into them.

Is it allowed to have a parent and a child struct share an attribute with the same name?

• In most OO-languages this is allowed.
• However, in scenario's like type-refactoring this will cause huge problems.

We should clearly specify whether or not this is allowed, and when allowed we should clearly describe the consequences.

The paragraph 7.2.2.3.5.1 updated as follows:
A structure can optionally extend one other structure, its “base_type.” In the event that there is a name or ID collision between a structure and its base type, the definition of the member in the former takes precedence the definition of the derived structure is ill-formed.

Typo: 4rth paragraph: For the saMe of run-time efficiency -> For the saKe of run-time efficiency.....

Corrected sentence: For the same sake of run-time efficiency …

The opening sentence seems to be missing a noun and a verb. Probably what is meant is:

System developers frequently require the ability to inject their own output into <code> that <is> produced by a Type Representation compiler.

Corrected sentence: System developers frequently require the ability to inject their own text into the code produced by a Type Representation compiler.

The specification of the extensibility kind for enumeration types is inconsistent. Figure 10 in section 7.2.2.3.1, "Enumeration Types", indicates that the extensibility_kind of all enumeration types is FINAL. However, Table 11 in section 7.2.3, "Type Extensibility and Mutability", says, "Enumeration types may be final, extensible, or mutable on a type-by-type basis."

Proposed Resolution:

The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.

The assignability rules for enumerations already address different extensibility kinds, so we can preserve the more general statement from 7.2.3. Fix Figure 10.