${taskforce.name} Avatar
  1. OMG Task Force

DDS for Lightweight CCM 1.0 CORBA Component Model joint RTF — All Issues

Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS4CCM11-18 Editorial corrections CCCMP 1.0 open
DDS4CCM11-17 Use of symbolic constant as string or sequence bound CCCMP 1.0 open
DDS4CCM11-16 Typos at figure 8.6 Constant example CCCMP 1.0 open
DDS4CCM11-15 Schema appears to be missing root element DDS4CCM 1.1 open
DDS4CCM11-14 Remove key_fields DDS4CCM 1.1 open
DDS4CCM11-7 DDS_TopicBase connector lacks type_name DDS4CCM 1.0 open
DDS4CCM11-1 Name patterns should support underscores and scoping DDS4CCM 1.0 open
DDS4CCM11-5 Make all arguments inout DDS4CCM 1.0 open
DDS4CCM11-4 Make topic_name changeable DDS4CCM 1.1 open
DDS4CCM11-9 Section 8.4.4 talks about threading, but this section is really under specified DDS4CCM 1.0b1 open
DDS4CCM11-8 Let the user be able to instantiate one dds connector DDS4CCM 1.0 open
DDS4CCM11-3 StateListenerControl:: is_filter_interpreted should be documented as optional DDS4CCM 1.0 open
DDS4CCM11-6 Layout issue test DDS4CCM 1.0 open
DDS4CCM11-2 attributes as part of porttype do appear on port and mirrorport DDS4CCM 1.0 open
DDS4CCM11-13 DDS4CCM RTF - proposed simple spec extension for common DDS use case DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed
DDS4CCM11-12 Move generic interaction support (GIS) to the CCM specification DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed
DDS4CCM11-11 proposed simple spec extension for common DDS use case DDS4CCM 1.1 open
DDS4CCM11-10 The model file ptc/11-02-11 is not valid UML – it has eclipse namespace and extraneous elements DDS4CCM 1.0 open

Issues Descriptions

Editorial corrections

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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

  • Reported: CCCMP 1.0 — Tue, 14 Apr 2020 08:30 GMT
  • Updated: Tue, 14 Apr 2020 18:53 GMT

Use of symbolic constant as string or sequence bound

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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.

  • Reported: CCCMP 1.0 — Tue, 7 Apr 2020 19:33 GMT
  • Updated: Thu, 9 Apr 2020 18:45 GMT

Typos at figure 8.6 Constant example

  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    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;
    
  • Reported: CCCMP 1.0 — Wed, 8 Apr 2020 15:18 GMT
  • Updated: Thu, 9 Apr 2020 18:44 GMT

Schema appears to be missing root element

  • Status: open  
  • Source: JHU/APL ( Michael Leatherman)
  • Summary:

    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.

  • Reported: DDS4CCM 1.1 — Fri, 8 Dec 2017 07:09 GMT
  • Updated: Thu, 4 Jan 2018 16:40 GMT

Remove key_fields

  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: DDS4CCM 1.1 — Mon, 7 Nov 2016 12:19 GMT
  • Updated: Fri, 18 Nov 2016 20:33 GMT

DDS_TopicBase connector lacks type_name

  • Legacy Issue Number: 18499
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS4CCM 1.0 — Sun, 24 Feb 2013 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Name patterns should support underscores and scoping

  • Legacy Issue Number: 17399
  • Status: open  
  • Source: Northrop Grumman ( Trent Nadeau)
  • Summary:

    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.

  • Reported: DDS4CCM 1.0 — Wed, 30 May 2012 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make all arguments inout

  • Legacy Issue Number: 15287
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS4CCM 1.0 — Thu, 10 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make topic_name changeable

  • Legacy Issue Number: 16603
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS4CCM 1.1 — Fri, 14 Oct 2011 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Section 8.4.4 talks about threading, but this section is really under specified

  • Legacy Issue Number: 14060
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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.

  • Reported: DDS4CCM 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Let the user be able to instantiate one dds connector

  • Legacy Issue Number: 15238
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS4CCM 1.0 — Mon, 3 May 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

StateListenerControl:: is_filter_interpreted should be documented as optional

  • Legacy Issue Number: 15313
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

  • Reported: DDS4CCM 1.0 — Tue, 29 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Layout issue test

  • Legacy Issue Number: 15286
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    See page 35, line 35,

    read_one_last returns the last sample of a given instanceThe targeted

    Missing dot after instance

  • Reported: DDS4CCM 1.0 — Thu, 10 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

attributes as part of porttype do appear on port and mirrorport

  • Legacy Issue Number: 15282
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    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

  • Reported: DDS4CCM 1.0 — Tue, 8 Jun 2010 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

DDS4CCM RTF - proposed simple spec extension for common DDS use case

  • Legacy Issue Number: 18874
  • Status: closed  
  • Source: Northrop Grumman ( Mark Hayman)
  • Summary:

    We have what for our DDS4CCM applications is a common use case that is not currently covered by the DDS4CCM v1.1 spec, and the CIAO implementation of it that we use. We would like to propose a minor extension to the DDS4CCM specification to support this use case in accordance with spec paragraph 7.1.1, where it says “the most common DDS use patterns have been then identified as connectors…”

    Specifically, I’m speaking of being able to define a distributed state table via a keyed DDS topic with 1) the ability for a subscriber to receive an event notification/callback for published sample updates to the topic in a DRTE event-driven component framework, combined with 2) a subscriber ability to read the state table information for the topic non-destructively from the reader cache during post-initialization operation.

    Referencing old emails from the OMG dds4ccm mail list during the 2009-2010 timeframe, there were numerous discussions regarding the use of DDS read vs. take on reactive “push” vs. on-demand/polled “pull” extended port types and supporting interfaces. The result from that time was that the DDS_Listen and DDS_StateListen reactive extended port types that provide callback notification of newly received samples would utilize a take. This was ostensibly to help prevent typical user QoS configuration errors where read buffers within connectors using default QoS might fill up and consume excessive system resources, cause errors, etc. In contrast, the on-demand DDS_Read and DDS_Get ports implicitly do a read, rather than a take.

    Note that the spec does not explicitly require the use of either read or take on any extended port or connector type. In fact it doesn’t say anything at all about underlying connector buffer management and associated semantics, aside from an implication that take should be used on reactive listen type ports due to their normal behavior of always delivering “fresh” data in callbacks, as well as the following note from section 7.2.2.1.2 page 14 of the spec that describes the “Interface Reader”:

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

    The assumption in this note that the Reader basic port interface on the DDS_Listen and DDS_StateListen reactive porttypes would only be useful for application layer initialization and subsequent duplication of the instanced state information flowing through the reader cache is what presumably led to their underlying assumed use of take. But again, this does not match our most common use case for the DDS_State connector in particular, where the reactive DDS_Listen and DDS_StateListen porttypes that offer the event notification callback also have the side-effect of destroying the reader cache with take vs. a read. This in turn renders their built-in Reader interfaces pretty useless for event-driven, run-time operation beyond the initialization phase of the component port’s lifecycle.

    The apparent original use case in mind for the existing reactive subscriber port types was an application component that would utilize the connector capabilities for distributing and receiving new/updated/deleted keyed instance samples, consume these incoming samples once received with a take, and then require the user to duplicate the state table information at the application layer in a map-like state structure or a database of some variety. Per the note, the Reader interface was only envisioned as useful for initialization of application layer state tables, prior to turning on either the ONE_BY_ONE or MANY_BY_MANY listener mode callbacks.

    We have a number of applications where we would like to receive event notifications for simple distributed state data on topics, with no required application layer state duplication, using a KEEP_LAST history QoS setting with small read buffer depth. In these applications, we would like to allow the latest samples for these instances to remain in the reader cache for run-time Reader query access by users, rather than having to copy and maintain them at the application layer instead.

    We have exchanged a number of ideas with our CIAO support contractor Remedy IT on how we might best handle the use case of subscriber side event notification + distributed state query access. Our proposed extension to cover this common use case is captured in the three minor requested spec extensions below. This approach appears to have the least impact on existing implementations of DDS4CCM. Since this is a functionality extension vs. a change, it should not affect existing implementations that use the v1.1 interfaces and connector definitions, aside from the possible need for an additional empty callback stub in the language level component executor (which for us is auto-generated by the CIAO IDL compiler anyway).

    1) Add a fourth DATA_AVAILABLE enumeration option to the existing “ListenerMode” enum definition, as defined in section 7.2.2.1.2 in the “Interface DataListenerControl” sub-section at the top of page 16 (26 of 72):

    enum ListenerMode

    { NOT_ENABLED, ONE_BY_ONE, MANY_BY_MANY, DATA_AVAILABLE // new mode setting for event notification + distributed state query }

    ;

    2) Add a new third callback operation called “on_data_available()” to the existing “Listener” interface definition, as defined in section 7.2.2.1.2 in the “Interface Listener” sub-section at the bottom of page 14 (24 of 72):

    local interface Listener

    { void on_one_data (in T datum, in ReadInfo info); void on_many_data (in TSeq data, in ReadInfoSeq infos); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    3) Add a new fifth callback operation called “on_data_available()” to the existing “StateListener” interface definition, as defined in section 7.2.2.1.2 in the “Interface StateListener” sub-section in the middle of page 15 (25 of 72):

    local interface StateListener

    { void on_creation (in T datum, in ReadInfo info); void on_one_update (in T datum, in ReadInfo info); void on_many_updates (in TSeq data, in ReadInfoSeq infos); void on_deletion (in T datum, in ReadInfo info); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    Functionally, a user wishing to support the event notification + distributed state query use case with DDS4CCM would first enable the DATA_AVAILABLE listener mode (after initialization) on the “data_control” basic port of either the DDS_Listen or DDS_StateListen extended port types – instead of either the ONE_BY_ONE or MANY_BY_MANY mode as they do now.

    Once DATA_AVAILABLE mode is enabled, the new on_data_available() callback would be invoked by the connector, in lieu of the other callback operations on the Listener or StateListener interfaces, when a new sample arrives on the topic. In this new listen mode, neither a DDS read nor take operation would be performed by the connector prior to the callback invocation, which is simply an event notification to the application component with no data passed. Within the application component’s on_data_available() implementation, the user is then free to utilize the existing Reader interface on these two reactive extended port types to query the state information in the underlying DDS reader cache, which should remain intact and accessible during post-initialization system operation.

  • Reported: DDS4CCM 1.0 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Move generic interaction support (GIS) to the CCM specification

  • Legacy Issue Number: 15964
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The current DDS4CCM specification is made of two parts

    1) Description of a generic interaction support (GIS) allowing to define extended ports and connectors

    2) Use of this GIS to define extended ports and connectors dedicated to DDS.

    The first part (GIS) has been designed in purpose of supporting all future CCM extensions and would be better placed in the CCM specification.

    Proposal is therefore to move it from DDS4CCM to CCM.

    ––––-

    Severity I guess is minor as it does not affect at all the ability to implement. Actually it could have been treated as éditorial apat the point of revisiting compliance...

  • Reported: DDS4CCM 1.0 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    Move the GIS section as a sub-section in CORBA – Part 3 / Component Model
    Rationale for the move: The GIS is not at all specific to DDS-related extended ports and connectors and will be used for other CCM extensions.
    Rationale for keeping the addition in a single CCM sub-section: It is easier to understand the purpose of the extension and to set it as optional.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

proposed simple spec extension for common DDS use case

  • Legacy Issue Number: 18992
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    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.

  • Reported: DDS4CCM 1.1 — Wed, 9 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Legacy Issue Number: 16092
  • Status: open  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: DDS4CCM 1.0 — Mon, 21 Mar 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT