C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — Open Issues

  • Acronym: C
  • Issues Count: 404
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Summary

Key Issue Reported Fixed Disposition Status
COMMONS-1 The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary COMMONS 1.0a1 open
COMMONS-6 Some of the commons ontologies include double spaces in annotations COMMONS 1.0a1 open
COMMONS-9 The constraint on a classifier that says it must classify something is too restrictive COMMONS 1.0a1 open
COMMONS-11 Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme COMMONS 1.0a1 open
CSRM11-3 Create examples of use of the profile CSRM 1.0b1 open
COMMONS-5 Examples are needed to help explain to Commons users how to use the ontologies COMMONS 1.0a1 open
COMMONS-4 Some of the diagrams in Clause 8 are difficult to read COMMONS 1.0a1 open
COMMONS-3 The format of the tables throughout the specification needs improvement COMMONS 1.0a1 open
COMMONS-2 The terms and definitions section of the Commons Ontology Library is incomplete COMMONS 1.0a1 open
CSRM-4 Add constraints to aid in correctness of profile useage CSRM 1.0b1 open
CSRM-1 Icons for profile CSRM 1.0b1 open
CSRM11-1 Icons for profile CSRM 1.0b1 open
CSRM-12 Recommended Additions CSRM 1.0a1 open
CSRM11-4 Recommended Additions CSRM 1.0a1 open
CSRM-5 Create examples of use of the profile CSRM 1.0b1 open
CSRM11-2 Add constraints to aid in correctness of profile useage CSRM 1.0b1 open
CSRM-9 Change names from CubeSat to Satellite. CSRM 1.0b1 open
CSRM-16 Remove Section 0 from the document CSRM 1.0a1 open
CSRM-35 Clarify usage of Group stereotype CSRM 1.0a1 open
CSRM-31 Add comments to 7.6.3 ExtRequirement source/Risk elements CSRM 1.0a1 open
CSRM-28 MeasurementSpecification missing documentation CSRM 1.0a1 open
CSRM-26 VerificationActivity missing documentation on verificaionMethod CSRM 1.0a1 open
CSRM-3 Change 7.6 SysML Extentions CSRM 1.0b1 open
CSRM-2 Add relationship convenience attribute for Validated and other relationships CSRM 1.0b1 open
CSRM-41 Modify Paragraph 2 to remove redundant reference to the machine readable file. CSRM 1.0a1 open
CORBARS_-1 Provide a simple sample application CORBA-REST 1.0b1 open
CORBARS_-2 Provide example of authentication and security CORBA-REST 1.0b1 open
C2MS11-101 Text for AMVAL REQ references non-existing fields C2MS 1.0 open
C2MS11-54 VCID and APID in Message Subject for TLMTDM Frame C2MS 1.0 open
C2MS11-88 Create CMD-MNEMONIC Field in Command Request Message C2MS 1.0 open
C2MS11-13 Add documentation within the model C2MS 1.0a1 open
C2MS11-4 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 open
C2MS11-39 Add field APID (and VCID) to Telemetry CCSDS Packet Message C2MS 1.0 open
C2MS11-42 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 open
C2MS11-49 Consider Renaming "Header String" type to "Subject Token String" C2MS 1.0 open
C2MS11-56 Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message C2MS 1.0 open
C2MS11-87 Missing Echo Request C2MS 1.0 open
C2MS11-19 Larger Data Types C2MS 1.0 open
C2MS11-20 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 open
C2MS11-21 Larger Data Types C2MS 1.0 open
C2MS11-46 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS11-55 REQUEST-ID as "Replacement" and related STOP C2MS 1.0 open
C2MS11-16 REQUEST-ID field does not support usage as a GUID C2MS 1.0 open
C2MS11-17 Make Fields Table and UML Match the Order of Fields for greater Readabliity C2MS 1.0 open
C2MS11-25 Make all subjects be buildable from fields in the message C2MS 1.0 open
C2MS11-26 Document that Header String type is to be at least one ASCII character C2MS 1.0 open
C2MS11-29 In Message Header, make NODE and USER-NAME string rather than Header String C2MS 1.0 open
C2MS11-30 Clarify the ".... Message Header Notes" tables re: being included in each message C2MS 1.0 open
C2MS11-28 Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header C2MS 1.0 open
C2MS11-32 Add field for USER to Message Header C2MS 1.0 open
C2MS11-38 In the Control Message, the field CNTL-STRING should be required C2MS 1.0 open
C2MS11-40 Control Message SPECIAL_INFO Field type should be String C2MS 1.0 open
C2MS11-48 Add Message-level Security Constructs C2MS 1.0 open
C2MS11-22 Message-level Security Credentials C2MS 1.0 open
C2MS11-31 Clarify the UML diagrams regarding the values for the fields inherited from Message Header C2MS 1.0 open
C2MS11-18 All Messages Subclass Message Header C2MS 1.0 open
C2MS11-33 Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS C2MS 1.0 open
C2MS11-75 Move Tracking Fields to a "Message Envelope" C2MS 1.0 open
C2MS11-36 Add DESTINATION-NODE and DESTINATION-FACILITY as fields C2MS 1.0 open
C2MS11-23 In message tables, rework the "value" column to allow for fixed values vs. default values C2MS 1.0 open
C2MS11-24 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 open
C2MS11-45 C2MS Database Query (DBQUERY) messages C2MS 1.0 open
C2MS11-47 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS11-83 Consider forcing a limited subscription C2MS 1.0 open
C2MS11-90 Real-world STREAM-MODE Issues C2MS 1.0 open
C2MS11-7 XML PSM recommended C2MS 1.0b1 open
C2MS11-2 C2CX Heartbeat comments C2MS 1.0a1 open
C2INAV12-1 Use @key instead of @Key C2INAV 1.0 open
CPP1116-37 6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive"i CPP11 1.5 open
C2MS11-43 Deprecate Archive Message Retrieval Messages C2MS 1.0 open
C2MS11-44 Consider a mechanism to request archived Commands and Events C2MS 1.0 open
C2MS11-41 C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC C2MS 1.0 open
C2MS11-8 Acknowledge Final Status inconsistency C2MS 1.0b1 open
C2MS11-37 Remove value for CNTL-STRING from CNTL message C2MS 1.0 open
C2MS11-34 In message Archive Message Retrieval Response, fix Header field names C2MS 1.0 open
C2MS11-15 Log message scope too broad, need Alert/Status style message introduced C2MS 1.0b2 open
C2MS11-14 Specify multiplicity for required and optional fields C2MS 1.0a1 open
C2MS11-10 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 open
C2MS11-35 Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects C2MS 1.0 open
C2MS11-27 Time Type table clarification for the DDD portion C2MS 1.0 open
C2MS11-11 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 open
C2MS11-3 Archive Mnemonic Value Request comments C2MS 1.0a1 open
CORBA34-905 Add CompressorId for zstd CORBA 3.4 open
CPP1116-36 Typo in example CPP11 1.5 open
CORBA34-904 Extend InvalidName exception CORBA 3.4 open
API4KP-17 Use RFC7231 for Error reporting CMMN 1.1 open
CORBA34-903 Replace Cookie with a string and use IDL map CORBA 3.4 open
CPP11-267 Extend Union mapping CPP 1.3 open
CORBA34-902 Add CDR marshaling support for IDL4 int8/uint8/map/biset/bitfield/bitmask CORBA 3.3 open
ABPSC-33 URLs, URIs and namespaces for CMMN 1.1 XSDs are not aligned CMMN 1.1 open
C2MS11-5 Data Dictionary Messages C2MS 1.0b1 open
DDS4CCM11-18 Editorial corrections CCCMP 1.0 open
DDS4CCM11-17 Use of symbolic constant as string or sequence bound CCCMP 1.0 open
DDS4CCM11-16 Typos at figure 8.6 Constant example CCCMP 1.0 open
C2MS11-1 Lack of a registry concept C2MS 1.0a1 open
C2MS11-12 "Mnemonic" should be called "Parameter" C2MS 1.0b1 open
C2MS11-9 Pub/Sub subscription status unknown C2MS 1.0b1 open
C2MS11-6 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 open
CORP-10 Support alternative way of modeling single dimension CORBAArray CORP 1.0b1 open
CORP-9 Use of expression as sequence/array bound CORP 1.0b1 open
CORP-8 Missing support for IDL "native" CORP 1.0b1 open
CCCMP-16 Bounded string attribute of struct/union/valuetype/interface is not mapped CCCMP 1.0 open
CR-154 Clarify semantics of None Event Listeners CMMN 1.1 open
CCCMP-15 Extended UML metamodel derivations of <> CCCMP 1.0 open
CR-153 Inconsistent spelling of color attributes in text, MM and XSD CMMN 1.1 open
CR-152 An Initial transition can't contain any trigger/event CMMN 1.1 open
CR-151 autoComplete doesn't take into account the event listeners CMMN 1.1 open
CR-150 Figure 7.4 'CMMN Shape' shows attribute isExpanded instead of isCollapsed CMMN 1.1 open
CR-148 Wrong manual activation default and missing defaults for ManualActivationRules, RequiredRules and RepetitionRules without condition CMMN 1.1 open
CR-149 Name missmatch between Table 5.51 and MM/XSD for condition of RequiredRules CMMN 1.1 open
CR-146 Process Task and Case Task should have performer defined CMMN 1.1 open
CR-147 Allow the possibility to define multiple standard events for an onPart CMMN 1.1 open
CTS213-13 Faulty CTS2 1.1 wsdl files CTS2 1.2 open
COLL-16 semantics of boolean iterator.next(out thing) ... COLL 1.0b1 open
CWM12-17 21.5 SQL-99 Data Types CWM 1.1 open
CWM12-71 Review the semantics of existing attribute types that are also CWM classes CWM 1.0 open
CWM12-57 CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0 CWM 1.0 open
CWM12-70 Add a representation for sequence to CWM relational package CWM 1.0 open
CWM12-56 Make ChangeRequest useful CWM 1.0 open
CWM12-22 Location: 12.1 Overview CWM 1.1 open
CWM12-76 CWM Object resource package does not provide support for exceptions CWM 1.0 open
CWM12-7 Location: 5.4 CWM 1.1 open
CWM12-11 Annex F: Acknowledgements CWM 1.1 open
CWM12-64 The XML package should be revised/extended to represent XML schema metadata CWM 1.0 open
CWM12-39 Location: 3 Normative References -- OCL CWM 1.1 open
CWM12-16 21.6 Type Mapping Examples CWM 1.1 open
CWM12-14 Annex A: References CWM 1.1 open
CWM12-5 Add features for 11404 aggregates CWM 1.1 open
CWM12-47 TaggedValue CWM 1.1 open
CWM12-53 Modeling and packaging guidelines CWM 1.0 open
CWM12-54 Rationalize 'Measurement' CWM 1.0 open
CWM12-50 SQLParameter CWM 1.1 open
CWM12-42 Introduction - references CWM 1.1 open
CWM12-26 Location: 10.3.16 SQLIndex CWM 1.1 open
CWM12-9 Introduction, Page XVII CWM 1.1 open
CWM12-2 The XML features should support current XML data structures CWM 1.1 open
CWM12-38 Location: 4 Abbreviations and Conventions - ODBC CWM 1.1 open
CWM12-1 Add support for flat and nested N-dimensional arrays CWM 1.1 open
CWM12-41 Location: 3 Normative References CWM 1.1 open
CWM12-24 10.3.18 SQLParameter CWM 1.1 open
CWM12-69 Inconsistencies caused by changing Expression etc from Data Types to Classe CWM 1.0 open
CWM12-52 Warehouse processes missing physical information CWM 1.0 open
CWM12-27 Location: 10.2.8 Procedures CWM 1.1 open
CWM12-61 Inadequate support for Organizational Structures CWM 1.0 open
CWM12-45 figure 6, page 212 CWM 1.1 open
CWM12-21 10.3.20 SQLStructuredType - referencingColumn CWM 1.1 open
CWM12-34 4 Abbreviations and Conventions - SQL-92 and SQL-99 CWM 1.1 open
CWM12-20 13.3.9 Schema CWM 1.1 open
CWM12-58 CWM should consider generating XMI 1.2 DTDs CWM 1.0 open
CWM12-48 Invalid explicit references for some 'association generalizations' in the CWM 1.1 open
CWM12-73 consider changing DeployedComponent from being subclass of Core::Package CWM 1.0 open
CWM12-65 Generic Data Mining metamodel issue CWM 1.0 open
CWM12-3 Support the full set of 11404 aggregates. CWM 1.1 open
CWM12-31 Location: 10.2.4 Structured Types and Object Extension , Figure 10.5 CWM 1.1 open
CWM12-12 Annex D: Legal Information CWM 1.1 open
CWM12-60 CWM should consider using MOF 1.4 for it's metamodel CWM 1.0 open
CWM12-66 The metamodel for DTD should be reviewed CWM 1.0 open
CWM12-51 We only need one COBOL Data Division metamodel. CWM 1.1 open
CWM12-33 Location: 10.1 Overview CWM 1.1 open
CWM12-30 Location: 10.2.6 Index CWM 1.1 open
CWM12-19 10.4.2 ColumnRefStructuredType CWM 1.1 open
CWM12-18 13.1 Overview CWM 1.1 open
CWM12-13 Annex C: Glossary CWM 1.1 open
CWM12-55 Predefined' values not defined in metamodel CWM 1.0 open
CWM12-59 Component Re-use unclear CWM 1.0 open
CWM12-62 Make it easier to interchange UML Models CWM 1.0 open
CWM12-46 Parameter CWM 1.1 open
CWM12-32 Location: 10.2.4 Structured Types and Object Extensions CWM 1.1 open
CWM12-29 Location: 10.3.15 SQLDistinctType CWM 1.1 open
CWM12-77 supplierDependency reference is missing from ModelElement CWM 1.0 open
CWM12-68 Description, Document, ResponsibleParty should be made subtypes of Comment CWM 1.0 open
CWM12-37 Location: 3 Normative References - ISO/IEC 9075:2003 Database language SQL CWM 1.1 open
CWM12-35 Location: 10.1 Overview CWM 1.1 open
CWM12-49 page 9-276/Section: 9.3.22 of ptc/2002-01-02 -- CWM issue CWM 1.1 open
CWM12-23 10.3.20 SQLStructuredType CWM 1.1 open
CWM12-74 package may fail to permit definition of transformations CWM 1.0 open
CWM12-75 XML Schema package issue CWM 1.0 open
CWM12-78 XML metamodel should be based on W3C XML Information Set CWM 1.0 open
CWM12-8 Add syntax type to the metamodel. CWM 1.1 open
CWM12-15 Annex B: Compatibility with other Standards CWM 1.1 open
CWM12-6 value "name" attribute of ModelElement CWM 1.1 open
CWM12-4 Add datatype generators CWM 1.1 open
CWM12-63 Practical changes to Contact metamodel CWM 1.0 open
CWM12-67 All OCL sections should be reviewed to ensure that they are complete CWM 1.0 open
CWM12-40 Location: 4 Abbreviations and Conventions CWM 1.1 open
CWM12-36 Location: 4 Abbreviations and Conventions - SQL CWM 1.1 open
CWM12-44 Foreword CWM 1.1 open
CWM12-43 formal/03-03-02 CWM 1.1 open
CPP13-1 1.16.3 Extraction from any CPP 1.1 open
CWM12-10 5.4 datatype attributes don't incorporate the features of 11404 datatype CWM 1.1 open
CWM12-72 Identify precise CWM definition to which interchange doc. conforms CWM 1.0 open
CWM12-28 Location: 10.3.14 SQLDataType CWM 1.1 open
CWM12-25 10.3.17 SQLIndexColumn CWM 1.1 open
COLL-15 IDL does not match COLL 1.0b1 open
COLL-14 Suggested changes to Collection spec. COLL 1.0b1 open
COLL-13 Failure behavior for iterator operations COLL 1.0b1 open
CPP13-81 Practical problem with DII using Request Pseudo Object CPP 1.0b1 open
COLL-9 Interface OrderedCollection COLL 1.0b1 open
COLL-8 Page 17-29: OrderedCollection.remove_element_at_position COLL 1.0b1 open
COLL-7 Page 17-26: Collection.all_elements_do COLL 1.0b1 open
COLL-6 page 17-23: Collection.remove_all COLL 1.0b1 open
COLL-5 Collection.add_element COLL 1.0b1 open
COLL-4 Map/SortedMap COLL 1.0b1 open
COLL-3 CORBAservices (editorial page 17-74, 17-75) COLL 1.0b1 open
COLL-2 CORBAservices (editorial page 17-71 to 17-73) COLL 1.0b1 open
COLL-1 Error in CosCollection information COLL 1.0b1 open
CORP-1 Section: 3.5.19 - 3.5.20 CORP 1.0b1 open
CCCMP-3 Section 9 of UML Profile for CORBA and CCM CCCMP 1.0 open
CCCMP-2 Section: 8.2.1 - 2 CCCMP 1.0 open
CCCMP-1 Section: 8.1.2 CCCMP 1.0 open
CCCMP-4 Inconsistent capitalization of <> CCCMP 1.0 open
CCMP-1 definition of the stereotype CORBAPrimaryKey CCMP 1.0b1 open
CCMP-3 Facet and Receptacles (ports) CCMP 1.0b1 open
CCMP-2 The (IDL) definition of the example is not correct CCMP 1.0b1 open
CCMP-4 Event ports CCMP 1.0b1 open
CCMP-6 Association needed CCMP 1.0b1 open
CCMP-5 Figure6: associations described Event ports have to be composite associatio CCMP 1.0b1 open
CSAR-1 Text and Java API differ on return value for seacrhChemicalElements method CSAR 1.0 open
CURR11-21 Place maximums on wstrings for interoperability CURR 1.0 open
CURR11-15 Add interfaces to DTime properly handle the DAmountOfTime difference inter CURR 1.0 open
CURR11-17 Improve text in specification of of DAmountOfTime CURR 1.0 open
CURR11-16 Support millisecond precision in DAmountOfTime CURR 1.0 open
CURR11-20 Changing RoundType.DONT_ROUND CURR 1.0 open
CURR11-19 Add ability to clone Money CURR 1.0 open
CURR11-23 Remove Depedence in FBCCurrency of CBO::DDecimal CURR 1.0 open
CURR11-22 Remove Dependence in FBCCurrency of CBO::DTime CURR 1.0 open
CURR11-18 Remove dependence on a specific version of the ISO 4217 standard CURR 1.0 open
CURR11-8 : Change name of interface to CBO::Decima CURR 1.0 open
CURR11-7 Corrections to the equals/setEquals interfaces of DTime CURR 1.0 open
CURR11-6 Improve DTime exception handling CURR 1.0 open
CURR11-14 Add interface to DTime CURR 1.0 open
CURR11-13 Clarification required on setYear of the DTime interface CURR 1.0 open
CURR11-12 support to set precision to something other than milliseconds CURR 1.0 open
CURR11-5 describe how the individual components should be accessed CURR 1.0 open
CURR11-4 Description of Exception handling semantics CURR 1.0 open
CURR11-3 Add text for DTime and DDecimal from CBO submission into Currency spec. CURR 1.0 open
CURR11-11 : Change name of interface to CBO::Time CURR 1.0 open
CURR11-10 Add interfaces to DDecimal CURR 1.0 open
CURR11-9 Clarify the equality method of DDecimal CURR 1.0 open
CURR11-2 The idl for CBO::DTime needs the method: long getYear() CURR 1.0 open
CURR11-1 Clairfy comparisons of two CBO::Ddecimal values on equality CURR 1.0 open
C2WSDL12-1 Section: 4.1.9 SOAP Binding C2WSDL 1.2 open
COAS-3 GCPR issue: Asynchronous COAS COAS 1.0 open
COAS-2 GCPR Project issue: Delivering Observation Data COAS 1.0 open
COAS-1 new conformance classes and the Naming Service COAS 1.0b1 open
COAS-6 GCPR issue: Updating IDL for Examples COAS 1.0 open
COAS-5 GCPR Issue: Using Relational Operators COAS 1.0 open
COAS-4 GCPR Issue: Event Interface Enhancements COAS 1.0 open
COBOL-2 COBOL Language Mapping Section: 1.2.1.2 COBOL 1.0 open
COBOL-1 anomaly in that unsigned integers are mapped to signed integers COBOL 1.0 open
COBOL-3 Mapping of short and long COBOL 1.0 open
CAD11-7 different tessellation structures for different kind of entities CAD 1.1 open
CAD11-6 CadFoundation::EntityPropsStruct CAD 1.0 open
CAD11-13 CadBrep::OrientedEdge interface issue CAD 1.1 open
CAD11-12 CadBrep module issue CAD 1.1 open
CAD11-17 Documentation for CadMain::Model::unique_entities() CAD 1.1 open
CAD11-16 CadMain::Model interface issue CAD 1.1 open
CAD11-15 Data in CadGeometry::EdgeTessellationStuct CAD 1.1 open
CAD11-14 CADServices 1.1 issue CAD 1.1 open
CAD11-9 exception CadConnection::BadParameter does not match the method anymore CAD 1.1 open
CAD11-8 return value of CadFoundation::Entity::cad_model() CAD 1.0 open
CAD11-11 method CadMain::Model::unique_ids_to_entities() CAD 1.1 open
CAD11-10 description for CadMain::Model::unique_ids_to_entities() is missing CAD 1.1 open
CAD11-5 Model creation parameters CAD 1.1 open
CAD11-4 File CadMain: Method add_child and remove_child CAD 1.0 open
CAD11-1 File CadGeometryExtens CAD 1.0 open
CAD11-3 struct OffsetCurveStruct CAD 1.0 open
CAD11-2 struct HyperbolaStruct should be moved from CadSurface to CadCurve CAD 1.0 open
CPP13-67 Section: 13.6 Server mapping CPP 1.1 open
CPP13-66 Concrete ValueType _init class problem CPP 1.1 open
CPP13-63 _var's and valuetypes CPP 1.2 open
CPP13-62 conversion algorithm not specified CPP 1.1 open
CPP13-58 Fixed and truncation/rounding? CPP 1.1 open
CPP13-57 ServantBase needs _get_domain_managers()? CPP 1.1 open
CPP13-65 Sequence _var needs const operator [] CPP 1.2 open
CPP13-64 No portable way to create a OUT argument for a DII request CPP 1.1 open
CPP13-61 Prohibit extracting from any into _out type? CPP 1.1 open
CPP13-60 Add set of typedefs that would facilitate template programming CPP 1.1 open
CPP13-70 need unchecked narrow CPP 1.2 open
CPP13-69 valuetype example has errors CPP 1.2 open
CPP13-59 UTF-8 and IDL character types in C++ CPP 1.1 open
CPP13-68 Describe operator != and == for all generated types CPP 1.2 open
CPP13-53 Optional parameters for _create_request? CPP 1.1 open
CPP13-52 ORB::destroy() missing CPP 1.1 open
CPP13-54 Passing two context lists to _create_request() CPP 1.1 open
CPP13-50 CORBA::RequestSeq or CORBA::ORB::RequestSeq? CPP 1.1 open
CPP13-49 _default_POA if no default ORB? CPP 1.1 open
CPP13-51 questions to IDL - C++ mapping ( CORBA 2.3, valuebox) CPP 1.1 open
CPP13-56 Inserters/extractors for boxed strings? CPP 1.1 open
CPP13-55 publication of messaging / unchecked_narrow CPP 1.1 open
CPP13-12 Value Box Mapping CPP 1.0b1 open
CPP13-11 portable includes CPP 1.0b1 open
CPP13-16 Setting the TypeCode of an Any without setting a value CPP 1.0 open
CPP13-15 Value boxes and sensible value issue CPP 1.0b1 open
CPP13-3 C++ _var type widening proposal CPP 1.0b1 open
CPP13-2 include files CPP 1.0b1 open
CPP13-10 Is public _ptr member mandatory? CPP 1.0b1 open
CPP13-9 Need more info for custom marshalled value in C++ CPP 1.0b1 open
CPP13-8 Generic extraction of Fixed CPP 1.0b1 open
CPP13-7 Extraction of Fixed from Any CPP 1.0b1 open
CPP13-5 struct containing Fixed type CPP 1.0b1 open
CPP13-4 Section 7.3.6: PortableServer::ValueRefCountBase CPP 1.0b1 open
CPP13-13 Valuetypes as operation arguments CPP 1.0b1 open
CPP13-14 Memory management of recursive value CPP 1.0b1 open
CPP13-6 Extraction of strings from an Any CPP 1.0b1 open
CPP13-45 unclear semantics for valuetype insertion into Any CPP 1.1 open
CPP13-44 Any insertion for Boolean/Octet/Char CPP 1.1 open
CPP13-47 CORBA::Environment for EH compilers CPP 1.1 open
CPP13-46 unspecified criterion for Any extraction CPP 1.1 open
CPP13-48 CORBA::release and CORBA::is_nil on POA_ptr CPP 1.1 open
CPP13-29 fixed-length _var assignment from pointer CPP 1.1 open
CPP13-28 UnknownUserException and stubs CPP 1.1 open
CPP13-22 Exceptions in servant constructors CPP 1.0 open
CPP13-21 Abstract interface and DSI issue with C++ CPP 1.0 open
CPP13-19 _default_POA CPP 1.0 open
CPP13-18 ValueBase::_copy_value clarification CPP 1.0 open
CPP13-27 Construction of _var types CPP 1.1 open
CPP13-26 C++ spec: Valuebase missing get_value_def CPP 1.1 open
CPP13-25 C++ ValueBox & Fixed question CPP 1.1 open
CPP13-20 Problem with AbstractBase definition CPP 1.0 open
CPP13-17 IDL that is not IDL! CPP 1.0 open
CPP13-23 _out types and nested calls CPP 1.0 open
CPP13-24 Any and UnknownUserException CPP 1.1 open
CPP13-43 Supporting typedefs for _var types? CPP 1.1 open
CPP13-42 Variable-length out params and exceptions CPP 1.1 open
CPP13-41 Read-only parameter remnants CPP 1.1 open
CPP13-40 Sequence mapping & custom marshalling CPP 1.1 open
CPP13-35 set_servant and null servant CPP 1.1 open
CPP13-34 ref counting ambiguous? CPP 1.1 open
CPP13-30 Object Reference insertion/extration to Any CPP 1.1 open
CPP13-39 DSI and implicit activation CPP 1.1 open
CPP13-38 void * operations on Any? CPP 1.1 open
CPP13-32 Valuetype "copying" semantics underspecified? (C++ issue # 1) CPP 1.1 open
CPP13-31 ValueBase::_copy_value() function is underspecified CPP 1.1 open
CPP13-33 Valuetype "copying" semantics underspecified? (C++ Issue # 2) CPP 1.1 open
CPP13-36 Issue with valuetypes & inout/out parameters CPP 1.1 open
CPP13-37 Constructor for structures? CPP 1.1 open
C11-55 OpaqueValue needs to be documented in the C Language mapping C 1.1 open
C11-54 Order of structure members C 1.1 open
C11-44 Bound seq buffer allocation C 1.0b1 open
C11-43 Seq buffer deallocation C 1.0b1 open
C11-42 Mapping for Aliases C 1.0b1 open
C11-41 Exception id name C 1.0b1 open
C11-38 Sequence buffer release C 1.0b1 open
C11-37 Sequence buffer initialization C 1.0b1 open
C11-34 Allocation and initialization C 1.0b1 open
C11-33 Exception initialization C 1.0b1 open
C11-40 Argument passing, cases 3 and 6 C 1.0b1 open
C11-39 Exception initialization and release C 1.0b1 open
C11-36 Sequence initialization C 1.0b1 open
C11-35 De-allocation and release C 1.0b1 open
C11-32 System Exception Type C 1.0b1 open
C11-7 implementation hints not specification (Section 14.24.2 last para) C 1.0b1 open
C11-6 Parameter memory freeing problem (Section 14.24.1.para 6) C 1.0b1 open
C11-11 C mapping for sequence (Section 14.11 CORBA 2.0) C 1.0b1 open
C11-10 inconsistent parameter name and order C 1.0b1 open
C11-15 vec10 and CORBA_sequence_long C 1.0b1 open
C11-14 Spec contains mutually inconsistent examples C 1.0b1 open
C11-18 sequence as anonymous type in struct C 1.0b1 open
C11-17 Declare and define Allocators for new sequence type C 1.0b1 open
C11-8 What happens when set_exception called more than once? C 1.0b1 open
C11-13 C mapping for Any C 1.0b1 open
C11-12 Representation of "string" values in an "any" C 1.0b1 open
C11-16 Allocation Functions for sequences of "T" C 1.0b1 open
C11-9 confusing presentation (Section 14.25.4) C 1.0b1 open
C11-53 Error in C language specification C 1.0b1 open
C11-52 Inconsistency in CORBA 2.0 C mapping C 1.0b1 open
C11-47 Example inconsistent with table 20 and table 21 C 1.0b1 open
C11-46 Seq buffer allocation C 1.0b1 open
C11-51 CORBA_string is not defined C 1.0b1 open
C11-50 No defined value for CORBA_OBJECT_NIL C 1.0b1 open
C11-49 Delete 14.17 para 1 C 1.0b1 open
C11-48 Initial state of out parameter pointers C 1.0b1 open
C11-45 release flag & returned data C 1.0b1 open
C11-4 Pseudo-Object underspecification C 1.0b1 open
C11-3 C Language header question C 1.0b1 open
C11-5 Inappropriate information (Sect. 14.23. last paragraph C 1.0b1 open
C11-1 Inout sequence/any behavior with oversized return values C 1.0b1 open
C11-2 Wrong placement of asterics in table C 1.0b1 open
C11-21 memory allocation functions C 1.0b1 open
C11-20 When MUST _buffer of sequence be allocated with _allocbuf C 1.0b1 open
C11-28 Exception release function C 1.0b1 open
C11-27 Exception stringification C 1.0b1 open
C11-25 Sequence buffer management C 1.0b1 open
C11-24 Sequence behavior C 1.0b1 open
C11-31 Minor field of system exceptions C 1.0b1 open
C11-30 Exception identification C 1.0b1 open
C11-26 Scoped sequence naming C 1.0b1 open
C11-22 memory release functions C 1.0b1 open
C11-23 mapping for sequences C 1.0b1 open
C11-29 CORBA_Environment initialization C 1.0b1 open
C11-19 CORBA_sequence_long C 1.0b1 open
CTS213-2 Usage Context Binding Inappropriately Expressed CTS2 1.0 open
CTS213-3 Using enumerations instead of using code systems CTS2 1.0 open
CTS213-1 CTS2: Documentation is incorrect in SpecificEntityList class CTS2 1.1 open
CTS213-11 CTS2: ConceptDomain Binding has no property attribute CTS2 1.1 open
CTS213-10 CTS2: Children/Descendants use inconsistent with Value Set CTS2 1.1 open
CTS213-9 CTS2: SpecificEntityList description is incorrect CTS2 1.1 open
CTS213-12 CTS2: EntityDescription lacks workflow status entry CTS2 1.1 open
CTS213-8 CTS2: "readContext" missing on ResolvedValueSetResolution functions CTS2 1.0 open
CTS213-4 AssociationQueryServices WSDL corrections CTS2 1.0b1 open
CTS213-5 CTS2: Wrong type in CompleteValueSetReference (ValueSetDefinition.xsd) CTS2 1.1 open
CTS213-6 CTS2: ValueSetDefinitionListEntry in ValueSetDefinition.xsd has wrong cardinality CTS2 1.1 open
CTS213-7 CTS2: ResourceList entries have double "entry" items CTS2 1.1 open

Issues Descriptions

The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary

  • Key: COMMONS-1
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    In the annotation vocabulary machine-readable file, the use of rdfs:isDefinedBy is inconsistent. For reified elements for Dublin Core annotations, we use the Qname / abbreviated IRI to link to the source. For reified elements for the Simple Knowledge Organization System (SKOS), we use the full IRI. And, we have not included rdfs:isDefinedBy for any of our local annotation declarations.

    The latter is probably ok, but we should normalize the references for Dublin Core and SKOS to all use the same approach.

    This issue was raised by Richard Beatch in his AB review.

  • Reported: COMMONS 1.0a1 — Fri, 1 Jul 2022 18:25 GMT
  • Updated: Sun, 7 Aug 2022 00:00 GMT
  • Attachments:

Some of the commons ontologies include double spaces in annotations


The constraint on a classifier that says it must classify something is too restrictive

  • Key: COMMONS-9
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    Classification schemes should be able to be defined without necessarily referring to all of the things that they classify. For example, one should be able to encode industry classifiers without having to know exactly what those classifiers apply to. Thus, the constraint that a classifier classifies some thing should be loosened to be min 0, meaning 'may'.

    This issue affects the Classifiers ontology, only

  • Reported: COMMONS 1.0a1 — Thu, 14 Jul 2022 21:44 GMT
  • Updated: Sun, 7 Aug 2022 00:00 GMT
  • Attachments:

Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme

  • Key: COMMONS-11
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    This is not expressible in OWL, easily. One option would be to create a boolean that indicates this is the case, which perhaps a rule engine for data quality, or sparql, or a SHACL shape could then test. What you really want to be able to say is that 'is classified by' can only have one value from a given classification scheme when applied to something.

    This is a change to the Classfiers ontology, which may impact that section of the specification.

  • Reported: COMMONS 1.0a1 — Fri, 5 Aug 2022 18:37 GMT
  • Updated: Fri, 5 Aug 2022 18:37 GMT

Create examples of use of the profile

  • Key: CSRM11-3
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Updated: Sat, 2 Jul 2022 15:09 GMT

Examples are needed to help explain to Commons users how to use the ontologies

  • Key: COMMONS-5
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    There are no examples in the specification itself, which are needed to assist both library implementers and users of the ontologies.

  • Reported: COMMONS 1.0a1 — Fri, 1 Jul 2022 19:03 GMT
  • Updated: Fri, 1 Jul 2022 19:03 GMT

Some of the diagrams in Clause 8 are difficult to read

  • Key: COMMONS-4
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    All these diagrams, with the exception of Figure 9, have too small symbols and text. It would be very easy to reduce the width of those diagrams by reorganizing the content a little, this would allow larger magnification of the images.

  • Reported: COMMONS 1.0a1 — Fri, 1 Jul 2022 18:47 GMT
  • Updated: Fri, 1 Jul 2022 18:47 GMT

The format of the tables throughout the specification needs improvement

  • Key: COMMONS-3
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    (1) Different fonts: I can understand why you are using a fixed-width font in the metadata tables to identify the right-hand columns as the actual values of the terms listed in the left column.
    In the Properties tables I suggest to use a sans-serif font (e.g. Ariel) for the Axioms column to clearly distinguish the Axioms from the Annotations
    (2) The Properties tables are too cramped. It is not clear what the purpose of the name repetitions in parentheses in the Name column is. However, these repetitions take up unnecessarily much horizontal space. This could be solved by always moving them in a line under the bold camel-case name. The recovered horizontal space should be then allocated to the Axioms column, which is way too narrow. Many axioms are mutilated by inappropriate line breaks.
    (3) Since you are not using vertical separators (which is ok), you should extend the gutter whitespace between columns to improve readability, in particular between Annotation and Axiom columns.
    (4) Clause 6 should contain good explanations regarding the fonts and the table layouts [and the parenthesis names].

  • Reported: COMMONS 1.0a1 — Fri, 1 Jul 2022 18:45 GMT
  • Updated: Fri, 1 Jul 2022 18:45 GMT

The terms and definitions section of the Commons Ontology Library is incomplete

  • Key: COMMONS-2
  • Status: open  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    This section defines ontology, but none of the other key terms that are present in any of the ontologies. It should be revised to incorporate at least some of the basic definitions that are present in the ontology files.

  • Reported: COMMONS 1.0a1 — Fri, 1 Jul 2022 18:40 GMT
  • Updated: Fri, 1 Jul 2022 18:40 GMT

Add constraints to aid in correctness of profile useage

  • Key: CSRM-4
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

    In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT

Icons for profile

  • Key: CSRM-1
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

    The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT

Icons for profile

  • Key: CSRM11-1
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    The original icons used for stereotypes in the profile were drafts and need to be replaced with better versions. The icons also need to be delivered as SVG.

    The document does not currently show these icons, so diagrams need to be updated or an appendix added to the icons.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT

Recommended Additions

  • Key: CSRM-12
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
    This is a big deal and needs lots of discussion.

    Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

    Figure 2 lists requirement elements related properties that are part of the SysML language.

    Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
    The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
    Object Constraint Language

    There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

    That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

    A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

    An Issue that Needs Resolution.

    The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

    My recommendation is to rename the stereotypes as show in Table 1 below.

    Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
    CubeSatRequirement SatelliteRequirement
    CubeSatSubsystemRequirement SatelliteSubsystemRequirement
    CubeSatComponentRequirement SatelliteComponentRequirement
    CubeSatUseCase SatelliteUseCase
    CubeSatSubsystemUseCase SatelliteSubsystemUseCase

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT
  • Attachments:

Recommended Additions

  • Key: CSRM11-4
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    To make the case for updating CSRM stereotypes. Once agreement is reached, updates to the CSRM Specification will be developed.
    This is a big deal and needs lots of discussion.

    Figures 1 lists CSRM element stereotypes. Black font denotes current baseline as captured in the normative CSRM Profile. Blue font denotes recommended additions.

    Figure 2 lists requirement elements related properties that are part of the SysML language.

    Figure 3 illustrates one of many ways to establish relationships between the mission stakeholders, requirements, technical measures, and use cases stereotypes. These stereotypes are denoted by italicized font in Figure 1.
    The relationships are captured in the element specifications and are displayed and maintained in diagrams and tables as shown in Figure 1.
    Object Constraint Language

    There has been discussion about codifying the allowable relationships using Object Constraint Language (OCL). OCL is a declarative language describing rules applying to Unified Modeling Language (UML) models. For example, a refine relationship can exist between a requirement. and any other model element, whereas a derive relationship can only exist between requirements.

    That could be done founded on the examples in Figure 3. This would be of limited benefit. A mission team will be using the stereotypes and relationships best suited to their mission and the stereotypes in Figure 3 are very limited as compared to Figure 1.

    A case could be made to established relationships for the stereotypes in Figure 1. But that is out-of-Scope for the SSWG CSRM effort.

    An Issue that Needs Resolution.

    The intent of defining addition stereotypes as shown in Figure 1 is to provide stereotypes for a variety of mission architectures. However, several of the stereotypes are identified as CubeSat stereotypes. But they are not unique to CubeSats. The only thing that makes a model a CubeSat model is the incorporation of a CubeSat form factor such as the Cal Poly CubeSat Design Specification.

    My recommendation is to rename the stereotypes as show in Table 1 below.

    Table 1. Renaming of Stereotypes (Proposed name changes from Figure 1)
    CubeSatRequirement SatelliteRequirement
    CubeSatSubsystemRequirement SatelliteSubsystemRequirement
    CubeSatComponentRequirement SatelliteComponentRequirement
    CubeSatUseCase SatelliteUseCase
    CubeSatSubsystemUseCase SatelliteSubsystemUseCase

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT
  • Attachments:

Create examples of use of the profile

  • Key: CSRM-5
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Originally the first versions of CSRM had examples. However, when the spec was reduced to a profile, the examples were removed. Because of some of the changes, not all examples are viable, so it is proposed we create new examples. Dave Kaslow also requested that the examples be categorized as a simplified and expert use of the profile to aid adoption by students.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT

Add constraints to aid in correctness of profile useage

  • Key: CSRM11-2
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Constraints should be added to aid in the creating of correct models. For example, an MoE needs to be related to a moeRequirement which in turn is refined by a moeSpecification.

    In addition, by categorization and content of warings and error of the constraints, we could add hints for new users of minimal and advanced concepts.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Updated: Fri, 1 Jul 2022 15:21 GMT

Change names from CubeSat to Satellite.

  • Key: CSRM-9
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Dave Kaslow proposes the following changes to stereotypes:

    From: CubeSatRequirement to: SatelliteRequirement
    From: CubeSatSubsystemRequirement to: SatelliteSubsystemRequirement
    From: CubeSatComponentRequirement to: SatelliteComponentRequirement
    From: CubeSatUseCase to: SatelliteUseCase
    From: CubeSatSubsystemUseCase to: SatelliteSubsystemUseCase

    Document attached was where the issue was raised.

  • Reported: CSRM 1.0b1 — Thu, 21 Apr 2022 19:43 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT
  • Attachments:

Remove Section 0 from the document

  • Key: CSRM-16
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Per standard process, Section 0 (zero) is to be removed from the Finalized document.,

  • Reported: CSRM 1.0a1 — Fri, 22 Apr 2022 20:42 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Clarify usage of Group stereotype

  • Key: CSRM-35
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Clarify the use of the Group stereotype.
    Pete Rivette wrote:
    7.1.12 says that <<Group>> groups related requirements but not which property is used to achieve that.

  • Reported: CSRM 1.0a1 — Thu, 16 Jun 2022 13:46 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Add comments to 7.6.3 ExtRequirement source/Risk elements

  • Key: CSRM-31
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    We are missing the comments to source and risk of ExtRequirement. The elements also need to be printed in the specification. Other tag definitions are also not printed and thus need to be displayed.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 21:53 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

MeasurementSpecification missing documentation

  • Key: CSRM-28
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Need to add documentation of MeasurementSpecification.summary (paragraph 7.28) and fix MeasurementSpecification.id missing documentation.

    The summary element is missing documentation.
    The id incorrectly indicates that it is the id of a requirement, rather than a MeasurementSpecification.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:38 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

VerificationActivity missing documentation on verificaionMethod

  • Key: CSRM-26
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    VerificationActivity.verificationMethod is missing documentation.

    Proposed fix: add documentation to
    The verificationMethod property indicates the primary method that VerificationActivity uses to verify a Requirement.

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:13 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Change 7.6 SysML Extentions

  • Key: CSRM-3
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    Section 7.6 to be replaced with an official SysML extensions profile. Section 1.6 was a hack that allowed the specification to move forward.

    Unfortunately replacing this section with a SysML profile may not be easy because of issues with how vendors have implemented the SysML extensions. It may be simpler to replicate all or part of the extensions.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:51 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Add relationship convenience attribute for Validated and other relationships

  • Key: CSRM-2
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    David Kaslow requested that derived properties be added to allow reporting.

    For example, a user of the profile should be able to add to a table a column that matches the Validated By or Validates concepts (and others) similar to how tables can display Verified By and Verifies.

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:38 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Modify Paragraph 2 to remove redundant reference to the machine readable file.

  • Key: CSRM-41
  • Status: open  
  • Source: Dassault Systemes ( Daniel Brookshier)
  • Summary:

    As the spec already has a reference to the machine-readable file, this line is redundant.

    This line in paragraph 2 should be removed:

    dtc/22-04-06 - CSRM Profile - XMI File (see the description in Section 6)

    Reported by Pete Rivett during FTF review.

  • Reported: CSRM 1.0a1 — Fri, 17 Jun 2022 19:49 GMT
  • Updated: Wed, 29 Jun 2022 17:09 GMT

Provide a simple sample application

  • Key: CORBARS_-1
  • Status: open  
  • Source: Micro Focus ( Matteo Vescovi)
  • Summary:

    It would be good to show a sample simple application that shows use of the REST mapping as proof of concept of use of the spec.

    While there are fragments sprinkled in the specification document, a simple application would be useful and ease adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:47 GMT
  • Updated: Wed, 29 Jun 2022 17:07 GMT
  • Attachments:

Provide example of authentication and security

  • Key: CORBARS_-2
  • Status: open  
  • Source: Micro Focus ( Matteo Vescovi)
  • Summary:

    It would be nice to have some discussion/example in the document for REST authentication and security.

    I think this would help with adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:50 GMT
  • Updated: Wed, 29 Jun 2022 17:07 GMT
  • Attachments:

Text for AMVAL REQ references non-existing fields

  • Key: C2MS11-101
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    For the Archive Mnemonic Value Request Message, under the explanatory text, there is a paragraph stating:

    "Optionally, if known or applicable, the requestor can specify the file type and file attributes with the optional dependent fields under the Output Product Category and Output File Attributes sections."

    I'm not sure what this is referring to. There are no Product Category or Output File Attributes dependent fields in the Message. The terms "Output Product Category" and "Output File Attributes" occur in the document only in this paragraph.

    The text either needs to be clarified or removed.

  • Reported: C2MS 1.0 — Wed, 29 Jun 2022 13:05 GMT
  • Updated: Wed, 29 Jun 2022 13:07 GMT

VCID and APID in Message Subject for TLMTDM Frame

  • Key: C2MS11-54
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    The Subject for TLMTDM Frame Messages includes the following:
    -ME3 = VCID
    -ME4 = APID

    However these fields:
    a) don't exist in the TLMTDM Frame Message, so can't be populated to the message subject,
    b) belong only to CCSDS frames, not TDM frames.

    These Message Subject Miscellaneous Elements should be removed and replaced with "FILL" to preserve ME5 as Collection Point.

  • Reported: C2MS 1.0 — Thu, 3 Mar 2022 22:57 GMT
  • Updated: Wed, 22 Jun 2022 13:36 GMT

Create CMD-MNEMONIC Field in Command Request Message

  • Key: C2MS11-88
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    In the Command Request Message, the Binary "CMD-DATA" message contains the packet/fram/CLTU, etc, for all CMD-FORMAT types. However, if the CMD-FORMAT type is MNEMONIC this doesn't make as much sense.

    Suggestion here is to create a new field in Command Request Message, "CMD-MNEMONIC" as type STRING to hold the human-readable MNEMONIC for command lookup if the CMD-FORMAT is of type MNEMONIC.

    In this way, both CMD-DATA and CMD-MNEMONIC would be Dependent fields, with usage based on the contents of CMD-FORMAT.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:54 GMT
  • Updated: Wed, 22 Jun 2022 13:26 GMT

Add documentation within the model

  • Key: C2MS11-13
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    In the current version of the model, there is no descriptive documentation within the model itself. This could be easily added from the non-normative specification and would aid engineering teams who use the model.

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:31 GMT
  • Updated: Tue, 21 Jun 2022 21:00 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS11-4
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    The messages for mnemonic access do not appear to include a request/response for "setting" the value of a parameter (mnemonic) from an application participating using C2MS. This capability is used for ground and other types of non-telemetered parameters (mnemonics).

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:21 GMT
  • Updated: Tue, 21 Jun 2022 20:57 GMT

Add field APID (and VCID) to Telemetry CCSDS Packet Message

  • Key: C2MS11-39
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    This value is used in the subject, so should be added to the message.
    (NOTE: do NOT add this field to the CCSDS Frame message; TBD for Processed Telemetry Message and TDM Frame message. Also, check the VC ID usage appropriateness in all 4 TLM messages.)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:58 GMT
  • Updated: Tue, 21 Jun 2022 20:51 GMT

C2MS: Optional Transfer Frame/Packet attributes should be described in schema

  • Key: C2MS11-42
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Non-self-describing CCSDS attributes for either transfer frames or space packets should be provided as dependent attributes of the frame messages. This would enable full integration between a sender and receiver. Right now, whether these optional fields are provided is unknown, causing the proper rendering of the frame to not be possible without outside negotiation (beyond the specification).

    Examples:

    Frame Header Error Control of the AOS transfer frame (AOS Space Data Link Protocol (ccsds.org)), where nothing prior to it in the definition specifies whether it is there or not:

    4.1.2.6 Frame Header Error Control
    4.1.2.6.1 If implemented, Bits 48-63 of the Transfer Frame Primary Header shall contain the Frame Header Error Control. NOTE – The 10-bit Master Channel Identifier, the 6-bit Virtual Channel Identifier, and the 8-bit Signaling Field may all be protected by an optional error detecting and correcting code, whose check symbols are contained within this 16-bit field.
    4.1.2.6.2 The presence or absence of the optional Frame Header Error Control shall be established by management.
    4.1.2.6.3 If present, the Frame Header Error Control shall exist in every Transfer Frame transmitted within the same Physical Channel.

    Space Packets and the secondary header (Space Packet Protocol (ccsds.org)): A space packet might have a secondary header with a variable length time code, a variable length ancillary data field, or both. A space packet might have a secondary header, a user data field, or both. The length is not specified for any of them. When present, the format of the time code can be one of several options, but which one is not specified:

    4.1.3.3.3 Secondary Header Flag 4.1.3.3.3.1 Bit 4 of the Packet Primary Header shall contain the Secondary Header Flag. 4.1.3.3.3.2 The Secondary Header Flag shall indicate the presence or absence of the Packet Secondary Header within this Space Packet. It shall be ‘1’ if a Packet Secondary Header is present; it shall be ‘0’ if a Packet Secondary Header is not present. 4.1.3.3.3.3 The Secondary Header Flag shall be static with respect to the APID and managed data path throughout a Mission Phase. 4.1.3.3.3.4 The Secondary Header Flag shall be set to ‘0’ for Idle Packets

    4.1.4.2.1.5 If present, the Packet Secondary Header shall consist of either: a) a Time Code Field (variable length) only; b) an Ancillary Data Field (variable length) only; or c) a Time Code Field followed by an Ancillary Data Field. 4.1.4.2.1.6 The chosen option shall remain static for a specific managed data path throughout all Mission Phases. NOTE – The format of the Packet Secondary Header is shown in figure 4-3. ANCILLARY DATA FIELD (optional) variable PACKET SECONDARY HEADER TIME CODE FIELD (optional) variable Figure 4-3: Packet Secondary Header

    4.1.4.2.2 Time Code Field 4.1.4.2.2.1 If present, the Time Code Field shall consist of an integral number of octets. 4.1.4.2.2.2 The Time Code Field shall consist of one of the CCSDS segmented binary or unsegmented binary time codes specified in reference [3].CCSDS RECOMMENDED STANDARD FOR SPACE PACKET PROTOCOL CCSDS 133.0-B-2 Page 4-8 June 2020 NOTE – The time codes defined in reference [3] consist of an optional P-Field (Preamble Field), which identifies the time code and its characteristics and a mandatory T[1]Field (Time Field). Examples of time codes are CCSDS Unsegmented Time Code and CCSDS Day Segmented Time Code. Examples of characteristics are ambiguity period, epoch, length, and resolution. 4.1.4.2.2.3 The time code selected shall be fixed for a given managed data path throughout all Mission Phases. 4.1.4.2.2.4 If the characteristics of the chosen time code are fixed, the corresponding P[1]field (as described in reference [3]) need not be present. If the characteristics are allowed to change, the P-field shall be present so as to identify the changes. 4.1.4.2.2.5 The presence or absence of the P-field in the Time Code Field shall be fixed for a given managed data path throughout all Mission Phases. If present, it shall immediately precede the T-field that is defined in reference [3]

    4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

    4.1.4.3 User Data Field 4.1.4.3.1 If present, the User Data Field shall follow, without gap, either the Packet Secondary Header (if a Packet Secondary Header is present) or the Packet Primary Header (if a Packet Secondary Header is not present). 4.1.4.3.2 The User Data Field shall be mandatory if a Packet Secondary Header is not present; otherwise, it is optional. 4.1.4.3.3 If present, the User Data Field shall consist of an integral number of octets. 4.1.4.3.4 If the Packet is not an Idle Packet, then the User Data Field shall contain application data supplied by the sending user. If the Packet is an Idle Packet, the User Data Field shall contain Idle Data. NOTE – The bit pattern of Idle Data is set by the mission and is not specified in this Recommended Standard

  • Reported: C2MS 1.0 — Tue, 13 Jul 2021 12:26 GMT
  • Updated: Tue, 21 Jun 2022 20:45 GMT

Consider Renaming "Header String" type to "Subject Token String"

  • Key: C2MS11-49
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    I believe the distinction between "Header String" and "String" types is to enforce compliance with Subject Element format (UPPERCASE Alphanumeric, "-" and "_" as only valid values). The description of "Header string" in Table 8-1, Field Type Definitions, indicates that this type is used for "subject name elements".

    It's a bit confusing to call this a "Header String", because not all Strings in the Header are Header Strings, and some fields are Header String type even though they are not in the Header (Some examples: USER, SUBCLASS, REFERENCE-ID, and OCCURRENCE-TYPE in Log, CNTL-KEYWORD in Control Message).

    In all cases, the fields that are Header String type are intended to be used as subject elements.

    One side note, that would need to be fixed, either way is that the actual type listed in Table 8-1, Field Type Definitions, lists the type in two places as "Header string" (lowercase s on string), where everywhere else in the document and in UML model figures, it is listed as "Header String".

  • Reported: C2MS 1.0 — Fri, 25 Feb 2022 13:37 GMT
  • Updated: Tue, 21 Jun 2022 20:13 GMT
  • Attachments:

Clarify Correlation PUBLISH-RATE and SAMPLE-RATE on Mnemonic Value Request Message

  • Key: C2MS11-56
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    In Mnemonic Value Request Message, there is a PUBLISH-RATE and there is a SAMPLE-RATE that can be specified for each MVAL. However, this latter item this is already solved via the PUBLISH-RATE of overall request, and confuses the overall meaning of the message if specified here. If a different PUBLISH-RATE is desired for a given MVAL, a separate subscription request suffices.

    I suggest removing 3 "Sample Rate" from MNEMONIC.n.CRITERIA and MNEMONIC.n.SAMPLE-RATE.

  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:40 GMT
  • Updated: Tue, 21 Jun 2022 20:06 GMT

Missing Echo Request

  • Key: C2MS11-87
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    There is no “need Echo” in the EGS REQ CMD Message. At present, all we can say is that based on MUS configuration, EGS CMDECHO may be generated.

    I propose using a new Boolean CMD-ECHO field in Command Request Message to indicate if an ECHO should be sent at any configured point along the ground chain as the command is transmitted.

    This would be an Optional field, defaulting to FALSE.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:48 GMT
  • Updated: Tue, 21 Jun 2022 19:54 GMT

Larger Data Types

  • Key: C2MS11-19
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    From Justin: In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). May need a separate field to indicate the type of data in these fields.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:48 GMT
  • Updated: Tue, 21 Jun 2022 18:57 GMT

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS11-20
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    Harmonization Needed

    I’d like to recommend a review of the Replay Telemetry Data Request Message compared to the Archive Mnemonic Value Request Message. These two messages should be nearly identical in form, but appear to have grown up in neighborhoods on opposite sides of the tracks.

    Some base behaviors are different between the two. Many fields exist in one request message but not the other. In one case, the same field exists in both request messages, but has a different meaning. The response paradigm is different between the two message sets.

    This issue is to harmonize the two message sets.

    Throughout this discussion, I’ll use the following abbreviations:

    • “RTDRM” - Replay Telemetry Data Request Message
    • “AMVRM” - Archive Mnemonic Value Request Message

    Sections below describe elements of the two that are dissimilar:

    Message Naming

    For TLM, the Message is called Replay Telemetry Data Request Message (RTDRM). For the MVAL it is Archive Mnemonic Value Request Message (AMVRM). Since both have the concept (implemented differently) of replay, but the AMVRM has a way to receive the data as an output file, I think that “Archive” is more meaningful. In fact the descriptive text under the RTDRM, refers to the “Telemetry Archive component”. So, I’d suggest renaming the RTDRM to Archive Telemetry Data Request Message to match better with Archive Mnemonic Value Request Message.

    Real-time and Future “Replay”

    Replay Telemetry Data Message set includes a long description of how to use the “replay” service provider as a way to get real-time, or even future TLM messages (Section 8.7). There is no analog in Archive Mnemonic Value Messages.

    I recommend we don’t include that discussion in the Archive Mnemonic Value Messages. It seems odd to have “replay” messages for something that isn’t replay. I believe the same intent can be achieved by simply requesting a “replay” whose end-date-time is in the future, and indicate that the archive service will continue to send out TLM, as long as it is put in the archive during that window. That is logically similar, without trying to fake out the system, because the data would still originate from the archive.

    The STREAM-MODE of the RTDRM (sec 8.7.1.3) can be RT or RPY, to accommodate the intent of separating real-time from replay. I don’t’ think this is needed. If we assume that we only replay data that is in the archive, whether it is arriving into the archive now or in the future, this is logically the same and wouldn’t require special handling in the message definition.

    Section 8.7.1 indicates that the two fields PLAYBACK-RATIO and DATA-RATE (described in sec 8.7.1.3) only apply if the STREAM-MODE is RT. However, having to specify STREAM-MODE as RT or RPY doesn’t seen necessary. These values could easily be applied to RPY: this would mean that the playback rate would be some ratio of the timing of the original TLM (play back at the same rate it was originally received, or some ratio related to it) or play it back at a certain data rate, from the archive. The distinction makes it awkward and I don’t think it’s necessary. The AMVRM uses PLAYBACK-RATIO and DATA-RATE with exactly these meanings, without any indicator of STREAM-MODE.

    I’m confused about what is meant by the fields of the RTDRM in Section 8.7.1.3 for files. There is a NUM-OF-FILES and a FILE.n.NAME-PATTERN, with very limited description of how this is to be used. The only clue is in Section 8.7.1, where there is indication that this only applies to a “real-time data stream”. I’m not sure how the requester is to know the names of files in the archive and why this would only apply to RT. Probably should be removed, unless we have a specific use-case for it.

    STREAM-MODE

    STREAM-MODE (described in sec 8.7.1.3) exists in RTDRM, but not in AMVRM at all. This would be useful in AMVRM, because STREAM-MODE can indicate SIM or TEST. RT and RPY are not needed, as described above.

    Request All Data Construct

    In addition to retrieving MVAL Data Messages as a stream, the AMVRM also has the concept of requesting the entire data set in a single message. In fact, this can either be in the payload of the single message or the data can be placed in a file at a specified URI. The RTDRM does not have this concept at all, and all retrieved TLM must be in a set of streamed messages. I like this capability of the AMVRM and recommend that it be added to the RTDRM.

    One oddity in this concept is that in the AMVRM (sec 8.9.1.3), if the RESPONSE-VIA-MSG is set to RESP.AMVAL, then it can be delivered in the single message or at a URI. However, the selection is controlled by two Boolean fields: DELIVER-VIA-REFERENCE (URI) and DELIVER-VIA-INCLUDE (message payload). It’s odd that these are separate Booleans, because there is no description of what would happen if they are both set to ‘0’ or if they are both set to ‘1’. I can surmise that setting both to ‘0’ would be an error and setting both to ‘1’ would mean to deliver the data set in both the single data message and also at the URI, but it’s hard to imagine the usefulness of doing so. I’d recommend we drop DELIVER-VIA-INCLUDE and just use the DELIVER-VIA-REFERENCE to mean that the data is to be EITHER in a URI OR in the data message.

    ACTION Field

    The RTDRM has an ACTION field to control flow (start, stop, etc). There is no analogue in AMVRM, but there probably should be.

    PDB-VERSION Field

    The AMVRM has a PDB-VERSION field. This field does not exist in RTDRM. To me this seems way down in the weeds, and was probably an add-on for a special one-off case somewhere along the line. Is it necessary? If not it should be removed. If so, it should be added to RTDRM as well.

    ORBIT Field

    RTDRM can specify a particular orbit. This field does not exist in AMVRM.

    Filename Fields

    RTDRM, as discussed earlier, has fields for the source files for TLM. This concept doesn’t exist for AMVRM. Unless we can come up with a specific use case for this (along with a better description of the fields in the RTDRM), I’d be in favor or dropping it from RTDRM. Otherwise, it should probably be added to AMVRM for consistency.

    FORMAT Field

    Both RTDRM and AMVRM have a FORMAT field. They are used for different purposes. I’d recommend calling the one in RTDRM TLM_FORMAT and the one in AMVRM something like FILE_FORMAT since that corresponds to their use.

    VCID and APID Fields

    RTDRM has VCID and APID fields. The AMVRM does not. Yet, the MVALs originated from the same TLM stream, so these seem applicable to AMVRM. Needs discussion. Note that both request messages have COLLECTION-POINT with identical meaning, so the origination of TLM and MVALs are tied in that way.

    Mnemonic Value Data Message vs Archive Mnemonic Value Data Message vs TLM Messages

    In the RTDRM, asking to retrieve TLM messages results in identical TLM messages to when these messages came in, real-time. The only exception is in the STREAM-MODE of that message type, which is set to RT for original messages, or RPY for messages coming out of the archive. This is a useful construct.

    However, for AMVRM, the original real-time messages have one format, defined in section 8.8.3.3 and a different format for messages retrieved from the archive, described in section 8.9.3.3.

    It seems logical to use either one pattern or the other. I prefer the pattern used by TLM, where the original message format reappears, but with a designator that it is a RPY message.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 16:28 GMT
  • Updated: Tue, 14 Jun 2022 17:11 GMT

Larger Data Types

  • Key: C2MS11-21
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    In the current specification, RAW-VALUE is limited to a 32-bit integer and EU-VALUE is limited to 64-bit float (i.e., double). These data types should be changed to allow larger data types to be represented (at a minimum, 64-bit integer should be supported throughout). (From Justin Boss)

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:44 GMT
  • Updated: Tue, 14 Jun 2022 17:05 GMT

Using REQ Messages for 'Publish'


REQUEST-ID as "Replacement" and related STOP

  • Key: C2MS11-55
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    Numerous field tables in C2MS allow reusing the same REQUEST-ID for a request to provide a "replacement". For example, MVAL REQ Message says in the Fields table (Table 8-99) under REQUEST-ID:

    "ID to identify the request message - if different request messages have the same value, the request is a replacement; else, it is a new request"

    In all cases, this is the only explanatory text of what is meant by "replacement". This is pretty ambiguous about expected result. So, for example,

    • If I send an initial request to start receiving MVAL A and B, and then send another request of the same REQUEST-ID for MVAL C, is the result that I'm now subscribed to A, B and C, or just to C?
    • If I send a request to start receiving MVAL X and Y with a PUBLISH-RATE of 1 and then send another request for a duration of 120 minutes, and then send another request wit the same REQUEST-ID for MVAL Y with a PUBLISH-RATE of 5, am I subscribed to X at 1 and Y at 5, or just Y at 5?

    There's no description of semantics regarding what is being replaced.

    A related issue is STOP request, specifying non-symmetrical MVALs, and what to do in that situation.

    • If I send a request to start receiving MVAL 11 and 12, and then send a STOP, but only specify MVAL 11, do I still get 12?

    I suggest the following for this message type, and something similar everywhere else "replacement" and "STOP" are mentioned:

    • - -

    Subscribing (START) – A client initiates a subscription for a listed set of MVALs via a Mnemonic Value Request Message with a REQUEST-TYPE of START. All listed MVALs of the REQ Message will be subscribed to with the same settings according to the fields specified in the message, such as PUBLISH-RATE, etc.

    Unsubscribing (STOP) – A client concludes a subscription via a Mnemonic Value Request Message with the same REQUEST-ID as a previous subscription request message, and a REQUEST-TYPE of STOP. When specifying STOP, the NUM-OF-MNEMONICS must be zero. The effect is to unsubscribe all MVALs previously specified in the Subscription (START) message of that REQUEST-ID.

    Reusing a REQUEST-ID (Replacement) – “MVAL Request Replacement” is defined as sending a new Mnemonic Value Request Message with the same REQUEST-ID as a prior Mnemonic Value Request Message, with a REQUEST-TYPE of “START”. In this case, whatever was requested previously is superseded by the new Mnemonic Value Request Message. For example, if a Request starts a subscription for MVALs “one” and “two” and a PUBLISH-RATE of 4, and a new Request arrives with the same REQUEST-ID, specifies MVALs “two” and “three” and no PUBLISH-RATE, the effect is that the client will no longer receive MVAL “one” and will receive “two” and “three” with a publish rate of 5 (the default value for PUBLISH-RATE). Conceptually, it is equivalent to stopping the previous subscription altogether and starting a new one.

    • - -
  • Reported: C2MS 1.0 — Fri, 4 Mar 2022 00:28 GMT
  • Updated: Tue, 14 Jun 2022 17:01 GMT

REQUEST-ID field does not support usage as a GUID

  • Key: C2MS11-16
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    From Justin: The REQUEST-ID field was defined as a U16. Recommend this field be changed to be a string to allow it to be utilized as a GUID. This allows it to work better for transport of existing interfaces that utilize a GUID to ensure message uniqueness, especially when multiple instances of the application are running concurrently.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:11 GMT
  • Updated: Tue, 14 Jun 2022 16:56 GMT

Make Fields Table and UML Match the Order of Fields for greater Readabliity

  • Key: C2MS11-17
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    It would greatly aid readability of the specification if the tables listing the message contents by field separated the required fields from the optional fields. By doing this, the UML and descriptive tables would be in alignment.

    This is true throughout, but for one pretty clear example, see section 8.6.1.3. The UML (figure 8-13) and the table (table 8-69) are hard to read together when looking at both.

    In this case, there are two blocks in the UML diagram that contain fields: one block is "Required Fields" and the other "Optional Fields". The table, simply shows fields. When reading down the fields in the table, the listed fields come from the two different UML blocks in the following order:

    1-Required
    2-Optional
    3-Required
    4-Optional
    5-Optional
    6-Required
    7-Required
    8-Optional
    9-Optional
    10-Required

    It would be much more clear to have all the fields in the table be listed in the same order as the UML diagram, with Required first, followed by Optional, along with a column specifying required or optional. Alternatively, there could be two tables: one for required fields in the same order as the "Required Fields" block of UML, and a second table with all the optional fields in the same order as the "Optional Fields" block of UML.

    As mentioned above, this is one example, but this disconnect between the UML and the Fields table is true throughout the document.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:33 GMT
  • Updated: Tue, 14 Jun 2022 16:52 GMT

Make all subjects be buildable from fields in the message

  • Key: C2MS11-25
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Almost all miscellaneous subject elements for messages are specified as mapping to fields in the message. But a few are not. For example, see the Miscellaneous Elements table 8-46 for the Control message. The elements DESTINATION_NODE and DESTINATION_FACILITY do not exist as fields in the message. (Note: it may be more appropriate to add some of these fields to the Message Header rather than many/most messages.) In this particular example, this may be resolved by C2MS11-28, but each message type would need to be evaluated to see what other subject elements are not mapped to fields.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:59 GMT
  • Updated: Tue, 14 Jun 2022 16:46 GMT

Document that Header String type is to be at least one ASCII character

  • Key: C2MS11-26
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    This is just a documentation clarification. Header Strings are the type used for building message subjects. It's invalid for a message subject element to be null. So, Header Strings need to be at least one character.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:09 GMT
  • Updated: Tue, 14 Jun 2022 16:29 GMT

In Message Header, make NODE and USER-NAME string rather than Header String

  • Key: C2MS11-29
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The NODE and USER-NAME fields are tracking fields supplied by the implementation (API). They should just be whatever strings are returned by the local o/s rather than forcing them to be of type Header String (upper alphanumeric, "-", "_").

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:23 GMT
  • Updated: Tue, 14 Jun 2022 16:27 GMT

Clarify the ".... Message Header Notes" tables re: being included in each message

  • Key: C2MS11-30
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The ".... Message Header Notes" tables can be confusing. For example, table 8-8. It should be made clear that the fields listed in those tables are from the Message Header definition, but the values apply only for that specific message. A small wording change would go a long way to helping, especially for newer users.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:39 GMT
  • Updated: Tue, 14 Jun 2022 16:26 GMT

Add DESTINATION_NODE and DESTINATION_FACILITY to Message Header

  • Key: C2MS11-28
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    In the Message Header (pages 41-45), add the fields DESTINATION_NODE and DESTINATION_FACILITY as Optional with type of Header String. This enhances the routing/subscribing options currently available for the DESTINATION_COMPONENT field.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:20 GMT
  • Updated: Tue, 14 Jun 2022 16:25 GMT

Add field for USER to Message Header

  • Key: C2MS11-32
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    In Log, Directive Request, and Simple Service Request, there is a USER field for use by communicating applications. This field should be moved to the Message Header, so that any message can utilize this field.

    Note: in the Log Message this field is used in the subject, so is defined as a Header String. In the Directive and Simple Service messages, it is not used in the subject so is defined as a string.

    Note 2: There is another field in the Message Header called USER-NAME; this is a tracking Field, so is reserved for use by the implementation and is the account/user name that started the application.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 18:01 GMT
  • Updated: Tue, 14 Jun 2022 16:24 GMT

In the Control Message, the field CNTL-STRING should be required

  • Key: C2MS11-38
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Change the CNTL-STRING field in the Control Message from optional to required. That field is the reason for the message. This also will be consistent with Directive Message, where DIRECTIVE-STRING is required. See Figure 8-9.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:52 GMT
  • Updated: Tue, 14 Jun 2022 16:22 GMT

Control Message SPECIAL_INFO Field type should be String

  • Key: C2MS11-40
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    In the Control Message, the field SPECIAL_INFO is Binary type in the UML diagram (Figure 8-9), but is described as "For application use. Any additional information can be provided here." (Table 8-48).

    Because C2MS has no definition or understanding of the binary format, it is probably better if the type be changed to "String", so that opaque data is not transmitted around the system where only the producer and consumer can understand what it is. Log messages, for example, would not be able to record, in any meaningful way, what was sent in the control message.

  • Reported: C2MS 1.0 — Tue, 6 Oct 2020 17:46 GMT
  • Updated: Tue, 14 Jun 2022 16:13 GMT

Add Message-level Security Constructs

  • Key: C2MS11-48
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    Add fields that allow encryption of content sections of C2MS messages as well as message signatures or message authentication codes. This would not assume or provide any particular mechanism to encrypt/sign, but would allow for tracking of these fields to aid usage.

    The benefit of doing this is to allow the Mission to determine levels of security and secure componentry, but to use the message definition as a way to track this information.

    Note that currently, GMSEC provides a level of encryption/signing, but my thought is that it would be preferred to allow the mission to manage this outside the transport layer. Providing encryption/signing FIELDS in the message definition allows for this decouplling.

    I've got some specific ideas about how to do this, which I can share, but just want to capture the need here.

  • Reported: C2MS 1.0 — Tue, 22 Feb 2022 16:50 GMT
  • Updated: Tue, 14 Jun 2022 16:08 GMT

Message-level Security Credentials

  • Key: C2MS11-22
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    Justin Boss:
    A username or alternate security credential should be able to be provided with all C2MS requests (and possibly should be required)?

    Systems should not automatically trust remote clients and therefore a credential should be required with all messages. This would allow components to authorize and audit requests on a per-user/connection level.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 03:38 GMT
  • Updated: Tue, 14 Jun 2022 16:07 GMT

Clarify the UML diagrams regarding the values for the fields inherited from Message Header

  • Key: C2MS11-31
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    This issue is related to C2MS11-30, which is about the table immediately prior to every message UML diagram. The UML diagrams, for example figure 8-3, seem to indicate that "MESSAGE-TYPE" and "MESSAGE-SUBTYPE" are fields in the individual message when they are actually in the Message Header.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:43 GMT
  • Updated: Tue, 14 Jun 2022 16:04 GMT

All Messages Subclass Message Header

  • Key: C2MS11-18
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    The way the UML is shown for each message, each C2MS message inherits the Message Header type. This isn't really semantically correct.

    Consider the diagram from section 8.6.3.3 (although this is true throughout all message specifications), which is included as Attachment 1. Organized this way, this UML means that Telemetry TDM Frame Message IS A Message Header, rather than that it contains a Message Header.

    THere are two options for making this a little more clear:

    Option A is that Instead, they should be subclasses of something called "C2MS Message" that itself contains a Message Header, as shown in Attachment 2, in which Telemetry TDM Frame Message IS A C2MS Message, and all C2MS Messages contain a Message Header.

    Option B is to use composition where each message contains a message header. This is as shown in Attachment 3.

    It's not a major point, but would increase readability and have better optics.

    After discussion, Option B seems like the right choice.

  • Reported: C2MS 1.0 — Fri, 28 Feb 2020 19:53 GMT
  • Updated: Tue, 14 Jun 2022 16:03 GMT
  • Attachments:

Add security fields that GMSEC API inserts into encrypted messages as Tracking Fields in C2MS

  • Key: C2MS11-33
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The intent of tracking fields is to reserve them for use by the implementation. So, to be complete, these fields should be added to the specification. If any of these fields were to be inadvertently added to the messages by an application, the implementation (GMSEC API) could potentially overwrite their values.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:33 GMT
  • Updated: Tue, 14 Jun 2022 15:58 GMT

Move Tracking Fields to a "Message Envelope"

  • Key: C2MS11-75
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    Tracking fields do not specifically belong in a C2MS Message. Rather, there should be a message envelope that contains these fields for the purpose of delivering a contained C2MS message. Recommended here, is to define a C2MB Sister spec that encompasses the 'how' of sending C2MS messages. This is the logical place for managing tracking fields in a "Message Envelope".

    This is clear when considering tracking fields, MW-INFO and CONNECTION-ID, which are message-bus handling constructs and have no meaning in C2MS itself.

  • Reported: C2MS 1.0 — Sun, 20 Mar 2022 01:04 GMT
  • Updated: Tue, 14 Jun 2022 15:57 GMT

Add DESTINATION-NODE and DESTINATION-FACILITY as fields

  • Key: C2MS11-36
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    One goal for consistency (and ease of implementation and use of said implementation) is to have all subject elements also be fields in the message. Adding DESTINATION-COMPONENT late in the adoption process of C2MS was a step in this direction, but DESTINATION-NODE and DESTINATION-FACILITY are needed also. See page 82 for example for CFG messages.

    (Note: this applies to all 5 C2CX messages - CFG, CNTL, DEV, HB, and RES)

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:45 GMT
  • Updated: Tue, 14 Jun 2022 15:55 GMT

In message tables, rework the "value" column to allow for fixed values vs. default values

  • Key: C2MS11-23
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Many fields in many messages contain value information. Some of the values are defaults and some are intended to be constant. Also, this information is in the "notes" column. There should be a way to differentiate between fixed and default values more easily than reading the notes fields. Also, this will make encoding those attributes in the .xsd PSM easier.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:48 GMT
  • Updated: Tue, 14 Jun 2022 15:51 GMT

Add a Message Exchange Pattern (MEP) for a component to forward requests/responses

  • Key: C2MS11-24
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Some services may depend on other services to satisfy a request. Create a MEP that discusses and shows how this could work.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:52 GMT
  • Updated: Tue, 14 Jun 2022 15:49 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS11-45
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Add the DBQUERY messages that were defined by NASA to the formal specification.

    These messages are listed as being part of the OMG specification here:
    https://software.nasa.gov/software/GSC-18536-1

    "A Graphics User Interface (GUI) based desktop viewer for XML Telemetry and Command Exchange (XTCE) files which allows some editing of the various XTCE properties of that open file, and then allows saving the updated information back to file. It includes a Goddard Mission Services Evolution Center (GMSEC) GMSEC Search XTCE (GSX) connector to support some GMSEC/ (Command and Control Message Specification) C2MS Database Query (DBQUERY) messages to search for some XTCE information which is then sent over GMSEC bus to the initiator of the search request."

  • Reported: C2MS 1.0 — Wed, 26 Jan 2022 18:09 GMT
  • Updated: Tue, 14 Jun 2022 15:48 GMT

Using REQ Messages for 'Publish'

  • Key: C2MS11-47
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    The "Publish" MEP second paragraph talks about using either MSG or REQ messages as a means of publishing. I think this could use some revisiting.

    It seems on that a REQ message "may or may not require a response. For example, one component may request another component to take some action and does not need to know immediately if the action was successful or not." f(section 6.3.2.1, pg 15). This is then enabled by specifying a BOOLEAN value for "RESPONSE" indicating whether a reponse is expected in a REQ message.

    To me, it seems like not expecting a response when issuing a REQ message is a corner case. Even in the example above, how do I know that ANY component received the REQ? I would prefer to say that components that process a REQ message are expected to respond AT LEAST with a RESP Message acknowledging receipt. If the sender chooses not to look for one, fine, but it seems like an odd pattern to make a request and ignore whether anyone heard you.

    This would aid in simplifying the Publish MEP to reduce it to just MSG. Actually, if we don't do this, we need to fix the sequence diagram on pg 24, anyway, because as shown it's incorrect; requiring sending a MSG before sending a REQ. It's really meant to be either-or. So, if we remove REQ as a Publish mechanism, the diagram will be adjusted to be correct. If we don't remove it, we need to split the SD into two separate diagrams.

    With all this in mind, I'd suggest:

    • that the Publish MEP use only MSG Messages, which is what they are intended for
    • and stating that REQ messages expect a response, even if it is only an acknowledgement (this would also remove the RESPOSE:BOOLEAN field from REQ messages.
    • this results in modifying the Sequence Diagram for Publish MEP (Note that this diagram is actually incorrect, anyway, because as shown, it says that to Publish, the publisher sends a MSG and then a REQ.) At a minimum, this diagram needs to be fixed, even if we don't make the semantic changes described here.

    Note that if we remove "RESPONSE:BOOLEAN" concept, this affects the following:
    8.4.1.3 Directive Request Contents
    8.10.1.3 Command Request Message Contents
    8.12.1.3 Simple Service Request Message Contents

    Additionally, we'd need to look for scattered text in the spec that says REQ does not require a response.

  • Reported: C2MS 1.0 — Thu, 17 Feb 2022 16:54 GMT
  • Updated: Tue, 14 Jun 2022 15:40 GMT
  • Attachments:

Consider forcing a limited subscription

  • Key: C2MS11-83
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    In the case of Mnemonic Value Request Message and Archive Mnemonic Value Request Message, the requestor can specify a STOP-TIME or DURATION, but both are optional. If neither is specified, the subscription is open-ended with no knowable end, until the requestor sends a 'STOP' message. In order to avoid infinite fulfillment of a subscription to a potentially lost requestor, we could enforce a concept that a requestor must specify either a STOP-TIME or Duration.

    In practice, this is an inadequate requirement, since a caller could specify a very long duration, like 1000 years, and circumvent the desire of this issue.

    However, this is issue simply captures the idea to promote further discussion.

  • Reported: C2MS 1.0 — Tue, 22 Mar 2022 21:15 GMT
  • Updated: Tue, 14 Jun 2022 15:31 GMT

Real-world STREAM-MODE Issues

  • Key: C2MS11-90
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    A number of C2MS Messages include the concept of marking the mode of the data as “real-time (RT), replay (RPY), simulation (SIM), or test (TEST)” through a required field, STREAM-MODE.

    The specific messages are:

    • Telemetry CCSDS Packet Message
    • Telemetry CCSDS Frame Message
    • Telemetry TDM Frame Message
    • Telemetry Processed Frame Message
    • Replay Telemetry Data Request Message
    • Attitude Parameter Message
    • Attitude Ephemeris Message
    • Orbit Parameter Message
    • Orbit Mean-Elements Message
    • Orbit Ephemeris Message
    • Tracking Data Message

    Where used, STREAM-MODE is a required field. A typical explanation in the C2MS Spec is that, “The STREAM-MODE field is used to classify the kind or source of the” message.
    Although this may be useful in a closed experimental/engineering system, the concepts are not appropriate for an operational SATOPS system, where replay, test, sim data should never be mixed with real-world operational data. In a system with many components, the use of the STREAM-MODE field assumes that every component will properly handle the distinction for every message. As an example, a FireThrusters CMD message is received and the component fails to note that this particular message is a RPY STREAM-MODE and thinks to itself… ‘huh, I thought we fired thrusters, yesterday… but, OK, here it goes…”. In another example, a SelfDestruct CMD message is received and the component fails to note that the message is marked as TEST or SIM…

    Instead of marking messages themselves, this type of distinction should be performed environmentally; one system is the operational system, other, separate systems are for simulation or test, another separate system performs forensics (replay). Keeping these purposed environments isolated from each other ensures that data never intermixes where not appropriate.
    The resolution to this concern could be any of the following:

    1. Remove the STREAM-MODE field — breaks backward compatibility, and affects any system already using this field. However, it represents a clean break from a field that should never be used in practice, anyway.
    2. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and mark the field as deprecated (deprecated = should no longer be used and will be removed in a future major release) — maintains backward compatibility, but signals to users to cease using the field.
    3. Make the STREAM-MODE field optional with default value assumed to be RT (real-time) and provide a best-practices statement; something to the effect of, “Although maintained for backward compatibility, the use of this field is strongly discouraged for operational systems, where test, sim, or replay data should never mix with real-world operational data” — this weakest approach leaves the use of the field in the hands of the user, but would be a bit embarrassing from the standpoint of a specification to preserve a capability that is strongly discouraged.

    See attachment for non-exhaustive use in C2MS Spec.

  • Reported: C2MS 1.0 — Fri, 10 Jun 2022 13:45 GMT
  • Updated: Tue, 14 Jun 2022 15:30 GMT
  • Attachments:

XML PSM recommended

  • Key: C2MS11-7
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Due to lack of the ability to have multiple independent implementations of GMSEC due to its message-building API functions in source code, it would be appreciated if there were an XML PSM available. This would allow for an independent implementation apart from the single known implementation at this time. At this time, there is no known PSM that enables implementation of C2MS at this time that does not depend on FOSS or government-licensed IP.

    This is based on inputs from C2MS-2.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:07 GMT
  • Updated: Sat, 11 Jun 2022 23:20 GMT

C2CX Heartbeat comments

  • Key: C2MS11-2
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 7.5.4

    • Suggest not having CPU / Memory utilization in the messages. That would be better implemented through normal system monitoring mechanisms (e.g., SNMP). Code to retrieve such information is typically platform-specific and is not related to the business logic of the component.
    • If such information is required, suggest having a system monitoring component instead.
    • Unclear exactly how this would work in a clustered environment. Different hosts implementing the same service would provide conflicting answers.
    • Unclear why the commentary on why memory leaks are bad is in the spec
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:21 GMT
  • Updated: Tue, 7 Jun 2022 14:55 GMT

Use @key instead of @Key

  • Key: C2INAV12-1
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL shipped with this specification uses @Key but that should be @key, IDL is case sensitive and DDSXTypes/IDL42 define @key, all lower case

  • Reported: C2INAV 1.0 — Tue, 7 Sep 2021 13:25 GMT
  • Updated: Wed, 13 Apr 2022 18:38 GMT

6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive"i

  • Key: CPP1116-37
  • Status: open  
  • Source: Micro Focus ( Simon McQueen)
  • Summary:

    The section says:

    "For all primitive types, enums, and
    reference types, an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

    This is the only use of "primitive types" in the spec. "Basic Data Types" should be preferred. Would suggest:

    "For all Basic Data Types [link/ref to 6.6 Mapping for Basic Data Types], enums [link/ref to 6.9 Mapping for Enums], and
    reference types [link/ref to 6.7.1 Reference Types], an in argument A of type P, that argument is passed as P. For all other types, an in argument A of type P is
    passed as const P&. For an inout and out argument it is passed as P&. If we return a type of P, it is returned as P."

  • Reported: CPP11 1.5 — Fri, 10 Dec 2021 15:02 GMT
  • Updated: Fri, 1 Apr 2022 07:18 GMT

Deprecate Archive Message Retrieval Messages

  • Key: C2MS11-43
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    The Archive Message Retrieval Request Message and related Archive Message Retrieval Response Message should be considered for deprecation.

    These are useful messages in an engineering environment when all messages and their corresponding storage method allows unfettered access to all consumers regardless of authentication/authorization, but in a real-world operational environment, this construct is much too uncontrolled.

    For example, the Archive Message Request allows, and suggests, sending a SQL statement or script expression in the REQ-STRING field, which the service provider would execute on behalf of the requestor, creating an exploitable cyber attack opportunity for malicious software.

    Even if the REQ-STRING were removed and the request only allowed for PROD-TYPE/PROD-SUBTYPE (the other way to request the archive), this would allow for all messages that ever flowed in the environment to be forwarded to a single requestor. In an unsecured system, that might make sense, but it is not appropriate in any system that closely controls who is allowed to send/receive any given message.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:20 GMT
  • Updated: Wed, 23 Mar 2022 15:29 GMT

Consider a mechanism to request archived Commands and Events

  • Key: C2MS11-44
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mike Anderson)
  • Summary:

    TLM and MVALs can be retrieved from the archive, but it would be useful to define a way to retrieve archived Commands and Events as well, since these represent, along with TLM, the SatOPs messages.

  • Reported: C2MS 1.0 — Fri, 10 Dec 2021 03:22 GMT
  • Updated: Wed, 23 Mar 2022 15:29 GMT

C2MS specification on page 168 is not clear regarding CMD-FORMAT=MNEMONIC

  • Key: C2MS11-41
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    It is not clear in the C2MS specification how to use/support the CMD-FORMAT=MNEMONIC on page 168. Explanation of the encoding should be provided to understand how to represent a command mnemonic and its arguments.

  • Reported: C2MS 1.0 — Tue, 6 Jul 2021 13:01 GMT
  • Updated: Wed, 23 Mar 2022 15:27 GMT
  • Attachments:

Acknowledge Final Status inconsistency

  • Key: C2MS11-8
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Based on review of latest specification, the problem detailed in C2MS-5 is still present. This problem makes it not possible for a client application to properly be developed to support all MEPs. If a client application is developed to support MEP2, then it will ignore all future responses after the first ACK comes in when communicating with a server that supports MEP4 or MEP5. If a client application is developed to support MEP4 and MEP5, then it will never think that a request finished when communicating with a server that supports MEP2.

    As is currently specified, via table 6-9 on page 20, the Acknowledge is listed as a Final Status. Though it is only a final status in MEP2.

    Possible solutions:
    1. Remove MEP2. This would make Acknowledge in Table 6-9 have a Final Status of "No"
    2. Add an additional status code of Acknowledge Complete (perhaps #7). In this option, Acknowledge (#1) would have Final Status of "No", though new Acknowledge Complete (#7) would have Initial Status of "Yes", Intermediate Status of "No", and Final Status of "Yes".

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:44 GMT
  • Updated: Wed, 23 Mar 2022 15:18 GMT

Remove value for CNTL-STRING from CNTL message

  • Key: C2MS11-37
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    The field CNTL-KEYWORD in the Control Message is supposed to contain the keyword extracted from the field CNTL-STRING. It should not be fixed. So, remove the value from the diagram. Figure 8-9. This is a Model change.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:49 GMT
  • Updated: Sun, 20 Mar 2022 01:12 GMT

In message Archive Message Retrieval Response, fix Header field names

  • Key: C2MS11-34
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Typo in the diagram only for Archive Message Retrieval Response calls the Header fields it uses MSG-TYPE and MSG-SUBTYPE. They should be MESSAGE-TYPE and MESSAGE-SUBTYPE, respectively. See page 64, figure 8-5.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:38 GMT
  • Updated: Sun, 20 Mar 2022 01:08 GMT

Log message scope too broad, need Alert/Status style message introduced

  • Key: C2MS11-15
  • Status: open  
  • Source: The MITRE Corporation ( Ryan Conrad)
  • Summary:

    The LOG message is nice to cover a certain scope of messages needing to be utilize by developers using the specification, however the ProductMessage again and again finds itself utilized instead of the LOG message because of the structure the LOG message has versus the ProductMessage for making things like status or event messages.

    Because of this, I had looked at the ALMAS specification from Navy and the CAP (Common Alerting Protocol) from OMG to come up with an Alert Notification and Alert Ack message that would be greatly helpful in making a solid Header for alert and status messages that could be different in scope than typical LOG messages.

    I have these messages defined in GMSEC/COMPATC2, and would need to attach it for you to see the details. Thank you

  • Reported: C2MS 1.0b2 — Mon, 30 Sep 2019 18:57 GMT
  • Updated: Thu, 17 Mar 2022 02:05 GMT

Specify multiplicity for required and optional fields

  • Key: C2MS11-14
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    Set the association multiplicity for required fields to '1' and optional fields to '0..1'

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:37 GMT
  • Updated: Thu, 17 Mar 2022 02:03 GMT

Requesting data via pub/sub requires knowing publisher's service name

  • Key: C2MS11-10
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. This could potentially be solved by a registry concept, as in C2MS11-1, but this particular issue proposes adding a service-matching capability wherein the requester is asking for a subscription to some data and the request results in linking the subscription to a service that provides that data.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Updated: Thu, 17 Mar 2022 01:53 GMT

Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects

  • Key: C2MS11-35
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Review and fix all uses of DESTINATION-COMPONENT in the Miscellaneous Elements of subjects for all messages where that field is used. Also, see 2016 GMSEC ISD for discussion of destination component and add that back in to the description of Configuration Status Message. See pages 74 and 78.

  • Reported: C2MS 1.0 — Wed, 24 Jun 2020 18:41 GMT
  • Updated: Mon, 14 Mar 2022 21:20 GMT

Time Type table clarification for the DDD portion

  • Key: C2MS11-27
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Document clarification: The DDD portion of the Time Type, as shown in table 8-2 on page 40, has a range of 1-365 (or 366). But when using a relative time (by preceding the value with a "+" or a "-"), the DDD portion can contain a zero value. Make this clear and add a couple more relative time examples.

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 17:17 GMT
  • Updated: Mon, 14 Mar 2022 20:44 GMT

For consistency, all message types should have a name that ends with "message"

  • Key: C2MS11-11
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    For most of the message types in C2MS, this convention is followed. The exceptions are:

    -Archive Message Retrieval Request
    -Archive Message Retrieval Response
    -Telemetry Message for CCSDS Packet
    -Telemetry Message for CCSDS Frame
    -Telemetry Message for TDM Frame

    Recommendation is to deffer this issue, but wanted to capture it because the community will ask why the inconsistent naming.

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Updated: Fri, 11 Mar 2022 15:20 GMT

Archive Mnemonic Value Request comments

  • Key: C2MS11-3
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 8.9.1

    • Need official registry for FORMAT values

    The AMVR message has a field called FORMAT that is of type String, but there is no enumeration of possible formats. This could be handled by requestor and supplier agree on a format.

    FORMAT is used to define the file format of the return data.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Updated: Fri, 25 Feb 2022 16:15 GMT


Typo in example

  • Key: CPP1116-36
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    using M2 = IDL::bounded_map<std::string, T, 20;

    should be

    using M2 = IDL::bounded_map<std::string, T, 20>;

  • Reported: CPP11 1.5 — Wed, 20 Oct 2021 06:24 GMT
  • Updated: Wed, 3 Nov 2021 16:29 GMT

Extend InvalidName exception

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

    We propose to extend the InvalidName exception with a "string name" member to simplify analyzing problems when this exception is thrown, the exception will tell at that moment the name that failed

  • Reported: CORBA 3.4 — Mon, 11 Oct 2021 08:56 GMT
  • Updated: Wed, 13 Oct 2021 16:25 GMT

Use RFC7231 for Error reporting

  • Key: API4KP-17
  • Status: open  
  • Source: Mayo Clinic ( Davide Sottara)
  • Summary:

    The spec defines an api4kp:services:Error datatype class used to wrap error messages.

    A better, and standard, datatype for this very purpose is defined in https://datatracker.ietf.org/doc/html/rfc7231

    Consider aligning

  • Reported: CMMN 1.1 — Wed, 29 Sep 2021 15:51 GMT
  • Updated: Wed, 29 Sep 2021 15:51 GMT

Replace Cookie with a string and use IDL map

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

    Currently CCM uses a Cookie which is returned from the connect operations which has to be pased with disconnect. This requires the deployment tooling to store this Cookie at deployment for usage later on at teardown. As each connection has a unique string id in the plan we propose to replace the Cookie with the unique string id which is from the deployment plan. With a connect this string is passed with the connect call, later on with disconnect the same string can be passed again. For all calls that retrieve a struct containing a Cookie we propose to replace this with a IDL map with the string as id , the reference as second value.

    These changes make deployment logic/tooling much easier, also now a IDL map is used which makes user code more clean instead of emulating a map with a sequence with a struct where the user has to search themselves.

  • Reported: CORBA 3.4 — Fri, 20 Aug 2021 09:23 GMT
  • Updated: Wed, 8 Sep 2021 13:46 GMT

Extend Union mapping

  • Key: CPP11-267
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping got extended to allow setting the union value and discriminator in one operation, see https://issues.omg.org/issues/CPP1114-14. This could be done in this language mapping also, but keep the discriminator, that keeps it backwards compatible

  • Reported: CPP 1.3 — Thu, 4 Mar 2021 07:08 GMT
  • Updated: Thu, 19 Aug 2021 14:25 GMT

Add CDR marshaling support for IDL4 int8/uint8/map/biset/bitfield/bitmask

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

    IDL4 extends the IDL type system with int8/uint8/map/bitset/bitfield/bitmask, these all could be useful at the CORBA layer so to have guaranteed interoperability CORBA should define the CDR marshaling support for these new types

  • Reported: CORBA 3.3 — Tue, 13 Oct 2020 08:20 GMT
  • Updated: Tue, 27 Oct 2020 21:06 GMT

URLs, URIs and namespaces for CMMN 1.1 XSDs are not aligned


Data Dictionary Messages

  • Key: C2MS11-5
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    It seems that there is a consensus that we need database data dictionary informational messages. It seems to be in work. Capturing the item here.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:23 GMT
  • Updated: Mon, 21 Sep 2020 14:23 GMT

Editorial corrections

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

    p16 7.3.6 cont'd

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

    -> context ConsumesDef



    p18 7.3.6 cont'd

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

    -> Constraints



    p18 7.3.6 cont'd

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

    -> c.oclIsTypeOf(ValueMemberDef)

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



    p19 top

    else
             result = home.key
    endi f }
    

    -> endif }



    p32 paragraph below Figure 7.16, last sentence

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

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



    p44 CORBAUnion example

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

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

                  INTEGER_CL,
                  FLOAT_CL,
                  DOUBLE_CL,
                  COMPLEX_CL,
                  STRUCTURED_CL
            };
    



    p45 Figure 8.9 - Union example (a)

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



    p45 Figure 8.10 - Union example (b)

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

    "lable" -> "label"



    p45 CORBAStruct example

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

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



    p49 CORBAArray list 1st bullet 4th sentence

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

    -> The value of the tag “index”



    p62 Constraints

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

    -> Constraints



    p62 Constraints

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

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

    -> c.oclIsTypeOf(ValueMemberDef)

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



    p63 8.2.3 Example

            typedef enum PhilosopherState
            {
    

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

            enum PhilosopherState
            {
    



    p63 8.2.3 Example

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

    -> secondsSinceLastMeal



    p66 Figure 8.25 bottom left

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

    -> service



    p71 paragraph before 8.4.2

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

    -> CORBAComponentFile , CORBAIDLFile , CORBAContainedFile , CORBADependentFile



    p71 Table 8.4 rightmost column header Const-raints

    -> Constraints



    p82 Class2Interface

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

    -> cl.operation



    p86 9.2.1 example, cont'd

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

    -> calculates

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

Use of symbolic constant as string or sequence bound

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

    Page 47 beneath Figure 8.13 contains:

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

    Page 48 CORBASequence contains:

    Sequences are represented in the Profile by two means:

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

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

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

    I propose following clarification:

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

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

    Consider the following IDL:

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

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

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

Typos at figure 8.6 Constant example

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

    The IDL example on page 41 above Figure 8.6 is:

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

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

          const short S = 3;
          [...]
                const long L = S + 20;
    
  • Reported: CCCMP 1.0 — Wed, 8 Apr 2020 15:18 GMT
  • Updated: Thu, 9 Apr 2020 18:44 GMT

Lack of a registry concept

  • Key: C2MS11-1
  • Status: open  
  • Source: NASA ( Jay Bugenhagen)
  • Summary:

    Discoverability of data is still a major concern due to the lack of a registry.

    • Unclear how components are supposed to find out about available resources
    • Unclear how components are supposed to find out about related subjects
    • What is the associated heartbeat subject of a client, particularly a temporary one?
    • ME1 depends on knowing the name of the other end beforehand. Where is this supposed to come from and why should a component have to care about that?
    • Recommend a registry be considered and answers to question above.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:10 GMT
  • Updated: Tue, 24 Mar 2020 15:11 GMT

"Mnemonic" should be called "Parameter"

  • Key: C2MS11-12
  • Status: open  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

    This to be consistent with the XTCE Specification. Moreover Mnemonic isn't accurate as the very definition of mnemonic is a shorthand "code" for the actual parameter name.

    Recommend close/deferring this issue, but believe it's important to capture our rationale as the community will ask why the inconsistency between SDTF specifications.

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:48 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Pub/Sub subscription status unknown

  • Key: C2MS11-9
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Justin Boss)
  • Summary:

    C2MS should offer a mechanism for clients and/or servers to be able to check validity of a subscription.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:43 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS11-6
  • Status: open  
  • Source: Boeing ( David Overeem)
  • Summary:

    I do not expect this can be addressed by the FTF. Suggest vote to defer to a future revision.

    For a complete implementation of C2MS on the systems I use, we need some kind of Procedure Script Execution set of messages. These would include being able to launch procedures, monitor them, show progress, etc. This could be a topic of some significant discussion and is entirely new scope. The closest analogue I have so far found is the Activity Tracking stuff in the CCSDS Mission Operations Common Services.

    if I do not write it down, I will forget.

  • Reported: C2MS 1.0b1 — Thu, 13 Sep 2018 00:28 GMT
  • Updated: Fri, 3 Jan 2020 20:50 GMT

Support alternative way of modeling single dimension CORBAArray

  • Key: CORP-10
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    CORBASequence uses multiplicity at the member members to define the sequence upper bound.
    The most frequent case of CORBAArray is the single dimensional array.
    Proposal: Permit using the members multiplicity for this common case in a similar way as for bounded sequence.
    When using this alternative way of modeling:

    • The multiplicity lower bound and upper bound shall both be set to the same value - the array size.
    • The stereotype tag index shall not be used; in other words, usage of attribute multiplicity shall not be mixed with the index tag.

    Modeling of multi dimensional arrays is not in affected by this proposal.

  • Reported: CORP 1.0b1 — Tue, 3 Sep 2019 08:50 GMT
  • Updated: Tue, 3 Sep 2019 18:57 GMT

Use of expression as sequence/array bound

  • Key: CORP-9
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    According to the IDL 4.2 grammar, the bound number of bounded sequence / bounded string and fixed array size is a
    positive_int_const which resolves to const_expr.
    In the examples for bounded sequence an array, the specification only shows literal constants used for the sizes.
    It is not defined how to use expressions, such as a reference to an IDL const declaration, as the size.
    At the least, it should be required to model a UML Dependency association from the CORBASequence / CORBAArray type to the const declaration.

  • Reported: CORP 1.0b1 — Sat, 31 Aug 2019 17:03 GMT
  • Updated: Tue, 3 Sep 2019 18:56 GMT

Missing support for IDL "native"

  • Key: CORP-8
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The specification omits support for the IDL native declaration.

  • Reported: CORP 1.0b1 — Sat, 31 Aug 2019 09:25 GMT
  • Updated: Tue, 3 Sep 2019 18:55 GMT

Bounded string attribute of struct/union/valuetype/interface is not mapped

  • Key: CCCMP-16
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    Section 8.1.2 defines stereotypes CORBAAnonymousSequence and CORBAAnonymousArray for mapping sequence/array attributes of struct/union/valuetype/interface without a dedicated typedef.
    However, an equivalent CORBAAnonymousString stereotype is not defined.
    Thus it is not obvious how to map e.g.

      struct struct_with_anon_bounded_str {
        string<32> anon_bounded_str;
      };
    
      union union_with_anon_bounded_str switch (boolean) {
        case TRUE:
          string<32> anon_bounded_str;
      };
    
      valuetype valuetype_with_anon_bounded_str {
        public string<32> anon_bounded_str;
      };
    
      interface interface_with_anon_bounded_str {
        attribute string<32> anon_bounded_str;
      };
    
  • Reported: CCCMP 1.0 — Wed, 20 Mar 2019 09:27 GMT
  • Updated: Mon, 8 Apr 2019 16:47 GMT

Clarify semantics of None Event Listeners

  • Key: CR-154
  • Status: open   Implementation work Blocked
  • Source: BPM Advantage Consulting ( Stephen White)
  • Summary:

    Event Listeners without a defined Event (User or Timer) are concrete elements and can be added to CMMN models.
    However, the execution semantics are not clear.
    Is the listener immediately triggered since there is nothing to wait for? Or does it wait indefinitely since there is nothing to wait for?
    [the former would be preferable]

    There are modeling styles that would use empty Event Listeners and it should be made clear if this is valid for execution.

  • Reported: CMMN 1.1 — Wed, 17 Oct 2018 18:10 GMT
  • Updated: Thu, 18 Oct 2018 20:03 GMT

Extended UML metamodel derivations of <>

  • Key: CCCMP-15
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    The UML Profile for CORBA and CCM on page 47 states:

    The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAString>>, <<CORBAWstring>>, and <<CORBASequence>> stereotypes.

    The part about «CORBAString» and «CORBAWstring» inheriting from «CORBATemplate» does not fit with figure 8.7 on page 42 which shows that those stereotypes inherit from «CORBABounded».

    According to the class diagram, the sentence should be:

    The extended UML metamodel contains an abstract stereotype <<CORBATemplate>>, which is a generalization of <<CORBAArray>> and <<CORBASequence>> stereotypes.
    
  • Reported: CCCMP 1.0 — Fri, 9 Feb 2018 13:02 GMT
  • Updated: Mon, 12 Feb 2018 10:28 GMT

Inconsistent spelling of color attributes in text, MM and XSD

  • Key: CR-153
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    In spec text and meta-model the Diagram Interchange attributes fillColor, strokeColor and fontColor are spelled with a lowercase first letter. However, in the XML Schemal they are spelled with an uppercase first letter: FillColor, StrokeColor and FontColor.

    Proposal:
    Adjust spelling in text and MM, because XSD is already implemented and in use.

  • Reported: CMMN 1.1 — Mon, 16 Oct 2017 13:48 GMT
  • Updated: Tue, 17 Oct 2017 14:31 GMT

An Initial transition can't contain any trigger/event

  • Key: CR-152
  • Status: open  
  • Source: NobleProg ( Filip Stachecki)
  • Summary:

    All initial transitions (create transitions) contain "create" trigger/event. It's illegal according to UML specification (State Machines).
    We could use "/create" instead to specify what kind of behavior is executing while transiting from initial node to the first state e.g. Active.

  • Reported: CMMN 1.1 — Tue, 27 Jun 2017 13:55 GMT
  • Updated: Tue, 27 Jun 2017 15:31 GMT

autoComplete doesn't take into account the event listeners

  • Key: CR-151
  • Status: open  
  • Source: Loqutus ( Stijn Beeckmans)
  • Summary:

    I was wondering why the stage autocomplete doesn't take into account the event listeners. At some point in time, it might be possible that a stage has no active children, but an event is still waiting for something. So in this case, I would expect that the stage doesn't autocomplete until the event has happened.

    Is there a reason why this is implemented otherwise?

  • Reported: CMMN 1.1 — Wed, 22 Feb 2017 10:06 GMT
  • Updated: Wed, 22 Feb 2017 15:27 GMT

Figure 7.4 'CMMN Shape' shows attribute isExpanded instead of isCollapsed

  • Key: CR-150
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Figure 7.4 'CMMN Shape' shows an attribute isExpanded instead of isCollapsed, which is described in spec text, tables and XML schema.

    Proposal:
    In Figure 7.4 on page 85 (PDF 101) replace attribute isExpanded with isCollapsed.

  • Reported: CMMN 1.1 — Tue, 9 Aug 2016 11:16 GMT
  • Updated: Wed, 10 Aug 2016 14:13 GMT

Wrong manual activation default and missing defaults for ManualActivationRules, RequiredRules and RepetitionRules without condition

  • Key: CR-148
  • Status: open   Implementation work Blocked
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Problem Desciption

    The condition expression of ManualActivationRules, RequiredRules and RepetitionRules is optional as shown in Figure 5.13 (PlanItemControl class diagram) on page 50 (PDF 66).
    Therefore, CMMN has to define default behaviors for two cases:

    1. A ManualActivationRule, RequiredRule and RepetitionRule is not present at all
    2. A ManualActivationRule, RequiredRule or RepetitionRule is present, but has no condition expression defined.

    The following sentences seem to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

    "A ManualActivationRule comprises of an Expression that MUST evaluate to boolean. If no ManualActivationRule is specified, then the default is considered “true.”"

    However, instead of defining the behavior for a missing condition expression (case 2), it talks about the marker itself and thereby accidentally makes all tasks and stages manual by default if they don't have the manual activation marker (case 1).
    This is completely contradicting the meaning of the manual activation marker: It would mean that a task can only be activated automatically, if it has a ManualActivationRule with a condition set to "false". By having a ManualActivationRule that task also gets the manual activation marker although it is activated automatically. On the other hand a task that has no ManualActivationRule would not get the manual activation marker although it is activated manually.

    Similar sentences are correct for case 1, but fail to define a default for case 2 in Table 5.49 (PlanItemControl attributes and model associations) on page 51 (PDF 67):

    "A RequiredRule comprises of an Expression that MUST evaluate to boolean. If no RequiredRule is specified, the default is “false.”"

    "A RepetitionRule comprises of an Expression that MUST evaluate to boolean. If no RepetitionRule object is specified, the default is “false.”"

    Furthermore, there is a cardinality mismatch between Tables 5.50, 5.51 & 5.52 and MM/XSD for conditions of ManualActivationRules, RequiredRules and RepetitionRules

    Recomendation

    This issue has been confirmed by people that worked in the CMMN specification. In particular: Mike Marin (IBM), Denis Gagné (Trisotech), Henk de Man (VDMbee), Ralf Mueller (Oracle) and Falko Menge (Camunda). They expect to see this issue fixed in the next CMMN version. In the meantime, they encourage all implementers and users of CMMN to read "false" instead of "true" in the description of attribute manualActivationRule in CMMN 1.1 Table 5.49 (PlanItemControl attributes and model associations), because the current specification text can lead to misinterpretations. Correct behavior is described in the following image:

    Proposal for Specification Text

    In Table 5.49 (PlanItemControl attributes and model associations) on page 50 (PDF 66):

    replace the following sentence:

    "If no ManualActivationRule is specified, then the default is considered “true.”"

    with:

    "If no ManualActivationRule is specified, then the default is considered “false.”"

    In Table 5.50 (ManualActivationRule attributes) on page 52 (PDF 68):

    Replace "Expression[1]" with "Expression[0..1]".
    Add the following sentence to the description of the attribute condition:

    "If no Expression is specified, then the default is considered “true.”"

    In Table 5.51 (RequiredRule attributes) on page 52 (PDF 68):

    Replace "Expression[1]" with "Expression[0..1]".
    Add the following sentence to the description of the attribute condition:

    "If no Expression is specified, then the default is considered “true.”"

    In Table 5.52 (RepetitionRule attributes) on page 53 (PDF 69):

    Replace "Expression[1]" with "Expression[0..1]".
    Add the following sentence to the description of the attribute condition:

    "If no Expression is specified, then the default is considered “true.”"

  • Reported: CMMN 1.1 — Mon, 4 Jul 2016 07:39 GMT
  • Updated: Wed, 13 Jul 2016 12:23 GMT

Name missmatch between Table 5.51 and MM/XSD for condition of RequiredRules

  • Key: CR-149
  • Status: open  
  • Source: Camunda Services GmbH ( Falko Menge)
  • Summary:

    Meta Model and XML schema use condition with lowercase c whereas Table 5.51 uses an uppercase C.

    Proposal:
    In Table 5.51 - RequiredRule attributes on page 52 (PDF 68) replace "Condition" with "condition".

  • Reported: CMMN 1.1 — Thu, 30 Jun 2016 18:39 GMT
  • Updated: Tue, 5 Jul 2016 12:08 GMT

Process Task and Case Task should have performer defined

  • Key: CR-146
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    It may be useful to be able to define the Performer for task of type Process and Case

  • Reported: CMMN 1.1 — Wed, 25 May 2016 14:27 GMT
  • Updated: Wed, 29 Jun 2016 15:55 GMT

Allow the possibility to define multiple standard events for an onPart

  • Key: CR-147
  • Status: open  
  • Source: Trisotech ( Denis Gagne)
  • Summary:

    When visually modeling it is often desired to have a planItem react to multiple standard events (e.g. when a certain caseFileItem is created or update or addchild or removechild etc. do this).
    Presently it is required to visually depict multiple copies of the caseFileItem with a separate onPart for each of the Standard events we want to react to because onPart can only have one standard event.
    It is proposed to allow onPart to have multiple standard events defined all of them in a disjontion (e.g. created OR addchild OR removechild or etc.)

  • Reported: CMMN 1.1 — Wed, 25 May 2016 14:40 GMT
  • Updated: Wed, 29 Jun 2016 15:53 GMT

Faulty CTS2 1.1 wsdl files

  • Key: CTS213-13
  • Legacy Issue Number: 19832
  • Status: open  
  • Source: Anonymous
  • Summary:

    The wsdl files provided at http://www.omg.org/spec/CTS2/1.1/ are not correct. #
    We tried to generate java services with wsdl2java using these wsdl and xsd files but got errors due to faulty namespace settings and incorrect fault settings in the methods.

    Where can we obtain the correct wsdl files to implement CTS2 specification conform soap services?

  • Reported: CTS2 1.2 — Thu, 10 Sep 2015 04:00 GMT
  • Updated: Thu, 10 Sep 2015 13:16 GMT

semantics of boolean iterator.next(out thing) ...

  • Key: COLL-16
  • Legacy Issue Number: 3271
  • Status: open  
  • Source: med.uu.nl ( Philip Lijnzaad)
  • Summary:

    here's a thing that has been bugging me for a while: the description of the
    semantics of the iterators in some of the CORBA Services seems to be unclear
    and inconsistent. They falls into two categories:

    Semantics A: returned value is relevant for the next invocation

    PropertyService says:

    The next_one() operation returns TRUE if an item exists at the current
    position in the iterator ... A return of FALSE signifies no more items in
    the iterator.

    Interoperable Naming Service says:

    The next_one() operation returns the next binding. It returns TRUE if it is
    returning a binding, FALSE if there are no more bindings to retrieve. If
    next_one() returns FALSE, the returned Binding is indeterminate.

    (the intention behind this is actually different, see below, as Michi
    Henning pointed out to me)

    The Trader Service (e.g. OfferIdIterator) says:

    The next_n() operations returns TRUE if there are further offer identifiers
    to be extracted from the iterator. It returns FALSE if there are no
    further offer identifiers to be extracted.

    (this is also clear, even though I don't think this is the rigth design).

    Semantics B: returned value is relevant for the past invocation:

    The Collection Service:

    retrieve_element_set_to_next() returns TRUE if an element has been
    retrieved.

    (This is really clear)

    In case A, a client always has to check whether s/he got something useful in
    the out parameter (since a FALSE return only says something about the
    subsequent call); this is not very elegant. In case B, a client always has to
    spend a fruitles round-trip to the server to know when the iteration is
    finished. This is IMO a better solution, and should preferably be adhered to
    by any OMG standard.

  • Reported: COLL 1.0b1 — Fri, 4 Feb 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:32 GMT

21.5 SQL-99 Data Types

  • Key: CWM12-17
  • Legacy Issue Number: 12325
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    SQL-99 is superseded by SQL:2003 (see comment on 3), which is mainly the same except that BIT and BIT VARYING data types are no longer included.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Review the semantics of existing attribute types that are also CWM classes

  • Key: CWM12-71
  • Legacy Issue Number: 4404
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    The precise semantics of the use of the CWM Expression class (and
    its subclasses) as the type of attributes of CWM classes is not clearly
    delineated (as discussed at the 7/12/01 CWM RTF meeting in Danvers, MA).
    Review the semantics of existing attribute types that are also CWM classes
    and correct them as needed.

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0

  • Key: CWM12-57
  • Legacy Issue Number: 4511
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Support for XMI for XML Schemas The above will probably be adopted at the September 2001 meeting. CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0 flavors. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Add a representation for sequence to CWM relational package

  • Key: CWM12-70
  • Legacy Issue Number: 4430
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    A sequence is a relational database object that allows the automatic generation of values. Sequences are ideally suited to the task of generating unique key values. Applications can use sequences to avoid possible concurrency and performance problems resulting from the generation of a unique counter outside the database. Currently, the CWM Relational package does not provide a representation for sequence. It should be added.

  • Reported: CWM 1.0 — Thu, 26 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make ChangeRequest useful

  • Key: CWM12-56
  • Legacy Issue Number: 4515
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This should be part of BusinessInformation: it is not at all specific to WarehouseOperations since one could request changes to database schemas, transformations or pretty much anything.

    'isActive' would be better than 'completed' for ChangeRequest, and would observe the convention of using 'is' for booleans. Moreover it should be a derived nonchangeable attribute to avoid inconsistency with 'status'.

    The reference from ChangeRequest to ModelElement should be 0..* since the request might be to create something new that cannot yet be referred to!

    The following are considered essential for most ChangeRequests: 1) two multivalued optional references to ResponsibleParty to indicate: a) raiser b) actionee 2) optional single-valued integer attribute 'priority' (larger value = more important), constrained to be non-negative. 3) optional single-valued string attributes 'raisersIdentifier' and 'identifier' (representing an id allocated by the raiser and that used internally by the warehouse management system). 4) optional multivalued string attribute 'history' to describe events in managing the request. 5) optional string attribute 'resolution' to decribe what actually happened (e.g. how the modelElements were changed, why the request was rejected etc).

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 12.1 Overview

  • Key: CWM12-22
  • Legacy Issue Number: 12322
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    "...and several examples are provided in Volume 2, Extensions, of the CWM Specification." This document is not referenced in either Clause 3 or the References Annex, and its role in this specification is not defined.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

CWM Object resource package does not provide support for exceptions

  • Key: CWM12-76
  • Legacy Issue Number: 4399
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Modern object-oriented programming languages such as Java and C#
    support the notion of exceptions as first class objects. However, the CWM
    Object resource package does not provide support for exceptions. Although
    exceptions might be added to extension packages specifically designed for
    each language that needs them, such an approach would not promote
    interchange of exceptions between data warehouse components written in
    different languages. This problem will become particularly accute for .NET
    languages in which particular exceptions are defined by language independent
    components (such as the .NET CLR libraries) and can be returned to
    application components written in any of a group of languages. Suggested
    approaches to resolving this difficulty might include (1) adding exceptions
    to the CWM Behavioral package or (2) creating an Object package and placing
    the new exception classes in it.

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 5.4

  • Key: CWM12-7
  • Legacy Issue Number: 12334
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The list of datatypes are incomplete.
    Proposed Solution:
    Include all the datatypes of ISO/IEC 11404.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Annex F: Acknowledgements

  • Key: CWM12-11
  • Legacy Issue Number: 12331
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This annex is not appropriate for an ISO standard, and cannot be normative.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The XML package should be revised/extended to represent XML schema metadata

  • Key: CWM12-64
  • Legacy Issue Number: 4467
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    This issue is to capture what has been stated in Chapter 12 of the CWM specification. The XML package should be revised and extended to represent XML Schema metadata as soon as XML Schema is adopted by W3Cas a recommendation (which happened in 5/01).

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 3 Normative References -- OCL

  • Key: CWM12-39
  • Legacy Issue Number: 12301
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    A normative reference for OCL is required, because it is used in Clause 8 (and elsewhere)
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

21.6 Type Mapping Examples

  • Key: CWM12-16
  • Legacy Issue Number: 12326
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    These tables gives data types from X/Open CLI SQL, which is not referenced in either Clause 3 or the References Annex but should not be used because they should be data types defined by SQL and the mappings defined by the current version (4) of JDBC.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Annex A: References

  • Key: CWM12-14
  • Legacy Issue Number: 12327
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This annex should not be described as Normative, since all normative references should be in Clause 3. Some of the non-normative reference should be normative and be moved to Clause 3. All references should be to current specifications.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Add features for 11404 aggregates

  • Key: CWM12-5
  • Legacy Issue Number: 12338
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The record and multidimensional arrays are aggregate datatypes and the common features of 11404 aggregates should be supported.
    Proposed Solution:
    Add features for 11404 aggregates.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

TaggedValue

  • Key: CWM12-47
  • Legacy Issue Number: 5697
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    CWM_1.0.dtd is missing the following element:
    <!ELEMENT CWM:ModelElement.taggedValue (CWM:TaggedValue)*>
    This element should be a child element of CWM:ModelElement and all elements
    that correspond to subclasses of ModelElement.

    Without this element, CWM_1.0.dtd does not conform to the CWM 1.0
    Metamodel. According to the metamodel, any ModelElement (or its subclass)
    can own TaggedValue through the TaggedElement aggregation.

  • Reported: CWM 1.1 — Thu, 24 Oct 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Modeling and packaging guidelines

  • Key: CWM12-53
  • Legacy Issue Number: 4583
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Metamodels described in the CWM specification employ certain
    modeling techniques and packaging styles in preference to others. However,
    the current text of the specification does not clearly delineate, or provide
    a rationale for, which modeling techniques and packaging styles are
    preferred and which are not. Because stylistic consistency is an important
    part of promoting both understandability and implementability, text should
    be added to the specification (possibly in Chapter 6) delineating preferred
    modeling techniques and packaging. Such documentation will provide guidance
    to submitters of enhancements to existing CWM metamodels and of new or
    replacement metamodel packges.

  • Reported: CWM 1.0 — Wed, 26 Sep 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Rationalize 'Measurement'

  • Key: CWM12-54
  • Legacy Issue Number: 4516
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This should be part of Foundation (probably Expressions or BusinessInformation): it is not at all specific to WarehouseOperations since one could apply measures to tables (for expected volumes), transformations etc.

    Measurement should have an optional reference to an Expression to define how the value has/should be calculated.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

SQLParameter

  • Key: CWM12-50
  • Legacy Issue Number: 5106
  • Status: open  
  • Source: International Business Machines ( Jean-Jacques Daudenarde)
  • Summary:

    An SQLParameter has no attribute. It should have some of the Column attribute: length, precision, scale and isNullable at minimum. This is valid for all the RDBMS.

  • Reported: CWM 1.1 — Wed, 3 Apr 2002 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Introduction - references

  • Key: CWM12-42
  • Legacy Issue Number: 12299
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The references to MOF and XMI should be the ISO documents, as in the Foreword
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.3.16 SQLIndex

  • Key: CWM12-26
  • Legacy Issue Number: 12316
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    see comment on 10.2.6
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Introduction, Page XVII

  • Key: CWM12-9
  • Legacy Issue Number: 12332
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The URLs do not work for the "three key industry standards"
    Proposed Solution:
    Change the final / to a period in each URL.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The XML features should support current XML data structures

  • Key: CWM12-2
  • Legacy Issue Number: 12341
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The XML features should support current XML data structures.
    Proposed Solution:
    Add current technology.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 4 Abbreviations and Conventions - ODBC

  • Key: CWM12-38
  • Legacy Issue Number: 12304
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    ODBC is Open Database Connectivity
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Add support for flat and nested N-dimensional arrays

  • Key: CWM12-1
  • Legacy Issue Number: 12339
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The multidimensional arrays should support the notion of APL arrays, including rank and shape attributes.
    Proposed Solution:
    Add support for flat and nested N-dimensional arrays (not just arrays nested as arrays).

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 3 Normative References

  • Key: CWM12-41
  • Legacy Issue Number: 12300
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The references to MOF and XMI should be the ISO documents, as in the Foreword
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

10.3.18 SQLParameter

  • Key: CWM12-24
  • Legacy Issue Number: 12318
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There should be a constraint that an SQL parameter can only be of type SQLDataType
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Inconsistencies caused by changing Expression etc from Data Types to Classe

  • Key: CWM12-69
  • Legacy Issue Number: 4407
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    Expression and their subtypes (BooleanExpression, etc.) were changed from Data Types (in the CWM Adapted Specification) to Classes in CWM 1.0. As a result, it caused design inconsistency in CWM. For example, ExpressionNode inherits from Element. This was designed originally based on the fact that Expression was a Data Type and could not be subclassed. It should now inherit from Expression, which can be subclassed. The CWM RTF should review and revise all such inconsistencies caused by changing Expression, Multiplicity, etc. from Data Types to Classes.

  • Reported: CWM 1.0 — Tue, 24 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Warehouse processes missing physical information

  • Key: CWM12-52
  • Legacy Issue Number: 4519
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    It's not at all clear how one links from a WarehouseProcess or TransformationExecution to the physical information that it is applied to (e.g. if the same information is replicated across a number of physical locations which is actually used as the source of a datawarehouse load?).

    At the Process level there is the opportunity for some sophistication (e.g. to list a number of physical sources/destinations in priority order); at the execution level one should record the actual instance used.

    Similarly one may want to specify and record which DeployedComponent(s) should be used to carry out the transformation.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.2.8 Procedures

  • Key: CWM12-27
  • Legacy Issue Number: 12313
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    It is inappropriate to use the name Procedure for referring to both procedures and functions (see 10.3.9). SQL uses the term routine for this purpose.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Inadequate support for Organizational Structures

  • Key: CWM12-61
  • Legacy Issue Number: 4473
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Sections 8.3 and 8.3.1.7 justify ResponsibleParty inheriting from Namespace in that it can be used for "capturing organizational structures or similar relationships". This is not only quite obscure but is inadequate for even very simple and common Warehouse-oriented situations - due to the strict composition semantics of Namespace. In particular it does not allow a single person to belong to more than one Position/Team, nor does it allow the representation of matrix/management relationships which are very common. Moreover it does not allow the separation of two very different concepts: packaging of models and organizational relationships.

    An example 'test' scenario is of 2 support teams: one for Corp Database A, another for Corp Database B. Both will always have the same Manager (regardless of who is currently filling that position) and make use the same Performance Specialist, John Wicks.

    It is proposed that CWM adopt a simple but specific Organization Structure metamodel (no more than 5 classes such as Unit, Position, Person) that also aims for consistency with OMG's recently adopted Organizational Structure Facility.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

figure 6, page 212

  • Key: CWM12-45
  • Legacy Issue Number: 5925
  • Status: open  
  • Source: Anonymous
  • Summary:

    Anyway, I think that there is a little error on the figure 6-6 chapter 6.2.4 of the v1.1 (wich is the figure 6, page 212 in the PDF, chapter 9.2.4 on the "old" document) : the Person has a "salary Column" instead of a "name column".

  • Reported: CWM 1.1 — Tue, 29 Apr 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

10.3.20 SQLStructuredType - referencingColumn

  • Key: CWM12-21
  • Legacy Issue Number: 12320
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The description of referencingColumn implies that only a 'column' (i.e. an attribute) of a structured type can be of a type REF, whereas any column of a table can be so.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

4 Abbreviations and Conventions - SQL-92 and SQL-99

  • Key: CWM12-34
  • Legacy Issue Number: 12307
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    SQL-92 and SQL-99 should not be used since they are no longer valid, and should NOT be described as ANSI documents
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

13.3.9 Schema

  • Key: CWM12-20
  • Legacy Issue Number: 12324
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The attribute XMLNamespace (also shown in Figure 13.1) is defined as a string, but it is an XML concept described by a specification separate from the referenced [XML], and quite distinct from the CWM concept of Namespace, and so should be referenced and described appropriately.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

CWM should consider generating XMI 1.2 DTDs

  • Key: CWM12-58
  • Legacy Issue Number: 4510
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Support for XMI 1.2 XMI 1.2 will probably be adopted at the September 2001 meeting. CWM should consider generating XMI 1.2 DTDs. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Invalid explicit references for some 'association generalizations' in the

  • Key: CWM12-48
  • Legacy Issue Number: 5695
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    This applies to CWM 1.1 (and also CWM 1.0).
    Sun MDR user Vincent Lombart spotted that he was getting the same
    association exported twice, which I tracked down to the following problem in
    the metamodel.

    There should be no explicit association between ClassifierMap and
    TransformationMap: the diagram in the CWM spec just documents the fact that
    the inherited ownedElement association is used to link these classes.
    The CWM XMI file is produced by the Unisys Rose integration which explicitly
    ignores such associations (signalled by '/' on the association ends - normal
    derived associations have '/' on the association name). This is used in
    several places e.g. in Relational model to show that Column and ColumnSet
    are linked using the owner-feature association.

    However in the ClassifierMap case there are also corresponding references
    explicitly defined as pseudo-attributes on Classifier and TransformationMap
    which has caused the references erroneously to be generated into the XMI
    file.

    On further investigation, the following inherited associations have
    superfluous references:

    XML:ElementType <-> XML:Schema
    XML:ElementType <-> XML:Attribute
    Transformation:TransformationMap <-> Transformation:ClasifierMap
    Transformation:TransformationActivity <-> TransformationStep (in this case
    the references are called 'step' and 'activity')
    BusinessNomenclature:Taxonomy <-> Concept
    BusinessNomenclature:Glossary <-> Term
    BusinessNomenclature:BusinessDomain <-> Taxonomy (in this case one
    reference is called just 'domain')

    Proposed resolution:
    Delete the above references/pseudo-attributes (with stereotype of
    <<reference>> though this is hidden on the diagram).

  • Reported: CWM 1.1 — Wed, 23 Oct 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

consider changing DeployedComponent from being subclass of Core::Package

  • Key: CWM12-73
  • Legacy Issue Number: 4402
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    In the SoftwareDeployment package, consider changing
    DeployedComponent from being a subclass of Core::Package to being as
    subclasss of Core::Subsystem. This change preserves the package nature of
    DeployedComponents and, at the same time, adds the ability of
    DeployedComponents to have features (because Core::Subsystem is a subclass
    of Core::Classifier, as well as Core::Package).

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Generic Data Mining metamodel issue

  • Key: CWM12-65
  • Legacy Issue Number: 4462
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    The Data Mining metamodel contains a sub-metamodel on classification/categorization, which is generic and which can be useful outside of data mining but in a data warehousing/business intelligence context. Following the tradition of CWM's design emphasis on modularity and reuse, this sub-metamodel should be made a separate package from the Data Mining package.

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Support the full set of 11404 aggregates.

  • Key: CWM12-3
  • Legacy Issue Number: 12340
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The full set of 11404 aggregates (record, array, set, bag, sequence, etc.) should be supported.
    Proposed Solution:
    Support the full set of 11404 aggregates.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.2.4 Structured Types and Object Extension , Figure 10.5

  • Key: CWM12-31
  • Legacy Issue Number: 12311
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    The figure does not enclose emp_t in parenthesis (..) as shown correctly in the associated text.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Annex D: Legal Information

  • Key: CWM12-12
  • Legacy Issue Number: 12330
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This normative annex appears to conflict with the intellectual property rights of ISO standards, and does not take account of the ISO requirement that all potential patents should be declared.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

CWM should consider using MOF 1.4 for it's metamodel

  • Key: CWM12-60
  • Legacy Issue Number: 4509
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    Support for MOF 1.4 MOF 1.4 will probably be adopted at the September 2001 meeting. CWM should consider using MOF 1.4 for its metamodel, which will bring particular benefits in the area of DataTypes. Note that there is a new OMG directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

The metamodel for DTD should be reviewed

  • Key: CWM12-66
  • Legacy Issue Number: 4461
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    This is an issue deferred from the CWM FTF. The metamodel for DTD should be reviewed, and revised if necessary, to make sure that it fully represents DTD information and that it is consistent with the new metamodel for XML Schema.

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

We only need one COBOL Data Division metamodel.

  • Key: CWM12-51
  • Legacy Issue Number: 4744
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    CWM vol. 2 3.1 says "The concepts and ideas implicit in the definition of the COBOL language's DATA DIVISION were one of the earliest (if not the first) formalizations of the ubiquitous record model. A COBOL program contains much more than just record descriptions. However, because neither CWM nor UML attempt to describe programming languages directly, only the DATA DIVISION is described here. The model presented here is compliant to the COBOL 85 language standard [COBOL]."

    UML Profile for EAI 14.1 says "The goal of this COBOL model is to capture the information that would be found in the Data Division." .

    Both define COBOL Data Division metamodels with different levels of detail. We only need one COBOL Data Division metamodel.

  • Reported: CWM 1.1 — Tue, 11 Dec 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.1 Overview

  • Key: CWM12-33
  • Legacy Issue Number: 12308
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    The referenced [SQL], the basis of this clause, is given as SQL:1999, which is no longer valid because it has been superseded by SQL:2003
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.2.6 Index

  • Key: CWM12-30
  • Legacy Issue Number: 12312
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    This should make it clear that indexing is not part of SQL, and the use of SQLIndex in Figure 10.10 is entirely inappropriate.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

10.4.2 ColumnRefStructuredType

  • Key: CWM12-19
  • Legacy Issue Number: 12321
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    see comment on 10.3.20
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

13.1 Overview

  • Key: CWM12-18
  • Legacy Issue Number: 12323
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    "XML Schema is an ongoing activity in the W3C. As future standards are adopted by the W3C on XML Schema, this package will be revised and extended accordingly." This document is not referenced in either Clause 3 or the References Annex, and the claimed revision has clearly not occurred.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Annex C: Glossary

  • Key: CWM12-13
  • Legacy Issue Number: 12329
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This annex should not be described as Normative, since it does not provide any requirement on the application of this standard as well as being incomplete and missing or being in conflict with the terminology of other normative references, such as SQL. The reference to RM-ODP is inappropriate, not being one of the listed sources.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Predefined' values not defined in metamodel

  • Key: CWM12-55
  • Legacy Issue Number: 4513
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    The 'predefined' values for SoftwareDeployment::SoftwareSystem.type (and subtype) should be formally defined as Constants in the metamodel. Similarly for WarehouseOperation::ChangeRequest.status and WarehouseOperation::Measure.type (there are probably others).

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Component Re-use unclear

  • Key: CWM12-59
  • Legacy Issue Number: 4512
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    By using the inherited ElementOwnership association to link SOftwareSystem and Component, this would seem to prevent the same component being reused in many systems. Though an Import association is depicted in Figure 8-7-1, nothing is said in the text about its semantics in this context: typically this would be used just for definitions/types ("extending the namespace" according to the description in the Core model) and not something that would need to be physically deployed as part of the SoftwareSystem.

    Proposed resolution: Introduce a new many-to-many shared aggregation to link SoftwareSystem and Component.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Make it easier to interchange UML Models

  • Key: CWM12-62
  • Legacy Issue Number: 4470
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    CWM uses a subset of UML for practical reasons. It also delegates the modeling of Object Oriented resources to that subset. However the way this is currently done makes it unnecessarily hard to take a model exported from a UML tool and import it as the model of an OO resource in CWM.

    CWM should provide support e.g. via metamodel and/or documented best practice (e.g. use of XMI namespaces) for this.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Parameter

  • Key: CWM12-46
  • Legacy Issue Number: 5921
  • Status: open  
  • Source: HTL Villach ( Lassnig Gernot)
  • Summary:

    I think a parameter must have a multiplicity, because otherwise there can be never ever overgiven/returned an array to/from an behavioralfeature. I think this is not correct, i think maybe this is right for input parameters, but i think for output or return parameters there must be an multiplicity to model an behavioralfeauture correct.

  • Reported: CWM 1.1 — Tue, 29 Apr 2003 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.2.4 Structured Types and Object Extensions

  • Key: CWM12-32
  • Legacy Issue Number: 12310
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    "A structured type is defined in terms of columns" - the SQL standard defines a structured type in terms of attributes and it is totally confusing to define it in terms of columns. A column can exist only within tables and can have constraints, which are not allowed for attributes of a structured type.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.3.15 SQLDistinctType

  • Key: CWM12-29
  • Legacy Issue Number: 12315
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The attributes length, precision and scale should not be present, because they are exactly the same as those for the related sqlSimpleType. What should be included are the methods that can be defined for distinct types.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

supplierDependency reference is missing from ModelElement

  • Key: CWM12-77
  • Legacy Issue Number: 4398
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    The supplierDependency reference is missing from ModelElement, which existed in the CWM Adapted Specification.This change makes the model illogical and unbalanced. Dependency is always defined between two ModelElements (a client and a supplier). Its definition involves two associations and four association ends. Either the supplierDependency reference should be put back (which makes a more flexible model) or the client reference on Dependency should also be removed (which makes a more restrictive model, but at least it is logical and balanced). (This is a revised write-up for issue #3398.)

  • Reported: CWM 1.0 — Fri, 20 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Description, Document, ResponsibleParty should be made subtypes of Comment

  • Key: CWM12-68
  • Legacy Issue Number: 4460
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    This is an issue deferred from the CWM FTF. Description, Document and ResponsibleParty should be made subtypes of Comment, allowing use of the corresponding reference on ModelElement.

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 3 Normative References - ISO/IEC 9075:2003 Database language SQL

  • Key: CWM12-37
  • Legacy Issue Number: 12302
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    A normative reference for ISO/IEC 9075:2003 Database language SQL is required, because it is the basis of Clause 10 (any previous edition has been superseded)
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.1 Overview

  • Key: CWM12-35
  • Legacy Issue Number: 12309
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    The inclusion of 'indexing' as part of Relational implies that it is part of SQL, but this is not true.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

page 9-276/Section: 9.3.22 of ptc/2002-01-02 -- CWM issue

  • Key: CWM12-49
  • Legacy Issue Number: 5299
  • Status: open  
  • Source: International Business Machines ( Jean-Jacques Daudenarde)
  • Summary:

    Table: this currently reference a Table. However, most RDBMS support "instead of" triggers which can be applied to views. Table should be replaced by a reference to a NamedColumnSet

  • Reported: CWM 1.1 — Thu, 16 May 2002 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

10.3.20 SQLStructuredType

  • Key: CWM12-23
  • Legacy Issue Number: 12319
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    An essential feature of SQL structured types is that they have methods, whose properties should be recorded
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

package may fail to permit definition of transformations

  • Key: CWM12-74
  • Legacy Issue Number: 4401
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Usage experience with the CWM 1.0 Transformation package has
    uncovered several situations in which the package may fail to permit
    definition of transformations that fully capture the intent of implementors.
    Such problems have appeared in several unrelated modeling venues and have
    led some implementors to seek alternative means for describing
    transformations. The existing transformation package should be reviewed by
    the RTF and changed as needed to improve its ability to represent the
    breadth of transformation semantics found in practical usage scenarios. As
    part of this effort, the RTF should consider incorporating the existing
    TypeMapping package into an evolved Transformation package – TypeMappings
    are, after all, really just lightweight transformations.

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

XML Schema package issue

  • Key: CWM12-75
  • Legacy Issue Number: 4400
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    The planned XML Schema package proposed for inclusion in CWM 1.1
    should be cognizant of and wherever possible, equivalent to, the XML Schema
    model planned for the inclusion in the XMI specification. Within reason,
    corresponding XML Schema-specific class in the two specifications show share
    the same names, attributes, and relationships to other classes.

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

XML metamodel should be based on W3C XML Information Set

  • Key: CWM12-78
  • Legacy Issue Number: 4247
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    XML metamodel should be based on W3C XML Information Set. W3C has a standard called XML Information Set http://www.w3.org/TR/xml-infoset/ (at Candidate Recommendation status) "This specification defines an abstract data set called the XML Information Set (Infoset). Its purpose is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document"

    In effect it defines an information model for XML with the following Information Items (the equivalent of classes in CWM): Document, Element, Attribute, Processing Instruction, Unexpanded Entity Reference, Character, Comment, Document Type Declaration, Unparsed Entity,Notation, Namespace. It would seem that since this is what W3C says should be modeled for XML documents then this should be the basis of the CWM XML model (the content part as opposed to the Schema part), or at least CWM should specify how it maps to this Information Set.

  • Reported: CWM 1.0 — Tue, 3 Apr 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Add syntax type to the metamodel.

  • Key: CWM12-8
  • Legacy Issue Number: 12336
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The expressions metamodel should have the kind of syntax associated the expression (e.g., is the expression C, APL, ksh, or something else, which all have significantly different parsing and syntax.
    Proposed Solution:
    Add the syntax type to the metamodel.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Annex B: Compatibility with other Standards

  • Key: CWM12-15
  • Legacy Issue Number: 12328
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    This annex is inappropriate in this standard, but if it remains it must be non-normative because it does not provide any requirement on the application of this standard.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

value "name" attribute of ModelElement

  • Key: CWM12-6
  • Legacy Issue Number: 12333
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    There is no requirement that the value "name" attribute of ModelElement correspond to the identifier (i.e., the string) of the model element.
    Proposed Solution:
    Add requirement that the "name" actually corresponds to the identifier of the model element.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Add datatype generators

  • Key: CWM12-4
  • Legacy Issue Number: 12337
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The 11404 datatype generator features should be included via the expressions metamodel capability.
    Proposed Solution:
    Add datatype generators

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Practical changes to Contact metamodel

  • Key: CWM12-63
  • Legacy Issue Number: 4472
  • Status: open  
  • Source: agnos.ai UK Ltd ( Pete Rivett)
  • Summary:

    These are gained from having tried to use the model in real situations.

    a) Add new attribute Contact.applicability: String (0..1), to allow a fuller description of when that

    contact should be used (e.g. "After hours or weekend emergencies only: when completion of a

    time-critical run is threatened").

    b) the associations between COntact and its constituent parts (Telephhone etc) should be shown as aggregations (not compositions) for clarity. This will have no effect on generated code/DTDs.

    c) split the phoneNumber attribute into its constituent parts. This is because the actual number to ring is dependent on context), and there may be uses where automatic dialing is required (e.g. for fax/pager access to contacts). [It is assumed that the calling progam knows what country/area it is dialing from). The proposed replacement attributes (all optional and of type String) are: countryCode inCountryAreaPrefix (e.g. for UK it would be "0" - one dials +44 1202 449419 outside UK but 01202 449419 inside UK) areaCode corePhoneNumber.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

All OCL sections should be reviewed to ensure that they are complete

  • Key: CWM12-67
  • Legacy Issue Number: 4459
  • Status: open  
  • Source: International Business Machines ( Dan Chang)
  • Summary:

    This is an issue deferred from the CWM FTF. Per recommendation from the Architecture Board, all OCL sections should be reviewed to ensure that they are complete

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 4 Abbreviations and Conventions

  • Key: CWM12-40
  • Legacy Issue Number: 12303
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    DTD is Document Type Definition
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 4 Abbreviations and Conventions - SQL

  • Key: CWM12-36
  • Legacy Issue Number: 12306
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    SQL should not be considered as an abbreviation for Structured Query Language
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Foreword

  • Key: CWM12-44
  • Legacy Issue Number: 12298
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    "Apart from this Foreword, the text of this International Standard is identical with that for the OMG specification for CWM 1.1 (formal/03-03-02)."
    While true of the current document this cannot hold if changes are made to respond to NB comments.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

formal/03-03-02

  • Key: CWM12-43
  • Legacy Issue Number: 8707
  • Status: open  
  • Source: btinternet.com ( Bryan Wood)
  • Summary:

    The specification does not identify the exact versions of MOF, UML and XMI that it refers to. Even if more than one version is applicable this needs to be made clear.

  • Reported: CWM 1.1 — Thu, 28 Apr 2005 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

1.16.3 Extraction from any

  • Key: CPP13-1
  • Legacy Issue Number: 5854
  • Status: open  
  • Source: Connox ( Raf Schietekat)
  • Summary:

    The question is about 99-07-41.pdf, as far as I know the latest C++ mapping specification. "1.41.5 Any Class" prescribes "Boolean operator>>=(const Any&, const char*&);" for unbounded strings, and "1.16.3 Extraction from any" says that unbounded strings are extracted by value. This seems to be contradictory: I seem to remember that const char* cannot be delete'd, though I don't find it in ISO/IEC 14882:1998(E). But, regardless of anything imposed by C++, the current mapping precludes a safe technique like (safe as in exception-proof): >> String_var theString; if(!(theAny>>=theString.out()))

    { ... }

    << I therefore propose that the mapping be changed to "Boolean operator>>=(const Any&, char*&);". This seems to work all right on my implementation (RayORB), for gcc 3.2 (MS VC++ 6.0 doesn't seem to care one way or the other, but I suppose that is wrong, although I'm not entirely sure).

  • Reported: CPP 1.1 — Mon, 10 Feb 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

5.4 datatype attributes don't incorporate the features of 11404 datatype

  • Key: CWM12-10
  • Legacy Issue Number: 12335
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The datatype attributes don't incorporate the features of 11404 datatype (properties, characterizing operations, value spaces). There is no way to record this kind of standard datatyping information in CWM in a standard way.
    Proposed Solution:
    Add these features to the metamodel. Describe, in a standard way, how datatype characterizing operations would be recorded.

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Identify precise CWM definition to which interchange doc. conforms

  • Key: CWM12-72
  • Legacy Issue Number: 4403
  • Status: open  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Provide in the body of a CWM interchange document, a means for
    identifying the precise CWM definition to which the interchange document
    conforms. Something similar to the way the XML documents identify the URI
    of the XML definition they conform to would do nicely. Such a mechanism in
    effect creates a name space within which the contents of the CWM interchange
    document can be evaluated. Useful side effects of having such a namespace
    include: (1) the definition of CWM extension packages without the present
    need that they be accompanied by the CWM definition itself, (2) a framework
    in which Universally Unique Identifiers (UUIDs) can be defined for each CWM
    object. Several requests for CWM UUIDs have already been received
    informally.

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Location: 10.3.14 SQLDataType

  • Key: CWM12-28
  • Legacy Issue Number: 12314
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The attribute typeNumber is not an SQL concept, and since it is described as being assigned by the owning DBMS this makes it totally useless for any exchange between different DBMSs.
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

10.3.17 SQLIndexColumn

  • Key: CWM12-25
  • Legacy Issue Number: 12317
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem:
    see comment on 10.2.6
    Proposed Solution: None proposed by source

  • Reported: CWM 1.1 — Wed, 19 Mar 2008 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

IDL does not match

  • Key: COLL-15
  • Legacy Issue Number: 1322
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The idl spec for the CollectionFactories interface in Chapter 17 of Corba Common Object Services document and the spec for the same interface in The CORBAservices OMG IDLText File(last updated Feb, 1998) do not match. The doocument (17-73) describes a method

  • Reported: COLL 1.0b1 — Thu, 14 May 1998 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:55 GMT

Suggested changes to Collection spec.

  • Key: COLL-14
  • Legacy Issue Number: 63
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A number of interface changes suggested for the Collection specification.

  • Reported: COLL 1.0b1 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:15 GMT

Failure behavior for iterator operations

  • Key: COLL-13
  • Legacy Issue Number: 62
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What should be done for remove/replace/retrieve_element_set_to_next if the element cannot be deleted/replaced/retrieved?

  • Reported: COLL 1.0b1 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:15 GMT

Practical problem with DII using Request Pseudo Object

  • Key: CPP13-81
  • Legacy Issue Number: 141
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If I want to use the DII to send out multiple simultaneous requests, I don"t see a practical way to associate any client specific context that is C++ compliant to those requests.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:15 GMT

Interface OrderedCollection

  • Key: COLL-9
  • Legacy Issue Number: 770
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Calls for removing and retrieving the first and last element can throw an EmptyCollection exception. Why can"t the calls remove_elements_at_position and retrieve_element_at_position throw such an exception?

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Page 17-29: OrderedCollection.remove_element_at_position

  • Key: COLL-8
  • Legacy Issue Number: 769
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Positions are numbered. When I remove 1 element, what happens with the indices?Do the portions of the indices of the elements located after the removed element decrement one?

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Page 17-26: Collection.all_elements_do

  • Key: COLL-7
  • Legacy Issue Number: 768
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a invocation of do_on on a certain element returns false, does the iteration have to stop, leaving some of the objects undone?Or do I continue until the end and then return false?

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

page 17-23: Collection.remove_all

  • Key: COLL-6
  • Legacy Issue Number: 767
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The side effects states that iterators that point to removed elements go in-between, and others keep theit state. If all elements are removed I doubt that some iterators can keep their state. I would set all iterators the invalid state...comments?

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Collection.add_element

  • Key: COLL-5
  • Legacy Issue Number: 766
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Page 17-23:"If the collection supports unique elements or keys...". If I already have a different element with the same key, do I return and add false?

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Map/SortedMap

  • Key: COLL-4
  • Legacy Issue Number: 765
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a confusing/conflicting situation in 2 parts of the document. Page 17-12 Map/SortedMap states that you can insert an object with 2 different keys (nicknames). The first note on page 17-122 states that if both key and element equality are defined, element and equality must imply key equality.

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

CORBAservices (editorial page 17-74, 17-75)

  • Key: COLL-3
  • Legacy Issue Number: 764
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Same case for RACollectionFactories) on page 17-74, 17-75 as in issue 763

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

CORBAservices (editorial page 17-71 to 17-73)

  • Key: COLL-2
  • Legacy Issue Number: 763
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The operation "create (ParameterList parameters) raises (ParameterInvalid)" is not mentioned in the CollectionFactories interface, while it is fully explained on page 17-73

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Error in CosCollection information

  • Key: COLL-1
  • Legacy Issue Number: 755
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Page 17-89, description of the retrieve_element_set_to_next operation in the Iterator interface: The signature of this operation is missing the second parameter "more".

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Section: 3.5.19 - 3.5.20

  • Key: CORP-1
  • Legacy Issue Number: 8754
  • Status: open  
  • Source: General Motors ( Davis Ford)
  • Summary:

    in UML Profile for CORBA, where it describes the UML notation examples for mapping of CORBA sequences/arrays...there is some significant confusion on my part with respect to the notation examples given. See Figure 3-27 for an example. In this figure the class stereotyped as <<CORBAAnonymousSequence>> has a composition association with a class stereotyped as <<CORBAPrimitive>>. The latter class has the following text appearing in the name compartment: "CORBA::short". I am bewildered at how the type can be represented in the name compartment of the class. I am trying to use a tool to auto-generate IDL from UML, and have no way to represent this, and I am unsure if this is even valid as per the UML specification. Is this legal, or is necessary to have an attribute that is of type CORBA::short in the attribute compartment?

  • Reported: CORP 1.0b1 — Mon, 2 May 2005 04:00 GMT
  • Updated: Mon, 9 Mar 2015 00:40 GMT

Section 9 of UML Profile for CORBA and CCM

  • Key: CCCMP-3
  • Legacy Issue Number: 12359
  • Status: open  
  • Source: Objective Interface Systems ( Victor Giddings)
  • Summary:

    Chapter 9 should be clearly marked as non-normative. Noted during smsc review. Thus, formal document number not available

  • Reported: CCCMP 1.0 — Mon, 31 Mar 2008 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.2.1 - 2

  • Key: CCCMP-2
  • Legacy Issue Number: 11159
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Yann Tanguy)
  • Summary:

    P. 51 . The CORBAUses stereotype has a property "multiple" of type PrimitiveKind P. 53 . The CORBAUses stereotype has a property "isMultiple" of type boolean. This looks like a naming and type inconsistency between diagram and tabular representation of the stereotype. If this is the case and isMultiple is really typed boolean, PrimitiveKind becomes useless (I did not find any other use of PrimitiveKind in the profile). If not (I mean PrimitiveKind is the wanted type), it may be better to type the "multiple" property with the "CORBAPrimitive" stereotype instead of creating and using an enumeration like PrimitiveKind.

  • Reported: CCCMP 1.0 — Wed, 18 Jul 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section: 8.1.2

  • Key: CCCMP-1
  • Legacy Issue Number: 11158
  • Status: open  
  • Source: Commissariat a l Energie Atomique-CEA ( Yann Tanguy)
  • Summary:

    Litteral of the enumeration PrimitiveKind are prefixed with "CORBA" or "Corba", instead of "CORBA" (upper case) for all litterals

  • Reported: CCCMP 1.0 — Wed, 18 Jul 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inconsistent capitalization of <>

  • Key: CCCMP-4
  • Legacy Issue Number: 18380
  • Status: open  
  • Source: Airbus Group ( Oliver Kellogg)
  • Summary:

    For the stereotype designating IDL "typedef", the UML Profile for CORBA
    v1.0 (02-04-01) uses the capitalization "CORBATypedef".
    The UML Profile for CORBA and CCM v1.0 (08-04-07) sometimes uses the
    same capitalization but also uses the capitalization "CORBATypeDef"
    (notice the capital "D".)
    For compatibility with the UML Profile for CORBA, I suggest replacing
    all occurrences of "CORBATypeDef" by "CORBATypedef".

  • Reported: CCCMP 1.0 — Mon, 21 Jan 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:59 GMT

