what about making is_lifecycle_checked a regular attribute, so not read only?

No Data Available

The version of IDL3+ grammar extensions that I have shows

<connector_body> ::= "

"

Shouldn't that line be

<connector_body> ::= "

"

?

issue withdrawn by submitter

On the ConnectorStatusListener there is an on_unexpected_status method. What
is meant with an unexpected status, I don't find the spec clear in this
area. If this are the statuses we don't handle explicitly, what can the user
do with it? He gets the entity and the kind, but now the status field
itself? Is this usefull to add?

No Data Available

The InstanceHandleManager interface is defined as abstract, but shouldn't
this one also be defined as local (which means remove abstract, you can't
have both). By now having abstract, it is technically possible to derive a
regular (non local) interface from it. This means we have todo more code
generation as necessary.

We would like to propose to replace abstract with local.

Make this (abstract) interface local

The current QueryFilter in the spec seems to match best to a QueryCondition.
But DDS also provides the ContentFilteredTopic support, that doesn't seem to
be available at the ccm-dds level, is this intended?

The resolution is to add on the reading-side DDS ports a filter attribute and a
basic port to change filter parameters when appropriate (this basic port will be
used in the port and provided in the associated mirrorport). This disposal implies
to add configuration attributes in porttype definitions.
In addition, for clarity purpose, the formerly named "filter" attribute on the Reader
interface is renamed "query" and inside the QueryFilter structure, the first field
(formerly "query") is renamed "expression" and the second (formerly
"query_parameters") simplified to become "parameters".
Rationale:
• The current QueryFilter is definitively intended to match the DDS query.
ContentFilteredTopic is also a very important DDS feature that should be
accessible through ccm-dds.
• Configuration attributes fin porttype definitions is also useful for many
other uses of the GIS (was missing)

Consider that timeout and max_delivered_data act as maximum boundaries
(not minimums to be enforced). These just mean that you will never wait
more than timeout nor receive more than max_delivered_data data.
Applied to you precise questions:

1) should directly return with the 50 samples.

2) should return after receiving the first sample.

Add a better explanation

In 09-10-25, page 3, line 17, it says ExtendePortType instead of
> ExtendedPortType

Correct the typo

read_last returns the last sample of all instances. Any DDS error when
> reading the data will be reported by an InternalError exception.
> read_all returns all samples of all instances. Any DDS error when reading
> the data will be reported by an InternalError exception.
>
> But, what is a DDS error, is this != DDS_RETCODE_OK? What todo with
> DDS_RETCODE_NO_DATA, also then throw an exception or return an empty
> sequence?

Add a better explanation

I just noticed, in section 7.2.2.1, that 'array' is allowed as a type
designator for template parameters. So now it is also a keyword? it
isn't on the list of new keywords in 7.3.6.

Remove 'array' from allowed type designator.
Rationale: Purpose was to avoid as much as possible new keywords. Expressing
the fact that the parameter type must be of type array does not appear to be such
a significant use case that a new keyword is justified.

When we check the ConnectorStatusListener we see that it has an
on_inconsistent_topic. The CSL is part of the DDS_Base connector, but the
concept of a topic is added to the DDS_TopicBase which is derived from
DDS_Base. It looks inconsistent that the CSL has a callback for something
that is not known at that connector level.

Why do we have a DDS_Base and a DDS_TopicBase, why not merge them into one
connector base?

No Data Available

DDS_TopicBase::key_fields is read/write with nonchangeble. I am aware that
DDS doesn't have a standardized way to specify keys in IDL. At the CCM level
we always instantiate a connector for a specific IDL type. It looks a nice
feature to be able to ask to the connector what the key_fields are, that is
something the tooling can't get from the IDL itself. But, why should this be
a writable (but not changeable) attribute, couldn't it just be readonly, it
is just there for the component to retrieve, it can probably be implemented
with some vendor specific code.

No Data Available

In CCMComponentPortKind ExtendedPort and Mirrorport are added. First in
update 5, page 11, line 21, font of MirrorPort is not ok. The other issue is
that MirrorPort is a keyword, so it should be _MirrorPort or maybe
ExtendedMirrorPort to match the ExtendedPort.

