First, thank you for this specification. It provides a systematic and comprehensive definition of the runtime type system which is important in the context of the next version of Experimental Physics and Industrial Control System (http://www.aps.anl.gov/epics/). Moreover, from my perspective, the conceptual idea of the dynamic container is more generic than DDS and EPICS and addresses other technologies, like AMQP. In this regard, I have several suggestions for the DynamicData interface of the Language Binding section, particularly, to scale down the number of methods from 270 to 30 and to replace the 'out' arguments with return values.

At this time, we are working on the prototype of this variant based on the consolidation of several approaches, including DDS Dynamic Data, Google's Protocol Buffers, etc. Certainly, for us, it would be ideal to have some common solution. According to the Beta 1 procedure, OMG will accumulate comments by November 29. But, probably, it can be discussed earlier, for example, at the coming OMG technical meeting. Please advise.

non issue, closed

DynamicType has a property "descriptor" of type (read-only) TypeDescriptor. This property is mapped to IDL as a readonly attribute. When code is generated for this attribute in C or C++, the corresponding getter is not consistent with the other getters in the same class, either in terms of its style or in terms of its memory management. (The other getters are all defined explicitly as methods in IDL.)

Proposed Resolution:
Remove this member and add an explicit getter method:

DDS::ReturnCode_t get_descriptor(
inout TypeDescriptor descriptor);

This method overwrites a user-provided object, just like get_member_by_name and get_annotation.

Remove these attributes and add explicit getter methods, like:
DDS::ReturnCode_t get_descriptor(
inout TypeDescriptor descriptor);
This method overwrites a user-provided object, just like DynamicType::get_member_by_name and get_annotation

The specialized Primitive Types defined for Int, UInt, Float, Boolean, etc... each define a property 'value' that is typed by the property's owner thus resulting in a circular reference in the model.

Figure 6
Figure 7
Figure 8

Each of these are specializations of the PrimitiveType abstract class. Changing the UML instance of the PrimitiveType definition to a UML:PrimitiveType will automatically convey the semantic that an instance of the specialized PrimitiveType is the value itself.

NB: To do this in Enterprise Architect recreate the PrimitiveType abstract definition as an instance of the 'Primitive' element found in the 'Class' toolbox.

Remove the value members

The specification introduces the concept of optional members into DDS data types. However, it does not address how comparisons of these members should work in content-filtering expressions. For example, if a content-filtered topic indicates that all samples are of interest where "x != 5", but x is not present in the sample at all, does the sample pass the filter or not?

Proposed resolution: Introduce the notional value "null" that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.) A member's value in a given sample shall be considered to be equal to null if that member is not present in the given sample. Its value shall not be considered equal to null if it is present.

Optional members:
Introduce the notional value “null” that may be used in a content-filter expression. The null value is not equal to any value in the domain of any data type. (That is, x != null for any non-null value of x.)
• An optional member’s value in a given sample shall be considered to be equal to null if that member is not present in the given sample.
• Its value shall not be considered equal to null if it is present.
• A non-optional member’s value shall never be considered equal to null.
Maps:
Use the same syntax as arrays and sequences, but instead of a numeric index, use the stringified representation of the key to be queried as a string literal. Such an expression evaluates to the “value” element of the map that is associated with the given key. For example:
my_map['foo'] = 'bar'
my_map['5'] = 'baz'
Bit sets:
Use the same syntax as arrays and sequences, but instead of a numeric index, use the enumerated constant identifying the desired bit. Such an expression evaluates to a Boolean value: true if the named bit is set or false if it is not. For example:
my_bitset['MY_BIT_CONSTANT']
Specify the above rules in a new section 7.6.5, “DCPS Queries and Filters”. Include the relevant updates to the DCPS Queries and Filters grammar (from Annex A in the DDS 1.2 specification).
In addition, include a description of the following things that should be described in DDS already but seem to be missing:
• The use square bracket syntax for arrays, strings, and sequences
• Boolean literals
An issue should be filed against DDS for this, but the resolution of this issue should not wait for it to be acted upon.

The above-mentioned attributes (Figures 28 and 37) have types defined in the form "xxx --> yyy" which has no meaning in UML. Please clarify and correct.