definition of the stereotype CORBAPrimaryKey

  • Key: CCMP-1
  • Legacy Issue Number: 7628
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    The definition of the stereotype CORBAPrimaryKey makes too strong restrictions. The CORBA Component Model defines a primary key as an ordinary valuetype, which is derived from Components::PrimaryKeyBase. Using the stereotype PrimaryKey would prevent me from using this valuetype in other parts of my application as a plain valuetype (e.g operation parameter). Suggestion: Remove stereotyp CORBAPrimaryKey. Use stereotype CORBAValueDef instead and refomulate the constraints accordingly. (e.g. inheritance)

  • Reported: CCMP 1.0b1 — Fri, 13 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Facet and Receptacles (ports)

  • Key: CCMP-3
  • Legacy Issue Number: 7632
  • Status: open  
  • Source: ANSYS, Inc. ( Marc Born)
  • Summary:

    Facet and Receptacles (ports) are specified as an UML association, but their names are specified as role names of the association end of the referenced interface. It means, the component refers directly to the external interface – it’s confusing and less intuitiv. Suggestion: Facet and Receptacle names are the names of the associations, describing ports.

  • Reported: CCMP 1.0b1 — Mon, 16 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The (IDL) definition of the example is not correct

  • Key: CCMP-2
  • Legacy Issue Number: 7629
  • Status: open  
  • Source: Fraunhofer FOKUS ( Tom Ritter)
  • Summary:

    The (IDL) definition of the example is not correct. The valuetyp for the key is not allowed to be abstract and it must have at least one public member. Furthermore, this key needs to be derived from Components::PrimaryKeyBase. The picture of the UML model should also be completely shown (i.e. including the member of the primary key). Suggestion: Modify example (IDL and picture)

  • Reported: CCMP 1.0b1 — Fri, 13 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Event ports

  • Key: CCMP-4
  • Legacy Issue Number: 7633
  • Status: open  
  • Source: ANSYS, Inc. ( Marc Born)
  • Summary:

    Event ports are specified as an UML association, but their names are specified as role names of the association end of the referenced event. It means, the component refers directly to the external event – it’s confusing. Suggestion: Event port (such as Facet and Receptacle) names are the names of the associations.

  • Reported: CCMP 1.0b1 — Mon, 16 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association needed

  • Key: CCMP-6
  • Legacy Issue Number: 7635
  • Status: open  
  • Source: ANSYS, Inc. ( Marc Born)
  • Summary:

    Association with <<CORBAManages>> between HomeImplDef and ComponentImplDef is needed, otherwise you can’t navigate and define what HomeImplDef manages what ComponentImplDef.

  • Reported: CCMP 1.0b1 — Mon, 16 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure6: associations described Event ports have to be composite associatio

  • Key: CCMP-5
  • Legacy Issue Number: 7634
  • Status: open  
  • Source: ANSYS, Inc. ( Marc Born)
  • Summary:

    Figure6: associations described Event ports have to be composite associations.

  • Reported: CCMP 1.0b1 — Mon, 16 Aug 2004 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text and Java API differ on return value for seacrhChemicalElements method

  • Key: CSAR-1
  • Legacy Issue Number: 9838
  • Status: open  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Nature of Problem
    The section 8.4.4 ChemSearchEngine class includes the following method:

    searchChemicalElements():Collection

    This is also shown in the figure 8.32. However the figure has a dependency from the ChemSearchEngine class to the ResultSet class.

    The Java API, in lifesci/05-08-03, correctly shows the return value for the method as ResultSet.

    Proposed Solution:

    Change the figure and text in section 8.4.4 to agree with the Java API.

  • Reported: CSAR 1.0 — Mon, 26 Jun 2006 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Place maximums on wstrings for interoperability

  • Key: CURR11-21
  • Legacy Issue Number: 2781
  • Status: open  
  • Source: Anonymous
  • Summary:

    Should the interfaces that accept a wstring also somehow state the maximum length of that data string? This is necessary for the implementation to know the maximum number of wide characters that may need to be stored in a persistence repository. e.g. Currency.mnemonic is three? This also includes the following : Currency.name, Currency.fractionName, Currency.symbol, Currency.fractionSymbol, Currency.description, Currency.ISOVersion, a locale wstring, ExchangeRate.rateType, CurrencyBook.publishedVersion, MoneyFormatter.formattingString, MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol, MoneyFormatter.radixSymbol.

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add interfaces to DTime properly handle the DAmountOfTime difference inter

  • Key: CURR11-15
  • Legacy Issue Number: 2427
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: DAmountOfTime difference(in DTime anotherTime) does not support an
    implementation properly as the difference between two points in time is a
    DamountOfTime instance and DamountOfTime represents an “absolute (positive)
    amount of time”. Thus, either DamountOfTime must be able to represent an
    amount of time that is less than zero, or the following interfaces must be
    available.
    · Propose the following additional interfaces:
    boolean equal(in CBO::Dtime otherObject);
    void setEqual(in CBO::Dtime otherObject);
    boolean less(in CBO::Dtime otherObject);
    boolean lessEqual(in CBO::Dtime otherObject);
    boolean greater(in CBO::Dtime otherObject);
    boolean greaterEqual(in CBO::Dtime otherObject);

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve text in specification of of DAmountOfTime

  • Key: CURR11-17
  • Legacy Issue Number: 2430
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The toWeeks(), toDays(), and toHours()operations return the amount to the
    nearest whole unit. The toMinutes() and toSeconds() operations are not
    specified in the same way, and the commentary for these two operations uses
    such poor English that the intention is not clear.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support millisecond precision in DAmountOfTime

  • Key: CURR11-16
  • Legacy Issue Number: 2429
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Cannot represent milliseconds or any sub-second
    precision

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changing RoundType.DONT_ROUND

  • Key: CURR11-20
  • Legacy Issue Number: 2780
  • Status: open  
  • Source: Anonymous
  • Summary:

    DO_NOT_ROUND would be more explicit and prohibit confusion as the contraction might cause some confusion.

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add ability to clone Money

  • Key: CURR11-19
  • Legacy Issue Number: 2778
  • Status: open  
  • Source: Anonymous
  • Summary:

    Need the ability to clone Money from existing Money

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove Depedence in FBCCurrency of CBO::DDecimal

  • Key: CURR11-23
  • Legacy Issue Number: 2783
  • Status: open  
  • Source: Anonymous
  • Summary:

    Replace DDecimal with CORBA fixed type.

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove Dependence in FBCCurrency of CBO::DTime

  • Key: CURR11-22
  • Legacy Issue Number: 2782
  • Status: open  
  • Source: Anonymous
  • Summary:

    Replace DTime in FBCCurrency with struct

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove dependence on a specific version of the ISO 4217 standard

  • Key: CURR11-18
  • Legacy Issue Number: 2776
  • Status: open  
  • Source: Anonymous
  • Summary:

    All throughout the spec it references ISO 4217:1995, it would be better to reference the latest ISO 4217 standard (i.e. no hard-coded date/year).

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

: Change name of interface to CBO::Decima

  • Key: CURR11-8
  • Legacy Issue Number: 2420
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Change name of interface to CBO::Decimal.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Corrections to the equals/setEquals interfaces of DTime

  • Key: CURR11-7
  • Legacy Issue Number: 2419
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The equals/setEquals() interfaces accept a base class CORBA Object as the
    parameter type. The instance passed must be narrow’ed to a DDecimal, DTime,
    etc. for the interface to carry on with its task. This is not possible as
    the Ddecimal, Dtime, etc. are not IDL Interfaces, they are IDL Value types.
    Since an IDL Value type does not derive from Object, the narrow’ing is not
    possible. This also affects other portions of the CBO … DCurrency, DMoney,
    etc. Also, equals(in Object anObject) causes a problem in a Java
    implementation as every Java class inherits from java.lang.Object. The
    boolean equals(Object obj) method supported by java.lang.Object cannot be
    overriden AND additional throw an FbcException. Thus, equals(), setEquals()
    should be changed wherever defined to be equal(), setEqual().

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve DTime exception handling

  • Key: CURR11-6
  • Legacy Issue Number: 2418
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CBOException type currently prohibits the called software from
    informing the calling software as to the source of the problem that raises
    a CBOException. e.g. If CBO::DTime::setSeconds(63) is called, a
    CBOException will be raised, but the caller cannot query the CBOException
    caught for its exception type or description as CBOException does not
    currently support these constructs. In the case where many arguments are
    presented to a method, the caller will not know which specific argument is
    causing the problem.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add interface to DTime

  • Key: CURR11-14
  • Legacy Issue Number: 2426
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Currency submission indicates that a specific Currency instance that
    does not have an expiration date will be noted with an expiration date of
    99/99/9999. This attribute is handled via a CBO::Dtime instance, but a
    CBO::Dtime instance cannot be created or mutated to represent 99/99/9999.
    e.g. The CBO::Dtime::setMonth(mon) expects 1 <= 12, etc. Would probably be
    easiest to have two operations on CBO::Dtime to handle this. These could
    be:
    void setUnspecified() – might be handled in an implementation as
    99/99/9999.
    boolean isUnspecified() – insulates the consumer from knowing how
    the notion of “unspecified” is implemented.

  • Reported: CURR 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification required on setYear of the DTime interface

  • Key: CURR11-13
  • Legacy Issue Number: 2425
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The setYear(in long year) interface is described such that year is
    expressed in four digit form. Does this then mean that year must be >= 1000
    or that year indicates an absolute year after christ? e.g. 99 means 99 and
    not 1999?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

support to set precision to something other than milliseconds

  • Key: CURR11-12
  • Legacy Issue Number: 2424
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Cannot set precision to something other than milliseconds, as DAmountOfTime
    cannot represent sub-second resolution. Cannot set the millisecond portion
    of the point in time as the Factory does not take the number of
    milliseconds as an argument, nor does the init() method.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

describe how the individual components should be accessed

  • Key: CURR11-5
  • Legacy Issue Number: 2380
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Should the subsystem/singleton components (i.e. StateIdManager,
    CurrencyBook, ExchangeRateManager, MoneyFormatter, MoneyCalculator) all be
    published separately to the CORBAservices Naming Service?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Description of Exception handling semantics

  • Key: CURR11-4
  • Legacy Issue Number: 2365
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Text needs to be added to describe what causes an exception to be raised
    for a given interface, when the semantics/preconditions for the interface
    have been violated (vs. exceptions specific to a vendor
    ’s implementation).
    e.g. Money.[gs]etValue(), MoneyFormatter.[gs]etFormattingString(), etc. It
    appears that most every interface raises (FbcException), but quite often
    the text which describes which exceptions can be raised, in terms of
    ExceptionType and under what conditions the exception is raised/thrown, has
    not been detailed. A detailed pass through the entire FbcCurrency spec
    should be conducted with attention paid to each interface and its exception
    generating details.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add text for DTime and DDecimal from CBO submission into Currency spec.

  • Key: CURR11-3
  • Legacy Issue Number: 2273
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Now that the CBO submission no longer exists, we need to add the text for DTime and DDecimal
    from the CBO submission into the Currency Spec.

  • Reported: CURR 1.0 — Fri, 18 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

: Change name of interface to CBO::Time

  • Key: CURR11-11
  • Legacy Issue Number: 2423
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Change name of interface to CBO::Time.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add interfaces to DDecimal

  • Key: CURR11-10
  • Legacy Issue Number: 2422
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Make the following interface changes:
    boolean equal(in DDecimal otherObject);
    void setEqual(in DDecimal otherObject);

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify the equality method of DDecimal

  • Key: CURR11-9
  • Legacy Issue Number: 2421
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Clarify comparisons of two CBO::Ddecimal values on
    equality (i.e. 2.0 equal to 2.000)
    – regardless of scale factor.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The idl for CBO::DTime needs the method: long getYear()

  • Key: CURR11-2
  • Legacy Issue Number: 2272
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The idl for CBO::DTime needs the method: long getYear()

  • Reported: CURR 1.0 — Fri, 18 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clairfy comparisons of two CBO::Ddecimal values on equality

  • Key: CURR11-1
  • Legacy Issue Number: 2266
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clairfy comparisons of two CBO::Ddecimal values on equality (i.e. 2.0 equal to 2.000)
    regardless of scale factor

  • Reported: CURR 1.0 — Thu, 17 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 4.1.9 SOAP Binding


GCPR issue: Asynchronous COAS

  • Key: COAS-3
  • Legacy Issue Number: 4020
  • Status: open  
  • Source: Anonymous
  • Summary:

    The QueryAccess interface has a matching interface called AsynchAccess which mirrors many operations in QueryAccess except the data is returned asynchronously. FCPR is looking at the ConstraintLanguage interface for doing population studies. The time needed to find and return the data from these types of queries could be significant. Yet these calls are synchronous. It may be useful to mirror this interface with one that has corresponding asynchronous operations. Additionally, the interfaces could be expanded to allow for clients to check on the status of their request.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Project issue: Delivering Observation Data

  • Key: COAS-2
  • Legacy Issue Number: 4018
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is one enhancement that will be treated in a separate issue paper: that of using another mechanism for the delivery of observation data such as XML or an IDL instead of the current nested ObservationData structure. For now we will simply mention that this is an area that needs to be enhanced. Massive amounts of data being moved across in the QueryAccess services need metadata or more descriptive access for clients to decode the data. We have suggested using XML in the any portion of the observation data structure. A DTD could be used for clients to decode the data in then XML stream. This removes the burden from the client of having to understand the internal data structures of the data being passed back. COTS products could be used to unwind the data and display the required portions. Versioning would also be easier to handle using XML since different versions of the DTD could be used to decode different XML format versions.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

new conformance classes and the Naming Service

  • Key: COAS-1
  • Legacy Issue Number: 3119
  • Status: open  
  • Source: Philips Electronics ( Charles Carman)
  • Summary:

    In editing the COAS specification to include the resolved solutions for the various issues I have come across the following problem with regard to the Naming Service:

    The revised COAS now has three independent conformance categories:
    1) interface conformance, i.e. the set of interfaces implemented by the server,
    2) data structure conformance, i.e. whether ObservationDataStruct is used, or some other solution, e.g. OBV
    3) qualified code conformance, i.e. whether the COAS rules for creating qualified codes from HL7 were used, etc.

    The current text for relating COAS and the Naming Service has the COAS conformance class (note the singular noun) placed in the "kind" member of the CosNaming::NameComponent struct, which is defined as a "string".
    Several solutions are possible:

    • define delimiters to be placed between the conformance categories in the "kind" string,
    • define a hierarchy of COAS names, with a different category placed in the "kind" string at each level of the hierarchy,
    • define a set of combination conformance class names that combine a common conformance class from each category, representing the set with a single name,
    • ...

    My preference is ??,

    • while the third would be take the least effort right now, it provides the least extensibility and interoperability,
    • the second would only require small additions to the section in the appendix that describes how COAS and Naming work together, but it places some fairly strong constraints on Naming hierarchies, possibly requiring a complex hierarchy and naming schemes
      for servers that support multiple interface and qualified code conformance classes (which is likely).
    • the first may break other clients that use the naming service, or it may be the best solution of the three.
    • ...
  • Reported: COAS 1.0b1 — Wed, 15 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR issue: Updating IDL for Examples

  • Key: COAS-6
  • Legacy Issue Number: 4023
  • Status: open  
  • Source: Anonymous
  • Summary:

    As mentioned in the previous paragraph, the IDL does not reflect the examples correctly in all cases, such as the Numeric data type. The entire IDL needs to be vetted to insure that the examples are accurately captured in the IDL.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Issue: Using Relational Operators

  • Key: COAS-5
  • Legacy Issue Number: 4022
  • Status: open  
  • Source: Anonymous
  • Summary:

    The ability to specify qualifiers will be an important facet of the GCPR COAS Implementation. Thus the get_observations_by_qualifier call will be used to specify filters for the data being requested. Relational operators will be a key element of the inbound qualifiers on this call - for example to specify that the results include values greater than a specified value.
    Though the COAS Specification shows that relational operators (greater-then, less-than, etc) can be specified for a value field, such as Numeric, in an optional component, the IDL does actually not contain any such optional field. Thus there is no current way to specify these relationships. Additionally, we suggest that the CodedElement class (subclass to ObservationValue) contain an optional field for relational operators. It is possible that a qualifier may include a coded element that needs such a relational operator.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR Issue: Event Interface Enhancements

  • Key: COAS-4
  • Legacy Issue Number: 4021
  • Status: open  
  • Source: Anonymous
  • Summary:

    The EventSupplier interface in COAS has one simple call for a client to receive events: subscribe. This operation allows a client to specify a sequence of subscriptions which are structures that include data on who and what the client is interested in. According to the specification, calling this operation will replace any current subscriptions made by a previous invocation. Thus this operation is not additive. We recommend that an additional operation be added which would allow subscriptions to additive - not replacing the current subscriptions but adding new ones. Conversely the ability to remove specific subscriptions would be required as well. GCPR will want to keep a cache of patient data up to date. The event interfaces may be useful for this purpose. As new patients are added to cache, servers could be notified of the new subscriptions. Without additive subscriptions, the client would have to resend the same subscription information on current patients already in cache each time a new subscription was needed.

  • Reported: COAS 1.0 — Mon, 6 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

COBOL Language Mapping Section: 1.2.1.2

  • Key: COBOL-2
  • Legacy Issue Number: 5857
  • Status: open  
  • Source: Anonymous
  • Summary:

    "4. If the identifier is greater than 30 characters, then truncate right to 30 characters."

    After this step there might be a hyphen at the end of the identifier. This should be truncated, too.

  • Reported: COBOL 1.0 — Wed, 12 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

anomaly in that unsigned integers are mapped to signed integers

  • Key: COBOL-1
  • Legacy Issue Number: 5640
  • Status: open  
  • Source: Anonymous
  • Summary:

    While skimming the CORBA->COBOL mapping of IDL constructs, I noticed an
    anomaly in that unsigned integers are mapped to signed integers:

    > IDL Name
    > COBOL Representation Integer Range COBOL Typedef
    >
    > unsigned short
    > PIC S9(05) BINARY 0 to 2^16 CORBA-unsigned-short
    > unsigned long
    > PIC S9(10) BINARY 0 to 2^32 CORBA-unsigned-long
    > unsigned long long
    > PIC S9(18) BINARY 18 numerics CORBA-unsigned-longlong
    > enum
    > PIC S9(10) BINARY CORBA-enum
    >
    > 1.4.1 Basic Integer Types
    >
    > The mapping of long long,
    > and unsigned long long
    > was made to PIC S9(18)
    > and PIC 9(18).

    Presumably the statement of section 1.4.1 is the correct one?

  • Reported: COBOL 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping of short and long

  • Key: COBOL-3
  • Legacy Issue Number: 19255
  • Status: open  
  • Source: Anonymous
  • Summary:

    The integer ranges given are wrong, correct would be -2^15 to 2^15 -1 and -2^31 to 2^31 -1.
    The COBOL Representation for short should be PIC S9(4) BINARY (which is 2 bytes) and for long PIC S9(10) BINARY (which is 4 bytes).

  • Reported: COBOL 1.0 — Fri, 21 Feb 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

different tessellation structures for different kind of entities

  • Key: CAD11-7
  • Legacy Issue Number: 5850
  • Status: open  
  • Source: Anonymous
  • Summary:

    There are some different tessellation structures for different kind of entities (geometric and topologic) and some are for both (e.g. EdgeTessellationStruct). Three of the four structs have a obj_ref member with type Object.

    Issues: 1. The type Object for obj_ref is too generic. 2. Some of the tessellation structs are for the use with one single interface (ConnectedFaceTessellationStruct -> Body) while some others are used in more than one interface (EdgeTessellationStruct -> Edge, Curve). 3. In some cases the obj_ref member of a single tessellation struct references a geometric entity (Curve, Surface), in others a topologic entity (Edge, Face, Body)

    Proposed Solution: For each interface which provides tessellation (has a tessellate() method) there should be one corresponding tessellation struct with a obj_ref member of the type of the interface which generated the struct.

    Edge -> EdgeTessellationStruct Face -> FaceTessellationStruct Curve -> CurveTessellationStruct Surface -> SurfaceTessellationStruct Body -> ConnectedFaceTessellationStruct

    It would be much clearer that way and the redundancies pretty few.

  • Reported: CAD 1.1 — Wed, 29 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadFoundation::EntityPropsStruct

  • Key: CAD11-6
  • Legacy Issue Number: 5847
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    In CadFoundation::EntityPropsStruct one variable is named ref_position in the pdf and ref_positions in the idl files. Should be ref_position

  • Reported: CAD 1.0 — Fri, 24 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadBrep::OrientedEdge interface issue

  • Key: CAD11-13
  • Legacy Issue Number: 5878
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    The CadBrep::OrientedEdge interface has two very similar methods to get the Face/OrientedFace which uses the OrientedEdge. That's pretty redundant. Besides: Both methods deliver useful information only when the OrientedEdge belongs to one and only one Face. Otherwise an exception is generated. I don't really see the usefulness of those two method, especially since for many cases there are two Faces for the Edge and one can always traverse there via the EdgeLoop.

  • Reported: CAD 1.1 — Mon, 3 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadBrep module issue

  • Key: CAD11-12
  • Legacy Issue Number: 5877
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    In the CadBrep module there are almost always two ways to traverse the topology: from the top level entities like Body to the underlying entites like Shell, Face, Edge, ... and the other way. For example I can get from Face to the OrientedFace which aggregates the Face or I can ask the OrientedShell in which Body it is contained. This does not make much sense to me. I always thought the topology is more or less hierarchical with Body is composed of OrientedShells which has reference to Shell and so on.
    Unless I am missing something important, it is just some not so small overhead to have all those relations at hand and being uptodate with them. I would place such things in a client for I see it as application specific, if it is neccessary or not.

  • Reported: CAD 1.1 — Mon, 3 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Documentation for CadMain::Model::unique_entities()

  • Key: CAD11-17
  • Legacy Issue Number: 5912
  • Status: open  
  • Source: CAxOPEN ( Andreas Korn)
  • Summary:

    2. The Documentation for CadMain::Model::unique_entities() and CadMain::Model::top_level_entities() says the only valid types asked for are geometric entity types but there is only mention and used CadFoundation::Entity (in the doc and in the return types). If this should really be only geometric entities, the return types could be CadBrep::BrepEntity and the documentation should be much clearer on what is allowd and what a invalid type.

  • Reported: CAD 1.1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadMain::Model interface issue

  • Key: CAD11-16
  • Legacy Issue Number: 5911
  • Status: open  
  • Source: CAxOPEN ( Andreas Korn)
  • Summary:

    CADServices 1.1
    1. In The CadMain::Model interface there is no clear way to get the DesignFeatures of a Model. The only possible way would be via top_level_entities() or unique_entities(), but these calls are for geometric entities (so it is written in the documentation).
    Proposed Solution: add a call "CadFeature::DesignFeatureSeq design_features()" to CadMain::Model. The DesignFeatures should be more clearly seperated from the BrepEntities as they are to different sights on the same data and should not be mixed per chance.

  • Reported: CAD 1.1 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Data in CadGeometry::EdgeTessellationStuct

  • Key: CAD11-15
  • Legacy Issue Number: 5882
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    I have a problem understanding how to interpret the
    > vertex_number's for
    > the points in CadGeometry::EdgeTessellationStuct. I don't see
    > the need
    > for a indexing here. It is just sequencial. Are there people,
    > who want
    > to do this another way?

  • Reported: CAD 1.1 — Fri, 14 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CADServices 1.1 issue

  • Key: CAD11-14
  • Legacy Issue Number: 5881
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    In the PDF document (03-02-02) for the CadServices the return value for CadFoundation::Entity::reference_position is CadUtility::PointStruct, but in the idl files it is CadUtility::PointStructSeq.
    I couldn't verify it against the newest documents (maybe newer than mine), because they were unreachable.
    Besides, the description of this method is not very helpful (at least to me). I have no clue how to interpret it.

  • Reported: CAD 1.1 — Thu, 13 Mar 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

exception CadConnection::BadParameter does not match the method anymore

  • Key: CAD11-9
  • Legacy Issue Number: 5855
  • Status: open