p16 7.3.6 cont'd

[19] context ConsumesDe inv:
component.contents->includesAll (consumess)

-> context ConsumesDef

p18 7.3.6 cont'd

[36] Contraints [33], [34], and [35] apply recursively to valuetype members that are valuetypes.

-> Constraints

p18 7.3.6 cont'd

[33, 34, 35, 36] isAcceptableKeyType (type)
isAcceptableKeyType (valueType : ValueDef) : Boolean
{ valueType.contents.forAll
( c | c.oclIsTypeOf(ValuefMemberDef) implies c.OclAsType (ValueMemberDef).isPublicMember)

-> c.oclIsTypeOf(ValueMemberDef)

-> c.oclAsType (ValueMemberDef)
(using lowercase "o" at c.oclAsType)

p19 top

else
         result = home.key
endi f }

-> endif }

p32 paragraph below Figure 7.16, last sentence

The Binding metaclass has two attributes: “name” (the name of the Binding) and “CCMQoS
metamodel: Bindingmandatory” (if “true,” then the QoS property is bound in any case).

-> Change “CCMQoS metamodel: Bindingmandatory” to “mandatory”

p44 CORBAUnion example

        enum Contents
        {
              INTEGER_CL;
              FLOAT_CL;
              DOUBLE_CL;
              COMPLEX_CL;
              STRUCTURED_CL;
        };

The delimiter for enum values is a comma; the value list should be:

              INTEGER_CL,
              FLOAT_CL,
              DOUBLE_CL,
              COMPLEX_CL,
              STRUCTURED_CL
        };

p45 Figure 8.9 - Union example (a)

-> Remove class «CORBAUnion» "Reading", it is redundant to fig. 8.10

p45 Figure 8.10 - Union example (b)

 ┌──────────────────────────────────────────────────────────┐
 │                      «CORBAUnion»                        │      
 │                        Reading                           │      
 ├──────────────────────────────────────────────────────────┤
 │ «CORBASwitch» discriminator: Contents                    │      
 │ «CORBACase» a_long: long {lable=INTEGER_CL}              │      
 │ «CORBACase» a_double: double {lable=FLOAT_CL, DOUBLE_CL} │
 │ «CORBACase» an_any: any {lable=default}                  │      
 └──────────────────────────────────────────────────────────┘

"lable" -> "label"