Change the type of AnnotationDescriptor::value to Map<String, String>.
Unify the property DynamicData::descriptor with the existing association to MemberDescriptor, and qualify this association by MemberId.
Change the property DynamicData::value to an association to Type, and qualify this association by MemberId.

The following figures exhibit inconsistent application of data types to attributes, operations and parameters:
Figure 4
Figure 9
Figure 10
Figure 13
Figure 14
Figure 16
Figure 26
Figure 30
Figure 33
Figure 36
Figure 37
Figure 38
Figure 39

Certain attributes/parameters have 'int' or 'string' applied which conflict the data types defined within the aforementioned model, and the PrimitiveTypes defined in UML. What is the intent with these? Which set of primitive data types are intended for application here (IDL? Java, C++, UML, XTypes?)

For example, the 'Enumeration' class in Figure 10 defines a 'bit-bound' property of type int.

Use DDS-XTypes types consistently. Note that Figures 9 and 16 are already correct—they use the DDS-XTypes-derived basic types, not the UML-built-in ones.
Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.

The following figures exhibit non-standard notation for specialized elements:
Figure 4
Figure 9
Figure 11
Figure 14
Figure 16
Figure 17
Figure 20

The textual notation showing generalized elements on specialized ones needs to either be hidden, or have the generalized element explicitly shown on the diagram (with generalization relationship between the elements showing).

NB: To hide the generalized element names on specialized ones in Enterprise Architect, double-click on a blank area of the diagram to open the Diagram Properties Dialog. On the "Diagram" tab deselect the "Show additional Parents" option.

Figures 4, 6–9, 12, 13, 15, 16, 17, 20, and 38: Simply hide the additional parents, as described above. Note that if the resolution to issue #16561 is accepted, the modification to figure 38 will be irrelevant, because the corresponding section of the document will be removed.
Figures 10, 11, and 14: Add class “Namespace” to the diagram.

The first rectangular symbol in Figure 3 contains truncated text - Type Representation

Fix the truncated text

have a new issue to file against the DDS-XTypes spec that was pointed out to me by Reinier Torenbeek.

Declared compatibility of types (i.e. type signature) includes base types but not derived types. Unfortunately, that means that a consumer using a base class unknown to an existing producer will not be able to consume data from that producer, because neither party will declare the relationship between the types.

For example: I publish Dog, which extends Animal. In version 2, a new intermediate class Mammal is introduced. However, a new consumer of Mammal won't match with a legacy producer of Dog, because both the Dog and Mammal endpoints declare that their types extend Animal, and neither one asserts that Dog should now extend Mammal.

Proposed Resolution:

Remove the type signature concept and go back to registering simple names. In its place, introduce a new QoS policy that lists assertions about which types extend which others. Consider making these assertions transitive. As today, the operative set of assertions when matching producers and consumers should be the union between the producer's and the consumer's sets.

Remove the type signature concept and go back to registering simple names

Source:

RTI (Mr. Alejandro de Campos, alejandro@rti.com)

Summary:

A small object-level assignability problem within a complex sample can result in an entire sample being discarded. For example, a string whose length is greater than the bound of a string it’s being assigned into must be discarded. A sequence with an unassignable member must be discarded. A structure with an unassignable member must be discarded. As a result, a small issue deep within a structure could cause a whole sample to be discarded. For example, an issue within a TypeObject could result in an entire built-in topic data sample being discarded and consequently a loss of discovery information.

Discussion:

If we attempt to prevent any possible semantic problem that could arise from partial samples, we will have to keep the existing draconian rules, which can have bigger impacts, as described above. Therefore, the rules should seek to be more lenient and allow type-aware code “above” the assignability algorithm to detect semantic problems.

Proposed Resolution:

The following are the cases identified in the specification in which individual objects may be unassignable:

· Strings that are too long: No change. Strings are a basic type, and truncation can generally not be easily detected by applications.

· Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.

· Sequences that are too long or contain unassignable elements: Discard only the offending elements, “left-shifting” subsequent elements and reducing the length as necessary.

· Maps that are too long or contain unassignable elements: No change. Map entries are not logically ordered, so elements may not be discarded in a stable fashion.

· Enumeration with unrecognized value: No change.

· Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.

· Structure with a “must understand” member not present in the destination type: No change—otherwise, the union would be malformed.

Add the following new rules:

· Structure with an unassignable non-optional member: The entire structure is considered unassignable. (This behavior was previously underspecified.)

· Structure with an unassignable option member: The member takes no value. The rest of the structure can theoretically be retained.

The following are the cases identified in the specification in which individual objects may be unassignable along with the changes to be made, if any:
• Strings that are too long: If the bound of a string increases, the string is unassignable. Strings are a basic type, and truncation can generally not be easily detected by applications.
• Arrays with unassignable elements: No change. In CDR, arrays have no length or other means of delimiting elements, so it is not possible to “truncate” them.
• Sequences that are too long or contain unassignable elements: If the bound of a sequence increases, or an element is unassignable, the whole sequence is unassignable. Applications have little ability to detect or mitigate sequence truncation, so automatic truncation is undesirable.
• Maps that are too long or contain unassignable elements: If the bound of a map increases, or an element is unassignable, the whole map is unassignable. Applications have little ability to detect or mitigate map truncation, so automatic truncation is undesirable.
• Enumeration with unrecognized value: No change.
• Union whose discriminator does not select a value in the destination type: No change—otherwise, the union would be malformed.
• Structure with a “must understand” member not present in the destination type: No change—otherwise, the structure would be malformed.
Add the following new rules for structures, which cover behavior that was previously underspecified:
• An unassignable non-optional member: The entire structure is considered unassignable.
• An unassignable optional member: The member takes no value. The rest of the structure can be retained.
• Mismatched “optional” attribute in a final or extensible structure: The types are not assignable. This restriction is necessary because of the header that precedes such members.

The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

The purpose of this concept is to distinguish cases where it is possible to delimit adjacent objects. This is necessary, for example, when deserializing arrays, to avoid a situation where extra members in an array element could throw off the deserialization of subsequent elements.

This definition is overly restrictive and can even prevent arrays of non-mutable elements from being assignable to themselves.

Proposed Resolution:

Amend the definition to consider any type strongly assignable to itself.

Proposed Revised Text:

The definition of the term “strongly assignable” in section 7.2.4, Type Compatibility: “is-assignable-from” relationship, states:

If types T1 and T2 are both mutable and T1 is-assignable-from T2, then T1 is said to be “strongly” assignable from T2.

Append the following sentence:

Any type is also considered (trivially) strongly assignable from itself, regardless of its extensibility kind.

Amend the definition of “strongly assignable” to consider any type strongly assignable to itself

OMG Issue No: ?????

Title: Incorrect default extensibility kind value in XSD file

Source:

RTI (Mr. Alejandro de Campos, alejandro@rti.com)

Summary:

The declaration of the complex type structOrUnionTypeDecl in the XSD file contains the following attribute declaration:

<xs:attribute name="extensibility"

type="extensibilityKind"

use="optional"

default="false"/>

However, “false” is not a valid value for the extensibilityKind type.

Proposed Resolution:

Change the default value to “extensible”.

Proposed Revised Text:

Replace the following attribute declaration within the complex type structOrUnionTypeDecl:

<xs:attribute name="extensibility"

type="extensibilityKind"

use="optional"

default="false"/>

…with this one:

<xs:attribute name="extensibility"

type="extensibilityKind"

use="optional"

default="extensible"/>

Change the default value to “extensible”.

The type assignability rules for unions have a number of problems (see the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types):

· The second and third bullets in the list of rules are redundant.

· According to the fourth bullet (assignability of default members), a union with a default label may not even be assignable to itself.

· The rules do not account for member IDs and names, which can be significant when deserializing objects in some data representations.

· The rules do not account for the fact that the discriminator may or may not be a key.

· The rules do not account for extensibility kind.

· The rules are under-specified with respect to malformed samples. Specifically, the discriminator may select a particular member X of the union, but the implementation may discover in its place a different member Y. (This situation will be detectable only with certain data representations.)

Proposed Resolution:

Apply the followin rules:

· Apply the member ID, name, and type matching rules for structures to unions as well.

· Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:

1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.

2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.

3. If both T1 and T2 have a default label, the corresponding members must be assignable.

· Either both types must have a key or neither.

· The extensibility kinds must match.

· Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. The impact is unspecified, although implementations may consider the object unassignable.

Proposed Revised Text:

Replace the center column of the UNION_TYPE row of the table in section 7.2.4.5, Aggregation Types, with the following:

UNION_TYPE if and only if it is possible to unambiguously identify the appropriate T1 member based on the T2 discriminator value and to transform both the discriminator and the other member correctly. Specifically:

· T1.discriminator.id == T2.discriminator.id and T1.discriminator.type is-assignable-from T2.discriminator.type.

· Either the discriminators of both T1 and T2 are keys or neither are keys.

· Any members in T1 and T2 that have the same name also have the same ID and any members with the same ID also have the same name.

· For each member “m1” in T1, if there is a member m2 in T2 with the same member ID then m1.type is-assignable-from m2.type.

· T1.extensibility == T2.extensibility.

· A discriminator value appearing in a non-default label of T2 selects a member m2. If the same discriminator value selects a member m1 of T1, then m1.id == m2.id.

· A discriminator value appearing in a non-default label of T1 selects a member m1. If the same discriminator value selects a member m2 of T2, then m1.id == m2.id.

· If both T1 and T2 have a default label, then the IDs of the members selected by those labels must be equal.

AND if T1 is final, the number of members in T1 is equal to the number of members in T2.

Remove the footnote that is linked to the old contents of that table cell.

Append the following paragraphs to the right-hand column of the same table row:

If either member of the union is unassignable, then the T2 object is unassignable to T1.

If the discriminator value of a union object and its non-discriminator member do not agree with one another, the object is considered malformed. In such a case, the behavior is unspecified. In particular, the implementation may or may not be able to detect this error. If it can, it should consider the object unassignable.

Apply the following rules:
• Apply the member ID, name, and type matching rules for structures to unions as well.
• Every discriminator value in T2 must select the “same” member in T1—or no member at all. This can be checked in three steps:
1. Every discriminator value in a non-default label of T2 selects the same member in T1 or none at all.
2. Every discriminator value in a non-default label of T1 selects the same member in T2 or none at all.
3. If both T1 and T2 have a default label, the corresponding members must be assignable.
• Either both types must have a key or neither.
• The extensibility kinds must match.
• Specify explicitly that an object of a union with a mismatch between its discriminator and non-discriminator members is considered malformed. If an implementation is able to detect this case, it shall consider the object unassignable. If not, then the impact is unspecified.

A bit set with bit bound <= 8 is mapped to a byte in some places (page 78 and 40) and to an unsigned short in others (page 88). (Page numbers refer to beta 2.)

Proposed Resolution:

A bit set with bit bound <= 8 should be serialized as a single byte.

Proposed Revised Text:

In the table in section 7.5.1.2.2, BitSet Types, replace these rows:

Bit Set Bound
Unsigned Integer Equivalent

1–16
unsigned short

…with the following:

Bit Set Bound
Primitive Equivalent

1–8
octet

9–16
unsigned short

A bit set with bit bound <= 8 should be serialized as a single byte.

The definition of PID_LIST_END in Table 27 in section 7.4.1.2.1, Interpretation of Parameter ID Values, reads:

RTPS specifies that the PID value 1 shall be used to terminate parameter lists within the DDS built-in topic data types. Rather than reserving this parameter ID for all types, thereby complicating the member ID-to-parameter ID mapping rules for all producers and consumers of this Data Representation, Simple Discovery types only shall be subject to a special case: member ID 1 shall not be used, and either parameter ID 0x3F02 or parameter ID 1 shall terminate the parameter list.

The meaning of “Simple Discovery types” is not clear. It should not apply to all mutable types that might ever be used as part of the Simple Discovery process. It is intended only to maintain backward compatibility with types defined in DDS-RTPS.

Proposed Resolution:

See the Proposed Revised Text below.

Proposed Revised Text:

Append an additional sentence: “These types consist of the built-in topic data types, and those other types that contain them as members, as defined by [RTPS].”

See the Revised Text below

Application code (i.e. business logic) generally depends statically on particular types and their members. Therefore, it is appropriate to define these types statically (e.g. in IDL) and generate code for them in order to take advantage of static type safety and improved performance.

In contrast, infrastructure code (i.e. logic that is independent of particular applications) generally must not depend on application-specific types, because such dependencies prevent that code from being reused.

These two kinds of code can exist within a single component. For example:

· The properties of application-specific types might be checked against a common set of rules to ensure that they meet organizational or program-specific guidelines.

· Certain design patterns may call for arbitrary application-specific types to be augmented in uniform ways.

· Type-specific application activities, such as reading and/or writing data, might be logged or recorded.

The straightforward way to handle these scenarios would be to:

1. Convert a generated type definition into a DynamicType object.

2. Convert an object of a generated type into a DynamicData object.

3. Pass these two dynamic objects to the infrastructure code and allow it to operate on them.

Unfortunately, the specification does not provide such a capability. Instead, applications have to manually construct DynamicType and DynamicData objects member by member. This code is not only verbose but also brittle, because if the static type definition changes (e.g. during development or across versions), it can grow out of sync with the hand-written code that manipulates that definition.

Discussion:

We need three new conversions:

1. TypeSupport à DynamicType

2. DynamicData à sample object

3. Sample object à DynamicData

These operations could either be added to the TypeSupport interface or to a “type builder” interface. The former approach is preferred, because the generic type parameter of the TypeSupport in the C++ and Java PSMs allows a degree of type safety that way.

Proposed Resolution:

Introduce three new TypeSupport operations:

1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.

2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object. If the DynamicType of the DynamicData is not compatible with the TypeSupport’s data type, raise an error.

3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

Proposed Revised Text:

TO DO

Introduce three new TypeSupport operations:
1. get_type: Get a DynamicType object corresponding to the TypeSupport’s data type.
2. create_sample: Create a sample of the TypeSupport’s data type from an input DynamicData object.
3. create_dynamic_sample: Create a DynamicData object from an input sample of the TypeSupport’s data type.

The current DynamicType API allows a type definition to be changed. Such a change can be ambiguous at best and dangerous at worst.

· Suppose that the type already types (DynamicData) objects. Should all of those objects refer to the old version of the type or the new version? If the new version, how shall we address the situation where the new type is inconsistent with the existing data contents?

· Suppose that the type has already been registered with some domain participant. Does the registered type name refer to the old version of the type or the new version? What shall be done about samples that may already have been published or received using the old version?

· Can DynamicTypeFactory cache and reuse identical types that are requested more than once? Ideally yes, but the ability to change a type makes the state management necessary to support this behavior very complicated.

It would be safer, clearer, and more efficient if DynamicType objects were immutable once created. That implies that either the factory must take sufficient inputs to fully create a type in one step, or we must employ a builder or similar pattern.

Discussion:

A builder pattern would give the application more flexibility in how to create new types. It would also nicely encompass the current load_type operations as well as hypothetical PSM-specific operations, such the creation of a DynamicType from a Java Class object.

Proposed Resolution:

TO DO

Proposed Revised Text:

TO DO

Define a new class DynamicTypeBuilder as a copy of the current definition of DynamicType. Remove from DynamicType all operations that modify an object, and add to DynamicTypeBuilder an operation build that returns a corresponding (immutable) DynamicType.
Update the existing DynamicTypeFactory to create instances of DynamicTypeBuilder instead of DynamicType. Rename this class DynamicTypeBuilderFactory accordingly.
Replace the existing operation DynamicType::clone with a corresponding create operation in DynamicTypeBuilderFactory.

Members of a structure or union type have a small number of metadata attributes, among them:

· optional: indicates that the member may or may not take a value in a particular sample

· must_understand: indicates that a consumer of the data must discard the sample if it encounters such a field in it

The type-level assignability rules detect mismatches respecting non-optional must_understand members. (Such members will always take a value, and therefore there is no possibility of data exchange between the producer and consumer.) However, must_understand members that are optional must be detected on a sample-by-sample basis: any sample that does not contain the offending member can be exchanged, but those that do cannot.

The XML Data Representation allows the encoding of the must_understand attribute within each sample, as does the parameterized encapsulation variants of the Extended CDR Data Representation. However, the traditional, non-parameterized encapsulation variants—used by final and extensible structures and unions—do not permit this attribute to be expressed. As a result, consumers will not be able to detect when it should have been present, and may therefore present incorrect data to applications.

Discussion:

The traditional CDR encapsulations prefix each optional member with a 32-bit “header” that indicates the presence and size of the member. In contrast, the parameterized CDR encapsulations prefix each member with a 32-bit parameter header that indicates the presence, size, ID, and metadata flags of the member, including must_understand. Therefore, we can reuse the parameter header structure we already have to solve this problem, instead of using just a 32-bit size, with no increase in overhead.

Proposed Resolution:

Reorganize the Extended CDR Data Representation section such that it first defines the parameter header structure and the member-ID-to-parameter-ID mapping. Second it shall define the traditional encapsulation variants, and finally it shall define the (fully) parameterized encapsulation variants.

Within the middle section—traditional CDR—update section 7.4.1.1.5.2, “Optional Members.” Remove the description of a 32-bit size, and in its place describe the use of a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

Proposed Revised Text:

TO DO

Update section 7.4.1.1.5.2, “Optional Members.” Instead of preceding each optional member with a 32-bit size, use a parameter header. Note that either the four-byte header defined by DDS-RTPS or the 12-byte extended header defined by DDS-XTypes may be used.

Source:

RTI (Mr. Alejandro de Campos, alejandro@rti.com)

Summary:

Each DDS QoS policy must define a couple of attributes: whether or not the policy has request-offer (RxO) semantics and whether or not it can be changed after an entity is enabled. The two new QoS policies defined by DDS-XTypes—TypeConsistencyEnforcementQosPolicy and DataRepresentationQosPolicy—define the first part but not the second.

Discussion:

Because of their potential interactions with historical data, neither of these policies should be changeable after an entity is enabled.

Proposed Resolution:

State in the introduction to each policy that its value cannot be changed after an entity is enabled.

Proposed Revised Text:

TO DO

State in the introduction to each policy that its value cannot be changed after an entity is enabled

The specification contains the following identified typographical errors:

· The third bullet in section 2.2, “Network Interoperability Conformance”, which begins with “Data Representation…”, is lacking an opening parenthesis at the start of the second sentence. The closing parenthesis is already present.

Proposed Resolution:

See the trivial corrections described above.

Proposed Revised Text:

See the trivial corrections described above

See the trivial corrections described above

The type_name members of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are bounded at 256 characters. The equivalent_type_name and base_type_name members store sequences of type names, but the strings in those sequences are unbounded. The flexibility to store strings of any length is unnecessary, because no string can appear there that doesn’t also appear in a type_name somewhere, and is therefore of 256 characters or less.

This issue is minor in that it does not impact correctness. However, it does impact clarity to a small extent and can impact the efficiency of some implementations.

Proposed Resolution:

Define a typedef “TypeName”, a string bounded at 256 characters. (See also issue #15969.)

Define a typedef “TypeNameSeq”, an unbounded sequence of TypeName elements.

Change the type of the equivalent_type_name and base_type_name members from StringSeq to TypeNameSeq.

Proposed Revised Text:

TO DO

This issue is obsolete in the face of issue #16561: the resolution of that issue eliminates the type signature concept altogether. Therefore, this issue should be merged with that one.
Disposition: Merged with issue #16561

A DynamicData object may encapsulate the state of an object of a collection type—a sequence, array, string, or map. In such a case, it is necessary to be able to get and set the length of the collection.

Discussion:

We need to add an accessor for the current length. This accessor can also be useful for other object of other types; for example, it can return the number of members in a structure.

However, it is not appropriate to add a mutator for the length directly:

· If the length of a collection is increased, that implies the addition of new elements. But the values of these new elements will not be meaningful.

· If the length of a collection is decreased, that implies the removal of existing elements. But that may not be meaningful (what does it mean to remove a non-optional member of a structure?) of useful (why would you want to clear the fifth element of a bit set just because of what its index is?).

· The lengths of some types cannot legally be changed at all—for example, array types.

Therefore, it is better to allow elements to be added and removed, where appropriate, and thereby modify the length implicitly.

Proposed Resolution:

Add an operation get_length to the DynamicData class.

· If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the bound.

· If the object is of a bit set type, return the number of named flags that are currently set in the bit set.

· If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.

· If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.

· If the object is of a primitive or enumeration type, it is atomic: return one.

· If the object is of an alias type, return the value appropriate for the alias’s base type.

Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:

· For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.

· For a map type, use get_member_id_by_name to obtain an ID for the new map key.

Proposed Revised Text:

TO DO

Add an operation get_item_count to the DynamicData class.
• If the object is of a collection type, return the number of elements currently in the collection. In the case of an array type, this value will always be equal to the product of the bounds of all array dimensions.
• If the object is of a bit set type, return the number of named flags that are currently set in the bit set.
• If the object is of a structure or annotation type, return the number of members in the object. This value may be different than the number of members in the corresponding DynamicType—for example, some optional members may be omitted; see the existing DynamicData documentation.
• If the object is of a union type, return the number of members in the object. This value will always be two: the discriminator and the current member corresponding to it.
• If the object is of a primitive or enumeration type, it is atomic: return one.
• If the object is of an alias type, return the value appropriate for the alias’s base type.
Expand the contracts of the existing set_<type>_value operations to allow them to append new elements to resizable collections—strings, sequences, and maps. (This behavior is aligned with the existing contract of the clear operations, which states that cleared elements of resizable collections shall be removed.) Obtain the member ID associated with the new value as follows:
• For a string or sequence type, use get_member_id_at_index to obtain an ID for the index one greater than the current length.
• For a map type, use get_member_id_by_name to obtain an ID for the new map key.

The equivalent_type_name and base_type_name fields from TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData are described in the prose of the specification and are reflected in the IDL file. However, they missing from the annex; they need to be added.

• Replace all literal-formatted text in Annex A (beginning with “<?xml…”) with the contents of the XSD file accompanying the specification.
• Replace all literal-formatted text in Annex B (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
• Replace all literal-formatted text in Annex C (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
• Replace all literal-formatted text in Annex D (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
• Replace all literal-formatted text in Annex E (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.
• Replace all literal-formatted text in Annex F (beginning with “module DDS”) with the corresponding content from the IDL file accompanying the specification.

The C++ mapping for the new MAP type needs a precise specification of member (or key) access semantics and memory management rules like the CORBA C++ mapping describes for the SEQUENCE type on pages 36-42 (par. 4.15) of the C++ language mapping, version 1.2, formal/2008-01-09.

Close this issue without making any change.
Disposition: Closed, no change

Allthough the specification of the MAP_TYPE in paragraph 7.2.2.3.4 refers to restrictions for key element type this is not formalized in either the specification for the IDL representation for maps or the C++ language mapping.

It should be clearly noted (for the IDL representation in bnf) that the key element type is restricted to integer and string types only.

The current IDL representation specs for map leave all options open for defining the key element type.
Although the specs in paragraph 7.2.2.3.4 describe the use of other element types as 'behaviour undefined' this is not clear enough as the chosen C++ representation simply will not work when f.i STRUCT or UNION types are chosen as key element type.

In section 7.2.2.3.4, provide a rationale for the restriction on key types.
In the section on the Plain Language Binding for map types (7.5.1.3), clarify that the use of an unsupported key element type shall result in a compilation error. Further indicate that in C++ (section 7.5.1.3.1), the Compare function implementation shall consider the character contents of strings; it shall not compare pointer values.

IDL Anonymous type declarations should not be used in IDL examples and the 'dds_xtypes.idl' file as this form of type declaration has been deprecated by the latest CORBA specs and will cause compatibility problems with modern CORBA IDL compilers.

• In the definitions of GroupDataQosPolicy, TopicDataQosPolicy, and UserDataQosPolicy, replace sequence<octet> with ByteSeq. This change removes occurrences of an anonymous type inherited from DDS itself.
• In the definitions of TopicBuiltinTopicData, PublicationBuiltinTopicData, and SubscriptionBuiltinTopicData, replace the type of the name, topic_name, and type_name fields (string<256>) with the existing typedef ObjectName. This change removes occurrences of an anonymous type inherited from DDS itself.
• In the definitions of Bytes and KeyedBytes, replace sequence<octet> with ByteSeq.
• Introduce two typedefs: “VerbatimLanguage” and “VerbatimPlacement”, the first a string bounded at 32 characters and the second at 128 characters. Change the type of the member Verbatim::language to VerbatimLanguage and the type of Verbatim::placement to VerbatimPlacement.