Based on the DDS-XTypes specification, different applications in the same domain may associate the same Topic with different types. As a result through discovery it should be possible to find all such definitions. However this is not currently possible with the DDS v1.2 specification and the DDS-XTypes does not provide an extension for this API.

The following resolution is related to the resolutions of issues #15702, #16007, and #16720.
Abstract Model:
A given topic is associated with one or more types. (This is a “topic” in the “virtual” system-wide sense independent of the way a topic is reflected through the API to any given component.) A given writer or reader endpoint is associated with one of the types of its topic.
If a writer and a reader share the same topic, then it is assumed that they are intended to communicate with one another. At that point, the two endpoints are evaluated to make sure that they are type-compatible—see the resolution to issue #15702.
On the Network:
The Topic, Publication, and Subscription built-in topic data types already contain a type_name member. In addition, these data types shall contain a list of type definitions encapsulated in a TypeObject (defined in the resolution to issue #15702). In the Publication and Subscription cases, this “list” shall consist of only a single element. In the Topic case, it may consist of multiple elements.
There is a related issue that will be addressed in the context of this issue, because it will improve matching performance and prepare the specification for the possibility of future support for polymorphic readers and writers: Today, the TypeObject type representation is not amenable to compact representation or fast comparison: types are identified by a “type ID” that an implementation can generate any way that it wishes. This approach has two weaknesses: (1) A definition is not self-contained—it requires a full tree of the types it uses to also be present. Also, (2) two types may be logically “equal” but may not have the same binary representation, because they refer to the “same” types by different indexes. Therefore, modify the TypeObject representation to replace ad hoc type indexes with deterministic hashes. (The lower-order 64-bits of an MD5 hash of the TypeObject representation of the type is sufficient: a system would require 1e6 types before it would have a 1e-6 probability of a collision. A full 128-bit hash could be used, but the overhead would be significant when data sample sizes are very small.) This change will address both of the above issues. It will also allow implementations to flexibly truncate the amount of detail they put on the network. The overhead can be further reduced if we assume that most members will be of primitive type—we can define a type ID as a union of a (small) primitive type ID and a (hashed, big) complex type ID.
In the Application Code:
As always, a Topic object is not the real virtual topic—it is only a local proxy. We retain the constraint that a single local Topic object is associated with only a single type. This constraint keeps the programming model the same for both XTypes-supporting and non-XTypes-supporting implementations, and it keeps the mental model simple for the majority of applications, which will not be aware of the presence of multiple types in their topics.
To allow endpoints of the same virtual topic to be associated with different types, we make one change: The names of local Topic objects do not need to be unique within a given DomainParticipant, provided that all of those Topics of the same name really represent different slices of the same virtual topic—in other words, they must all have the same name.

The @key annotation is currently defined as:

@Annotation
local interface Key

;

Now suppose I have the following topic type:

struct ATopicType

;

What is the key (a,b) or (b,a)? What if there were no annotations?

The order of the key should be formally defined by the spec as this has an impact, among other things, on the computation of the keyhash.

The rule could be as simple as taking the key element in the same order of the attribute ID. The other option is to extend the key to support a value, yet I think the first alternative is more orthogonal.

The key hash is currently calculated in the following way, according to the DDS-RTPS specification:
1. Serialize the key members…
a. …in their declaration order
b. …in big-endian CDR format
2. If the serialization is less than or equal to 128 bits, that is the key hash.
3. Otherwise, apply an MD5 hash to reduce the result to 128 bits.
Update step (1a) above such that key fields are always serialized in ascending order by member ID rather than by declaration order. Note that this change applies only when calculating the key hash, not at any other time.
This change is backwards compatible with pre-XTypes DDS implementations, because legacy type definitions will lack @ID annotations, and hence all members will always be in ascending ID order.

In the IDL definitions for the specification section Representing Types with TypeObject, the type TypeKind is declared to be an enumeration. The type TypeId is declared to be a typedef to long. Certain well-known TypeId values are initialized using TypeKind values. However, this causes compilation errors from some IDL compilers, which do not allow enumerated values to be assigned to integral constants.
Resolution:
Change TypeKind from an enumeration to a typedef to short.

resolved

In the IDL definitions for the specification section Representing Types with TypeObject:
• The type “TypeId” collides with the IDL keyword “typeid.”
• The type “Module” and its member “module” collide with the IDL keyword “module.”
These collisions cause IDL compilation errors.
Resolution:
Escape the identifiers TypeId and Module by preceding them with underscores. Per the IDL specification, this lexical change does not impact the generated code.
Rename the type member “module” to “mod” to prevent collisions either with the IDL keyword or with the name of the enclosing type.
Revised Text:
Replace the type identifier “TypeId” in the IDL file with “_TypeId” everywhere it occurs.
Replace the type identifier “Module” in the IDL file with “_Module” everywhere it occurs.
Replace the member identifier “module” (in the type “Module”) in the IDL file with “mod.”

resolved

The Plain Language Binding relies on the IDL-to-C and IDL-to-C++ language mappings to generate programming APIs for these languages. Unfortunately, these mappings prefix all primitive type names with “CORBA,” which is incorrect and confusing for DDS users. For example:
• DDS Int32 will become CORBA_Long in C.
• DDS Float64 will become CORBA::Double in C++.
Resolution:
Update the Plain Language Binding for primitive types in C and C++ to place them in a conceptual “DDS” module instead of the current “CORBA” module. At the same time, rename them to be consistent with their names in the DDS type system—for example, “Int32” instead of “Long.” (The Plain Language Binding already makes several extensions to the IDL-to-C/C++ mapping specifications. This change would constitute one more.)
These new primitive types must be compatible in size and representationwith the definitions in the Type System; these definitions will be provided in a table within the Plain Language Binding section. (As a side effect, they will also be compatible with to their CORBA-module counterparts, such that applications using both DDS and CORBA can assign from one to the other without type casts or loss of information.)

Update the Plain Language Binding for primitive types in C and C++ to place
them in a conceptual “DDS” module instead of the current “CORBA” module. At
the same time, rename them to be consistent with their names in the DDS type
system—for example, “Int32” instead of “Long.” (The Plain Language Binding
already makes several extensions to the IDL-to-C/C++ mapping specifications.
This change would constitute one more.)
These new primitive types must be compatible with the definitions in the Type
System; these definitions will be provided in a table within the Plain Language
Binding section. (As a side effect, they will also be compatible with their CORBAmodule
counterparts, such that applications using both DDS and CORBA can
assign from one to the other without type casts or loss of information.)

Summary:
Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, identifies the type consistency enforcement kinds. This QoS policy is request-offer (RxO); readers and writers must match exactly in order to communicate. However, this requirement for an exact match is not required by implementations and is too restrictive for users.

The resolution below is closely related to the resolutions of issues #16097 and #16561.
The existing type consistency enforcement QoS policy, which governs both type signature consistency and type definition structural consistency, shall be simplified. It shall be removed from the Topic and DataWriter QoS and the corresponding built-in topic data types. It shall remain in the DataReader QoS and in the Subscription built-in topic data type. Its “kind” enumeration shall have the following values:
• DISALLOW_TYPE_COERCION: The DataWriter and the DataReader must support the same data type in order for them to communicate.
• ALLOW_TYPE_COERCION: The DataWriter and the DataReader need not support the same data type(s) in order for them to communicate as long as the reader’s type is assignable from the writer’s type.
The default settings shall be as follows:
• For compliant readers: ALLOW_TYPE_COERCION
• Inferred for non-compliant readers: DISALLOW_TYPE_COERCION
Type compatibility shall be determined according to the following steps:s
1. The TypeObject type definition is considered first, provided that it is available for both the Publication and the Subscription. (This is anticipated to be the most common case for DDS-XTypes-conformant implementations.) If the Subscription allows type coercion, then its type must be assignable from the type of the Publication. If the Subscription does not allow type coercion, then its type must be equal to that of the Publication.
2. If either the Publication or the Subscription does not provide any TypeObject definitions, then the type names are consulted. (This case is important in cases where a given component cannot, or does not wish to, provide concrete type definitions. For example, it may not support XTypes, it may wish to conserve bandwidth, it may not wish to reveal its type definition(s), or it may not even be type-aware—it may simply record binary payloads, for example.) The Subscription and Publication type_name fields must match exactly.
If the reader and writer are not type-compatible, the middleware raises an INCONSISTENT_TOPIC status change.
The following behaviors will result from the default values and evaluation orders above when writers and readers have default QoS:
• Compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior is what we want, and it is unchanged from the current DDS-XTypes default.
• Compliant writers will communicate with non-compliant readers. The reader will not allow type coercion, so the types (really the type names) must match exactly. This behavior is unchanged from the implied contract of DDS implementations prior to DDS-XTypes.
(Suppose the writer has out-of-band knowledge of the reader’s type definition. If the writer determines that the types are not equal, it will consider the topic inconsistent and forbid communication. The reader will be unable to detect this inconsistency. However, the reader will not receive any data from the writer, so deserialization errors will be prevented just the same.)
• Non-compliant writers will communicate with compliant readers. The reader will allow type coercion. This behavior provides maximum flexibility without requiring changes to deployed non-compliant applications.
(Suppose the reader has out-of-band knowledge of the writer’s type definition. If the reader determines that the types are not assignable, the writer will be unable to detect this inconsistency and may send data to the reader nonetheless. The reader implementation will need to detect and eliminate this extraneous data without attempting to deserialize it—for example, by checking upon receiving the data from the socket whether the source data is actually from a matched writer. This edge case is little different from other preexisting cases, such as the use by a non-matching writer of a multicast address used by the reader. Therefore, it is not expected to be a barrier to implementation.)

The specification contains the following typographical errors:
• Section 7.6.1.3.1, TypeConsistencyEnforcementQosPolicy: Conceptual Model, bullet EXACT_NAME: “…they’re structural definitions…” should be “…their structural definitions….”
Resolution:
Fix the errors as described above.
Revised Text:
Revisions are described in the summary above

Fix the errors as described above.
Note that the typo is section 7.6.1.3.1 will be addressed automatically by the resolution to issue #15702, which replaces the text is question. If no further typos are added to this issue, it can be closed as a duplicate of that issue.
Revised Text:
Revisions are described in the summary above.
Disposition: Merged with issue 15702

The type assignability rules for structure types (section 7.2.4.5, Aggregation Types) allow mutable types to be assigned in either direction, so long as there are no name, ID, or type conflicts among the types’ members. Unfortunately, these rules permit a degenerate case: two mutable types having no key members and no members in common will have no conflicts, and therefore will be considered assignable. However, readers will always observe every sample to have all default/empty contents.
Resolution:
Add an additional rule to the assignability determination to require that at least one member is in common.

Add an additional rule to the assignability determination to require that at least
one member is in common.

Currently, the XML Type Representation and XML Data Representation do not define XML namespaces. This omission prevents XML documents of these types from being used in certain contexts, such as within XML catalogs or SOAP messages.
Resolution:
1. Specify the XML namespace for the XML Type Representation. This namespace shall be formed by appending the OMG document number of the specification to the OMG HTTP domain in the following way: http://www.omg.org/<TF or TC>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the beta 1 specification would be: http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
2. Allow the association of a target namespace with the XSD Type Representation of a set of types, such that documents conforming to such type definitions may be properly validated against that namespace. This target namespace will be implied by the fully qualified name of each non-nested type, such that all DDS types, regardless of which Type Representation was used to define them, implicitly define a target namespace that can be used to validate XML Data Representation documentsThis mechanism will be specific to the XSD Type Representation; the concept of a target XML namespace will not be promoted into the Type System (or, by extension, into other Type Representations). (This implied target namespace will be a URN, not a URL; it will not be possible to dereference it.)
2.3. Allow applications the choice of whether to include XML namespaces on the network. Split the XML Data Representation into two dialects: XML_VALID and XML_WELL_FORMED. The former will include explicit namespace declarations and properly qualify all element and attribute names. The latter will, for the sake of compactness, omit namespace information.

1. Specify the XML namespace for the XML Type Representation. This
namespace shall be formed by appending the OMG document number of the
specification to the OMG HTTP domain in the following way:
http://www.omg.org/<TF or TC>/<year>/<month>/<document
ordinal>/<section_name>. For example, the namespace for the beta 1
specification would be:
http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
2. Allow the association of a target namespace with the XSD Type
Representation of a set of types, such that documents conforming to such
type definitions may be properly validated against that namespace. If this
target namespace is not specified explicitly, it shall be implied by the fully
qualified name of each module, such that all DDS types, regardless of which
Type Representation was used to define them, implicitly define a target
namespace that can be used to validate XML Data Representation
documents. The implied namespace shall take the form
ddstype://www.omg.org/<module path>, where <module path> is a
list of enclosing modules, separated by forward slashes, from outermost to
innermost. (Note that this implied target namespace is a URN, not a URL; it
will not be possible to dereference it.)
3. Allow applications the choice of whether to include XML namespaces on the
network. Split the XML Data Representation into two dialects: “valid” and “well
formed.” The former will include explicit namespace declarations and properly
qualify all element and attribute names. The latter will, for the sake of
compactness, omit namespace information.
With respect to (#2), the ability of an XSD author to explicitly specify a target
namespace—rather than relying on a module-based implied namespace—is
important to retain compatibility with the CORBA to WSDL/SOAP Interworking
Specification, on which the XSD Type Representation depends. The authors of
that specification explicitly chose not to support module-based namespaces for
performance reasons, as described in section 4.1.4 of that specification.

One of the reasons for the development of the DDS-XTypes specification was the prior lack of explicitness and formality in the DDS type system and in its representations. DDS-XTypes addresses this need—and simultaneously extends both the type system and its representations. It would help the discourse about DDS systems, and the modeling of DDS systems, if a subset of DDS-XTypes were defined that identified only those parts of DDS and/or DDS-RTPS that were in broad use before the existence of DDS-XTypes.
This subset would include the following:
• A subset of the Type System:
o The full set of primitive types
o Strings of narrow or wide characters
o Sequences
o Aliases
o Structures without inheritance and with “final” extensibility
o Enumerations
o Unions
• The IDL Type Representation of the above
• The CDR Data Representation of the above
• The Plain Language Binding for the above

Identify the above subset of the specification in a new, non-normative, annex

The IDL Type Representation defines syntax for Type System concepts that were previously not expressible in IDL, such as annotations, maps, etc. This syntax is currently defined in prose and with examples. The specification should additionally provide a formal EBNF grammar.
Resolution:
Add EBNF grammar constructs to the relevant sections of the specification document.

Add EBNF grammar productions to the relevant sections of the specification document.
To avoid whitespace sensitivity in these productions, modify the Alternative (comment-like) Syntax when multiple annotations are applied. Instead of writing this:
//@MyFirstAnnotation @MySecondAnnotation
…write this:
//@MyFirstAnnotation //@MySecondAnnotation

The Type System currently allows a type designer to specify that the storage for a type member may be located outside of the type itself. (This is an important capability when, for example, objects of the member’s type are very large.) However, it provides insufficient flexibility when such objects are stored in collections: the entire collection may be stored externally, but the collection members must be stored contiguously.
Resolution:
Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.

Enhance the Type System to allow collection elements to be shared, not just members of aggregation types. In the IDL Type Representation, this shall be expressed syntactically by the application of the built-in @Shared annotation to the collection member type.
Note that this resolution does not provide a general-purpose annotation facility for collection members. It merely provides an appropriate Type System property and Type Representation syntax to express it.
Sequences:
sequence<@Shared Foo, 42> sequence_of_foo;
// or:
sequence<
Foo, //@Shared
42
> sequence_of_foo;
Arrays:
Foo array_of_foo @Shared [42];
// or:
Foo array_of_foo //@Shared
[42];
Maps:
map<string, @Shared Foo, 42> map_of_string_to_foo;
// or:
map<
string,
Foo, //@Shared
42
> map_of_string_to_foo;
Strings: Strings will not support this feature (i.e. individual characters cannot be stored externally to the string itself). Since string elements can only be individual narrow or wide characters, this “limitation” in theory is not expected to be a limitation in practice.

The DynamicData class, part of the Dynamic Language Binding, has a huge API consisting of many dozens of methods. This large size makes the API harder to understand and reuse.

Change the design of the class to reduce the size of the API. Specifically:
• Replace navigation by name, ID, or index with navigation by ID only. Provide conversion methods to obtain the ID based on either of the other two. When the object is of some type for which the concept of “member ID” is not applicable (e.g. sequences), the user can nevertheless convert from the index to a “member ID” and look up based on that. It is not necessary to specify the mapping from index to ID in such cases; all that matters is that the implementation can provide one. (Where the range of indexes and IDs overlap, the “mapping” could even be a no-op.)
• Coalesce access to sequences and arrays.

The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. Some of these specializations contain additional “overloads” of DDS-standard types-specific methods for the sake of convenience. However, some of these overloads are not correct:
• KeyedStringDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
• KeyedStringDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
• KeyedStringDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
• KeyedStringDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
• BytesDataWriter::write_string_w_bytes should be named BytesDataWriter::write_w_bytes (copy-paste error).
• BytesDataWriter::write_string_w_bytes_w_timestamp should be named BytesDataWriter::write_w_bytes_w_timestamp (copy-paste error).
• KeyedBytesDataWriter::unregister_instance_w_key does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance method specified by DDS.)
• KeyedBytesDataWriter::unregister_instance_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to unregister based on the key, so the handle should be removed. (Users wishing to unregister based on an instance handle can use the typical unregister_instance_w_timestamp method specified by DDS.)
• KeyedBytesDataWriter::write_bytes_w_key doesn’t actually include the key among its arguments. It should.
• KeyedBytesDataWriter::write_bytes_w_key_w_timestamp doesn’t actually include the key among its arguments. It should.
• KeyedBytesDataWriter::dispose_w_key does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose method specified by DDS.)
• KeyedBytesDataWriter::dispose_w_key_w_timestamp does not need to take both a string key and an instance handle. The purpose of this method is to dispose based on the key, so the handle should be removed. (Users wishing to dispose based on an instance handle can use the typical dispose_w_timestamp method specified by DDS.)
Resolution:
Correct the method signatures as described in the summary above.

Correct the method signatures as described in the summary above

The IDL file contains specializations of all of the type-specific interfaces for the new built-in types: “Foo”DataWriter and “Foo”DataReader. However, the FooTypeSupport definitions are not included. These specializations require no method overloads; however, they should be included for the sake of clarity and completeness.
Resolution:
Add the missing type definitions.

Add the missing type definitions

Section 7.3.1.1.2, Forward Compatibility with Respect to Compilers, defines a pragma declaration that IDL file authors can use to delimit portions of their IDL files that require certain versions of this specification. Especially since IDL files can include one another, it would be helpful if such pragma declarations were allowed to nest within one another.
Resolution:
Allow pragma declarations to nest.
• Any version number specified by a nested pragma overrides the enclosing version number, if any.
• Any unclosed declaration shall be considered to continue until the end of the input.
In addition, the pragma “end” declaration shall—like the “begin” declaration—allow a version number to be specified to clarify the nesting relationship.

Allow pragma declarations to nest.
• Any version number specified by a nested pragma overrides the
enclosing version number, if any.
• Any unclosed declaration shall be considered to continue until the end of
the input.
In addition, the pragma “end” declaration shall—like the “begin” declaration—
allow a version number to be specified to clarify the nesting relationship.

The specification provides equivalent definitions for the built-in annotations defined by the IDL Type Representations. However, it only includes these in the specification document, not in the IDL file.
Resolution:
Add these definitions to the IDL file. Add this content as an additional annex in the specification document.

