Issues for Mailing list of the DDS for (Light Weight) CORBA Component Model 1.0 Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 13884: push operation should be push_T$
Issue 13885: Shouldn't table 10 take parameterized connectors into account?
Issue 13886: Should be as below (lower case) 7.2.3.4.1 set_configuration_values
Issue 13888: wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)?
Issue 13889: change nb to number in the comment on line 29/32/35
Issue 13890: Change on line 5 StringSeq to CORBA::StringSeq
Issue 13891: line 29, change On_data to on_data (lower case)
Issue 13892: line 52, change DDS_StateLsisten to DDS_StateListen
Issue 13893: line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq
Issue 13894: line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS
Issue 13895: Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?
Issue 13896: line 4, replace the with The (T upper case)
Issue 13897: Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?
Issue 13946: Figure 1 should say IDL3+ instead of Extended IDL3
Issue 13949: The usage of ULongSeq should be CORBA::ULongSeq
Issue 13952: this struct uses a StringSeq but the namespace is lacking
Issue 13953: DDS_Listen is never defined in this spec
Issue 13954: For 3, check UML CCM reference, it says 5formal, is that ok?
Issue 13955: Section: 6.1.2: It should be ExtendedPort and MirrorPort, not InversePort
Issue 13956: Section 7.1.2: Layout of figure 2 and 3 can be improved
Issue 13957: Section 7.2.1.2: Line 16 ends with two semi colons instead of 1
Issue 13958: Section 7.2.3: Line 38-39 starting with "note that events" doesn't read
Issue 13959: Section: 7.2.4.2.1
Issue 13960: Section 7.2.4.4: Line 3-4 doesn't read
Issue 13961: Section 7.2.4.5: this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7
Issue 13962: Section 8.2.2.1.1: what about making is_lifecycle_checked a regular attribute, so not read only?
Issue 13963: why not use an exception instead of a return value for the methods in Getter<>?
Issue 13964: Section: 8.2.2.1.2 font
Issue 13965: Section 8.3.1: On line 19, after DDS_Base it should be a {
Issue 13966: Section 8.4.2: On line 1, the annex numbers are lacking
Issue 13967: Section 8.4.2: For Table 12, Boolean, font of BOOLEAN_TRUE is not ok
Issue 13968: Section 8.2.2.2.5: On line 5 DURATION_INFINITE_NSEC should be used
Issue 13969: Section 9: Line 4 should start with a capital
Issue 13970: Section 9.2.1.1: line 39 should be indented
Issue 13971: Section 9.2.2: Line 13 says DCPOS, shouldn't this be DCPS?
Issue 13972: Section 9.2.2: Line 16 doesn't read, line 33 should also be clear
Issue 13973: Shouldnh't InternalError use DDS::ReturnCode_t
Issue 13974: Annex D: Font of line 20 not ok
Issue 14017: Section: 8.2.2.1.4 and annex A missing parameter name
Issue 14020: The spec uses $ as string replacement for IDL3+
Issue 14024: keywords that can't be used in other IDL anymore
Issue 14025: table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1
Issue 14028: The spec doesn't say anything about forward declared IDL3+ interfaces
Issue 14037: DDS4LwCCM - template interface IDL grammar
Issue 14038: DDS4LwCCM - template interface body
Issue 14039: DDS4LwCCM - forward declared template interface?
Issue 14040: DDS4LwCCM - standalone template interfaces?
Issue 14046: DDS4LwCCM - concatentation symbol usage
Issue 14057: the spec should be more clear for which constructs the $ can be used
Issue 14060: Section 8.4.4 talks about threading, but this section is really under specified
Issue 14080: propose to read the AMI chapter that was part of the alpha spec
Issue 14110: SampleInfo
Issue 14117: ListenerControl
Issue 14118: Section 8.2.2.1.3: ListenerControl attribute
Issue 14119: What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague
Issue 14120: The non-terminal 'extended_port_decl' appears as both a component export and a connector export.
Issue 14121: On line 24, the term '<connector_export>' should be '<connector_export>+'.
Issue 14122: Lines 32-36 imply that value declarations and type declarations may be parameterized
Issue 14168: We propose to change the tags to <dds> and </dds>
Issue 14174: One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown.
Issue 14175: if no key is specified the an_instance is supposed to be empty?
Issue 14176: line 17 and 21 the exception NonExistent: under which conditions has this exception to be thrown?
Issue 14177: For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp
Issue 14178: For line 44 and 20 I would recommend to have update/create/delete as bold font
Issue 14179: Line 14, change inees to fields
Issue 14180: MultiWriter
Issue 14181: or MultiUpdater the return value of unsigned long doesn't make sense
Issue 14182: Return type of the MultiWriter/MultiUpdater?
Issue 14201: Destination module for implied template interfaces
Issue 14202: Reader::read_all_history
Issue 14203: QueryFilter
Issue 14204: Typo, 8.3.1
Issue 14205: Return value of operations on MultiUpdater/MultiWriter/
Issue 14206: Typo, erroneaous
Issue 14207: Typo, betwen
Issue 14208: Reader interface
Issue 14209: Dds4ccm and includes
Issue 14210: Reader port question
Issue 14211: non-keyed datatypes
Issue 14212: NonExisting::indexes with Reader/Getter/Writer
Issue 14213: Sequence typedef leads to multiple sequences
Issue 14214: Do we need the Multi* interfaces/ports?
Issue 14217: QoS profile attribute name?
Issue 14534: MultiListener
Issue 14558: Extended ports
Issue 14562: (Multi)Updater method names?
Issue 14567: Updater and instance handle
Issue 14574: topic_name attribute
Issue 14578: on_subscription_matched missing
Issue 14581: readonly attribute DDS::StringSeq key_fields;?
Issue 14590: DDS port interfaces should be local
Issue 14611: DDS4CCM module name
Issue 14612: mirrorport in CCMComponentPortKind
Issue 14825: DDS_TopicBase::key_fields
Issue 14830: csl::on_inconsistent_topic
Issue 14836: IDL3+ keyword question/issue
Issue 14845: read_last
Issue 14846: Typo, 09-10-25, ExtendePortType
Issue 14847: getter text should be clearer about the behavior
Issue 15160: Type, DDS Listen instead of DDS_Listen
Issue 15172: Supporting Content Filtered Topics
Issue 15173: InstanceHandleManager, local?
Issue 15174: ConnectorStatusListener::on_unexpected_stat
Issue 15225: inout data parameters
Issue 15231: issue create/addressed?
Issue 15238: Let the user be able to instantiate one dds connector
Issue 15282: attributes as part of porttype do appear on port and mirrorport
Issue 15286: Layout issue test
Issue 15287: Make all arguments inout
Issue 15313: StateListenerControl:: is_filter_interpreted should be documented as optional
Issue 15888: section 8.3.1 Base Connectors
Issue 16603: Make topic_name changeable
Issue 17399: Name patterns should support underscores and scoping

Issue 13884: push operation should be push_T$ (dds4ccm-ftf)

Page 15 lists: // Parameterized interface interface EventsPusher <typename T> { typedef sequence<T> T$Seq; // construction of a type name void push (in T$Seq events); void push_$T (in T event); // construction of an operation name }; The replacement, is that T$ or $T, seems the push operation should be push_T$

Shouldn't table 10 take parameterized connectors into account?

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

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> { // T assumed to be a data type typedef sequence<T> T$Seq; nb_bytes write(in T$Seq instances) // returns nb of written raises (InternalError); attribute boolean is_coherent_write; };

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

Change on line 5 StringSeq to CORBA::StringSeq

line 29, change On_data to on_data (lower case)

line 52, change DDS_StateLsisten to DDS_StateListen

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

line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS

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

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

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

Figure 1 should say IDL3+ instead of Extended IDL3

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

this struct uses a StringSeq but the namespace is lacking, should it be CORBA::StringSeq? struct QueryFilter { string query; StringSeq query_parameters; }; 

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

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

It should be ExtendedPort and MirrorPort, not InversePort

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

Line 16 ends with two semi colons instead of 1

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

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

Line 3-4 doesn't read

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

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

As stated in the spec, checking the lifecycle is quite an heavy process as it may
imply to create a reader for that purpose. In addition, whether this behavior has
to be enforced is unlikely to change over the component's life. For those reasons,
the behavior has to be set at init time and in not changeable after that.
Disposition: Closed, no change

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?

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 

On line 19, after DDS_Base it should be a {

On line 1, the annex numbers are lacking 

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

On line 5 DURATION_INFINITE_NSEC should be used 

Line 4 should start with a capital 

line 39 should be indented 

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

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

Shouldnh't InternalError use DDS::ReturnCode_t 

Font of line 20 not ok 

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

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 ${var} or #{var} or %var%; this is much clearer and matches already supported substitution options The new way would be: interface EventsPusher <typename T> { typedef sequence<T> #{T}Seq; void push (in #{T}Seq events); void push_#{T} (in T event); }; The other option is to use the C preprocessor way X##Y -> XY It then becomes interface EventsPusher <typename T> { typedef sequence<T> T##Seq; void push (in T##Seq events); void push_##T (in T event); }; 

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 

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

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

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

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.

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.

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.

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?

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?

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. 

No time to tackle it completely. In any case, will not change the already defined
interfaces.
Disposition: Deferred

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

As its title says, this specification is aiming at standardizing ports for DDS and
proposes a general framework to add ports (GIS – Generic Interaction Support),
then uses it for DDS. Standardizing AMI ports is out of RFP scope.
This example was provided in the submission only as a rationale for the GIS. It
was never intended to be normative.
Disposition: Closed, no change

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 

The spec intended to ease use of DDS. Many DDS users feedback show that
they can be easily lost with some SampleInfo information. SampleInfo is the pure
view on the internal state of the data. ReadInfo attempts to translate it a more
user-centric view. Note that translation SampleInfos in ReadInfos is not only
copying a few fields from the firsts to the seconds: it requires also combining
them.
Disposition: Closed, no change

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 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?

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

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'.

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

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.

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.

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? 

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?

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?

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

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? 

Line 14, change inees to fields

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

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

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?

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>
    {
        uses Foo_Intf<T> foo_port;
    };
};


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


=========
foobarbaz.idl:
#include "baz.idl"
module FooBarBaz
{
    connector FooBarBaz_Connector
    {
        mirrorport Bar_Port < Baz::Baz_Struct > foobarbaz_port;
    };
};


=========


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?

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. 

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 {
        string                  query;
        StringSeq               query_parameters
        };

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

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?

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

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

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?

Purpose is to get IDL simple interfaces.
In case performance is really a huge concern, the DDS basic port can be used
Disposition: Closed, no change

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?

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)

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?

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?

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 {
  long x;
  long y;
}


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> {
        void read_all (out TSeq instances, out ReadInfoSeq infos)
                raises (InternalError);
        void read_all_history (out TSeq instances, out ReadInfoSeq infos)
                raises (InternalError);
        void read_one (inout T an_instance, out ReadInfo info)
                raises (NonExistent,
                        InternalError);
        void read_one_history (in T an_instance, 
                               out TSeq instances, out ReadInfoSeq infos)
                raises (NonExistent,
                        InternalError);
        attribute QueryFilter filter
                setraises (BadParameter);
}


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.

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.

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?

The name is given in the DDS_Base connector description (qos_profile)
Disposition: Closed, no change

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).

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.

Currently it is not planned that an extended port be recursive. The reason is that
while we fail to see any use case where that feature would really add something
(apart being intellectually satisfactory), it brings an extra-complexity, not only at
the CIF level (name of the resulting ports) but also at D&C tooling level.
Therefore it is decided not to change that feature.
Disposition: Closed, no change

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++.

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> {          // T assumed to be a data type
        void create (in T an_instance)
                 raises (AlreadyCreated,
                           InternalError);
        void update (in T an_instance)
                 raises (NonExistent,
                           InternalError);
        void delete (in T an_instance)
                 raises (NonExistent,
                           InternalError);
        readonly attribute boolean is_lifecycle_checked;
        }; 

 

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

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

DDS states this feature as optional
In case it is really needed the provided port DDS entity allows accessing it
Disposition: Closed, no change

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;

There is currently no standard DDS way to indicate the key fields. Placing this
information at the connector level is useful for system documentation.
Disposition: Closed, no change

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.

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

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.

No time to tackle it completely
Disposition: Deferred

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.

Having the key fields expressed in the CDP is a nice feature at least for systemwide
documentation purpose.
If the DDS implementation does not provide any means to retrieve this
information, the tooling can fill the gap by propagating it.
Disposition: Closed, no change

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? 

DDS connectors not concerned with any topic make no sense but some
connectors are concerned with several topics (and in particular DLRL's ones if
we talk about standardized ones). If the root of all connectors were
DDS_TopicBase (as suggested), all the attached topics would not be treated
equally, which is quite strange.
• DDS_Base is the root for all connectors
• DDS_TopicBase:DDS_Base is the root for all mono-topic connectors
Disposition: Closed, no change

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.

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?

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

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.
 

page 40 line one has a type, DDS Listen should be DDS_Listen for the port name

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 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.

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?

Unfortunately, it is not possible to get simply the status fields for unknown
statuses... Fortunately, this should never happen (except if the DDS
implementation bugs)
Disposition: Closed, no change

Currently in the spec when several data are to be returned, the related parameter is an 'out' sequence. Even if this is semantically correct, it makes implementation of smart memory management impossible. 
Suggestion is then to turn those parameters into 'inout' ones.

The version of IDL3+ grammar extensions that I have shows 

<connector_body> ::= "{" <connector_export> "}"

Shouldn't that line be

<connector_body> ::= "{" <connector_export>* "}"

?

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

No time to tackle it completely. Other solutions to minimize code generation are
under investigation.
Disposition: Deferred

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

See page 35, line 35, 


 read_one_last returns the last sample of a given instanceThe targeted 

Missing dot after 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

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).

Right now (in section 8.3.1 Base Connectors)  the DDS_Base connector has an attribute named qos_profile and the only thing said about it is that it contains a File URL or XML string.

Excerpt from 8.3.1 Base Connectors:
connector DDS_Base {

uses ConnectorStatusListener error_listener;

attribute DDS:DomainId_t domain_id

setraises (NonChangeable);

attribute string qos_profile // File URL or XML string

setraises (NonChangeable);

};

 

However, section 8.4.2.3 QoS Profiles talks about qos_profiles that are actually specified within the xml file.

 

So the problems are:

 

1.       The same name “qos_profile” is used to mean both an attribute referring to a file URL or XML string as well as referring to a subsection within the XML file.

2.       There is no mechanism for the user to reference the qos_profile name that was defined within the xml file (the “subsection within the XML file “) which makes it useless.

 

A possible solution would be to:

 

1.       Change the meaning of the qos_profile attribute to be a reference to the qos_profile defined within the XML file.

2.       Add another optional attribute for specifying the path to the xml file.

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

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.