The union discriminator should also support the try_construct specification. Per XTYPES this may be needed when the union discriminator is an enum.

Moreover, the <struct> element allows a <const> to be defined inside. This is inconsistent with the IDL syntax which disallows that.

7.3.10.4 Data Sample Representation Examples (non-normative) contains examples of how to represent different types of data using XML. Extend those to include maps.

Also, the examples for <aSequenceOfStructs> and <anArrayOfStructs> seem wrong as they only contain a float which does not match any of the defined structures.

Also, the example for <aUnion> does not specify the value of the discriminator which will only work if there is a single discriminator value: It will also not apply to the default case, or if there is no value associated with the discriminator...

In the DDS specification domains are identified by a integer domainId. This was expanded in the DDS-RTPS and DDS-Security specifications to also allow identification with a domainTag string. So the Domain is ultimately identified by a unique value of the tuple (domainId, domainTag).
The core DDS has not been revised in a while but there is an issue filed to add it (DDS15-258).

References:

• RTPS version 2.5, Table 8.78 says:

  domainId	DomainId_t	Identifies the DDS domainId of the associated DDS DomainParticipant.
  domainTag	string	Identifies the DDS domainTag of the associated DDS DomainParticipant.

• DDS Security 10.4.1.2.5.1
  On the "domain" element that appears in the Governance file:
  The value in this element identifies the DDS domains to which the rule applies. DDS domains are identified by their DomainId (an integer) and a DomainTag (a string). One or more DomainId values (or ranges) must always be specified. In addition, one or more DomainTag values or DomainTagExpression values may be optionally specified.
  If no DomainTag and DomainTagExpression is specified, then it shall be treated as if the empty string ("") was specified as the only DomainTag value.
  Example:

      <domains>
          <id>0</id>
          <id_range>
          <min>10</min>
          <max>20</max>
          </id_range>
          <tag>Robot15</tag>
          <tag_expression>AGVS/*</tag_expression>
      </domains>
  

The specification lacks the XSD type definitions for the extensions added in DDS-TSN. These include:

• Schemas used to define Nodes in the system
• Schemas uses to define DDS deployments
• Schemas used to define the TSN configuration/requirements of those deployments.

The DDS-XML specification should be updated to include these schemas.

The specification does not allow <application> elements to extend other already-defined <application> elements. This is inconsistent with what is supported in other elements like <domain_participant> which in fact can be defined to extend other <domain_participant> elements.

The DDS-XML specification, specifically the dds-xml_application_definitions_nonamespace.xsd schema should be updated to support this.

The specification lacks the XSD type definitions for the QoS extensions coming from DDS-RTPS and DDS-RPC:

• Specification of domainTag alongside domainId
• Registration of interface types used for DDS-RPC (rpc call style)
• Definition of RPC services (request reply and rpc)

The DDS-XML specification, specifically the dds-xml_domainparticipant_definitions_nonamespace.xsd schema should be updated to support these.

The specification lacks the XSD type definitions for the QoS extensions coming from DDS-RTPS and DDS-RPC:

• Specification of domainTag alongside domainId
• Registration of interface types used for DDS-RPC (rpc call style)
• Definition of RPC services (request reply and rpc)

The DDS-XML specification, specifically the dds-xml_domain_definitions_nonamespace.xsd schema should be updated to support these.

The DDS revision proposes to change DDS::Time_t/Duration_t to 64bit, see https://issues.omg.org/browse/DDS15-13. When there is a new dds spec this spec will also need an update

1. In the specification and xsd file，can not find that how to describe the locator information of the domain participant such as metatrafficUnicastLocator or defaultUnicastLocator.
2. When the topicKind of a topic is WITH_KEY, how to describe the corresponding key-value information of the DateWriter in the "data_writer" part.
3. If user can add some bolcks that user defined and if there are some rules?
4. There are no "uint8" or "int8" in the the simpleType whose name is "allTypeKind" in the xsd file whose name is "dds-xml_type_definitions_nonamespace.xsd". But there are the definition in chapter "7.3.2.2 Basic Types" of the specification "Extensible and Dynamic Topic Types for DDS"(DDS-XTypes)

The IDL specification got extended with support for uint8/int8, map, bitset/mask, but there is no mapping for this in the DDS XML specification. The DDS XML specification should define how these new IDL types are mapped in XML. Also missing are interface definitions needed by DDS-RPC and some annotations DDS-XTYPES and IDL4. Specifically:

• uint8/int8
• map
• bitset and bitmask
• Interface and Exception definition
• bultin type declarations such as "unit"
• custom annotation definitions
• application of custom annotations

The DDS-XML specification, specifically the dds-xml_type_definitions_nonamespace.xsd schema should be updated to support these.

This specification lacks the XSD type definitions for the QoS extensions coming from DDSXTypes (at least DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy). These should be added to the DDS XML specification.

In section 7.3.2.4.4.1, the "Is equivalent to the following XML" paragraph has the wrong style. It should be "Text Body" rather than monospace.