5.6.17. XML Configuration

5.6.17.1. [Major] Could not use multiple <types> tags to create user data types

Consider the following XML file, which is used to create user data types:

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="../xsd/rti_dds_profiles.xsd">
    <types>
        <struct name="Struct1">
            <member name="m1" type="short"/>
        </struct>
    </types>

    <types>
        <struct name="Struct2">
            <member name="m1" type="nonBasic" nonBasicTypeName="Struct1"/>
        </struct>
    </types>
</dds>

If you configured your DomainParticipantFactoryQos to have this XML file in your profile.url_profile value, and you attempted to call DDS_DomainParticipantFactory_set_qos on this QoS, this call would have incorrectly failed with the following error:

DDS_XMLTypeCode_reportNotFoundTypeSymbol:Parse error at line 11: type 'Struct1' not found

This error happened because the second <types> tag was incorrectly treated as containing a set of type definitions that were independent from those contained in the first <types> tag.

Another consequence of this incorrect behavior was that only the first <types> tag was considered when looking up the typecode of a given structure. Consider the following XML file:

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="../xsd/rti_dds_profiles.xsd">
    <types>
        <struct name="Struct1">
            <member name="m1" type="short"/>
        </struct>
    </types>

    <types>
        <struct name="Struct2">
            <member name="m1" type="short"/>
        </struct>
    </types>
</dds>

In this case, calling DDS_DomainParticipantFactory_set_qos would have succeeded, but then calling

DDS_DomainParticipantFactory_get_typecode_from_config(
        DDS_TheParticipantFactory,
        "Struct2");

would have incorrectly failed because Struct2 does not exist under the first <types> tag.

These problems have been fixed by treating the second <types> tag as an extension of the first one. This new behavior also works across multiple XML files; if the two <types> tags are in different XML files, then the second <types> tag will still be considered an extension of the first one.

[RTI Issue ID CORE-14680]

5.6.17.2. [Minor] Duplicate type names were allowed in an XML file for defining user data types

Consider the following XML file, which is used to create user data types:

<dds xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="../xsd/rti_dds_profiles.xsd">
    <types>
        <struct name="Struct1">
            <member name="m1" type="short"/>
        </struct>
        <struct name="Struct1">
            <member name="m2" type="long"/>
        </struct>
    </types>
</dds>

If you configured your DomainParticipantFactoryQos to have this XML file in your profile.url_profile value, and you attempted to call DDS_DomainParticipantFactory_set_qos on this QoS, this call would have incorrectly succeeded when the duplicate Struct1 names should have caused it to fail. A similar problem existed for enum, bitset, valuetype, sparse_valuetype, union, typedef, and const tags.

[RTI Issue ID CORE-14796]

5.6.17.3. [Trivial] DDS-prefixed enumerations caused confusion in XSD files

Before this release, the DDS-prefixed enumerations DDS_KEEP_LAST_HISTORY_QOS and DDS_KEEP_ALL_HISTORY_QOS were valid in the XSD files, as well as the standard enumerations, KEEP_LAST_HISTORY_QOS and KEEP_ALL_HISTORY_QOS. Having both sets of enumerations (with and without the DDS_ prefix) in the XSD files was confusing. In this release, RTI has updated the XSD files by removing the non-standard enumerations DDS_KEEP_LAST_HISTORY_QOS and DDS_KEEP_ALL_HISTORY_QOS and keeping the standard ones, KEEP_LAST_HISTORY_QOS and KEEP_ALL_HISTORY_QOS.

The primary goal of this change is to ensure that tools utilizing XSD files are aligned with standard DDS enumerations, thereby reducing potential confusion and maintaining consistency across applications. It’s important to note that while these DDS-prefixed enumerations have been removed from the XSD files, they remain valid within the Connext XML parser. This means that existing configurations using these terms will continue to operate as expected.

However, anyone leveraging third-party tools for XML file validation might encounter warnings or errors if the removed DDS-prefixed enumerations are still in use. These tools may no longer recognize these enumerations as valid due to the enumerations’ absence in the updated XSD files. We recommend reviewing and updating your XML configurations to use the standard enumeration terms to ensure seamless compatibility and validation across all tools and applications.

[RTI Issue ID CORE-14012]