Add these definitions to the IDL file. Add this content as an additional annex in
the specification document

The specification dictates that the new QoS policies DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy apply to Topics, DataReaders, and DataWriters. These additions are reflected in the IDL file by the inclusion of corresponding members in the built-in topic data types TopicBuiltinTopicData, SubscriptionBuiltinTopicData, and PublicationBuiltinTopicData. Corresponding additions to TopicQos, DataReaderQos, and DataWriterQos are therefore implied, but updated definitions of those types are not provided in the IDL file.
Resolution:
Add the missing type definitions to the IDL file.
The type extensibility kinds of the QoS structures should be MUTABLE to be consistent with the built-in topic data types, which are also containers of QoS policies and which have that extensibility kind.

Add the missing type definitions to the IDL file.
The type extensibility kinds of the QoS structures should be MUTABLE to be
consistent with the built-in topic data types, which are also containers of QoS
policies and which have that extensibility kind.

The IDL file augments the DDS-standard QoS policies with meta-data defined by this specification in a way that is consistent with the serialization of those policies as defined by the DDS-RTPS specification. Specifically, it defines each policy to be “nested” (meaning that it is intended to be propagated only when contained within another type) to have an extensibility kind of EXTENSIBLE (meaning that members can be appended to the end of the type, but that members cannot be inserted in the middle or reordered).
In contrast, the two new QoS policies introduced by the specification—DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy—are defined to be nested, but their extensibility kinds are not specified. Per this specification, the kind EXTENSIBLE will be inferred by default but could be overridden by implementations. In order to be clear and avoid potential interoperability problems, these types should explicitly specify the extensibility kind EXTENSIBLE, just as all other policies do.
Resolution:
Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY) to the definitions of DataRepresentationQosPolicy and TypeConsistencyEnforcementQosPolicy in the IDL file.

Add the built-in annotation @Extensibility(EXTENSIBLE_EXTENSIBILITY)
to the definitions of DataRepresentationQosPolicy and
TypeConsistencyEnforcementQosPolicy in the IDL file.

Summary:
In the IDL definitions for the specification section Representing Types with TypeObject, some members of type MemberId are named simply member, and some members of type TypeId are named simply type. The fact that the integral types of these members represent IDs is clear to readers of the IDL or to readers of generated code in languages that support typedef (such as C), because the type name is explicit. However, in Java and other programming languages that do not support typedef, the types of these members degrades to simply int (or another built-in integral type). This type obscures the meanings of the members.
Resolution:
Name the members in question more explicitly: member_id and type_id.
Revised Text:
Rename the following type members in the IDL file:
• AnnotationUsageMember::member ? AnnotationUsageMember::member_id
• AnnotationUsage::type ? AnnotationUsage::type_id
• TypeProperty::id ? TypeProperty::type_id
• MemberProperty::id ? MemberProperty::member_id
• MemberProperty::type ? MemberProperty::type_id

Name the members in question more explicitly: member_id and type_id.

The Type System defines a type member attribute shared, which indicates that a member should be stored by reference instead of by value to enable the use of external stores—for example, for large data members. This attribute appears in the TypeObject IDL definitions as a built-in annotation @Shared. However, this built-in annotation is never formally defined. (Possibly, it was deleted accidentally in a previous revision of the specification document.)
Resolution:
Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.

Add a section defining this built-in annotation to section 7.3.1.3, Built-in Annotations.
Issue 15707, Improve support for shared data, needs to update the description of this new section. The FTF should not create the section in this issue only to modify it in that one. Rather, we should merge this issue with that one and make the entire change in one place.
Revised Text:
See issue 15707.
Disposition: Merged with issue 15707

The IDL definition of the type AnnotationDescriptor from the section Representing Types with TypeObject depends on a typedef “Parameters,” which is an alias to a string-to-string map. This type definition was present in earlier revisions of the IDL file but was inadvertently deleted in the adopted revision.
Resolution:
Restore the missing type definition.
Revised Text:
Add the following definition immediately before AnnotationDescriptor in the IDL file:
typedef map<ObjectName, ObjectName> Parameters;

Restore the missing type definition.