1. OMG Mailing List
  2. Issues not yet assigned to a Task Force

Unclassified Issues

  • Note: Issues in this list are assigned a temporary issue key (e.g. INBOX-1) which is changed when the issue is assigned to a Task Force. Nevertheless, this temporary issue key will redirect to the new issue key when assigned.
  • Issues Count: 194

Issues Summary

Key Issue Reported Status
INBOX-1988 relationship not defined KerML 1.0 Bet Alpha 2 pending
INBOX-1987 scope on Query SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1986 locking SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1985 Branches are mutable SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1984 wrong multiplicity on DataVersion SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1983 previousCommits must be in the same project as the Commit SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1982 Data needs to be reworked SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1981 need the commit for a project SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1980 Semantics of ProjectUsage needs to be defined SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1979 Need both an internal and external ProjectUsage SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1978 how is /versionData calculated SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1977 Head on Branch should be multiplicity 0..1 SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1976 multiplicity change between Project and DataVersion SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1975 navigation between DataVersion to DataIdentity SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1974 two branches can have the same head SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1973 multiplictiy change on Tag Commit SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1972 OCL Constraints SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1971 need attribute /usedProject SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1970 some attributes need to be {readOnly} SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1969 there needs to be a stament in the standard concerning how things are serialized SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1968 should have defaults consistent in the parameters SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1967 over specification of the API SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1966 specification and language need to be {ordered} SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1965 specification example SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1964 value being 1..* SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1963 Fig. 7 orderBy should be {ordered} SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1962 inconsistency with queries SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1961 JoinOperator and Operator are enumerations SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1960 visibility needs to be consistent SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1959 created needs to be consistent SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1958 ownership dots SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1957 all multiplicities explicity SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1956 many of the association ends are wrapped SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1955 All Attributes and AssociationEnds are singular SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1954 IRI needs defintion SystemsModelingAPI 1.0 Bet Alpha 2 pending
INBOX-1953 The UML Profile for the UAF Does Not Specify UAF Architecture Views or View Content - No Mechanism Within the XML UAF 1.2 pending
INBOX-1952 Incorrect Title '1.4 Layered Progression of Architecture Definition' - Should be 1.4 Layered Progression of Architecture Description' UAF 1.2 pending
INBOX-1951 Consistency/Lack of Standardisation - 'stakeholder viewpoint', vs MODAF::viewpoint vs ISO 42010 Architecture Viewpoint UAF 1.2 pending
INBOX-1950 The Master / Root Normative Specification to Which the EA Guide Conforms is the UAF DMM Not a UML Profile Implementation (UAFML) UAF 1.2 pending
INBOX-1949 A Repository Does Not Store Architecture - It Stores Architecture Description(s) - Differentiation of Duck vs Photo of Duck UAF 1.2 pending
INBOX-1948 Consistency - 'ISO420:Architecture Description' vs 'UAF:ArchitecturalDescription' UAF 1.2 pending
INBOX-1947 'Reference Architecture' Should be 'Reference Architecture Description' UAF 1.2 pending
INBOX-1946 Consistency - 'Cross Cutting Viewpoints' Are Not ISO42010:Architecture Viewpoints - They're MODAF::Viewpoints - Same Word, Different Meaning UAF 1.2 pending
INBOX-1945 Incorrect of the Term 'Modelling Language' As Synonym for a UML Profile UAF 1.2 pending
INBOX-1944 User Guide - The User Cannot Use the UAFML - they Use a Modelling Tool with Added Behaviours. Incorrect Claims for UAFML. UAFML benefits / features unclear UAF 1.2 pending
INBOX-1943 writing error DDSI-RTPS 2.5 pending
INBOX-1942 Incorrect Use of MODAF::Viewpoint in Grid UAF 1.2 pending
INBOX-1941 Incorrect Inclusion of UAF Architecture Viewpoints in an AD. Inconsistent and Incorrect Definition of 'Concern'. A StrategicPhase is Not a System UAF 1.2 pending
INBOX-1940 Inconsistent Definition of 'Architecture'. Unintelligable Note. Incorrect Reference. Step Name Should be 'Define Architecture Description Drivers and Challenges' UAF 1.2 pending
INBOX-1939 'Definition' Seems to be an Attribute of Any UAFElement - It Shouldn't Be a Separate Element (Inconsistent Representation of Attributes) UAF 1.2 pending
INBOX-1938 Figure 9:118 Caption ' ArchitectureMetadataDefinition' Includes the Following Metamodel Element Title ('Definition') UAF 1.2 pending
INBOX-1937 View Specification - Am-Pr Architecture Development Method Name Doesn't Match Subject. Missing (No) Triples to Address Concerns UAF 1.2 pending
INBOX-1936 Tables Refer to a View Specification Am-Tx Architecture Extensions that Doesn't Exist + Table Numbering Error Table 1:2 UAF 1.2 pending
INBOX-1935 UAF Grid and text refers to 'Architecture Extensions' View Specification - View Specification Doesn't Exist UAF 1.2 pending
INBOX-1934 View Specification Am-Tr Architecture Traceability - Only 1 Relationship Element Provided, Unable to Describe Traces to External Sources UAF 1.2 pending
INBOX-1933 acquire/release mastership - system requesting mastership is ambiguous OARIS 2.0 pending
INBOX-1932 Multiplicity of composition/aggregation end for many different elements with {subsets owner} should be 1 and not 0..1 UML 2.5.1 pending
INBOX-1931 ActualPerson is not a Distinct Type. Inconsistent Representation of Individual vs Type/Class wrt Other Metamodel Elements (ActualXXX Elements Contradict Class Mechanism)) UAF 1.2 pending
INBOX-1930 ServiceRole is Neither a Type of Nor Part of a Service UAF 1.2 pending
INBOX-1929 'Usage of + 'Whole:Part' - ProtocolLayer is Not a Distinct Metamodel Concept - It is a Reflexive Whole:Part Relationship on Protocol UAF 1.2 pending
INBOX-1928 8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Specification Doesn't Provide Any Sequencing Triples to Address Its Concerns UAF 1.2 pending
INBOX-1927 8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Spec Includes UML Metaclasses UAF 1.2 pending
INBOX-1926 Operational Structure Viewpoint Identifier Should Be 'Op-Sr' Not 'Op-St' (which duplicates Operational States Viewpoint Identifier) UAF 1.2 pending
INBOX-1925 8.1.1 View Specifications::Architecture Management::States::Architecture Status has Nothing to Do with 'Architecture' - It Describes the State of the Architecture Description UAF 1.2 pending
INBOX-899 The Normative References section refers to both versions 1.0 and 1.1 of XML Schema for no obvious reason Untriaged pending
INBOX-894 GIOP and IIOP versioning must be clearly and consistently specified Untriaged pending
INBOX-893 Licensing Service issue Untriaged pending
INBOX-892 omission from the OMG --Trader spec Untriaged pending
INBOX-891 Relationship connector and components/homes not clearly specified Untriaged pending
INBOX-890 Page: 56..64 Untriaged pending
INBOX-660 Typos in section 3.1.6.4.1 DDS 1.2 pending
INBOX-659 which_contained_modified operation should be removed DDS 1.2 pending
INBOX-658 Typos in section 3.1.6.6 DDS 1.2 pending
INBOX-657 Typos in section 3.1.6.4.3 & 3.1.6.4.4 DDS 1.2 pending
INBOX-656 Typos in section 3.2.1.2 IDL description DDS 1.2 pending
INBOX-655 section 3.2.1.2 IDL description on page 3-52 DDS 1.2 pending
INBOX-654 section 3.2.2.3.2.13 MultiRelation, 3rd bullet DDS 1.2 pending
INBOX-653 Typos in section 3.2.1.2 IDL description DDS 1.2 pending
INBOX-652 section 3.2.1.2.2 Implied IDL DDS 1.2 pending
INBOX-651 In section 3.2.2.3.2.11 MultiAttribute. DDS 1.2 pending
INBOX-650 In section 3.2.2.3.2.11 MultiAttribute, the example xml code DDS 1.2 pending
INBOX-649 section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation DDS 1.2 pending
INBOX-648 Figure 3-4 and section 3.2.1.2.2 Implied IDL DDS 1.2 pending
INBOX-647 In section 3.2.3.5 Code example, several typos DDS 1.2 pending
INBOX-646 Section 3.2.1.1 Mapping Rules regarding error reporting DDS 1.2 pending
INBOX-645 section 3.2.2.3.2.13 MultiRelation - XML code DDS 1.2 pending
INBOX-644 Inconsistency in attribute definitions for valuetype ObjectRoot DDS 1.2 pending
INBOX-643 Figure 3-4 on page 3-16 is missing some operations in some classes DDS 1.2 pending
INBOX-642 Give each CacheAccess its own Publisher and DataWriters DDS 1.2 pending
INBOX-641 use case for multiple valueFields DDS 1.2 pending
INBOX-640 A descriptive name DDS 1.2 pending
INBOX-639 Specify names of mono-relation and multi-relation fields for default mappin DDS 1.2 pending
INBOX-638 create_object and create_unregistered_object DDS 1.2 pending
INBOX-637 clarify behavior of content_filters in an inheritance hierarchy DDS 1.2 pending
INBOX-367 typo to be corrected: External Interface File (EIF)] AFP 1.0 pending
INBOX-327 Typo (missing article) NIEM-UML 3.0 FTF pending
INBOX-170 Introduce the clear() operation on the Collection interface. DDS 1.2 pending
INBOX-202 Add an attribute to get the home_index DDS 1.2 pending
INBOX-183 Describe exact behaviour of compositions and associations in the DLRL. DDS 1.2 pending
INBOX-162 objects instances in a writeable CacheAccess DDS 1.2 pending
INBOX-227 Selection should have a non-listener way of obtaining the members DDS 1.2 pending
INBOX-186 The classname in FullOid makes no sense in case of a 'local' Object model DDS 1.2 pending
INBOX-133 non-existing elements DDS 1.2 pending
INBOX-166 Cache DDS 1.2 pending
INBOX-155 (last) end_updates call on CacheListeners DDS 1.2 pending
INBOX-167 The generated class FooImpl is not mentioned in the implied idl DDS 1.2 pending
INBOX-188 The Implied IDL needs to be extended with attribute examples for class Foo DDS 1.2 pending
INBOX-205 Unregistered objects DDS 1.2 pending
INBOX-193 Typo in section 3.1.6.1.2.1 DDS 1.2 pending
INBOX-159 Typo in section 3.1.4.2.1 DDS 1.2 pending
INBOX-108 Need to clarify what is meant by "RELATED_OBJECTS" DDS 1.1 pending
INBOX-210 In section 3.1.6.3.5 regarding the CacheListener clarify some things DDS 1.2 pending
INBOX-230 Clarify exceptions for enable_updates and disable_updates operations of Cac DDS 1.2 pending
INBOX-207 Clarify text on page 3-35 directly following the operation descriptions. DDS 1.2 pending
INBOX-175 In section 3.1.6.3.11 regarding the FilterCriterion clarify some things DDS 1.2 pending
INBOX-138 Clarify usage of create_cache operation DDS 1.2 pending
INBOX-119 Proposed Enhancement: allow QoS directly on a DLRL object type? DDS 1.2 pending
INBOX-120 Request clarification of how to handle a dangling related object DDS 1.2 pending
INBOX-146 Clarify usage of cache_usage operation on the CacheBase, section 3.1.6.3.2 DDS 1.2 pending
INBOX-130 PIM Spec should have separate tables for Foo types, like DCPS section does DDS 1.2 pending
INBOX-129 Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception? DDS 1.2 pending
INBOX-126 Request clarification on interface of DLRL object with multi-attribute DDS 1.2 pending
INBOX-125 Request clarification: what can you do with a deleted object? DDS 1.2 pending
INBOX-213 Support local class in Mapping XML DDS 1.2 pending
INBOX-161 set_query and set_parameters operation DDS 1.2 pending
INBOX-220 Let the attach/detach listener operation return a boolean DDS 1.2 pending
INBOX-154 Add an operation to the Cache DDS 1.2 pending
INBOX-204 set_auto_deref, deref_all, underef_all operations DDS 1.2 pending
INBOX-157 Clarify typical scenario for read mode of a CacheAccess in section 3.1.6.5. DDS 1.2 pending
INBOX-132 Section 3.1.3.1 on page 3-3 DDS 1.2 pending
INBOX-203 Clarify usage of Fully qualified names in the model tags in section 3.2.2.3 DDS 1.2 pending
INBOX-218 Clarify exceptions/usage for remove operation on List in section 3.1.6.3.16 DDS 1.2 pending
INBOX-151 Add exceptions, clarify usage of other exceptions DDS 1.2 pending
INBOX-194 Change description on mapping rules for Exceptions or return values DDS 1.2 pending
INBOX-208 Various typos in section 3.1.6.3.7, ObjectHome DDS 1.2 pending
INBOX-147 In section 3.1.6.3.7 regarding the ObjectHome clarify some things DDS 1.2 pending
INBOX-221 Clarify various things with operation enable_all_for_pubsub DDS 1.2 pending
INBOX-163 Clarify exceptions with operation register_all_for_pubsub DDS 1.2 pending
INBOX-222 Description not detailed enough DDS 1.2 pending
INBOX-173 Clarify usage of the is_modified() operation on the ObjectRoot DDS 1.2 pending
INBOX-144 Clarify usage of the destroy() operation on the ObjectRoot DDS 1.2 pending
INBOX-226 getter/setter/is_modified operations DDS 1.2 pending
INBOX-178 Unclarities in table in section 3.1.6.2 the row regarding the CacheAccess DDS 1.2 pending
INBOX-118 Should "set" method called outside of writable CacheAccess throw exception? DDS 1.2 pending
INBOX-121 DLRL Issue: Mismatch between DLRL and CORBA on enumerations DDS 1.2 pending
INBOX-128 DLRL Issue: Error in the IDL for the SelectionListener DDS 1.2 pending
INBOX-215 Prevent writing contents of CacheAccess while 'invalid' relations exists DDS 1.2 pending
INBOX-214 getters of relationships DDS 1.2 pending
INBOX-169 Add attribute to CacheAccess (section 3.1.6.3.3) DDS 1.2 pending
INBOX-228 DCPSError also becomes a 'runtime' exception DDS 1.2 pending
INBOX-219 instance_state of a DCPS instance becomes NOT_ALIVE_NO_WRITERS DDS 1.2 pending
INBOX-145 Indicate the semantics of merging separate topics into one single object DDS 1.2 pending
INBOX-184 DLRL object DDS 1.2 pending
INBOX-153 How are deleted objects treated in a CacheBase and a Selection DDS 1.2 pending
INBOX-189 FilterCriterion DDS 1.2 pending
INBOX-201 Proposal to make the is_xxx_modified operation optional DDS 1.2 pending
INBOX-200 Clearly separate default mapping from pre-defined mapping DDS 1.2 pending
INBOX-197 The read_state of a cache object contains some typos DDS 1.2 pending
INBOX-225 Clarify listeners DDS 1.2 pending
INBOX-142 Clarify exceptions DDS 1.2 pending
INBOX-196 Section 3.2.1.2.1 Generic DLRL Entities get_instance DDS 1.2 pending
INBOX-150 Describe exact event propagation in case of inheritance + multiple listener DDS 1.2 pending
INBOX-136 Minor typo's and inconsistencies DDS 1.2 pending
INBOX-190 In section 3.1.6.3.6 regarding the Contract clarify some things DDS 1.2 pending
INBOX-198 Clarify usage of refresh operation on the CacheBase, section 3.1.6.3.2 DDS 1.2 pending
INBOX-117 DLRL Issue: Request clarification on the behavior of is_modified DDS 1.2 pending
INBOX-122 DLRL Issue: Int the future, allow DLRL valuetype implementations? DDS 1.2 pending
INBOX-212 Rewrite sentence on page 3-1, section 3.1 DDS 1.2 pending
INBOX-171 Clarify what happens in the purge operation of the CacheAccess DDS 1.2 pending
INBOX-187 Which exceptions can be raised under which circumstances? DDS 1.2 pending
INBOX-131 Section: 3.1.4.5 DDS 1.2 pending
INBOX-116 DLRL Issue: Error in the ownership of a SelectionCriterion DDS 1.2 pending
INBOX-199 Enable_all_for_pubsub operation DDS 1.2 pending
INBOX-191 Relationships to objects that have been deleted are not allowed. DDS 1.2 pending
INBOX-164 Remove the CacheDescription object DDS 1.2 pending
INBOX-156 There is a lot of redundancy in the XML file. DDS 1.2 pending
INBOX-143 Cache should have a getter to obtain its related DomainParticipant. DDS 1.2 pending
INBOX-224 Clarify exceptions for add/put operations on List in section 3.1.6.3.16 DDS 1.2 pending
INBOX-206 Unclear sentence in section 3.1.6.1.1 DDS 1.2 pending
INBOX-148 Usage of Undefined unclear DDS 1.2 pending
INBOX-177 Clarify what happens with selection->refresh if auto_refresh is true DDS 1.2 pending
INBOX-158 Clarify typical scenario for write mode of CacheAccess in section 3.1.6.5.2 DDS 1.2 pending
INBOX-180 samples from the underlying DataReaders DDS 1.2 pending
INBOX-211 Various typos in section 3.1.6.3.4, Cache DDS 1.2 pending
INBOX-185 cloned objects DDS 1.2 pending
INBOX-141 Extend the XML to allow optional relationships DDS 1.2 pending
INBOX-209 Unclarities in section 3.1.4.2.3 DDS 1.2 pending
INBOX-127 DLRL Issue: Need clarification on limitations of bi-directional association DDS 1.2 pending
INBOX-123 Request clarification on a WRITE_ONLY CacheAccess, cloning, and refresh() DDS 1.2 pending
INBOX-137 Clarify usage of find_home_by_name DDS 1.2 pending
INBOX-139 Clarify exception condition DDS 1.2 pending
INBOX-124 DLRL Issue: Diagrams in Fig 3.5 and Fig 3.6 look improperly captioned DDS 1.2 pending
INBOX-115 IDL interfaces for ObjectListener and FooListener are inconsistent DDS 1.2 pending
INBOX-109 clarify allowable (spec compliant) ways to implement ObjectReference[]. DDS 1.1 pending

Issues Descriptions

relationship not defined

  • Key: INBOX-1988
  • Status: pending  
  • Source: Private ( Anders Reggestad)
  • Summary:

    Figure 4. Elements defines the relationship attribute, as well as several subsets depend on the same relationship though the attribute isn't anywhere to be found exept for in the figure 4.

  • Reported: KerML 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 20:28 GMT
  • Updated: Fri, 19 Apr 2024 20:28 GMT
  • Attachments:

scope on Query




wrong multiplicity on DataVersion


previousCommits must be in the same project as the Commit


Data needs to be reworked

  • Key: INBOX-1982
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Data does not need to be further refined in the standard (i.e. no need for Relationship and operations like getRelationshipsByRelatedElements)... these could be there for operations that specifically deal with KerML models...
    I would suggest if doing that there should be two sections to this standard or possibly two standards... one that deals with
    versioning... the other that is specific to the serialized model

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 16:56 GMT
  • Updated: Fri, 19 Apr 2024 16:56 GMT
  • Attachments:

need the commit for a project

  • Key: INBOX-1981
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    "usage is the set of Project Usage records representing all other Projects being used by the given Project"… this does not work, need a particular commit for this

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 16:53 GMT
  • Updated: Fri, 19 Apr 2024 16:53 GMT
  • Attachments:

Semantics of ProjectUsage needs to be defined

  • Key: INBOX-1980
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    What does project usage mean?... I am presuming this comes from Cameo kind of idea about ProjectUsage... but what in this spec does it mean and what can one surmise about it

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 16:51 GMT
  • Updated: Fri, 19 Apr 2024 16:51 GMT
  • Attachments:

Need both an internal and external ProjectUsage


how is /versionData calculated


Head on Branch should be multiplicity 0..1



navigation between DataVersion to DataIdentity

  • Key: INBOX-1975
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    There should be a navigation between DataVersion to DataIdentity... presumably DataVersion knows about DataIdentity but not vice-versa

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 16:44 GMT
  • Updated: Fri, 19 Apr 2024 16:44 GMT
  • Attachments:

two branches can have the same head

  • Key: INBOX-1974
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Two Branches can have the same head (Commit) … need multiplicity change
    for example to start them off with the same set of elements

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 16:43 GMT
  • Updated: Fri, 19 Apr 2024 16:43 GMT
  • Attachments:





there needs to be a stament in the standard concerning how things are serialized

  • Key: INBOX-1969
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    there needs to be a statement in the standard concerning how things are serialized...

    I have reworked the model here https://material.elparazim.com/SysMLv2API/ and used two stereotypes...
    <<NS>> and <<SID>> which stand for "No Serialization" and "Serialize Id (only)"
    I believe this leads to a full understand of what will come when one serializing something from
    the APi (also examples are given for this serialization(s))

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:35 GMT
  • Updated: Fri, 19 Apr 2024 15:35 GMT
  • Attachments:

should have defaults consistent in the parameters

  • Key: INBOX-1968
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    the standard for functions should be, e.g.

    getExternalRelationships(projectId:UUID, branchId:UID[0..1],commitId:UID[0..1]):ExternalRelationship[0..*]

    which means if a branchId is missing use the commitId, if commitId is missing then use the head of the branchId if it is there,
    otherwise, use the default Branch and its head of the project given
    many of the API operations need to be specified this way to be consistent

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:29 GMT
  • Updated: Fri, 19 Apr 2024 15:29 GMT
  • Attachments:

over specification of the API

  • Key: INBOX-1967
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Most of the API is over specified… as an example, getExternalRelationship has that you need to give it a Project… but you do not need a Project, you only need a ProjectId… so for this one example…
    getExternalRelationships(project:Project,commit:Commit):ExternalRelationship[0..*] should be
    getExternalRelationships(projectId:UID,commitId:UID):ExternalRelationship[0..*]

    this would follow the Interface Segregation Principle (“no client should be forced to depend on methods it does not use”)… most of the API is over specified in this way

    I have a reworked model at https://material.elparazim.com/SysMLv2API/

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:23 GMT
  • Updated: Fri, 19 Apr 2024 15:23 GMT
  • Attachments:

specification and language need to be {ordered}

  • Key: INBOX-1966
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    specification and language need to be

    {ordered}

    ... this will have the same kind of semantics as
    Opaque/Expression or Behavior from UML (see fig 8.2 and its description in UML 2.5.1)

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:13 GMT
  • Updated: Fri, 19 Apr 2024 15:13 GMT
  • Attachments:

specification example

  • Key: INBOX-1965
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Need at least one example of a specification for an ExternalRelationship...

    also need to define what it means if the specification is null (i.e. presume this means that one is referring to the entire element, so this is the way one specifies that an element in a model is really a remote element from another model)... this needs to be specified

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:10 GMT
  • Updated: Fri, 19 Apr 2024 15:10 GMT
  • Attachments:

value being 1..*

  • Key: INBOX-1964
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    need to explain in the standard why value is 1..* (presuming because of the "in" operator, but the semantics of that is not specified)

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:07 GMT
  • Updated: Fri, 19 Apr 2024 15:07 GMT
  • Attachments:


inconsistency with queries

  • Key: INBOX-1962
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig. 7 queries (which should be a singular, query) is an associationend… whereas in fig. 5 queries is shown as an attribute (needs to be removed in fig. 5)

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:04 GMT
  • Updated: Fri, 19 Apr 2024 15:04 GMT
  • Attachments:

JoinOperator and Operator are enumerations


visibility needs to be consistent

  • Key: INBOX-1960
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    1. Fig 6 visibility is not shown on all the attributes, needs to be consistent
    2. Fig 7 visibility is not shown on all the attributes, needs to be consistent

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:01 GMT
  • Updated: Fri, 19 Apr 2024 15:01 GMT
  • Attachments:

created needs to be consistent

  • Key: INBOX-1959
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    Fig 5 Project, Commit, CommitReference all have created as a attribute, But many of the examples (and some of the text have timestamp).. needs to be consistent… I like “created” as it tells one what the timestamp is for

    and deleted as the other timestamp name

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 15:00 GMT
  • Updated: Fri, 19 Apr 2024 15:00 GMT
  • Attachments:

ownership dots


all multiplicities explicity

  • Key: INBOX-1957
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    there are some multiplicities not shown... since there is no specification in the standard about what modeling language the diagram is in... do not know how to interpret these missing multiplicities... would suggest explicitly showing all multiplicities in the diagram

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 14:57 GMT
  • Updated: Fri, 19 Apr 2024 14:57 GMT
  • Attachments:

many of the association ends are wrapped

  • Key: INBOX-1956
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    the models used in the standard have the association ends wrapped so you can't see them... suggest that they be unwrapped and
    shown on one line

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 14:55 GMT
  • Updated: Fri, 19 Apr 2024 14:55 GMT
  • Attachments:

All Attributes and AssociationEnds are singular

  • Key: INBOX-1955
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    all the standard modeling languages use the same convention as well as most modeling style guides... and so does KerML...

    all attributes and association ends are singular... the fact that they can be plural is taken care of by multiplicity

    would suggest this convention be followed

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 14:53 GMT
  • Updated: Fri, 19 Apr 2024 14:53 GMT
  • Attachments:

IRI needs defintion

  • Key: INBOX-1954
  • Status: pending  
  • Source: Elparazim ( Mr. George Edward Roberts)
  • Summary:

    IRI standard is referenced, but that does not give a precise definition of how to use it, especially if one wants to be interoperable among implementations... would suggest...

    Standard ProjectI IRI:

    {protocol}://{serverIRI}/projects/{projectId}/commits/{commitId}/elements/{elementId}{protocol}

    ://

    {serverIRI}

    /projects/

    {projectId}

    /commits/

    {commitId}

    the first is for Elements and the second is for externally referenced projects

  • Reported: SystemsModelingAPI 1.0 Bet Alpha 2 — Fri, 19 Apr 2024 14:51 GMT
  • Updated: Fri, 19 Apr 2024 14:51 GMT
  • Attachments:

The UML Profile for the UAF Does Not Specify UAF Architecture Views or View Content - No Mechanism Within the XML

  • Key: INBOX-1953
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    It states:
    'UAF provides a complete set of stakeholder viewpoints as the basis for defining the variety of necessary architecture views of an Enterprise and these views are specified in the UAFML.'

    1) 'stakeholder viewpoints' should be 'architecture viewpoints' in accordance with ISO/IEC/IEEE 42010
    2) a UML profile such as the UAFP does not specify architecture views nor view content. There is no standardised mechainsm within the UML to do so. The normative UML profile for the UAF - dtc/21-12-14 - contains no stereotypes to represent any UAF architecture view nor does it contain any definition of UAF architecture view content. [ The statement that 'these views are specified in the UAFML' is flat out untrue ]. Do the UAF authors not understand the architecture of the UML profile for the UAF?

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:37 GMT
  • Updated: Fri, 19 Apr 2024 07:37 GMT
  • Attachments:

Incorrect Title '1.4 Layered Progression of Architecture Definition' - Should be 1.4 Layered Progression of Architecture Description'

  • Key: INBOX-1952
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Incorrect section title - '1.4 Layered Progression of Architecture Definition'

    As it states: 'The viewpoints allow for a logical and systematic flow of architecting activities'. This has nothing to do with 'architecture definition' - it's the evolution of 'architecture description'

    The accurate title is therefore '1.4 Layered Progression of Architecture Description'.

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:27 GMT
  • Updated: Fri, 19 Apr 2024 07:27 GMT
  • Attachments:

Consistency/Lack of Standardisation - 'stakeholder viewpoint', vs MODAF::viewpoint vs ISO 42010 Architecture Viewpoint

  • Key: INBOX-1951
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The UAF is supposed to be a technical standard. The effectiveness of standardisation requires the use of the correct standard terms consistently. ISO/IEC/EEEE 42010 provides the correct terms needed for architecture description - both their names and the meanings - but the UAF mixes and matches terms, changes their names and intoroduces its own non-standard new ones. The use of 'viewpoint' is inconsistent and incorrect and there is nothing provided to the reader so that they can understand the different meanings of the same term. This wouldn't be a problem if the UAF used the term 'architecture viewpoint' (not 'viewpoint') as defined by ISO/IEC/IEEE 42010 for the meaning defined by the ISO.

    The abstract states:
    'The nine steps of the workflow are laid out in alignment with the stakeholder viewpoints in UAF for producing the requisite architecture views in each of those viewpoints'

    1) 'stakeholder viewpoints' should be 'architecture viewpoints' (viewpoints and views do not record something when "viewed from a particular direction"). The problem here, though is that these 'stakeholder viewpoints' are incorrectly termed 'view specifications' both in the UAF grid and the DMM package structure.

    2) 'architecture views in each of those viewpoints' - an architecture viewpoint is a specification for an architecture view not a containing mechanism - this use of 'viewpoint' is actually MODAF::viewpoint - a different thing and undefined

    3) wherever 'view' appears it should correctly be 'architecture view' in accordance with ISO/IEC/IEEE 42010 so that that the meaning is uambiguously tied to the ISO concept not the various casual uses of the term.

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 07:07 GMT
  • Updated: Fri, 19 Apr 2024 07:07 GMT
  • Attachments:

The Master / Root Normative Specification to Which the EA Guide Conforms is the UAF DMM Not a UML Profile Implementation (UAFML)

  • Key: INBOX-1950
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The abstract states:
    'This document describes a workflow for creating Enterprise Architecture (EA) views in accordance with the Unified Architecture Framework (UAF) Modeling Language (UAFML).'

    The traceability is incorrect. No process conforms to a UML profile - this makes no sense.

    A UML profile, the UAFML, is not the root / master / defining specification for the UAF - it is the agnostic UAF DMM specification. Unless you are stating that the EA guide is only applicable to one specific implementation and not any implementation of the UAF. If this is true the statement should be qualified to state that it only applies to the particular UML + SysML implementation provided by the UML profile (UAFML).

    Presumably since SysML has its own normative UML profile this profile should be renamed the SysML Modelling Language (SysMLML) ....

  • Reported: UAF 1.2 — Fri, 19 Apr 2024 06:52 GMT
  • Updated: Fri, 19 Apr 2024 06:52 GMT
  • Attachments:

A Repository Does Not Store Architecture - It Stores Architecture Description(s) - Differentiation of Duck vs Photo of Duck

  • Key: INBOX-1949
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 1:4 - Architecture Views and Models are Used in Other Architecture Processes shows a box labelled 'Architecture Repository'.

    This is incorrect. Using the ISO 42010 conceptual model the (real world) 'architecture' and 'architecture description' (an artefact) are separate concepts. You do not store the real world thing on a hard drive - you store its description.

    I would recommend checking and issuing the following as guidance to the UAF authors to avoid keep making this error - [1] ‘The Treachery of Images, 1929 by Rene Magritte’, Rene Magritte - Biography, Paintings, and Quotes. [Online]. Available: https://www.renemagritte.org/the-treachery-of-images.jsp

    It might seem trivial but it makes reading hard work particularly where you legilimately use an 'architecture description' to make comment on an 'architecture'. Because this error is so widesperead it's impossible for the reader to understand Figure 1.4 because anywhere 'architecture' appears it could really mean 'architecture description'

    If someone told you that they were storing a duck on a hard drive you'd question their sanity. If they instead correctly said they were storing a photo of a duck on a hard drive it'd be a perfectly understandable and reasonable thing to say. This persisant and endemic confusion of the two terms is that wrong.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:46 GMT
  • Updated: Thu, 18 Apr 2024 13:46 GMT
  • Attachments:

Consistency - 'ISO420:Architecture Description' vs 'UAF:ArchitecturalDescription'

  • Key: INBOX-1948
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    A.4.3 Architecture Description Organization and Relationships p 119. 120

    The problem in not using the terms defined by ISO 42010 is that inconsistency results:

    'As the enterprise architecture description is built in those steps, it....'
    'Some architectural descriptions may represent generalizations or elements intended to convey guidance and patterns for reuse'

    'Architectural Description – a work product used to express the Architecture of some System Of Interest.It provides executive-level summary information about the architecture description in a consistent form to allow quick reference and comparison between architecture descriptions – It includes assumptions, constraints, and limitations that may affect high-level decisions relating to an architecture-based work program. (Note: architectural description is a UAF model element and “architecture description” is simultaneously a concept used in ISO 42010 that is defined as a collection of architecture views)'

    The Note is meaningless - what does ' simultaneously a concept used in ISO 42010 that is defined as a collection of architecture views' and how somehow does 'architectural description' differ?

    The definition deceives the reader into thinking that this is ISO 42010 definition. The first part has indeed been taken from ISO 42010 - reference needed and then has been added to starting with 'It includes...' which is not part of the ISO 42010 definition of 'architecture description'

    and in the DMM 9.1.2 p 130 we have 'Architectural Description' defined as 'An Architecture Description is a work product used to express the Architecture of some System Of Interest.'

    If it's an (ISO 42010) Architecture Description use the term Architecture Description.

    'to federate multiple architectural descriptions in a structured manner or as a set of associations or usages within an organization’s architecture description repository ...' - 'architecture description repository' (correct) storing 'architectural descriptions' (incorrect)

    'so that architecture description elements may be directly translated into model ...' - 'architecture description element' (correct) - not 'architectural description elements'. Interstingly the UAF DMM has no such thing as an Architecture Description Element.

    Later on we have:

    View – an “information item..' - this is incorrect the ISO 42010 term is 'architecture view' since 'view' has many other meanings.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:37 GMT
  • Updated: Thu, 18 Apr 2024 13:37 GMT
  • Attachments:

'Reference Architecture' Should be 'Reference Architecture Description'

  • Key: INBOX-1947
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    In 3.3 Establishing the Purpose and Scope of the Architecting Effort we have :-

    'The enterprise architecture description is used by stakeholders to improve communication and cooperation among affected parties and enable them to work together in a more integrated, coherent fashion. This will, in turn, help the enterprise more effectively achieve its goals. This can be facilitated by creating a “reference architecture” that guides development of the rest of the enterprise architecture in Steps 3-7, as well as using an architecture framework that defines the views to be used.'

    The subject is an enterprise architecture descriptiuon.

    "Reference architecture" is incorrect - it should be "reference architecture description" that guides development of ... the 'enterprise architecture description' (not enterprise architecture)

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:19 GMT
  • Updated: Thu, 18 Apr 2024 13:19 GMT
  • Attachments:

Consistency - 'Cross Cutting Viewpoints' Are Not ISO42010:Architecture Viewpoints - They're MODAF::Viewpoints - Same Word, Different Meaning

  • Key: INBOX-1946
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.6 Cross Cutting Viewpoints and Figure 1:5 - Cross-Cutting Viewpoints in UAF

    These are not 'Viewpoints' in the sense of either ISO/IEC/IEEE 42010 or even the UAF's own DMM - 9.1.2 Summary & Overview - Viewpoint p134 - Viewpoint.

    This inconsistency needs to be removed. Terms should not be incosistent with international standards. Any term used in the text should also be consistent with the underlying metamodel.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 13:11 GMT
  • Updated: Thu, 18 Apr 2024 13:11 GMT
  • Attachments:

Incorrect of the Term 'Modelling Language' As Synonym for a UML Profile

  • Key: INBOX-1945
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Puzzled why the UML profile for the UAF, the UAFP, is now incorrectly termed the UAF Modelling Language as this introduces yet another unwanted term for a UML Profile that is in use for the SysML and the UML yet somehow confusing or not good enough for the UAF requiring it to invent its own bespoke term for the same concept.

    Looking at closed issue UAF-29 - https://issues.omg.org/issues/UAF12-29

    The argument then made:
    'Misunderstanding about whether the UAF Profile can be used in modeling an enterprise architecture. Not uncommon for managers to think that they must use SysML to model their EA since they don't realize that the UAFP is already designed with the semantics for modeling enterprise constructs such as capability, enterprise phase, processes, personnel, operations, services, portfolios, etc. This misunderstanding is largely due to fact that UAFP is called a "profile" and many don't understand what is meant by profile. '

    1) The UAFP is as is explained at length in the EA User Guide - an implementatoion of SysML so, yes, SysML is used for the UAF views. Are you stating that the UAF views can be produced in a UML modelling tool without the UAFP and without the SysML (non SysML users Don't Care About the this as it is irrelevant)
    2) The UAFP is a UML profile. If it isn't please explian why - there does seem to be an XML file that is a UML profile
    3) No users should be concerned with UML profiles - if they are it is because the OMG unnecesarily include this in user-facing documentation. The solution is to remove references to it from the EA User Guide

    The disposition on closing then states:

    'The decision has been taken by the group to rename the profile part of the specification to the modelling language following the naming convention of OMG, e.g. UML, SysML, SoaML, RAAML, etc. The change will improve clarity of the purpose of the document as the term "Profile" is not so well understood in non UML modellers community. Plus it is more than just profile. It also brings notation. '

    4) The UAFML is not distinct from the SysML - is every model using the SYSML now its own modelling language? Of course not.
    5) '"Profile" is not so well understood in non UML modellers ' - why does any non-UML modeller care about a profile - it's completely irrelevant because it's an implementation mechanism for a UML modelling tool. Non-UML modellers use the DMM which is supposed to be - but isn't quite yet - UML free / agnostic. This is invalid.
    6) The SysML and the UML are UML profiles. They also have 'notation' - whatever 'notation' means since this doesn't form part of any specification of the UAF DMM.
    7) The DMM correctly identifies the UAFML as a profile : 'The Unified Architecture Framework Modeling Language (UAFML) is the standard implementation of the UAF DMM. It was created by mapping the UAF concepts and relationships to corresponding stereotypes in the UAFML Profile.'
    8) The user cannot use the UAFML to create views - the XML profile does not content elements to represent the UAF architecture views nor define what is allowed in each `UAF architecture view - this is done in the UML modelling tool. The users cannot therefore use the UAFML without this extra hidden 'magic' (technical debt). They can, however, open a UML modelling tool and use the tool to create a UAF view of a particular flavour (with no mention or reference to the UAFML in sight).

    It is this casual creation of new terms to refer to existing terms that is one of the root causes of inconsistency within the UAF. The point of standardisation is sticking to the terms not constantly rolling your own.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 12:33 GMT
  • Updated: Thu, 18 Apr 2024 12:33 GMT
  • Attachments:

User Guide - The User Cannot Use the UAFML - they Use a Modelling Tool with Added Behaviours. Incorrect Claims for UAFML. UAFML benefits / features unclear

  • Key: INBOX-1944
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.1 Overview of the Unified Architecture Framework - Modelling Using the UAF. states:-
    'Modeling Using UAF. The UAF Modeling Language 1 (UAFML) is an implementation of the DMM that specifies how the UAF views can be modeled using the SysML notation and semantics. Even though the UAFML is based on SysML, there are some significant differences that should be noted. SysML is great for doing the following activities:
    (a) modeling systems and for doing systems engineering,
    (b) defining and tracing between levels of abstraction within a system,
    (c) defining the logical and physical attributes for a system and the mapping of requirements and functions to these attributes. The UAF Modeling Language provides all this, plus more:
    a) Capability and Enterprise Concepts: defines the “why” and “what” and “when” before the “how”
    b) Services Concepts: definition of enterprise services (producing and consuming) and traceability to capabilities, operations and implementing resources
    c) Human Factors: How people and systems interact, and their expected knowledge & skills
    d) Security: Identifying risk, its mitigation, and integrating security into the architecture
    e) Standards: definition of and compliance with standards in the architecture
    f) Project Deliveries: phased milestone approach to capability deployment
    g) System Configuration Over Time: deployment and changes in roadmaps and timelines
    h) Tie-in to Non-System Elements in the Architecture: Easy way to link the entire Architecture to Requirements
    i) Built-in Traceability Between Multiple Views: Between Layers and Across Layers'

    The problems with this are:-
    1) The title is modelling using the UAF but most of the subject matter seems to be the UAFML
    2) This is a user guide - the user will never use the UAFML directly. The UAFML, more correctly the UAF (UML) Profile XML (), contains only UML and SysML implementations of the DMM elements. It does not contain any UAF architecture views nor does it define what triples appear in each UAF architecture view. This is implemented by the respective tool vendor. If the user did load the profile they would see a large set of UML/SDysML elements and they'd have to figure out which to use to produce a conforming UAF architecture view. The UAFML does not 'specifies how the UAF views can be modeled' - it simply defines which UML and SysML elements are used to implement the DMM elements needed.
    3) The UAFML isn't a modelling language - it's a single use of a modelling language (UML and SysML). It cannot be used as a modelling language by the user. It is a UML profile so new terms shouldn't be created for well defined and understood concepts. Are the OMG now renaming UML profile to 'Modelling Language'? This just adds inconsistency and shows a lack of the importance of standardisation. The language being used is still the UMNL or the SysML not the UAFML.
    4) d), e), h) incorrectly use 'Architecture' which should be 'Architecture Description'
    5) h) is meaningless - what is a 'tie-in to Non System Elements'? The subject seems to be traceability / conformance to requirements which can be described. And what does 'entire architecture' mean? Do you mean 'any Architecture Description Element can be linked to one or more Requirements'? Why 'Non-System'? Don't you allow a System element to be linked to Requirements?
    6) f) is titled 'Project Deliveries' but then describes 'capability deployment' - projects always deliver tangible things, which may include Systems. The sentence should be modify to describe what the UAF can describe wrt project delivery [how this affects capability is the subject of a))
    7) c) Human Factors - 'expected competences and skills' should be 'competences' (the text needs to use the terms in the DMM so cross-comparison is possible)
    8 e) h) Standards - 'Requirement' isn't a UAFElement or indeed a DMM element (DMM Figure 9:134) - it doesn't exist within the UAF
    9) Built-in Traceability. What does this mean? What DMM elements are automatically linked to what other DMM elements? The UAF Grid doesn't define layers so what is a 'layer'? This could be a liability if the user has no control.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 11:17 GMT
  • Updated: Thu, 18 Apr 2024 11:17 GMT
  • Attachments:

writing error

  • Key: INBOX-1943
  • Status: pending   Implementation work Blocked
  • Source: Shanghai Action Technology Co., Ltd. ( Action Hao)
  • Summary:

    The original text reads:
    The RTPS protocol version 2.5 defines the following special values.
    PROTOCOLVERSION_1_0
    PROTOCOLVERSION_1_1
    PROTOCOLVERSION_1_0 PROTOCOLVERSION_1_1
    PROTOCOLVERSION_2_1
    PROTOCOLVERSION_2_2
    PROTOCOLVERSION_2_2
    PROTOCOLVERSION_2_4

    Two PROTOCOLVERSION_2_2 appeared
    I think it should be PROTOCOLVERSION_2_3

  • Reported: DDSI-RTPS 2.5 — Thu, 18 Apr 2024 10:36 GMT
  • Updated: Thu, 18 Apr 2024 10:36 GMT
  • Attachments:

Incorrect Use of MODAF::Viewpoint in Grid

  • Key: INBOX-1942
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    1.1 Overview of the Unified Architecture Framework p2 states:-

    'The UAF Grid (Figure 1:2) has rows that represent typical stakeholder domains (or viewpoints as they are called in UAF)'

    Figure 1:2 shows a left hand column which the callout labels as 'Viewpoints'. The cells identifiy 'View Specifications'

    This is clearly wrong and inconsistent with ISO/IEC/IEEE 42010. It looks as though the authors have not appreciated that 'viewpoint' for the leftmost column derives from the MODAF use of the term to collect together a group of architecture view definitions with a common theme. In the old ISO/IEC/IEEE 42010:2011 text this was referred to as an (architecture) perspective. In misusing 'viewpoint' this then left a problem of how to refer to the things that specify architecture view content (ISO42010:Architecture Viewpoint) and therefore another undefined term was added - 'view specification' which seems to mean the same thing as ISO42010:Architecture Viewpoint.

    The use of 'view specification' is further muddied by the DMM Figure 7-1 p13 which states that 'view specifications (cells) correspond to viewpoints'. This could be read a view specifications is a synonym for viewpoint.

    It's a mess. The easiest solution is to consistently use the ISO 42010 definitions and the names of the ISO 42010 concepts without alteration

    1) Eliminate any mention of 'view specification' where this refers to an artefact that specifies architecture view content. The correct term is 'Architecture Viewpoint' not 'Viewpoint' (as this is otherwise easily confused with other uses of the term).
    2) The use of Viewpoint in reference to the left hand column of the UAF Grid is incorrect - that is an inconsistent and incorrect and doesn't (as claimed) conform to ISO/IEC/IEEE 42010. The suggestion is 'Architecture Perspective'. 'Domain' often refers to other things. Whatever term is used it needs to be prefixed with 'Architecture' to separate it from the casual use of the term.
    3) Correct the names of the metamodel elements in the DMM. If you can't or won't, produce a mapping table that demonstrates the mapping and the equivalence to the standard.

    4) A viewpoint is not a 'stakeholder domain'. This seems to be using 'viewpoint' in another sense. It is also not a synonm for 'domain'. The cells identifiy 'architecture viewpoints' - specifications against which architecture views are created and interpreted.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 09:01 GMT
  • Updated: Thu, 18 Apr 2024 09:01 GMT
  • Attachments:

Incorrect Inclusion of UAF Architecture Viewpoints in an AD. Inconsistent and Incorrect Definition of 'Concern'. A StrategicPhase is Not a System

  • Key: INBOX-1941
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    4.1.3 Architectural Description Structure p26 states:

    'Each architectural description is either decomposed into, or synthesizes, views and viewpoints, which may be laid out in dashboards and other fit-for-purpose perspectives to aid in understanding an architectural plan. Each planned viewpoint should address specific concerns held by relevant stakeholders'

    1) Simply 'decomposes into or synthesizes' to 'formed from' - the aim should be to have as short a document and as short as sentences as possible.
    2) 'decomposes into ... viewpoints' is incorrect for the UAF. Users are not going to include the UAF viewpoints in each of their architecture descriptions. Even in ISO/IEC/IEEE 42010 where it got less clear in the 2022 edition owing to removal of multiplicities the inclusion of architecture viewpoints is a 'may' not 'shall'
    3) What's a 'planned viewpoint' ? Architecture Viewpoints don't address concerns - iaw ISO/IEC/IEEE 42010 they frame concerns. It is not 'should' - Architecture Viewpoints always frame at least one Concern - mandatory i.e. don't misquote the standard. In following the guide the user should reasonably expect to conform to the standard. This process step seems to be the inverse of what the standard says - you first establish what the architecture description task stakeholders concerns are, then you select the architecture viewpoints that most closely frame those concerns.

    Later on we have:

    'Concern – interest in a Strategic Phase (Strategic Phase is synonym for System in ISO 42010) relevant to one or more of its stakeholders. (Note: a concern may be a “matter of relevance or importance to a stakeholder regarding an entity of interest” [ISO 42010] that will be addressed in an architecture)'

    4) A Concern is not an interest in a Strategic Phase. In ISO/IEC/IEEE 42010 it's 'matter of relevance or importance to a stakeholder'. In the DMM p131 it's 'A matter of relevance or importance to a stakeholder regarding an entity of interest.' which is more restrictive that the standard - you can only raise a concern about the entity of interest. It's definitely NOT 'interest in a Strategic Phase'. Suggest that you adopt the ISO definition consistently and without additions.
    5) Strategic Phase is NOT a synonym for System in ISO 42010 - a duration or time period is not equivalent to a System
    6) a Concern is addressed in an 'architecture description' NOT 'architecture' via the content of the architecture views produced.

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 08:26 GMT
  • Updated: Thu, 18 Apr 2024 08:26 GMT
  • Attachments:

Inconsistent Definition of 'Architecture'. Unintelligable Note. Incorrect Reference. Step Name Should be 'Define Architecture Description Drivers and Challenges'

  • Key: INBOX-1940
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    4.1 Step 1 Define Architecture Drivers and Challenges p22

    1) The subject isn't 'architecture' - it's 'architecture description' - reference materials, the AD effort. The name should therefore be 'Define Architecture Drivers and Challenges'
    2) It incorrectly states 'The Summary and Overview architecture view defines the overall architecture'. It doesn't. It defines the architecture description. If you look at p25 in the DMM - View Specifications::Summary & Overview::Summary & Overview - states 'Concerns: quick overview of an architecture description and summary of analysis.' i.e. 'architecture description' not 'architecture'

    p23 we have a definition of 'architecture':
    'Architecture – fundamental concepts and properties related to an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes [ISO/IEC/IEEE 42020:2019] (Note: This architecture entity can be an enterprise or system or some other kind of thing. These fundamental concepts and properties can be about key entities and relationships, along with associated behaviors, which are characterized in an architectural description.)'

    3) The source for the definition should be ISO/IEC/IEEE 42010 not ISO/IEC/IEEE 42020
    4) There is an additional note which isn't part of the original source - this incorrectly states 'This architecture entity can be an enterprise or system or some other kind of thing'. This cannot be true. In ISO/IEC/IEEE 42010:2022 we have in the conceptual model 'Entity of Interest has Architecture' therefore Architecture cannot be the same as Entity of Interest or System.

    In the DMM 9.1.2 Domain MetaModel::Summary & Overview p 131 we have a definition for the Architecture metamodel element:

    'An abstract type that represents a generic architecture. Subtypes are OperationalArchitecture, Service Architecture, and ResourceArchitecture.'

    5) Ignoring the fact that the DMM doesn't define the Architecture concept - it only defines its use in representing a real world thing (as all AD elements do) - we have 2 different definitions of Architecture. The DMM one is incorrect. The suggestion is to use the ISO/IEC/IEEE 42010 one unaltered - the UAF incorrectly claims that it conforms to ISO/IEC/IEEE 42010 so why wouldn't it use the definitions and relationships from the standard?

  • Reported: UAF 1.2 — Thu, 18 Apr 2024 07:51 GMT
  • Updated: Thu, 18 Apr 2024 07:51 GMT
  • Attachments:

'Definition' Seems to be an Attribute of Any UAFElement - It Shouldn't Be a Separate Element (Inconsistent Representation of Attributes)

  • Key: INBOX-1939
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The metamodel element Definition is defined 'A comment containing a description of an element in the architecture.' and Figure 9:119 shows that there is some unnamed relationship between UAFElement and Definition (impossible to extract any meaning from this).

    1) The definition of Definition is wrong - 'a comment containing a description' - is this Comment, Description or, as the element name says,a definition?
    2) Every UAFElement presumably has a 'description' - if Definition is an attribute of every UAFElement why not show it as such on the UAFElement (as has been done with the 'author' element of Definition - inconsistent representation of attributes). If this isn't an attribute there needs to be something in the text of the document to explain how to interpret. All relationships should be named - any unnamed relationship, excepting specialisation, is an error as it leaves the interpretation to guesswork . Role names are a bonus.
    3) The 'author' element name needs to be qualified to 'definition author' or 'comment author' to separate it from the DCMI creator tag (= author). It isn't clear in the UAF whether there is an 'element author' - the person who created the element. It would make more sense for the element creator to be captured since they presumably define the element on creation - simply capturing the definition author and not the element author makes little sense.

  • Reported: UAF 1.2 — Wed, 17 Apr 2024 07:47 GMT
  • Updated: Wed, 17 Apr 2024 07:47 GMT
  • Attachments:

Figure 9:118 Caption ' ArchitectureMetadataDefinition' Includes the Following Metamodel Element Title ('Definition')

  • Key: INBOX-1938
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.1 Domain Metamodel::Architecture Management - Definition / Figure 9:118

    The 'Definition' metamodel element title has somehow got merged into the preceding Figire 9:118 caption - 'Figure 9:118 – ArchitectureMetadataDefinition'

  • Reported: UAF 1.2 — Wed, 17 Apr 2024 07:20 GMT
  • Updated: Wed, 17 Apr 2024 07:20 GMT
  • Attachments:

View Specification - Am-Pr Architecture Development Method Name Doesn't Match Subject. Missing (No) Triples to Address Concerns

  • Key: INBOX-1937
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    8.1.1 View Specification - Am-Pr Architecture Development Method is defined:

    'Stakeholders: Enterprise Architects, Model Managers, Modelers, Enterprise Systems Engineers. Concerns: development sequence of models and views and how they are related to each other. Definition: defines workflow or process steps used in managing the architecture development. Recommended Implementation: SysML Activity Diagram, text.'

    Figure 8.4 shows a single element - ArchitecturalDescription. No relationship elements. No architecture views,

    1) The subject description of views, their sequence etc is not 'architecture' it's 'architecture description'. The view specification name is therefore not correct - the subject doesn't appear within the view specification name - it should be 'Architecture Description Method'
    2) There are no elements / triples provided to describe the sequence of models, views and how they relate to each other hence Fig 8.4 does not provide the means to address the concerns. Presumably there should be at least the means to describe a trace. To describe a sequence of views you need something like 'View follows View'
    3) Figure 8.4 only shows a single attribute for ArchitecturalDescription - see Figure 9:129. It ought also to include purpose, assumptionandConstraint etc (all of the ISO/IEC/IEEE 42010 required properties)
    4) It suggests using a SysML Activity Diagram but provides no triples to describe Activities or their sequence.
    5) If models and their sequence are expected you need to provide the means to describe them.
    6) This view specification does so little that there seems to be little point in its existance - it would be easy to incorporate the concerns into another Am view specification.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 11:13 GMT
  • Updated: Tue, 16 Apr 2024 11:13 GMT
  • Attachments:

Tables Refer to a View Specification Am-Tx Architecture Extensions that Doesn't Exist + Table Numbering Error Table 1:2

  • Key: INBOX-1936
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    The tables Table 2:1, 1:2, 2:2, 2:3 mapping the various AF viewpoints to the UAF view specifications show a Am-Tx Architecture Extensions view specification that doesn't exist. Until the view specification has been defined these rows should be deleted.

    Table 1:2 has a table number that doesn't fit with the previous 2:1 table and the following Table 2:2 identifier. The identifiers for the tables 1:2, 2:2 and 2:3 need to be corrected.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 10:51 GMT
  • Updated: Tue, 16 Apr 2024 10:51 GMT
  • Attachments:

UAF Grid and text refers to 'Architecture Extensions' View Specification - View Specification Doesn't Exist

  • Key: INBOX-1935
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Section 7 UAF Grid. Fig 7-1 and note e) refer to a 'Architecture Extensions' view specification:
    'The Architecture Extensions view specification provides a means to extend the framework to other domains'

    1) There is no 'Architecture Extensions' view specification in 8.1 View Specifications
    2) The name 'Architecture Extensions' is incorrect - the subject is not the architecture but the architecture description (it describes means to extend the architecture framework not the architecture'. The name should more accurately be 'Architecture Description Extensions' or 'Architecture Framework Extensions'.

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 10:35 GMT
  • Updated: Tue, 16 Apr 2024 10:35 GMT
  • Attachments:

View Specification Am-Tr Architecture Traceability - Only 1 Relationship Element Provided, Unable to Describe Traces to External Sources

  • Key: INBOX-1934
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 8:10 - Architecture Traceability.

    The (Am-Tr) Architecture Traceability view specification has a number of problems:-
    1) Figure 8-10 only allows one relationship (in green) - ...Architecture implements ...Phase - what is this supposed to mean - there is no direction ? How does this address the understanding of 'the impact of change'?
    2) Under stakeholders - 'people who want to understand impact of change across the architecture supporting assets,' is a concern not a role
    3) Under concerns - 'reuse of architectures' - given the widespread conflation of 'architecture' and 'architecture description' does 'architecture' here mean 'architecture'?
    4) ArchitecturalDescription is show yet there is no allowed relationship with it. As it does not contribute any tripes that are allowed it should not be shown in the Figure
    5) Under definition we have 'shows references to ... external sources, e.g. documents'. There are no relationships or artefact elements shown to enable these references to be described
    6) Typo on role on Architecture - 'realizingArchitedcture'

  • Reported: UAF 1.2 — Tue, 16 Apr 2024 08:24 GMT
  • Updated: Tue, 16 Apr 2024 08:24 GMT
  • Attachments:

acquire/release mastership - system requesting mastership is ambiguous

  • Key: INBOX-1933
  • Status: pending  
  • Source: RTX ( Dr. David Bainbridge)
  • Summary:

    The acquire and release mastership messages have only a "count" field. There is no way for the radar to determine which system is requesting or releasing mastership. The radar needs to know the identity of the master when reporting mastership. Suggest adding a subsystem ID to acquire and release mastership messages.

  • Reported: OARIS 2.0 — Mon, 15 Apr 2024 15:49 GMT
  • Updated: Mon, 15 Apr 2024 15:49 GMT
  • Attachments:

Multiplicity of composition/aggregation end for many different elements with {subsets owner} should be 1 and not 0..1

  • Key: INBOX-1932
  • Status: pending  
  • Source: N/A ( Robert Hairgrove)
  • Summary:

    At page 64 of the PDF file, section 7.2.3.1 "Elements", states: "Every Element in a model must be owned by exactly one other Element of that model, with the exception of the top-level Packages of the model."

    There are very many diagrams which show owner relationships as composition between different elements, sometimes with multiplicity as 0..1 and sometimes as 1.

    For example, on PDF page 64-65 under section 7.3 Templates, diagram of "Abstract Syntax" at 7.3.2:

    • TemplateableElement owns zero or one TemplateSignature, and TemplateSignature has exactly 1 owner;
    • Ownership of ParameterableElement is given correctly as 0..1 because a Package is also a ParameterableElement since it is a
      specialization of PackageableElement, but a Package might not have an owner.

    So these seem correct to me. However, referring to the diagram on (PDF) page 149, section 9.4.2 "Features - Abstract Syntax":

    • Parameter owns zero or more ValueSpecifications, but Parameter is the owner, so it should be exactly 1 and not 0..1;
    • BehavioralFeature owns Parameter and ParameterSet, but multipicity of the owner is 0..1 instead of 1;
    • ParameterSet owns Constraint, but multipicity of the owner is 0..1 instead of 1;

    Since neither ValueSpecification nor Parameter nor Constraint can be Packages, they should always have exactly one owner Element, if I understand this correctly.

  • Reported: UML 2.5.1 — Mon, 15 Apr 2024 13:57 GMT
  • Updated: Mon, 15 Apr 2024 13:57 GMT
  • Attachments:

ActualPerson is not a Distinct Type. Inconsistent Representation of Individual vs Type/Class wrt Other Metamodel Elements (ActualXXX Elements Contradict Class Mechanism))

  • Key: INBOX-1931
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.6 Domain Metamodel::Personnel - Person, Figure 9:234

    Person is defined as 'A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g., properties such as address, telephone number, nationality, etc).'

    1) This doesn't define what the 'Person' concept is - it only defines how it is used for an implementation that seeks to be able to represent a real world person. Every Class/Type defines properties applied to an individual - this is not an identifying feature.

    2) In most modelling languages such the UML etc we have a means to represent a type (Class) e.g. UML Class and an individual (instance of a UML Class). The individual / instance automatically takes on the propertties of the type / Class.

    If, for example, I instantiate a UML Class named 'Car' that has a property, 'manufacturer' the resulting element is an individual which we understand to represent a real world thing, Car. I can then allocated the manufacter's name to the 'manufacturer' property. None of this requires an ActualCar - all of the Class/Type properties are defined as part of the Class/Type - there is no new type or stereotype needed to define Class properties.

    For example if I have a model element of Type/Class = Standard and then give it a DCMIIdentifier = 'ISO/IEC/IEEE 42010' and DCMITitle = 'Interational Standard - Systems and Software - Architecture Description' everyone understands that this is a representation of the real world artefact - ISO/IEC/IEEE 42010. There is only the one Class/Type which defines the properties that make the Class unique from all other types. Class definitions have to be unique - if they depend on another Class then they're not. There is no ActualStandard required.

    ActualPerson is not a type of Person - as defined it only exists to hold a set of properties that can be applied to an individual or instance of the Person Class/Type.

    This separation is completely inconsistent with every other UAF metamodel element - we don't have ActualArchitecturalDescription, ActualArchitectureViewpoint, ActualStandard et al. This looks to be an old error inherited from early MODAF days where someone was thinking of abstractly representing instantiation but made the mistake of embedding this in what was a UML implementation (the M3).

    The 'Actualxxx' construct isn't needed in the UAF. Nor is it needed by any implementation of the UAF in any other ADL. On p288 we have ActualPerson = 'An individual human being.' - it isn't - it's supposed to be a type of Person. This makes no sense since the metamodel presents types.

    It adds more elements, relationships, complicates implementation, adds inconsistencies and increases the cost of maintenance for no good reason.

    From a practical means to define properties of individuals there is no technical need for ActualPerson, Actual-anything.

    The DMM looks to be a bottom-up merging of donor AF metamodels warts and all rather than a top-down what-do-I need-to-address-each-viewpoint-concern. This has not only not preserved errors but does not produce the smallest metamodel needed (very much like constructing programme task logic from the start/left rather than starting with the end deliverable and working to the left).

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 13:36 GMT
  • Updated: Mon, 15 Apr 2024 13:36 GMT
  • Attachments:

ServiceRole is Neither a Type of Nor Part of a Service

  • Key: INBOX-1930
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.5 Domain Metamodel::Services - ServiceRole , Figure 9:215 - ServiceRole

    'A behavioral feature of a Service whose behaviour is specified in a ServiceFunction'

    a Role is something that is played by typically an Actor. i.e. the relationship is something like Service plays ServiceRole (if the metamodel names are accurate).

    Instead what is shown is:-
    1) a role name of 'type' on Service - Service is a type of ServiceRole?
    2) whole:part relationship - ServiceRole is a part of Service - it shouldn't be a whole:part if a role is played by the element
    3) How does anyone in a non-UML or even UML ADL implement this view specification - the only 3 green relationship elements provided are ServiceMessage from/to ServiceRole, ServiceConnector from/to ServiceRole, the other end of PerformsInContext isn't shown. There are many possibilities (OperationalRole, OperationalActivityAction, FunctionAction, ResourceRole, ServiceFunctionAction, ServiceRole) - Figure 9:107 - which one or ones are permitted for this view specification? This is a problem in not presenting whole triples i.e. there should be no case where both the from and to node elements aren't also shown.
    4) role names on ServiceMessage should be on ServiceRole not the ServiceMessage connector element
    5) The definition of ServiceRole is not atomic and hence incorrect - in depends on the existence of a relationship with a ServiceFunction element hence is not independent and defines a triple.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 08:52 GMT
  • Updated: Mon, 15 Apr 2024 08:52 GMT
  • Attachments:

'Usage of + 'Whole:Part' - ProtocolLayer is Not a Distinct Metamodel Concept - It is a Reflexive Whole:Part Relationship on Protocol

  • Key: INBOX-1929
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    9.1.10 Domain Metamodel::Standards::Structure , Fig 9:236 ProtocolLayer

    ProtocolLayer is defined as 'Usage of a Protocol in the context of another Protocol. Creates a whole-part relationship.'

    1) ProtocolLayer (as identified by 'another' and 'usage') is not therefore distinct from Protocol and shouldn't therefore be a metamodel element - it should be represented by a whole:part relationship on Protocol.

    2) ProtocolLayer is not a type of Protocol - which I what I think the incorrect role name on the Association from ProtocolLayer to Protocol is stating. whole:part + type = ?

    3) Any metamodel element including 'usage' is likely to be invalid. Usage is a particular UML implementation and often a fudge. No metamodel element is a usage of any other. An elementis its own thing - if usage is involved it is not a distinct concept.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 08:19 GMT
  • Updated: Mon, 15 Apr 2024 08:19 GMT
  • Attachments:

8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Specification Doesn't Provide Any Sequencing Triples to Address Its Concerns

  • Key: INBOX-1928
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    View Specifications::Operational::Sequences::Operational Sequences View Specification:

    'Concerns: express a time ordered examination of the operational exchanges as a result of a particular operational scenario.

    Definition: provides a time-ordered examination of the operational exchanges between participating nodes (OperationalPerformer roles) as a result of a particular operational scenario'

    1) Figure 8:29 includes no triples to define the order of exchanges of operational messages. Even the incorrectly included UML Lifeline does not define an order - it is inferred by visual presentation reading from, say, top to bottom or annotating with a sequence number. There are no formal semantics that define the order of a sequence. In any case the UML shouldn't be in this document - it is a specific implementation. The missing part in this view specification is something that semantically describes order or=f exchanges (which the UML etc is then able to implement) i.e. something like' OperationalExchange follows OperationalExchange'

    2) The concern isn't 'time-ordered examination' - it is something like 'in what order ....'

    3) The definition should be phrased in terms of real world things not the metamodel representing the real world. It might include the application of the viewpoint to real world situations. Simply describing the metamodel provides no utility.

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 06:56 GMT
  • Updated: Mon, 15 Apr 2024 06:56 GMT
  • Attachments:

8.1.4 View Specifications::Operational::Sequences::Operational Sequences View Spec Includes UML Metaclasses

  • Key: INBOX-1927
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Figure 8:29 Operational Sequences shows 3 UML Metaclasses - Message, Interaction and Lifeline.

    The DMM is supposed to be agnostic and therefore should include no UML, SysML, BPMN et al ADL elements. The UML/SysML implementation is supposed to be in formal/22-07-05 UAF Modelling Language

  • Reported: UAF 1.2 — Mon, 15 Apr 2024 06:40 GMT
  • Updated: Mon, 15 Apr 2024 06:40 GMT
  • Attachments:

Operational Structure Viewpoint Identifier Should Be 'Op-Sr' Not 'Op-St' (which duplicates Operational States Viewpoint Identifier)

  • Key: INBOX-1926
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Table 2:1 - UAF 1.2 to DoDAF 2.02 Mapping at the bottom. The Operational Structure viewpoint identifier is shown as 'Op-St' which duplicates the Operational States Viewpoint identifier. it should be 'Op-Sr'

  • Reported: UAF 1.2 — Sat, 13 Apr 2024 20:09 GMT
  • Updated: Sat, 13 Apr 2024 20:09 GMT
  • Attachments:

8.1.1 View Specifications::Architecture Management::States::Architecture Status has Nothing to Do with 'Architecture' - It Describes the State of the Architecture Description

  • Key: INBOX-1925
  • Status: pending  
  • Source: Eclectica Systems Ltd ( Nic Plum)
  • Summary:

    Another consequence of the failure within the UAF to distinguish between 'Architecture' and 'Architecture Description' concepts.

    The title of the viewpoint (not 'View Specification') is ' - View Specifications::Architecture Management::States::Architecture Status

    'Stakeholders: Enterprise Architects, people who want to understand the architecture governance, Technical Managers. Concerns: architecture status.

    Definition: captures version number and approval workflow of the architecture. Recommended Implementation: SysML State Machine Diagram, state table, text.

    ArchitecturalDescription

    status : String [*]

    ...

    Figure 8:5 - Architecture Status'

    Figure 8.5 shows the ArchitectureDescription element - NOT any ...Architecture element. It is clear that the viewpoint describes the state of the architecture description not architecture.

    Hence NOT 'architecture governance' - should be 'architecture description governance', 'approval workflow of the architecture description', The name of the viewpoint should be 'Architecture Description State' since 'St' = state and the subject is 'Architecture Description' not 'Architecture'

  • Reported: UAF 1.2 — Sat, 13 Apr 2024 19:50 GMT
  • Updated: Sat, 13 Apr 2024 19:50 GMT
  • Attachments:

The Normative References section refers to both versions 1.0 and 1.1 of XML Schema for no obvious reason

  • Key: INBOX-899
  • Status: pending  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Normative References section refers to both versions 1.0 and 1.1 of XML Schema for no obvious reason

  • Reported: Untriaged — Thu, 10 Dec 2009 05:00 GMT
  • Updated: Fri, 16 Aug 2019 16:16 GMT
  • Attachments:

GIOP and IIOP versioning must be clearly and consistently specified

  • Key: INBOX-894
  • Status: pending  
  • Source: Red Hat ( Robert Kukura)
  • Summary:

    GIOP and IIOP versioning must be clearly and consistently specified. There are numerous places within the Firewall Traversal FTF report's version of CORBA chapter 15 where certain specific GIOP or IIOP versions are explicitly cited, but the newly introduced versions are not mentioned. For example, the definition of the GIOP_version field of the GIOP Message Header in section 15.4.1 says "The major GIOP version number of this specification is one (1); the minor versions are zero(0), one (1), and two (2)." GIOP versions 1.3, 1.4, and 1.5 are not addressed. Similarly, table 15-3 does not even show messages such as Request and Reply applying to GIOP versions 1.4 and 1.5. There are other occurances where the intent may not be so obvious. I recommend revisiting every reference to a particular GIOP or IIOP version in chapter 15 to make sure that the new versions (including 1.3) are correctly addressed. Where possible, I recommend replacing lists of versions with text such as "version 1.2 and up" that does not need to be revised every time a new version is introduced.

  • Reported: Untriaged — Mon, 10 May 2004 04:00 GMT
  • Updated: Fri, 16 Aug 2019 16:11 GMT
  • Attachments:

Licensing Service issue

  • Key: INBOX-893
  • Status: pending  
  • Source: OES Technologies Ltd ( Mark Biggerstaff)
  • Summary:

    The Action struct has a member of type ActionRequired, name 'action' .

    The JacORB (1.4 beat 4) IDL comiler/parser complains that the declarator has already been used (identifier collision):

    Error in CosLicensingManager.idl, line:28(17): Declarator action already defined in scope. ActionRequired 1 error(s). Errors compiling CosLicensingManager.

    The Corba spec (2.4 00-10-01) states in the Lexical definitions that upper and lower case are regarded as the same. Is the use of the Action & action definitions twice then a collision? Can the the action variable be renamed in the IDL file to something like action_required without affecting any other specification /

  • Reported: Untriaged — Tue, 18 Jun 2002 04:00 GMT
  • Updated: Fri, 16 Aug 2019 16:10 GMT
  • Attachments:

omission from the OMG --Trader spec

  • Key: INBOX-892
  • Status: pending  
  • Source: Class Design Limited ( Bill Somerville)
  • Summary:

    Given a property P defined by type B as PROP_NORMAL, two types T1 and T2 inherit from B but each strengthens the mode to PROP_READONLY and PROP_MANDATORY respectively. Then is there an implied strengthening to PROP_MANDATORY_READONLY in a further derived type T3 which inherits from both T1 and T2? Related to this, the OMG spec has nothing to say about waht exception should be raised by an attempted "weakening" of a property mode by a sub-type or exactly what is construed as a "weakening" with multiple inheritance. Another slightly different senario is: Given a property P defined by type B as PROP_READONLY, two types T1 and T2 inherit from B with one of them "strengthening" the mode of B to PROP_MANDATORY_READONLY. Is deriving a type T3 from both T1 and T2 legal?

  • Reported: Untriaged — Wed, 3 Nov 2004 05:00 GMT
  • Updated: Fri, 16 Aug 2019 16:09 GMT
  • Attachments:

Relationship connector and components/homes not clearly specified

  • Key: INBOX-891
  • Status: pending  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The spec does not clearly describe the relationship between connectors and components (inheritance?) and homes (manageability).

    >From paragraph 7.4 (programming model for connectors) we can conclude the following:
    1. connectors are derived from CCMObject
    2. connectors (can) have a (keyless) Home

    The formal spec in the earlier paragraphs of chapter however does not seem to mention any of this or of the consequences like:
    a) can we explicitly define a connector as the managed component of a Home?
    b) can we define explicit factories for connectors in a Home managing that connector?
    c) can we declare a component as an explicit derivative of a connector?

    I think the answers to a) and b) should be yes. This should be clearly described in the spec.
    In principal the answer to c) could also be yes but I think that is a bad idea since the connector is definitely not meant to be used as a general purpose component. I feel this should actually be explicitly prohibited by the spec.

  • Reported: Untriaged — Mon, 12 Dec 2011 05:00 GMT
  • Updated: Fri, 16 Aug 2019 16:08 GMT
  • Attachments:

Page: 56..64

  • Key: INBOX-890
  • Status: pending  
  • Source: Proekspert ( Ahti Legonkov)
  • Summary:

    C++ as a language is not just the core language but also STL that accompanies with it. There are lots of useful algorithms in STL, but they are not very easily used with the C++ mappings of CORBA Sequences. Step closer to this usability would be to add a member typedef that would tell the type of items the sequence contains - this would allow implementing an STL iterator compliant types more easily. And really nice thing would be if the mapping would have begin() and end() functions like STL containers do.

  • Reported: Untriaged — Wed, 26 Oct 2005 04:00 GMT
  • Updated: Fri, 16 Aug 2019 16:07 GMT
  • Attachments:

Typos in section 3.1.6.4.1

  • Key: INBOX-660
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.6.4.1 still talks about operations that no longer exist (how_many_added, how_many_removed, etc). In the second bullet these operations are mentioned. It is our suggestion to remove the mention of those operations, and simply state that there are operations to retrieve precisely which parts of the object has been modified, but don't mention explicitly which operations are available for this purpose.

    Solution:
    Replace:
    o Then all the updates are actually applied in the cache16. When an object is modified, several operations allow to get more precisely which parts of the object are concerned (see ObjectRoot::is_modified operations as well as the operations for Collection, namely, is_modified, how_many_added, how_many_removed, removed_values, and which_added); these operations can be called in the listeners.
    With:
    o Then all the updates are actually applied in the cache16. When an object is modified, several operations allow to get more precisely which parts of the object are concerned, such operations can be called in the listeners.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:52 GMT
  • Attachments:

which_contained_modified operation should be removed

  • Key: INBOX-659
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The which_contained_modified operation should be removed from the table on page 3-33 as well as from the text description on page 3-35, as the operation no longer exists (see figure 3-4). Getting the modified elements from collections can be done through the relevant collection interface operation (added_elements, modified_elements and removed_elements). In the IDL description in section 3.2.1.2 on page 3-50 the enum RelationKind, valuetype RelationDescription and it's derived valuetypes ListRelationDescription, IntMapRelationDescription and StrMapRelationDescription as well as the sequence typedef for RelationDescriptions should be removed.

    Solution:
    Remove the which_contained_modified operation from the table and remove the following text (at the top of page 3-35)
    o get which contained objects have been modified (which_contained_modified). This method returns a list of descriptions for the relations that point to the modified objects (each description includes the name of the relation and if appropriate the index or key that corresponds to the modified contained object).

    On page 3-50 in section 3.2.1.2 remove the following:
    enum RelationKind

    { REF_RELATION, LIST_RELATION, INT_MAP_RELATION, STR_MAP_RELATION}

    ;
    valuetype RelationDescription

    { public RelationKind kind; public RelationName name; }

    ;
    valuetype ListRelationDescription : RelationDescription

    { public long index; }

    ;
    valuetype IntMapRelationDescription : RelationDescription

    { public long key; }

    ;
    valuetype StrMapRelationDescription : RelationDescription

    { public string key; }

    ;
    typedef sequence<RelationDescription> RelationDescriptionSeq;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:52 GMT
  • Attachments:

Typos in section 3.1.6.6

  • Key: INBOX-658
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The section 3.1.6.6 regarding generated classes contains many typos. It mentions the FooQuery class to be generated, but that is no longer the case! The queryCriterion class is all that is needed for query filters. In the Implied IDL on page 3-60, section 3.2.1.2.2 the local interface for Fooquery should be removed as well!
    It also mentions a FooRelation class, which no longer exists, and names the collection types incorrectly (FooListRelation should simply be FooList), etc.
    It also forgets to mention the FooSet class and the Foo class itself.

    Solution:
    Replace:
    Assuming that there is an application class named Foo (that will extend ObjectRoot), the following classes will be generated:
    o FooHome : ObjectHome
    o FooListener : ObjectListener
    o FooSelection : Selection
    o FooSelectionListener : SelectionListener
    o FooFilter : FilterCriterion
    o FooQuery : FooFilter, QueryCriterion
    o And for relations to Foo objects (assuming that these relations are described in the applicative mode - note also that the actual name of these classes will be indicated by the application):
    o "FooRelation" : RefRelation
    o "FooListRelation" : ListRelation
    o "FooStrMapRelation" : StrMapRelation
    o "FooIntMapRelation" : IntMapRelation
    With:
    Assuming that there is an application class named Foo (that will extend ObjectRoot), the following classes will be generated:
    o Foo: ObjectRoot
    o FooHome : ObjectHome
    o FooListener : ObjectListener
    o FooSelection : Selection
    o FooSelectionListener : SelectionListener
    o FooFilter : FilterCriterion
    o FooList : List
    o FooStrMap : StrMap
    o FooIntMap : IntMap
    o FooSet : Set

    On page 3-60 in section 3.2.1.2.2 remove:
    local interface FooQuery : DDS::QueryCriterion, FooFilter {
    };

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:51 GMT
  • Attachments:

Typos in section 3.1.6.4.3 & 3.1.6.4.4

  • Key: INBOX-657
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Sections 3.1.6.4.3 & 3.1.6.4.4 describe the sequence of listener triggers, they both state the selection listener is triggered first and then the object listeners. However this is not in correspondance with section 3.1.6.4.2, which states objectlisteners are triggered first!
    It's our suggestion to make everything uniform and let object listeners be triggered first and then selection listeners, as that sequence seems more logical. Naturally the paragraph of the selectionlistener should start with the word 'Then' instead of 'First' if they are swapped and vice virsa for the paragraph about ObjectListeners.

    Solution:
    Obvious

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:51 GMT
  • Attachments:

Typos in section 3.2.1.2 IDL description

  • Key: INBOX-656
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-48 and 3-49 for the definition of the ObjectListener the on_object_created and on_object_deleted operations are listed, however these operations are generated on the derived class 'Foo', thus should be contained within the comments just like operation on_object_modified. This was not correctly revised during the last spec revision.

    Solution:
    Replace:
    local interface ObjectListener

    { boolean on_object_created ( in ObjectRoot the_object); /**** will be generated with the proper Foo type* in the derived * FooListener * boolean on_object_modified ( * in ObjectRoot the_object); ****/ boolean on_object_deleted ( in ObjectRoot the_object); }

    ;
    With:
    local interface ObjectListener

    { /* Will be generated with the proper Foo type in the derived FooListener * * boolean on_object_modified (in ObjectRoot the_object); * boolean on_object_created (in ObjectRoot the_object); * boolean on_object_deleted (in ObjectRoot the_object); */ }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:51 GMT
  • Attachments:

section 3.2.1.2 IDL description on page 3-52

  • Key: INBOX-655
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-52 the criterion attribute of the Selection interface is incorrectly defined within the comments section. It should simply be listed as an attribute, as it wont be generated in the specialized FooSelection. In the implied IDL in section 3.2.1.2.2 on page 3-60 a wrong attribute is stated as well (filter attribute, it should be removed).

    Solution:

    In section 3.2.1.2 IDL description on page 3-52 replace (only the beginning of the interface definition is shown):
    local interface Selection {
    // Attributes
    // ----------
    readonly attribute boolean auto_refresh;
    readonly attribute boolean concerns_contained;
    /***

    • Following attributes will be generated properly typed
    • in the generated derived classes
      *
      readonly attribute SelectionCriterion criterion;
      readonly attribute ObjectRootSeq members;
      readonly attribute SelectionListener listener;
      *
      */

    With:
    local interface Selection {
    // Attributes
    // ----------
    readonly attribute boolean auto_refresh;
    readonly attribute boolean concerns_contained;
    readonly attribute SelectionCriterion criterion;

    /* The following attributes will be generated properly typed

    • in the generated derived classes
      *
    • readonly attribute ObjectRootSeq members;
    • readonly attribute SelectionListener listener;
      */

    In the implied IDL in section 3.2.1.2.2 on page 3-60 replace:
    local interface FooSelection : DDS::Selection

    { readonly attribute FooFilter filter; readonly attribute FooSeq members; readonly attribute FooSelectionListener listener; FooSelectionListener set_listener ( in FooSelectionListener listener); }

    ;
    With:
    local interface FooSelection : DDS::Selection

    { readonly attribute FooSeq members; readonly attribute FooSelectionListener listener; FooSelectionListener set_listener ( in FooSelectionListener listener); }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:50 GMT
  • Attachments:

section 3.2.2.3.2.13 MultiRelation, 3rd bullet

  • Key: INBOX-654
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    In section 3.2.2.3.2.13 MultiRelation, the 3rd bullet states a valueKey sub-tag, which does not exist! It should be keyDescription instead!

    Solution:
    Replace:
    This tag gives the mapping for a multi-valued relation. It has:
    o A mandatory attribute to give the name of the relation.
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic - see Section 3.2.2.3.2.11).
    o One valueKey sub-tag (see Section 3.2.2.3.2.12).
    With:
    This tag gives the mapping for a multi-valued relation. It has:
    o A mandatory attribute to give the name of the relation.
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic - see Section 3.2.2.3.2.11).
    o One keyDescription sub-tag (see Section 3.2.2.3.2.12).

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:50 GMT
  • Attachments:

Typos in section 3.2.1.2 IDL description

  • Key: INBOX-653
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2 IDL description on page 3-49 for the definition of the SelectionListener the on_object_out operation is listed, however this operation is generated on the derived class 'Foo', thus should be contained within the comments just like operations on_object_modified and on_object_in. This was not correctly revised during the last spec revision.

    Solution:
    Replace:
    local interface SelectionListener

    { /* Will be generated with the proper Foo type * in the derived FooSelectionListener * void on_object_in ( in ObjectRoot the_object); void on_object_modified ( in ObjectRoot the_object); * ***/ void on_object_out ( in ObjectRoot the_object); }

    ;

    With:
    local interface SelectionListener

    { /* Will be generated with the proper Foo type in the derived FooSelectionListener * * void on_object_in (in ObjectRoot the_object); * void on_object_modified (in ObjectRoot the_object); * void on_object_out (in ObjectRoot the_object); */ }

    ;

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:49 GMT
  • Attachments:

section 3.2.1.2.2 Implied IDL

  • Key: INBOX-652
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2.2 Implied IDL, typo in the FooHome defintion for the create_selection operation. The parameters listed are incorrect. They should be DDS::SelectionCriterion criterion instead of FooFilter filter. And the concerns_contained_objects attribute is missing all together. Furthermore the raises clause is wrong as well, the BadParameter exception did not exist in that definition of the specification, it should be PreconditionNotMet.

    Solution:
    Replace:
    FooSelection create_selection (
    in FooFilter filter,
    in boolean auto_refresh)
    raises (DDS::BadParameter);
    With:
    FooSelection create_selection (in DDS::SelectionCriterion criterion, in boolean auto_refresh, in boolean concerns_contained_objects) raises (DDS::PreconditionNotMet);

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:49 GMT
  • Attachments:

In section 3.2.2.3.2.11 MultiAttribute.

  • Key: INBOX-651
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The description in section 3.2.2.3.2.11 MultiAttribute still refers to the indexField attribute of the MultiPlaceTopic as being mandatory. This is wrong, it is defined as an implied attribute in IDL.

    Solution:
    Replace:
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic). This sub-tag follows the same pattern as placeTopic, except it has a mandatory attribute in addition to state the field needed for storing the collection index.
    With:
    o A mandatory sub-tag to give the DCPS Topic where it is placed (multiPlaceTopic). This sub-tag follows the same pattern as placeTopic, except it has an optional attribute in addition to state the field needed for storing the collection index, which should be used if the collection is a List or Map type.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:48 GMT
  • Attachments:

In section 3.2.2.3.2.11 MultiAttribute, the example xml code

  • Key: INBOX-650
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The example XML code forgets to properly fill out the multiPlaceTopic, forgetting to list the index attribute of the multiPlaceTopic. Also the content attribute of the keyDescription has an incorrect value. It should be FullOid, not FullOID (cases).

    Solution:

    Replace:
    <multiAttribute name="comments">
    <multiPlaceTopic name="COMMENTS-TOPIC"
    <keyDescription content="FullOID">
    <keyField>CLASS</keyField>
    <keyField>OID</keyField>
    </keyDescription>
    </multiPlaceTopic>
    <valueField>COMMENT</valueField>
    </multiAttribute>
    With:
    <multiAttribute name="comments">
    <multiPlaceTopic name="COMMENTS-TOPIC" indexField="INDEX">
    <keyDescription content="FullOid">
    <keyField>CLASS</keyField>
    <keyField>OID</keyField>
    </keyDescription>
    </multiPlaceTopic>
    <valueField>COMMENT</valueField>
    </multiAttribute>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:48 GMT
  • Attachments:

section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation

  • Key: INBOX-649
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.2.3.2.10 MonoAttribute, 3.2.2.3.2.12 MonoRelation the cases for the content attributes values of the keyDescription is incorrect

    Solution:
    In section 3.2.2.3.2.10 on page 3-67 replace:
    <monoAttribute name="y">
    <placeTopic name="Y_TOPIC">
    <keyDescription content="SimpleOID">
    <keyField>OID</keyField>
    </keyDescription>
    </placeTopic>
    <valueField>Y</valueField>
    </monoAttribute>
    With:
    <monoAttribute name="y">
    <placeTopic name="Y_TOPIC">
    <keyDescription content="SimpleOid">
    <keyField>OID</keyField>
    </keyDescription>
    </placeTopic>
    <valueField>Y</valueField>
    </monoAttribute>

    In section 3.2.2.3.2.12 on page 3-68 replace:
    <monoRelation name="a_radar">
    <keyDescription content="SimpleOID">
    <keyField>RADAR_OID</keyField>
    </keyDescription>
    </monoRelation>
    With:
    <monoRelation name="a_radar">
    <keyDescription content="SimpleOid">
    <keyField>RADAR_OID</keyField>
    </keyDescription>
    </monoRelation>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:47 GMT
  • Attachments:

Figure 3-4 and section 3.2.1.2.2 Implied IDL

  • Key: INBOX-648
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The find_object operation is not listed in the ObjectHome class in figure 3-4 on page 3-16.

    Solution:
    Obvious

    Problem:
    In section 3.2.1.2.2 Implied IDL, typos in the FooHome defintion for the find_object_in_access. The operation no longer exists. The find_object operation is missing a parameter as well

    Solution:

    Replace:
    Foo find_object_in_access (in DDS::DLRLOid oid, in DDS::CacheAccess access)
    raises (DDS::NotFound);
    Foo find_object (in DDS::DLRLOid oid);
    With:
    Foo find_object (in DDS::DLRLOid oid, in DDS::CacheBase source);

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:47 GMT
  • Attachments:

In section 3.2.3.5 Code example, several typos

  • Key: INBOX-647
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.3.5 Code example on page 3-74 and 3-75 several typos can be found. It talks about a DLRL module, which should be DDS in the definition of the CacheFactory variable and Cache variable.
    The create_cache operation is missing a parameter (cache name).
    The home objects should have their default constructors called.
    The create_object operations sometimes has a - as seperator instead of a _.
    The create_object should take a cache access as parameter instead of the cache, this cache access should also be created.
    The write operation should be performed on the created cache access, not on the cache.
    The closing }; should also be removed, as it is never opened.
    The setter operation for the operations are also incorrect. They should be set_x, not x. And the relation has a put operation which does not exist.
    The first setter for the a_radar attribute should operate on t1, not t2.

    Solution:

    Replace:
    DDS::DomainParticipant_var dp;
    DLRL::CacheFactory_var cf;
    /*

    • Init phase
      */
      DLRL::Cache_var c = cf->create_cache (WRITE_ONLY, dp);
      RadarHome_var rh;
      TrackHome_var th;
      Track3DHome_var t3dh;
      c->register_home (rh);
      c->register_home (th);
      c->register_home (t3dh);
      c->register_all_for_pubsub();
      // some QoS settings if needed
      c->enable_all_for_pubsub();
      /*
    • Creation, modifications and publication
      */
      Radar_var r1 = rh->create_object(c);
      Track_var t1 = th->create-object (c);
      Track3D_var t2 = t3dh->create-object (c);
      t1->w(12);// setting of a pure local attribute
      t1->x(1000.0);// some DLRL attributes settings
      t1->y(2000.0);
      t2->a_radar->put(r1);// modifies r1->tracks accordingly
      t2->x(1000.0);
      t2->y(2000.0);
      t2->z(3000.0);
      t2->a_radar->put(r1);// modifies r1->tracks accordingly
      c->write();// all modifications are published
      };
      With:
      DDS::DomainParticipant_var dp;
      DDS::CacheFactory_var cf;
      /*
    • Init phase
      */
      DDS::Cache_var c = cf->create_cache ("a_cache", WRITE_ONLY, dp);
      RadarHome_var rh = new RadarHome();
      TrackHome_var th = new TrackHome();
      Track3DHome_var t3dh = new Track3DHome();
      c->register_home (rh);
      c->register_home (th);
      c->register_home (t3dh);
      c->register_all_for_pubsub();
      // some QoS settings if needed
      c->enable_all_for_pubsub();
      /*
    • Creation, modifications and publication
      */
      DDS:CacheAccess_var ca = c->create_access(WRITE_ONLY);
      Radar_var r1 = rh->create_object(ca);
      Track_var t1 = th->create_object (ca);
      Track3D_var t2 = t3dh->create_object (ca);
      t1->w(12);// setting of a pure local attribute
      t1->set_x(1000.0);// some DLRL attributes settings
      t1->set_y(2000.0);
      t1->set_a_radar(r1);// modifies r1->tracks accordingly
      t2->set_x(1000.0);
      t2->set_y(2000.0);
      t2->set_z(3000.0);
      t2->set_a_radar(r1);// modifies r1->tracks accordingly
      ca->write();// all modifications are published
  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:47 GMT
  • Attachments:

Section 3.2.1.1 Mapping Rules regarding error reporting

  • Key: INBOX-646
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Section 3.2.1.1 Mapping Rules regarding error reporting states that an exception is only raised when future behavior is affected

    This is not exactly the case: Exceptions are also thrown when unrecoverable errors have occurred.

    Solution:
    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:46 GMT
  • Attachments:

section 3.2.2.3.2.13 MultiRelation - XML code

  • Key: INBOX-645
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.2.3.2.13 MultiRelation, the xml code still talks about a FullSimpleOID, it should be FullOid. The case is also wrong for the SimpleOid

    Solution:
    Replace:
    <multiRelation name="tracks">
    <multiPlaceTopic name="RADARTRACKS-TOPIC"
    <keyDescription content="SimpleOID">
    <keyField>RADAR-OID</keyField>
    </keyDescription>
    <\multiPlaceTopic>
    <keyDescription content="FullSimpleOID">
    <keyField>TRACK-CLASS</keyField>
    <keyField>TRACK-OID</keyField>
    </keyDescription>
    </multiRelation>
    With:
    <multiRelation name="tracks">
    <multiPlaceTopic name="RADARTRACKS-TOPIC"
    <keyDescription content="SimpleOid">
    <keyField>RADAR-OID</keyField>
    </keyDescription>
    <\multiPlaceTopic>
    <keyDescription content="FullOid">
    <keyField>TRACK-CLASS</keyField>
    <keyField>TRACK-OID</keyField>
    </keyDescription>
    </multiRelation>

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:46 GMT
  • Attachments:

Inconsistency in attribute definitions for valuetype ObjectRoot

  • Key: INBOX-644
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    On Section 3.2.1.2 on page 3-51 regarding valuetype ObjectRoot contains the attribute class_name, but it is missing in figure 3-4 and in the ObjectRoot description in the entity listings. It should either be removed from IDL, or be added to the PIM.

    Solution:
    We propose to remove it from the IDL since, it can also be obtained through the related home: on Section 3.2.1.2 on page 3-51 regarding valuetype ObjectRoot remove:
    readonly attribute ClassName class_name;

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:45 GMT
  • Attachments:

Figure 3-4 on page 3-16 is missing some operations in some classes

  • Key: INBOX-643
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The find_object operation is not listed in the ObjectHome class in figure 3-4 on page 3-16.

    Solution:
    Obvious

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:45 GMT
  • Attachments:

Give each CacheAccess its own Publisher and DataWriters

  • Key: INBOX-642
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    If one of the purposes of the CacheAccess is to separate sets of objects that are being manipulated by different threads from eachother, then it makes sense to also give them a separate Publisher. Otherwise different threads might try to write different coherent sets of information using the same DataWriters at the same time, thus mixing up two separate coherent sets as one big chunk. Also with respect to tailoring QoS settings the modifying threads might influence each-other.

    Solution:

    Giving each CacheAccess its own Publisher and DataWriters allows you to completely separate each thread of modification. Coherent Sets that are being written always have exactly the right coherence scope, and it is possible to have different CacheAccess objects for different purposes: for example one CacheAccess to write the objects reliably, another one to send them with best-effort.

    Creating a CacheAccess then implicitly creates a Publisher and all the required DataWriters for all ObjectHomes attached to the main Cache, using the same QoS settings as the writers already attached to the main Cache. To allow the user of a CacheAccess to tailor these QoS-settings, all these DCPS entities should be created in a disabled state. That means that the CacheAccess would require a new operation called 'enable' to enable them all. Also it means that since the CacheAccess will have its own Publisher, the 'the_publisher' attribute can be moved from the Cache to the CacheBase interface.

    Question is why a Cache still requires a Publisher if you are only allowed to write information from a CacheAccess. We see no reason why a Cache could not be used to write information as well: there are sufficient mechanisms available in DLRL to prevent manual modifications being overwritten by automatic updates: one could disable the automatic updates for this purpose, or one could do the modification during a listener callback, thus blocking new updates from being applied. Also for a WriteOnly application it makes sense to have a writeable Cache. We therefore also propose to move the write operation from the CacheAccess to the CacheBase class and to change the CacheAccess parameter in the create_object and create_unregistsred_object operations into a CacheBase operation.

    TBD.

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:44 GMT
  • Attachments:

use case for multiple valueFields

  • Key: INBOX-641
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    The DTD , the monoAttribute and multiAttribute elements allow multiple valueField elements to be specified inside them. It is not explained for which use-cases something like that would be convenient.

    Solution:

    In case the attribute is a struct, it could be used to map it directly onto multiple value Fields in the topic using the order in which the members of the struct are mentioned. (However, for such cases it might be better to map each struct member individually using its scoped name to avoid confusion.) It could also make sense to use it for elements inside an array.

    However, the exact use-case for which this is allowed should be mentioned explicitly, referably with good examples.

    TBD.

  • Reported: DDS 1.2 — Thu, 15 Feb 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:44 GMT
  • Attachments:

A descriptive name

  • Key: INBOX-640
  • Status: pending  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    The following IDs can be used in PT issue IDs:
    TYPO = To reflect the issue is about a type in the specification
    CLAR = To reflect the issue clarifies something in the specification
    ARCH = To reflect the issue highlights an architectural significant problem in the specification.

  • Reported: DDS 1.2 — Mon, 5 Mar 2007 05:00 GMT
  • Updated: Mon, 12 Feb 2018 19:43 GMT
  • Attachments:

Specify names of mono-relation and multi-relation fields for default mappin

  • Key: INBOX-639
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    In section 8.1.4.3, add:

    o For a mono-relation called "bar", the mono-relation's oid fields are "bar_class" and "bar_oid".

    o For a multi-relation, the related object's oid and class fields are "value_oid" and "value_class".

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 12 Feb 2018 19:42 GMT
  • Attachments:

create_object and create_unregistered_object

  • Key: INBOX-638
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    DDS DLRL Issue: create_object and create_unregistered_object should
    throw PreconditionNotMet if keyType is incompatible Section 8.1.6.3.7, ObjectHome, add the following to these method descriptions:

    create_object: "The method throws a PreconditionNotMet if the Home is a NoOid Home"

    create_unregistered_object:"The method throws a PreconditionNotMet if the Home is a FullOid or SimpleOid Home"

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 12 Feb 2018 19:41 GMT
  • Attachments:

clarify behavior of content_filters in an inheritance hierarchy

  • Key: INBOX-637
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Add the following to 8.1.6.3.7, ObjectHome::set_content_filter:

    "An object must pass all content filters in its Home and its base Homes to be accepted into the Cache"

  • Reported: DDS 1.2 — Wed, 9 May 2007 04:00 GMT
  • Updated: Mon, 12 Feb 2018 19:40 GMT
  • Attachments:

typo to be corrected: External Interface File (EIF)]

  • Key: INBOX-367
  • Status: pending  
  • Source: Allasia ( Walter)
  • Summary:

    Bracket "]" at the end to be removed
    Definition of EIF: External Interface File (EIF)]

  • Reported: AFP 1.0 — Thu, 15 Dec 2016 15:04 GMT
  • Updated: Mon, 25 Sep 2017 14:38 GMT
  • Attachments:

Typo (missing article)

  • Key: INBOX-327
  • Status: pending  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    Sentence 2: Change: "is very common task" to "is a very common task".

  • Reported: NIEM-UML 3.0 FTF — Mon, 26 Sep 2016 19:16 GMT
  • Updated: Mon, 25 Sep 2017 14:37 GMT
  • Attachments:

Introduce the clear() operation on the Collection interface.

  • Key: INBOX-170
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It would be convient to have a clear() operation on the collection interface which simply removes all elements from the collection (does not effect added/modified/deleted _elements operations results…). While we are at it, remove the type in the table stating there are no attributes as well (since two attributes are listed!!).

    Solution:
    Replace:
    Collection
    no attributes
    length integer
    values Undefined [] (e.g. of type ObjectRoot or Primitive type)

    It provides the following attributes:
    o length - the length of the collection.
    o values - a list of all values contained in the Collection.

    With:
    Collection
    attributes
    length integer
    values Undefined [] (e.g. of type ObjectRoot or Primitive type)
    operations
    clear void

    It provides the following attributes:
    o length - the length of the collection.
    o values - a list of all values contained in the Collection.

    It provides the following methods:
    · clear - to clear the contents of the Collection, does not affect the added_elements, modified_elements, deleted_elements results. If the object this Collection belongs to is not registered or does not belong to a (writeable) CacheAccess a PreconditionNotMet is raised

    In the IDL description on page 3-55 add the following to the abstract valuetype Collection:
    void clear() raises(PreconditionNotMet);

    In figure 3-4 on page 3-16 the clear() operation should be added to the operation listing of class Collection

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add an attribute to get the home_index

  • Key: INBOX-202
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It would be convient (and performance reasons desirable) to get the index of the home associated with an ObjectRoot in one call, this would especially be usefull in combination with the contained_types operation on the CacheAccess.

    Solution:
    Add the following row to the attributes listing of the ObjectRoot directly following the row for attribute owner:
    home_index integer

    Add the following description to the list of description for attributes on page 3-21 directly following the description of attribute owner:
    o the index (home_index) under which it's related ObjectHome is registered to the Cache
    On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the attribute description:
    readonly long home_index;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Describe exact behaviour of compositions and associations in the DLRL.

  • Key: INBOX-183
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It is possible to annotate certain relations in the XML as being compositions and/or associations. Section 3.1.3.2.2 briefly describes how such relationships should behave. However, although it is possible to enforece constraints on certain relationships on the writer side, it is not possible to enforece them on the reader side. Especially not since the constraints are part of the 'local' object model, while the topics sould have been written by somebody with another 'local' model where these constraints are not enforced.
    What should happen to a composition relation where multiple objects claim possession of the same compound object? Or to an association where the associated object does not refer back to the object that associates it?

    Solution:

    In our opinion these constraints can only be enforced in the local object model, not on the entire system. (Unless of course the entire system shares the same object model). Because of this we propose to enforece these constraints only on the writer side of the DLRL: when objects in a writeable CacheAccess are modified and do not adhere to these constraints, the write operations will raise an InvalidObjects (See also issue PT-DLRL-ARCH-0008).

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

objects instances in a writeable CacheAccess

  • Key: INBOX-162
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    When should objects instances in a writeable CacheAccess be regsitered to the DataWriter? Upon entrance into the writeable CacheAccess or only when actually performing the write operation. This choice may impact ownership matters. Same question for newly created objects in a CacheAccess: when should they be registered?

    Solution:

    Our proposal is to only register any changes during the write operations, otherwise overhead is very heavy when cloning a large tree of Objects into a writeable CacheAccess. Probably most of these objects will not become modified and then doing a register upon entrance of each instance might result in huge numbers of unnecessary register messages.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Selection should have a non-listener way of obtaining the members

  • Key: INBOX-227
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    The only way to find out which objects were inserted into/modified in/removed from a Selection is by attaching a SelectionListener to that Selection and by processing the callbacks on these events. However, there should also be a way to obtain this information without having to resort to Listeners.

    Solution:

    Add operations to the Selection that return a list of objects that are inserted into/modified in/removed from that Selection.

    Section 3.1.6.2, Figure 3-4: Add 3 operations to the Selection called "get_inserted_members", "get_modified_members" and get_removed_members".

    Section 3.1.6.3.9: Add the following entry to the table:
    Selection
    operations
    get_inserted_members <undefined>[]
    get_modified_members <undefined>[]
    get_removed_members <undefined>[]

    Section 3.1.6.3.9
    Add:

    · get_inserted_members returns all objects that entered the Selection in the current update round.
    · get_modified_members returns all objects still belonging to the Selection whose content has changed in the current update round.
    · get_removed_members returns all objects that exited the Selection in the current update round.

    Section 3.2.1.2.1: In the following lines of the Generic IDL of the Selection interface:
    Replace:

    /***

    • Following method will be generated properly typed
    • in the generated derived classes
      *
      SelectionListener set_listener (
      in SelectionListener listener);
      *
      ***/

    With:

    /***

    • Following method will be generated properly typed
    • in the generated derived classes
      *
      SelectionListener set_listener (in SelectionListener listener);
      ObjectRootSeq get_inserted_members ( );
      ObjectRootSeq get_modified_members ( );
      ObjectRootSeq get_removed_members ( );
      *
      ***/

    Section 3.2.1.2.2: In the Implied IDL of the FooSelection interface add the following lines:

    FooSeq get_inserted_members ( );
    FooSeq get_modified_members ( );
    FooSeq get_removed_members ( );

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The classname in FullOid makes no sense in case of a 'local' Object model

  • Key: INBOX-186
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    When using a keyDescription set to "FullOid" in the XML mapping file, each OID field is accompanied by a class-name field that represents the actual type of a specific object instance (i.e. the name of the class that that object instance was instantiated to.)
    However, in case of a purely 'local' object model, this class name has no meaning outside the scope of the application that uses this local model. If the topics used for transport are also mapped to another 'local' object model, you get a confusing mix of local and global information in the same topic. This sort of confusion should be avoided at all costs: topics may only transport information that refers to the global information model, not to some local representation of it.

    Solution:

    Either allow the FullOid tag to only be used in case of a 'global' object model (default mapping, topic model is generated to match it), or describe that the class-name should not represent the name of a 'local' DLRL class, but rather the name of the topic that represents the state of that 'local' class.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

non-existing elements

  • Key: INBOX-133
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It is not clear what will happen when someone tries to obtain or remove a non-existing element from a Collection type (i.e. use the get/remove operation with a non-existing key/index). The NoSuchElement Exception was meant for that purpose.

    Solution:

    Explicitly mention the siutuations in which the NoSuchElement exception will be raised.

    Section 3.1.6.3.16
    Replace:

    · "remove - to remove the item with the highest index from the collection.
    · "get - to retrieve an item in the collection (based on its index).

    With:

    · remove - to remove the item with the highest index from the collection. If the List is already empty, a NoSuchElement is raised.
    · get - to retrieve an item in the collection (based on its index). If the specified index is greater than or equal to the length of the List, a NoSuchElement is raised.

    Section 3.1.6.3.17
    Replace:

    · "remove - to remove an element from the Set. If the specified element is not contained in the Set, the operation is ignored.

    With:

    · remove - to remove an element from the Set. If the specified element is not contained in the Set, a NoSuchElement is raised.

    Section 3.1.6.3.18 AND 3.1.6.3.19
    Replace:

    · "remove - to remove an item from the collection.
    · "get - to retrieve an item in the collection (based on its key).
    With:

    · remove - to remove an item from the collection. If no item matches the specified key, a NoSuchElement is raised.
    · get - to retrieve an item in the collection (based on its key). If no item matches the specified key, a NoSuchElement is raised.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Cache

  • Key: INBOX-166
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It is not clear whether it is allowed to create a CacheAccess when the Cache is not yet in enabled mode. Since the CacheAccess is not usable until the Cache is enabled, it makes sense not to allow the creation of a CacheAccess in that case.

    Solution:

    Make clear that a PreconditionNotMet is raised when a CacheAccess is created in a Cache that is not yet enabled.

    Section 3.1.6.3.4
    Replace:

    The purpose of the CacheAccess must be compatible with the usage mode of the Cache: only a Cache that is write-enabled can create a CacheAccess that allows writing. Violating this rule will raise a PreconditionNotMet:

    With:

    The Cache must have its pubsub_state set to ENABLED before it is allowed to create a CacheAccess. Furthermore, the purpose of the CacheAccess must be compatible with the usage mode of the Cache: only a Cache that is write-enabled can create a CacheAccess that allows writing. Violating any of these rules will raise a PreconditionNotMet.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

(last) end_updates call on CacheListeners

  • Key: INBOX-155
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It is currently not clear that the modification states are cleared after the last call to the CacheListener (multiple cache listeners may be registered!). This should be clarified.

    Solution:
    Replace:
    o Finally all the CacheListener::end_updates operations are triggered and the modification states of the updated objects is cleaned; the order in which these listeners are triggered is not specified.

    With:
    o Finally all the CacheListener::end_updates operations are triggered and the modification states of the updated objects is cleaned after the last CacheListener::end_updates has been triggered; the order in which these listeners are triggered is not specified.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The generated class FooImpl is not mentioned in the implied idl

  • Key: INBOX-167
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.2.1.2.2 Implied IDL add directly after the definition of the Foo valuetype:

    valuetype FooImpl : Foo

    { //place for application to implement application defined operations // (operations signature known at Foo level!) }

    ;

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The Implied IDL needs to be extended with attribute examples for class Foo

  • Key: INBOX-188
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In the implied IDL section 3.2.1.2.2 on page 3-59 it shows what classes/operation are generated for a fictional type Foo. However this example is too simplistic, it would be helpful to extend the example for valuetype Foo, so that the valuetype contains one simple attribute, one simple key field attribute and one mono relation and one multi relation, as an example to what methods are generated because of such attributes.

    Our suggestion is to add the following attributes to the Foo class:
    public long x; //keyfield of the underlying topic
    public long y;
    public Bar a_bar;
    public BarSet bars;

    The Bar class itself is left out of consideration for the example.

    Solution:
    Replace:
    This section contains the implied IDL constructs for an application-defined class named
    Foo.
    #include "dds_dlrl.idl"
    valuetype Foo: DDS::ObjectRoot

    { // some attributes and methods }

    ;
    With:
    This section contains the implied IDL constructs for an application-defined class named
    Foo. For example purposes several attributes are defined on Foo. Namely:
    · public long x (keyfield of the underlying Foo topic)
    · public long y (a regular field)
    · public Bar a_bar (mono relation to a Bar DLRL object)
    · public BarSet bars (multi relation of Bar DLRL objects)
    The related Bar classes are not worked out in the implied IDL, but just mentioned as forward valuetype defintions.
    #include "dds_dlrl.idl"

    //forward declarations of Bar and it's helper classes. Bar itself is not worked out
    //in the implied IDL
    valuetype Bar;
    valuetype BarSet;

    valuetype Foo: DDS::ObjectRoot

    { //getter methods for all attributes long get_x(); long get_y(); Bar get_a_bar() raises (DDS::NotFound); BarSet get_bars(); //setter methods for all attributes void set_x(long val) raises (DDS::PreconditionNotMet); void set_y(long val) raises (DDS::PreconditionNotMet); void set_a_bar(Bar val) raises (DDS::PreconditionNotMet); void set_bars(BarSet val) raises (DDS::PreconditionNotMet); //is_xxx_modified methods for all attributes boolean is_x_modified(); boolean is_y_modified(); boolean is_a_bar_modified(DDS::ReferenceScope scope); boolean is_bars_modified(DDS::ReferenceScope scope); }

    ;

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unregistered objects

  • Key: INBOX-205
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It is not clear what the read_state and write_state should be of an unregistered object.

    Solution:

    Set both states to VOID until the object gets registered.

    Section 3.1.6.3.7
    Replace:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet. An unregistered object has both its read_state and its write_state set to VOID, and may only be used to assign a unique combination of key-values to it. The object should be registered before anything else can be done with it.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typo in section 3.1.6.1.2.1

  • Key: INBOX-193
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The last sentence of section 3.1.6.1.2.1 is in conflict with section 3.1.6.3.4 which states that a missing object home (i.e. no subscription exists) raises a BadHomeDefinition (see details on the register_all_for_pubsub operation). Making navigation to an object for which no subscription exists impossible.

    The BadHomeDefinition option is superior, as it forces application developers to think about their local object model and remove relations they do not need, not only to object home they happened not to register, but also relations between object homes they have registered. The power of DLRL is in the fact each application can tailor the object model to it's own specific needs, removing relations from DLRL management which are simply not of any interest (this is a performance saver!).
    It's also undesirable to ignore missing object homes and just return a NotFound exception as it's not clear to an application developer that these exceptions are occuring because he forgot to register a home, the bad home definition makes things much more explicit, without a loss in flexibility.

    Solution:
    Replace:
    If a relation points towards an object for which no subscription exists, navigating through that relation will raise an error (NotFound).
    With:
    If a relation points towards an object for which no subscription exists, a BadHomeDefinition exception is raised when the Cache is registered for publication/subscription.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Typo in section 3.1.4.2.1

  • Key: INBOX-159
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.4.2.1 speaks of tables and rows, it is suggested to change this into topics and instances to correspond better with DCPS terminology.
    It is also suggested to speak of 'fields to uniquely identify the object' instead of 'fields needed to store a reference to that object'.
    It is also wise to change the word application in the last sentence of the last paragraph to implementation, as this mechanism is worked out by a DLRL implementation, not an application.

    Solution:

    Replace:
    Each DLRL class is associated with at least one DCPS table, which is considered as the 'main' table. A DLRL object is considered to exist if it has a corresponding row in this table. This table contains at least the fields needed to store a reference to that object (see below).

    To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main table as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension table. For example, this allows the application to load all the instances of a given class (including its derivations) in a single operation.

    With:
    Each DLRL class is associated with at least one DCPS topic, which is considered as the 'main' topic. A DLRL object is considered to exist if it has a corresponding instance in this topic. This topic contains at least the fields to uniquely identify the object (see below).

    To facilitate DLRL management and save memory space, it is generally desirable that a derived class has the same main topic as its parent concrete class (if any)5, with the attributes that are specific to the derived class in an extension topic. For example, this allows the implementation to load all the instances of a given class (including its derivations) in a single operation.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Need to clarify what is meant by "RELATED_OBJECTS"

  • Key: INBOX-108
  • Status: pending  
  • Source: Jackrabbit Consulting ( Mrs. Charlotte Wales)
  • Summary:

    Need to clarify what is meant by "RELATED_OBJECTS" – ObjectRoot has an is_modified method that takes a scope, OBJECT_ONLY, CONTAINED_OBJECTS and RELATED_OBJECTS. Whereas it is clear that OBJECT_ONLY means only attributes on this ObjectRoot and that CONTAINED_OBJECTS includes any changes to objects that this object refers to, it is not clear what RELATED_OBJECTS means.

  • Reported: DDS 1.1 — Fri, 14 Apr 2006 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.5 regarding the CacheListener clarify some things

  • Key: INBOX-210
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem (1/3):
    In the description for the on_begin_updates it says at the end '(assuming that updates_enabled is true)', which is a bit vague as to the context of that statement. Replace it with something like "This operation will only be triggered for a Cache which has updates_enabled set to true." That statement should also be added at the end of the on_end_updates operation.
    This clarification is required because the other two operations are not dependant on the state of the updates_enabled…

    Solution (1/3):
    Replace:
    o on_begin_updates indicates that updates are following. Actual modifications in the cache will be performed only when exiting this method (assuming that updates_enabled is true).
    o on_end_updates indicates that no more update is foreseen.

    With:
    o on_begin_updates indicates that updates are following. Actual modifications in the Cache will be performed only when exiting this method. This operation will only be triggered for a Cache which has updates_enabled set to true.
    o on_end_updates indicates that no more update is foreseen. This operation will only be triggered for a Cache which has updates_enabled set to true.

    Problem (2/3):
    The paragraph following the descriptions for all operations says: "In between, the updates ….". Since two new operations where added in the last spec revision this statement is now unclear. In between which operations? This should be clarified to state in between the on_begin_updates and on_end_updates.

    Solution (2/3):
    Replace:
    In between, the updates are reported on home or selection listeners. Section 3.1.6.4, "Listeners Activation," on page 3-41 describes which notifications are performed and in what order.
    With:
    In between the on_begin_updates and the on_end_updates calls the updates are reported on home or selection listeners. Section 3.1.6.4, "Listeners Activation," on page 3-41 describes which notifications are performed and in what order.

    Problem (3/3):
    The description for the on_updates_enabled and on_updates_disabled both start with a wrong quotation mark. It should be removed.

    Solution (3/3):
    Replace:
    o "on_updates_enabled - indicates that the Cache has switched to automatic update mode. Incoming data will now trigger the corresponding Listeners.
    o "on_updates_disabled - indicates that the Cache has switched to manual update mode. Incoming data will no longer trigger the corresponding Listeners, and will only be taken into account during the next refresh operation.
    With:
    o on_updates_enabled - indicates that the Cache has switched to automatic update mode. Incoming data will now trigger the corresponding Listeners.
    o on_updates_disabled - indicates that the Cache has switched to manual update mode. Incoming data will no longer trigger the corresponding Listeners, and will only be taken into account during the next refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions for enable_updates and disable_updates operations of Cac

  • Key: INBOX-230
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 for the descriptions of the enable and disable updates operation it should state a PreconditionNotMet is thrown if the cache is created with a usage of WRITE_ONLY. It should also state that multiple calls to the operations is considered a no-op. It should also be stated that calling the disable_updates operation results in all cache listeners being triggered with the on_updates_disabled call and for the enable the on_updates_enabled is called in scope of the thread making the call to enable or disable updates.

    Solution:

    Replace (see issue XXX(PT-DLRL-TYPO-0011) which already made changes to the disable_updates description):
    o disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account.

    o enable_updates causes the registered (and thus not applied) updates to be takeninto account, and thus to trigger the attached Listener, if any.

    With:
    o disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account. All registered CacheListeners will be triggered with the on_updates_disabled call (in scope of the thread calling the disable_updates operation) signaling, to any interested party, that updates on the Cache will no longer be automatically processed and no longer result in listener triggers. If the cache_usage of the Cache is WRITE_ONLY then a PreconditionNotMet is raised.

    o enable_updates causes the registered (and thus not applied) updates to be taken into account, and thus to trigger the attached CacheListeners, if any. All registered CacheListeners will be triggered before any updates are applied with the on_updates_enabled call (in scope of the thread calling the enabled_updates operation) signaling, to any interested party, that the updates on the Cache will be automatically processed and thus result in listener triggers. If the cache_usage of the Cache is WRITE_ONLY then a PreconditionNotMet is raised.

    In the IDL description in section 3.2.1.2 on page 3-58 replace:
    // — Updates management
    void enable_updates ();
    void disable_updates ();
    With:
    // — Updates management
    void enable_updates () raises (PreconditionNotMet);
    void disable_updates ()raises (PreconditionNotMet);;

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify text on page 3-35 directly following the operation descriptions.

  • Key: INBOX-207
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The text following the operation descriptions of the ObjectRoot on page 3-35 talks about state transitions taking place between the start of an update round and the end of an update round. This is confusing. It should state that state transitions are applied directly following the start of an update round and are cleared directly following the end of an update round.

    Solution:

    Replace:
    A Cache Object represents the global system state. It has a read_state whose transitions represent the updates as they are received by the DCPS. Since Cache Objects cannot be modified locally, they have no corresponding write_state (i.e. their write_state is set to VOID). State transitions occur between the start of an update round and the end of of an update round. When in automatic updates mode, the start of the update round is signaled by the invocation of the on_begin_updates callback of the CacheListener, while the end of an update round is signaled by the invocation of the on_end_updates callback of the CacheListener. When in manual update mode, the start of an update round is defined as the start of a refresh operation, while the end of an update round is defined as the invocation of the next refresh operation.

    With:
    A Cache Object represents the global system state. It has a read_state whose transitions represent the updates as they are received by the DCPS. Since Cache Objects cannot be modified locally, they have no corresponding write_state (i.e. their write_state is set to VOID). State transitions are applied directly following the start of an update round and are cleared directly following the end of an update round. When in automatic updates mode, the start of the update round is signaled by the invocation of the on_begin_updates callback of the CacheListener, while the end of an update round is signaled by the invocation of the on_end_updates callback of the CacheListener. When in manual update mode, the start of an update round is defined as the start of a refresh operation, while the end of an update round is defined as the invocation of the next refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.11 regarding the FilterCriterion clarify some things

  • Key: INBOX-175
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In the description for the check_object method is should state that the membership_state is optional in the sense that implementations of the spec may or may not use this parameter. If not used it always states an UNDEFINED_MEMBERSHIP state.

    Solution:

    Replace:
    o check if an object passes the filter - return value is TRUE - or not - return value is FALSE (check_object). This method is called with the first parameter set to the object to be checked and the second parameter set to indicate whether the object previously passed the filter (membership_state). The second parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is useful when the FilterCriterion is attached to a Selection to allow writing optimized filters.
    With:
    o check if an object passes the filter - return value is TRUE - or not - return value is FALSE (check_object). This method is called with the first parameter set to the object to be checked and the second parameter set to indicate whether the object previously passed the filter (membership_state). The second parameter (which is actually an enumeration with three possible values - UNDEFINED_MEMBERSHIP, ALREADY_MEMBER and NOT_MEMBER) is optional and may be useful when the FilterCriterion is attached to a Selection to allow writing optimized filters. The membership_state parameter has a default value of UNDEFINED_MEMBERSHIP in case the implementation does not support this option.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of create_cache operation

  • Key: INBOX-138
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The create_cache operation is responsible for creating a DCPS publisher and/or subscriber, depending on the cache usage. If this creation fails a DCPSerror should be thrown, the text should state this.
    It should also be stated that a cache is created by default with updated_enabled() returning false, forcing the application to explicitly enable the cache for updates. This prevents that the application immediately starts receiving updates after the enable_all_for_pubsub.

    It should also be clarified that the QoS settings on the participant determine if the publisher/subscriber will be created as enabled or disabled entities. IE if the QoS setting for autoenable_created_entities is set to true on the partcipant the Subscriber and Publisher are created in an enabled state, if set to false then both entities will be created in a disabled state.

    Solution:
    Replace:
    Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    With:
    Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant. If the creation of the Publisher and/or Subscriber required by the Cache fails a DCPSError is raised. The Cache is created with updates disabled by default (updates_enabled() returning false). The autoenable_created_entities QoS setting of the entity_factory of the passed DomainParticipant determines if the Publisher and/or Subscriber will be created in an enabled or a disabled state. If this QoS setting is set to true then these entities will be created in an enabled state, if set to false then these entities will be created in a disabled state. The Publisher and/or Subscriber themselves will always have their entity_factory.autoenable_created_entities QoS setting set to false, ensuring that DataWriter and DataReader entities are created in a disabled state, this setting may be overridden before the register_all_for_pubsub() call to the created Cache, which will result in the DataWriter and DataReader entities to be created as enabled entities, in this scenario updates will be received from the moment the register_all_for_pubsub is called, but can only be viewed after a call to the enable_all_for_pubsub.
    The creation of Topic entities during the register_all_for_pubsub is also slaved to the passed DomainParticipant's entity_factory.autoenable_created_entities QoS setting at the time the register_all_for_pubsub() is called.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Proposed Enhancement: allow QoS directly on a DLRL object type?

  • Key: INBOX-119
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It might be useful to allow QoS settings directly on a DLRL object type. For things like HISTORY, it would be a lot cleaner to apply QoS at the DLRL object type level (say, an object type and everything related to a certain depth) and let DLRL pass it through to DCPS.
    That way, the user doesn't need to know his application's DLRL-to-DCPS mapping – the same QoS application code could be used regardless of how the DLRL-to-DCPS mapping is configured. The user's QoS code wouldn't depend on the details of the application's mapping, which could change.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification of how to handle a dangling related object

  • Key: INBOX-120
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    How should dangling relationships be handled?

    For example, suppose I have a Foo->Bar relationship. My Foo has a related Bar.

    1. I clone the Foo and the Bar into the CacheAccess.
    2. Someone deletes the Bar, but does not update the Foo's relationship.
    3. I refresh the CacheAccess, which deletes my Bar in the CacheAccess, but my Foo thinks it's still related.

    What should happen when I call Foo.get_bar()?

    a. throw an exception? (NotFound? AlreadyDeleted?)
    b. return a NULL?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of cache_usage operation on the CacheBase, section 3.1.6.3.2

  • Key: INBOX-146
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The explanation of the cache usage only talks about the intent to support write operations. However if the usage is WRITE_ONLY there is no intent to support read operations, such as refresh as well. This should be stated as such.

    Solution:

    Replace:
    The cache_usage indicates whether the cache is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.

    With:
    The cache_usage indicates whether the cache is intended to support write operations only (WRITE_ONLY) or read operation only (READ_ONLY) or both read and write operation (READ_WRITE). This attribute is given at creation time and cannot be changed afterwards.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

PIM Spec should have separate tables for Foo types, like DCPS section does

  • Key: INBOX-130
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It would be helpful if the DLRL section's Platform-Independent Model broke out separate interface tables for its generated types, as the DCPS spec does with FooTypeSupport, FooDataReader, FooDataWriter, etc. This would enable the spec to clarify some slightly confusing tables, such as the table for a SelectionListener that shows on_object_in, on_object_out, and on_object_modified accepting an ObjectRoot parameter, when we really know it accepts a Foo. Breaking out a separate FooSelectionListener to demonstrate this would be useful, as it was for the DCPS section.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception?

  • Key: INBOX-129
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Can a CacheAccess::refresh() throw an AlreadyClonedInWriteMode exception?

    Suppose an object is cloned into a writable CacheAccess with scope=RELATED_OBJECTS and some depth >1. Now, suppose object2, which is unrelated, is cloned into a different writable CacheAccess.
    Then, suppose incoming updates cause object and object2 to be related, where a subsequent CacheAccess::refresh() would pull object2 into the first writable CacheAccess. But, wait, it's already in the other writable CacheAccess. Does that cause an exception on the refresh()?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification on interface of DLRL object with multi-attribute

  • Key: INBOX-126
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Does a Collection attribute have a setter?

    For example, suppose I have a Foo with a List<Long> in it (this isn't valid IDL, please humor me):

    valuetype Foo : DDS::ObjectRoot

    { public List<long> my_longs; }

    That generates a Foo::get_my_longs() in the target language. Should it also generate a Foo::set_my_longs() in the target language?

    Or should there simply be a Foo::get_my_longs(), and I modify the List<long> via add, put, etc?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification: what can you do with a deleted object?

  • Key: INBOX-125
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    If I have a handle on an object (such as a Foo), and the Foo is deleted from underneath me, I understand that I'll get an AlreadyDeleted exception if I try to do anything (call a setter or a getter) on the Foo.

    However, it seems like you should be able to get the OID and the read_state (which should be OBJECT_DELETED) from a deleted object. Can you? Can I call oid() and read_state() on a deleted object without getting an AlreadyDeleted exception?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Support local class in Mapping XML

  • Key: INBOX-213
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Currently the Mapping tags do not give any support for local classes, they mention local attributes but ignore locally defined valuetypes in the DLRL IDL, in default mapping these valuetypes would always lead to DCPS topics being generated from them.

    Solution:
    Make the local element a sub-tag of the dlrl tag as well. If the local tag is defined as sub-tag of the dlrl element, then the name should be fully qualified and refer to a class being 'local', if the local tag is a sub-tag of the classMapping element then it means the attribute is local and the name does not have to be fully qualified.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

set_query and set_parameters operation

  • Key: INBOX-161
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The set_query and set_parameters operation both have a return value of type boolean indicating success or not and an exception which is raised if an error was detected. Obviously one of the two is not neccesary, if an exception is raised then the return value is irrelevant and vice versa. So a choice needs to be made for one or the other. We propose to keep the exception as that is in line with other similar operation (set_content_filter on the ObjectHome for example). Also update the IDL description on page 3-52 in section 3.2.1.2.

    Solution:
    Change the return value of the set_query and set_parameter operations from boolean to void. And replace the following text:
    o set the value of the expression and its parameters (set_query); a TRUE return value indicates that they have been successfully changed.
    o set the values of the parameters (set_parameters). The number of parameters must fit with the values required by the expression. A TRUE return value indicates that they have been successfully changed.

    With:
    o set the value of the expression and its parameters (set_query). If the expression is not valid or if it's parameters do not match the number of parameters in the expression then a SQLError is raised.
    o set the values of the parameters (set_parameters). The number of parameters must fit with the values required by the expression, else a SQLError is raised.

    On page 3-52 in section 3.2.1.2 IDL description replace:
    boolean set_query (
    in string expression,
    in StringSeq parameters) raises (SQLError);
    boolean set_parameters ( in StringSeq parameters ) raises (SQLError);
    With:
    void set_query (in string expression, in StringSeq parameters) raises (SQLError);
    void set_parameters ( in StringSeq parameters ) raises (SQLError);

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Let the attach/detach listener operation return a boolean

  • Key: INBOX-220
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Change the return type of the attach_listener and detach_listener operation on the Cache entity to return a boolean instead of void. True indicates the operation was successfully (i.e. the listener was successfully attached or successfully removed). False indicates the operation was not successfully (i.e. the listener could not be attached, because it already was attached for the attach operation and for the detach operation it means the listener could not be detached because it was not attached in the first place.

    Solution:
    On page 3-22 in the table for section 3.1.6.3.4 replace:
    attach_listener void
    listener CacheListener
    detach _listener void
    listener CacheListener

    With:
    attach_listener boolean
    listener CacheListener
    detach _listener boolean
    listener CacheListener

    On page 3-23 for the description of the attach/detach listener add a sentence indicating the boolean return value and its meaning
    Replace:
    · attach/detach a CacheListener (attach_listener, detach_listener).

    With:
    · attach/detach a CacheListener, if the operation was successful true is returned and false if otherwise (attach_listener, detach_listener).

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add an operation to the Cache

  • Key: INBOX-154
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Currently when an application is interested in the creation/modification/deletion of specific objects, he can attach a Listener to the corresponding ObjectHome. We will then get separate callbacks for each object of this type that gets created/deleted/modified. But maybe the user doesn't want all these separate callbacks and just wants to deal with a subset of all possible events (for example only creations). He could do so by not attaching ObjectListeners to the ObjectHomes, but by using the CacheListener and then iterate through all Homes using for example only the get_created_objects. It would be nice if the Cache could then return a list of Homes that contain information that needs to be processed, to prevent the user from also having to iterate through all homes that have nothing to report.

    Solution:

    Add an operation to the Cache that returns a list of indexes for all homes that received updates in the current update round.

    Section 3.1.6.2, Figure 3-4: Add an operation to the Cache called "get_updated_home_indexes".

    Section 3.1.6.3.9: Add the following entry to the table:

    Cache
    operations
    get_updated_home_indexes integer[]

    Section 3.1.6.3.4
    Add:

    · retrieve the indexes of all ObjectHomes that received updates in the current update round (get_updated_home_indexes).

    Section 3.2.1.2: Add to the IDL of the Cache interface the following line:

    LongSeq get_updated_home_indexes( );

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

set_auto_deref, deref_all, underef_all operations

  • Key: INBOX-204
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The descriptions of the deref_all, underef_all and set_auto_deref should be stated to be implementation dependant, as these operations basically are only a standardized set of operations which can be used by DLRL applications to optimize the memory usage of the underlying DLRL implementation, but the exact affects and such are impossible to describe on specification level. And whether it is more efficient for an implementation to always load the states or do it on request basis is an implementation issue, so we would like to state for the mentioned three operation that the affects are implementation dependant.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify typical scenario for read mode of a CacheAccess in section 3.1.6.5.

  • Key: INBOX-157
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.5.1 it states the typical scenario for a cache access in read mode. But it would be nice if it was expand with a step between 4 and 5 which states that if desired new contracts can be created, existing contracts can be modified or deleted and step 3 can be repeated.

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section 3.1.3.1 on page 3-3

  • Key: INBOX-132
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.3.1 on page 3-3 states that a simple type may be a 'simple structure', a footnote explains that a simple structure may be a structure that can be mapped inside one DCPS data. But this is still very unclear, we would like to clarify what a simple structure is by changing the footnote to state:
    "A simple structure is a structure that only contains members of simple type"
    This must also be changed on page 3-5, the last line on the page.

    Furthermore the union type should also be added to the list of simple types on page 3-3.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of Fully qualified names in the model tags in section 3.2.2.3

  • Key: INBOX-203
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    The XML as described in section 3.2.2.3 and sub section has a problem in relation to IDL modules. How to represent to valuetypes named Foo which are defined in different modules for example? It is currently not clear how this should be done. It is our suggestion to clarify that fully qualified names should be used in IDL sense. Where a valuetype Foo in module Test would be referred to as "Test::Foo". The subsections of section 3.2.2.3 should state for each element attribute if fully qualified names must be used.

    Solution:

    In section 3.2.2.3 replace:
    Model tags are specified by means of XML declarations that must be compliant with the DTD listed in the following section; subsequent sections give details on the constructs.
    With:
    Model tags are specified by means of XML declarations that must be compliant with the DTD listed in the following section; subsequent sections give details on the constructs. The elements in the DTD often have attributes which give the name of IDL defined entities. To correctly identify such entities, fully qualified names (in IDL sense) should be used as much as possible. For example a valuetype Foo in module Test would be referred to as "Test::Foo".

    In section 3.2.2.3.2.2 EnumDef replace:
    This tag contains an attribute name (scoped name of the IDL enumeration) and as many value sub-tags that needed to give values.
    With:
    This tag contains an attribute name (fully qualified name of the IDL enumeration) and as many value sub-tags that needed to give values.

    In section 3.2.2.3.2.3 TemplateDef replace:
    This tag contains three attributes:
    o name - gives the scoped name of the type.
    o pattern - gives the construct pattern. The supported constructs are: List, StrMap, IntMap, and Set.
    o itemType - gives the type of each element in the collection.

    With:
    This tag contains three attributes:
    o name - gives the fully qualified name of the type.
    o pattern - gives the construct pattern. The supported constructs are: List, StrMap, IntMap, and Set.
    o itemType - gives the fully qualified type name of each element in the collection.

    In section 3.2.2.3.2.4 AssociationDef replace:
    o class - contains the scoped name of the class.
    With:
    o class - contains the fully qualified name of the class.

    In section 3.2.2.3.2.5 compoRelationDef replace:
    o class - contains the scoped name of the class.
    With:
    o class - contains the fully qualified name of the class.

    In section 3.2.2.3.2.6 ClassMapping replace:
    This tag contains one attribute name that gives the scoped name of the class and:
    With:
    This tag contains one attribute name that gives the fully qualified name of the class and:

    In section 3.2.2.3.2.7 MainTopic replace:
    This tag gives the main DCPS Topic, to which that class refers. The main Topic is the topic that gives the existence of a object (an object is declared as existing if, and only if, there is an instance in that Topic matching its key value.
    It comprises one attribute (name) that gives the name of the Topic, one (optional) attribute (typename) that gives the name of the type (if this attribute is not supplied the type name is considered to be equal to the topic name) and:
    With:
    This tag gives the main DCPS Topic, to which that class refer. The main Topic is the topic that gives the existence of an object (an object is declared as existing if, and only if, there is an instance in that Topic matching its key value).
    It comprises one attribute (name) that gives the name of the Topic (must adhere to topic naming rules, see section B-3 regarding the TOPICNAME), one (optional) attribute (typename) that gives the fully qualified name of the type (if this attribute is not supplied the type name is considered to be equal to the topic name) and:

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions/usage for remove operation on List in section 3.1.6.3.16

  • Key: INBOX-218
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The remove operation should do nothing if it did not contain an element with the specified key.

    The remove operation on the collection (list, strmap, intmap, but NOT set) should mention it raises a PreconditionNotMet if:

    • The owner ObjectRoot of the List is not contained within a (writeable) CacheAccess
    • The owner ObjectRoot has not yet been registered (i.e. has no identity)

    This should also be fixed in the IDL descriptions (normal and implied)

    In section 3.2.1.2 IDL description: For the List replace:
    void remove( ) ;
    With:
    void remove( ) raises (PreconditionNotMet);;

    For the StrMap valuetype:
    Replace:
    void remove( in string key );
    With:
    void remove( in string key ) raises (PreconditionNotMet);

    For the IntMap valuetype:
    Replace:
    void remove( in long key );
    With:
    void remove( in long key ) raises (PreconditionNotMet);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add exceptions, clarify usage of other exceptions

  • Key: INBOX-151
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Several new Exceptions need to be introduced in the exception list on page 3-18:
    · BadParameter - To be thrown when an illegal parameter is used for an operation. An illegal parameter is defined as a NIL pointer
    · TimeOut - To be thrown during the write operation of the CacheAccess to indicate a time out occurred while trying to write the contents of the CacheAccess.

    On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following two definitions:
    exception BadParameter

    {string message;};
    exception TimeOut {string message;}

    ;

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Change description on mapping rules for Exceptions or return values

  • Key: INBOX-194
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Section 3.2.1.1 Change description on mapping rules for Exceptions or return values. Currently it states that return-values are used for recoverable errors and exceptions for non-recoverable errors. Remove this description: exceptions are used for both cases.

    Solution:

    TBD.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Various typos in section 3.1.6.3.7, ObjectHome

  • Key: INBOX-208
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem 1:
    In the table on page 3-26 and 3-27 regarding the ObjectHome entity some types of attributes, parameters and return types are incorrectly shown. In the rest of the document whenever an operation is to have a return type/parameter of a specialized class or an attribute is of a specialized class it does not state the class (for example ObjectRoot) but states the word Undefined between < and > appended with the word if the type (Selection, StrMap, etc, making <undefined>Selection. This is missing various times in the table in section 3.1.6.3.7 regarding the ObjectHome. Specifically for the attributes 'selections' and listener' and for the operations attach_listener (listener param), detach_listener (listener param), create_selection (return type), delete_selection (a_selection param), create_object (return type), create_unregister_object (return type), register_object (unregister_object param), find_object (return type), get_objects(return type), get_created_objects (return type), get_modified_objects (return type), get_deleted_objects (return type).

    Problem 2:
    The attribute 'listener' in the table, should be 'listeners' as used everywhere else in the ObjectHome defintion (see figure 3-4 on page 3-16 and the description for the attribute on page 3-28)

    Problem 3:
    The attribute 'class_name' in the table should be 'name' to be made consistent with figure 3-4 on page 3-16. It should also be updated in the description on page 3-27

    Problem 4:
    The attribute parent (type: ObjectHome) and children (type: ObjectHome[]) should be added to the table. Their descriptions should also be added in the attribute listing directly following the table. (see figure 3-4 where they are mentioned)

    Solution:
    XXX TBD

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.7 regarding the ObjectHome clarify some things

  • Key: INBOX-147
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem 1
    The description for the name attribute (see issue XXX) needs to be clarified into saying that the name attribute gives the fully qualified name using IDL '::' as seperators (i.e. ObjectHome representing class Foo in module test has as name 'test::Foo').

    Solution 1:
    Replace:
    o the public name of the application-defined class (name).
    With:
    o the public fully qualified name (using IDL seperators '::') of the application-defined class (name). For an ObjectHome representing class Foo in module test it's name becomes 'test::Foo'.

    Problem 2:
    The description for the index attribute of the object home needs to specify what the index is in case the home is not yet registered with any Cache. It is our suggestion to make this operation return -1 as value for an ObjectHome which has not yet been registered to any Cache. The description also contains a type, as it talks about index, but it should be registration_index.

    Solution 2:
    Replace:
    o the index under which the ObjectHome has been registered by the Cache (see Cache::register_home operation).
    With:
    o the index (registration_index) under which the ObjectHome has been registered by the Cache (see Cache::register_home operation). If the ObjectHome was not yet registered to any Cache then -1 is returned as value.

    In the IDL description in section 3.2.1.2 on page 3-53 the attribute type of the registration_index needs to be replaced from unsigned_long to long to allow -1 as return value.
    Replace:
    readonly attribute unsigned long registration_index;
    With:
    readonly attribute long registration_index;

    In the IDL description in section 3.2.1.2 on page 3-58 regarding the Cache interface description change the return value of the register_home operation from unsigned_long into long:
    Replace:
    unsigned long register_home (
    in ObjectHome a_home)
    raises (
    PreconditionNotMet);
    With:
    long register_home ( in ObjectHome a_home) raises (PreconditionNotMet);

    Problem 3:
    The description for the selections and listeners attributes should be in plural, furthermore the attribute names in the description should be bold .

    Solution 3:
    Replace:
    o the list of attached Selection (selections).
    o the list of attached ObjectListener (listeners).
    With:
    o the list of attached Selection objects (selections).
    o the list of attached ObjectListener objects (listeners).

    Problem 4:
    The description for the set_content_filter operation states that it can only be set before the home is registered to a Cache. But this is not correct, it should state that it must be set while the cache the home is registered to (if any) has a pubsub state of INITIAL. As long as the readers have not been created it should not be prohibited to set the content filter.

    Solution 4:
    Replace:
    o set the content_filter for that ObjectHome (set_content_filter). As a content filter is intended to be mapped on the underlying infrastructure it can be set only before the ObjectHome is registered (see Cache::register_home). An attempt to change the filter expression afterwards will raise a PreconditionNotMet. Using an invald filter expression will raise an SQLError.
    With:
    o set the content_filter for that ObjectHome (set_content_filter). As a content filter is intended to be mapped on the underlying infrastructure it can be set only if the Cache to which the ObjectHome belongs (if any) has not yet been registered for pubsub. (see Cache::register_all_for_pubsub). An attempt to change the filter expression afterwards will raise a PreconditionNotMet. Using an invald filter expression will raise an SQLError.

    Problem 5:
    The description of the deref_all operation talks about the 'most recent' state, but this is not correct. As in 'manual' update mode (using the refresh operation on the Cache) one wants to load the state as known during the last refresh operation, which is not neccesarily the most recent state known in DCPS. Reasoning behind this is that one doesn't want to have inconcistent states within the DLRL, where one object state is significantly 'newer' then other states, especially since 'dereferencing' is only meant to load in a state which is not done at refresh time to gain performance. The deref_all is not meant as a refresh on home level!

    Solution 5:
    Replace:
    o ask to load the most recent state of a DLRL Object into that Object for all objects managed by that home (deref_all).
    With:
    o ask to load the last known state (at the time of the last update round) of a DLRL Object into that Object for all objects managed by that home (deref_all).

    Problem 6:
    The description about the create_selection operation talks about a SelectionCriteration (second line) where it should talk about a QueryCriterion. In the last line it should clarify that the PreconditionNotMet is raised if the cache it belongs to is still set to INITIAL with relation to the DCPS state as well as if the home does not yet belong to a Cache.

    Solution 6:
    Replace:
    o create a Selection (create_selection). The criterion parameter specifies the SelectionCriterion (either a FilterCriterion or an SelectionCriterion) to be attached to the Selection, the auto_refresh parameter specifies if the Selection has to be refreshed automatically or only on demand (see Selection) and a boolean parameter specifies, when set to TRUE, that the Selection is concerned not only by its member
    objects but also by their contained ones (concerns_contained_objects); attached SelectionCriterion belong to the Selection that itself belongs to its creating ObjectHome. When creating a Selection while the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.
    With:
    o create a Selection (create_selection). The criterion parameter specifies the SelectionCriterion (either a FilterCriterion or an QueryCriterion) to be attached to the Selection, the auto_refresh parameter specifies if the Selection has to be refreshed automatically or only on demand (see Selection) and a boolean parameter specifies, when set to TRUE, that the Selection is concerned not only by its member
    objects but also by their contained ones (concerns_contained_objects); attached SelectionCriterion belong to the Selection that itself belongs to its creating ObjectHome. When creating a Selection if the ObjectHome does not yet belong to a Cache or while the DCPS State of the Cache that the ObjectHome belongs to is still set to INITIAL, a PreconditionNotMet is raised.

    Problem 7:
    The description of the create_unregistered_object should be changed to indicate that only the identity should be set/changed for objects created by this operation. One wants to prevent relations and such to be set on unregistered objects. The only reason this operation exists is to allow an application to set the identity of the object if the object is mapped using predefined mapping rules. In this mode the DLRL cannot determine the keys itself and thus needs user input.

    Solution 7:
    Replace the word 'content' on the first line with 'identity'.

    Problem 8:
    Clarify the register_object method only takes objects created by the create_unregistered_object method of the same home instance.

    Solution 8:
    Replace:
    o register an object resulting from such a pre-creation (register_object). This operation embeds a logic to derive from the object content a suitable oid; only objects created by create_unregistered_object can be passed as parameter, a PreconditionNotMet is raised otherwise. If the result of the computation leads to an
    existing oid, an AlreadyExisting exception is raised. Once an object has been registered, the fields that make up its identity (i.e. the fields that are mapped onto the keyfields of the corresponding topics) may not be changed anymore.
    With:
    o register an object resulting from such a pre-creation (register_object). This operation embeds a logic to derive from the object content a suitable oid; only objects created by create_unregistered_object (of the same ObjectHome instance) can be passed as parameter, a PreconditionNotMet is raised otherwise. If the result of the computation leads to an
    existing oid, an AlreadyExisting exception is raised. Once an object has been registered, the fields that make up its identity (i.e. the fields that are mapped onto the keyfields of the corresponding topics) may not be changed anymore.

    Problem 9:
    Clarify behavior for the find_object operation if no object with the specified OID can be located. (return NULL). It is not desireable to throw an exception if no object can be found (Notfound) as that is too heavy wait just to report that no object with the specified OID exists..

    Solution 9:
    Replace:
    o retrieve a DLRL object based on its oid in the in the specified CacheBase (find_object).
    With:
    o retrieve a DLRL object based on its oid in the in the specified CacheBase (find_object). If no such object can be located NULL is returned.

    In the IDL description on page 3-54 in section 3.2.1.2 regarding the ObjectHome replace:
    ObjectRoot find_object (
    in DLRLOid oid,
    in CacheBase source)
    raises (
    NotFound);
    With:
    ObjectRoot find_object ( in DLRLOid oid, in CacheBase source);

    Problem 10:
    Clarify the behavior of the get_topic_name operation if the passed attribute is not defined within the home. (it should just return NULL)

    Solution 10:
    Replace:
    o retrieve the name of the topic that contains the value for one attribute(get_topic_name). If the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.
    With:
    o retrieve the name of the topic that contains the value for one attribute (get_topic_name), if the attribute is unknown then NULL is returned. If the DCPS State of the Cache is still set to INITIAL, a PreconditionNotMet is raised.

    Problem 11:
    It should be clarified that objects with the state DELETED should not be contained in the get_objects operation of the ObjectHome. The text about ObjectRoot turning into Foo should also be removed, as its already covered by the undefined bit see XXX.

    Solution 11:
    Replace:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.
    With:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). Objects with the state DELETED are not contained within this list.

    Problem 12:

    Remove the text about ObjectRoot becoming Foo in the generated home for the description of the get_created_objects, get_modified_objects, get_deleted_objects. Its already stated with the undefined bit… See XXX

    Solution 12:
    Replace:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome and that have been created, modified or deleted during the last refresh operation (get_created_objects, get_modified_objects and get_deleted_objects respectively). The type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.
    With:
    o obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome and that have been created, modified or deleted during the last refresh operation (get_created_objects, get_modified_objects and get_deleted_objects respectively).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify various things with operation enable_all_for_pubsub

  • Key: INBOX-221
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 regarding the operation enable_all_for_pubsub several clarifications should be made:
    1) In the first sentence before the word 'QoS' is should say (immutable) to clarify it's mainly the idea that immutable QoS settings can be changed at that time.
    2) The expression "those two operations" in the second sentence should be replaced by "this operation and the register_all_for_pubsub operation".
    3) It should state the DCPSError is raised if an error occurred while enabling the DCPS entities.

    Solution:
    Replace:
    o enable the derived Pub/Sub infrastructure (enable_all_for_pubsub). QoS setting can be performed between those two operations. One precondition must be satisfied before invoking the enable_all_for_pub_sub method: the pubsub_state must already have been set to REGISTERED before. A PreconditionNotMet Exception is thrown otherwise. Invoking the enable_all_for_pub_sub method on an ENABLED pubsub_state will be considered a no-op.

    With:
    o enable the derived Pub/Sub infrastructure (enable_all_for_pubsub). Changes to the (Immutable) QoS settings can be performed between this operation and the register_all_for_pubsub operation. One precondition must be satisfied before invoking the enable_all_for_pub_sub method: the pubsub_state must already have been set to REGISTERED before. A PreconditionNotMet Exception is thrown otherwise. A DCPSError is raised if an error occurred while enabling the DCPS entities. Invoking the enable_all_for_pub_sub method on an ENABLED pubsub_state will be considered a no-op.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions with operation register_all_for_pubsub

  • Key: INBOX-163
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Description of the register_all_for_pubsub operation on page 3-23 in section 3.1.6.3.4 doesn't say under which conditions the DCPSError exception is raised

    Solution:
    Add the following sentence to the description of the register_all_for_pubsub operation:
    A DCPSError is raised if an error was encountered while trying to create the DCPS entities

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Description not detailed enough

  • Key: INBOX-222
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The description of the getter, setter and is_xxx_modified operation for attributes of a DLRL object is not detailed enough. An exception listing should be added, and for what type of attributes the exception is valid and under which circumstances.

    Exceptions for get_<attribute_name> operations:
    · DCPSError (which should be made a 'runtime' exception, to prevent nasty catch clause needed for each getter!!)
    o For all (shared) attributes:
    § a DCPSError if some error happened in DCPS (state might need to be fetched from DCPS, if the object was not dereffed).

    · NotFound
    o For mono relation shared attributes:
    § A NotFound exception if the related attribute could not be located.

    Exceptions for set_<attribute_name> operations:
    · PreconditionNotMet
    o For all (shared) attributes:
    § Object is not in a (writeable) cacheaccess
    o For any (shared) attribute that is a key field (predefined mapping only)
    § Object is already registered (i.e. identity may not be registered anymore)
    o For mono relation shared attributes:
    § If the value of the parameter is NIL, but the relation was modeled as a mandatory relation (see XXX)
    § If the object in the parameter has different keys then the owner object and the relation is mapped using so called 'shared' keys.
    o For mono/multi relation shared attributes:
    § 'Owning' object (or owner of the collection if multi relation) is not yet registered.
    § 'Target' object (or owner of the collection if multi relation) is not yet registered.
    § If the object (or owner of the collection if multi relation) represented by the parameter has already been deleted (this does not include marked for destruction!)
    § If the object (or owner of the collection if multi relation) in the parameter is not defined in the scope of the same CacheAccess
    o For multi relation shared attributes:
    § If the parameter value is NIL

    Furthermore the descriptions should also be augmented. The setter description should state that a setter for a collection type basically clears the entire contents of the collection of the 'owner' objects and then copies in the content of the collection in the parameter. Making the setter for a collection work like a clear of the contents of the 'old' collection and then an element for element add of the elements of the other collection.

    The is_xxx_modified operation description should also state that it takes a ReferenceScope as parameter for (mono/multi) relations. SIMPLE_CONTENT_SCOPE only takes the reference to the related object into account (for multi relations this means elements in the collection, not the multi relation object (pointer) itself which should never change during the life cycle of the owning object!) and REFERENCED_CONTENTS_SCOPE takes the reference to the related object into account as well as the content of the object.

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of the is_modified() operation on the ObjectRoot

  • Key: INBOX-173
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Firstly all references to primary and secondary (or clone) objects should be replaced with cache and cacheaccess objects respectively. Furthermore the usage of the is_modified operation is unclear, it states that it returns false when the read_state is new. Suppossedly because nothing is modified (it's the first time the data is seen). In that light we can only wonder what the is_modified should return when the DLRL receives a new sample for the underlying topics of the Object, but all the attributes have the exact same value (although the real compare is more complex, as some attributes are actually foreign keys and if a new generation of a relation appeared then the attribute value may not have changed, but the relation represented by the attribute has… but that's more of an implementation issue I suppose), or when a dispose is received, but no new data sample. In those cases should this operation return false, or true? That's not clear from the current description of the operation.
    Basically we see two options for the is_modified operation
    1) true is only returned when one of the is_xxx_modified operations returns true
    2) true is only returned if the read_state of the object is something else then NOT_MODIFIED
    The first operation has some added value, as an application now does not need to access each is_xxx_modified operation and find out nothing has changed. However the drawback is that the read_state may be MODIFIED or DELETED, but the is_modified operation still indicates nothing has changed. Forcing an application to always use the read_state() operation along with the is_modified operation and never being able to just use one or the other to determine if something changed at the object (because an object becoming new or disposed is ussually something an application desires to know). This approach also makes the is_modified operation rather complex, as it's implementation has to evaluate each mono attribute by value, each relation by value AND by reference (by value is needed if it was NotFound before and after an update round, and by reference is needed in case of new generations). This all makes the is_modified operation from a seemingly light weight operation into a heavy weight one.
    Furthermore if we look at the added benefit of the is_modified operation, it's that we can provide a scope, asking it to check out it's related/contained objects as well for modifications. To us that's the real advantage of this operation over simply getting the read_state of the operation.
    And that's why we prefer option 2, only returning true if the read_state() is something else then NOT_MODIFIED. Because then an application can simply use the is_modified operation to determine what it wants to do with the object, whether it's new, deleted, modified or one of it's related objects has something modified. That does not matter, one call will tell the application whatever it needs to know, if the application does not require modification info on related objects, then it can just use the read_state or the is_modified with a simple_object_scope.

    Solution:
    Replace:
    o see if the object has been modified by incoming modifications (is_modified). is_modified takes as parameter the scope of the request (i.e., only the object contents, the object and its component objects, the object and all its related objects). In case the object is newly created, this operation returns FALSE; 'incoming modifications' should be understood differently for a primary object and for a clone object.
    o For a primary object, they refer to incoming updates (i.e., coming from the infrastructure).
    o For a secondary object (cloned), they refer to the modifications applied to the object by the last CacheAccess::refresh operation.

    With:
    o see if the object has been updated in the current update round (is_modified). is_modified takes as parameter the scope of the request, i.e.,only the object contents (SIMPLE_OBJECT_SCOPE), the object contents and its composed objects contents (CONTAINED_OBJECTS_SCOPE, unlimited depth), the object contents, its composed objects contents and all its related (non-composed) objects contents (RELATED_OBJECTS_SCOPE, depth of 1 for related objects and unlimited depth for contained objects). Incoming modifications should be understood differently for a cache object and for a cacheaccess object.
    o For a cache object, they refer to incoming updates (i.e., coming from the infrastructure).
    o For a cacheaccess object that is cloned from a cache objects, they refer to the modifications applied to the object by the last CacheAccess::refresh operation.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of the destroy() operation on the ObjectRoot

  • Key: INBOX-144
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It should be clarified that a destroyed ObjectRoot is only removed from the CacheAccess after the write() operation has been performed. The ObjectRoot will produce AlreadyDeleted exceptions only after that time.

    Solution:
    Replace:
    o mark the object for destruction (destroy), to be executed during a write operation. If the object is not located in a writeable CacheAccess, a PreconditionNotMet is raised.
    With:
    o mark the object for destruction (destroy), to be executed during a write operation on the owning CacheAccess. After the write operation has been completed the object will be removed from the CacheAccess and subsequent calls to operations on the object may result in AlreadyDeleted exceptions being raised. If the object is not located in a writeable CacheAccess, a PreconditionNotMet is raised.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

getter/setter/is_modified operations

  • Key: INBOX-226
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    For each attribute a getter, setter and is_xxx_modified (in case of non-keyfields) operation is to be generated in the derived class. This should be made more explicity by adding the operations in the table contents on page 3-34. It should also be added in the IDL description in section 3.2.1.2 on page 3-51 and in figure 3-4 on page 3-16

    Since keyfields determine the identity of a DLRL object, they cannot be changed. That means no is__<attribute>_modified operations needs to be generated for them.

    Solution:
    Add the following to the table on page 3-34:
    For each attribute defined on the class:
    get_<attribute_name> <undefined attribute type>
    set_<attribute_name> void
    value <undefined attribute type>
    For each attribute defined on the class which is not a relation to another DLRL object:
    is_<attribute_name>_modified boolean
    For each attribute defined on the class which is a relation (mono relation / multi relation) to another DLRL object:
    is_<attribute_name>_modified boolean
    scope ReferenceScope

    Section 3.1.6.3.14:
    Replace:

    · is_<attribute>_modified, to get if this attribute has been modified by means of incoming modifications (cf. method is_modified).

    With:

    · is_<attribute_name>_modified, to get if this attribute has been modified by means of incoming modifications (cf. method is_modified). Since keyfields cannot be changed by incoming modifications, this operation will not be generated for attributes that represent such keyfields.

    Add the following text in the description for valuetype ObjectRoot on page 3-51 in section 3.2.1.2 within the closing bracket of the objectroot valuetype.
    /* For each attribute of the application type 'Foo' the following operations

    • will be generated:
    • <attribute_type> get_<attribute_name>();
    • void set_<attribute_name>(<attribute_type> value);
    • If the attribute is a MonoAttribute or MultiAttribute the following operation will
    • be generated:
      *
    • boolean is_<attribute_name>_modified();
      *
    • If the attribute is a MonoRelation or MultiRelation the following operation will
    • be generated:
      *
    • boolean is_<attribute_name>_modified(ReferenceScope scope);
      */

    Add in figure 3-4 on page 3-16 to the ObjectRoot class operations listing the following operations:
    get_<attribute_name>()
    set_<attribute_name>()
    is_<attribute_name>_modified()

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclarities in table in section 3.1.6.2 the row regarding the CacheAccess

  • Key: INBOX-178
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In the table in section 3.1.6.2 in the row regarding the CacheAccess it should be clarified that one CacheAccess should be used by one thread. If multiple threads require access to the same CacheAccess it is the application responsibility to ensure thread safety.

    Solution:
    Replace:
    Class that encapsulates the access to a set of objects. It offers methods to refresh and write objects attached to it; CacheAccess objects can be created in read mode, in order to provide a consistent access to a subset of the Cache without blocking the incoming updates or in write mode in order to provide support for concurrent modifications/updates threads.

    With (sentence at the end added):

    Class that encapsulates the access to a set of objects. It offers methods to refresh and write objects attached to it; CacheAccess objects can be created in read mode, in order to provide a consistent access to a subset of the Cache without blocking the incoming updates or in write mode in order to provide support for concurrent modifications/updates threads. A CacheAccess should only be used by one thread, if multiple threads require access to the same CacheAccess then it is the responsibility of the application to ensure thread safety.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Should "set" method called outside of writable CacheAccess throw exception?

  • Key: INBOX-118
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    A set_<attribute> call on a DLRL object is only valid from within a writable CacheAccess. It seems that, if an application calls set_<attribute> on a DLRL object outside of a writable CacheAccess, then set_<attribute> should throw an exception – probably a PreconditionNotMet exception. However, the spec doesn't indicate that an exception should be thrown in this case. It only mentions the case where the attribute is a key field in the non-default mapping (3.1.6.3.14)

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Mismatch between DLRL and CORBA on enumerations

  • Key: INBOX-121
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The DLRL spec indicates that enumerations are mapped to 8-bit integers or strings, not to IDL enums. See 3.1.4.2.3

    Can that be right? An IDL enum is a 32-bit integer. See 3.11.2.4 in the 04-03-01 CORBA spec. It seems strange not to map a DLRL enum to an IDL enum. Is there a reason?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Error in the IDL for the SelectionListener

  • Key: INBOX-128
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The IDL for SelectionListsner has an error.

    The base SelectionListener class shows on_object_out() accepting an ObjectRoot; but the generated FooSelectionListener shows on_object_out (correctly) accepting a Foo. Putting the base SelectionListener's on_object_out() inside of the comment would fix this.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Prevent writing contents of CacheAccess while 'invalid' relations exists

  • Key: INBOX-215
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It is desirable to prevent an application from writing changes that are in itself inconsistent. Changes are inconsistent when for example a NIL pointer for a relation that was modeled as mandatory is still set (in predefined mapping, what would one put into the key values?!) or a relation to an object that is marked to be disposed in the next write operation (setting such relations is allowed, as long as they are reset again when writing the contents.). The latter is to be prevented to ensure receiving application do not get inconsistent data, i.e. a relation to a deleted object which could result in an AlreadyDeleted exception is to be prevented at all costs.

    To prevent such inconsistencies to be inserted into the system we propose to let the write operation throw an InvalidObjects exception to indicate the application has created an invalid state within the CacheAccess. To determine which objects are invalid an operation should be added to retrieve all invalid objects in the CacheAccess. And each ObjectRoot should have an operation to retrieve the names of the relations which cause the object to be marked as an invalid object.

    Solution:

    Add new Exception in the exception list on page 3-18:
    · InvalidObjects - To be thrown during the write operation of the CacheAccess to indicate invalid objects exist in the CacheAccess. An invalid object is defined as an object which has one or more invalid relation(s).

    On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following definition:
    exception InvalidObjects

    {string message;}

    ;

    Change the description of the write() operation on the CacheAccess on page 3-21, add the following:
    An InvalidObjects exception is raised if one of the objects contained within the CacheAccess has one or more invalid relation(s)

    Add the following operation to the CacheAccess class in figure 3-4 on page 3-16:
    get_invalid_objects()

    Add the following operation description to the end of the table of the CacheAccess in section 3.1.6.3.3, page 3-21.
    get_invalid_objects ObjectRoot[]

    Add the following description for operation get_invalid_objects() right after the description of operation delete_contract
    · Returns a list of all ObjectRoots which have one or more invalid relation(s). This operation should be used to recover from an InvalidObjects exception thrown by the write() operation. (get_invalid_objects)

    Add the following operation to the collection class in figure 3-4 on page 3-16
    get_invalid_elements()
    get_element_status()

    Add the following operations to the ObjectRoot class in figure 3-4 on page 3-16:
    get_invalid_relations()
    get_relation_status ()

    Add the following operation description to the end of the table of the Collection entity in section 3.1.6.1.15 on page 3-38
    get_invalid_elements <undefined element type>[]
    get_element_status RelationStatus
    value <undefined element type>

    Add the following description for operation 'get_invalid_elements()' right after the description of operation 'values':
    · Returns all elements which are seen as invalid by the DLRL. An element is invalid when it refers to an object with the write_state OBJECT_DELETED or when the collection is a composition, but the constituent object referred to by the element is also referred by another composition relation or when the relation is an association but the associated object referred to by the element does not correctly point back to the object. (get_invalid_elements)
    · Returns an enumeration indicating wether the element indicated by the value parameter is valid or invalid (and the exact relation why it is invalid). If the element is not known within the scope of the Collection than a NoSuchElement exception is raised. (get_element_status)

    Add the following operation description to the end of the table of the ObjectRoot entity in section 3.1.6.3.14 on page 3-34:
    get_invalid_relations string[]
    get_relation_status RelationStatus
    name string

    Add the following description for operation invalid_relations () right after the description of operation is_modified
    · Returns a list of relation names which are seen as invalid by the DLRL. A relation is invalid when it refers to an object with the write_state OBJECT_DELETED or when the relation is a NIL pointer but modeled as a mandatory relation (cardinality of 1) or when the relation is a composition, but the constituent object is also referred by another composition relation or when the relation is an association but the associated object does not correctly point back to the object. For relations that are collections the cardinality reason can not result in the relation being seen as invalid. (get_invalid_relations)
    · Returns an enumeration indicating wether the relation indicated by the name parameter is valid or invalid (and the exact relation why it is invalid). If no relation is known with that name within the scope of the ObjectRoot than a PreconditionNotMet exception is raised. (get_relation_status)

    On Section 3.2.1.2 IDL description on page 3-47 directly following the ObjectState enum add the following enum:
    enum RelationStatus

    { //The relation has no violations. VALID, //The relation is a NIL pointer but was modeled as a mandatory relation. CARDINALITY_VIOLATION, //The relation points to an object with read_state OBJECT_DELETED or //an object which was already garbage collected. LIVELINESS_VIOLATION, //The related object does not correctly associate itself with the 'owner' object //of this relation. ASSOCIATION_VIOLATION, //The related object is a constituent object in more then one composition relation. COMPOSITION_VIOLATION }

    ;

    On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the operation description:

    StringSeq get_invalid_objects();
    RelationStatus get_relation_status(in string name) raises (PreconditionNotMet);

    On Section 3.2.1.2 IDL description on page 3-55 regarding valuetype List add the operation description:
    LongSeq get_invalid_elements();
    RelationStatus get_element_status(in long index) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype StrMap add the operation description:
    StringSeq get_invalid_elements();
    RelationStatus get_element_status(in string key) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype IntMap add the operation description:
    LongSeq get_invalid_elements();
    RelationStatus get_element_status(in long key) raises (NoSuchElement);

    On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype Set add the operation description:
    /* To be properly typed in the generated derived classes:
    *

    • ObjectRootSeq get_invalid_elements();
    • RelationStatus get_element_status(in ObjectRoot value) raises (NoSuchElement);
      */

    On section 3.2.1.2.2 Implied IDL on page 3-62 regarding valuetype FooSet add the operation description:
    FooSeq get_invalid_elements();
    RelationStatus get_element_status(in Foo value) raises (NoSuchElement);

    In section 3.2.1.2 IDL description on page 3-57 regarding the CacheAccess add the exception InvalidObjects to the raises clause of the write operation.
    void write() raises (PreconditionNotMet, DCPSError, InvalidObjects, TimeOut);
    See issues XXX, XXX and XXX for details about the other exceptions and why the readonlymode exception was axed.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

getters of relationships

  • Key: INBOX-214
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It is possible for getters of relationships between DLRL objects to throw a Notfound exception when the related object cannot be located by the DLRL. However if that related object arrives in a later update round the NotFound should be cleared and the getter should return the related object. The owner of that relation should be seen as modified and the is_xxx_modified operation for that relation attribute should return true even if the object itself was not explicitly updated in that update round.

    Example:
    Update round 1: We receive object Foo and detect it has a relation to object Bar, but this object is not known. The relation is thus set to a NotFound exception if accessed.
    Update round 2: We now receive the Bar object that is the target of the Foo objects bar relation. We do not receive an update for the Foo object itself though.

    We propose in situation like above to mark Object Foo as modified and set the received Object Bar as the target of Object Foo. Is_xxx_modified for that relation returns true. This should be explained in the specification.

    Solution:
    TBD

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Add attribute to CacheAccess (section 3.1.6.3.3)

  • Key: INBOX-169
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Currently it is only possible to retrieve the names identifying the object homes for which a CacheAccess contains objects, but it would be desirable if instead of getting an array of string you'd get an array of indexes.
    This would allow for a more performance friendly way for applications to jump to the code to handle objects of a specific type in a CacheAccess

    Solution:

    Add the following row to the attributes listing of the CacheAccess directly following the row for attribute type_names:
    contained_types integer[]

    Add the following description to the list of description for attributes on page 3-21 directly following the description of attribute type_names:
    o A list of indexes that represents the types for which the CacheAccess contains at least one object (contained_types).

    In the IDL description on page 3-57 section 3.2.1.2 add attribute definition in the interface CacheAccess:
    readonly attribute LongSeq contained_types;

    In figure 3-4 on page 3-16 add the contained_types to the attribute listing of class ObjectHome.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DCPSError also becomes a 'runtime' exception

  • Key: INBOX-228
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Currently the DCPSError is used in various operations to indicate an error occuring in DCPS, however it is implementation specific for which operations the DCPS is accessed. For example the getter of a simple attribute needs to access DCPS if the state of the object was not yet dereffed.
    And because it's up to the implementation to decide where to keep it management information, it also possible to get DCPS errors on operations which the specification does not define them. For example a refresh on a Selection or the get_objects on a CacheBase or ObjectHome may raise DCPSErrors in our implementation.

    To give a better flexibility we suggest to make the DCPSError exception runtime as well, especially since often such exceptions are not recoverable. In such cases that the exception IS recoverable we suggest introducing a specific exception for that case. For example introducing a timeout exception in the write operation of the CacheAccess to deal with the fact the DCPS DataWriter timed out, as that is recoverable, but an error code indicating the DataWriter is deleted is not recoverable.

    Solution:
    Replace (in section 3.2.1.1):
    Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted exception. Since this exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly.
    With:
    Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted and DCPSError exceptions. Since these exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

instance_state of a DCPS instance becomes NOT_ALIVE_NO_WRITERS

  • Key: INBOX-219
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It should clearly be stated what to do to the lifecycle of a DLRL object when the instance_state of the corresponding DCPS instance becomes NOT_ALIVE_NO_WRITERS.

    Solution:

    Our proposal is to mark this situation in the DLRL object, but not to start a new DLRL generation. There must be some mechanism however to notify the application about changes to the Liveliness of such an object. We propose to add a specific ObjectState called LIVELINESS_LOST, which is a separate state variable from the ObjectState. A transition to this state can be signalled by a callback method on the ObjectListener called "on_object_liveliness_lost". When liveliness is regained, the ObjectState can revert back to the LIVELINESS_ASSURED. A new callback should be added for that situation called "on_object_liveliness_regained". Similarly the ObjectHome should provide methods called "get_liveliness_lost_objects" and "get_liveliness_regained_objects".

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Indicate the semantics of merging separate topics into one single object

  • Key: INBOX-145
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It needs to become clear how a situation is handled where a place- or extension topic is disposed, but the main topic is not, or vice-versa. What should be the result for the Object representing this combination?.

    Solution:

    Our proposal is that an object gets deleted if one or more of its constituent topics are deleted, and that it starts a new generation if one or more of its constituent topics starts a new generation. The same beaviour would then apply wrt Liveliness: the combination looses liveliness if one of the constituent topics does.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL object

  • Key: INBOX-184
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    What should happen to an object that passes a contentfilter once, but then its update gets blocked by the contentfilter? Currently the DLRL behaves as if no update was received, potentially resulting in the wrong assumption that the previous state is still the most recent state available.

    Solution:

    This problem cannot be solved without some support on DCPS ContentFilteredTopic level as well, since a special state needs to be introduced to represent instances that are blocked by a filter. The idea is to introduce a special state called NOT_COMPLIANT, that has similar properties to the DELETED state, except for the fact that it has another meaning. This NOT_COMPLIANT state can also be used for other purposes (See issue PT-DLRL-ARCH-0029).

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

How are deleted objects treated in a CacheBase and a Selection

  • Key: INBOX-153
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    It needs to be clarified how deleted objects are treated in a CacheBase and a Selection. In the update round in which they are reported as being deleted, are they still part of the members of that CacheBase/Selection or not? (See also section 3.1.6.4.1 last bullet.)

    Solution:

    Since deleted objects are no longer alive, we propose not to mention them in the members attribute of CacheBases/Selections. In the update round in which they become deleted they will be reported as being deleted in those CacheBases/Selections, but this deletion is executed immediately.

    Section 3.1.6.3.2
    Replace:

    · "A list of (untyped) objects that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.

    With:

    · A list of (untyped) objects (excluding the ones that are marked as deleted) that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.

    Section 3.1.6.3.7
    Replace:

    · obtain from a CacheBase a (typed) list of all objects that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[] in a FooHome.

    With:

    · obtain from a CacheBase a (typed) list of all objects (excluding the ones that are marked as deleted) that match the type of the selected ObjectHome (get_objects). For example the type ObjectRoot[ ] will be substituted by a type Foo[ ] in a FooHome.

    Section 3.1.6.3.9:
    Replace:

    · the list of the objects that are part of the selection (members).

    With:

    · the list of the objects (excluding the ones that are marked as deleted and the ones that no longer pass the filter) that are part of the selection (members).

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

FilterCriterion

  • Key: INBOX-189
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    When a Selection is in auto_refresh mode, normal operation is that it only evaluates objects in the update round in which they receive updates: objects that do not get updated have no reason to enter/exit a Selection. However, that mechanism is based on the assumption that the filter only evaluates the state of the object itself. What if the filter evaluates other things, like the state of related objects. Then the filter should also be re-applied if the state of such a related object changes.

    Solution:

    There may be a need to set the scope of a FilterCriterion: this scope will then define when and how objects should be re-evaluated by the Selection.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Proposal to make the is_xxx_modified operation optional

  • Key: INBOX-201
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    The is_xxx_modified operation (generated for each shared attribute in each DLRL object) is very heavy weight to implement, while it may not be used very much. We propose to make it optional, for example by a setting in the XML file, a setting on the corresponding ObjectHome, or by some QoS or something..

    Solution:

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clearly separate default mapping from pre-defined mapping

  • Key: INBOX-200
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    In Section 3.1.6.3.7 of the ObjectHome, there are descriptions for the create_object and the create_unregistered_object methods. They fail to mention that create_object may not be used for classes that have a keyDescription of "NoOid", and that create_unregistered_object may not be used for classes that have a keyDescription of "FullOid" or "SimpleOid". A PreconditionNotMet should be thrown in these cases.

    Solution:

    Section 3.1.6.3.7 on page 3-28
    Replace:

    · create a new DLRL object (create_object). This operation takes as parameter the CacheAccess concerned by the creation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:
    · create a new DLRL object (create_object). This operation takes as parameter the CacheAccess concerned by the creation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Furthermore, this ObjectHome may not manage any topics that have their keyDescription set to "NoOid" in the XML mapping file. Not satisfying all these preconditions will raise a PreconditionNotMet.

    Section 3.1.6.3.7 on page 3-29
    Replace:

    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Not satisfying either precondition will raise a PreconditionNotMet.

    With:
    · pre-create a new DLRL object in order to fill its content before the allocation of the oid (create_unregistered_object); this method takes as parameter the CacheAccess concerned with this operation. The following preconditions must be met: the Cache must be set to the DCPS State of ENABLED, and the supplied CacheAccess must writeable. Furthermore, this ObjectHome may only manage topics that have their keyDescription set to "NoOid" in the XML mapping file. Not satisfying all these preconditions will raise a PreconditionNotMet.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

The read_state of a cache object contains some typos

  • Key: INBOX-197
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    If we look at the state diagram of the read_state of the cache object, we can see several typos. With typos we mean transitions that are impossible (when reading other parts of the spec). the specification states that the DLRL works with update rounds, after the start of an update round updates are processed and applied onto objects, this may lead to state changes. Once the update round end, this information is cleared again.
    This last statement is of important, because if at the end of an update round the 'modification info' is cleared, then the read_state would return to NOT_MODIFIED after the end of updates signal (assuming it was NEW or MODIFIED) or it would be garbage collected if the state was DELETED. But this means there is no state transition between the NEW and MODIFIED state, not between the MODIFIED and DELETED states. There is also no transition from NEW to DELETED. These three transitions should thus be removed.
    Another 'typo' is that one transition is missing, namely from the start point directly to the DELETED state. Because it might happen that the DLRL detects a new object which is already disposed, and this is not something that can be ignored! This situation happens when a sample is read which has the following states (on DCPS level) view_state = NEW, sample_state = NOT_READ, instance_state = NOT_ALIVE_DISPOSED. In this case the DLRL cannot give this sample the state NEW, as it is disposed this update round and thus should not be shown as new, as that an incorrect view on things, the only way to go is to show it as DELETED, since ignoring such information is not a choice the DLRL can make. So this transition must be added.
    These changes produce the following diagram:

    The things said for the read_state of a cache object can also be said for the read_state of a cacheaccess object. An additional item missing is that the read_state of a cache access object in read_write mode can also go from start to void and then to end, in case of a local creation and then destruction through a write. This was not correctly mentioned, this also means the read_state diagram is valid for any usage of the cache access, the accompying text must be changed for this as well. The read_state of the cache access object is thus basically the same as the cache object, except the void state and it's transitions are added and some transitions have different descriptions

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify listeners

  • Key: INBOX-225
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.4 it should state that listeners are only triggered if the related cache has updated_enabled returning true, that is not clear now from the text.

    Solution:
    Replace (on page 3-41):
    As described in Section 3.1.6.2, "DLRL Entities," on page 3-15, there are three kinds of listeners that the application developer may implement and attach to DLRL entities: CacheListener, ObjectListener, and SelectionListener. All these listeners are a means for the application to attach specific application code to the arrival of some events. They are therefore only concerned with incoming information.
    With:
    As described in Section 3.1.6.2, "DLRL Entities," on page 3-15, there are three kinds of listeners that the application developer may implement and attach to DLRL entities: CacheListener, ObjectListener, and SelectionListener. All these listeners are a means for the application to attach specific application code to the arrival of some events. They are therefore only concerned with incoming information. Listeners are only triggered if the related Cache has updates_enabled returning true, with the exception of the operations modifying the result of the updates_enabled operation (disable_updates/enable_updates).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions

  • Key: INBOX-142
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The get operation on the List and StrMap and IntMap classes should mention that a NoSuchElement is raised if the List/IntMap/StrMap does not contain an element for the index/key specified with the get operation.

    In the IDL description in section 3.2.1.2 on page 3-55, 3-56 add the raise clauses to the operations:
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    ObjectRoot get( in long key );
    With:
    ObjectRoot get( in long index ) raises (NoSuchElement);

    For the StrMap valuetype:
    Replace:
    ObjectRoot get( in string key );
    With:
    ObjectRoot get( in string key ) raises (NoSuchElement);

    For the IntMap valuetype:
    Replace:
    ObjectRoot get( in long key );
    With:
    ObjectRoot get( in long key ) raises (NoSuchElement);

    In section 3.2.1.2.2 Implied IDL on page 3-61 and 3-62
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    Foo get( in long key );
    With:
    Foo get( in long index ) raises (NoSuchElement);

    For the StrMap valuetype:
    Replace:
    Foo get( in string key );
    With:
    Foo get( in string key ) raises (NoSuchElement);

    For the IntMap valuetype:
    Replace:
    Foo get( in long key );
    With:
    Foo get( in long key ) raises (NoSuchElement);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section 3.2.1.2.1 Generic DLRL Entities get_instance

  • Key: INBOX-196
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    For clarification purposes the generic IDL on page 3-59 in section 3.2.1.2.1 regarding the cache factory should mention the get_instance operation, in comments ofcourse.

    Solution:

    Add the following code to the CachFactory local interface definition:
    /* To be implemented as a static operation in the implementation:

    • CacheFactory get_instance();
      */
  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Describe exact event propagation in case of inheritance + multiple listener

  • Key: INBOX-150
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    In section 3.1.6.3.8 it is described how events that are not handled by child-objects are propagated to their parent objects. It is clearly described that when the callback function returns TRUE, the event will not be propagated to the parent Listener, otherwise it will. However, what should happen when two listeners are attached to the same Home and one of them returns TRUE and the other one returns FALSE?

    Solution:

    Clearly state that as long as only one of the Listeners returns FALSE, the event will be propagated to the parent listener.

    section 3.1.6.3.8
    Replace:

    Each of these methods must return a boolean. TRUE means that the event has been fully taken into account and therefore does not need to be propagated to other ObjectListener objects (of parent classes).

    With:

    Each of these methods must return a boolean. TRUE means that the event has been fully taken into account and therefore does not need to be propagated to other ObjectListener objects (of parent classes). In case of multiple listeners being attached to the same ObjectHome: as long as one or more of these listeners return FALSE, the event will be propagated to the parent classes, regardless of the number of listeners that returns TRUE.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Minor typo's and inconsistencies

  • Key: INBOX-136
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Remove quotations in the table contained in the Contents chapter (page 3-1).

    Solution:

    Replace:
    Section Title Page
    "Platform Independent Model (PIM)" 3-1
    "OMG IDL Platform Specific Model (PSM)" 3-45

    With:
    Section Title Page
    Platform Independent Model (PIM) 3-1
    OMG IDL Platform Specific Model (PSM) 3-45

    Problem:
    Footnote 2 is on wrong page.

    Solution:
    Move footnote 2 from page 3-3 to page 3-2

    Problem:
    In section 3.1.3.3, paragraph two, last sentence says 'They appear in grey on the schema.' Referring to the next figure, but no objects are in grey on that figure.

    Solution:
    Remove the sentence 'They appear in grey on the schema.' So that the paragraph looks as follows.

    Replace:
    Note that two objects that will be part of a DLRL model (namely ObjectRoot that is the
    root for all the DLRL classes as well as ObjectHome that is the class responsible for
    creating and managing all DLRL objects of a given class) are featured to show the
    conceptual relations between the metamodel and the model. They appear in grey on the
    schema.

    With:
    Note that two objects that will be part of a DLRL model (namely ObjectRoot that is the
    root for all the DLRL classes as well as ObjectHome that is the class responsible for
    creating and managing all DLRL objects of a given class) are featured to show the
    conceptual relations between the metamodel and the model.

    Problem:
    The first sentence of section 3.1.5.1 should not say:
    A DLRL class is associated with several DCPS Topic
    But say
    A DLRL class is associated with several DCPS Topics
    IE topics should be made plural.

    Solution:
    Replace:
    A DLRL class is associated with several DCPS Topic
    With:
    A DLRL class is associated with several DCPS Topics

    Problem:
    In figure 3-4 the CacheFactory shows an operation called 'find_cache', which should be 'find_cache_by_name'. The ObjectHome shows an operation called 'get_new_objects' which should be 'get_created_objects'

    Solution:
    Change operation name 'find_cache' in the CacheFactory class into 'find_cache_by_name'.
    Change operation name 'get_new_objects' in the ObjectHome class into 'get_created_objects'.

    Problem:
    In the table in section 3.1.6.2 in the row regarding the Cache two typos need to be corrected regarding the location of the word 'first' in the sentence regarding attaching objects to the CacheAccess and the last bullet needs to be rewritten and be made more clear.

    Solution:
    Replace:
    Class whose instance represents a set of objects that are locally available. Objects within a Cache can be read directly; however to be modified, they need to be attached first to a CacheAccess. Several Cache objects may be created but in this case, they must be fully isolated:
    o A Publisher can only be attached to one Cache.
    o A Subscriber can only be attached to one Cache.
    o Only DLRL objects belonging to one Cache can be put in relation.

    With:

    Class whose instance represents a set of objects that are locally available. Objects within a Cache can be read directly; however to be modified, they first need to be attached to a CacheAccess. Several Cache objects may be created but in this case, they must be fully isolated:
    o A Publisher can only be attached to one Cache.
    o A Subscriber can only be attached to one Cache.
    o A DLRL object can only have relationships with DLRL objects in the same Cache.

    Problem:
    The table in section 3.1.6.2 in the row regarding the ObjectListener talks about a 'peculiar' ObjectHome. This should say 'particuliar'.

    Solution:
    Replace:
    Interface to be implemented by the application to be made aware of incoming updates on the objects belonging to one peculiar ObjectHome.
    With:
    Interface to be implemented by the application to be made aware of incoming updates on the objects belonging to one particuliar ObjectHome.

    Problem:
    On page 3-18 remove wrong quotation marks and the word identify in the explanation of the AlreadyExisting exception should be identity.

    Replace:
    o "DCPSError: if an unexpected error occured in the DCPS
    o "BadHomeDefinition: if a registered ObjectHome has dependencies to other, unregistered ObjectHomes.
    o "NotFound: if a reference is encountered to an object that has not (yet) been received by the DCPS.
    o "AlreadyExisting: if a new object is created using an identify that is already in use by another object.
    o "AlreadyDeleted - if an operation is invoked on an object that has already been deleted.
    o "PreconditionNotMet - if a precondition for this operation has not (yet) been met.
    o "NoSuchElement - if an attempt is made to retrieve a non-existing element from a Collection.
    o "SQLError - if an SQL expression has bad syntax, addresses non-existing fields or is not consistent with its parameters.

    With:
    o DCPSError: if an unexpected error occured in the DCPS
    o BadHomeDefinition: if a registered ObjectHome has dependencies to other, unregistered ObjectHomes.
    o NotFound: if a reference is encountered to an object that has not (yet) been received by the DCPS.
    o AlreadyExisting: if a new object is created using an identity that is already in use by another object.
    o AlreadyDeleted - if an operation is invoked on an object that has already been deleted.
    o PreconditionNotMet - if a precondition for this operation has not (yet) been met.
    o NoSuchElement - if an attempt is made to retrieve a non-existing element from a Collection.
    o SQLError - if an SQL expression has bad syntax, addresses non-existing fields or is not consistent with its parameters.

    Problem:
    The first sentence in section 3.1.6.3.2, CacheBase, should talk about Cache-like objects, not Cache objects. Various wrong quotation marks are used in the attribute and operation listings. Attributes and operation names are not in bold at the description as is common throughout the spec. A bullet is missing for the explanation of the kind attribute. A new line is missing before the sentence "It offers methods to:". And the word 'cache' in the explanation of CacheUsage should be CacheBase

    Solution:
    Replace:
    CacheBase is the base class for all Cache classes. It contains the common functionality that supports Cache and CacheAccess.

    With:
    CacheBase is the base class for all Cache-like classes. It contains the common functionality that supports Cache and CacheAccess.

    Replace:
    The public attributes give:
    o "The cache_usage indicates whether the cache is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.
    o "A list of (untyped) objects that are contained in this CacheBase. To obtain objects by type, see the get_objects method in the typed ObjectHome.
    The kind describes whether a CacheBase instance represents a Cache or a CacheAccess.It offers methods to:
    o "Refresh the contents of the Cache with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    With:
    The public attributes give:
    o The cache_usage indicates whether the CacheBase is intended to support write operations (WRITE_ONLY or READ_WRITE) or not (READ_ONLY). This attribute is given at creation time and cannot be changed afterwards.
    o A list of (untyped) objects that are contained in this CacheBase. If an error in DCPS occurred, a DCPSError is raised. To obtain objects by type, see the get_objects method in the typed ObjectHome.
    o The kind describes whether a CacheBase instance represents a Cache or a CacheAccess.

    It offers methods to:
    o Refresh the contents of the CacheBase (refresh) with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    Problem:
    Several wrong quotation marks in section 3.1.6.3.3, CacheAccess, can be seen in the description of various operations.

    Solution:

    We propose to remove these quotation marks before operation descriptions of type_names, create_contract and delete_contract

    Problem (1/2):
    On page 3-29 in section 3.1.6.3.8 regarding the ObjectListener it incorrectly states the parameters of the operations as ObjectReference (which doesn't even exist anymore!), ObjectRoot and ObjectRoot. All these return type should be replaced with Undefined as the operations are generated in the typed ObjectListener class as typed operations.

    Solution (1/2):
    Replace the return types of the operation in the table with Undefined.

    Problem (2/2):
    On page 3-30 at the top it states that four operations are following, but only three operations are listed! There are only 3 operations!!

    Solution (2/2):
    Replace:
    It is defined with four methods:
    With:
    It is defined with three methods:

    Problem:
    On page 3-29 in section 3.1.6.3.8 regarding the Selection it incorrectly states the types of the attributes 'members' and listener as ObjectRoot[] and SelectionListener respectivly. This should be replaced by <undefined>[] and <undefined>SelectionListener respectively.
    The operation set_listener also wrongly specifies the return type and parameter type, both should be replaced by <undefined>SelectionListener.

    Solution:
    Obvious.

    Problem:
    In the table on page 3-31 regarding the SelectionCriterion it states the type of attribute kind as 'SelectionCriteria'. However this type does not exist anywhere! It should be CriterionKind. Also the attribute listing underneath the table is not conform the style used throughout the DLRL spec.

    Solution:
    Replace SelectionCriteria with CriterionKind in the table, make the style conform.

    Problem:
    In the table on page 3-32 in section 3.1.6.3.11 about the FilterCriterion is states that parameter 'an_object' has as type 'ObjectRoot' However this should be '<undefined>' as the method is properly generated in the 'FooFilter' class.

    Solution:
    Replace the parameter type of an_object with the word <undefined>.

    Problem:
    In the table on page 3-32 in section 3.1.6.3.12 regarding the QueryCriterion it states that the parameter names for the set_query (second param) and the set_parameters is 'arguments'. This is not consistent with the IDL PSM, which states 'parameters' as name. They should be made the same. The names in the table should be replaced with the name 'parameters'.

    Solution:
    Replace the parameter's name 'arguments' with 'parameters'.

    Problem:
    In section 3.1.6.3.3 CacheAccess, the table states that the operations 'the_object' parameter has as type ObjectRoot. However since these operations are generated in the derived class it should state '<undefined>' as type for the parameters.

    Solution:
    Obvious

    Problem:
    The first paragraph on page 3-33 in section 3.1.6.3.14 still talks about primary and secondary objects (or clones). In the last spec change primary objects where renamed to Cache objects and secondary objects(or clones) to CacheAccess objects. Note that cacheAccess object may be clones of cache objects, but that does not need to be the case.
    The text should be revised. The text also talks about an ObjectReference, which no longer exists, that text should be removed.

    Solution:
    Replace:
    ObjectRoot is the abstract root for any DLRL class. It brings all the properties that are needed for DLRL management. ObjectRoot are used to represent either objects that are in the Cache (also called primary objects) or clones that are attached to a CacheAccess (also called secondary objects). Secondary objects refer to a primary one with which they share the ObjectReference.
    With:
    ObjectRoot is the abstract root for any DLRL class. It brings all the properties that are needed for DLRL management. ObjectRoot are used to represent either objects that are in the Cache (also called cache objects) or objects that are attached to a CacheAccess (also called cacheaccess objects). Cacheaccess objects may be clones of cache objects, in that case they share the same OID.

    Problem:
    The table in section 3.1.6.3.19 regarding the intmap has an attribute defined called 'keys'. The type listed is 'string[]', but this should be 'integer[]', obviously.

    Solution:
    Obvious

    Problem:
    The text in section 3.1.6.2 states that any entity for which a generated class exists are indicated in italics. However when we look at the figure we see that this is not correct. The CacheBase class is incorrectly shown in italics, and the Selection class is incorrectly NOT shown in italics. The CacheListener should also not be in italics, as no class is generated for it, the same goes for the SelectionCriterion and the Collection. The ObjectHome however SHOULD be in italics.

    Solution:
    Make ObjectHome and Selection in italics
    Make CacheBase, CacheListener, SelectionCriterion and collection not in italics.

    Problem:
    In section 3.2.1.2.2 Implied IDL on page 3-60. A white space is missing in the attribute definition of the selections attribute between the attribute name and attribute type.

    Solution:
    Replace:
    readonly attribute FooSelectionSeqselections;
    With:
    readonly attribute FooSelectionSeq selections;

    Problem:
    In section 3.2.2.3.2.9 typo in section name ExtensionTable, it should be ExtensionTopic.

    Solution:
    Replace:
    3.2.2.3.2.9 ExtensionTable
    With:
    3.2.2.3.2.9 ExtensionTopic

    Problem:
    In section 3.2.3.2 IDL Model description on page 3-69 and 3-70 a module DLRL is mentioned twice, which does not exist. Track inherits from DLRL::ObjectRoot, it should be module DDS::ObjectRoot, same goes for valuetype Radar on page 3-70

    Solution:
    Replace:
    #include "dlrl.idl"
    valuetype stringStrMap; // StrMap<string>
    valuetype TrackList; // List<Track>
    valuetype Radar;
    valuetype Track : DLRL::ObjectRoot

    { public double x; public double y; public stringStrMap comments; public long w; public Radar a_radar; };
    valuetype Track3D : Track { public double z; };
    valuetype Radar : DLRL::ObjectRoot { public TrackList tracks; };
    With:
    #include "dlrl.idl"
    valuetype stringStrMap; // StrMap<string>
    valuetype TrackList; // List<Track>
    valuetype Radar;
    valuetype Track : DDS::ObjectRoot { public double x; public double y; public stringStrMap comments; public long w; public Radar a_radar; }

    ;
    valuetype Track3D : Track

    { public double z; }

    ;
    valuetype Radar : DDS::ObjectRoot

    { public TrackList tracks; }

    ;

    Problem:
    In section 3.2.3.4 Underlying DCPS Data Model the RADAR-TOPIC table is completely missing.

    Solution:
    Add:
    RADAR-TOPIC Topic to store all Radar objects, as well as the embedded attributes.
    OID Field to store the oid identifier.

    Problem:
    Faulty quotation marks can be found in the method description in sections 3.1.6.3.16, 3.1.6.3.17, 3.1.6.3.18 and 3.1.6.3.19. For example it states:
    o "remove - to remove the item with the highest index from the collection.
    But it should be:
    o remove - to remove the item with the highest index from the collection.

    All quotation marks should be removed!

    Solution:
    Remove quotation marks in section 3.1.6.3.16 for operations:

    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • add
    • put
    • get
      Remove quotation marks in section 3.1.6.3.17 for operations:
    • add
    • remove
    • contains
    • added_elements
    • removed_elements
      Remove quotation marks in section 3.1.6.3.18 for operations:
    • keys
    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • put
    • get
      Remove quotation marks in section 3.1.6.3.19 for operations:
    • keys
    • remove
    • added_elements
    • removed_elements
    • modified_elements
    • put
    • get
  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

In section 3.1.6.3.6 regarding the Contract clarify some things

  • Key: INBOX-190
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem (1/4) (typo):
    Each attribute and operation description wrongly starts with a quotation mark, these should be removed.
    Problem (2/4) (typo):
    The description of attribute depth talks about a RELATED_OBJECT_SCOPE. This should be RELATED_OBJECTS_SCOPE (objects should thus be plural).
    Problem (3/4) (clarification):
    During the description of the scope attribute the various scopes are explained, for clarification purposes insert the type of scope right after the explaination.
    Problem (4/4) (clarification):
    In the description for the set_depth operation, indicate that the depth is ignored unless the scope is set to RELATED_OBJECTS_SCOPE, just like it says at the getter for the depth attribute.

    Solution:

    Replace:
    o "The top-level object (contracted_object). This is the object that acts as the starting point for the cloning contract.
    o "The scope of the cloning request (i.e., the object itself, or the object with all its (nested) compositions, or the object with all its (nested) compositions and all the objects that are navigable from it up till the specified depth).
    o "The depth of the cloning contract. This defines how many levels of relationships will be covered by the contract (UNLIMITED_RELATED_OBJECTS when all navigable objects must be cloned recursively). The depth only applies to a RELATED_OBJECT_SCOPE.

    It offers methods to:
    o "Change the depth of an existing contract (set_depth). This change will only be taken into account at the next refresh of the CacheAccess.
    o "Change the scope of an existing contract (set_scope). This change will only be taken into account at the next refresh of the CacheAccess.

    With:
    o The top-level object (contracted_object). This is the object that acts as the starting point for the cloning contract.
    o The scope of the cloning request (i.e., the object itself (SIMPLE_OBJECT_SCOPE), or the object itself along with all its (nested) compositions (CONTAINED_OBJECTS_SCOPE), or the object itself along with all its (nested) compositions and all the objects that are navigable from it up till the specified depth (RELATED_OBJECTS_SCOPE)).
    o The depth of the cloning contract. This defines how many levels of relationships will be covered by the contract (UNLIMITED_RELATED_OBJECTS when all navigable objects must be cloned recursively). The depth only applies to a RELATED_OBJECTS_SCOPE.

    It offers methods to:
    o Change the depth of an existing contract (set_depth). This change will only be taken into account at the next refresh of the CacheAccess. The depth only applies to a RELATED_OBJECTS_SCOPE.
    o Change the scope of an existing contract (set_scope). This change will only be taken into account at the next refresh of the CacheAccess.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of refresh operation on the CacheBase, section 3.1.6.3.2

  • Key: INBOX-198
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.2 in the explantion of the refresh operation it should be stated a DCPSError may be raised if an error occurred while trying to read data from DCPS. And it should be stated a PreconditionNotMet exception is raised in case the cache_usage of the cache base excludes read operations.

    Solution:

    Replace:
    o Refresh the contents of the Cache with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess).

    With:
    o Refresh the contents of the CacheBase with respect to its origins (DCPS in case of a main Cache, Cache in case of a CacheAccess). A PreconditionNotMet is raised if the cache_usage excludes read operations.
    A DCPSError is raised if an error occurred while trying to read data from DCPS. If the CacheBase represents a Cache that has updates_enabled set to true, then this operation is considered a no-op.

    In section 2.2.1.2 IDL Description on page 3-57 regarding the definition of the local interface CacheBase replace:
    void refresh( ) raises (DCPSError);
    With:
    void refresh( ) raises (DCPSError, PreconditionNotMet);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Request clarification on the behavior of is_modified

  • Key: INBOX-117
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec implies that is_modified is only valid in the context of a listener callback (I suppose that would be an ObjectListener or a SelectionListener callback). See section 3.1.6.4.1, general scenario, which says that after end_updates is called, the "modification states of the updated objects is cleaned". Does that mean that, outside of an ObjectListener or SelectionListsner, a call to is_modified always returns false?

    Also, the spec is not clear about what happens in a CacheAccess. A CacheAccess, of course, has no listeners. So, for the is_modified() methods to be useful from a CacheAccess, they'd have to be valid from outside of a listener for an object in a CacheAccess. Is that the case?

    There is also the corner case of a manual Selection. A manual Selection might not have a listener. There wouldn't be any way to call is_modified () on an object in a manual Selection that doesn't have a Listener – you'd have to attach a Listener to the manual selection, and call is_modified in the callback that happens when you call refresh().
    Is that what the spec intends?

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Int the future, allow DLRL valuetype implementations?

  • Key: INBOX-122
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The DLRL spec uses CORBA valuetypes to specify DLRL objects. The implementations of these CORBA valuetypes (e.g. Foo) are completely provided by the DLRL – the user doesn't have to implement anything, which is great from a simplicity standpoint.

    However, this limits the DLRL valuetypes to being not much more that fancy structs with inheritance and relationships, but no behavior.

    One of the capabilities of standard CORBA valuetypes is the ability to specify valuetype operations in IDL and then implement them in the target language. The CORBA valuetype specification has permits the user to write the valuetype's implementation class, providing behavior for the methods specified in IDL. The user then implements a valuetype factory as a hook to create instances of the user-written valuetype implementation.

    I can see a similar comcept as useful to DLRL. It would probably be useful for a user to specify valuetype operations in DLRL IDL and implement them in the target language.
    One way to do this is to have the DLRL compiler generate a Foo class with a pure virtual method for each valuetype operation. The user inherits from it, implementing a MyFoo with implemntations of the pure virtual methods.

    We also need a factory; naturally, we'd use the FooHome. The generated FooHome would include a pure virtual "create()", or something like it, which the user would implement in a derived MyFooHome class to create instances of his MyFoo. Instead of creating a FooHome and registering it with the Cache, the user creates a MyFooHome and registers it with the Cache. The DLRL core uses the MyFooHome's overridden create() method to make new Foo handles (which are actually MyFoo handles, containing the user's behavior).

    There may be holes in this, but the basic idea is probably useful. It would permit a DLRL object model to be a full object model.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Rewrite sentence on page 3-1, section 3.1

  • Key: INBOX-212
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    DLRL is unmistakenly linked with DCPS. DLRL requires DCPS entities to create a cache for example, and one can directly request the publisher or subsriber from such a Cache. A DLRL not built on top of DCPS is not a DLRL at all.

    Solution:
    Replace:
    It is an optional layer that may be built on top of the DCPS layer.

    With:
    It is an optional layer that is built on top of the DCPS layer.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify what happens in the purge operation of the CacheAccess

  • Key: INBOX-171
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The purge operation needs to be further detailed as what the consequences of the operation are. Also the wrong quotation mark at the end of the description needs to be removed as well.

    Solution:

    Replace:
    Detach all contracts (including the contracted DLRL Objects themselves) from the
    CacheAccess (purge)."

    With:
    Detach all Contracts (including the contracted ObjectRoots themselves) from the
    CacheAccess (purge). If the CacheAccess is writeable then the CacheAccess will unregister itself for each purged (previously written) ObjectRoot. If the CacheAccess was the last writeable CacheAccess within the scope of the owning Cache for the purged (previously written) ObjectRoot, then an explicit unregister_instance is performed for that instance at the respective DataWriter entity. A DCPSError is raised if the purge failed due to an error on DCPS level.

    In section 3.2.1.2 on page 3-57 IDL description regarding the CacheAccess interface replace:
    void purge ();
    With:
    void purge () raises (DCPSError);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Which exceptions can be raised under which circumstances?

  • Key: INBOX-187
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The description of the write operation does not specify which exceptions can be thrown. Not that the IDL description on page 3-57 also states the ReadOnlyMode exception can be raised, but that exception no longer exists! So fix this as well. See issue XXX and XXX for mention of the TimeOut and InvalidObjects exceptions.

    Solution:

    Replace:
    o Write objects (write). If the CacheAccess::cache_usage allows write operation, those objects can be modified and/or new objects created for that access and eventually all the performed modifications written for publications.

    With:
    o Write objects (write). If the CacheAccess::cache_usage allows write operation, those objects can be modified and/or new objects created for that access and eventually all the performed modifications written for publications. A PreconditionNotMet is raised if the CacheAccess::cache_usage does not allow the write operation (i.e. usage is READ_ONLY). A TimeOut exception is raised if one of the underlying DCPS DataWriter entities timed out. A DCPSError is raised if the write failed due to an error in the DCPS layer.

    In section 3.2.1.2 on page 3-57 regarding the IDL description of the write() operation of the interface CacheAccess replace:
    void write ()
    raises (
    ReadOnlyMode,
    DCPSError);
    With:
    void write () raises (DCPSError, PreconditionNotMet, InvalidObjects, TimeOut);

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Section: 3.1.4.5

  • Key: INBOX-131
  • Status: pending  
  • Source: Honeywell ( James Richardson)
  • Summary:

    Context: "However an exiting DCPS model by construction is unlikely to rely heavily on inheritance between its ‘classes.’" You mean "existing".

  • Reported: DDS 1.2 — Fri, 22 Sep 2006 04:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Error in the ownership of a SelectionCriterion

  • Key: INBOX-116
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec says that the Selection takes ownership of the SelectionCriterion parameter passed in create_selection (see 3.1.6.3.7, ObjectHome, create_selection bullet item).

    However, this violates CORBA "in" parameter passing semantics, in which the client owns an "in" parameter and is responsible for it.

    The right way (in CORBA terms) to do this is for the client to create the FooSelectionCriterion on the heap, store it in a FooSelectionCriterion_var smart pointer, and let the smart pointer release it when it goes out of scope. The Selection can make a "copy" of the FooSelectionCriterion, presumably by bumping up its reference count.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Enable_all_for_pubsub operation

  • Key: INBOX-199
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Certain QoS settings on DCPS entities may conflict with DLRL usage, such as a history for samples, this cannot be represented within DLRL. Or setting auto_purge_disposed_samples_delay to something else then infinite or settings for coherent updates qos setings

    Solution:
    If such qoS settings are set in conflict with required settings for DLRL a PreconditionNotMet will be raised, explain this in the enable_allfor_pubsub operation.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Relationships to objects that have been deleted are not allowed.

  • Key: INBOX-191
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    It is possible for situations to arise where an ObjectRoot has a relation to an ObjectRoot which has already been deleted. Imagine we have a relationship between class Foo and Class Bar.
    In update round 1 we receive both Foo and Bar and create the relationship from Foo to Bar.
    In update round 2 the Bar object is disposed and thus the read_state is changed to DELETED, at the end of the update round the Bar object is actually deleted, accessing it from that moment on will raise the AlreadyDeleted exception. In this update round the relationship from Foo to Bar has not been reset (this is not unlikely in hybrid (DCPS and DLRL mixed) systems, or even DLRL only systems (topic samples are lost for example).
    If we try to navigate from Foo to the Bar object after update round 2, then we will get that Bar object, however accessing any operation gives us the (runtime) exception AlreadyDeleted.

    Because the above example deals with an error situation (The Foo object should have been updated in update round 2 and the relation to object Bar should have been reset, or the sample doing that shouldn't have been lost) we propose to clarify in the specification that it is NOT allowed to have a relationship to an object with the object state DELETED at the time of a refresh. Such relations should transparently be reset by the DLRL to a NotFound exception and the Foo object in the example should be marked as MODIFIED during the update round the deletion of the related object is detected, a call to the is_xxx_modified operation of the Foo object regarding relation Bar should return true.

    This also ensures that an application can NEVER get an AlreadyDeleted exception unless the application has specifically done something wrong (like maintain a reference to the Bar object in it's own application code and ignored the deletion event).

    Not allowing relationships to objects that are deleted ensures the same behavior is found for all situation involving relations, which is convinient for the application as it doesn't need to take exceptional situation into account but can be assured the middleware resolves such situations in a uniform manner.
    Foo is received but no Bar is available results in NotFound.
    Foo is received, Bar is received as disposed results in NotFound.
    Foo is received, Bar is received, Bar is then disposed results in NotFound.

    Solution:
    Explain the above behavior in the specification.

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Remove the CacheDescription object

  • Key: INBOX-164
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The CacheDescription object is used within the create_cache operation on the CacheFactory only. It is a strange concept; a holder for a name and participant only. Instead one should simply provide the name and participant as parameters to the create_cache operation instead of needing to cumbersomely wrap it in a Cachedescription object.

    Solution:
    We propose to change the signature of the create_cache operation from
    create_cache(CacheUsage cache_usage, CacheDescription description)
    to
    create_cache(string name, CacheUsage cache_usage, DomainParticipant participant);
    Replace (in the table description of the CacheFactory on page 3-19)
    create_cache Cache
    cache_usage CacheUsage
    description CacheDescription

    With:

    create_cache Cache
    name string
    cache_usage CacheUsage
    participant DomainParticipant

    In the text on page 3-19 describing the create_cache operation change the text regarding the CacheDescription to reflect the change as well
    Replace:
    This method takes as a parameter cache_usage, which indicates the future usage of the Cache (namely WRITE_ONLY-no subscription, READ_ONLY-no publication, or READ_WRITE-both modes) and a description of the Cache (at a minimum, this CacheDescription gathers the concerned DomainParticipant as well as a name allocated to the Cache). Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    With:
    This method takes as a parameter name, which represents the name allocate to the Cache; a paramater cache_usage, which indicates the future usage of the Cache (namely WRITE_ONLY-no subscription, READ_ONLY-no publication, or READ_WRITE-both modes) and a parameter participant, which contains the concerned DomainParticipant. Depending on the cache_usage a Publisher, a Subscriber, or both will be created for the unique usage of the Cache. These two objects will be attached to the passed DomainParticipant.

    (see next page for more)

    On page 3-59 in section 3.2.1.2 IDL description replace:
    /************************************************

    • CacheFactory : Factory to create Cache objects
      ************************************************/
      valuetype CacheDescription { public CacheName name; public DDS::DomainParticipant domain; }

      ;
      local interface CacheFactory

      { Cache create_cache ( in CacheUsage cache_usage, in CacheDescription cache_description) raises ( DCPSError, AlreadyExisting); Cache find_cache_by_name( in CacheName name); void delete_cache ( in Cache a_cache); }

      ;
      With:
      /************************************************

    • CacheFactory : Factory to create Cache objects
      ************************************************/
      local interface CacheFactory { Cache create_cache ( In CacheName name; in CacheUsage cache_usage, in DDS::DomainParticipant participant) raises ( DCPSError, AlreadyExisting); Cache find_cache_by_name( in CacheName name); void delete_cache ( in Cache a_cache); }

      ;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

There is a lot of redundancy in the XML file.

  • Key: INBOX-156
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Inheritance is redundantly modeled in both IDL and XML. What to do when there is inheritance according to IDL but not the XML or vice-versa? Also, it is not clear in case of multiple level inheritance (C extends B extends A) which topic should act as the main topic: for class C in this example, is the main topic the one corressponding to the highest parent (A), or the topic corresponding to the closest parent (B)?
    Finally, also the place topic description is very redundant: for each attribute located in the same place topic, the placetopic definition needs to be repeated.

    Solution:

    Our proposal is to not mention the extension topics in the IDL: just use normal class mapping and deduce from the IDL that two classes have an inheritance relationship.
    Furthermore we propose to define the topic definition (with its keydescription outside the scope of the class mapping: each attribute can then just refer to a known topic definition without repeating it.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Cache should have a getter to obtain its related DomainParticipant.

  • Key: INBOX-143
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Currently it is not possible to navigate from a Cache to its underlying DomainParticipant. Such navigation may be convenient because the underlying DomainParticipant may be needed to manage statuses, control connectivity, change QoS settings and assert liveliness.

    Solution:

    Add an attribute to the Cache that refers to the underlying DomainParticipant.

    Section 3.1.6.2, Figure 3-4: Add a DomainParticipant class and a reference from the Cache to that DomainParticipant class. Name the reference "the_participant".

    Section 3.1.6.3.4: Add the following entry to the table:

    Cache
    attributes
    the_participant DDS::DomainParticipant

    Section 3.1.6.3.4
    Replace:

    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

    With:

    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related DomainParticipant (the_participant), Publisher (the_publisher) and Subscriber (the_subscriber).

    Section 3.2.1.2: Add to the IDL of the Cache interface the following line:

    readonly attribute DDS::DomainParticipant the_participant;

  • Reported: DDS 1.2 — Tue, 13 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exceptions for add/put operations on List in section 3.1.6.3.16

  • Key: INBOX-224
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The add/put operations on the List in section 3.1.6.3.16, the add/remove operations on the Set in section 3.1.6.3.17, the put operation in the StrMap in section 3.1.6.3.18 and the put operation in the IntMap in section 3.1.6.3.19 should mention they raise a PreconditionNotMet if:

    • The owner ObjectRoot of the Collection is not contained within a (writeable) CacheAccess
    • The owner ObjectRoot has not yet been registered (i.e. has no identity)
    • Value is NIL
    • In case the Collection represents a MultiRelation (instead of a MultiAttribute)
      o The target (to be added) ObjectRoot has not yet been registered (i.e. has no identity)
      o The target (to be added) ObjectRoot is contained within a different CacheAccess or no CacheAccess
      o The target (to be added) ObjectRoot has already been deleted (different then marked for deletion!)

    The put operation of the List should also state a PreconditionNotMet is raised if the index provided is smaller then 0 or larger then the length of the list.

    In the IDL description in section 3.2.1.2 on page 3-55, 3-56 add the raise clauses to the operations:
    For the list valuetype (also fix type of the first attribute of the List valuetype, operation put which takes an index, not a key as param) replace:
    void add( in ObjectRoot value );
    void put( in long key, in ObjectRoot value );
    with:
    void add( in ObjectRoot value ) raises (PreconditionNotMet);
    void put( in long index, in ObjectRoot value ) raises (PreconditionNotMet);

    For the Set valuetype:
    Replace:
    void add( ObjectRoot value );
    void remove( ObjectRoot value );
    With:
    void add(in ObjectRoot value ) raises (PreconditionNotMet);
    void remove(in ObjectRoot value ) raises (PreconditionNotMet);

    For the StrMap valuetype:
    Replace:
    void put( in string key, in ObjectRoot value );
    With:
    void put( in string key, in ObjectRoot value ) raises(PreconditionNotMet);

    For the IntMap valuetype:
    Replace:
    void put( in long key, in ObjectRoot value );
    With:
    void put( in long key, in ObjectRoot value ) raises (PreconditionNotMet);

    In section 3.2.1.2.2 Implied IDL on page 3-61 and 3-62
    Replace for the FooList:
    void add( in Foo value );
    void put( in long key, in Foo value );
    With:
    void add( in Foo value ) raises (PreconditionNotMet);
    void put( in long index, in Foo value ) raises (PreconditionNotMet);

    Replace for the FooSet:
    void add( in Foo value );
    void remove( in Foo value );
    With:
    void add(in Foo value ) raises (PreconditionNotMet);
    void remove(in Foo value ) raises (PreconditionNotMet);

    Replace for the FooStrMap:
    void put( in string key, in Foo value );
    With:
    void put( in string key, in Foo value ) raises(PreconditionNotMet);

    Replace for the FooIntMap:
    void put( in long key, in Foo value );
    With:
    void put( in long key, in Foo value )raises(PreconditionNotMet);

    Solution:
    TBD

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclear sentence in section 3.1.6.1.1

  • Key: INBOX-206
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The sentence "Even if an object is not changeable by several threads at the same time, there is a need to
    manage concurrent threads of modifications in a consistent manner." Is very unclear as to what is meant. This should be clarified.

    Solution:
    ?

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Usage of Undefined unclear

  • Key: INBOX-148
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Everywhere where the word undefined is used it is not clear what this means, and the word may be used not only for Foo types, but also FooSelection classes, which makes it unclear what an undefined word means in the context. We suggest putting undefined between < and > and to state within the < and > the type which makes:
    <undefined> for Foo
    <undefined>Selection for FooSelection
    Etc.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify what happens with selection->refresh if auto_refresh is true

  • Key: INBOX-177
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.9 regarding the Selection the refresh operation needs to be clarified. I.E. the behavior if the selection is created with auto_refresh set to true (we suggest making it a no-op).

    Solution:
    On page 3-31 in section 3.1.6.3.9
    Replace:
    o request that the Selection updates its members (refresh).
    With:
    o request that the Selection updates its members (refresh). If the Selection was created with auto_refresh set to true, then this operation is considered a no-op.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify typical scenario for write mode of CacheAccess in section 3.1.6.5.2

  • Key: INBOX-158
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Section 3.1.6.5.2 still talks about the clone_object operation, neglects to talk about the create_unregistered_object/register_objects operations and in step 5 it talks about modifying the attached. (attached what?!) it probably should say objects. Also between step 6 and 7 it should say

    Solution:
    Replace:
    3.1.6.5.2 Write Mode
    The typical scenario for write mode is as follows:
    1. Create the CacheAccess for write purpose (Cache::create_access).
    2. Clone some objects in it (ObjectRoot::clone or clone_object).
    3. Refresh them (CacheAccess::refresh).
    4. If needed create new ones for that CacheAccess (ObjectHome:: create_object).
    5. Modify the attached (plain access to the objects).
    6. Write the modifications into the underlying infrastructure (CacheAccess::write).
    7. Purge the cache (CacheAccess::purge); step 2 can be started again.
    8. Eventually, delete the CacheAccess (Cache::delete_access).
    With:
    3.1.6.5.2 Write Mode
    The typical scenario for write mode is as follows:
    1. Create the CacheAccess for write purpose (Cache::create_access).
    2. Attach some cloning contracts to it (CacheAccess::create_contract)
    3. Execute these contracts (CacheAccess::refresh).
    4. If needed create new objects for that CacheAccess (ObjectHome:: create_object or ObjectHome::create_unregistered_object followed by ObjectHome::register_object).
    5. Modify the objects (plain access to the objects).
    6. Write the modifications into the underlying infrastructure (CacheAccess::write).
    7. If needed create new contracts, delete/change exisiting contracts and then goto step 3 again.
    8. Purge the cache (CacheAccess::purge); step 2 can be started again.
    9. Eventually, delete the CacheAccess (Cache::delete_access).

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

samples from the underlying DataReaders

  • Key: INBOX-180
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Clearly state that it is not allowed to directly access information from the underlying DataReaders of a Cache Subscriber. Doing so might modify the status of these samples (for example their view_state and sample_state), potentially corrupting the Cache state as well.

    Solution:

    TBD.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Various typos in section 3.1.6.3.4, Cache

  • Key: INBOX-211
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem (1/5):
    Section 3.1.6.3.4 on the table on page 3-22 errornously states the operations load(), lock() and unlock(), which no longer exist since the previous specification update. They have been removed from the idl as well and figure 3-4, but not here.

    Solution (1/5):
    Remove load(), lock() and unlock() operations from the table on page 3-22

    Problem (2/5):
    Section 3.1.6.3.4 on page 3-24 still contains various descriptions about operations that no longer exist, namely load, deref, lock, unlock. All these operations were removed in the previous spec revision.

    Solution (2/5):
    Remove the following texts:
    o explicitly request taking into account the waiting incoming updates (load). In case
    updates_enabled is TRUE, the load operation does nothing because the updates are
    taken into account on the fly; in case updates_enabled is FALSE, the load operation
    'takes' all the waiting incoming updates and applies them in the Cache. The load
    operation does not trigger any listener (while automatic taking into account of the
    updates does - see Section 3.1.6.4, "Listeners Activation," on page 3-41 for more
    details on listener activation) and may therefore be useful in particular for global
    initialization of the Cache.
    o transform an ObjectReference to the corresponding ObjectRoot. This operation can
    return the already instantiated ObjectRoot or create one if not already done. These
    ObjectRoot are not modifiable (modifications are only allowed on cloned objects
    attached to a CacheAccess in write mode).
    o lock the Cache with respect to all other modifications, either from the infrastructure
    or from other application threads. This operation ensures that several operations can
    be performed on the same Cache state (i.e., cloning of several objects in a
    CacheAccess). This operation blocks until the Cache can be allocated to the calling
    thread and the waiting time is limited by a time-out (to_in_milliseconds). In case
    the time-out expired before the lock can be granted, an exception (ExpiredTimeOut)
    is raised.
    o unlock the Cache.

    Problem (3/5):
    In section 3.1.6.3.4 on page 3-24 in the middle of the page an indent is missing for the following text. And the paragraph is also ended with a ':', which should be a '.'. In the middle of the text, behind the first bold, italic word Cache it also has a ':', which should be a ';'

    Solution (3/5):
    Replace:
    The purpose of the CacheAccess must be compatible with the usage mode of the Cache:
    only a Cache that is write-enabled can create a CacheAccess that allows writing.
    Violating this rule will raise a PreconditionNotMet:

    With:
    The purpose of the CacheAccess must be compatible with the usage mode of the Cache;
    only a Cache that is write-enabled can create a CacheAccess that allows writing.
    Violating this rule will raise a PreconditionNotMet.

    Problem (4/5):
    Section 3.1.6.3.4 on page 3-22 right underneath the table gives an overview of the attributes of the Cache. The first bullet takes three attributes into one description, while everywhere else separate bullets are used for each attribute. This should be no different.

    Solution (4/5):
    Replace:
    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

    With:
    · the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state)

    · the related Publisher (the_publisher)

    · the related Subscriber (the_subscriber).

    Problem (5/5):

    In the description of the disable_updates() operation of the Cache in section 3.1.6.3.4 on page 3-22 still talks about the possibility of updates being interrupted. This 'possibility' was removed in the previous spec revision. An update round will always be finished normally.

    Solution (5/5):
    Replace:
    disable_updates causes incoming but not yet applied updates to be registered for further application. If it is called in the middle of a set of updates (see Listener operations), the Listener will receive end_updates with a parameter that indicates that the updates have been interrupted.
    With:
    disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

cloned objects

  • Key: INBOX-185
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    What should happen to cloned objects that, when the CacheAccess is refreshed, are no longer covered by any contract? You cannot just treat them as if they were deleted.

    Solution:

    Probably a special state needs to be introduced for this called NOT_COMPLIANT.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Extend the XML to allow optional relationships

  • Key: INBOX-141
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:

    Extend the XML to allow optional relationships (i.e. relationships with a cardinality of 0..1). This way it is always possible to explicitly allow NULL pointer relations, even in case of predefined mapping.

    Solution:

    An optional relationship should be accompanied by a boolean field that specifies whether the foreign keyfields should be interpreted or not.

    TBD.

  • Reported: DDS 1.2 — Wed, 14 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Unclarities in section 3.1.4.2.3

  • Key: INBOX-209
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    Various things are unclear in this section, for example the last bulleted list in this section does not take the Set type of a multi-valued attribute into account. A bullet needs to be added to state that the set does not contain an index key. Also replace 'row' with the word 'instance' in accordance with other issues. Also it needs to be indicated that in case of predefined mapping that the user defined keys identify the object, not the OID.
    In accordance with another issue, replace the word 'row' with 'instance'. Replace the word 'cell' with 'field'

    Solution:

    Replace:
    Mono-valued attributes and relations are mapped to one (or several) cell(s)7 in a single row whose key is the means to unambiguously reference the DLRL object (i.e., its oid or its full oid, depending on the owner class characteristics as indicated in the previous section):
    With:
    Mono-valued attributes and relations are mapped to one (or several) field(s)7 in a single instance whose key is the means to unambiguously reference the DLRL object (i.e. its oid, its full oid, or its user defined keys, depending on the owner class characteristics as indicated in the previous section):

    Replace (in the first bulleted list of the section):
    reference to another DLRL object (i.e., relation) -> as many cells as needed to reference unambiguously the referenced object (i.e., its oid, or its full oid as indicated in the previous section).
    With:
    reference to another DLRL object (i.e., relation) -> as many fields as needed to reference unambiguously the referenced object (i.e., its oid, its full oid, or its user defined keys as indicated in the previous section).

    Replace:
    Multi-valued attributes are mapped to one (or several) cell(s) in a set of rows (as many as there are items in the collection), whose key is the means to unambiguously designate the DLRL object (i.e., oid or full oid) plus an index in the collection.
    o For each item, there is one instance that contains the following, based on the type of attribute:
    o simple basic type -> one cell of the corresponding DCPS type;
    o enumeration -> one cell of type integer or string;
    o simple structures -> as many cells as needed to hold the structure;
    o reference to another DLRL object -> as many cells as needed to reference unambiguously the referenced object (i.e., its oid, or its full oid as indicated in the previous section).
    o The key for that row is the means to designate the owner's object (i.e., its oid or full oid) + an index, which is:
    o An integer if the collection basis is a list (to hold the rank of the item in the list).
    o A string or an integer9 if the collection basis is a map (to hold the access key of the item in the map).
    With:
    Multi-valued attributes are mapped to one (or several) field(s) in a set of instances (as many as there are items in the collection), whose key is the means to unambiguously designate the DLRL object (i.e., oid or full oid, or its user defined keys) plus an optional index in the collection.
    o For each item, there is one instance that contains the following, based on the type of attribute:
    o simple basic type -> one field of the corresponding DCPS type;
    o enumeration -> one field of type integer or string;
    o simple structures -> as many fields as needed to hold the structure;
    o reference to another DLRL object -> as many fields as needed to reference unambiguously the referenced object (i.e., its oid, its full oid, or its user defined keys as indicated in the previous section).
    o The key for that row is the means to designate the owner's object (i.e., its oid, full oid, or its user defined keys) + an optional index, which is:
    o An integer if the collection basis is a list (to hold the rank of the item in the list).
    o A string or an integer9 if the collection basis is a map (to hold the access key of the item in the map).
    o No index if the collection basis is a set (The item value field is implicitly the key in this case)

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Need clarification on limitations of bi-directional association

  • Key: INBOX-127
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    Bi-directional associations involving multi-relations (either 1-to-N or M-to-N) and underspecified. Modifications to one side of a bi-directional relationship is supposed to be automatically reflected in the other side of the relationship, (see 3.1.3.2.2) but that is not always possible given the provided Collection interfaces.

    The behavior is clear if one of the multi-relations involved is a Set.
    A change one side of the association causes an add/remove on the Set side of the association.

    The behavior is interpretable if one of the multi-relations involved is a List. In a UML 1-to-N or M-to-N relationship, is is expected that there will not be duplicate entries in the "multi" side of the relationship. In other words, in a Foo<->*Bar relationship, the same Bar will not occur more than once in the Foo's list of Bars. Using this interpretation, you can interpret a n "add" to the non-List side of the relationship as implying that a new object is added to the end of the list, and a "remove" as implying that the object is removed from the List. In other words, we can treat the List just like a Set and allow changes to the association from both sides.

    The caveat is that you can't have duplicate entries in a List that is involved in a bi-directional association. (Then again, what if you modify the association from the List side, and you put duplicate values? Do we allow that?)

    Bi-directional assoications get very tricky when IntMaps or StrMaps are involved.

    If two maps are involved (e.g. IntMap to StrMap), then it is impossible to modify the association. If I add to it from the IntMap side, then I have to somehow specify the key to use on the StrMap side. The Collection interfaces provide no mechanism to to this.

    If only one map is involved (either 1-to-N or M-to-N), then I must to all modifications from the map side. Otherwise, I have no way to indicate the Map key when I modify the association.

    So, the specification need to be clarified on bi-directional associations:

    1. The behavior of a List in a bi-directional association must be clarified. Is what I said above correct, or should there be limitations on how you can use a List in a bi-directional association?

    2. The usage of IntMaps and StrMaps must be clarified. There are several possibilities:

    a. IntMaps and StrMaps are not allowed in bi-directional associations
    b. IntMaps and StrMaps are allowed, but you must make all modifications to the association from the Map side of the association.
    Map-to-Map associations are not allowed.
    c. All types of associations are allowed, and the OMG will add to the Collection API to provide the methods needed to set the map keys appropriately from either direction

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Request clarification on a WRITE_ONLY CacheAccess, cloning, and refresh()

  • Key: INBOX-123
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The spec is not completely clear on what you can and cannot do with a WRITE_ONLY CacheAccess.

    Is it legal to clone an object into a WRITE_ONLY CacheAccess, or are we only permitted to create brand new objects (via create_object) in a WRITE_ONLY CacheAccess?

    On a related note, is a CacheAccess::refresh() for a WRITE_ONLY CacheAccess always a noop, or should it throw an exception? It seems like it should thrown an exception (such as a WriteOnlyMode exception, which doesn't exist) to be consistent with CacheAccess::write, which throws a ReadOnlyMode exception when you call it from a READ_ONLY CacheAccess.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify usage of find_home_by_name

  • Key: INBOX-137
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    In section 3.1.6.3.4 on page 3-23 in the description of the operation find_home_by_name of the Cache entity it states that an already registered home can be retrieved using its name. It should be clarified that this name is the fully qualified name (in IDL sense, with '::' as seperator). The name of ObjectHome for Object Foo which is defined in module test thus becomes 'test::Foo'.

    Solution:

    Replace:
    o retrieve an already registered ObjectHome based on its name (find_home_by_name) or based on its index of registration (find_home_by_index). If no registered home can be found that satisfies the specified name or index, a NULL is returned.

    With:
    o retrieve an already registered ObjectHome based on its fully qualified name (in IDL sense, meaning for an ObjectHome representing class 'Foo' which was defined in module 'test' has the name "test::Foo") (find_home_by_name) or based on its index of registration (find_home_by_index). If no registered home can be found that satisfies the specified name or index, a NULL pointer is returned.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

Clarify exception condition

  • Key: INBOX-139
  • Status: pending  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    Problem:
    The explaination on page 3-24 for the create_cache operation states that a PreconditionNotMet is only raised if the usage of the access is not compatiable with the usage of the cache. It should also say that a PreconditionNotMet is raised if an access is attempted to be created while the cache is not yet enabled for pub sub.

    Solution:
    Add the new reason in the description.

  • Reported: DDS 1.2 — Mon, 12 Feb 2007 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

DLRL Issue: Diagrams in Fig 3.5 and Fig 3.6 look improperly captioned

  • Key: INBOX-124
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    It looks like the Fig 3.5 and Fig 3.6 diagrams have incorrect captions.
    I believe they should be corrected as follows:

    Fig 3.5: "read_state" and "write_state" should be swapped; the VOID diagram refers to read_state. The caption on the right-hand state chart should be "read_state of a Cache object in READ_ONLY or READ_WRITE mode".

    Fig 3.6's first state chart should have a caption that reads "read_state of a CacheAccess object in READ_ONLY or READ_WRITE mode"; the second state chart's caption should read "CacheAccess object", not just "CacheAccess"

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

IDL interfaces for ObjectListener and FooListener are inconsistent

  • Key: INBOX-115
  • Status: pending  
  • Source: OCI ( Don Busch)
  • Summary:

    The base IDL and implied IDL are inconsistent for ObjectListener and FooListener:

    1. The return values are "boolean" in the base class, "void" in the derived. Should be "boolean" for all.
    2. The comments in ObjectListener IDL imply that only on_object_modified has a Foo-specific version generated in the derived class. But FooListener has Foo-specific versions for all three operations. FooListener version is correct.

  • Reported: DDS 1.2 — Fri, 22 Dec 2006 05:00 GMT
  • Updated: Mon, 2 May 2016 03:26 GMT
  • Attachments:

clarify allowable (spec compliant) ways to implement ObjectReference[].

  • Key: INBOX-109
  • Status: pending  
  • Source: Jackrabbit Consulting ( Mrs. Charlotte Wales)
  • Summary:

    Need to clarify and/or enumerate allowable (spec compliant) ways to implement ObjectReference[]. The method definitions have return values or parameters specified by ObjectReference[]. Given that this is part of the platform independent model, it would appear that one could approach the implementation of this in C++ in one of two ways – as std::vector<ObjectReference *> or as an ObjectReference array. It is unclear which would be the preferred spec compliant way to do this. Alternatively, one could implement this as a language specific container, vector, list, map or whatever is the best performing container for the given situation, but would that not be in compliance with the spec at all?

  • Reported: DDS 1.1 — Fri, 14 Apr 2006 04:00 GMT
  • Updated: Wed, 27 Apr 2016 12:21 GMT
  • Attachments: