DDSWEB11 — The file dds-xtypes_type_definition.xsd should not define a targetNamespace

This is the so called "Chameleon" Schema and it is best for XSDs that define "building blocks of XSD types" which may be then imported/included (included) by other XSDs.

See http://www.xfront.com/ZeroOneOrManyNamespaces.html

The issue is this. If a XSD is imported into another one that has a different target namespaces it will cause some "usability problems" in the resulting XML documents. This is only an issue when the XSD is imported in order to be a building block of the resulting XSD and is not natural for the end user to have to understand the original XSDs as separate conceptual units.

For example if we wanted to create a "dds.xsd" that used a target namespace such as http://www.omg.org/dds/ and this imports XSDs like XTYPES with target namespace http://www.omg.org/xtypes/ and dds4ccm with target namespece (http://www.omg.org/dds4ccm). Note these are not the actual namespaces in those documents. I am selecting this to simplify the description.

Then each time an element from a different namespace it would need to explicitly add the attribute xmlns to the element. This would happen for both for the included DDS_QosProfiles.xsd (it uses the namespace http://www.omg.org/dds4ccm) and for dds-xtypes_type_definition.xsd (it uses the namespace http://www.omg.org/xtypes/) the resulting references to elements in that XSD would need to specify the namespace using the "xmlns" attribute as in:
<publisher name="ShapePublisher">
<publisher_qos>
<partition xmlns="http://www.omg.org/dds4ccm/">
<name>
<element>A</element>
</name>
</partition>
<publisher_qos>
</publisher>

This is cumbersome and hard to get right for the user. Also many XML editors do not provide assistance with it. The best solution would have been for the referenced standards (DD4CCM and XTYPES) to define their XSD schemas without a targetNamespace. This would have allowed the namespace to be defined in the XSD that includes them.

This is a common approach known as using “Chameleon Schemas”. These specifications could also preserve the use of their namespace by putting the namespace in a separate XSD that “includes” the Chameleon Schema. To address this an issue should be filed against those specifications to change their schemas into Chameleon schemas.

There is no loss of generality as it is always possible to define another XSD that simply includes the Chameleon one and adds the namespace.