In addition to the change “MirrorPort” to “ExtendedMirrorPort”, correction of two
other related mistakes
• “CCMPortKind” does not exist (“CCMComponentPortKind” instead)
• The name of the attribute is "kind" (“CCMComponentPortKind” is the
name of the enumeration)

In the DDS4CCM specification the IDL module name is sometimes CCM_DDS sometimes DDS_CCM. It should be CCM_DDS everywhere.

Nme always the module CCM_DDS

we propose to change the topic_name attribute to a regular attribute, not readonly

This attribute as well as the others on DDS-DCPS connectors are not
changeable dynamically as they are used to create and configure the DDS
entities in support to this DDS pattern. However as their configuration by an
external tool is highly desirable, they have been turned into regular attributes
which can raise a NonChangeable exception.

The DDS4CCM specification states that a component with a DDS port and the fragment of connector supporting this DDS port should be collocated but the related interfaces are not defined as local.

Define all interfaces used in the DDS ports as local

Why does 8.3.1 add the following attribute to the DDS_TopicBase? What is the functional meaning of this, shouldn't we just remove this attribute?

readonly attribute DDS::StringSeq key_fields;

No Data Available

on_subscription_matched is missing from the connectorstatuslistener, we propose to add this to one of the listeners

No Data Available

Currently DDS4CCM specifies the Updater port below. We are looking at using
register_instance/write/unregister_instance for this? If this port is
intended to deliver an abstraction of these methods, why don't we pass the
instancehandle back to the CCM Level?

Johnny

interface Updater<typename T>

;

Add the optional instance_handle parameter to each operation dealing with a
specific instance

We noticed that the (Multi)Updater uses delete as method name, this is a
reserved keyword in C++ which leads to _cxx_delete in the C++ mapping. Maybe
it is an idea to use different method names, like register/write/dispose as
in DDS? It is now a small change, but prevents users to use _cxx_delete when
using C++.

Disposition: See issue 14214 for disposition

On page 5, line 17, the spec says the following of extended ports:
>
> Extended ports allow grouping a set of single CCM ports (facet/provides
> and
> receptacle/uses), to define a particular semantic. The extended ports
> are
> declared in IDL3+ (extended IDL3 with new keywords). A new keyword is
> introduced to define extended ports (porttype) and to declare an
> extended
> port at component level (port).
>
> Shouldn't this be:
>
> Extended ports allow grouping a set of single CCM ports (facet/provides
> and
> receptacle/uses) and extended ports, to define a particular semantic.
> The
> extended ports are declared in IDL3+ (extended IDL3 with new keywords).
> A
> new keyword is introduced to define extended ports (porttype) and to
> declare
> an extended port at component level (port).
>
> So, add that an extended port can contain extended ports again.

No Data Available

On page 34 (word) on line 30 it gives the paragraph below. There is an
> inconsistency there, it says "a sequence" and the next sentence it says
> "each sequence". Looking at the IDL, it just is one sequence, so it
> should
> probably be "Depending of grouping mode, the sequence will contain"
>
> Johnny
>
> Behavior of a MultiListener is as follows:
> on_data is here called with a sequence of new values. Depending of
> grouping_mode, each sequence will contain 1) all the samples of an
> instance,
> 2) all new last samples or 3) all new samples.
> Query filter (if any) will be found in the associated Reader (see below
> -
> definition of DDS extended ports).

Disposition: See issue 14214 for disposition

The DDS4CCM spec says the following about specifying qos profiles
> > through
> > XML
> > ***
> > A QoS Profile shall be attached as a configuration attribute to a DDS
> > connector. This profile should contain all values for
> > initializing DDS Entities that are required by the connector.
> > ***
> > Shouldn't the attribute name also be standardized?

No Data Available

I have been thinking of how I could use the Multi* interfaces/ports. I can
imagine that a component developer first starts to use the basic ports and
when he is more concerned with efficiency/performance he wants to use the
Multi ports where he can send batches of data to DDS in one call. This looks
nice, but when he wants todo that, he has to use different ports, which
leads to a different component design. It is just not an easy change to make
a new implementation of the component, it will become something completely
different by use the other ports. No easy swap to a more efficient component
implementation.

I think we should remove all Multi ports and merge their functionality into
the regular ports. That way a component developer can use the more efficient
sequences based interfaces without large changes in models and deployment
plants.

Merge the multi-operations with the simple ones in a consolidated interface:
Writer + MultiWriter ¨ Writer
Updater + MultiUpdater ¨ Updater
RawListener + MultiListener ¨ Listener
StateLisener + MultiLisener ¨ StateListener
Take the opportunity of this recast of the IDL description for the DDS ports, to
better harmonize the names of the operations and to rationalize the roles of each
interface.

Several of the DDS ports have the following typedef:
typedef sequence<T> T$Seq;

This leads to an unique sequence type for each DDS interface (MultiWriter,
MultiUpdater, Reader, Getter, MultiListener). This leads to 5 times
typecodes, footprint, but also the sequences are really from a different
type in the programming language. A sequence returned from a Reader, just
can't passed directly into a writer, it are different sequences.

I think we do want to have the same sequence to be used, the one related to
T and this then has to be in the same namespace of T (the topic).

If we for example have
struct GPS

We want to get sequence<GPS> GPSSeq in the global namespace.

Not ::CCM_DDS::GPS_reader::GPSSeq, ::CCM_DDS::GPS_getter::GPSSeq, etc.

I think we should remove the typedef of the interfaces and add it as a
template argument, so that for example we get a reader below.

interface Reader <typename T, typename TSeq>

This would mean that the user of the interface/port has to instantiate it
with the basic type and the sequence type, but that seems the only way to
get only one sequence definition used between all the ports, corba, and dds
itself. The seqeunce just also has to be in the same namespace as the
original type T, we just can't do that with a typedef in an interface that
uses the sequence.

The whole template support has been revisited. According to that new support all
parametrized constructs are now grouped in a module. The CCM_DDS::Typed
module is parameterized with T and Tseq – sequence <T>).
Making the second parameter of type sequence<T> allows to check at compile
time that the type of the second parameter is actually sequence of the first one.

With the Reader/Getter/Writer we always handle one instance. When we can't
find that instance, should NonExisting::indexes then just be a sequence that
is empty, or with one index in it, 0?

Clarify that in this case, the sequence should contain the only index 0

When I look at the reader I get the impression this interface is designed
with keyed data types in mind. How would for example read_one work when
there is no key defined? What is the value that then should be passed in as
instance?

Disposition: See issue 14176 for disposition

What is the behavior of the methods on the Reader interface when there is no
data? Should the methods throw an exception or return a Boolean (but all
read methods are void)

clarify text

I got this questions from one of our users. I think it would be a good thing
to standardize the IDL filenames where the dds ports are defined in to get
interoperability in the user code. What are the ideas of others on this?

Johnny

> Are the headers to include in idl to get dds4ccm capabilities
> standardized? My guess is no. I need to include more than
> components.idl to get definitions. Do we need to raise this with omg?

Give the name “ccm_dds.idl” to the idl file.

I noticed that all methods on the Reader<typename T> interface have only out
arguments. Some return all samples for all instances, with just out, the
caller can't preallocate a buffer that can be used, the memory has to be
allocated each time again and released when not used. This doesn't really
use the power of DDS to my idea, any ideas on this?

No Data Available

In the spec there is a typo, between instead of betwen

Page 48, line 45. Page 49, line 41

Also page 49, line 18, or instead of od

correct typo

There is a typo in the batch 2 document, page 48, line 21: erroneaous

correct typo

A small question related to QueryFilter. From which namespace is StringSeq
coming? Is this from the DDS namespace or from the CORBA namespace?

Johnny

struct QueryFilter

;

withdrawn by submitter

The Reader::read_all_history is documented as:
read_all_history returns all samples of all instances

This could return a lot of data, the reader has no idea how much he will
get. Does this make sense? There is no way the Reader can limit the history
to a certain size as we could do with DDS directly.

Disposition: See issue 14214 for disposition

A question, several of the methods on MultiUpdater/MultWriter return an
unsigned long for nb of instances update/written/etc. At the moment the
method succeeds all instances are updated, the caller has passed in the
sequence, so he knows which elements got updated. If it failed, we get an
exception with the index failed (so no return value). It looks that the
return value doesn't add a thing, why not make it void?

withdrawn by submitter

8.3.1 has a typo on line 27 (page 37), attributre

withdrawn by submitter

Suppose we have this:

========
foo.idl:
module Foo
{
interface Foo_Intf < typename T >
{
};
};

=========
bar.idl:
#include "foo.idl"
module Bar
{
porttype Bar_Port <typename T>

;
};

=========
baz.idl:
#include "bar.idl"
module Baz
{
struct Baz_Struct
{
};
};

=========
foobarbaz.idl:
#include "baz.idl"
module FooBarBaz
{
connector FooBarBaz_Connector

;
};

=========

In which module(s) are the implicit interfaces for Bar_Port and
Foo_Intf (with respect to their parameterization with Baz_Struct)
assumed to be declared?

To give names to the instantiated interfaces, the initial version of the specification
was proposing a naming convention which was far from covering all the cases as
shown by this issue. In addition, this strategy was not in line with the one
selected by IDL to get rid of anonymous types resulting from instantiation of
existing templates (such as sequences). IDL now requires an explicit instantiation
with a name allocated by the developer.
It has thus been decided to remove that naming convention and to rely on
explicit instantiations.
Ina addition, a typical use case for parametrized extended ports and connectors
is as follows: a parametrized interface is used in a similarly parametrized port
type, which itself is used in a similarly parametrized connector. Eventually, when
instantiated, it is mandatory that the concrete interface in support of the extended
port attached to a component be exactly the same type as the one if support to
the corresponding mirror port of the connector (otherwise connections will not be
feasible), when in fact two explicit interface instantiations would result in two
different types (even if identical). Therefore it is mandatory that the interface, the
port type and the connector be in the same template scope, to allow a unique
interface instantiation be shared by the instantiated port type and connector.
This lead to proposing template support for the only grouping structure of IDL,
namely the module. Adding template modules is on the one hand less intrusive in
the existing IDL grammar and on the other hand far more versatile than the initial
proposed support. As it is needed to support almost all the possible extended
ports and connectors and enough for that purpose, it was decided to limit the
template support to template modules.
Consequently it was needed to recast almost entirely chapter 7, in order to
present in one place the template support (while in the initial chapter
organization, it was spread over the descriptions of each of the interaction
constructs – port types, ports, connectors). The resulting outline is as follows:
7 Generic Interaction Support
7.1 Simple Generic Interaction Support
7.2 Generic Interaction Support with Templates
7.3 IDL3+ Grammar
7.4 Programming Model for Connectors
7.5 Connector Deployment and Configuration taking the opportunity of this recast, the whole grammar description has been
rewritten in order to make it closer to the initial IDL grammar.

Why do the MultWriter/MultiUpdater methods have a return value of unsigned
long and not void? When the method succeeds all elements are written, if it
fails, the return value itself is worthless because we get an exception.
When it has succeeded the number of instances written is the same as the
number of instances passed, or not?

Disposition: See issue 14214 for disposition

Also for MultiUpdater the return value of unsigned long doesn't make sense, if the methods work, the number of elements written is all, if it fails, the exception will tell you the number failed

Disposition: See issue 14182 for disposition

For MultiWriter we have: unsigned long write(in T$Seq instances) // returns nb of written raises (InternalError); But, when write fails we get an exception. So, when it success all data has been written and then the return value is not needed. I would recommend to make this method void. In case it succeeds all instances are written, if it fails, the exception will tell you the number failed, so it the number written is one less then the number failed

Disposition: See issue 14182 for disposition

For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp

change the attribute

On line 17 and 21 the exception NonExistent is mentioned but this chapter doesn't describe under which conditions this exception has to be thrown. What should the read_one and read_one_history do when there are no samples? Throw an exception? what is an_istance then with read_one?

As part of the DDS-DCPS ports reorganization, improve the description of the
Reader operations has been improved

Line 14, change inees to fields

correct typo

For line 44 and 20 I would recommend to have update/create/delete as bold font, this refers to method names. Maybe split it in 2 sentences. For example: If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing and update and delete that the instances are existing; AlreadyCreated and NonExistent exceptions may be raised. Change If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing. Update and delete check that the instances are existing. AlreadyCreated and NonExistent exceptions may be raised. On page 31/39 line3, it says: The write or dispose orders are stopped. Write/dispose is DDS terminology, use: The update and delete calls are stopped ... On pase 31/39 line 3, say what happens with the create call? Does it stop on the first error?

clarify the text

On line 34 and 36 the spec mentions that the parameter an_instance has to be filled with the key value, but what if the topic doesn't have a key? I think the spec should mention this, if no key is specified the an_instance is supposed to be empty?

clarify the text

One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown. On line 8 a void query is mentioned, but what is a void query? A string of size 0?

Clarify that the test of validity for query and query parameters is to be done by
DDS.

On line 11 it says: The root tag of the configuration file must be <dds_ccm> and end with </dds_ccm>. We propose to change the tags to <dds> and </dds>. The XML QoS is coming from this spec but shouldn't be tied to it, it can be used without ccm at all.

appply change

Lines 32-36 imply that value declarations and type declarations may be parameterized the same as interface declarations. By extension, lines 14 & 15 imply that value declarations and type declaration may also be used to implement 'provides' and 'uses' ports.

Disposition: See issue 14201 for disposition

On line 24, the term '<connector_export>' should be '<connector_export>+'.

Disposition: See issue 14201 for disposition

The non-terminal 'extended_port_decl' appears as both a component export and a connector export. In particular, the 'generic_template_spec' non-terminal is problematic here. Since a component cannot be parameterized, as a component export, it must be the scoped name of a previously defined IDL type. As a connector export, however, it would appear to be legal IDL in this form, but also as a simple identifier matching one of the connector's template parameters. Are both constructs legal as connector exports? If so, they can't both be covered by 'generic_template_spec'.

Disposition: See issue 14201 for disposition

What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague

Disposition: See issue 14201 for disposition

The ListenerControl defines the attribute enabled. When checking the DDS spec I see that DDS only has the feature to enable an entity, not disable it. Shouldn't this attribute not be defined as: void enable (); as in the dds spec 7.1.2.1.1.7 enable Also DDS says an entity is enabled by default, the DDS4CCM says false in 8.2.2.1.3 What is the background of this, shouldn't DDS4CCM say it is enabled by default?

Disposition: See issue 14117 for disposition

The DDS4CCM spec defines the interface ListenerControl. This is used for the various ports of 8.2.2.2. Some ports (like DDS_RawListen) do specify multiple listen ports, listener and status. There is now just one flag to enable/disable them both. maybe I am just interested in the status and not listener. We propose to move the attribute enabled to each listen interface and remove the ListenerControl interface from the spec. Then each listener can be enabled/disabled independently of each other

The data listening extended ports are defined based on the fact that very often
(not to say all times) an application component which wants to be notified of
modifications of data (listener mode) needs to start by an initialization phase
where he gets all the existing data (and not receive thousands of notifications to
get the data that were existing before its creation). It is why they combine a Data
Listener basic port with a Reader one. Before that init phase is completed, the
component cannot treat well incoming notifications. This is why that
DataListenerControl port is also provided to turn on/off the data 'tap'.
In return, Status Listeners are slightly different in nature: they are there to allow
the component receive errors. The component has no choice with that and
should be in position to get errors even during the init phase! It is the reason why
those are always enabled (enabled at creation and no means / needs to enable
them explicitly).
The recasting of DDS listen ports has added the necessity for two enabled
modes (ONE_BY_ONE and MANY_BY_MANY). In addition, the StateListener is
given a specific control interface allowing in addition to control how filtering in and
out is reflected in the notifications.

The CCM4DDS spec defines SampleInfo in its own IDL. It describes that this is a simplified version of DDS::SampleInfo. This new struct has the following disadvantages to our idea: - the struct that gets received from DDS itself has to be converted to the CCM4DDS struct taking performance - not all DDS information is available anymore for the component We propose to use DDS::SampleInfo throughout the spec instead of introducing a simplified shadow struct

No Data Available

We propose to read the AMI chapter that was part of the alpha spec. It seems useful for ccm to also standardize the ami ports. the chapter will need some more work and fine tuning

No Data Available

On page 11, line 10, the body of a template interface is given as identical to that of a non-template interface. However, if the concatenation symbol $ can be used in a template interface member, how can this be? The $ symbol can't be part of a legal identifier, so it will have to be a token in its own right. This changes the grammar at some level, whether it be in the definition of an individual export, such as an operation, or in the definition of an identifier itself.

Disposition: See issue 14201 for disposition

the spec should be more clear for which constructs the $ can be used. The rules for the regular IDL should be extended. Is this possible for attributes, exceptions, etc?

Disposition: See issue 13884 for disposition

On page 7, lines 24-26, there are examples of $ usage.
These all apply to the parameter value following the
type classifier 'typename'. Will it also be legal to
use it with parameter values following other type
classifiers?

Disposition: See issue 13884 for disposition

Is it illegal to use a template interface to define an 'interface type' which may then be specialized for simple CORBA object requests? My guess would be that a template interface is intended for use only in an extended port, but it would be helpful to state it explicitly in the document.

Disposition: See issue 14201 for disposition

Nothing in the new IDL3+ production rules suggests that a template interface can be forward declared. This restriction makes sense if a template interface may be used only in an extended port definition (submitted as a separate issue), but it would be helpful to state the restriction explicitly in the document.

Disposition: See issue 14201 for disposition

table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1

correct the typo

The spec adds typename, primitive, port, mirrorport, porttype, and connector as keywords meaning that they can't be used anymore in other IDL. Below a list of files for TAO that have port, all from CORBA specs and for the keyword port. * orbsvcs/orbsvcs/SSLIOP.idl: * orbsvcs/orbsvcs/HTIOP.idl: * orbsvcs/orbsvcs/CSIIOP.idl: * tao/EndpointPolicy/IIOPEndpointValue.pidl: * tao/Strategies/sciop_endpoints.pidl: * tao/IIOP_Endpoints.pidl: * tao/IIOP.pidl: Because of this we need to use the _ prefix mechanism as specified in CORBA 7.2.3.1. To our idea the DDS4CCM spec should clearly specify all new keywords together and refer to the section in the corba spec. At the end also the CORBA spec has to be updated to list the new keywords

Gather all the new keywords in a table

The spec uses $ as string replacement for IDL3+. We find this not real and doubt whether a new string substitution should be added to the world. We would propose to use a different form, based on 'variable substitution' as found in unix shells, perl, ruby Two other options where we prefer the first one - use $

or %var%; this is much clearer and matches already supported substitution options The new way would be: interface EventsPusher <typename T> { typedef sequence<T> #

Seq events); void push_#

(in T event); }; The other option is to use the C preprocessor way X##Y -> XY It then becomes interface EventsPusher <typename T>

;

Disposition: See issue 13884 for disposition

On page 11, line10, it appears that the (optional) inheritance spec comes after the interface body. This is probably not intended.

Disposition: See issue 14201 for disposition

The spec doesn't say anything about forward declared IDL3+ interfaces. If it is not allowed, it should be mentioned. If it is allowed, the spec should mention it and describe it like section 7.8.4 of the regular CORBA spec for regular interfaces

Disposition: See issue 14201 for disposition

Font of line 20 not ok

correct the typo

Shouldnh't InternalError use DDS::ReturnCode_t

apply change

Line 16 doesn't read, line 33 should also be clear, "is likely" should be specified more strict

clarify the text

Last parameter of ConnectorStatusListener:: on_unexpected_status ( in DDS::Entity the_entity, in DDS::StatusKind); should be given a parameter name

correct the error

Line 13 says DCPOS, shouldn't this be DCPS?

correct the typo

line 39 should be indented

correct the typo

Line 4 should start with a capital

Disposition: See issue 13896 for disposition

On line 5 DURATION_INFINITE_NSEC should be used

correct the typo

For Table 12, Boolean, font of BOOLEAN_TRUE is not ok

correct the typo

why not use an exception instead of a return value for the methods in Getter<>? On line 28, it should say "return as result" when decided to keep bool. For the time_out, what about making this an argument of all methods, is setting this at this level at the correct level?

Proposed solution
1. keep the boolean as result and correct the text line 28
2. let the time_out as an attribute as purpose is to simplify as much as
possible the API . Reducing the number of parameters goes in that
direction. We noticed in our systems that time-out value was unlikely to
change from one call to another, making it a recurring value is therefore
sensible;

On line 1, the annex numbers are lacking

Insert correctly the cross-references to the annexes.

On line 19, after DDS_Base it should be a {

correct the typo

The font of line 11,12,13 should show the name of the methods in bold On line 29, On_data should start with lower capital

correct the typos

this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7

clarify the test

Line 3-4 doesn't read

clarify the text

Line 2, remove - from ConnectorPackage-Description Fix type in footer 3, ComponentUsageDescription and ComponentPackage Description (typo in first, space in second)

correct the typos

Line 38-39 starting with "note that events" doesn't read

clarify the text

The spec uses DDS_Listen<> on page 38 and 54, but DDS_Listen is never defined in this spec

The correct name is DDS_RawListen

this struct uses a StringSeq but the namespace is lacking, should it be CORBA::StringSeq? struct QueryFilter

;

Disposition: See issue 13890 for disposition

Line 16 ends with two semi colons instead of 1

correct the typo

Layout of figure 2 and 3 can be improved, not all lines hit the connector, text is not all readable

Change the figures

It should be ExtendedPort and MirrorPort, not InversePort

correct the typo

For 3, check UML CCM reference, it says 5formal, is that ok?

correct the typo

The usage of ULongSeq should be CORBA::ULongSeq to show that these types are coming from the CORBA namespace

Disposition: See issue 13888 for disposition

Figure 1 should say IDL3+ instead of Extended IDL3

Replace Extended IDL3 by IDL3+

Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?

Disposition: See issues 13949 + 13973 for disposition

line 4, replace the with The (T upper case)

correct the typo

Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?

Disposition: See issue 13894 for disposition

line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS

Discard DDS_ in front of all QoS values

line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq

Correct the typo (the second part of the issue is already in issue 13890)

line 52, change DDS_StateLsisten to DDS_StateListen

correct the typo

line 29, change On_data to on_data (lower case)

correct the typo

Change on line 5 StringSeq to CORBA::StringSeq

As CCM is meant to abstract from CORBA, it is not a good thing to create here a
dependency to CORBA In addition, those StringSeq will be passed to DDS,
DDS::StringSeq is therefore a much better choice.
This concerns the query parameters as well as the topic key fields

wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)? typedef unsigned long bytes; Also change the comment to // returns number of bytes written interface MultiWriter<typename T>

;

The idea is good but the proposed name (bytes) is misleading as what is
returned is a count of data samples. In addition, it in inconsistent to let unsigned
long as index in lists of data. It is thus proposed to name that typedef
DataNumber_t, to create also DataNumberSeq and to use them each time the
unsigned long or sequence of Ulong were used.

Line 18, has 7.2.3.4.1 Set_configuration_values Should be as below (lower case) 7.2.3.4.1 set_configuration_values

correct the typo

Shouldn't table 10 take parameterized connectors into account?

Disposition: See issue 14201 for disposition

Page 15 lists: // Parameterized interface interface EventsPusher <typename T>

; The replacement, is that T$ or $T, seems the push operation should be push_T$

The new template support in response to issue 14201 removes the need for that
controversial concatenation operator.

change nb to number in the comment on line 29/32/35

Disposition: See issue 13888 for disposition