p45 CORBAStruct example

        struct Problem
        {
              string expression;
              Fraction result;
              Boolean correctness;

-> boolean correctness;
(lowercase "b" at "boolean")

p49 CORBAArray list 1st bullet 4th sentence

• Named by a typedef declaration arrays are represented by the UML DataType [...]
  [...] The value of the “tag „index” is a list of integers separated by comma [...]

-> The value of the tag “index”

p62 Constraints

[43-4] Contraints [43-1], [43-2], and [43-3] apply recursively to [...]

-> Constraints

p62 Constraints

[43-1, 43-2, 43-3, 43-4] isAcceptableKeyType(type)

isAcceptableKeyType (valueType : ValueDef) : boolean
{ valueType.contents.forAll (c | c.oclIsTypeOf(ValuefMemberDef) implies
c.OclAsType(ValueMemberDef).isPublicMember) and

-> c.oclIsTypeOf(ValueMemberDef)

-> c.oclAsType(ValueMemberDef)
(with lowercase "o" at c.oclAsType)

p63 8.2.3 Example

        typedef enum PhilosopherState
        {

Use of `typedef` in this context is archaic. Omit `typedef`:

        enum PhilosopherState
        {

p63 8.2.3 Example

        eventtype StatusInfo {
              public  string name;
              public  PhilosopherState state;
              public  long secondesSinceLastMeal;

-> secondsSinceLastMeal

p66 Figure 8.25 bottom left

        ┌─────────────────────┐
        │   <<enumeration>>   │
        │  ComponentCategory  │
        ├─────────────────────┤
        │ ▱ session           │
        │ ▱ entity            │
        │ ▱ process           │
        │ ▱ sevice            │
        │ ▱ extension         │
        └─────────────────────┘

-> service

p71 paragraph before 8.4.2

[...] All these files are represented using a UML Artifact with stereotypes
<<CORBAAComponentFile>>, <<CORBAAIDLFile>>, <<CORBAAContainedFile>>, and <<CORBAADependentFile>>.

-> CORBAComponentFile , CORBAIDLFile , CORBAContainedFile , CORBADependentFile

p71 Table 8.4 rightmost column header Const-raints

-> Constraints

p82 Class2Interface

Class2Interface (cl, itf)
FORALL UML1Class cl WHERE c.stereotype = "CORBAInterface" || "CORBAHome“
CREATE UML2Interface itf
SETTING itf.stereotype = cl.stereotype, itf.name = cl.name, itf.attribute = cl.attribute, itf.operation = cl.opertaion,

-> cl.operation

p86 9.2.1 example, cont'd

      interface RetrieveRadarData {
          /* callculates the List of radar contacts visible for a given position of a Radar */

-> calculates

Page 47 beneath Figure 8.13 contains:

The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAString>>, <<CORBAWstring>>, and <<CORBASequence>> stereotypes. All <<CORBATemplate>> elements have a tag “bound” that indicates the maximum size of the element.

Page 48 CORBASequence contains:

Sequences are represented in the Profile by two means:

• Named by a typedef declaration sequences are represented by the UML DataType with the stereotype <<CORBASequence>>. Sequence members are represented by an attribute of the DataType, which always has the name “members” (profile keyword), members type is represented by the type of the “members”-attribute and the max size is represented by the multiplicity of the “members”-attribute.
  [...]

Thus there appear to be two mechanisms for specifying the string/sequence bound,

• either via the «CORBAString» / «CORBASequence» stereotype tag bound
• or via the typedef-datatype attribute members multiplicity upper bound

I propose following clarification:

When defining a bounded string or a bounded sequence,
* If the bound value is a plain number, the multiplicity upper bound of the "members" attribute shall be used for carrying the bound number.
* If the bound is a symbolic constant then the stereotype tag "bound" shall be used. It shall carry the fully qualified name of the IDL constant.

Reason:
Use of attribute multiplicity for the symbolic constant representing the string/sequence bound is problematic.
Most UML tools do not support such symbols in the UML attribute multiplicity expression.

Consider the following IDL:

module config {
   const short max_size = 8;
};
module types {
   typedef string<config::max_size> name_t;
   typedef sequence<boolean, config::max_size> bool_seq_t;
};

Here, in both cases the multiplicity of the members attribute shall not be used. Instead, the stereotype tag bound shall contain "config::max_size"
for the typedef-datatypes.

The IDL example on page 41 above Figure 8.6 is:

module Y
{
      constant short S = 3;
      interface X
      {
            constant long L = S + 20;
      };
};

The keyword for IDL constants is const, i.e.

      const short S = 3;
      [...]
            const long L = S + 20;

The document seems to missing the dds element at the very end of the schema.

Probably OBE, but the 1.0 version of the PDF also is missing the element. In the xsd version of the 1.0 spec, the root element is dds_ccm, which doesn't match the XML File Syntax section (page 46 of the version 1.0 PF).

Finally, the XSD download for 1.1 is not working when I click on the link on http://www.omg.org/spec/DDS4CCM/1.1/ Only the UML document is available in the informative machine consumable documents section.

Thanks.

We propose to remove key_fields completely from the DDS_TopicBase connector. The knowledge which fields are a key is specified in IDL using annotations and shouldn't be set again on the connector instance. This is duplicate information which could only lead to inconsistencies and possible problems. Until now we also have not seen any use case which require this information to be available as StringSeq as part of a connector instance.

In order to have the same memory management for the single data and datum operations, we propose to make all out arguments inout. This impacts:
Reader::read_one_last, info to inout
Getter::get_one, all arguments to inout

When registering a topic to DDS we need to use an unique combination of domain id, topic name, and typename. Recent discussions revealed that there is no standard for a default typename, but also there could be reasons why an user don't want to use the default type_name. We propose to add to the DDS_TopicBase connector a type_name attribute, which when set, will be used as type_name, if not set, the DDS vendor default type_name will be used for the topic type

The name patterns in the normative XML schema in Annex C do not support underscores. For detailed or lengthy profile names (especially including internal acronyms), using underscores significantly improves readability.

In addition, the elementName type is used both for the name and base_name attributes of the qosProfile type; however, the pattern for the elementName type does not support scoping, which is needed for inheritance between profiles in different libraries.

In order to address these, I propose that the elementName and topicNameFilter patterns be changed from:

"([a-zA-Z0-9 ])+"

to:

"^((:?([a-zA-Z0-9_])(:[a-zA-Z0-9_]))*)$"

The latter is the currently commented-out pattern in the schema with the addition of the underscore.

In some systems they are receiving the topic_name after startup, at some moment they just get it and want to set it to a new value. We propose to remove topic_name, there seems to be no technical or structural reason not to allow the user to change the topic_name after the connector fragment has been initialized

Section 8.4.4 talks about threading, but this section is really under specified. It should be much clearer how threading works and what guarantees are given.

Currently the DDS4CCM specification puts within the Typed module the extended ports, but also the dds connectors. The drawback of this approach is that when the user instantiates this templated module he gets both connectors, even when he is only interested in using one. We propose to move the DDS_State and DDS_Event to their own typed module so that the end user can instantiate just one of these connectors. This also makes it easier for a code generator to just generate the implementation for a specific connector, at this moment there is nothing in idl which can be used to determine whether the end user wants to use DDS_Event and/or DDS_State

is_filter_interpreted has to be documented as optional, not just the filtering of out.

This is because there is no required feature in the DDS core or part of the DDS DCPS specification which provides the INSTANCE_FILTERED_IN or INSTANCE_FILTERED_OUT status. Near as I can tell, this functionality comes as part of the DLRL layer "Selection_Listener" object (8.1.6.3.13).

See page 35, line 35,

read_one_last returns the last sample of a given instanceThe targeted

Missing dot after instance

This version of DDS4CCM adds the functionality to specify attributes as part of a porttype. This porttype can than be used by a component or connector as port or as mirrorport. The problem we see is that the attribute appears on the component/connector that uses the porttype as port or mirrorport. To our opinion the grammer should be more specific where the attribute appear, we propose to add the attribute by default to the component that uses the porttype as port, when the attribute has to appear on the component that uses the port as mirrorport we propose to define the attribute as:
mirror attribute my_attribute;

In case of DDS4CCM we see that the dds4ccm DDS_State connector gets 4 attributes which is what we want, but any user component using the porttype also gets a filter attribute

In paragraph 7.2.2.1.2, a note about interface Reader says:

<< Note: This interface is the basis for a passive data reader (i.e. a component that just looks at the data as they are). It is also very useful for the reactive data getters (i.e. components that need to react to new data, whether they choose to get them in pull mode or be notified in push mode) in their initialization phase. This is the reason why all the DDS ports on the subscribing side will embed a Reader basic port.>>

This note may let people think that it is ONLY useful in initialisation phase, which is not true. A clarification sentence would avoid that misunderstanding.

The model file ptc/11-02-11 is not valid UML – it has eclipse namespace and extraneous elements