For numeric types, it is often convenient for a data model to say "value is in range or a designated out-of-range marker".
IEEE-754 defines the "not a number" NaN specifically for this purpose. It fits within the numeric type and is "infectious", so "x op NaN = NaN" for most mathematical operations and all values of x. Other values such as 0 or 1 are sometimes useful defaults for out of range in specific contexts.

While the semantics are similar to optional<float>, a purely numeric data type can be more efficient for communications and processing, especially on embedded platforms.

Feature request: add an annotation for defining such disjoint numeric sets.

feature request: define APIs so multiple type definitions can be pre-processed, thus avoiding runtime type lookup between known IDL versions

use case: a system grows over time with IDL versions 1, 2, ... N. All these versions are designed for interoperability or with known breakages. Avoiding unnecessary discovery traffic is important for system performance.

An API to load XML type definitions would be useful in many situations. An IDL-compiler based API would be more efficient for embedded platforms.

Consider the following IDL fragment
enum E

typedef sequence<E, N> SeqE;
struct S

If the user wants to extend E with additional values, then @try_construct(USE_DEFAULT) allows the subscriber to replace unknown values with a default.
Q1: Where should this annotation be applied – in the definition of SeqE or S?

If the user wants to extend SeqE with added length, then @try_construct(TRIM) allows the subscriber to shorten samples as needed.

Q2: If the user needs to extend both E and SeqE, then how can they use both annotations at the same time?

The current spec tells us (last paragraph of 7.6.1):

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 hard-coded into them.

This paragraph leaves the reader wondering how to do so, and it seems like the answer would be found in 7.6.6 "Use of Dynamic Data and Dynamic Type." But there are limitations with the current DynamicTypeSupport as defined by 7.6.6 that makes this either difficult or impossible.

The scenario described by 7.6.1, in the general case, is that a Topic is in use in a Domain by an arbitrary collection of DataReaders and DataWriters. Since we are only concerned with receiving data (for now) in a logger/monitor application, we'll consider the existing DataWriters. Each of these DataWriters may have a different type. The goal of our logger/monitor is to receive data from all of them.

In the simple case of only one writer, the logger/monitor can get its type from Built-In Topics and create a DynamicTypeSupport for this type. Then create a DataReader based on this type support, which of course will use DynamicData as its data sample type.

But in the case of multiple writers, there is no straightforward way to create a DataReader that can receive data samples from all writers. Creating multiple DataReaders isn't an attractive solution because it complicates the application code and it could lead to scenarios where the same data is received via multiple readers.

It seems like what's needed is an AnyTypeSupport object with a similar role as DynamicTypeSupport's but without the need to provide it an immutable DynamicType on creation. Only DataReaders (no DataWriters) could be created using AnyTypeSupport. Its data sample type would also be DynamicData (and all DynamicData instances already carry with them a reference to their DynamicType). Its TypeIdentifier would be TK_NONE or a new constant designated for this purpose. All actual types written by DataWriters would be assignable to TK_NONE (it passes type compatibility checking trivially).

As defined create_sample can only return the sample object. This doesn't allow the API to indicate that there was an error unlike other calls in DDS. Other operations either can't normally fail, return an interface that can be null, or return a ReturnCode_t. At least in the C++ Language Mapping, create_sample can return a struct or a union by value, so it can't be null in those cases (section 5.11). I imagine this might be different in other mappings though.

Figure 16 defines bitset as another kind of aggregated type. One might assume that this has the semantics of an IDL4 bitset.

The text after Figure 16 and the rest of the spec doesn't define how bitset works in the type system (assignability), type representation, and data representation.

Definition of equality is based on the "Properties" of the class as defined by the UML models (for example, Table 54). However, associations/aggregations (which are not properties) are just as important for equality. An example is the TypeDescriptor that's associated with each DynamicType. While not a Property, the state of TypeDescriptor is effectively part of the state of DynamicType.

A related issue is that DynamicTypeMembers can only be equal "if they belong to the same type." This seems to be both unnecessary and prevents certain valid use cases. An application may want to determine if two different structs each have a string member of a certain name. Based on the Type System model (sect 7.2) it would be natural to apply the equals() operation on the members to check their logical equality independent of which struct they're declared in.

DynamicTypeSupport has the following IDL definition in Annex C:

interface DynamicTypeSupport : TypeSupport {
  /* This interface shall instantiate the type FooTypeSupport
   * defined by the DDS specification where "Foo" is DynamicData.
   */
  /*static*/ DynamicTypeSupport create_type_support(
    in DynamicType type);
  /*static*/ DDS::ReturnCode_t delete_type_support(
    in DynamicTypeSupport type_support);
  DDS::ReturnCode_t register_type(
    in DDS::DomainParticipant participant,
    in ObjectName type_name);
  ObjectName get_type_name();
};

This definition can't be used in an XTypes implementation, at least in one using standard IDL. register_type and get_type_name can't use those names because a derived interface can't define operations that share names with ones in its base interfaces. This is described at the end of 7.4.3.4.3.2.1 in IDL 4.2. Another issue is the "static" operations. They get the point across as to what the author means but, they are also not usable as IDL can't define operations as static. DynamicTypeBuilderFactory and DynamicDataFactory also do this.

When serializing a sequences of non-primitive elements, the XTYPES spec requires serializing a DHEADER ahead of serializing the number of elements and each element. This is rule (12)

Arrays of non-primitive elements also serializing the DHEADER but not the number of elements. This is rule (9)

I think it would make sense to modify or at least relax these rules.
At a minimum arrays and sequeces of enumerated types and bitmask types should not have a DHEADER as it does not add information beyond what is available knowing the number of elements and size of each element. That it, they should behave as primitives (basically they are integers).

Additionally it may be better to not have the DHEADER at all for sequences and arrays. Or at least for sequences or arrays whose elements are final.

Basically the "extensibility" of the sequence is already handled by having the number of elements and having a DHEADER adds nothing and makes types that contain sequences of FINAL incompatible with XCDR1. This is a side-effect that we did not want or anticipate. Otherwise types that are constructed from only FINAL types would be compatible between XCDR1 and XCDR2 (except for 8-byte aligned types).

Larga data types or types that contain compressible data (e.g. strings) can benefit from using compression at serialization time.
This would reduce the size required to store the data in the reader/writer caches as well as the bandwidth used to send the data.

This is complementary to transport-level compression and has the advanatage that the data is only compressed once (at serialization, instead of every time it is sent) as well as reducing memory requirements.