C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
COMMONS13-14 Commons silently changes the semantics of dct:description Commons 1.2b1 open
C2MS12-10 In message tables, make use of an enum type to designate a discreet list C2MS 1.0 open
C2MS12-22 Replace simple service REQ/RESP C2MS 1.0 open
C2MS12-41 Lack of Required Fields in Sub-elements C2MS 1.0 open
C2MS12-34 Inconsistent Fields MVAL Response and AMVAL Response C2MS 1.0 open
C2MS12-33 Re-evaluate Optional Boolean Fields C2MS 1.0 open
C2MS12-42 Required or Optional for MNEMONIC Status on Data Messages C2MS 1.0 open
C2MS12-5 Acknowledge Final Status inconsistency C2MS 1.0b1 open
C2MS12-28 Rework "Introduction to Specification" into a Section Describing Expected Use C2MS 1.0 open
C2MS12-20 Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message C2MS 1.0 open
C2MS12-96 namespace support should be reflected in at least the telemetry and command related C2MS messages C2MS 1.1b1 open
C2MS12-23 Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages C2MS 1.0 open
C2MS12-36 mnemonic.n.sample.m.quality seems to be wrong type C2MS 1.0 open
C2MS12-79 Create a C2MS SM&C MAL Message C2MS 1.1b1 open
C2MS12-74 Add SM&C MAL Message C2MS 1.1b1 open
C2MS12-16 Define a Way to Create Argument-based Commands for the Command Request Message C2MS 1.0 open
CPP1117-41 Missing base_type IDL traits for base struct and bitset CPP11 1.7 open
C2MS12-91 Standardize Table Cell Borders C2MS 1.1b1 open
C2MS12-93 Remove 'Not used' Designators in "Properties of Miscellaneous" Tables C2MS 1.1b1 open
C2MS12-89 Miscellaneous Minor Document Formatting/Text Issues C2MS 1.1b1 open
C2MS12-87 Standardize Sections and Section Names for Message Subjects C2MS 1.1b1 open
C2MS12-84 Fix Use of 'Severe' in Diagrams (Should be 'Critical') C2MS 1.1b1 open
COMMONS13-13 Annotation Vocabulary missing discussion of labeling policy Commons 1.2b1 open
COMMONS13-12 Annotation Vocabulary has incomplete definitions from SKOS Commons 1.2b1 open
COMMONS13-11 The documents ontology is missing the notion of a document part Commons 1.2b1 open
COMMONS13-10 Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts Commons 1.2b1 open
CPP1117-40 Add support for @cpp_mapping CPP11 1.7 open
CORBA35-75 lwCCM issues - home finders and finder operations CORBA 3.0.3 open
CORBA35-91 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 open
CORBA35-85 lwCCM issues - abstract storage type CORBA 3.0.3 open
CORBA35-84 lwCCM issues - abstract storage home CORBA 3.0.3 open
CORBA35-80 lwCCM issues - get_all_facet, ... CORBA 3.0.3 open
CORBA35-25 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 open
CORBA35-23 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 open
CORBA35-89 lwCCM issues - security CORBA 3.0.3 open
CORBA35-90 lwCCM issues - transaction CORBA 3.0.3 open
CORBA35-86 lwCCM issues - section 4.1.2 CORBA 3.0.3 open
CORBA35-88 lwCCM issues - persistence CORBA 3.0.3 open
CORBA35-87 lwCCM issues - entity components CORBA 3.0.3 open
CORBA35-81 lwCCM issues - segmentation CORBA 3.0.3 open
CORBA35-82 lwCCM issues - locator CORBA 3.0.3 open
CORBA35-83 lwCCM issues - CIDL CORBA 3.0.3 open
CORBA35-77 lwCCM issues - configurators CORBA 3.0.3 open
CORBA35-78 lwCCM issues - Section 4.1 CORBA 3.0.3 open
CORBA35-79 lwCCM issues - primary key CORBA 3.0.3 open
CORBA35-74 lwCCM issues - invalid rows CORBA 3.0.3 open
CORBA35-76 lwCCM issues - proxy homes CORBA 3.0.3 open
CORBA35-73 lwCCM issues - Entity2Context CORBA 3.0.3 open
CORBA35-415 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 open
CORBA35-418 Can value type inherit from Value Box type CORBA 2.2 open
C2MS12-26 Deprecate fields duplicated between C2MS Messages and the Message Envelope C2MS 1.0 open
C2MS12-32 Revisit Tracking Fields C2MS 1.0 open
C2MS12-37 AMVAL Value Response Doesn't Mirror MVAL Value Response Message C2MS 1.0 open
C2MS12-46 What to do when Priority isn't Specified C2MS 1.0 open
C2MS12-15 Using REQ Messages for 'Publish' C2MS 1.0 open
C2MS12-18 Command Echo Not Provided Message C2MS 1.0 open
C2MS12-67 Revisit Completion Status in Command Response Message C2MS 1.0 open
C2MS12-43 Rework Log Message C2MS 1.0 open
C2MS12-31 Consider Deprecating and Later Removing Resource Message C2MS 1.0 open
COMMONS13-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 open
COMMONS12-2 The quantities and units ontology does not allow representation of unitless quantity values Commons 1.1b1 open
COMMONS13-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 open
COMMONS12-1 Need an ontology representing multidimensional arrays COMMONS 1.0b2 open
C2MS12-66 Consider a Command Completed Publish Message C2MS 1.0 open
C2MS12-21 Reconsider Oneshot in MVAL Request/Response C2MS 1.0 open
C2MS12-47 Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message C2MS 1.0 open
C2MS12-44 Consolidate Navigation Data Messages C2MS 1.0 open
C2MS12-19 Replace Unsolicited Echo with a Separate Message C2MS 1.0 open
C2MS12-11 Add a Message Exchange Pattern (MEP) for a component to forward requests/responses C2MS 1.0 open
C2MS12-2 Data Dictionary Messages C2MS 1.0b1 open
C2MS12-7 Add documentation within the model C2MS 1.0a1 open
C2MS12-4 XML PSM recommended C2MS 1.0b1 open
C2MS12-14 C2MS Database Query (DBQUERY) messages C2MS 1.0 open
COMMONS12-13 Clean up a few issues with the Locations ontology Commons 1.1 open
COMMONS12-7 The definition of aspect needs refinement Commons 1.1 open
OARIS3-17 C2INav Model refers to an old OARIS Common Types package C2INAV 1.0 open
CORBA35-191 BNF changes CORBA 3.0.2 open
CORBA35-195 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 open
CORBA35-607 Add optional/map mapping (and other IDL4 special types) CORBA 3.4 open
C2MS12-51 Refactor "Introduction to Specification" section in front matter of Document C2MS 1.0 open
C2MS12-48 Improve Example Text for Publish Rate C2MS 1.0 open
C2MS12-12 C2MS: Optional Transfer Frame/Packet attributes should be described in schema C2MS 1.0 open
C2MS12-17 Split ME1 in Simple Service Req/Resp C2MS 1.0 open
C2MS12-8 Larger Data Types C2MS 1.0 open
C2MS12-38 Normalize Headers and Text in the new DB Query Messages C2MS 1.0 open
C2MS12-45 Undo Addition of DB Query Messages in 1.1 C2MS 1.0 open
C2MS12-39 Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES C2MS 1.0 open
CPP1117-39 constexpr constructors missing CPP11 1.7 open
CPP1117-38 CORBA::CustomerMarshal, type CPP11 1.7 open
CPP1117-37 Typo CORBA::CustomerMarshal CPP11 1.7 open
C2MS12-49 Align TLM Terms C2MS 1.0 open
C2MS12-40 Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model C2MS 1.0 open
C2MS12-30 Remove the Req/Resp/Pub MEP C2MS 1.0 open
C2MS12-29 Use Semantic Versioning for Version Number of Messages C2MS 1.0 open
C2MS12-27 Remove Superfluous Fields from Header and Envelope C2MS 1.0 open
C2MS12-25 At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency C2MS 1.0 open
C2MS12-24 At Next Major Revision: Order MEs and Fields Consistently C2MS 1.0 open
C2MS12-6 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 open
C2MS12-3 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 open
C2MS12-9 Harmonize Replay TLM and Archive Mnemonic Message Sets C2MS 1.0 open
C2MS12-1 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 open
C2MS12-50 use of brackets not consistent for Subject Elements C2MS 1.0 open
C2MS12-35 Non-sensical Description for PROD-MSGS-TO-SEND C2MS 1.0 open
C2MS12-13 Consider a mechanism to request archived Commands and Events C2MS 1.0 open
CSRM12-3 Informational Update to CSRM Profile Specification CSRM 1.1b1 open
CSRM12-2 Informational Update to CSRM Profile Specification CSRM 1.0 open
CORBA35-441 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 open
CORBA35-438 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 open
CORBA35-432 Add CORBATCKind to end of enum list CORBA 2.0 open
CORBA35-428 ODL is erroneous CORBA 2.0 open
CORBA35-426 page 2-30: There is a label "Examples", but no examples CORBA 2.0 open
CORBA35-417 Section 5.5 Interface repository (01) CORBA 2.2 open
CORBA35-411 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 open
CORBA35-416 Section 5.5 Interface repository (02) CORBA 2.2 open
CORBA35-409 Value type ansd Value Box"s single data member name CORBA 2.2 open
CORBA35-404 Section 5.6.2 Repository Id CORBA 2.2 open
CORBA35-405 Clarify the hash code algorithm CORBA 2.2 open
CORBA35-403 Repository Id (02) CORBA 2.2 open
CORBA35-402 Repository Id (03) CORBA 2.2 open
CORBA35-401 Section 5.6.3 Hashing Algorythm CORBA 2.2 open
CORBA35-400 Semantics of computing the hash code.. CORBA 2.2 open
CORBA35-397 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 open
CORBA35-399 Concrete value class CORBA 2.2 open
CORBA35-395 Java mapping example and C++ mapping example CORBA 2.2 open
CORBA35-393 Why is ValueBase a value and not a native type? CORBA 2.2 open
CORBA35-391 Editorial page 8-107 CORBA 2.2 open
CORBA35-386 Can public modifier be applied to value operations? CORBA 2.2 open
CORBA35-374 Can "public" mofifier be applied to value operations? CORBA 2.2 open
CORBA35-349 Minimum CORBA and POA CORBA 2.3 open
CORBA35-357 No typecodes for abstract interfaces CORBA 2.2 open
CORBA35-345 issue with TCPfirewallMechanism CORBA 2.2 open
CORBA35-344 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 open
CORBA35-338 How can we bound the range of invoke ids in the IDL? CORBA 2.3 open
CORBA35-337 It should be possible to have negative invoke ids CORBA 2.3 open
CORBA35-335 Problem: Why is AssociationId a string? CORBA 2.3 open
CORBA35-336 Section number: 4.2.1 CORBA 2.3 open
CORBA35-334 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 open
CORBA35-332 Section 4.3.2.1 Title and text should be changed CORBA 2.3 open
CORBA35-333 There is a difference between the responder and initiator interfaces CORBA 2.3 open
CORBA35-331 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 open
CORBA35-329 Section number: 5.2 and other sub-sections CORBA 2.3 open
CORBA35-328 Section number: 5.4.1 CORBA 2.3 open
CORBA35-327 Shouldn't it be typedef string CORBA::ScopedName? CORBA 2.3 open
CORBA35-326 Section number: Fig. 27 CORBA 2.3 open
CORBA35-322 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 open
CORBA35-321 Section number: 5 CORBA 2.3 open
CORBA35-316 Firewall POA Policy does not control access CORBA 2.3 open
CORBA35-320 Section number: 2.3 CORBA 2.3 open
CORBA35-314 new_target CORBA 2.3 open
CORBA35-313 new_callback CORBA 2.3 open
CORBA35-311 Proxified object references CORBA 2.3.1 open
CORBA35-312 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 open
CORBA35-310 Reusing PASSTHRU CORBA 2.3.1 open
CORBA35-309 Clarification is needed on the passing of credentials CORBA 2.3.1 open
CORBA35-308 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 open
CORBA35-306 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 open
CORBA35-305 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 open
CORBA35-304 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 open
CORBA35-303 Specification Translation from ASN to IDL issue CORBA 2.3.1 open
CORBA35-302 TcPdu User and Provider interfaces CORBA 2.3.1 open
CORBA35-301 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 open
CORBA35-274 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 open
CORBA35-242 Which model should ConcurrencyControl support? CORBA 2.0 open
CORBA35-239 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 open
CORBA35-241 Who is responsible for releasing locks in transaction? CORBA 2.0 open
CORBA35-218 interface QueryEvaluator { CORBA 2.0 open
CORBA35-211 CosConsurrencyControl service bug or not? CORBA 2.3.1 open
CORBA35-215 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 open
CORBA35-210 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 open
CORBA35-174 Issue: CSIv2 Identity Assertion CORBA 2.3.1 open
CORBA35-130 Section: 4.2 CORBA 3.0.3 open
CORBA35-129 Section: 4.2 (02) CORBA 3.0.3 open
CORBA35-9 Incorrect mappings for systems exceptions (part A) CORBA 2.0 open
CORBA35-8 Capter 13C: Editorial CORBA 2.0 open
CORBA35-7 Section 13A.2.3: editorial CORBA 2.0 open
CORBA35-6 Section 13A.5.2: Editorial CORBA 2.0 open
CORBA35-4 Duplicate union labels CORBA 2.0 open
CORBA35-5 Changes to ForeignComplexType CORBA 2.0 open
CORBA35-213 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 open
CORBA35-606 The CCM document component-formal-21-02-04 shall be removed from CORBA 3.4 to become a standalone CCM specification. CORBA 3.4 open
CORBA35-440 Ordering of user exception and return values CORBA 1.2 open
CORBA35-439 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 open
CORBA35-435 Standard ProgramId CORBA 2.0 open
CORBA35-437 VB cannot handle array out-parameters CORBA 2.0 open
CORBA35-434 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 open
CORBA35-433 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 open
CORBA35-431 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 open
CORBA35-340 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 open
CORBA35-420 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 open
CORBA35-214 Correction of CORBA specification (page 18-51) CORBA 2.3.1 open
CORBA35-339 Section number: 3.5.1.1, item 3 CORBA 2.3 open
CORBA35-208 COM/CORBA keywords CORBA 2.2 open
CORBA35-207 Fixed Types in COM CORBA 2.4.2 open
CORBA35-3 COM Sequence changes CORBA 2.0 open
CORBA35-1 Levels of Indirection for passing COM types seem to be missing CORBA 2.0 open
CORBA35-436 What should Automation View accept in bounded sequences? CORBA 2.0 open
CORBA35-430 uuid for DForeignException has an extra 0 CORBA 2.0 open
CORBA35-427 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 open
CORBA35-429 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 open
CORBA35-424 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 open
CORBA35-425 page 4-109, section 4.1.5.3: editorial CORBA 2.0 open
CORBA35-423 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 open
CORBA35-422 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 open
CORBA35-421 INSTANCE_Clone does not need an in-parameter CORBA 2.0 open
CORBA35-342 Section number: 3.3.4 and elsewhere CORBA 2.3 open
CORBA35-419 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 open
CORBA35-330 Shouldn't this section really be called TC Service Interface? CORBA 2.3 open
CORBA35-324 Should SIOP version number start with 1.2? CORBA 2.3 open
CORBA35-325 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 open
CORBA35-300 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 open
CORBA35-323 Section number: 6.2.2 CORBA 2.3 open
CORBA35-298 Missing definition on security tags in the SIOP CORBA 2.3.1 open
CORBA35-299 There is currently no valuetype support in SIOP. CORBA 2.3.1 open
CORBA35-297 Use of PolicyType id CORBA 2.3.1 open
CORBA35-264 Lifecycle Key type definition CORBA 1.2 open
CORBA35-263 Stream contexts and internalization CORBA 1.2 open
CORBA35-262 Start and end of context tags CORBA 1.2 open
CORBA35-261 Definition of stream portability CORBA 1.2 open
CORBA35-260 Multiple objects on a stream CORBA 1.2 open
CORBA35-259 Timeout while locking CORBA 1.2 open
CORBA35-258 Communication failure issue CORBA 1.2 open
CORBA35-257 Getting the thread ID in a non-transactional lock request CORBA 1.2 open
CORBA35-256 Freeing of locks at the end of a transaction CORBA 1.2 open
CORBA35-255 Coordinator remembering LockCoordinator CORBA 1.2 open
CORBA35-254 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 open
CORBA35-253 Using local thread identification for concurrency CORBA 1.2 open
CORBA35-252 Common format on stream CORBA 1.2 open
CORBA35-251 CosGraphs::deep CORBA 1.2 open
CORBA35-250 performing a compound copy of relationship CORBA 1.2 open
CORBA35-246 CosCompoundExternalization Service CORBA 1.2 open
CORBA35-245 CosCompoundExternalization Service (2) CORBA 1.2 open
CORBA35-244 CosCompoundExternalization Service (3) CORBA 1.2 open
CORBA35-240 Internalizing roles-IDL optimization CORBA 2.1 open
CORBA35-243 Purpose of related LockSet CORBA 2.0 open
CORBA35-238 QueryCollection::Collection -- membership scoping CORBA 1.2 open
CORBA35-237 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 open
CORBA35-235 QueryCollection::Collection -- finding index CORBA 1.2 open
CORBA35-236 Query Collection::Collection -- Sharing State CORBA 1.2 open
CORBA35-234 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 open
CORBA35-233 QueryCollection::Collection -- iterator updating CORBA 1.2 open
CORBA35-231 QueryCollection::Collection -- reset() exceptions CORBA 1.2 open
CORBA35-232 QueryCollection::Collection -- destroy methods CORBA 1.2 open
CORBA35-230 QueryCollection::Collection -- next_n() CORBA 1.2 open
CORBA35-229 QueryCollection::Collection -- keyed collections CORBA 1.2 open
CORBA35-228 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 open
CORBA35-226 Updating information via query iterators CORBA 1.2 open
CORBA35-227 Use of MD5 on arguments CORBA 1.2 open
CORBA35-225 How do iterators handle changing of the data they are pointing at CORBA 1.2 open
CORBA35-224 Clarification request for section 11.1.5 CORBA 1.2 open
CORBA35-222 retrieve_element CORBA 1.2 open
CORBA35-223 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 open
CORBA35-221 Delegating iterator functionality to the RDBMS CORBA 1.2 open
CORBA35-220 Query language for operations CORBA 1.2 open
CORBA35-219 OQS relation to POS CORBA 1.2 open
CORBA35-217 Malformed PropertyName CORBA 1.2 open
CORBA35-216 WWW Form output CORBA 1.2 open
CORBA35-209 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 open
CPP1117-36 Change union API misuage exception CPP11 1.7 open
CORBA35-446 Add CDR marshaling support for new IDL4 types (e.g. maps, bitset, bitmask) CORBA 3.3 open
CORBA35-175 Polymorphic Valuetypes and the DII CORBA 2.3.1 open
CORBA35-176 DynValue & custom valuetypes CORBA 2.3.1 open
CORBA35-177 Custom Value Marshaling Issue CORBA 2.3.1 open
CORBA35-178 Potential deadlock with POA::deactivate_object() CORBA 2.3 open
CORBA35-296 BiDir GIOP Policy Clarification CORBA 2.4.1 open
CORBA35-315 Firewall Traversal algorithm CORBA 2.3 open
CORBA35-317 Outgoing local port in Bi-directional IIOP CORBA 2.3 open
CORBA35-318 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 open
CORBA35-319 Bi-Directional GIOP: which connections may be used? CORBA 2.3 open
CORBA35-350 ValueHelper Interface issue CORBA 2.2 open
CORBA35-352 Status of hashed repository IDs CORBA 2.2 open
CORBA35-356 TypeCode complexity for value types CORBA 2.2 open
CORBA35-379 Marshaling engine issue CORBA 2.2 open
CPP1117-35 No external annotation mapping CPP11 1.7 open
CPP1117-34 No mapping for min/max/range annotations CPP11 1.7 open
CPP1117-33 Clarify implicit default CPP11 1.7 open
CORBA35-347 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 open
CORBA35-348 The values of these tags need to be assigned CORBA 2.2 open
CORBA35-353 OBV init CORBA 2.2 open
CORBA35-354 CodeBase interface uses undefined type CORBA 2.2 open
CORBA35-355 Memory Management for Value Factories Unspecified CORBA 2.2 open
CORBA35-360 OBV TypeCode parameters wrong CORBA 2.2 open
CORBA35-361 C++ boxed value member clashes CORBA 2.2 open
CORBA35-362 Custom marshalling support for IDL fixed type CORBA 2.2 open
CORBA35-363 Default constructor for Java values CORBA 2.2 open
CORBA35-364 Boxed values need extension to write_Value call CORBA 2.2 open
CORBA35-365 TypeCodes for values CORBA 2.2 open
CORBA35-366 Forward declaration of value boxes CORBA 2.2 open
CORBA35-367 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 open
CORBA35-368 OBV spec inefficient for dending large number of small objects CORBA 2.2 open
CORBA35-369 OBV C++ problem with "supports" CORBA 2.2 open
CORBA35-370 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 open
CORBA35-371 TypeCodes defined in section 5.8.2 CORBA 2.2 open
CORBA35-372 CDR Streams CORBA 2.2 open
CORBA35-373 OBV "chunking" CORBA 2.2 open
CORBA35-376 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 open
CORBA35-375 Typo on page 8-107 of OBV specification CORBA 2.2 open
CORBA35-390 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 open
CORBA35-392 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 open
CORBA35-394 Section 7.3.10 Value Factories CORBA 2.2 open
CORBA35-396 Section 7 C++ Language mapping CORBA 2.2 open
CORBA35-398 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 open
CORBA35-406 Type code issue CORBA 2.2 open
CORBA35-407 Missing member_kind and member_tc CORBA 2.2 open
CORBA35-408 describe_value() operation issue CORBA 2.2 open
CORBA35-410 p.6.68 boxed values of complex types map to same type CORBA 2.2 open
CORBA35-413 Can Value type inherit from Value Box type? CORBA 2.2 open
CORBA35-192 rules for marshalling ValueBoxes CORBA 3.0.2 open
CORBA35-193 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 open
CORBA35-194 restriction of where a valuetype chunk can end CORBA 3.0.2 open
CPP1117-32 Default annotation CPP11 1.7 open
CORBA35-197 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 open
CORBA35-198 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 open
CORBA35-200 How does DynValue handle derived valuetypes? CORBA 3.0 open
CORBA35-202 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 open
CORBA35-203 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 open
CORBA35-204 valuetypes and local interfaces CORBA 3.0.2 open
CORBA35-206 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 open
CORBA35-212 CosExternaliazation Service (bug?) CORBA 2.4.2 open
CORBA35-266 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 open
CORBA35-267 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 open
CORBA35-268 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 open
CORBA35-269 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 open
CORBA35-270 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 open
CORBA35-271 Expected behavior of a non-conformant implementation CORBA 2.5 open
CORBA35-272 Targets of Export and Offer Policies incompletely specified CORBA 2.5 open
CORBA35-273 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 open
CORBA35-275 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 open
CORBA35-276 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 open
CORBA35-277 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 open
CORBA35-278 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 open
CORBA35-279 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 open
CORBA35-280 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 open
CORBA35-281 Implications about BiDirIds CORBA 2.5 open
CORBA35-282 paragraph limits use of BiDirOfferContext CORBA 2.5 open
CORBA35-283 Negotiate Session Message Issues CORBA 2.5 open
CORBA35-284 CodeSet issue (05) CORBA 2.5 open
CORBA35-285 CodeSet issue (04) CORBA 2.5 open
CORBA35-286 CodeSet issue (03) CORBA 2.5 open
CORBA35-287 CodeSet issue (02) CORBA 2.5 open
CORBA35-288 CodeSet issue (01) CORBA 2.5 open
CORBA35-289 GIOP version 2.0 issue CORBA 2.5 open
CORBA35-290 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 open
CORBA35-291 Bidirectional Policy insufficient for persistent objects CORBA 2.5 open
CORBA35-292 Server Authentication CORBA 2.5 open
CORBA35-293 Negotiation Session message is unwieldy CORBA 2.5 open
CORBA35-294 Negotiate Session Message Orientation CORBA 2.5 open
CORBA35-295 MAIN_THREAD_MODEL questions CORBA 2.4.1 open
CORBA35-442 The use of Full Services definitions in CORBA/e spec CORBAe 1.0b1 open
CPP1117-31 Apply IDL/C++ formatting to code in text CPP11 1.7 open
CPP1117-30 Remove semi colon after namespace closure CPP11 1.7 open
CPP1117-29 Destructors should be override CPP11 1.7 open
CSRM12-1 xmi profile CSRM 1.0b2 open
CORBA35-447 Add support for IDL4 int8/uint8/map/bitset/bitfield/bitmask CORBA 3.4 open
CORBA35-172 Implications of any/valuetype marshalling CORBA 2.4.1 open
CORBA35-69 69.3 AssemblyFactory Interface CORBA 3.0 open
CORBA35-65 [CCM] Interface Repository Metamodel CORBA 3.0 open
CORBA35-61 CCM IDL style inconsistency CORBA 3.0.2 open
CORBA35-60 multiple lifetime policies declaration issue CORBA 3.0.2 open
CORBA35-58 CCM spec: insufficient examples of component attributes CORBA 3.0.2 open
CORBA35-53 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 open
CORBA35-2 Section 13C.1.3 Editorial CORBA 2.0 open
CORBA35-54 issue on component supporting abstract interfaces CORBA 3.0.2 open
CORBA35-51 portability of CCM descriptors CORBA 3.0.2 open
CORBA35-173 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 open
CORBA35-48 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 open
CORBA35-45 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 open
CORBA35-41 "supports" keyword CORBA 3.0.3 open
CORBA35-40 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 open
CORBA35-29 CCMHome should have a get_container method CORBA 3.0.2 open
CORBA35-307 Traversal algorithm not sufficient CORBA 2.3.1 open
CORBA35-341 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 open
CORBA35-343 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 open
CORBA35-346 passthrough connection CORBA 2.2 open
CORBA35-351 "Tool" issue for IDL compilers too complex CORBA 2.2 open
CORBA35-359 P 5-44: use of base type CORBA 2.2 open
CORBA35-358 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 open
CORBA35-377 Narrowing from abstract interfaces CORBA 2.2 open
CORBA35-378 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 open
CORBA35-380 No portable way to obtain list of type safe repository IDs CORBA 2.2 open
CORBA35-381 Keyword identifiers (04) CORBA 2.2 open
CORBA35-382 Keyword Identifiers(03) CORBA 2.2 open
CORBA35-383 Keyword identifiers (02) CORBA 2.2 open
CORBA35-384 Keyword identifiers (01) CORBA 2.2 open
CORBA35-385 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 open
CORBA35-387 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 open
CORBA35-388 Editorial: p 5-50 CORBA 2.2 open
CORBA35-389 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 open
CORBA35-412 New lexical type - Keyword Identifie CORBA 2.2 open
CORBA35-414 "Safe" keyword identifier issue CORBA 2.2 open
CORBA35-38 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 open
CORBA35-39 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 open
CORBA35-110 NVList Section: 7.5 CORBA 3.0.3 open
CORBA35-113 Page: 21-5 CORBA 3.0.3 open
CORBA35-114 Section: Appendix A CORBA 3.0.3 open
CORBA35-115 Section: 21.3.14.11 CORBA 3.0.3 open
CORBA35-116 Section: 4.5.2 CORBA 3.0.3 open
CORBA35-119 Section: 11.3.9.16 CORBA 3.0.3 open
CORBA35-121 Page: 21-43 CORBA 3.0.3 open
CORBA35-122 Section: 22.11.1 CORBA 3.0.3 open
CORBA35-123 Section: 22.16/ CORBA 3.0.3 open
CORBA35-124 Section: 11.3.9 CORBA 3.0.3 open
CORBA35-125 Section: 21.4.3.1 CORBA 3.0.3 open
CORBA35-126 Section: 21.9.1 CORBA 3.0.3 open
CORBA35-127 Section: 21.7 CORBA 3.0.3 open
CORBA35-128 update the spec to not used anonymous types CORBA 3.0.3 open
CORBA35-131 Section: 13.6.2 CORBA 3.0.3 open
CORBA35-132 Section: 7.4 CORBA 3.0.3 open
CORBA35-141 struct PolicyValue CORBA 3.0.3 open
CORBA35-145 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 open
CORBA35-146 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 open
CORBA35-147 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 open
CORBA35-148 Section: 15.4.2/16.4.1 CORBA 3.0.3 open
CORBA35-150 Section: 21.3.13 CORBA 3.0.3 open
CORBA35-152 16.10 lists register_initial_reference CORBA 3.1 open
CORBA35-153 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 open
CORBA35-154 add CORBA::ORB::arg_list CORBA 3.0.3 open
CORBA35-155 Section 13.7 ServiceContext CORBA 3.0.3 open
CORBA35-156 Section: 21.7.3 CORBA 3.0.3 open
CORBA35-157 Section: 4.8.1 CORBA 3.0.3 open
CORBA35-158 move struct to IOP module CORBA 3.0.3 open
CORBA35-159 Add create_policy with just the type as argument CORBA 3.1 open
CORBA35-160 context should be local interface CORBA 3.1 open
CORBA35-162 interface ORB should be local CORBA 3.0.3 open
CORBA35-163 Make anonymous types illegal CORBA 3.0.3 open
CORBA35-180 Appendix A CORBA 3.0.3 open
CORBA35-181 Section: 4.3.13 CORBA 3.0.3 open
CORBA35-183 The POA state inactive is not used consistent. CORBA 3.0.3 open
CORBA35-184 argument of the set_servant call has a small typo CORBA 3.0.3 open
CORBA35-185 change in the POAManager CORBA 3.0.3 open
CORBA35-186 Add a typedef for the POAManager id CORBA 3.0.3 open
CORBA35-187 methods on the POA CORBA 3.0.3 open
CORBA35-205 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 open
CORBA35-443 Add CompressorId for zstd CORBA 3.4 open
CORBA35-444 Extend InvalidName exception CORBA 3.4 open
CORBA35-445 Replace Cookie with a string and use IDL map CORBA 3.4 open
CORBA35-448 ConfigValues to a std map CORBA 3.4 open
CORBA35-28 CCMHome should have a get_components method CORBA 3.0.2 open
CORBA35-26 HomeConfigurator should not extend CCMHome CORBA 3.0.2 open
CORBA35-24 Generic port connections CORBA 3.0.2 open
CPP1117-28 Add && setter CPP11 1.6b1 open
CPP1117-27 std::optional should be passed as const& CPP11 1.6b1 open
CPP1117-26 Formatting c++/idl in text CPP11 1.6b1 open
CPP1117-24 Fix bitset mapping CPP11 1.6b1 open
C2INAV13-3 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 open
C2INAV13-2 Enumeration value ESTIMATED used twice in the same package C2INAV 1.2b1 open
C2INAV13-1 C2INav Model refers to an old OARIS Common Types package C2INAV 1.2 open
CPP13-82 Improve wording CPP 1.3 open
CPP1116-38 Improve wording CPP11 1.6b1 open
ABPSC-33 URLs, URIs and namespaces for CMMN 1.1 XSDs are not aligned CMMN 1.1 open
LCC13-6 LCC ontologies and reference data should be refactored to use the Commons library COMMONS 1.0 open
CORBA35-247 $issue.summary CORBA 1.2 open
CORBA35-248 $issue.summary CORBA 1.2 open
CORBA35-249 $issue.summary CORBA 1.2 open
CORBA35-199 messaging router issue CORBA 3.0 open
CORBA35-201 module SendingContext CORBA 3.0.3 open
CORBA35-196 What is the RSC when using a PersistentPoller CORBA 3.0.1 open
CORBA35-188 Codec Interface Deficiencies CORBA 3.0.3 open
CORBA35-189 An extension of IOR to protect target objects Nature CORBA 3.0.3 open
CORBA35-190 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 open
CORBA35-182 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 open
CORBA35-179 Code Set Conversion on Operations CORBA 3.0.3 open
CORBA35-168 ForwardRequest is impossible to detect in clients CORBA 2.6.1 open
CORBA35-171 Avoiding RSC/TSC copy on server side CORBA 2.4.1 open
CORBA35-170 Proposal for extension to CosNaming CORBA 2.6 open
CORBA35-169 New issue: ForwardRequest() CORBA 2.6 open
CORBA35-164 rule (85) is misplaced CORBA 3.1 open
CORBA35-167 processing TaggedComponents within an IOR CORBA 3.0 open
CORBA35-165 Bad quotes and imported dot CORBA 3.1 open
CORBA35-166 missing document title CORBA 3.1 open
CORBA35-161 Redundant bullet CORBA 3.2 open
CORBA35-151 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 open
CORBA35-142 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 open
CORBA35-144 definition of Invalid Policies changed CORBA 3.1 open
CORBA35-143 mention of (deprecated) function get_implementation removed from text CORBA 3.1 open
CORBA35-149 Section: 13.6.10.1 CORBA 3.0.3 open
CORBA35-140 Two typo's in Annex A.4 CORBA 3.1 open
CORBA35-135 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 open
CORBA35-134 Minor code ambiguity CORBA 3.0.3 open
CORBA35-133 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 open
CORBA35-120 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 open
CORBA35-117 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 open
CORBA35-118 CORBA Exceptions CORBA 3.0.3 open
CORBA35-111 Page: 7-7 CORBA 3.0.3 open
CORBA35-112 Page: 9-1 CORBA 3.0.3 open
CORBA35-106 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 open
CORBA35-107 Section: Chapter 9, Chapter 5 CORBA 3.0.3 open
CORBA35-108 Section: Chapter 11 CORBA 3.0.3 open
CORBA35-109 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 open
CORBA35-99 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-100 69.3 Software Package Descriptor CORBA 3.0 open
CORBA35-101 Add the capability to define a component artifact property CORBA 3.0 open
CORBA35-103 69.8.2.9 The sequence Element CORBA 3.0 open
CORBA35-102 Test Property - add a test property definition to the properties DTD CORBA 3.0 open
CORBA35-104 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 open
CORBA35-105 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 open
CORBA35-92 Component Artifact Dependency CORBA 3.0 open
CORBA35-96 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 open
CORBA35-93 69.3.2.2 The author Element, page 69-474 CORBA 3.0 open
CORBA35-95 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 open
CORBA35-94 Descriptor CORBA 3.0 open
CORBA35-98 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 open
CORBA35-97 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 open
CORBA35-67 Checking XML DTD elements related to the trader service CORBA 3.0 open
CORBA35-68 Description for the impltype Element? CORBA 3.0 open
CORBA35-70 Uses Relationships CORBA 3.0 open
CORBA35-71 Device Artifact Dependency CORBA 3.0 open
CORBA35-72 Dependency on D+C FTF CORBA 3.0.3 open
CORBA35-64 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 open
CORBA35-62 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 open
CORBA35-63 Issue on the description of the consumesidentifier element CORBA 3.0 open
CORBA35-66 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 open
CORBA35-55 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 open
CORBA35-56 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 open
CORBA35-59 3.2.7 Compositions with Managed Storage CCM 3.0 open
CORBA35-57 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 open
CORBA35-52 'local executor mapping' CORBA 3.0.2 open
CORBA35-50 EnterpriseComponent should have a get_servant method CCM 3.0 open
CORBA35-44 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 open
CORBA35-43 HomeExecutorBase should have a set_context method CORBA 3.0.3 open
CORBA35-46 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-47 EnterpriseComponent should have a get_servant method CORBA 3.0.2 open
CORBA35-49 HomeExecutorBase should have a get_servant method CORBA 3.0.2 open
CORBA35-42 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 open
CORBA35-22 Interface Introspection CORBA 3.0.2 open
CORBA35-27 Session2Context interface CORBA 3.0.2 open
CORBA35-16 page 1-20 and page 1-21 - editorial CORBA 3.0.2 open
CORBA35-20 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 open
CORBA35-19 GIOP Conformance and Interceptors CORBA 3.0.2 open
CORBA35-18 context interface for home implementation CORBA 3.0.2 open
CORBA35-17 page 1-20 the description of the get_connection operation CORBA 3.0.2 open
CORBA35-21 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 open
CORBA35-10 valuetype fragmentation ambiguous CORBA 3.0.2 open
CORBA35-11 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 open
CORBA35-12 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 open
CORBA35-13 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 open
CORBA35-14 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 open
CORBA35-15 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 open
CPP11-267 Extend Union mapping CPP 1.3 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
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-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
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
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

Commons silently changes the semantics of dct:description

  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definition in Commons Annotation Vocabulary is not a mere copy of what's in DCT with the documented addition of making it a owl:AnnotationProperty, but adds the triple :
    <rdfs:subPropertyOf rdf:resource="&skos;note"/>
    That may or may not be a good idea but it adds a dependency and it's a significant change that should be flagged.
    In fact, given that SKOS itself makes use of DCT, that makes for a somewhat undesirable circular dependency though not formally stated.

    If an aim is some sort of unification then maybe skos:definition should be made a subProperty of dct:description.

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 20:28 GMT
  • Updated: Mon, 16 Dec 2024 01:50 GMT

In message tables, make use of an enum type to designate a discreet list

  • Key: C2MS12-10
  • Status: open  
  • Source: NASA ( Mr. John 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.

    Note too, that another issue identified that when the PRIORITY field is optional, it should have a default value. RTF in 12/24 determined it should be medium for the following tables:
    Directive Request Message
    Simple Service Request Message

  • Reported: C2MS 1.0 — Tue, 23 Jun 2020 16:48 GMT
  • Updated: Fri, 13 Dec 2024 22:14 GMT

Replace simple service REQ/RESP

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

    Replace simple service REQ/RESP and deprecate current simple service messages. Maybe call this "Generic Service".

    Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:

    • Destination Component is overloaded with two different meanings, depending on use.
    • Using Destination Component for SERVICE-NAME essentially requires the mission to establish a naming convention to separate SERVICE-NAME from DESTINATION-COMPONENT strings in order to tell the difference between them.
    • The Request can include a SERVICE-GROUP to further the SERVICE-NAME, sort of like namespacing, but this SERVICE-GROUP is not included in the Response message, which means that if needed in the Request, it is not possible to correctly correlate a Response to a Request.
    • The paradigm does not include a publish MEP natively, so at some point in the past, GMSEC/C2MS declared that a Request Message could be used to publish information, completely outside the Req/Resp MEP.
    • Current usage is to submit a request and then to have the response message indicate either the DESTINATION-COMPONENT of the original requestor or, alternately, the SERVICE-NAME associated with the original request. In keeping with other response messages, it should probably be just the DESTINATION-COMPONENT. It doesn't really need to have the option to use SERVICE-NAME, because the requestor is known. It also creates an odd and confusing alternate use, where in the current mode, the DESTINATION-COMPONENT is the requestor, but the SERVICE-NAME is related to the provider.

    Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.

    In this there are two factors that need consideration:

    • The Simple Service (and its replacement) should be intended for emerging services that go online in an existing domain, but that have not yet been able to establish their own set of dedicated C2MS-derived messages. It should not be the case that services live forever on this Simple Service (or replacement) mechanism.
    • The C2MS Messages themselves, perhaps in 2.0? should have a mechanism for extension without having to define new messages types. In other words, a service provider should be able to create a C2MS message that is simply expanded by what the service provider needs. If this can be accomplished, the Simple Service Paradigm is greatly aided, either by providing an easier path to offload the temporary use of Simple Service, or even by obviating the need for Simple Service.

    If we create a new replacement for Simple Service, need to account for the question raised in C2MS12-41.

  • Reported: C2MS 1.0 — Tue, 11 Jul 2023 14:51 GMT
  • Updated: Wed, 11 Dec 2024 15:23 GMT

Lack of Required Fields in Sub-elements

  • Key: C2MS12-41
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have a number of cases where there is a listing of something, like Files in Product Message. Although Num-of-files is required, nothing in the file itself is required.

    Should review these and decide if any of these are dependent, and therefore required for each File.

    Note that this is true in many other cases, need to find them all and come up with a plan for each.

    The complete list of messages/classes that exhibit this are:

    • C2MS Message Envelope
    • Telemetry Processed Frame Message
    • Mnemonic Value Response Message
    • Mnemonic Value Data Message
    • Archive Mnemonic Value Data Message
    • Device Message
    • Resource Message
    • Product Request Message
    • Product Response Message
    • Product Message
    • Simple Service Message
    • Archive Message Retrieval Request
  • Reported: C2MS 1.0 — Sun, 7 Apr 2024 22:57 GMT
  • Updated: Wed, 11 Dec 2024 15:20 GMT

Inconsistent Fields MVAL Response and AMVAL Response

  • Key: C2MS12-34
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The AMVAL Response and AMVAL Data messages mostly line up with MVAL Response and MVAL Data messages, but not quite. The AMVAL Response, for example, contains no samples, which are present for all of MVAL Response, MVAL Data and AMVAL Data. Also, AMVAL Response, contains a Product Subtype Category not found in any of the others. This needs analysis and convergence to align these messages better.

    Probably just need to do some analysis regarding comparative usages and fields to determine if it is correct as-is and if not, make them more consistent.

    There is a related issue regarding required versus optional fields that is being resolved in C2MS12-42.

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:51 GMT
  • Updated: Wed, 11 Dec 2024 14:37 GMT

Re-evaluate Optional Boolean Fields

  • Key: C2MS12-33
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some message fields of type Boolean are listed as optional. This has a pretty ambiguous meaning for a boolean, which if present, is always True or False.

    For one non-exhaustive example, some messages include a FINAL-MESSAGE boolean field that is optional. What does it mean when not present? It could be inferred that it is equivalent to False, but it could also be inferred that this is ignored when there is only one message, which would be the same as True.

    We need to go through all these usages individually and decide if these should be required, rather than optional.

  • Reported: C2MS 1.0 — Thu, 18 Jan 2024 21:04 GMT
  • Updated: Wed, 11 Dec 2024 14:27 GMT

Required or Optional for MNEMONIC Status on Data Messages

  • Key: C2MS12-42
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    When Mnemonic data is returned in the Mnemonic Value Response Message (representing the initial state of mnemonics being requested), the fields MNEMONIC.n.NAME and MNEMONIC.n.STATUS are required. This makes sense, because of the nature of the mnemonic values. If a name and status can't be returned, nothing else would seem relevant. However, when the data is conveyed in subsequent Mnemonic Value Data Messages, MNEMONIC.n.NAME and MNEMONIC.n.STATUS are Optional. This, in contrast, seems to be in error.

    Note that via copy-paste, the Archive Mnemonic Value Request/Data Messages are exactly the same. The MNEMONIC.n.NAME and MNEMONIC.n.STATUS are required in the Response Message and optional in the Data Message.

    Normally, it would not be appropriate to apply required to a field that was previously optional in order to avoid backward compatibility. But in this case it is clearly an oversight and the assumption is that anyone sending mnemonics in the Data Messages is already providing the name and status of each. Therefore, the fields in both the MVAL Data and AMVAL Data Messages should be modified to make these required, following the lead of the MVAL and AVMAL Response Messages.

  • Reported: C2MS 1.0 — Wed, 10 Apr 2024 16:25 GMT
  • Updated: Wed, 11 Dec 2024 13:57 GMT

Acknowledge Final Status inconsistency

  • Key: C2MS12-5
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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, 11 Dec 2024 00:01 GMT

Rework "Introduction to Specification" into a Section Describing Expected Use

  • Key: C2MS12-28
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    There is frequently confusion about how C2MS should be used. Normal use patterns are not described in the C2MS document, and this would be useful to add as a guide to users. This is especially true when C2MS is used in an enterprise environment, because common interpretation is critical.

    The section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2), and perhaps called "System Architecture", "Guidance", "User Guide", or something like that.

    If moved to a numbered section, it needs to be marked "Informative".

    The idea is to communicate context for how C2MS has been created and how it is expected to be used.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:36 GMT
  • Updated: Tue, 10 Dec 2024 23:57 GMT

Clarity and Usage Issues with Replay Telemetry Data Request (and Response) Message

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

    There are some clarity issues with Replay Telemetry Data Request (and Response) Message:

    • There is a STREAM-MODE the fields of the Replay Telemetry Data Request Message, but in this case, I believe what it is there for is to say what types of telemetry messages to replay. It's not part of the Subject, the way STREAM-MODE is for other messages. I'm not sure it makes sense in this message type and should be re-evaluated. At a minimum, beefing up the description of it would be helpful.
    • There is no mention that the replayed TLM messages should be marked with STREAM-MODE of RPY (Replay), but I assume that would be true, because otherwise, there would be no way to have RPY messages. This should be discussed in the context of this message.
    • There is a lot of messiness that can come from replaying the telemetry messages back in an operational environment. I could pick messages to replay from two years ago. What processes are listening for those messages? Do MVAL messages also get produced from the replayed TLM? Note that these cannot be marked RPY. Are Event Messages produced from the limit checks? Note that these cannot be marked RPY. Blech. Probably need a discussion of all this and a warning, again, not to have RPY messages flow in an operational environment.
    • There is discussion in "8.8 Replay Telemetry Data Messages" regarding using the Replay Request Message to get "real-time" or even "a future flow of data". In other words, there has been consideration at some point about using these messages as a way to request TLM messages wholly apart from subscribing to the normal published TLM messages. The only apparent benefits of this are the ability to constrain the DATA-RATE, to affect the PLAYBACK-RATIO, or to allow pausing or stepping through the TLM stream of the current (or future) real-time data. Any other elements of the data stream, could simply be filtered out as part of normal pub-sub of the standard messages. This makes for a bit of a Frankenstein meaning to the Replay messages. Not sure what do do about this. I think it actually simply makes more sense to say, if you want to do this kind of stuff, get the messages replayed from the archive, rather than to use this as a mechanism to affect real-time data. In any case, this could use some attention and explanation. Bottom line, I feel like this is one of those cases where the power of infinite flexibility has been employed so say, "Sure this is a message about replay, but you can get it to do basically whatever you want related to telemetry streams."
    • Section "8.8 Replay Telemetry Data Messages" refers to "Replay Telemetry Data Messages". However, this is a category rather than a specific message type, so some rewording is probably worthwhile to avoid confusion. The term "Replay Telemetry Data Messages" refers to replayed messages related to telemetry, which are specifically and exclusively: Telemetry CCSDS Packet Message, Telemetry CCSDS Frame Message, Telemetry CCSDS CADU Frame Message, Telemetry CCSDS Transfer Frame Message, Telemetry TDM Frame Message, and Telemetry Processed Frame Message.
  • Reported: C2MS 1.0 — Sun, 19 Mar 2023 21:16 GMT
  • Updated: Tue, 10 Dec 2024 16:00 GMT

namespace support should be reflected in at least the telemetry and command related C2MS messages

  • Key: C2MS12-96
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    Many t&c systems support some form of namespaces in their database definitions. For example a "parameter" might be associated with a certain namespace ("/myagency/mymission/mysystem/mysubsystem/batv1") or a command as well. XTCE supports a kind of namespace through the spacesystem tree. GSFC's ITOS supports namespaces in the database. (the other one, ASIST does not). And so forth.

  • Reported: C2MS 1.1b1 — Thu, 5 Dec 2024 16:50 GMT
  • Updated: Tue, 10 Dec 2024 02:20 GMT

Clarify how to specify array and aggregate parameters (MNEMONICs) in MVAL and related messages

  • Key: C2MS12-23
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The text for MVAL and related messages doesn't explain or give examples of how to specify for example an array or record – for example a BATV[1] or something more complicated like: SBUS.STATUS.PFRAME[27].STACK_DEPTH.

    Any text addressing this should also discuss the XTCE repeat concept which the author of this issue believes today is handled by NUM-OF-SAMPLES.

  • Reported: C2MS 1.0 — Wed, 12 Jul 2023 19:02 GMT
  • Updated: Tue, 10 Dec 2024 01:38 GMT

mnemonic.n.sample.m.quality seems to be wrong type

  • Key: C2MS12-36
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the messages where it exists, mnemonic.n.sample.m.quality is of type Boolean, with False meaning Good Quality and True meaning Questionable Quality. This just seems wrong. Probably should be a U16 with 1 = good and 0 = questionable.

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:18 GMT
  • Updated: Tue, 10 Dec 2024 01:20 GMT

Create a C2MS SM&C MAL Message

  • Key: C2MS12-79
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    The SM&C defines a set of mission operations services. At the bottom of this we believe there's an SM&C MAL message.

    We believe that if we define a C2MS MAL message and appropriate delivery (addressing) – that any C2MS service could flow over a C2MS implementation.

  • Reported: C2MS 1.1b1 — Mon, 16 Sep 2024 19:45 GMT
  • Updated: Tue, 10 Dec 2024 00:35 GMT

Add SM&C MAL Message

  • Key: C2MS12-74
  • Status: open  
  • Source: NASA ( Mr. James Kevin Rice)
  • Summary:

    SM&C (Spacecraft Monitor & Control) is a CCSDS working area that defines a set of ground system services, it is mainly Parameter (Mnemonic) value based (low level info is largely gone except they've added a packet construct recently). At the bottom of SM&C is the MAL message. The MAL message is technically abstract and one is to map it to your transport technology of choice – but perhaps there's no reason to literally implement a MAL message on the GMSEC bus. Determining details like "how will this really work" and so on would be part of this effort.
    Once completed, we then say to SM&C folks that we could support an SM&C service. There's an additional facet related about tying into XTCE. The MAL is explained further here – https://en.wikipedia.org/wiki/Message_Abstraction_Layer ... Note that in essence the idea which may need refinement is to make a mapping of the MAL into a concrete C2MS message. Implementation an addressing scheme in the pub/sub environ is another aspect. at least some implementations by esa use tcp/ip and it may be that some hard address approach would work well enough for pub/sub (broadcast not being needed)

  • Reported: C2MS 1.1b1 — Thu, 12 Sep 2024 17:42 GMT
  • Updated: Tue, 10 Dec 2024 00:34 GMT

Define a Way to Create Argument-based Commands for the Command Request Message

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

    The Command Request Message designates one CMD-FORMAT type as MNEMONIC, but it seems impossible to use this type to send a mnemonic-based command using the message as is, because the formatted command is to be held in CMD-DATA (binary). We have explored modifying to this message to include arguments to fill in a looked up command, but as we have tried to go in that direction, we get further from the expected use of Command Request Message.

    Therefore, this issue calls out the need to create a new message request/response to 'create' a formatted command from a command name and list of command arguments. This formatted command can then be placed in the CMD-DATA of the Command Request message. (This was the solution we converged upon in Chicago, 2024).

    This "Command Creation Request Message" should indicate the CMD-FORMAT desired, include a CMD-NAME field of type STRING to hold the human-readable name for command lookup. It is also to contain a list of 0-n Command Arguments to hold the human-supplied arguments, along with a way to specify the argument type.

    The "Command Creation Response Message should include the binary field CMD-DATA to line up with the same field name/type in Command Request Message.

    As part of this effort, the MNEMONIC CMD-FORMAT should be deprecated in Command Request Message, since it turned out not to be useable as is.

  • Reported: C2MS 1.0 — Tue, 7 Jun 2022 12:54 GMT
  • Updated: Mon, 9 Dec 2024 18:44 GMT

Missing base_type IDL traits for base struct and bitset

  • Key: CPP1117-41
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Both the IDL struct and bitset support inheritance in 6.31, at the moment the struct/bitset has a base, a IDL::traits<>::base_type should be make available for template meta programming

  • Reported: CPP11 1.7 — Fri, 22 Nov 2024 12:37 GMT
  • Updated: Mon, 2 Dec 2024 18:32 GMT

Standardize Table Cell Borders

  • Key: C2MS12-91
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the spec PDF, there is a lot of inconsistency about how XX Message Additional Information tables appear in the document.

    Some have (mostly) heavy cell borders - ex: Table 8-36. Directive Response Message Additional Information

    Some have normal cell borders - ex: Table 8-140. Command Request Message Additional Information

    Some have both in the same table - ex: Table 8-31. Directive Request Message Additional Information

    Having heavy cell borders leads to a propensity to add cells with inconsistent cell borders, unless care is taken by the editor. Because of this, I recommend using normal cell borders on all these tables. Normal borders are used in many of them and they look fine.

    Similarly all the XX Message Header Field Values tables should be updated in the same way.

    Additionally, there are other similar tables that follow this basic construct and should also be updated:

    • Table 6-9. Ordinal Date and Time Field Type Definition
    • Table 6-10. Response Status Substructure
    • Table 8-3. Mapping of Message Header Fields to the C2MS Subject Name
    • Table 8-9. Pass-Related Occurrence Types
    • Table 8-10. Telemetry Limit Violation Occurrence Types
    • Table 8-11. Command Verification Occurrence Types
    • Table 8-12. Miscellaneous Occurrence Types
    • Table 8-13. Log Message to Echo a Directive Request Message
    • Table 8-14. Product Message to Echo a Directive Request Message
    • Table 8-20. Examples of Start and Stop Times
    • Table 8-26. Meaning of Response Status and Return Value with Recommended Actions
    • Table 8-37. Group Hierarchical Associations
    • Table 8-160. Meaning of RESPONSE-STATUS and RETURN-VALUE with Recommended Actions
    • Table A-1. Software Class and Subclass Categories

    Finally, - Table 8-161. Example Scenarios Using the Set of Product Messages should keep the format of the cells generally, but needs to be cleaned up.

    As a note, there are some tables where the structure of the table is easier to distinguish with some heavy borders and these should remain. These are related to the XX Message Subject Naming Tables.

  • Reported: C2MS 1.1b1 — Fri, 22 Nov 2024 15:25 GMT
  • Updated: Fri, 22 Nov 2024 16:51 GMT

Remove 'Not used' Designators in "Properties of Miscellaneous" Tables

  • Key: C2MS12-93
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    A minority (nine out of 60+) of "Properties of Miscellaneous" tables have lines for Miscellaneous Elements only to state that they are "not used". This is superfluous and inconsistent with most other tables of this type. The "not used" aspect is knowable by the ME not being listed either in this table or its preceding "Subject Naming" table.

    This does not apply to the following tables, since they have some not used MEs in between others that are used, so they do need to be specified:

    • Table 8-86. Properties of the Miscellaneous Elements for the Telemetry TDM Frame Message
    • Table 8-91. Properties of the Miscellaneous Elements for the Telemetry Processed Frame Message

    Additionally, "Table 8-182. Properties of the Miscellaneous Elements for the Navigation Data Message" lists ME6 but without any other information, including "not used". Upon review, though, it is not used, so the line should simply be removed to avoid confusion.

  • Reported: C2MS 1.1b1 — Fri, 22 Nov 2024 16:22 GMT
  • Updated: Fri, 22 Nov 2024 16:49 GMT

Miscellaneous Minor Document Formatting/Text Issues

  • Key: C2MS12-89
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Item 1 - Table 8-62 Resource Message Additional Information is blank for NUM-OF-DISKS Type and Presence, should be U16 and R.

  • Reported: C2MS 1.1b1 — Wed, 20 Nov 2024 16:24 GMT
  • Updated: Wed, 20 Nov 2024 16:24 GMT

Standardize Sections and Section Names for Message Subjects

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

    Some messages have an inconsistent layout or section naming for their "Message Subjects" section. These need to be brought into a standard from. Messages that have this issue:

    • Section 8.3.1.1 Log Message Subject Names does not start at the right spot. It should begin before Table 8-5. Log Message Subject Naming. Additionally it should be "8.3.1.1 Log Message Subjects" (this is being fixed in the resolution of C2MS12-43)
    • Directive Response and Requests Messages to do not have 'Message' in the section heading. (Instead of "Directive Response Subjects" it should be "Directive Response Message Subjects" to be consistent with others.
  • Reported: C2MS 1.1b1 — Wed, 20 Nov 2024 00:28 GMT
  • Updated: Wed, 20 Nov 2024 00:55 GMT

Fix Use of 'Severe' in Diagrams (Should be 'Critical')

  • Key: C2MS12-84
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Late in C2MS 1.1, we aligned SDTF error levels across the specs. 1.1 initially used 'Severe' for the highest level of concern. Later, we changed this to 'Critical' as this was better alignment with XTCE. Although the document text was all changed, we had three model diagrams that referred to 'Severe' in notes: Log Message, Heartbeat Message and Device Message. The notes in these diagrams all need to be fixed to use 'Critical' instead of 'Severe'.

    Note that Log Message is already being fixed as part of the proposed resolution for C2MS12-43. Therefore, this issue only addresses Heartbeat and Device Messages.

  • Reported: C2MS 1.1b1 — Fri, 15 Nov 2024 18:19 GMT
  • Updated: Fri, 15 Nov 2024 18:19 GMT

Annotation Vocabulary missing discussion of labeling policy

  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Little best practice or guidance is given in either the spec or the ontology. By the fact that they're included it seems that skos:prefLabel and skos:altLabel are recommended. However they're not actually used in this or any of the other Commons ontologies.
    Commons itself provides an alternative with its Designations ontology. And OMG provides a strong capability in MVF.

    Users of Commons should be warned about the anti-pattern use of rdfs:label as the primary in conjunction with skos:altLabel which makes it impossible, with reasoning enabled, to return only the primary (since skos:altLabel; is a subProperty of rdfs:label)

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 20:08 GMT
  • Updated: Sun, 10 Nov 2024 20:42 GMT

Annotation Vocabulary has incomplete definitions from SKOS

  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The definitions taken from SKOS seem altered and incomplete.
    For example here is the official definition from SKOS RDF file for altLabel. The Commons version changes the label (using "tag" instead of "label") and omits the comments, one of which is the important (informal) disjointness constraint, and example.

    <rdf:Description rdf:about="#altLabel">
    <rdfs:label xml:lang="en">alternative label</rdfs:label>
    <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2004/02/skos/core"/>
    <skos:definition xml:lang="en">An alternative lexical label for a resource.</skos:definition>
    <skos:example xml:lang="en">Acronyms, abbreviations, spelling variants, and irregular plural/singular forms may be included among the alternative labels for a concept. Mis-spelled terms are normally included as hidden labels (see skos:hiddenLabel).</skos:example>
    <!-- S10 -->
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#AnnotationProperty"/>
    <!-- S11 -->
    <rdfs:subPropertyOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"/>
    <!-- S12 (not formally stated) -->
    <rdfs:comment xml:lang="en">The range of skos:altLabel is the class of RDF plain literals.</rdfs:comment>
    <!-- S13 (not formally stated) -->
    <rdfs:comment xml:lang="en">skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties.</rdfs:comment>
    <!-- For non-OWL aware applications -->
    <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
    </rdf:Description>

  • Reported: Commons 1.2b1 — Sun, 10 Nov 2024 19:56 GMT
  • Updated: Sun, 10 Nov 2024 20:09 GMT

The documents ontology is missing the notion of a document part

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    SBRM and other OMG processes need to be able to connect documents to the components therein. RTF members have requested that we add these terms to the documents ontology to facilitate mapping to other document ontologies as well as for extension purposes.

  • Reported: Commons 1.2b1 — Sat, 2 Nov 2024 19:26 GMT
  • Updated: Sat, 2 Nov 2024 19:26 GMT

Need to augment the locations ontology to cover sites and facilities, or create a new ontology for these concepts

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Several OMG members have requested a general ontology that includes sites and facilities, which are currently modeled in FIBO, primarily for lending and asset management purposes, but they are also needed for retail and manufacturing. The relationship between a site and a facility is many to many, and modeling them for manufacturing as well as retail, energy, military, and other domain areas can be tricky. Having the general pattern that can be extended by any domain area would be very useful for extension purposes.

  • Reported: Commons 1.2b1 — Sat, 2 Nov 2024 19:21 GMT
  • Updated: Sat, 2 Nov 2024 19:21 GMT

Add support for @cpp_mapping

  • Key: CPP1117-40
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Proposal is to add a @cpp_mapping as IDL4toC++ has, to enable users to select a mapping of IDL struct to a C++ struct (that mapping itself has to be added here also)

  • Reported: CPP11 1.7 — Wed, 23 Oct 2024 13:23 GMT
  • Updated: Mon, 28 Oct 2024 14:52 GMT

lwCCM issues - home finders and finder operations

  • Key: CORBA35-75
  • Legacy Issue Number: 7148
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.8 "exluding support for home finders" there
    are still references to finder operations and home finders in the following
    sections:
    1.7.1 (§2), 1.7.1.1, 1.7.3, 1.7.3.3, 1.7.4 (§1), 1.7.5 (heterodox), 3.3.6
    (point 5), 4.3.2.1 (get_CCM_home), 4.5, 4.5.1 (point 4, last §), 4.5.1.1
    (last point), 4.5.1.2
    The following sections have to be removed:
    1.7.3.2, 4.5.1.3, 4.5.2.3

    Proposed resolution:

    Add a row in the table 4.8 with :
    "Normative Exclusion" column : Exclude support for home finders and finder
    operations
    "Document Impact" column :
    Section 1.7.1, paragraph 2: remove reference to home finders and
    finder operations.
    Section 1.7.1.1: remove reference to home finders and finder
    operations.
    Section 1.7.3: remove reference to home finders and finder
    operations.
    Section 1.7.3.3: remove reference to home finders and finder
    operations.
    Section 1.7.4 paragraph 1: remove reference to home finders and
    finder operations.
    Section 1.7.5 (heterodox): remove reference to home finders and
    finder operations.
    Section 3.3.6, point 5: remove reference to home finders and finder
    operations.
    Section 4.3.2.1 (get_CCM_home): remove reference to home finders and
    finder operations.
    Section 4.5: remove reference to home finders and finder operations.
    Section 4.5.1, point 4 and last paragraph: remove reference to home
    finders and finder operations.
    Section 4.5.1.1, last point: remove reference to home finders and
    finder operations.
    Section 4.5.1.2: remove reference to home finders and finder
    operations.
    Section 1.7.3.2: remove
    Section 4.5.1.3: remove
    Section 4.5.2.3: remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:02 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA35-91
  • Legacy Issue Number: 6254
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    On page 11: The Normative Impact "Disable get_connections, get_all_receptacles, get_named_receptacles operations in the Receptacles interface" does not match the Document Impact: "Section 1.5.3: remove". Removal of section 1.5.3 removes the Receptacles interface in it entirety, including the description of the generic connect and disconnect operations, which are referred to by comment in the previous item. The Document Impact needs to be narrowed.

  • Reported: CORBA 3.0.2 — Tue, 16 Sep 2003 04:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - abstract storage type

  • Key: CORBA35-85
  • Legacy Issue Number: 7131
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 4;
    there are still references to abstract storage type in the following
    sections:
    3.2.2 (§2), 3.2.6, 3.2.9 (point 4)

    Proposed resolution:

    Row 4 in the table 4.1, add in the "Document Impact" column :
    Section 3.2.2, paragraph 2: remove references to abstract storage type
    Section 3.2.6: remove references to abstract storage type
    Section 3.2.9, point 4: remove references to abstract storage type

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - abstract storage home

  • Key: CORBA35-84
  • Legacy Issue Number: 7132
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 3;
    there are still references to abstract storage homes in the following
    sections:
    1.7.4, 3.2.5 (§4), 3.2.6

    Proposed resolution:

    Row 3 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.4: remove references to storage home
    Section 3.2.5, paragraph 4: remove references to abstract storage home
    Section 3.2.6: remove references to abstract storage home

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - get_all_facet, ...

  • Key: CORBA35-80
  • Legacy Issue Number: 7143
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.2 "exluding support introspection,
    navigation, ...", row 2; there are still references to these operations in
    the following sections:
    1.4.3, point 3 and 4, section 1.4.3.4, paragraph 1

    Proposed resolution:

    Row 2 in the table 4.2, in the "Document Impact", add:
    Section 1.4.3, point 3 and 4: remove references to these operations
    Section 1.4.3.4, paragraph 1: remove references to these operations

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA35-25
  • Legacy Issue Number: 7028
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Events
    interface.

    While the normative exclusion "disable get_all_consumers
    [...]" (8th row of section 10.3) retains the generic
    get_consumer, subscribe, unsubscribe, connect_consumer
    and disconnect_consumer operations, removing section 1.6.8
    would remove the entire Events interface.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the
    8th row, replace the text

    Section 1.6.8: remove

    with

    Section 1.6.8: remove these operations from the Events
    interface. Also remove the ConsumerDescription,
    EmitterDescription, SubscriberDescription and
    PublisherDescription types.

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA35-23
  • Legacy Issue Number: 7027
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing Victor's issue on section 1.5.3, I noticed
    that a similar problem exists with respect to the Navigation
    interface.

    While the normative exclusion "disable get_all_facets, get_
    named_facets, same_component operations in Navigation
    interface" retains the generic provide_facet operation,
    removing section 1.4.3.3 would remove the entire Navigation
    interface.

    On the other hand, the still-present section 1.4.3.4 references
    the disabled operations.

    Proposed resolution:

    In section 10.3, in the "Document Impact" column of the second
    row, replace the text

    1.4.3.3: remove

    with

    1.4.3.3: remove these operations from the Navigation
    interface. Also remove the PortDescription, FacetDescription
    and FacetDescriptions types.

    1.4.3.4: remove

  • Reported: CORBA 3.0.2 — Wed, 25 Feb 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - security

  • Key: CORBA35-89
  • Legacy Issue Number: 7127
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.5 "exluding support for security", there are
    still references to the security feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 , 4.5.1.5, 4.5.2.5

    Proposed resolution:

    Add a row in the table 4.5 with :
    "Normative Exclusion" column : Exclude support for security
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    security
    Section 4.2.1, paragraph 1: remove reference to security
    Section 4.2.12: remove reference to security
    Section 4.5.1.1: remove reference to security
    Section 4.5.1.5: remove reference to security
    Section 4.5.2.5: remove reference to security

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - transaction

  • Key: CORBA35-90
  • Legacy Issue Number: 7126
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.4 "exluding support for transaction", there
    are still references to the transaction feature in the following sections:
    4.2 (§1), 4.2.1, 4.2.12 (basic), 4.5.1.1 (point 2), 4.5.1.4, 4.5.2.4

    Proposed resolution:

    Add a row in the table 4.4 with :
    "Normative Exclusion" column : Exclude support for transaction
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    transaction
    Section 4.2.1, paragraph 1: remove reference to transaction
    Section 4.2.12: remove reference to transaction
    Section 4.5.1.1, point 2: remove reference to transaction
    Section 4.5.1.4: remove reference to transaction
    Section 4.5.2.4: remove reference to transaction

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - section 4.1.2

  • Key: CORBA35-86
  • Legacy Issue Number: 7130
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    the section 4.1.2 doesn't have to be fully removed. Only the references to
    entiy container have to.

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column, replace
    "Section 4.1.2: remove" by "Section 4.1.2: remove reference to entity
    container API types".

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - persistence

  • Key: CORBA35-88
  • Legacy Issue Number: 7128
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; there
    are still references to persistence in the following sections:
    4.2 §1, 4.2.1 §1, 4.2.12

    Proposed resolution:

    Add a row in the table 4.1 with :
    "Normative Exclusion" column : Exclude support for persistence
    "Document Impact" column : Section 4.2, paragraph 1: remove reference to
    persistence
    Section 4.2.1, paragraph 1: remove reference to persistence
    Section 4.2.12: remove reference to persistence

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - entity components

  • Key: CORBA35-87
  • Legacy Issue Number: 7129
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to entity components in the following sections:
    3.3.3.3, 4.5.1.3 (§1), 4.5.2.3 (point 3)

    Proposed resolution:

    Row 7 in the table 4.1, add in the "Document Impact" column :
    Section 3.3.3.3: remove references to entity components
    Section 4.5.1.3, paragraph 1: remove references to entity components
    Section 4.5.2.3, point 3: remove references to entity components

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - segmentation

  • Key: CORBA35-81
  • Legacy Issue Number: 7142
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", there
    are still references to segmentation in the following sections:
    : 3.2.1.6 (§1), 3.2.11 (§1), 3.2.9 (point 2), 4.2.12 (extended)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - locator

  • Key: CORBA35-82
  • Legacy Issue Number: 7141
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.3 "exluding support for segmentation", row
    3; there are still references to locator in the following sections:
    3.3.3.5, paragraph 4 and last paragraph

    Proposed resolution:

    Row 3 in the table 4.3, in the "Document Impact", add:
    Section 3.3.3.5, paragraph 4 and last paragraph: remove references to
    locator

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:01 GMT

lwCCM issues - CIDL

  • Key: CORBA35-83
  • Legacy Issue Number: 7133
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 2;
    and the table 4.3 "exluding support for segmentation", row 1: there are
    still references to CIDL in the following sections:
    1.5.2.1 (§1), 3.1 (§1)

    Proposed resolution:

    Row 2 in the table 4.1 and Row 1 in the table 4.3, add in the "Document
    Impact" column :
    Section 1.2.2.1, paragraph 1: remove references to CIDL
    Section 3.1, paragraph 1: remove references to CIDL

  • Reported: CORBA 3.0.3 — Tue, 9 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - configurators

  • Key: CORBA35-77
  • Legacy Issue Number: 7146
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.6 "exluding support for configurators";
    there are still references to configurators in the following sections:
    1.10.2 (second point), 1.10.2.1 (§2), 1.11.1 (configuration_complete)

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - Section 4.1

  • Key: CORBA35-78
  • Legacy Issue Number: 7145
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence"; in the
    "Document Impact" column, row 1, the § 3 doesn't exist in the section 1.1.4.

    Proposed resolution:
    Table 4.1, row 1, column "Document Impact": replace "Section 1.1.4,
    paragraph 3: remove" by "Section 1.1.4, paragraph 2: remove"

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - primary key

  • Key: CORBA35-79
  • Legacy Issue Number: 7144
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 1;
    there are still references to primary key in the following sections:
    1.7.1 (§1 & §3), 1.7.4, 1.7.5.1 (§1, §2), 1.7.5.2 (§1, §2)

    Proposed resolution:

    Row 1 in the table 4.1, add in the "Document Impact" column :
    Section 1.7.1, paragraph 1 and 3: remove references to primary key
    Section 1.7.4: remove references to primary key
    Section 1.7.5.1, paragraph 1and 2: remove references to primary key
    Section 1.7.5.2, paragraph 1and 2: remove references to primary key

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - invalid rows

  • Key: CORBA35-74
  • Legacy Issue Number: 7149
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 2
    and 3 are not valid

    Proposed resolution:

    remove the rows 2 and 3 of the table 4.7

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - proxy homes

  • Key: CORBA35-76
  • Legacy Issue Number: 7147
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.7 "exluding support for proxy homes", row 1;
    in section 3.2.5, the last paragraph should be removed.

    Proposed resolution:

    Row 1 in the table 4.7, in the "Document Impact", add:
    Section 3.2.5 last paragraph:remove

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

lwCCM issues - Entity2Context

  • Key: CORBA35-73
  • Legacy Issue Number: 7150
  • Status: open  
  • Source: THALES ( Olivier Hachet)
  • Summary:

    This issue concerns the table 4.1 "exluding support for Persistence", row 7;
    there are still references to Entity2Context in the following sections:
    3.2.11 (§2)

    Proposed resolution:

    Row 7 in the table 4.1, in the "Document Impact", add:
    Section 3.2.11, paragraph 2:remove reference to the Entity2Context
    interface.

  • Reported: CORBA 3.0.3 — Wed, 10 Mar 2004 05:00 GMT
  • Updated: Thu, 17 Oct 2024 16:00 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Legacy Issue Number: 1140
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec (orbos/98-01-18) does not specify which TypeCode operations apply
    to Value and ValueBox types. For example, are id(), name(), member_name(),
    member_count(), member_type(), etc. valid for Value and ValueBox or should they
    raise BadKind exception?

    I don"t see why they should not be valid. Normative text should be added in
    CORBA 2.2 section 8.7.1 TypeCode Interface to reflect this and the comments in
    the IDL should also be updated.

  • Reported: CORBA 2.2 — Thu, 9 Apr 1998 04:00 GMT
  • Updated: Thu, 17 Oct 2024 15:51 GMT

Can value type inherit from Value Box type

  • Legacy Issue Number: 1055
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can a Value type inherit from a Value Box type (the Value Box is
    described as been syntactic sugar for a Value type)? If so, what is the
    implicit name of the Value Box"s single data member?

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Thu, 17 Oct 2024 15:50 GMT

Deprecate fields duplicated between C2MS Messages and the Message Envelope

  • Key: C2MS12-26
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    With the advent of the C2MS Message Envelope, some tracking or meta-data fields exist in both the new Message Envelope and in the already-existing C2MS Message. For now, it is the case that we want to leave fields in the C2MS message and encourage migration toward Message Envelope usage. In a follow-on release, the duplicated fields should be deprecated in the C2MS Message.

  • Reported: C2MS 1.0 — Sat, 22 Jul 2023 20:27 GMT
  • Updated: Thu, 26 Sep 2024 22:32 GMT

Revisit Tracking Fields

  • Key: C2MS12-32
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS 1.0, there is no indicator whether a tracking field (special fields in the Message Header and Heartbeat Messages) is required, optional or dependent. As such, in C2MS 1.1, we are marking these all optional, except for Heartbeat.SUBSCRIPTION.n.SUBJECT.PATTERN, which is being marked as dependent (required if NUM-OF-SUBSCRIPTIONS is > 0).

    These should all be evaluated for R/O/D. One special case is HEARTBEAT.NUM-OF-SUBSCRIPTIONS. Normally, this should be required, because of C2MS11-135. However, in discussion for C2MS11-187, we went back to optional for this field. The rationale for this is that because it is a tracking field and therefore reserved for use by the PSM, rather than the generator of the message, it is difficult to understand what it means for a tracking field to be required. This reflects a shortcoming of the current C2MS documentation where it's not very clear what it means for a field to be a tracking field.

    Finally, there are some tracking fields that should be considered for removal, such as CONNECTION-ID, MW-INFO, and USER from the Message Header. These fields seem useful for debugging, but not operations.

    With the context stated above, the following need to be addressed in a future revision of C2MS:

    • Revisit which tracking fields should remain and deprecate the others.
        • As part of this, note that outside the Message Header, the only C2MS message that defines tracking fields is the Heartbeat Message. Do these belong? It just seems strange.
    • Determine R/O/D (required/optional/dependent) for each tracking field. Note that in an OMG meeting in Jan, 2024, broad-brushing it, it appeared that UNIQUE-ID and PUBLISH-TIME in the Message Header and NUM-OF-SUBSCRIPTIONS in the Heartbeat could be required, and the others optional in the Message Header.
    • Document the expected use for these tracking fields, including:
        • What the expected population of tracking fields is by both the Message Sender and the underlying PSM. (example, many of these are set as part of the GMSEC API and are supposed to be left alone before invoking the API in the one PSM that we currently have, but this is inner-workings knowledge and not clearly specified in C2MS).
        • What the expected use of these tracking fields, if any, is by a Message Recipient. For example, are these stripped off by the PSM before delivery? That would be symmetrical if the PSM populates the fields, but no mention of this exists in the current documentation. Some fields may be handled differently from others... for example UNIQUE-ID makes sense, but is the PSM really going to deliver CONNECTION-ID to the Message Recipient?
        • What does it mean if a tracking field is required? If only the PSM sets them, this would mean that a message would have to be created without a required field and then handed to the PSM, which is required to populate it.... this all needs clarity in the documentation.
  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 22:17 GMT
  • Updated: Thu, 26 Sep 2024 22:31 GMT

AMVAL Value Response Doesn't Mirror MVAL Value Response Message

  • Key: C2MS12-37
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    MVAL and AMVAL seem pretty close in most respects, but MVAL Response Message has many fields that are not present in AMVAL Response Message. Probably just need to do some analysis regarding comparative usages and fields to determine if it is correct as-is and if not, add the missing fields to AMVAL Resp.

  • Reported: C2MS 1.0 — Fri, 26 Jan 2024 00:20 GMT
  • Updated: Thu, 26 Sep 2024 22:30 GMT

What to do when Priority isn't Specified

  • Key: C2MS12-46
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Priority is an optional field on a couple of messages. We need to do some analysis regarding what it means if Priority isn't specified, and consider making textual guidance in the document.

    Affected messages:

    • Directive Request Message
    • Simple Service Request Message
  • Reported: C2MS 1.0 — Mon, 22 Apr 2024 00:24 GMT
  • Updated: Thu, 26 Sep 2024 22:29 GMT

Using REQ Messages for 'Publish'

  • Key: C2MS12-15
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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: Thu, 26 Sep 2024 22:27 GMT
  • Attachments:

Command Echo Not Provided Message

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

    We have already added a CMD-ECHO boolean to the Command Request Message in C2MS11-87. However, there is a possible scenario where just because we asked for one, there is no way for one to be delivered.

    According to C2MS11-87, the field is an attempt to "Indicate if an ECHO should be sent at any configured point(s) along the ground chain as the command is transmitted."

    The question of this issue is around what to do if the back-end system is not capable of or is not configured to send an Echo. In that case, there would quietly be no echo at all in spite of setting that flag to true. Gerry has brought up that perhaps we need a message type that is "unable to echo" or use the CMD ECHO message with a value of "here's your echo, but we aren't able to collect any information".

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 19:46 GMT
  • Updated: Thu, 26 Sep 2024 22:23 GMT

Revisit Completion Status in Command Response Message

  • Key: C2MS12-67
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    We have a command request message and a command response message.

    There can apparently be multiple responses, each as it progresses through the values of the XTCE-STATUS. These even can include if the command was accepted, is executing and if it was completed at the vehicle. But this would mean that the command service that intercepts the command request message must be able to determine from vehicle TLM each of these states.

    It would probably be worth while to revisit this and document more clearly the pattern of use of this item, including the multiple responses, and the expected statuses to produce by the command component service provider.

    Additionally, there may be a couple of statuses not covered by XTCE-STATUS, such as VCC checking, and TLM verification (verifying the effected change in the telemetry). The former could fall under either 'invalid' or 'failed', but these aren't really discreet enough. The latter doesn't have any status indicated in this message.

  • Reported: C2MS 1.0 — Mon, 22 Jul 2024 22:35 GMT
  • Updated: Thu, 26 Sep 2024 22:20 GMT

Rework Log Message

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

    The Log Message in 1.0 is vague in the sense of what it is supposed to be used for. Is it an application-level log (similar to Log4j or is it an event alerting mechanism for ground and/or satellite events. It might be useful to split it into application logging vs ground or satellite alerting. Need to analyze its intended and current use to the extent possible and recommend a way forward that clearly demarcates event alerts from logging.

    There also needs to be an Event that is to capture AWEs or state change... something to do with teh operational state of the system (Mission Data).

  • Reported: C2MS 1.0 — Sun, 14 Apr 2024 23:36 GMT
  • Updated: Thu, 26 Sep 2024 22:09 GMT

Consider Deprecating and Later Removing Resource Message

  • Key: C2MS12-31
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Resource Message stated objective is to enable publishing "computer performance data" via a defined C2MS message. However, using C2MS messages to monitor CPU load, memory utilization, and network port status seems wholly out of scope for satellite command and control. This provides what is essentially a rudimentary mechanism for resource monitoring, which could easily be better accomplished through industry standard mechanisms completely outside of C2MS.

    In C2MS11-2, we removed CPU and memory related data from the Heartbeat Message. It makes sense to completely remove the Resource Message (via deprecation) for the same reason.

  • Reported: C2MS 1.0 — Fri, 12 Jan 2024 21:43 GMT
  • Updated: Thu, 26 Sep 2024 22:08 GMT

The quantities and units ontology does not allow representation of unitless quantity values

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There is a gap in the quantities and units ontology whereby we cannot represent counts of things, which do not necessarily have units, nor can we properly represent ratio values, which may involve scalar quantity values that do not have units. There is also a challenge in representing ratio values more generally, since there is no numeric value representing the ratio on the class.

  • Reported: Commons 1.1b1 — Tue, 13 Feb 2024 21:34 GMT
  • Updated: Wed, 25 Sep 2024 22:59 GMT

The quantities and units ontology does not allow representation of unitless quantity values

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    There is a gap in the quantities and units ontology whereby we cannot represent counts of things, which do not necessarily have units, nor can we properly represent ratio values, which may involve scalar quantity values that do not have units. There is also a challenge in representing ratio values more generally, since there is no numeric value representing the ratio on the class.

  • Reported: Commons 1.1b1 — Tue, 13 Feb 2024 21:34 GMT
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Need an ontology representing multidimensional arrays

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:03 GMT
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Need an ontology representing multidimensional arrays

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is needed for representation of tensor and vector quantities for the quantities and units ontology, and for representation of certain machine learning algorithms, among other requirements.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:03 GMT
  • Updated: Wed, 25 Sep 2024 22:59 GMT

Consider a Command Completed Publish Message

  • Key: C2MS12-66
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The Command Response Message has in the XTCE-STATUS field the ability to convey if a message was executed and completed. However, this may be incomplete because it doesn't account for VCC checking or functional verification (the expected effect was attained after the command, as would be indicated in a changed TLM point).

    One possible solution is to add a new Command Completed Message that the command subsystem would send out after all checks to indicate that all the VCC Verification, Command Accept Verification and effected TLM (Functional Verification) were completed.

  • Reported: C2MS 1.0 — Tue, 16 Jul 2024 18:20 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Reconsider Oneshot in MVAL Request/Response

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

    Mnemonic Value Request Message and its corresponding Mnemonic Value Response Message utilize a concept called "ONESHOT" or "Oneshot". These are the only messages in C2MS that have this construct.

    This is described in Mnemonic Value Request Message as:
    "The Mnemonic Value Request Message is used to request one or more mnemonics either as a single sample ('Oneshot') or as a request to Start publishing the mnemonics continuously."

    and

    Mnemonic Value Response Message:
    "For a 'Oneshot' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the values of the requested mnemonics and no further Mnemonic Value Data messages will be published."

    However, in a significant way, these statements conflict with the next line:
    "For a 'Start' Mnemonic Value Request Message, the Mnemonic Value Response Message contains the initial values of the requested mnemonics and subsequent occurrences of the mnemonics will be published via the Mnemonic Value Data Message."

    In other words, the Response Message will contain the initial set of data (current point values) in response to EITHER 'Start' or 'Oneshot'. The description says "either or" ("either as a single sample ('Oneshot') or as a request to Start publishing"), but the logical statement should be "yes and maybe" (Both Oneshot and Start will contain the initial set of data, but only Start will be followed with Mvals).

    The effect of this is that the MVAL Req/Resp works in a primary subscription-based manner or in a different manner when specifying ONESHOT.

    With this in place the MVAL Req/Resp sometimes follow the Request/Response Message Exchange Patter, and other times follow the Request/Response/Publish MEP. In fact, figure 8-19 Mnemonic Value Message Sequence Diagram illustrates the Request/Response/Publish MEP. It is not valid for the Request/Response MEP. No example of the Request/Response MEP is shown for this message.

    Furthermore, some fields are handled specially depending on which MEP is used. For example, it is stated in the spec that when using ONESHOT, the following fields are ignored in the Request:
    • PUBLISH-RATE
    • DURATION
    • MNEMONIC.n.CRITERIA
    • MNEMONIC.n.SAMPLE-RATE

    Meanwhile, in the Reponse, RESPONSE-STATUS field values 3 and 4, likely only apply to ONESHOT, while 1 likely only applies to non-ONESHOT. requests.

    This odd dual-purposing of these messages was all likely done at some point out of convenience of overloading existing messages rather than creating new messages that would have been a more coherent design.

    It has the effect, for a 'Start' of the consumer needing to read both the MVAL Return message for data and then a series of MVAL data message, rather than simply reading MVAL data messages.

    In order to remove this overload, I suggest one of the following:

    1 - deprecating ONESHOT and related fields in those messages and creating a new Message Type for retrieving current values. These could be called Mnemonic Current Value Request Message and Mnemonic Current Value Response Message.

    2 - removing the value fields from the Response Message above, then simply convert the ONESHOT to a form of Request/Response/Publish MEP in which only one publish happens, and then the subscription ends. Subscription termination is already part of the spec, because of DURATION. The way this would work is the requestor sends a request message marked for ONESHOT, the service sends a response message, the service sends a single Mnemonic Value Data Message, the subscription is terminated. In this way, Mvals are only communicated in one type of message: Mval Data Message, easing the burden for handling two message types.

    In a certain sense, I like the first option better, because it addresses the need to get current values using dedicated messages. However, the second approach is a much smaller change and represents a solution that is FAR more straight-forward than the way it is implemented today.

  • Reported: C2MS 1.0 — Thu, 23 Mar 2023 13:01 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Analyze Legal use of "Search" for FRAMESYNC-STATUS in TLM Processed Frame Message

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

    TLM Processed Frame Message currently requires 1+ NUM-OF-MNEMONICS, which makes sense, except that "Search" is a valid status for FRAMESYNC-STATUS. If that status is Search, it doesn't seem possible for there to be MNEMONICS... yet, if there are no MNEMNOICS, because FRAMESYNC-STATUS is Search, then why would there be a TLM Processed Frame Message?

    Need to do some analysis on this and decide how to handle this conundrum in the document. Should 0+ be the value of NUM-OF-MNEMONICS, or should 1=Search not be a valid FRAMESYNC-STATUS, and either way, this needs to be explained to the user of this message.

    Finally, does FRAMESYNC-STATUS even belong in this "Processed Frame" message? This might have been a long-ago copy-paste error. A frame synch status of 'Verify' is used typically to say that the processing component has the frame but is looking for the next framesync marker after which it moves to 'Lock' state, and will keep everything flowing, while 'Check' means that after processing some frames in 'Lock' state, it's now trying to locate the framesync marker again (like short frame, for example). Either way, it just seems (to me) that we would only produce "Processed Frames" if the FRAMESYNC-STATUS is 'Lock'. There may be exceptional cases where a component is asked to produce MNEMONICS even under the 'Verify' or 'Check' states, but this would be rare, and error prone. So, maybe just getting rid of 'Search' would be OK-ish, but again, just need to re-evaluate this one.

  • Reported: C2MS 1.0 — Mon, 22 Apr 2024 00:52 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Consolidate Navigation Data Messages

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

    The various Navigation Data Messages are nearly identical. They should be consolidated into a hierarchy that defines a Navigation Data Message base class and then let the others derive from it for better model structure. The Tracking Data Message has a few extra fields. Otherwise, everything is identical across all messages except for some type values.

    I thought about doing this when I was updating the model in 1.1, but would have also had to update the chapter text and didn't have time for all that in 1.1.

  • Reported: C2MS 1.0 — Mon, 15 Apr 2024 18:12 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Replace Unsolicited Echo with a Separate Message

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

    According to the Command Echo Request:

    “This message is nominally sent after a Command Request is processed by the final destination (e.g., antenna or spacecraft). The Command Echo Message can also be generated without a prior Command Request Message being sent; this is known as an 'unsolicited echo' and can be generated by ground station equipment as a result of the antenna receiving noise or interference.”

    The concept of an unsolicited echo seems very strange, because it raises the question of what is being echoed, if it is not the command.

    The Command Echo Message Additional Information table has a CMD-ECHO-RESULT value of UNEX "Unexpected echo received" which I suspect is tied to the "unsolicited echo".

    If an unsolicited echo is meant to convey that the ground equipment is receiving noise or interference from the antenna, I believe a better approach would be to define a message to capture the noise or interference as an occurrence in the ground string and to send that, rather than to overload the Command Echo Message.

  • Reported: C2MS 1.0 — Wed, 15 Mar 2023 20:20 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

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

  • Key: C2MS12-11
  • Status: open  
  • Source: NASA ( Mr. John 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: Mon, 23 Sep 2024 00:33 GMT

Data Dictionary Messages

  • Key: C2MS12-2
  • Status: open  
  • Source: Boeing ( Mr. 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, 23 Sep 2024 00:33 GMT

Add documentation within the model

  • Key: C2MS12-7
  • 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: Mon, 23 Sep 2024 00:33 GMT

XML PSM recommended

  • Key: C2MS12-4
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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: Mon, 23 Sep 2024 00:33 GMT

C2MS Database Query (DBQUERY) messages

  • Key: C2MS12-14
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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."

    NOTE: C2MS12-2 is being closed as a DUP of this message, so the intent of that issue needs to be addressed in the resolution of this one.

  • Reported: C2MS 1.0 — Wed, 26 Jan 2022 18:09 GMT
  • Updated: Mon, 23 Sep 2024 00:33 GMT

Clean up a few issues with the Locations ontology

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    1. County and FederalCapitalArea should be subclasses of CountrySubdivision

    2. FederalState should have synonyms rather than this in the note "variously referred to as a state, province or canton".

    3. Several annotations on geographic region identifier and a few other concepts need clarification

  • Reported: Commons 1.1 — Fri, 16 Aug 2024 18:15 GMT
  • Updated: Mon, 16 Sep 2024 14:39 GMT
  • Attachments:

The definition of aspect needs refinement

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Rather than classifying 'something' an aspect should classify a set or group of things - at a higher metalevel than 'quality' in BFO, for example. This impacts the Classifiers ontology, in which Aspect is defined.

  • Reported: Commons 1.1 — Fri, 12 Apr 2024 18:40 GMT
  • Updated: Mon, 16 Sep 2024 14:39 GMT
  • Attachments:

C2INav Model refers to an old OARIS Common Types package

  • Key: OARIS3-17
  • Status: open  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The C2INav Model refers to a package defined by OARIS 1.1.
    OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.

  • Reported: C2INAV 1.0 — Wed, 21 Jun 2023 10:00 GMT
  • Updated: Mon, 16 Sep 2024 14:35 GMT

BNF changes

  • Legacy Issue Number: 5952
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    BTW I think the twiddle is incomplete because it is not reflected
    in the BNF for Identifier. I think it is better if the BNF always
    reflects the ultimate specification of a language's lexical
    definition. Otherwise compiler writers are apt to miss the
    subtleties.
    I'll propose some BNF changes if others agree

  • Reported: CORBA 3.0.2 — Wed, 25 Jun 2003 04:00 GMT
  • Updated: Thu, 12 Sep 2024 21:34 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Legacy Issue Number: 5856
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is a sentence in the first paragraph of 22.6 that should be fixed:

    "The implementation of these methods must generate a method invocation
    as described in Section 22.14, Message Routing, on page 22-50."

    However, 22.2.5.3 allows asynchronous invocations to be delivered via
    synchronous protocols if the RoutingPolicy is ROUTE_NONE.

    This sentence should be changed to:

    "The implementation of these methods may generate a method invocation as
    described in Section 22.14, Message Routing, on page 22-50, depending
    on the effective RoutingPolicy for the invocation."

  • Reported: CORBA 3.0.2 — Tue, 11 Feb 2003 05:00 GMT
  • Updated: Thu, 12 Sep 2024 21:31 GMT

Add optional/map mapping (and other IDL4 special types)

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

    For IDl4 the CDR marshaling should be described, optional could be described as a union with a boolean discriminant, with TRUE containing the value, map as a sequence of structs containing each key/value, other IDL4 extensions can also be described using IDL base types marshaling. That also enables interoperability of optional/map/others with an old implementation without IDL4 support, the IDL has to be rewritten to work, but at that moment an IDL3 app can talk with a IDL4 app (at least for CDR)

  • Reported: CORBA 3.4 — Mon, 27 May 2024 06:22 GMT
  • Updated: Thu, 12 Sep 2024 21:22 GMT

Refactor "Introduction to Specification" section in front matter of Document

  • Key: C2MS12-51
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The section titled: "Introduction to Specification" needs evaluation and at least some rework. This is largely written as a "how we got to here" section, but could use more C2MS-centric language. Also, this should be considered to be moved from the front matter to a numbered section, such as perhaps 5.1 (moving the existing 5.1 to 5.2).

    If moved to a numbered section, it needs to be marked "Informative".

    May be related to C2MS12-28.

  • Reported: C2MS 1.0 — Sat, 29 Jun 2024 20:14 GMT
  • Updated: Thu, 12 Sep 2024 19:14 GMT

Improve Example Text for Publish Rate

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

    In section 8.8.1.3 Mnemonic Value Request Message Contents, there is a kind of odd example paragraph under the explanation of PUBLISH-RATE, that states: "For example, the data provider may know that it is limited to an output rate of 1 megabyte per second. If it is currently near its maximum output rate and after calculating the additional load of the request it would exceed that rate, the data provider may reject the Mnemonic Value Request with a "Failed Completion" status in the RESPONSE-STATUS field, and an optional status of "Unable to meet demand" in the RETURN-VALUE field."

    This should probably be placed elsewhere (under a different heading in the same area) and possibly reworded, as an example of not being able to meet the request, instead of an example of PUBLISH-RATE.

    The issue is that PUBLISH-RATE is described, then a caveat is given, then an example of the caveat. It winds up confusing as an example of PUBLISH-RATE.

  • Reported: C2MS 1.0 — Thu, 25 Apr 2024 14:11 GMT
  • Updated: Thu, 12 Sep 2024 18:49 GMT

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

  • Key: C2MS12-12
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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: Thu, 12 Sep 2024 18:12 GMT

Split ME1 in Simple Service Req/Resp

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

    Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:

    • Service Provider Name (a named instance of a component, such as FDServiceApp1)
    • A Service Name not related to a specific component (such as Flight Dynamics)

    Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:

    • A Requestor Name (a named instance of a components that requested a service, or will receive data from the Service Provider, such as C2App7)
    • A Service Name not specific to a component (such as Flight Dynamics)

    Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.

    This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.

    This issue reqeusts to do that same thing, matching the modification made by that major user.

  • Reported: C2MS 1.0 — Thu, 16 Feb 2023 15:53 GMT
  • Updated: Wed, 11 Sep 2024 21:06 GMT

Larger Data Types

  • Key: C2MS12-8
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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.

    [NOTE: the reason for deferment is simply say making the RAW-VALUE a 64 bit and the EU-VALUE 128-bit float falls outside of hardware support and programming language support -- and adding a DATA-TYPE field to support the specification of any valid c2ms data-type in either field seems like a big change that should be considered more fully.]

    The current spec supports a RAW-VALUE and EU-VALUE (converted/calibrated) fields. Currently the RAW one is a 32-bit signed integer and the EU one is a double (64-bit). To support a broader value type and range, this change adds a RAW-VALUE-TYPE and an EU-VALUE-TYPE to any message these fields are in. In some cases, if the message has both a RAW and EU value, these could in some cases be identical. Additional optional (special case) fields are also added RAW-VALUE-LENGTH and EU-VALUE-LENGTH, these two are discussed below.

    The RAW-VALUE-TYPE and EU-VALUE-TYPE would be one of the C2MS data-types and be valid for all samples in the message. Hence, they are only specified once per message.

    For example, a typical combination might be: RAW-VALUE-TYPE=I32, EU-VALUE-TYPE=F64 for numeric calibrated telemetered values.

    The main reason in some cases to preserve both the RAW and the EU value is that in some cases there's a need to re-calibrate existing values and the raw can then be used to do that... [are there any others?]

    [It's worth noting that RAW here may mean literally bit-by-bit what's in the packet or it could mean "host corrected" (byte swapped) but without calibration -- we should sort that out. In fact, C2MS does not say that I can tell ... I'm aware that some orgs support the notion of raw from the packet, host-converted (byte/bit corrected), and fully calibrated) in which case within discussion we may want to have 3 fields, which seems excessive. I think I prefer 'host-corrected' for the raw, as we can only do so much, and some folks might not have the truly raw bits available anyway...]

    RAW-FIELD-TYPE and EU-TYPE-TYPE are of type String. The legal values are specified in table 8.1 column Field-type. Note that these should probably be mixed character legal in these fields.

    Two OPTIONAL fields are available for type binary (blob) and variable. These types SHALL supply RAW-VALUE-LENGTH and EU-VALUE-LENGTH which are both I32 and specify the number of bytes for either field value. Negative values are illegal. From an implementation point of view in regard to these variable length fields, that messages beyond a few megabytes are likely not supported.

  • Reported: C2MS 1.0 — Sat, 21 Mar 2020 15:48 GMT
  • Updated: Wed, 11 Sep 2024 16:13 GMT

Normalize Headers and Text in the new DB Query Messages

  • Key: C2MS12-38
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the already-approved C2MS11-45, we added DB Query Messages. However, this issue did not include a text description for each message, which is common for all other C2MS Messages.

    Specifically, the new sections 8.14.1 and 8.14.2 need a description in order to be consistent with other C2MS Messages.

    Additionally, some of the subsection headers, table and figure titles don't conform to usage in the remainder of the document.

  • Reported: C2MS 1.0 — Thu, 1 Feb 2024 14:21 GMT
  • Updated: Wed, 11 Sep 2024 16:08 GMT

Undo Addition of DB Query Messages in 1.1

  • Key: C2MS12-45
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS11-45, approved in Ballot #10, the C2MS11 RTF added two new DB Query messages to C2MS 1.1. However, late in the 1.1 cycle, it was determined that these new messages are inadequate at the present time and need significant rework. The decision was made by the author of the DB Query messages to remove these from 1.1 and resubmit updated versions in a later release (1.2).

    Therefore this issue is intended to undo the effect of C2MS11-45, so that those changes are not included in 1.1.

    Note related issue (that was added to capture some of, but not all, of the updates needed) C2MS11-212.

    An attached word doc includes markup text that was intended to augment the previously-approved C2MS11-45. This is simply included to aid recreation of a resolution issue in the future 1.2.

    Two other attachments contain the originally-approved text for the spec. These should all be combined and reworked.

  • Reported: C2MS 1.0 — Tue, 16 Apr 2024 21:29 GMT
  • Updated: Wed, 11 Sep 2024 16:08 GMT
  • Attachments:

Need Review/Documented Explanation of NUM-OF-PROD-SUBTYPE-SUBCATEGORIES

  • Key: C2MS12-39
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    The purpose NUM-OF-PROD-SUBTYPE-SUBCATEGORIES in several messages is not clear and needs to be reviewed and either removed or expanded upon. Note that this is called NUM-OF-PRODUCT-SUBTYPES in C2MS 1.0, but the explanations are simply preserved from 1.0 into 1.1 where the field was renamed, so this issue persists.

    One interesting aspect of this is that these subtype subcategories are represented in the subject of the Product Message ME5 and ME6, and all other messages that have it refer to this Subject construct. This is described in the table and notes for the table for (C2MS 1.1) "Table 8-163. Properties of the Miscellaneous Elements for the Product Message"

  • Reported: C2MS 1.0 — Fri, 2 Feb 2024 17:42 GMT
  • Updated: Tue, 10 Sep 2024 03:15 GMT

constexpr constructors missing

  • Key: CPP1117-39
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In user code I want to use constexpr for IDL fixed values, for example

    constexr F pi

    {3.142857}

    ;

    But in order for that to work a constexpr constructor has to be available, the spec should define that

  • Reported: CPP11 1.7 — Wed, 4 Sep 2024 07:19 GMT
  • Updated: Wed, 4 Sep 2024 14:18 GMT

CORBA::CustomerMarshal, type

  • Key: CPP1117-38
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::CustomerMarshal, should be CORBA::CustomMarshal,

  • Reported: CPP11 1.7 — Mon, 19 Aug 2024 07:10 GMT
  • Updated: Wed, 4 Sep 2024 14:10 GMT

Typo CORBA::CustomerMarshal

  • Key: CPP1117-37
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::CustomerMarshal should be CORBA::CustomMarshal

  • Reported: CPP11 1.7 — Mon, 19 Aug 2024 07:08 GMT
  • Updated: Wed, 4 Sep 2024 14:07 GMT

Align TLM Terms

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

    This is probably one for 2.0...

    Message subtypes include the following that need to be address, possibly reworked/renamed:

    • TLMPKT that should be renamed TLMCCSDSPKT
    • TLMFRAME (already deprecated).
    • TLMCCSDSCADUFRAME (new in 1.1 and OK)
    • TLMCCSDSTRANSFERFRAME (new in 1.1 and OK)
    • TLMTDM that probably should be renamed TLMTDMFRAME

    Additionally, there is an enumerated value CCSDSPKT in Replay Telemetry Data Request Message and CCSDSPACKET in Command Request Message and Command Echo Message. These two should be make the same name.

  • Reported: C2MS 1.0 — Tue, 7 May 2024 17:34 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

Find a Reusable Way to Represent types like Mnemoic, Sample, Others in Model

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

    There are many 'classes' in the model (because that's what is in the message) for Mnemonic, frequently with different values. Same probably true of Sample and others. It would be great if these structs in the messages and classes in the model were better reused so that we don't have two different items both called "Mnemonic".

    This issue sort of harkens back to when we had things like "Required Fields" in each message in the model, with no relationship to each other.

  • Reported: C2MS 1.0 — Tue, 6 Feb 2024 18:41 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

Remove the Req/Resp/Pub MEP

  • Key: C2MS12-30
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In C2MS2.0, we need to revisit the Req/Resp/Pub MEP, as is the same with MVAL Req, followed by an MVAL Resp, followed by an indefinite number and duration of MVAL Data Messages.

    This should really be either a standard Pub-Sub construct or should just be a simple req/response.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 20:23 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

Use Semantic Versioning for Version Number of Messages

  • Key: C2MS12-29
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    This is one for C2MS 2.0. Capturing it here, because this is the only avenue to enter issues at present.

    Instead of a F32 for version number, which then uses a year, like 2024.0, we should change this to a formatted string that uses Semantic Versioning, with a string that looks like the following:

    MAJOR.MINOR.PATCH

    Examples: "2.0.0", "2.1.1"

    Note that this means changing the base type and the meaning of the current version numbers.

    Note, too, that this shouldn't simply be type STRING, but should be something like VERSION-STR with the format defined by C2MS.

    Also, consider getting rid of the separate header version and message content version. This is just something to bring up to the group.

  • Reported: C2MS 1.0 — Wed, 27 Sep 2023 19:53 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

Remove Superfluous Fields from Header and Envelope

  • Key: C2MS12-27
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Many fields in the C2MS Header (which have of necessity also been put in the C2MS Envelope) should be evaluated for change or removal in the next major release. Change to be made in both C2MS Message and C2MS Envelope. Examples:

    • ROLE should be renamed COMPONENT-ROLE to avoid confusion with user role (authorization).
    • USER-NAME should be removed. This seems to be only debug info and does not have anything to do with authentication/authorization. The new fields SENDER-IDENTITY and SENDER-ACCESS in the envelope provide that.
    • FACILITY/NODE/PROCESS-ID/CONNECTION-ID are candidates for removal. These seem only valuable for debugging. Debug info doesn't belong in a standard, IMO.
    • CONNECTION-ID should be removed. This is definitely only valuable for debugging.
    • MW-INFO - no idea why this is there. Probably need a use case or example of what this is used for, but it doesn't seem to belong.
  • Reported: C2MS 1.0 — Sun, 23 Jul 2023 15:30 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

At Next Major Revision: Evalutate all Required/Optional/Dependent states for consistency

  • Key: C2MS12-25
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some fields and message elements that should be required are listed as optional. For example, in the Telemetry CCSDS Packet Message, ME SCID was added in 1.1, so had to me marked optional, but it should be required. APID already existed in that message as a Message Element, but not as a field, so whereas the ME is required, the field had to be made optional (for backward compatibility).

    Additionally, in section 6.2.2 Format of C2MS Subject Names, there is a description that says, "If an element is required but not applicable for that mission or to that type of message, the publisher inserts “FILL” (no quotes) for that element." However, this should be cleaned up. If a field is required it should be required, if not, then it should not be required. Need a run through the messages to see how this can be improved.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:35 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

At Next Major Revision: Order MEs and Fields Consistently

  • Key: C2MS12-24
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    Some Message Elements and Fields are in different order from message to message. The fields are just a listing so not as important, but the MEs are order-dependent. One example of how this is an issue is that the Telemetry CCSDS Packet Message added a new ME, but this had to go to the end (ME6) because of backward compatibility. This creates a strange ordering with VCID, APID, Collection Point, SCID. This is just one example, but the need is to evaluate all the MEs and fields and see if any need to be moved to make messages more uniform in structure.

    Additionally, there are cases where some MEs have been removed between 1.0 and 1.x, leaving "not used"/"FILL" in the corresponding positions of MEs and these need cleaning up.

  • Reported: C2MS 1.0 — Sun, 16 Jul 2023 21:29 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

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

  • Key: C2MS12-6
  • 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

    These were likely left this way because they already have "Message" in the name, though with a different meaning. Archive Message Retrieval Request Message does sound redundant. Perhaps renaming to any of the following would help:

    • Archived Messages Request Message
    • Archive Retrieval Request Message
    • Archive Request Message
    • Archive Message Request Message

    Not using "Archive Message" in the title is a bit confusing because there is Archive data that is not simply archived messages, see "Archive Mnemonic Value Request Message"

    Note that when originally entered, this issue listed all the following... but in 1.1, the only messages not ending in "Message" are the Archive request/responses.

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

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Updated: Thu, 8 Aug 2024 00:02 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS12-3
  • Status: open  
  • Source: Boeing ( Mr. 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: Thu, 8 Aug 2024 00:02 GMT

Harmonize Replay TLM and Archive Mnemonic Message Sets

  • Key: C2MS12-9
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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: Thu, 8 Aug 2024 00:02 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS12-1
  • Status: open  
  • Source: Boeing ( Mr. 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: Thu, 8 Aug 2024 00:02 GMT

use of brackets not consistent for Subject Elements

  • Key: C2MS12-50
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In the "... Subject Naming" tables, a "Subject Content" item is supposed to have brackets [] around variables and no brackets for literals. This is not always followed though. See Telemetry CCSDS Packet Message as an example.ME2-ME6 do not use brackets, but should. Several other tables are like this.

  • Reported: C2MS 1.0 — Mon, 13 May 2024 06:05 GMT
  • Updated: Wed, 24 Jul 2024 21:29 GMT

Non-sensical Description for PROD-MSGS-TO-SEND

  • Key: C2MS12-35
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. Mike Anderson)
  • Summary:

    In Product Response Message, PROD-MSGS-TO-SEND field is an unsigned type, with a stated minimum "value" of 0+, but says in the description text the following:

    A value of “-1” can be used to indicate “Unknown”.

    Should probably find a different way to indicate unknown, such as not including this optional field in the message.

  • Reported: C2MS 1.0 — Wed, 24 Jan 2024 21:55 GMT
  • Updated: Wed, 24 Jul 2024 21:24 GMT

Consider a mechanism to request archived Commands and Events

  • Key: C2MS12-13
  • Status: open  
  • Source: Kratos RT Logic, Inc. ( Mr. 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, 24 Jul 2024 21:16 GMT

Informational Update to CSRM Profile Specification

  • Key: CSRM12-3
  • Status: open  
  • Source: INCOSE ( Haifeng Zhu, David Kaslow)
  • Summary:

    Rationale:
    System Adaptability is an increasingly important topic, as it’s an effective way to reduce significant cost overrun and schedule delays, which frequently exist in aerospace industry. It is also listed in INCOSE SE Vision 2035 as one of the backbone technology (ref: "Paul Schreinemakers", leader of FuSE – Future Systems Engineering initiative in INCOSE).
    Recent progress in this topics include: Boeing’s adoption of adaptability technique to achieve sustainability (https://www.linkedin.com/feed/update/urn:li:activity:7159262285008437249/ ) and proposal of including adaptability into IEEE Smart Cities standards, etc.
    Adaptability is a very important and desirable property of a reference architecture. That allows users to easily adapt to changes in the future, which almost always happen in the aerospace industry. Overly restrictive architecture often cause high cost when requiring changes in the late stages of the development cycle. Thus, it is important to emphasize that CSRM is adaptable per INCOSE’s definition of adaptability in SEBoK.

    Recommended Updates:

    Doc number: dtc/23-12-05
    Page 1

    Add one sentence is Section 2:
    The CSRM reference architecture defined in conformance with the CSRM Profile accommodates architecture adaptability [REF of SEBoK] and provides necessary facilities (mission profiles). The conformance definition enables user production of high system adaptability per the standard SEBoK definition of adaptability.

    Add a reference in Section 3:
    [REF of SEBoK] IEEE, INCOSE, Steven Institute of Technology, Systems Engineering Body of Knowledge (SEBoK), version 2.9, System Adaptability Chapter, URL: https://sebokwiki.org/wiki/System_Adaptability , 2024

  • Reported: CSRM 1.1b1 — Fri, 28 Jun 2024 19:35 GMT
  • Updated: Mon, 1 Jul 2024 15:22 GMT

Informational Update to CSRM Profile Specification

  • Key: CSRM12-2
  • Status: open  
  • Source: INCOSE ( Haifeng Zhu, David Kaslow)
  • Summary:

    Rationale:
    System Adaptability is an increasingly important topic, as it’s an effective way to reduce significant cost overrun and schedule delays, which frequently exist in aerospace industry. It is also listed in INCOSE SE Vision 2035 as one of the backbone technology (ref: "Paul Schreinemakers", leader of FuSE – Future Systems Engineering initiative in INCOSE).
    Recent progress in this topics include: Boeing’s adoption of adaptability technique to achieve sustainability (https://www.linkedin.com/feed/update/urn:li:activity:7159262285008437249/ ) and proposal of including adaptability into IEEE Smart Cities standards, etc.
    Adaptability is a very important and desirable property of a reference architecture. That allows users to easily adapt to changes in the future, which almost always happen in the aerospace industry. Overly restrictive architecture often cause high cost when requiring changes in the late stages of the development cycle. Thus, it is important to emphasize that CSRM is adaptable per INCOSE’s definition of adaptability in SEBoK.

    Recommended Update:
    Doc number: dtc/23-12-05
    Page 1

    Add one sentence is Section 2:
    The CSRM reference architecture defined in conformance with the CSRM Profile accommodates architecture adaptability [REF of SEBoK] and provides necessary facilities (mission profiles). The conformance definition enables user production of high system adaptability per the standard SEBoK definition of adaptability.

    Add a reference in Section 3:
    [REF of SEBoK] IEEE, INCOSE, Steven Institute of Technology, Systems Engineering Body of Knowledge (SEBoK), version 2.9, System Adaptability Chapter, URL: https://sebokwiki.org/wiki/System_Adaptability , 2024

  • Reported: CSRM 1.0 — Fri, 28 Jun 2024 19:24 GMT
  • Updated: Mon, 1 Jul 2024 15:22 GMT

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: open  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    In chapter 11 'Unreliable Mulicast Inter-ORB Protocol' the struct PortableGroup::GroupInfo is discussed. However in the consolidated IDL and the IDL available from the OMG web site, this struct has been replaced by PortableGroup::TagGroupTaggedComponent. Which is correct?

  • Reported: CORBAe 1.0b1 — Tue, 27 May 2008 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

  • Legacy Issue Number: 681
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Add CORBATCKind to end of enum list

  • Legacy Issue Number: 687
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Enum CORBATCKind omits the boolean kind (p.4-123, section 4.1.12) I recommend adding it to the end of list to preserve backward compatibility. Also missing tk_char.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

ODL is erroneous

  • Legacy Issue Number: 691
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ODL which shows an extra, optional parameter for exception information on property-get or property-set method is erroneous, since MKTYPLIB doesn"t allow extra parameter on property accessor

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

page 2-30: There is a label "Examples", but no examples

  • Legacy Issue Number: 693
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) ValueDefSeq is used in a couple of places but is never defined. A typedef
    for it is missing.

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5.3.3: Is it possible to have a value inherit from (ie, support) a
    boxed value ? If yes, the Java mapping of boxed values of type
    string, sequence and arrays should be changed because String
    and arrays can"t be extended in Java.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) Attribute "name" in interface ValueMemberDef clashes with attribute "name"
    inherited from Contained. A different name should be used, something like
    "value_member_name"

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If a value type can inherit from a Boxed Value then what is the implicit name of
    the Value Box"s single data member?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether the #pragma prefix is still part
    of the repository Id. I think it should be.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Clarify the hash code algorithm

  • Legacy Issue Number: 1262
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why is the 64 bit hash code at the end of the string and
    not at the beginning ? This can speed up the comparison
    when two repository Ids are different.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) How does one find out a RepositoryID for registering a factory or a streaming
    policy?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.6.3 Hashing Algorithm (and 5.6.2)

    • It is not clear whether the hash value is translated
      into ascii or not.
    • I assume the result is a long long:

    long long hash = sha[1] << 32 + sha[0]

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the exact semantics of computing the hash code and comparison semantics for type equivlanece. (lost email, paraphrase of issue)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The default ref-counting classes are said to be "fully concrete".
    Is this really necessary?
    What is the semantic of "_copy_value" for the ref-counting class?
    => suggest that "_copy_value" MUST NOT be implemented
    (It is implemented by "_copy_value" of the real value type)

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I have an important issue concerning the C++ mapping and the fact
    that application developers need to define/implement the concrete
    value class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the
    generated C++ class.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What is the rationale for making ValueBase a value and not a native type?
    It seems strange to me that a ValueBase "value" maps to java.io.serializable
    in Java. Isn"t that what native was invented for?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107, interface Account should inherit ":" from Describable and
    value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Can the "public" modifier be applied to value operations? What is the default?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can the "public" modifier be applied to value operations? What is the default?
    In the Java mapping example on page 6-64 the operations are mapped to
    public operations of the Java class. However in the C++ mapping example on page
    7-95, the operations are mapped to protected pure virtual functions of the generated
    C++ class.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Minimum CORBA and POA

  • Legacy Issue Number: 2676
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Minimum CORBA submission describes exactly what should
    be present in minimum CORBA (basically CORBA 2.2 including
    the POA) in IDL/PIDL.

    However, the Java language mapping in CORBA 2.2
    does not include the POA -> just the APIs for registering
    transient objects.

    One cannot even take recourse to CORBA 2.3 to get the
    language mapping, since much stuff (OBV, Java to IDL etc.)
    was added in the intervening time. There does not seem to be
    any existing document which documents a Java language mapping
    of CORBA 2.2 including POA without lots of other stuff.

  • Reported: CORBA 2.3 — Mon, 31 May 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no typecodes for abstract interfaces. Does this mean
    that abstract interfaces cannot be members of structs, unions,
    or values? If so, I think this is a problem and we should add
    typecodes for abstract interfaces.

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The issue comes from the following configuration:

    Client - Tcp Firewall - Giop Proxy Server - Server

    The server"s IOR will contains a FirewallComponent, which includes two
    FirewallMechanisms - a TcpFirewallMechanism and a GIOPProxy. The issue
    comes when the GIOP Proxy has multiple profiles, which may have different
    host/port, and the TcpFirewallMechanism can only have one host/port. Does
    that mean for any host/port specified in one of the GIOP Proxy "s profiles,
    you always to connect to the host/port specified in the
    TcpFirewallMechanism? This seems unrealistic since the Tcp firewall usually
    provide a one-to-one mapping.

  • Reported: CORBA 2.2 — Wed, 13 Jan 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The submission makes no mention of HTTP tunnelling. There are many
    firewalls which filter HTTP, FTP and email related traffic. Is the
    omission based on the assumption that such firewalls will comprise
    a CORBA conformant GIOP proxy on a well-known IIOP port? The Bi-
    directional GIOP specification suggests not (section 5-1,
    paragraph 2).

    Is tunnelling regarded as an implementation matter? If so there
    will be important issues such as relaxing GIOP/HTTP mapping and
    security which the specification should clarify.

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

How can we bound the range of invoke ids in the IDL?

  • Legacy Issue Number: 2589
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: How can we bound the range of invoke ids in the IDL? Q773 requires
    invoke ids in the range -128 to 127. ROS has no limits.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

It should be possible to have negative invoke ids

  • Legacy Issue Number: 2590
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It should be possible to have negative invoke ids.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Problem: Why is AssociationId a string?

  • Legacy Issue Number: 2592
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: Why is AssociationId a string? Should one explore the possibility of
    using a combination of values supplied by both the initator and responder.
    Strings do not seem to be the most scalable solution.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section number: 4.2.1

  • Legacy Issue Number: 2591
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: It is not necessary to have uniqueness of Invoke Ids within a dialog.
    The invoke id can be reused as soon as it is no longer active.

    Proposed solution: Put in text following the discussion of management of invoke
    ids in the TC spec.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

The current text for DialogFlowCtr is for outgoing only

  • Legacy Issue Number: 2593
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.1

    Problem: The current text for DialogFlowCtr is for outgoing only. It should be
    updated to reflect incoming messages from the legacy domain.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:57 GMT

Section 4.3.2.1 Title and text should be changed

  • Legacy Issue Number: 2595
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.3.1.2

    Problem: Title and text should be changed to reflect that it is dealing with creating
    an association rather than initiating a dialog.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

There is a difference between the responder and initiator interfaces

  • Legacy Issue Number: 2594
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.2.2

    Problem: There is a difference between the responder and initiator interfaces
    because the initator cannot support the new association operations.

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section 4.7.1: RelativeRoundTripPolicy

  • Legacy Issue Number: 2596
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 4.7.1

    Problem: Is it necessary to indicate that RelativeRoundTripPolicy is not
    propogated to the server? Also does TC interworking require the support of the
    priority policies?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section number: 5.2 and other sub-sections

  • Legacy Issue Number: 2598
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.2 and other sub-sections

    Problem: The encapsulation BerData could potentially hold ASN.1 encoded via
    other rules like PER. So is this name misleading, or too restrictive?

    Proposed solution: One choice is EncodedData.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section number: 5.4.1

  • Legacy Issue Number: 2599
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.1

    Problem: DialogPortion should be a union rather than a struct. The complete IDL
    is correct.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Shouldn't it be typedef string CORBA::ScopedName?

  • Legacy Issue Number: 2600
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 7.1, page 108

    Problem: Shouldn’t it be typedef string CORBA::ScopedName?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section number: Fig. 27

  • Legacy Issue Number: 2601
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: Fig. 27

    Problem: Shouldn’t GwTcPduHandler be replaced by GwTcPduProvider?

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Problem: There is no way to send dialogue data in a continue confirm.

  • Legacy Issue Number: 2605
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5.4.4

    Problem: There is no way to send dialogue data in a continue confirm.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section number: 5

  • Legacy Issue Number: 2606
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: There is no way to associate more than one instance of a TcPduUser
    with a GT/AC pair for incoming SS7 messages.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Firewall POA Policy does not control access

  • Legacy Issue Number: 2639
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In orbos/98-07-03 4.9 it says "However, it is desirable to provide a
    portable means by which the object implementor can decide whether an
    object could be accessible through a firewall. The following POA
    policy is defined for this purpose:" but this policy can at most
    control what components are included in references created by the
    POA. Since the references do not have any mechanism to defend against
    forgery, exclusion of a FirewallMechanism component does not prevent
    access through a firewall. If an attacker obtains some other reference
    with the FirewallMechanism component(s), it can convert a reference
    created under NO_EXPORT into the reference that would have been
    created under EXPORT.

    The description of the policy needs to be changed to make it clear
    that the policy does not imply any access control enforcement. The
    ability of an attacker to forge references, either by combining parts
    of other references, or otherwise, should be explicitly stated as a
    security issue that must be addressed by means outside this
    specification.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section number: 2.3

  • Legacy Issue Number: 2607
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Use UML to express relationship of interfaces.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

new_target

  • Legacy Issue Number: 2648
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.7.4 - description of new_target operation.

    The first para states:

    "The new_target operation informs the firewall that it should prepare itself
    to
    receive requests destined for the specified target. The object returned
    from this
    operation is the destination on the firewall to which a request on the
    target should be
    sent i.e. the object_key in the return object should be used in the GIOP
    request header."

    and the last para says:

    "The object returned by the new_target operation must contain an object key
    which
    allows the proxy to uniquely identify the target. A client is not required
    to open a new
    connection to the proxy server, even when the target object(s) are located
    in different
    servers."

    The last sentence implies that the IOR returned from the new_target has the
    same host/port number as the GIOPProxy. This may not be true. For example if
    a firewall is load balancing across ports and network interfaces, the
    host/ports may be differnt, and in this situation a new connection is
    required.

  • Reported: CORBA 2.3 — Mon, 10 May 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

new_callback

  • Legacy Issue Number: 2651
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: OMG document orbos/98-07-03, section 4.7.4 under new_callback page 4-16,
    the first paragraph reads

    When the client side object adapter creates the object reference for the
    callback object, it may invoke the
    new_callback operation on the outermost inbound GIOP Proxy on the server
    side and pass the callback object as the argument.

    Say, there are no client-side firewalls and there is only one
    server-side GIOPproxy firewall.

    1. how does the object adapter or the client orb get access to the IOR
    of the GIOPProxy object ???
    2. how does the object adpater know that the object that is being
    created/instantiated will be used as a callback
    object ??

    Does POA provide any m

  • Reported: CORBA 2.3 — Thu, 13 May 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Proxified object references

  • Legacy Issue Number: 2865
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Proxified object references obtained by invoking
    new_target() should not be passed between ORBs. Instead the original IOR
    containing the target and firewall information should be passed. The reason
    for this is that the IOR does not contain enough information to inform the
    second ORB whether or not it is a reference for a NORMAL or PASSTHRU
    connection, or whether it is a proxified reference at all. This issue is
    very tightly related to issue 2, so we will describe how it fails for each
    of the possible solutions to the PASSTHRU establishment problem outlined in
    issue 2.
    One solution for which this is not an issue is the solution
    of using a port per target. However, this is not a viable solution because
    it is restrictive and will fail under moderate load. For solution 1 we
    don"t have a problem because no object reference is returned by
    set_target(), therefore it cannot be passed to other ORBs. For solution 2
    we have a problem because the second ORB won"t know whether it is supposed
    to first invoke start_passthru() or simply start making requests. Therefore
    it may get a connection type that it wasn"t expecting. For solution 3 we
    have a problem because once the original connection has been made, the
    reference is invalid. This occurs because the firewall does not have
    knowledge of how many clients are expected to try to connect to that target,
    and it may attempt to claim that port for reuse before another client has
    connected.

    Proposed Solution:
    The passing of object references obtained by invoking
    new_target() should be expressly prohibited by the specification. One
    example is, "The object reference returned by new_target() may not be passed
    to another client. Instead the original reference that was passed as the
    argument to new_target() must be passed to the second client, and the second
    client will follow the rules of the traversal algorithm to reach the desired
    target."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

How to obtain initial reference to the GIOPProxy object

  • Legacy Issue Number: 2864
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    The specification does not outline a specific method by
    which to obtain the initial reference to the GIOPProxy object. We believe
    that an interoperable solution for obtaining this initial reference is
    needed in order to insure that all implementations will be able to be
    correctly configured to contact all other implementations.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Reusing PASSTHRU

  • Legacy Issue Number: 2866
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Reusing PASSTHRU connections by the firewall should be
    expressly disallowed by the specification. With the current wording of the
    specification, a vendor may attempt to reuse PASSTHRU connections. While
    this will work in some cases, it is not interoperable because there are
    cases when reusing PASSTHRU connections will not work. For example,
    connection reuse when SSL is in use will not work because all of the
    information that distinguishes data streams is contained within the
    encrypted portion of SSL packets. If two SSL connections try to share a
    single connection, there will be an SSL protocol failure because the server
    will not be able to separate the data streams before it processes the SSL
    packet.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Clarification is needed on the passing of credentials

  • Legacy Issue Number: 2867
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    Clarification is needed on the passing of credentials.
    Section 4.7.3 states that "Since all proxies will have access to the IOR of
    the target object, and the certificate of the client, they can judge whether
    this client may use a pass-through connection or not." Section 4.12 states
    that "When a client establishes a normal connection to a target via a
    trusted proxy and uses a secure transport (e.g. IIOP/SSL), in order to
    achieve end-to-end authentication, the proxy will have to forward the
    client"s certificate/identity to the server." Section 4.12 implies that the
    ForwardedIdentity service context will only be used when using a secure
    transport, but section 4.7.3 implies that the client certificate will always
    be available. In fact, the ForwardedIdentity service context should only be
    used in the case of a NORMAL connection using a secure transport because
    those are the only conditions under which there is a notion of trust between
    a requestor and the recipient of that request. This means that the only
    mechanism upon which to base a decision of whether or not to allow a
    PASSTHRU connection is the source host address/port.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Problems with routing and/or traversal of firewalls.

  • Legacy Issue Number: 2868
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issues 7-9 refer to problems with routing and/or traversal of firewalls.
    These problems arise due to a lack of required information about firewall
    topology in the IOR. Most of these problems could be eliminated if it were
    required that the servers place the entire chain of server-side firewalls
    that must be traversed into the IOR. Specifically, the first paragraph in
    section 4.8 should be modified so that the entire chain of firewalls is
    always required, or those situations in which it should be required should
    be stated. Some of those situations are outlined in the following issues.
    Specifically, it is incorrect to state that "strictly it is only necessary
    to convey information on the outermost inbound firewall."

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Use of InvokeId as the type name for both invoke id and link id.

  • Legacy Issue Number: 2915
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The idl is

    struct TcLinkedContext

    { DialogFlowCtr ctr; InvokeId ivk_id; InvokeId lnk_id; AssociationId a_id; }

    ;

    While it is correct that these are both of the same type, the name of the type
    could be confusing.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

When does a multiassociation TcUse know that it has been finished with?

  • Legacy Issue Number: 2916
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The creation of a TcUser interface with multiple associations does not have
    a standardised way for destruction.

    Proposed solutions

    1. Add a destroy() method to TcUser
    2. Explicitly state in the RFP that the CosLifeCycle::destroy() method should
    be called once the object is no longer required.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Why one to one association between a TcPduUser and TcPduProvider interface?

  • Legacy Issue Number: 2917
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    There is an assumption in the design that there is a one to one
    association between a TcPduUser and a TcPduProvider
    during a TC Session. This is enforced in the IDL through the
    call

    TcPduProvider::get_dialog_id()

    and the factory call

    TcPduProvider create_tc_pdu_provider(
    in TcPduUser user,
    out DialogId d_id)
    raises(NoMoreDialogs);

    Since the TcPduUser reference (or some sort of reference)
    is not passed over in get_dialog_id(), the only conclusion
    is that the reference has to be the one passed over in the
    create, and therefore that each TcPduProvider is tied to
    one and only one TcPduUser.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    The Specification Translation from ASN to IDL does not appear to
    require that each OPERATION carries a NoMoreAssociations exception.

    This is necessary if the use of DialogFlowCtr can implicitly create a new
    association during a call on an object that supports multiple associations.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: open  
  • Source: Ericsson ( Neill Jones)
  • Summary:

    As the interfaces currently stand, there is a minimum of 5 CORBA calls
    per transaction
    1. either TcPduProvider::get_dialog_id
    or TcPduProviderFactory::create_tc_pdu_provider
    2. TcPduProvider::invoke_req
    3. TcPduProvider::begin_req
    4. TcPduUser::end_ind
    5. TcPduUser::result_l_ind

    Given that a CORBA call is about 1 millisecond on average,
    this makes for a highly inefficient interface from a high-performance
    perspective,
    and renders the distribution of these interfaces undesirable, and the
    use of the TcPduProvider/User interfaces unlikely in a real system.

    Ideally this should be reduced to a minimum of 2 CORBA calls, one for a call
    going out, and one for the reply.

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

use of the SSN number in the 1988 TCAP version

  • Legacy Issue Number: 2982
  • Status: open  
  • Source: Anonymous
  • Summary:

    As far as I can see when using the 1988 TCAP version the submission
    does not seems to handle the case where the subsystem number (SSN) is
    used to seperate between several TC-User protcols per GT (typically
    protocols from different vendors). The naming tree proposed for the
    1988 TCAP protocol can only store one TC-User protocol per GT, that is
    only one DefAc per GT can be stored (see section 4.3.1.1 in the
    proposal).

    The use of the SSN number for this purpose is explained in chapter
    4.2.3 in the second paragraph in the ITU Recommendation Q.775.

    It should be easy to fix this as one only have to use the same naming
    tree structure proposed for the 1993 TCAP version in these cases.

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Firewall FTF Issue: No ene-to-end security for firewall traversal

  • Legacy Issue Number: 7313
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The title of Section 1.7, End-to-End Secure Connection, is misleading. There is no end-to-end security in the firewall traversal spec. All security mechanisms described in this spec are essentially mechanisms between a client, firewalls, and a server, not end-to-end. Thus, it is susceptible to the man-in-the-middle attack.

    I'm saying we should fix the problem, but the title of this section and the caption of Figure 1-4 is certainly misleading. Besids, if the firewall traversal scheme described in the spec is actually susceptible to the man-in-the-middle attack, we may want to consider stating it somewhere in the spec rather than making people have a wrong impression that it is secure

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Which model should ConcurrencyControl support?

  • Legacy Issue Number: 577
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is inconsistency regarding which model ConcurrencyControl needs to support

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Circular refrences to CosStream and CosCompoundExternalization,
    i have not been able to find an idl compiler that can compile
    these modules.

    as aside, i have foud many syntax errors in the IDL you provide
    as CORBAServices98-03-02.idl, in many of its interfaces, there are
    typos, and it is not correct with the specifications.

  • Reported: CORBA 2.2 — Mon, 1 Jun 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Who is responsible for releasing locks in transaction?

  • Legacy Issue Number: 578
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In lock duration of Section 7.1 there are two descriptions. The role of the clients is vague to me

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

interface QueryEvaluator {

  • Legacy Issue Number: 575
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I understand the params to be name value pairs of columns and the values for the
    selection, update, delete, insert criteria
    what is in the query? I would think if this is the whole query why would you
    need the params??

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

CosConsurrencyControl service bug or not?

  • Legacy Issue Number: 3522
  • Status: open  
  • Source: Anonymous
  • Summary:

    I develop CosConcurrencyControl service for JacORB, but I don't
    understud from specification how client can destroy LockSet.
    When I create Object which allow concurrency access, I create LockSet.
    When I destroy this Object I must destroy LockSet, because it's garbage,
    bu no way for this does not exists.

    As solution of this problem, I add in CosConcurrencyControl.idl next
    changes:
    exception LockExists{};

    and method
    void destroy raises (LockExists);

    in interface LockSet.

    As I undestand this changes is wrong, but have you idea about desigion
    this problem.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: in section 4.9.2 last paragraph:

    "Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
    interface I. Any event on the channel that does not correspond to an
    operation defined in interface I is NOT passed on to the consumer. Such a
    ProxyPushSupplier is therefore an event filter based on type".

    My question is: if we have this proxy to block generic calls (push() in this
    case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
    support push() ? Why should the generic calls like push() be blocked anyway
    if (according to 4.7.1) TypedPushConsumer should support both typed and generic
    models ?

    Is there something I am misunderstanding ?

  • Reported: CORBA 2.2 — Thu, 5 Feb 1998 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a bit of confusion in the specification concerning the
    exceptions that are possible during the internalization process.

    The internalize operation can raise CosLifeCycle::NoFactory and
    StreamDataFormatError exceptions. This operation calls the
    internalize_from_stream operation of the Streamable interface that can
    raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
    ObjectCreationError exceptions.The last paragraph on page 8-20 (August
    1997 release) states that the ObjectCreationError and
    StreamDataFormatError exceptions of the internalize_from_stream
    operation originate from the read_object amd read_<type> operations on
    the StreamIO interface. However, the ObjectCreationError is not raised
    by any of these, according to the IDL in figure 8-6.

  • Reported: CORBA 2.2 — Thu, 30 Apr 1998 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Issue on Document orbos/2000-08-04, CSIv2 Joint Submission

    Document: orbos/2000-08-04, CSIv2 Joint Submission
    Subject: Identity Assertion of X.501 Distinguished Name is not good enough
    Severity: Critical

    Summary:

    The Identity Token union contains a branch that is labled
    X501DistinguishedName. A single DN is insufficient to identify an entity.
    A path of X501Distinguished Names is needed instead. Also, other concerns
    about naming types are raised.

    Discussion:

    An X.501 Distinguished Name is insufficient to identify a single entity.
    The name must be accompanied by the name of its defining authority. In the
    case of public key certificates, the names certificate authority must be
    included.

    The chain of DNs in this manner must be included up to a root authority
    to have any definitive meaning.

    This approach will be consistent with the client sending a X.509
    Certificate Chain. A DN path is actually defined by the certificate chain.

    Furthermore, the DN path should only come from an authority that is
    acceptable to the server, whether it be a DN path, or an X.509
    Certificate Chain.

    The IOR should list the acceptable authorities and their name types.

    It is becoming more an more evident that we must invent GSS_NT_Export_Name
    types for X.509 Certificate Chain and X.501 DN path.

    The SAS_ContextSec structure should list, instead of the naming types,
    the naming authorities!

    We shall assume that the name types of the asserted identities shall be
    the same as the name types of listed naming authorities in the IOR.

    This is the only way this procedure can work Interoperable and without
    the client Guessing what it should do.

    Suggestions:

    An OID for an X.509 Public Key Certificate Chain shall be defined for a
    GSS Export Name, and its encoding will be a ASN1 sequence of and X.509
    certificate with the least significant certificate first.

    An OID for an X.501 Distinguished Name Path shall be defined for a GSS
    Exported Name, and its encoding shall be an ASN1 sequence of an X.501
    Distinguished Name with the least significant name first.

    To avoid having the target put a whole certificate chain in its IOR,
    a new OID shall be allocated in which its GSS Exported Name encoding is a
    X.501 DN path, but stipulates that the client should send a certificate
    chain from that named authority. This GSS Exported Name shall only be
    used in IORs and not for transmission in the Identity Token.

    typedef Security::GSS_NT_ExportedName NamingAuthority;

    struct CompoundSecMech

    { Security::AssociationOptions target_requires; IOP::TaggedComponent transport_mech; sequence<ServiceConfiguration> privilege_authorities; sequence<NamingAuthority> naming_authorities; }

    ;

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section: 4.2

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

    The is an error in the ServiceDetail struct. service_detail is listed twice, the first one should be removed. struct ServiceDetail

    { ServiceDetailType service_detail_type; sequence <octet> service_detail; ServiceDetailData service_detail; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section: 4.2 (02)

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

    Struct ServiceInformation is wrong, the sequence<> lines should be removed. struct ServiceInformation

    { sequence <ServiceOption> service_options; ServiceOptionSeq service_options; sequence <ServiceDetail> service_details; ServiceDetailSeq service_details; }

    ;

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA35-9
  • Legacy Issue Number: 679
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Section 4.1.18.6 Table 4-14: A few of these mappings don"t seem to make sense (i.e. the meaning of the different exceptions in each object system is much different

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Capter 13C: Editorial

  • Key: CORBA35-8
  • Legacy Issue Number: 709
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: There are a bunch of code samples that use a different font than the rest of the document

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section 13A.2.3: editorial

  • Key: CORBA35-7
  • Legacy Issue Number: 707
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Example of "on both machines" does nor correspond to the diagrams. Add "on an intermediate machine" to sentence

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Section 13A.5.2: Editorial

  • Key: CORBA35-6
  • Legacy Issue Number: 708
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Third bullet should read:"...are sorted based upon interface name.." Last bullet should read "..the operations introduced in the current interface are mapped last and ordered.."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Duplicate union labels

  • Key: CORBA35-4
  • Legacy Issue Number: 704
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: When multiple union labels resolve to the same union member, the property accessor for that union member has an additional (optional) argument

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Changes to ForeignComplexType

  • Key: CORBA35-5
  • Legacy Issue Number: 701
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: The following methods should be added to DIForeignComplexType, IID should be changed: string type_name(); string scoped_name(); string_repository_id(); more details in corresponding archive file

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Wed, 26 Jun 2024 00:56 GMT

Inconsisten IDL in the Minimum CORBA chapter

  • Legacy Issue Number: 4216
  • Status: open  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
    complete IDL for a minimumCORBA implementation. However, the text in
    the chapter and the IDL are inconsistent, for example, section 23.4.2
    reads:

    ------------------------------------------------------------------------
    ---------------
    The is_a operation is omitted so as not to introduce a requirement
    either for holding

    detailed type information in the object reference or for getting type
    information over

    the wire. Instead, minimumCORBA relies on design time resolution of type
    checking

    issues.

    The non_existent operation is omitted, because of the design philosophy
    of making

    more decisions statically at design time.

    The create_request operation is omitted, as the Dynamic Invocation
    Interface is

    omitted.

  • Reported: CORBA 2.4.2 — Sat, 3 Mar 2001 05:00 GMT
  • Updated: Wed, 12 Jun 2024 21:24 GMT

The CCM document component-formal-21-02-04 shall be removed from CORBA 3.4 to become a standalone CCM specification.

  • Status: open  
  • Source: Objective Interface Systems ( Mr. Chuck Abbott)
  • Summary:

    The component-formal-21-02-04 for CORBA 3.4 part 3 will be moved to its own separate specification.

  • Reported: CORBA 3.4 — Thu, 28 Mar 2024 17:17 GMT
  • Updated: Wed, 12 Jun 2024 20:43 GMT

Ordering of user exception and return values

  • Legacy Issue Number: 16
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The COM/CORBA Part A spec states that user exceptions go after return values in one place, and before return values in another. (3.2.10.3 and 4.1.3.1)

  • Reported: CORBA 1.2 — Fri, 14 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Standard uuid for interfaces (COM/CORBA Part A)

  • Legacy Issue Number: 680
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Standard ProgramId

  • Legacy Issue Number: 684
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

VB cannot handle array out-parameters

  • Legacy Issue Number: 682
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The VB cannt handle array out-parameters. Must use in-outs.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Section 4.1.12: DICORBA TypeCode::kind

  • Legacy Issue Number: 685
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Remove EX_repositoryID readonly property from IForeignException

  • Legacy Issue Number: 686
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Return value type of DICORBATypeCode::member_type should be changed

  • Legacy Issue Number: 688
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation

  • Legacy Issue Number: 2586
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 3.5.1.1, item 4 plus appropriate section of interaction translation

    Problem: How to handle the sending of an empty RESULT and the reception of
    such a component.

    Proposed solution: Obviously no way to change the IDL from void. Need
    something in the TC Repository for use by a gateway in deciding what to do.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Dispatch versions of DCORBAObject and DORBObject

  • Legacy Issue Number: 699
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be straight dispatch versions of DCORBAObject and DORBObject

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Correction of CORBA specification (page 18-51)

  • Legacy Issue Number: 3342
  • Status: open  
  • Source: Anonymous
  • Summary:

    >You write on page 18-51:
    >In COM V2.0, interfaces can have single inheritance. However, as opposed to
    >CORBA,
    >there is a standard mechanism by which an object can have multiple interfaces
    >(without
    >an inheritance relationship between those interfaces) and by which clients can
    >query
    >for these at run-time. (It defines no common way to determine if two interface
    >references refer to the same object, or to enumerate all the interfaces
    >supported by an
    >entity.)
    >
    >It's not right, that there's no common way to determine if two interface
    >references refer to the same object. The IUnknown-Pointer of two different
    >interfaces of the same object must be the same (object identity in COM).

  • Reported: CORBA 2.3.1 — Tue, 22 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Section number: 3.5.1.1, item 3

  • Legacy Issue Number: 2588
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue: 5

    Section number: 3.5.1.1, item 3

    Problem: We have mistakenly associated TcLinkedContext with the operation
    which has the LINKED keyword rather than the actual linked operation, i.e., the
    operations appearing following the LINKED keyword

  • Reported: CORBA 2.3 — Mon, 12 Apr 1999 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
    deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
    This tool mangles the following identifier (not necessarily a complete list) by
    prepending them with "_":

    "BSTR", "CALLCONV", "coclass", "CY",
    "CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
    "dual", "EXCEPINFO", "guid", "GUID",
    "HRESULT", "importlib", "IDispatch",
    "INTERFACEDATA", "IUnknown", "LCID",
    "METHODDATA", "odl", "oleautomation",
    "PARAMDATA", "properties", "propget", "propput", "retval",
    "SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
    "VARIANT", "VARIANTARG", "VARIANT_BOOL",
    "VARTYPE", "VARENUM"

    As far as I can tell, the output of the "mktyplib" tool makes use
    (directly or indirectly) of the regular C++ bindings, whose identifiers
    are not mangled the same way. This makes it impossible to emit COM bindings
    for IDL files that contain the above keywords.

    The problem that I"m running into is in CosTrading IDL, where the identifier
    "properties" is used.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Fixed Types in COM

  • Legacy Issue Number: 4507
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

  • Reported: CORBA 2.4.2 — Fri, 17 Aug 2001 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

COM Sequence changes

  • Key: CORBA35-3
  • Legacy Issue Number: 703
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: Change the layout of both bounded and unbounded sequences to be the same

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Levels of Indirection for passing COM types seem to be missing

  • Key: CORBA35-1
  • Legacy Issue Number: 702
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

What should Automation View accept in bounded sequences?

  • Legacy Issue Number: 683
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When mapping bounded sequences, should the Automation View accept as an in-parameter a Safearray whose upper bound is less than the maximum lenght of the mapped sequence?

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

uuid for DForeignException has an extra 0

  • Legacy Issue Number: 689
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

Page 2-41, section 2.9.7.2 Add name for Automation View interface

  • Legacy Issue Number: 692
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There should be a standard name for the Automation View interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 2-25 contradicts first sentence of 3rd full para on p 4-106

  • Legacy Issue Number: 690
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I suggest that the automation chapter be changed to align with the architecture chapter

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

boundary violations should cause View to propagate DISP_E_OVERFLOW

  • Legacy Issue Number: 695
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 4-109, section 4.1.5.3: editorial

  • Legacy Issue Number: 694
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:15 GMT

page 4-129, section 4.1.17.1: retval attribute

  • Legacy Issue Number: 696
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

page 4-129, section 4.1.17: change term "CORBA proxy"

  • Legacy Issue Number: 697
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

INSTANCE_Clone does not need an in-parameter

  • Legacy Issue Number: 698
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Section number: 3.3.4 and elsewhere

  • Legacy Issue Number: 2584
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: There is a general problem on how to specify sending an empty
    Transaction PDU, such as an empty BEGIN, or an empty CONTINUE. "Empty"
    means just the Transaction portion without ROS components. This problem has
    to be addressed for sending an empty Transaction PDU from the CORBA side,
    as well as what to do when such a PDU is received from the legacy domain.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

  • Legacy Issue Number: 700
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If number of dimensions of an input SAFEARRAY does not match the mapped CORBA type, the Automation View should generate the HRESULT DISP_E_TYPEMISMATCH

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Shouldn't this section really be called TC Service Interface?

  • Legacy Issue Number: 2597
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 5

    Problem: Shouldn’t this section really be called TC Service Interface because it
    really provides an IDL version of Q.771? Note that this requires changing the
    names of various interfaces by removing the word Pdu, which should be
    reasonably simple.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Should SIOP version number start with 1.2?

  • Legacy Issue Number: 2603
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.1

    Problem: Should SIOP version number start with 1.2?

    Proposed solution:

    Rationale: This would allow a quick recognition of the highest GIOP version supported by
    this version of SIOP.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Could SIOP be changed to 7IOP, pronounced "seven-up"?

  • Legacy Issue Number: 2602
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6

    Problem: Could SIOP be changed to 7IOP, pronounced "seven-up"?

    Proposed solution:

    Rationale: The S in SIOP may be mistaken for Security.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: open  
  • Source: Siemens AG ( Nils Fischbeck)
  • Summary:

    Align SIOP definition with GIOP 1.3 of CORBA2.3.1.

    Problem: SIOP is currently defined to carry GIOP messages with version 1.2
    and lower.

    Proposed Solution: Allow GIOP 1.3 messages to be transported.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Section number: 6.2.2

  • Legacy Issue Number: 2604
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section number: 6.2.2

    Problem: sccp_version should be changed to SIOP_version. Also the word
    "agent" should be changed to "server."

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: open  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:

    There are security tags mentioned in the SIOP
    document but no definition of how to use them is ever given.

  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: open  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    While editing the changes from the Firewall RTF into Core Chapter 15 I noticed a
    curious thing in the Firewall RTF report. It seems that the RTF chose to re-use
    a PolicyType id for a new and different policy while obsoleting a published one.
    The PolicyType Id in question is 37, which used to be BIDIRECTIONAL_POLICY_TYPE
    associated with the structure BiDirPolicy::BidirectionalPolicy

    and is now proposed to be BIDIRECTIONAL_INVOKE_POLICY associated with structure
    BiDirPolicy::InvokeMode.

    This appears to me to be a dangerous practice, since the fact that the published
    standard may have been implemented by someone using the obsolete definition.

    I would like to suggest that the recommendation of the Firewall RTF be modified
    leaving the published policy type and policy as is with a note stating that it
    is obsolete, and a new policy type id be allocated for
    BIDIRECTIONAL_INVOKE_POLICY.

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Lifecycle Key type definition

  • Legacy Issue Number: 18
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Several LifeCycle methods take a "key" argument, but do not clarify whether multiple NameComponents are allowed in a key, if ordering matters, etc.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Stream contexts and internalization

  • Legacy Issue Number: 19
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Externalization spec does not state how a stream implementation is to discover that a context exists when internalizing an object.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Start and end of context tags

  • Legacy Issue Number: 20
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream data format does not define tags to be used to identify the beginning and end of a context.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Definition of stream portability

  • Legacy Issue Number: 21
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The standard stream format should specify that it is portable across different ORBs and hardware, but not across streamable object implementations whch use different semantic content.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Multiple objects on a stream

  • Legacy Issue Number: 22
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What happens when multiple calls are made to Stream::externalize() at the top level? Does the stream contain all those objects, and how does a client discover this?

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Timeout while locking

  • Legacy Issue Number: 47
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB times out while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 2 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Communication failure issue

  • Legacy Issue Number: 56
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If the ORB suffered a communication failure while LockSet::lock() is being called, how does the client know if the lock was granted or not?

  • Reported: CORBA 1.2 — Tue, 23 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Getting the thread ID in a non-transactional lock request

  • Legacy Issue Number: 57
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In a non-transactional lock request, the lock identity is supposedly based on thread ID. How can the server code get the client thread ID when they may be on different machines?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Freeing of locks at the end of a transaction

  • Legacy Issue Number: 58
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear whether CosTransactions::Coordinator is responsible for freeing locks at the end of a transaction.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Coordinator remembering LockCoordinator

  • Legacy Issue Number: 59
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: CosTransactions Coordinator does not have any IDL method to remember LockCoordinator. How does it know what Lock Coordinators should be informed to drop locks?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Input values for "which" arg of non-trans. LockCoordinator

  • Legacy Issue Number: 60
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: For a non-transactional client who wants to get a LockCoordinator, what input values should one use for the "which argument?

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Using local thread identification for concurrency

  • Legacy Issue Number: 61
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It seemed more useful for the concurrency service to be non-IDL, and just based on local thread identification.

  • Reported: CORBA 1.2 — Wed, 24 Jul 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Common format on stream

  • Legacy Issue Number: 466
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When reading a stream, there is no way of telling where context (limited to calls to begin_context and end_context) end and a new one starts.. Resolved problem with new "tag-byte" 0xFF.

  • Reported: CORBA 1.2 — Thu, 19 Dec 1996 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosGraphs::deep

  • Legacy Issue Number: 469
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: If CosGraphs::deep propagation value is encountered, is the Node"s related object supposed to get copied, too. What if LifeCycleObject delegates to CosCompoundLifeCycle::Operations?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

performing a compound copy of relationship

  • Legacy Issue Number: 470
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The second pass of operation is to "cause the node and all of its roles" to be copied. How do you get related object of the NEW roles to be the New Node?

  • Reported: CORBA 1.2 — Fri, 3 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service

  • Legacy Issue Number: 476
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When Node::externalize_node is called, is node responsible for externalizing related object? What happens, if related object isn"t a CosStream::Streamable?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service (2)

  • Legacy Issue Number: 477
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Role in new node are disconnected It"s role of read_graph to correctly establish new relationships. How is that accomplished?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

CosCompoundExternalization Service (3)

  • Legacy Issue Number: 478
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When internalizing a relationships, how do the "shallow" nodes and roles get included?

  • Reported: CORBA 1.2 — Tue, 21 Jan 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

  • Reported: CORBA 2.1 — Mon, 25 Aug 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Purpose of related LockSet

  • Legacy Issue Number: 576
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the specification, "Related lock sets" appears only in "create_related()" and create_transaction_related()" Where do I use these methods

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- membership scoping

  • Legacy Issue Number: 3
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I assume that we are allowed to scope membership in a collection via an interface test (e.g, must be rooted off of Collection) and throw an InvalidElement exception?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- Adding multiple elements

  • Legacy Issue Number: 4
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Using collection factories, can you add multiple elements at once, and/or add new create methods?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- finding index

  • Legacy Issue Number: 6
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: On CollectionObj->remove_element_at(IteratorRef), how does the collection "know" the index?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Query Collection::Collection -- Sharing State

  • Legacy Issue Number: 5
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How do IteratorObjs and CollectionObjs share state?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- Iterator Position Invalid

  • Legacy Issue Number: 7
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What does the IteratorPositionInvalid exception mean? Is it only that the user has cycled through the list elements and that no reset() has been issued?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- iterator updating

  • Legacy Issue Number: 8
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How does the Iterator know to become invalid when the Collection is altered?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- reset() exceptions

  • Legacy Issue Number: 10
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can an iterator "reset()" throw an exception such as IteratorPositionInvalid if it is wrapping a db cursor which has no facility for reset?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- destroy methods

  • Legacy Issue Number: 9
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Where are the destroy methods on the Iterator or on the Collection?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- next_n()

  • Legacy Issue Number: 11
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can an interator have a next_n()? Or is this supposed to be via subtyping the interface?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

QueryCollection::Collection -- keyed collections

  • Legacy Issue Number: 12
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is it correct to offer the vanilla collection methods and add a new set for keyed access?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Questions on CosQuery::QueryableCollection interfaces

  • Legacy Issue Number: 13
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Clarifications on interfaces which support QueryableCollection.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Updating information via query iterators

  • Legacy Issue Number: 69
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When using iterator operations like adding, inserting, etc., how are changes reflected back to the datastores?

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Use of MD5 on arguments

  • Legacy Issue Number: 23
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Appendix D states that a challenge structure consists of the MD5 of the arguments, but does not specify how the arguments are laid into a stream of octets for the MD5 algorithm.

  • Reported: CORBA 1.2 — Wed, 26 Jun 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

How do iterators handle changing of the data they are pointing at

  • Legacy Issue Number: 78
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is it not possible that objects in a collection could have changed in between calls to the iterator accessing them?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Clarification request for section 11.1.5

  • Legacy Issue Number: 79
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Several of the bullets in section 11.1.5 are unclear.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

retrieve_element

  • Legacy Issue Number: 81
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: How does this operation work?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Definition of NULL in datafiles without NULL as a concept

  • Legacy Issue Number: 80
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 11.4.2 para. 3 says that FieldValues may be NULL. What if my datastore is a flat file without a concept of NULL. Does NULL take on the value of empty string for flat files?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Delegating iterator functionality to the RDBMS

  • Legacy Issue Number: 82
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Is there a way that I can delegate the functionality of the Iterators to the RDBMS itself?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Query language for operations

  • Legacy Issue Number: 83
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Need all operations on the Collection be made using the SQL-92/QOL-93? If so, how is it possible to handle flat file datastores?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

OQS relation to POS

  • Legacy Issue Number: 84
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Need the OQS have any interface with the POS? I don"t see how the two can be interfaced.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Malformed PropertyName

  • Legacy Issue Number: 284
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help

  • Reported: CORBA 1.2 — Sat, 19 Oct 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

WWW Form output

  • Legacy Issue Number: 535
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module

  • Reported: CORBA 1.2 — Thu, 6 Mar 1997 05:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Compiler being able to translate from OMG-IDL into ANSI

  • Legacy Issue Number: 184
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?

  • Reported: CORBA 1.2 — Mon, 14 Oct 1996 04:00 GMT
  • Updated: Sat, 13 Apr 2024 00:14 GMT

Change union API misuage exception

  • Key: CPP1117-36
  • Status: open   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In order to get a type system which is CORBA independent we propose to change the exception which can be thrown by the union from CORBA::BAD_PARAM to std::invalid_argument. The impact for users is minimal as they can except std exceptions from the other std types they already use through this language mapping.

  • Reported: CPP11 1.7 — Wed, 20 Mar 2024 15:06 GMT
  • Updated: Thu, 4 Apr 2024 15:09 GMT

Add CDR marshaling support for new IDL4 types (e.g. maps, bitset, 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: Thu, 28 Mar 2024 17:11 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: open  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Using the static invocation interfaces, it is possible to receive a
    valuetype that derives from the one declared in an operation, as long
    as a valuetype factory is known in the receiver (truncation is not the
    issue here).

    The same is not possible at the DII: When creating the request, the
    caller must indicate what type it expects, by forming a named value.
    Conceptually, the typecode in the named value should be the typecode
    of the base of all acceptable value types. However, if the ORB
    receives a derived type, it has no means of unmarshalling it - even if
    the application has knowledge about the derived type.

    What is missing is an interface to make typecodes of value types known
    to the ORB; with those, the ORB could then understand the CDR of the
    valuetype, and create a DynAny when asked to.

  • Reported: CORBA 2.3.1 — Wed, 7 Jun 2000 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the interaction between the
    DynValue interface and custom valuetypes.

    I frankly don't see any way that the DynValue interface can possibly
    correctly handle a custom valuetype when the ORB does not have a factory
    for the type. It is theoretically possible for DynValue to properly
    work with a known custom type, but the implementation strategy could not
    be based on parsing the marshalled form of the valuetype.

    So, there are two issues that need to be addressed:

    1. Should DynValue handle custom valuetypes at all?

    2. For the set of custom valuetypes that it cannot handle, what
    exceptions should be raised by each operations?

  • Reported: CORBA 2.3.1 — Sat, 25 Mar 2000 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: open  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    Due to the way that custom values are marshaled it is
    nearly impossible for a bridge (or other process) to
    process/forward GIOP messages which contain custom
    marshaled values (which the bridge has no compile/run-time
    knowledge of).

    The main issue is that the "alignment" of the
    custom marshaled data is unknown, other than the
    data will always start on a four byte boundry due
    to the presence of chunking.

    Should/could the value encoding format be changed to
    enforce eight byte alignment for all custom marshaled
    data (chunks)? This would allow bridges and other
    tools to process->[store]->forward messages containing
    custom values.

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

Potential deadlock with POA::deactivate_object()

  • Legacy Issue Number: 2772
  • Status: open  
  • Source: Anonymous
  • Summary:

    The draft CORBA 2.3 spec (ptc/99-03-07) does not deal with a potential deadlock situation. If an object is explicitly deactivated with POA::deactivate_object(), the object remains in the active object map until all operations pending on the object have completed. Any attempts to reactivate the object (implicitly via a ServantActivator, or explicitly via activate_object_with_id()) must block until the pending invocations have completed. However, if a servant's implementation of an object deactivates the object and then (directly or indirectly through a call to another collocated object) reactivates the object, the invocation will deadlock.

  • Reported: CORBA 2.3 — Mon, 28 Jun 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 19:59 GMT

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: open  
  • Source: Network Associates ( Brian Niebuhr)
  • Summary:

    I am a little confused as to the scope of the BiDirPolicy in the 2.4.1
    specification. Is the BiDirPolicy a POA policy, an ORB policy, or both? In
    section 15.8 paragraph 5 on page 15-55, the specification states:

    "If the client ORB policy permits bi-directional use
    of a connection, a Request message should contain an IOP::ServiceContext
    structure in its Request header, which indicates that this GIOP connection
    is bi-directional."

    but then in section 15.9 paragraph 4 on page 15-59, the specification
    states:

    "In the absence of a BidirectionalPolicy being passed in the
    PortableServer::POA::create_POA operation, a POA will assume a policy value
    of
    NORMAL."

    but then again in the next sentence the specification states:

    "A client and a server ORB must each have a BidirectionalPolicy with a value
    of
    BOTH for bi-directional communication to take place."

    Could someone clarify for me what the intent for the scope of the policy was
    here, and what the rationale behind that decision was? We are currently
    reviewing how to use/fix BiDirIIOP in our submission to the firewall RFP,
    and I would like to understand the issues regarding the scope of the BiDir
    policy.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Updated: Mon, 4 Mar 2024 19:16 GMT

Firewall Traversal algorithm

  • Legacy Issue Number: 2641
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The description of firewall traversal in orbos/98-07-03 4.11 has some
    significant unstated assumptions, and prescribes an algorithm that has
    several flaws.

    In orbos/98-07-03 4.11 it says: "A client will determine if it needs
    to go through a firewall to make a request on the target object. If
    the client is in the same domain a direct invocation can be made. The
    client can determine this be examining the host address information in
    the target IOR." This assumes that the enclave structure maps to host
    addresses in some way known to all clients. This needs to be made more
    explicit.

  • Reported: CORBA 2.3 — Fri, 7 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:57 GMT

Outgoing local port in Bi-directional IIOP

  • Legacy Issue Number: 2638
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 5.8.1 it says "If a client has not set up any mechanism for
    traditional-style callbacks using a listening socket, then the port entry
    in its IOR must be set to the outgoing connection"s local port (as
    retrieved using the getsockname() sockets API call)". At IOR creation time
    there may be no connection, or there may be many, so the mandated local
    port may be non-existent or ambiguous.

    This topic was discussed on the firewall-rtf list during Feb-Mar 1999 but
    was not raised as an issue.

  • Reported: CORBA 2.3 — Thu, 6 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:54 GMT

Bi-Directional GIOP: Masquerade security issue needs to be more explicit

  • Legacy Issue Number: 2634
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The remark about masquerade at the end of ptc/98-10-11 15.8 is not
    explicit enough. This is an important security issue and it needs to
    be made explicit that a malicious client may claim that its connection
    is Bi-Directional for use with any host and port it chooses, in particular
    it may specifiy the host and port of security sensitive objects.

    In general, a server that has accepted an incoming connection has no
    way to discover the identity or verify the integrity of the client
    that initiated the connection.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:54 GMT

Bi-Directional GIOP: which connections may be used?

  • Legacy Issue Number: 2633
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-10-11 15.8 from the end of the fourth paragraph "any
    requests from the server on an objects exported by the client to the
    server via this connection will be sent back to the client on this
    same connection." to the eleventh paragraph "If the client initiates a
    new connection it is not foreseen here that the server can use that
    connection for requests on the object exported previously." it seems
    to be implied that a reference must be passed via a connection if that
    connection is to be used to invoke the referenced object with
    Bi-Directional GIOP.

  • Reported: CORBA 2.3 — Wed, 5 May 1999 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:53 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:02 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec orbos/98-01-18 introduces a new repository ID
    mechanism. It says in 5.6.2.1

    >> We don"t recommand the classic id format "IDL:" <scoped name> ":"
    >> <major> "." <minor> because it is not "foolproof" enough. (It is of
    >> course allowable to use this format, since the CORE specification
    >> does not mandate any particular form.)

    The last sentence is not entirely correct, as 8.6.4 of formal/98-02-33
    specifies

    >> A definition is globally identified by an OMG IDL - format
    >> RepositoryId if no ID pragma is encountered for it.

    The issue is whether the OBV specification changes this default for
    values or not

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:01 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV design for the "CORBA::tk_value" TypeCode defines a
    potentially recursive constructed type that involves ValueMembers.
    The "tk_value" TypeCode defines the entire complexity of the types
    within the Value.

    It is our understanding that when the ORB code that handles "Anys" for
    C++ detects a tk_value TypeCode and needs to encode/decode the associated
    Value object – (e.g., for Any::replace(TypeCode, void *) – it will
    need to invoke a method on that object that understands the object
    instance data and the associated state information. Further
    examination of the TypeCode complexity will not be necessary by the
    Any implementation, since this code would not have knowledge of or
    ability to set the state information within the Value object itself.

    The reason why the layout of the state information within a value
    cannot be known by external code is that virtual inheritance of
    abstract values and/or abstract interfaces makes it impossible to
    calculate the offsets of the data members in a compiler
    independent manner.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 18:00 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Using the IDL defined in Issue # 1352, we have the send() method, in interface Foo, which takes a Base value type as its formal parameter. Now suppose we wish to pass a Derived value type. When marshaling the list of repository ids, the marshaling engine has no notion of the formal type of the parameter, thus it does not know how many safe repository ids it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Mon, 4 Mar 2024 17:57 GMT

No external annotation mapping

  • Key: CPP1117-35
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification lacks a description how to map the @external annotation

  • Reported: CPP11 1.7 — Wed, 24 Jan 2024 09:32 GMT
  • Updated: Wed, 24 Jan 2024 21:37 GMT

No mapping for min/max/range annotations

  • Key: CPP1117-34
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 spec lacks a mapping for the min/max/range annotations

  • Reported: CPP11 1.7 — Wed, 24 Jan 2024 09:28 GMT
  • Updated: Wed, 24 Jan 2024 21:37 GMT

Clarify implicit default

  • Key: CPP1117-33
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec says "In case the union has an implicit default member it is initialized to that case", but it doesn't specify what is an implicit default member, maybe add "i.e., if the union does not have a default case and not all permissive discriminator values are listed"

  • Reported: CPP11 1.7 — Tue, 16 Jan 2024 09:13 GMT
  • Updated: Tue, 16 Jan 2024 13:52 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 5 - Bi-directional GIOP misled me in a number of points, even after
    numerous readings and a discussion with an author. I believe the chapter
    contains all the pertinent information; it just has to be a bit more
    carefully presented.

  • Reported: CORBA 2.2 — Mon, 7 Dec 1998 05:00 GMT
  • Updated: Fri, 12 Jan 2024 21:37 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The firewall spec defines a number of tag values from OMG managed spaces.
    The values of these tags need to be assigned.

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:37 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec introduces the concept of initializers, which maps
    cleanly only to languages that support overloaded constructors.

    Other languages, such as C, would typically offer functions to provide
    inialization of values. Since initializers are not named, an intuitive
    mapping is hard to find.

  • Reported: CORBA 2.2 — Fri, 14 Aug 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:35 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The definition for interface CodeBase in module SendingContext
    has a method
    CORBA::InterfaceRepository get_ir();

    There is no type CORBA::InterfaceRepository. I believe this was
    intended to say
    CORBA::Repository get_ir();

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:34 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There are no rules governing how to free value factories in C++.
    Specifically, the ORB does not know what to do with the value factory at
    shutdown, and applications do not know what to do with the factory
    returned by register_value_factory. Directly deleting the factories may
    be hazardous (e.g. if they are shared across multiple valuetypes or even
    multiple ORBs), and leaving them around may introduce memory leaks.

  • Reported: CORBA 2.2 — Tue, 28 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:33 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.9.7 of orbos/98-01-18 says that the TypeCode parameters for both
    tk_value and tk_value_box start with a string which is the type"s
    repository ID. Why? For everything except tk_interface, the repository ID
    is not visible as a parameter. I believe these parameter lists should not
    include repository IDs to make them consistent with the others.

    I assume that the

    {member_name, TypeCode}

    pairs in the tk_value parameter
    list should appear in the order of declaration of the members in the
    valuetype. This is not stated anywhere.

    The visibility of each member should be added to the tk_value parameter
    list. Each entry in the list should contain

    {member_name, TypeCode, short}

    where the short refers to the Visibility of the member.

    The parameter list for tk_value should probably have an additional
    parameter which is the TypeCode of the concrete valuetype base, if any.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: For boxed values that are structs, unions, or other constructed types with
    member accessor and modifier functions, their member functions such as
    value(), boxed_in(), boxed_inout(), etc. may potentially clash with the
    names of those accessor and modifier functions.

    Solution: make the names of such special member functions start with an
    underscore, e.g., _value(), _boxed_in().

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The custom marshalling streams CDRInputStream and CDROutputStream
    don"t support the IDL fixed type. I propose adding the following
    type definition and methods:

    typedef sequence<fixed> FixedSeq;

    abstract value CDROutputStream

    { ... void write_fixed (in fixed value); void write_fixed_array (in FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

    abstract value CDRInputStream

    { ... fixed read_fixed (); void read_fixed_array (inout FixedSeq seq, in unsigned long offset, in unsigned long length); }

    ;

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec is not very clear about whether the Java class
    generated for an IDL value has a default (no-argument) constructor.

    A no-argument constructor is needed so that the Helper class
    can construct a value when demarshalling. However, it should be
    package-private in order to limit its visbility to the Helper
    class and not expose it to client code. This is also true for
    state fields declared as private in the IDL value type (which the
    spec currently states are mapped to private in Java).

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There"s a problem with the mapping to Java for boxed IDL values
    for non-primitive Java types, for example, a boxed string or a
    boxed sequence. The currently specified write_Value call doesn"t
    allow these to be marshalled correctly.

  • Reported: CORBA 2.2 — Wed, 8 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec does not contain a clear definition of how TypeCodes for
    values and value boxes are constructed. There is something about
    this in section 5.6.3, but this seems to describe a variant of the
    algorithm rather than the algorithm itself. Section 5.9.7 needs to
    be expanded to describe this in at least as much detail as the
    description of the encoding of recursive sequence TypeCodes in the
    current CORBA spec.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:31 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear from the spec whether or not value boxes can be
    forward declared, and used recursively. For example,

    value v;
    struct s

    { long s0; v next; }

    ;
    value v s;

    If value boxes are indeed syntactic sugar, the answer should be yes.
    That brings the next question: Does this mean that one can call
    create_box_value_tc(), supplying NULL for the original_type, and
    then later on fill in the member typecode via fill_in_recursive_tc,
    supplying a ValueMemberSeq of length 1?

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.8.6 gives the BNF for the GIOP encoding of values but does not
    describe the semantics behind them. Some of the semantics are referred
    to in earlier section and intuitive for an outsider with a little CORBA
    experience. Some of the the explicit semantics seem to be missing
    altogether (e.g. the "" in <end_tag>). It would be useful if the
    descriptions explicitly used the names within the BNF grammar or
    explicit specifications for each name in the grammar was given.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: One of the common patterns used in IDL specifications is to pass a
    sequence of a data type in order to cut down on network round trips.
    The current OBV spec (orbos/98-01-01) even suggests sending a graph of
    objects and optimizing for the case where the same object occurs
    multiple times in the graph (which I assume will normally be a small
    number of the total objects). The spec seems to be inefficient for
    sending a large number of small objects though. I have looked at the
    errata before and don"t recall any relavent changes but know the RTF are
    considering some now.

  • Reported: CORBA 2.2 — Tue, 30 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec allows a value to support multiple interfaces. In C++, such
    values
    are specified to derive from the POA skeletons generated from those
    interfaces.
    This presents a potentially intractable problem: skeletons are not designed to
    be inherited together with skeletons for other interfaces because servants do
    not support multiple interfaces. (The Multiple Interface RFP isn"t finished
    yet, right?) The top of page 20-104 of the latest C++ mapping (orbos/98-05-08)
    explicitly says

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:30 GMT

ValueMemberSeq: What is to be done with the RepositoryID parameter?

  • Legacy Issue Number: 1528
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2) In addition to the ValueMemberSeq, the input parameters to
    fill_in_recursive_sequence_tc include the target TypeCode
    pointer, and the RepositoryId.

    What is to be done with the RepositoryId parameter ?
    Is the method supposed to update the Id as well ?
    If that is the case, is it an optional/required parameter ?

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) The fill_in_recursive_sequence_tc method is intended to act
    upon an existing "tk_value" TypeCode. The signature indicates
    that it should return a TypeCode pointer.

    What TypeCode is supposed to be returned ?
    If the signature is in error, the specification should
    be corrected – if not, the specification requires
    some additional explanation as to which TypeCode
    needs to be returned.

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec defines CDROutputStream and CDRInputStream types values for
    custom marshaling. The names of these types should not contain "CDR" since
    there is nothing that prevents them from being implemented to use a data
    representation other than CDR.

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:29 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The OBV spec adds the notion of "chunking" because it claims that "it is
    anticipated that value types may be rather large, particularly when a graph
    is being transmitted. Hence the encoding supports the breaking up of the
    serialization into an arbitrary number of "chunks" in order to facilitate
    incremental processing." (orbos/98-01-18, page 5-55)

    This "feature" should be removed from the spec, since it is the job of the
    underlying transport to handle this issue. GIOP already provides
    fragmentation, allowing transports to handle large parameters efficiently
    – why should we build yet another fragmentation solution on top of it?

  • Reported: CORBA 2.2 — Thu, 11 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:28 GMT

"in". "out", and "inout" modifiers on value operation parameters

  • Legacy Issue Number: 1419
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The "in", "out", and "inout" modifiers on value operation parameters are
    effectively comments. This is the case as a value maps to a language
    pointer or reference. When it is passed in a local interface
    there is no way to guarantee "in" or "out" semantics; it is passed by
    reference which essentially has "inout" semantics.

    These semantics should be explicitly stated.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:27 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A typo: on page 8-107 of the OBV spec., interface Account should inherit ":" from
    Describable and value Currency should support Describable.

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:27 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p 5-24, first paragraph of 5.3.1.3:
    The implementation of operations may be remote if the value also
    supports CORBA.Object.
    typo p 5-30, last line of 5.3.2.6: may BE defined

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:23 GMT

Can an instance of C be passed by value to an operation that expects an A?

  • Legacy Issue Number: 1275
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Given:

    abstract interface A {};
    interface B : A {};
    value C : supports B {};

    Can an instance of C be passed by value to an operation that expects an A?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:20 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Semantic of register_value_factory is not clear
    What do applications should expect if a factory is already
    registered for a given repositoryId?

    The operation returns the previous factory. But it is not
    clear whether it is overriden or not.

    • When should register_factory be called ?
      I assume that this is after the ORB is initialized (since we
      need a pointer to the ORB). This means that initialization
      of "Component Libraries" is not trivial.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:19 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: According to the object-by-value C++ mapping, the value type that is
    not boxed results in an abstract C++ class. Basically, the reference
    counting methods are not provided (abstract). It is the responsibility of
    application developer to define/implement a concrete class. Althought
    this can be done, there are some issues:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:16 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: - What is the return type of "_add_ref" and "_remove_ref"
    (defaults to "int", but what is the semantic of the result value)
    => propose to change to "void"

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 21:13 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: TypeCodes:

    • It is not clear whether the IDL compiler has to generate
      a TypeCode object for each Value type.
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:58 GMT

Missing member_kind and member_tc

  • Legacy Issue Number: 1260
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:57 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Also, the OBV spec defines a describe_value() operation in interface ValueDef
    which returns a FullValueDescription structure. Is there supposed to be another
    operation which returns the shorter ValueDescription structure?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:57 GMT

p.6.68 boxed values of complex types map to same type

  • Legacy Issue Number: 1256
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p.6.68: It is a bit awkward that boxed values of "complex" types map
    all to the same type (i.e., as for typedefs, the value"s name appears
    only in holder/helper classes), and that each boxed value of "basic" type
    maps to its individual class. Instead, boxed values of basic types
    could map to the corresponding java.lang.* class, e.g.
    java.lang.Integer, java.lang.Short, etc. An issue with this approach
    is that java.lang.Short and java.lang.Byte are not defined in JDK
    1.0.2. I doubt however this JDK is still much in use; for its users,
    short and octet could optionally map to e.g. CORBA.ShortValue and
    CORBA.ByteValue (inspired from CORBA::StringValue).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:55 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Can a Value type inherit from a Value Box type (the Value Box is described
    as been syntactic sugar for a Value type)?

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Fri, 12 Jan 2024 20:53 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The GIOP specification does not say anything at all about the rules for marshalling ValueBoxes.

    I believe the expected format is to marshal ValueBoxes as if they were a normal Value with a single member, and that they follow the normal rules about indirections and chunking. The spec should clearly state this.

  • Reported: CORBA 3.0.2 — Wed, 16 Apr 2003 04:00 GMT
  • Updated: Fri, 12 Jan 2024 19:51 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.3.9.2 states:

    "In the DSI model, since the parameters are first available when the user code calls arguments, receive_request is called from within arguments. It is possible that arguments is not called in the DSI model. The target may call set_exception before calling arguments. The ORB shall guarantee that receive_request is called once, either through arguments or through set_exception."

    The problem here, is that the DSI servant has already been invoked at this point, and the DSI implementation will be unaware that the server interceptor may have cancelled the invocation via raising a system exception or ForwardRequest user exception. So the DSI implementation will carry on, creating all sorts of wonderful havoc as it continues to interact with the ServerRequest PO.

    Any vendors want to comment on what their PI implementation does now?

    Proposed fix:

    First, we should define a new system exception minor code that the servant implementation can detect so that it can clean up and get out of the way as expeditiously as possible when raised by arguments or set_exception. Perhaps a minor code for OBJ_ADAPTER? Should there be two minor codes, to distinguish a system exception from ForwardRequest as the reason for cancelling the invocation?

    Second, we need some more text either in chapter 8 or 21 that states that any calls by the DSI implementation to ServerRequest::set_result or ServerRequest::set_exception will be ignored (or perhaps reraise the exception defined in the previous paragraph) if ServerRequestInterceptor::receive_request raises an exception.

  • Reported: CORBA 3.0.2 — Wed, 2 Apr 2003 05:00 GMT
  • Updated: Fri, 12 Jan 2024 19:50 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    There is a small issue with the restriction of where a valuetype chunk can end. The spec says

    "The data may be split into multiple chunks at arbitrary points except within primitive CDR types, arrays of primitive types, strings, and wstrings, or between the tag and offset of indirections. It is never necessary to end a chunk within one of these types as the length of these types is known before starting to marshal them so they can be added to the length of the currently open chunk."

    However, in the case of array of wchar, the length is not known before starting to marshal, since each char (in GIOP 1.2 and 1.3) is marshalled as a (sort-of) sequence of octets. I think it should be legal to end a valuetype chunk in the middle of an array of char.

  • Reported: CORBA 3.0.2 — Wed, 26 Mar 2003 05:00 GMT
  • Updated: Fri, 12 Jan 2024 19:50 GMT

Default annotation

  • Key: CPP1117-32
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The default annotation is not just for struct members, also for exception/union members but it can also be applied to a type, so also for example attributes of an interface/component/connector can have a default, all code generation related to that should also use the default whenever one is needed (for example starter code generation)

  • Reported: CPP11 1.7 — Thu, 11 Jan 2024 08:33 GMT
  • Updated: Fri, 12 Jan 2024 17:13 GMT

Messaging Routing Protocol is broken for GIOP 1.0 & 1.1

  • Legacy Issue Number: 5662
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is impossible to use the routing protocol to communicate with servers
    that only support GIOP 1.0 or 1.1, because the information contained in
    struct MessageBody does not contain enough information to determine the
    alignment requirements of the contents of body member. The GIOP 1.0 &
    1.1 RequestHeader struct contain an octet sequence for principle as the
    last member, and specify no alignment requirements for the message
    body. Thus, it is impossible for the final router to determine the
    proper alignment for the message body when marshalling a GIOP Request
    message for delivery to the target object.

    The same problem applies to the Response message.

  • Reported: CORBA 3.0 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:43 GMT

Spec doesn't make clear what is valid mix of policies and what is invalid

  • Legacy Issue Number: 5624
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec doesn't make it clear what is a valid mix of policies and what
    is invalid. For example, should it be legal to set a
    RequestPriorityPolicy, MaxHopsPolicy or QueueOrderingPolicy value if the
    RoutingPolicy is ROUTE_NONE?

    Also, should setting both RequestEndTimePolicy and
    RelativeRequestTimeoutPolicy be illegal? Or must the client/server pick
    which ever one expires first?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:42 GMT

How does DynValue handle derived valuetypes?

  • Legacy Issue Number: 5467
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I just noticed that the description of DynValue is totally silent on the
    issue of derived valuetypes.

    Here's an example to set things up:

    // IDL

    valuetype A

    { public short s; }

    ;

    valuetype B

    { public long l; }

    ;

    struct S

    { A an_a; }

    ;

    // C++

    DynamicAny::DynFactory df = ...;
    B *b = ...;
    S my_s;
    CORBA::Any my_any;

    s.an_a = b;
    my_any <<= s;

    DynamicAny::DynAny_var da = df->create_dyn_any(my_any);
    DynamicAny::DynStruct_var ds = DynamicAny::DynStruct::_narrow(da);

    ds->seek(0);
    da = ds->current_component();

    DynamicAny::DynValue_var dv = DynamicAny::DynValue::_narrow(da);
    CORBA::TypeCode_var tc = dv->type();

    cout << tc->id() << endl;

    -----------

    Now some questions:

    1. What is printed by the above C++ code? "IDL:A:1.0" or "IDL:B:1.0"?

    2. If the typecode is for valuetype A, what happens to the members
    defined in valuetype B? Seems they must be inaccessable yet still
    recoverable if I convert the DynValue back to an any and extract the
    value, because I can't truncate a B to an A.

    3. If the typecode is for valuetype B, we now have the interesting case
    where:

    tc->equivalent(ds->type()->member_type(0))

    is false. Is this going to confuse programmers or programs? I think it
    will, since it means that if I try to insert dv into another DynStruct
    via assign() or the like, it will fail, since the TypeCodes are no
    longer equivalent.

    4. Do the answers change if B is truncatable and the program can find
    the TypeCode for B (perhaps via SendingContextRunTime)? How about if it
    can't find the TypeCode?

  • Reported: CORBA 3.0 — Tue, 16 Jul 2002 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:41 GMT

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Fifth bullet near the beginning of this section states:

    Incarnations of a particular object may not overlap; that is, incarnate shall not be invoked with a particular ObjectId while, within the same POA, that ObjectId is in use as the ObjectId of an activated object or as the argument of a call to incarnate or etherealize that has not completed.

    Unfortunately, I do not see anywhere where the exception to be thrown from activate_object_with_id() for this case is specified. According to this text, if incarnate() is executing for a particular ObjectId, any calls to activate_object_with_id() should be rejected by the POA. This came up in comp.object.corba, where someone posted a question as to why Orbix 2000 throws the ObjectAlreadyActive exception for this case.

  • Reported: CORBA 3.0.2 — Mon, 12 Jan 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:40 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: open  
  • Source: Borland Software Corporation ( Wolfgang Haefelinger)
  • Summary:

    [..] It is used to indicate the relative amount
    of time for which a Request or its corresponding
    Reply may be delivered. After this amount of
    time, the Request is cancelled (if a response
    has not yet been received from the target) or
    the Reply is discarded (if the Request had
    already been delivered and a Reply returned from
    the target) [..]
    ---------------------------------------------------------
    Question:

    • What is the precise meaning of "Request is
      cancelled"?

    Does it mean that client ORB just gives up or
    does it mean that client tries, in kind of best
    effort semantics, to cancel request on server?

    If this cancellation fails, how will client user
    be informed about this? By a minor code in
    thrown Timeout exception?

    Is it possible to clarify this?

  • Reported: CORBA 3.0.2 — Wed, 29 Oct 2003 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:39 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The spec appears silent as to whether valuetypes are allowed to support local interfaces. Table 3-10, for example, says nothing at all about local interfaces.

    There's a couple ways to look at this. First, valuetypes are not CORBA objects. Servants for local interfaces are direct CORBA object instances, i.e., the "local" declaration on an interface effectively removes the distinction between a CORBA object and its servant. If a valuetype were used as a servant for a local object, then the valuetype would itself also be a CORBA object. By this analysis, valuetypes should not be allowed to support local interfaces.

    Another way to look at it is that the valuetype should just inherit the local interface's operations and attributes without having any subtype/subclass relationship with the base local interface. This would be a rather pointless approach to take, is there would be no possibility of using the valuetype polymorphically with respect to the base local interface.

  • Reported: CORBA 3.0.2 — Thu, 16 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:38 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: open  
  • Source: Remedy IT ( Martin Corino)
  • Summary:

    The current mandatory annotation definitions (7.4.15.4.1) will cause problems when IDL specifications are attempted to be reused between profiles applying different requirements concerning annotations (for example a profile with annotations and a profile without annotations or two or more profiles with different sets of annotations).

    As the IDL 4 specification has removed the support for the commented form of annotations there is no possibility anymore to declare annotations in a form that has semantic meaning in one profile and does not cause parsing errors in another profile not supporting (these) annotations.
    Even with the commented form supported the mandatory specification of annotation definitions for applied annotations would cause similar kind of problems as it is likely that the definitions for the standard set of annotations from one profile would not be available in another profile not supporting those annotations.

    Personally I do not see any use for annotation definitions (and in fact I cannot find any commentaries regarding that in the spec) but I would suggest that at the very least IDL compilers should be allowed to ignore any annotations not known to the profile for which the IDL compiler is configured.
    Ideally I would like to see a specification without any mandatory annotation definitions leaving it up to the tool supplier to enforce annotation definitions or implement implicit (embedded) definitions.

  • Reported: CORBA 3.1.1 — Tue, 31 Mar 2015 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:38 GMT

CosExternaliazation Service (bug?)

  • Legacy Issue Number: 4188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Page 2-7 of the CosExternalization Service Specification (April 2000)
    defines the following interfaces:
    CosStream::Node
    CosStream::Role
    CosStream::Relationship

    A CosStream::Node inherits from the CosStream::Streamable interface and
    therefore is a streamable object – it has an external_form_id attribute
    that enables a FactoryFinder to recreate the object using the
    create_uninitialized operation.

    Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
    not support the CosStream::Streamable interface and therefore are not
    "streamable;" in particular, there is no standard method to obtain a KEY for
    them when it is time to internalize them.

    Perhaps, I am missing something (it wouldn't be the first time , but
    having them support the Streamable interface would certainly make
    implementation much easier. Might I suggest the following:

    interface Role: CosGraphs::Role, CosStream::Streamable

    { ... }
    interface Relationship: CosGraphs::Relationship, CosStream::Streamable { ... }

    at a minimum this would permit the CosStream::Node internalize_node()
    operation and the CosStream::StreamIO read_graph() operation to use a KEY
    value in the FactoryFinder to instantiate the object, before it is
    internalized.

  • Reported: CORBA 2.4.2 — Mon, 5 Feb 2001 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:36 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: open  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    ptc/04-04-06 section 15.9.1 (top of page 15-67) states:
    When the server receives a BI_DIR_GIOP_OFFER context it must send back a
    BI_DIR_GIOP_ACCEPT context in both the strong and weak identification cases.

    What happens if an ACCEPT service context is not returned? Either immediately
    or ever?

    Can a connection initiator, having sent an OFFER SC, send any further GIOP
    messages over that connection prior to receiving the ACCEPT SC?

    Should a connection initiator, having sent an OFFER SC but not having received
    an ACCEPT SC, accept a Request (i.e in the reverse direction) on that connection?
    a) for an object whose POA's BiDirId has been offered and accepted?
    b) for an object whose POA's BiDirId has been offered but a corresponding
    ACCEPT has not yet been received?
    c) for an object whose POA's BiDirId has been offered and accepted only over a
    different connection (to that over which the Request arrives)?
    d) for an object whose POA has a BiDirId but it hasn't yet been offered?
    e) for any object (e.g. one whose POA doesn't have a BiDirId)?

    If an OFFER SC is sent on a Request message, can the corresponding ACCEPT
    SC be carried on any GIOP message from the connection acceptor?
    a) the associated Response
    b) a Response not associated with the Request
    c) a NegotiateSession message
    d) a Request message for an object whose POA's BiDirId has already been
    negotiated

    If an OFFER SC is sent on a NegotiateSession message, can the corresponding
    ACCEPT SC come piggy-backed on any GIOP message (that can carry SCs) or
    must it come over a NegotiateSession message?

    If two POAs (with EXPORT policy) are created and their BiDirIds are sent separately
    in OFFER SCs on separate messages over a given connection, is a subsequently
    received ACCEPT SC deemed to relate to one or to both of the offered BiDirIds?

    Since I assume that a connection is effectively promoted to BiDir once the first
    ACCEPT SC (indicating no error) is received. What is the point of insisting that
    the connection acceptor "must" send additional ACCEPT SC?

    In fact, even wthout any ACCEPT(no error) SCs, the occurrence of a GIOP Request
    message from the connection acceptor would imply that the connection acceptor
    has accepted the BiDirId. It would seem that the ACCEPT(no error variant) SC is
    completely superfluous.

    Given the ambiguities in the protocol, it seems likely that an implementation may
    find the real-world interactions to have broken its model of the protocol. What should
    a GIOP protocol machine do in such a situation?

    If the connection initiator deems that the OFFER-ACCEPT protocol has gone wrong
    should it be required to close the connection?

    As there is no correlation between OFFER SCs and ACCEPT SCs, on a given
    connection, does an ACCEPT (indicating an error) imply that the connection is
    in an indeterminate state and should be closed?

    If a connection is to be closed due to an error in the OFFER-ACCEPT protocol do
    the normal rules regarding outstanding invocations apply? Do they apply for both
    directions?

  • Reported: CORBA 2.5 — Thu, 13 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: open  
  • Source: Syracuse University ( C. Joncheng Kuo)
  • Summary:

    This issue was mentioned by Dave Stringer. I now file it as an issue.

    When a bi-directional connection is established between a connection initiator and a connection acceptor, the connection acceptor may have to consider this bi-directional connection is volatile, i.e., the connection acceptor may lose (and is not able to resume) its capability of making invocations on such a connection anytime. For example, the connection may be lost due to network problems or the client may close a connection due to an idle time-out. These situations are not a problem for uni-directional GIOP because the ORB who wants to make an invocation can always initiate a new connection when the old connection is not available.

    This problem may be less serious when bi-directional communication occurs only during the period of an invocation from the connection initiator. In other words, if the connection is lost and results in the failure of bi-directional "callback", the connection initiator may retry, effectively resuming the bi-directional connection.

    On the other hand, for the use case in which a connection initiator "registers" an object reference to the connection acceptor, there is no guarantee that "callbacks" from the connection acceptor to the connection initiator will eventually succeed, assuming the network is not always down.

    If this issue is a limitation that cannot be solved easily, we should spell it out in the spec.

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:33 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    Part of this issue has been surfaced in the discussions over the mail list. I now file it as an issue.

    The Bi-directional GIOP spec says, "An object reference with a BidirectionalOfferPolicy of DENY must not be invoked over a bi-directional
    connection." Satisfying this policy requirement does not close some potential limitation and ambiguity when other policies or policy instances are around.

    For example, at the connection initiator side, we may have two object references one of which has BidirectionalOfferPolicy of DENY and the other has BidirectionalOfferPolicy of ALLOW. If these two object references point to the same server, according to spec, we need two connections to the server: one is bi-directional and one is not. However, having a non-bi-directional connection doesn't mean much. For invocations on the object reference with the DENY policy, the server side can always callback using the other bi-directional connection.

    There is an argument (by Brian Niebuhr) saying that it's not realistic to both trust and not trust the same server. However, in practice, it's not always possible to tell whether two object references point to the same server or not. Furthermore, the client may decide whether or not to trust the server of an object reference depending on reasons other than the information about the server. For example, the client may decide to use BidirectionalOfferPolicy of ALLOW or DENY according to the source of an object reference.

    On the other hand, at the connection acceptor side, things become a little more interesting. For an object reference with BidirectionalAcceptPolicy of ALLOW and effective BidirectionalOfferPolicy of DENY (e.g., the default policy on that ORB), what shall be the proper behavior of the ORB? According to the BidirectionalAcceptPolicy, "the ORB may accept and use any connections that a client has offered as bi-directional." However, shall we let the BidirectionalOfferPolicy of DENY prohibits the use of such a bi-directional connection? Or shall we allow the use of such a bi-directional connection because it's in the "reverse" direction?

  • Reported: CORBA 2.5 — Tue, 11 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The Bidirectional GIOP spec does not specify how many BI_DIR_GIOP_OFFER service contexts are allowed in a NegotiateSession or Request.

    If only one such service context is allowed, it shall be stated clearly. Besides, because each BI_DIR_GIOP_OFFER service context can contain only either strong or weak BiDirIds (but not both), if there are both strong and weak BiDirIds on the ORB, the ORB has to use at least two GIOP messages to send them all.

    If we allow multiple BI_DIR_GIOP_OFFER service contexts in one message, we'll have a problem in matching BI_DIR_GIOP_ACCEPT service contexts to these offers because there is no sequencing on offers and accepts.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The connection_complete field of the FirewallPathRespContext is under specified.

    The fourth paragraph (including IDL) from the end of Section 1.5.4, Firewall Service Context, says,

    “Once the connection has been established, the last intelligent firewall in the FirewallPath sends a FIREWALL_PATH_RESP service context in another NegotiateSession message.”

    However, the last paragraph of this section says that, when the connection is not completely established, a FIREWALL_PATH_RESP service context with the connection_complete field of false is sent.

    Furthermore, when the connection_complete field is false, the spec does not explain what are the situations that may cause incomplete connection establishment and what the client shall do for “further processing”. Shall the FIREWALL_PATH_RESP service context also contains information indicating what the client shall do?

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:32 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    It is not defined what happens if a non-conformant implementation receives a BiDir offer.

    RECOMMENDATION:
    State that a non-conformant implementation need not do anything - it may simply ignore the offer.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:15 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The target (ORB, POA, object, thread) of the Export and Offer policies and the side of the connection involved is incompletely specified.

    RECOMMENDATION:
    Define the two sides of a connection as the connection 'Initiator' and connection 'Acceptor'. The usual terms of 'client' (Initiator) and 'server' (Acceptor) become confusing in a bi-directional situation. Given those terms for each side, specify that the Export and Offer policies are used on the Initiator side. Specify that the Export policy may be applied to the ORB, the POA and/or to the thread. Specify that the Offer policy can be applied to the Initiator ORB, to a reference in the Initiator for an object in the Acceptor, or to a thread in the Initiator ORB.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:14 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP Document discusses three stages of connection setup, but it is unclear when each stage begins and when it ends. It is also unclear what NegotiateSession or Firewall activity can take place in each stage and what the order of processing may be.

    RECOMMENDATION:
    Rewrite the relevant portions of the document to specify the following (excerpted without edit from Brian Niebuhr's discussion of NegotiateSession contexts and the stages of setup):

    "...during connection setup, only firewall contexts can be in the negotiate session message, NOTHING ELSE. After the connection is setup, there is a period before the first request or locate request where we can do session setup items. I think that in that period, only Bidir contexts can be sent, NOTHING ELSE. The first request or locate request indicates the connection_established period. Again, during that period I think only the Bidir contexts should be legal. This makes things very simple. There are no conflicts between firewall and bidir, and nothing else can go in a negotiate session message."

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:14 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The new BiDir spec is not clean about what BiDirIds shall be send to what connections. Because the BidirectionalOfferPolicy is either ALLOW or DENY, the only way to make bi-directional GIOP possible is to send all BiDirIds on an ORB to every connection that is used by an object reference that has effective BidirectionalOfferPolicy ALLOW. Besides, when a new POA with BidirectionalExportPolicy ALLOW is created, the BiDirId of this new POA must be transmitted to the server side of every existing bi-directional connections (before or in the next request).

    The above implication derived from the spec is very inefficient. Consider an ORB with n bi-directional connections and m BiDirIds. The communication overhead for sending these BiDirIds is (m * n), while, in the ideal case, the communication overhead for sending BiDirIds is (c * n) where c is the average number of BiDirIds needed on each bi-directional connection. This ideal case can be easily achieved by allowing the BidirectionalOfferPolicy to specify a list of POAs whose BiDirIds shall be transmitted.

    Proposed resolution:
    1. Extend the choices of the value field of the BidirectionalOfferPolicy:
    ALLOW_ALL – same as ALLOW now, but the implication shall be explicitely stated in the spec
    ALLOW_LISTED – a list of POAs being provided in the policy
    DENY – same as it now
    2. Add a field to the policy to allow a sequence of POAs being specified.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document allows all of the contexts that can be found in a GIOP query or response message to be also allowed in a NegotiateSession message. However, the interplay among these contexts is undefined. An example is the use in NegotiateSession messages of both CodeSet negotiation and BiDir connection setup. What can be used in what order is not defined.

    RECOMMENDATION:
    Only bi-directional GIOP and firewall contexts may be used in a NegotiateSession message in this version of GIOP. The contexts are the following:

    · BI_DIR_GIOP_OFFER
    · BI_DIR_GIOP_CHALLENGE
    · BI_DIR_GIOP_RESPONSE
    · BI_DIR_GIOP_ACCEPT
    · FIREWALL_PATH
    · FIREWALL_PATH_RESP

    Further contexts may be added to new versions of the BiDir GIOP spec as their interplay with the existing set and the order of their use is carefully analyzed and documented. This effectively limits the scope of the problem to the bidir protocol and use by the firewall. The order and stage of processing the above contexts is discussed in another Firewall issue.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document specifies that all BiDirIds must be randomly generated. However, persistent POAs must use the same BiDirId across sessions since they are stored in the IOR.

    RECOMMENDATION:
    A new policy is created (BiDirIdGenerationPolicy) that contains two fields:
    field 1, the ID generation method, will take the value 'RANDOM' or the value 'REPEATABLE'
    field 2, the ID type, will take the value 'STRONG' or the value 'WEAK'

    The random generation method is adequately documented. The repeatable method will always generate the same BiDirId for a given POA. This effectively makes the ID a constant, but without the concern for storage. It also results in the end-user not having to deal with BiDirIds - they are handled entirely by the infrastructure.

    The values for the ID type indicate whether the type of BiDirId generated is strong or weak.

    This policy is placed on the client ORB and/or the POA in question.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify the connections over which a BI_DIR_GIOP_OFFER should be sent.

    RECOMMENDATION:
    A BI_DIR_GIOP_OFFER will be sent over all existing bi-directional connections. If there are none, then a new connection will be established and its bidirectionality initiated.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:06 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The actions that result from the failure of a BiDir challenge are unclear.

    RECOMMENDATION:
    The client has proven itself untrustworthy. A BI_DIR_GIOP_RESPONSE containing a STRONG_FAILED result is returned to the client and all bi-directional connections to the client are closed.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The BiDir GIOP document does not specify which BiDirIds and how many of them are sent in a BI_DIR_GIOP_OFFER.

    RECOMMENDATION:
    All unoffered BiDirIds are supplied in a BI_DIR_GIOP_OFFER.

  • Reported: CORBA 2.5 — Thu, 6 May 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    I'll use the following example to explain the implications that I derive from my understanding about the spec. I hope that it makes sense to you. If I'm wrong, please let me know.

    Suppose I set up a client that has some POAs with BI_DIR_EXPORT policy ALLOW. The client wants to invoke a server that accepts bi-directional GIOP. This invocation will cause callbacks to a few objects on the client using bi-directional GIOP. The server is not allowed to create new connections to the client.

    In the code of my client application, I can simply use the following statement to invoke the target object. And I would expect that the target object will call back some of the objects on the client ORB during this invocation.

    obj = ...; // target
    obj.invoke_target(...);

    In order for the above scenario to work, I derive the following implications from the spec.

    1. This invocation requires the target to call back on some of the objects on the client ORB. Because the client ORB has no knowledge about what objects might be called back, the client ORB has to ensure that the BiDirIds on all of its POAs that have EXPORT policy ALLOW must be available at the server side.

    This conclusion also implies that the client ORB may have to track what BiDirIds that have been sent (and accepted) over every connection that allows bi-directional GIOP in order to figure out what BiDirIds have not yet been sent, assuming that you don't want to send all BiDirIds in every request. Furthermore, when someone creates a new POA with the EXPORT policy ALLOW later on the client ORB, the next new invocation on each bi-directional connection will also have to transmit the BiDirId for this new POA to the server side.

    2. When the server receives a GIOP Request with BI_DIR_GIOP_OFFER service context, the server cannot dispatch the request to the target object implementation until this connection becomes bi-directional. Why? If the server dispatches the request before this connection becomes bi-directional, this request may fail because the target is not able to call back objects on the client ORB. In the case of Strong BiDirIds, the server may even have to send CHALLENGE and wait for RESPONSE before the server can dispatch the request.

    If we put both implications together in the case of Strong BiDirIds, when someone creates a new POA with EXPORT policy ALLOW on a client ORB, a longer delay will be expected in the next request on every bi-directional connection because the server has to verify the BiDirId of this new POA no matter whether this new BiDirId will be used for callbacks on that connection or not. To me this overhead is not acceptable if it is the only way to implement bi-directional GIOP according to the spec. I hope the spec can be written in a way that allows efficient implementation, though efficiency is not always a concern for everyone.

  • Reported: CORBA 2.5 — Thu, 8 Apr 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    PROBLEM:
    The second paragraph on page 15-60 of the revised GIOP chapter only allows a BiDirOfferContext to be sent to a server if the ORB-level policy permits it:

    "If the client ORB policy permits bi-directional use of a connection, a Request or
    NegotiateSession (see MARS/04-01-01) message can be sent to the server that
    contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header that
    indicates that this GIOP connection is bi-directional. The BiDirOfferContext
    indicates to the server that the objects with the supplied BiDirIds are available for
    invocation over that connection. To determine whether an ORB may support bidirectional
    GIOP, the BidirectionalOfferPolicy has been defined (see Section 15.9,
    "Bi-directional GIOP policy," on page 65)."

    This, however, contradicts the rest of the document, which allows the ORB-level policy to be overriden at the object level. ("A BidirectionalOfferPolicy can be applied to a client ORB, and it can be overridden
    for specific object references received by the client ORB." - Section 15-9, page 15-66).

    Additionally, the first sentence of the above paragraph is worded in such a way that it defines a connection as bidirectional before it has accepted as such by a server.

    Finally, a spurious reference to the submission document is included in the first sentence ("see MARS/04-01-01").

    RECOMMENDATION:
    Rephrase the paragraph as follows:

    If the effective BidirectionalOfferPolicy of an object in the client is set to ALLOW, a Request or NegotiateSession message that contains a BI_DIR_GIOP_OFFER IOP::ServiceContext structure in the header can be sent to the server, offering bi-directional use of the connection. The BiDirOfferContext indicates to the server that the objects with the supplied BiDirIds are available for invocation over that connection. To determine if bidirectional GIOP may be supported, the BidirectionalOfferPolicy has been defined (see Section 15.9, "Bi-directional GIOP policy," on page 65).

  • Reported: CORBA 2.5 — Tue, 6 Apr 2004 04:00 GMT
  • Updated: Thu, 11 Jan 2024 17:05 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    If a service context negotiation fails by way of the NegotiateSession
    message in either direction. how does the sender (client or servers side)
    get an indication back to the sender?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:04 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset come before/with/after BiDir negotiation?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:04 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Can Codeset come before/with Firewall Traversal in Negotiate Session
    meesages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    On a connection in which BiDir is negotiated, but no Codeset
    is negotiated, will the reverse direction be able to negotiate
    code set?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does Codeset get negotiated in only the other direction?
    If so, will that happen in Negotiate Session meesages orRequest Messages?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:03 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Does the CodeSet get negotiated in Negotiate Session?
    If so, does Codeset continue to get negotiated in Requests?

  • Reported: CORBA 2.5 — Mon, 22 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:02 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: open  
  • Source: bergersen.org ( Rebecca Bergersen)
  • Summary:

    The following paragraph raises an interesting issue. If we follow this to the letter

    • since it says that the new version of GIOP is not backward compatible with the
      earlier versions of GIOP, it implicitly appears to make this new GIOP version a
      new "major" version of GIOP. Clearly we need to figure out a way to avoid doing
      this, since creating GIOP version 2.0 in this way raises all sorts of other issues.

    From the second paragraph on page 1-30 of the Firewall Final Adopted Spec (ptc/04-04-01):

    This document supercedes the previously adopted CORBA firewall specification. In
    addition, the changes to bi-directional GIOP, specified in Chapter 15, supercede the
    adopted specification for bi-directional GIOP. These specifications are not backwards
    compatible with the previous specifications and they are intended to make it possible
    to create a functional protocol for the interoperation of ORBs and firewalls.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:02 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

  • Legacy Issue Number: 7167
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    There seems to be a discrepancy in the changes proposed to CSIIOP and CSI modules. The draft document has identical changes to both. I think the intent of the Errata was to have only one, just switch them from CSIIOP to CSI. However, Brian's convience document doesn't show the change. Now, the draft document ptc/2004-01-01 that we are voting on has both. What to do? Should that be represented by another document, namely CSI, with it's changes, just like 2004-01-02 is? Cheers, -Polar

    Yeah, I see the problem. Yet another consequence of the adopted spec changing existing spec without calling out the change in the section meant to identify changes to existing specs. So it looks like the fix involves: 1. Section 1.9.2 and 1.9.3 in ptc/04-01-01 [henceforth referred to as document A] should disappear. 2. The first half of section of document A starting from the second para of the section and upto and including the last but one paragraph on page 1-20, should be appended to Section 24.2.5 "Identity Token Format" of Chapter 24 of Core with the title (that is the CSIv2 Chapter)[henceforth referred to as document B]. Also append a row to table 24-2 with info about ITTCompundToken. 3. The IDL in section 1.9.3 of document A should be merged properly into the IDL for the CSI module that appears in section 24.9.2 document B. 4. The addition to CSIIOP IDL as it appears in Section 1.5.2 of document A should be merged appropriately into the IDL for CSIIOP in section 24.9.3 of document B. 5. In document B insert a section 24.5.1.6 "TAG_IIOP_SEC_TRANS" with a two liner explanation of what this tag is together with the IDL for it from section 1.5.2 of document A. I'd suggest that we file this as an issue and resolve it in the FTF roughly along the lines suggested above.

  • Reported: CORBA 2.5 — Fri, 19 Mar 2004 05:00 GMT
  • Updated: Thu, 11 Jan 2024 17:00 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The BidirectionalPolicy insufficient for persistent objects.

    The BidirectinoalExport Policy is a POA policy and it only has two values
    of ALLOW and DENY. If it is ALLOW, then a TAG_BI_DIR_GIOP componenet
    should be placed in the IOR. It is stated that the ORB must generate a
    random identifier when the POA is created. However, that will not work for
    persistent objects in which the BiDirectional Offer must remain constant.

    Also, there is no default specified if this policy is not placed on a POA,
    and no default for the RootPOA.

  • Reported: CORBA 2.5 — Thu, 9 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:59 GMT

Server Authentication

  • Legacy Issue Number: 6312
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    As I understood it, the Firewall Traversal specification was to use new
    CSIv2 Compound Identity types to give the target server the complex
    principal composed of the client and the authenticating firewall traversal
    path. The server was to be authenticated to the client in much the same
    way. This functionality appears to be missing in the specification. It is
    easily fixed by returning a CSIv2 IdentityTokenSeq from a successful
    firewall negotiation, specifying the backwards firewall authentication
    trail from the server to the client.

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:58 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The Negotiate Session message is unwieldy in that if it is used to send
    service contexts, there are no general ways to govern its use other than
    by special rules, all of which special cases are not accounted for in the
    specification.

    For example, when do you sent Bidirectional service contexts as ooposed to
    firewall contexts? Can you send transaction contexts? Codesets? Codebase?
    CSIv2? Can you send BiDir service contexts while firewall contexts are
    being processed?

  • Reported: CORBA 2.5 — Tue, 7 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:52 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: open  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    The NegotiateSession message is a single typed GIOP message that is sent
    between both Client and Server to negotiation service contexts, and
    further to initiate and negotiate bidirectional GIOP.

    Having a single message is problematic in that a connection, once
    negotiated bidirectional may have different requirements for such things
    like Codesets, etc. Getting a NegotiateSession message after a
    bidrectional set up, the endpoints will have difficulty discerning the
    orientation of the NegotiateSession message.

    At the very least NegotateSession messages should have an orientation,
    much like the GIOP Request and Reply messages do.

    I'm not so sure they must be correlated with a "request id", but different
    message types would help. I would suggest two messages,
    NegotiateSessionRequest and NegotiateSessionReply to maintain the
    client-server orientation, respectively.

  • Reported: CORBA 2.5 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Thu, 11 Jan 2024 16:52 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: open  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    i have a few questions about the POA ThreadPolicy type
    MAIN_THREAD_MODEL.

    first, the 2.4.1 spec (00-11-03), sec 4.2.3.2 , 'perform_work' states,
    "If called by the main thread, this operation performs an
    implementation-defined unit of work; otherwise it does nothing."

    how is a distinguished main thread supposed to be reliably determined?
    i'm not sure we really need to define this. i'd think what we're trying
    to say is that the thread that calls perform_work() is the thread that
    will be used to do the work, and it is up to the application to make
    sure this happens. in section 4.2.3.3, the spec states,
    "For maximum portability an application should call either run or
    perform_work on its main thread."

    to me it seems the intent is to let the application determine what the
    'main thread' is.

    second, what happens if an application calls both run & perform_work?
    and what happens if the application calls run from multiple threads? it
    isn't really clear what the difference in request handling with regard
    to the thread used is between run() & perform_work().

    right now the spec seems to imply through the use of the message loop
    example in section 4.2.3.2 that perform_work is really intended to be
    used to handle situations where a single thread must be used for all
    application activity. now add to that the note on pg 11-12 about using
    the main thread model:
    "Note - Not all environments have such a special requirement. If
    not, while requests will be processessed sequentially, they may not all
    be processed on the same thread."

    my interpretation is that ORB::run would be used in cases where you
    simply want the POAs to be accessed sequentially, but the application
    doesn't care about which thread the implementation uses, but you would
    need to call perform_work to specifically hand the application defined
    main thread to process requests.

    my suggestion (finally ;^) is that we should state perform_work should
    be called, on whichever thread the application likes, if it wants to
    hand a specific thread to the ORB to do work. otherwise, calling
    ORB::run from any thread simply means the implementation is free to
    handle requests for servants associated with main thread model POAs on
    whatever thread the implementation may choose (including a new one), in
    keeping
    with the requirement that the requests be processed on each POA's
    servants sequentially..

    one more question: does it make sense to state that a callback type of
    architecture won't work when using this threading model?

  • Reported: CORBA 2.4.1 — Wed, 17 Jan 2001 05:00 GMT
  • Updated: Thu, 11 Jan 2024 16:51 GMT

The use of Full Services definitions in CORBA/e spec

  • Legacy Issue Number: 10598
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem:

    Since CORBA/e is for embedded constrained systems, one should be using LW Services as a minimal compliant point this would still allow one to offer up a Full Services in its offering but the other way around would not be compliant.

    Suggested Change

    The suggested change is to use LW Services definitions for CORBA/e.

  • Reported: CORBAe 1.0b1 — Fri, 19 Jan 2007 05:00 GMT
  • Updated: Thu, 11 Jan 2024 16:50 GMT

Apply IDL/C++ formatting to code in text

  • Key: CPP1117-31
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    All IDL/C++ that is used in the text should be have a different font like done in the other parts of the spec, that is for example int8_t/uint8_t/Base::Base/

  • Reported: CPP11 1.7 — Wed, 10 Jan 2024 10:42 GMT
  • Updated: Wed, 10 Jan 2024 15:27 GMT

Remove semi colon after namespace closure

  • Key: CPP1117-30
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    There shouldn't be a semi colon after the namespace closure, this is done in more places in the spec, search for "namespace", closing should be "}" and not "};", see chapters 6.3/6.5/6.23.1/6.26.2/6.27.2/6.28/6.29

  • Reported: CPP11 1.7 — Wed, 10 Jan 2024 10:40 GMT
  • Updated: Wed, 10 Jan 2024 15:26 GMT

Destructors should be override

  • Key: CPP1117-29
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    For the following places the declared destructors should be using override and not virtual as they override the base class destructor. This should happen to:

    • 6.18.4, see "virtual ~Example();"
    • 6.18.4, see "virtual ~OBV_Example();"
    • 6.20, see "virtual ~Exception();"
    • 6.20, see "virtual ~SystemException();"
    • 6.25, see "virtual ~MyLocalIF();"
    • 6.26.6, see "virtual ~A_skel ();" and "virtual ~A_impl ();"
    • 6.26.8 see "virtual ~TIE() = default;"
  • Reported: CPP11 1.7 — Wed, 10 Jan 2024 10:34 GMT
  • Updated: Wed, 10 Jan 2024 15:26 GMT


Add support for IDL4 int8/uint8/map/bitset/bitfield/bitmask

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

    CORBA 3.4 should have support for int8/uint8/map/bitset/bitfield/bitmask/bitvalue for DynamicAny, DynamicSkeleton, Interface Repo, Any/TypeCode and other CORBA APIs related to types

  • Reported: CORBA 3.4 — Mon, 17 Jul 2023 13:56 GMT
  • Updated: Wed, 6 Dec 2023 23:16 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: open  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    RE: CCM chapters document [orbrev] 99-10-04, section 61.6.2, page 61-45.
    The document citation indicates that the integrity of the valuetype –
    that is, the received marshalled state – is to be preserved in an
    ORB-mediated operation, even if that valuetype cannot be unmarshalled,
    either partially (truncated) or at all. If this value is then passed to
    another operation, the original marshalled state is to be transmitted.
    This preserves the transmitted object in its entirety, regardless of
    local implementation concerns. This is obviously necessary for bridges
    or event processing, such as through the notification service.

    So the question arises, what happens if you have a partial (truncated)
    unmarshall and the recipient application changes the local state of the
    valuetype through its attributes or local operations? How can/will you
    even know the state was changed? Do you ignore the changes and send the
    originally received marshalled stream, send only the new valuetype even
    though it is a truncation of the original, or "merge" the new values for
    the unmarshalled part followed by the original appended data for the
    truncated part? Should this third option be possible through an
    explicit ORB call – that is, the application is responsible to identify
    the change in state to the ORB? I assume that the semantics of
    "truncatable" must come to include the understanding that data in the
    truncatable portions may not be contextually dependent on the inherited
    parent of the valuetype.

    As a further question, is there a reason why this semantic
    interpretation should not be extended to be a general requirement rather
    than only with respect to transmission of anys? My experience has found
    that passing anys tends to be expensive and is avoided where it can be.
    A more general interpretation permits transmission of a comprehensive
    data structure among intermediate agents that only use (unmarshall) the
    information they need.

  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:15 GMT

69.3 AssemblyFactory Interface

  • Key: CORBA35-69
  • Legacy Issue Number: 5576
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Suggested changes to the AssemblyFactory interface.

    AssemblyFactory Issues.

    1. Ease of use Issue. After the create operation is performed, one is
    force to call lookup to get the Assembly that just got just created. Why is
    a cookie returned by the create operation instead of an Assembly? Is the
    reason because of security? If the interface were more open this would
    still allow a secure implementation to be implemented.
    Suggested change is to return an Assembly instead of a Cookie. Change
    destroy operation to take in an Assembly parameter instead of Cookie.
    Change lookup operation to take in a name parameter. These changes
    make it consistent with the other CCM interfaces, such as Container,
    KeyLessCCMHome, ComponentServer, and ServerActivator.
    2. Multiple users Issue. For multiple users, how does a client know what
    assemblies are created. Add a get_assemblies operation that returns a list
    of assemblies. These changes make it consistent with other CCM interfaces,
    such as Container, ComponentServer, and ServerActivator.
    3. User-friendly identifier for Assembly Instance issue. Add an input
    name parameter that can be assigned to the Assembly instance that gets
    created. Add a read only name or label attribute to the Assembly interface.

  • Reported: CORBA 3.0 — Thu, 8 Aug 2002 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:14 GMT

[CCM] Interface Repository Metamodel

  • Key: CORBA35-65
  • Legacy Issue Number: 5594
  • Status: open  
  • Source: Anonymous
  • Summary:

    in the BaseIDL there is a class StructDef which has the Attribute members of
    Type Field. How can I model a IDL struct with more than one entry?
    I think there should be a aggregation from StructDef (1<>----->*) to the Field
    class (Page 8-10 of the CCM Spec).

    *) With EnumDef there is the same problem, I guess a assotiation from EnumDef to
    string (1<>----->*) would solve it (Page 8-10 of the CCM Spec).

    *) Also with ExceptionDif and its attribute members (Page 8-11 of the CCM Spec).

  • Reported: CORBA 3.0 — Mon, 26 Aug 2002 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:13 GMT

CCM IDL style inconsistency

  • Key: CORBA35-61
  • Legacy Issue Number: 5858
  • Status: open  
  • Source: Anonymous
  • Summary:
    • document : formal/02-06-65
    • chapter : 1.5.2.4
    • text in question :

    module Components
    {
    valuetype Cookie

    { private CORBA::OctetSeq cookieValue; }

    ;
    };

    • Issues :

    1. Naming style used in this definition violates rules defined in
    "OMG IDL Style Guide" (ab/98-06-03).

    2. Naming style used in this definition is inconsistent with other parts
    of the CCM IDL, for example:

    module Components
    {
    valuetype PortDescription

    { public FeatureName name; public CORBA::RepositoryId type_id; }

    ;

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;
    }

    • suggested resolution : replace `cookieValue' with `cookie_value'
  • Reported: CORBA 3.0.2 — Wed, 12 Feb 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:12 GMT

multiple lifetime policies declaration issue

  • Key: CORBA35-60
  • Legacy Issue Number: 5870
  • Status: open  
  • Source: INRIA ( Nawel Sabri)
  • Summary:

    In section 4.2.5 of the CCM spec formal/02-06-65, it is said that "Servant lifetime policies may be defined for each segment within a component", but there is no way to do it. Lifetime policy is declared in the CCD descriptor of the component, as an attribute of the "servant" XML element, and is implicitly applied on all the segments of the component(when it is segmented) !

    Suggested resolution: to leave the servant element as it is, expressing a DEFAULT lifetime policy, and to add the same servant element as an optional child of the segment element. This will specify the lifetime policy of the segment and override the defautl one. DTD has to be changed as follows :

    <!ELEMENT segment
    ( segmentmember+
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

    becomes:

    <!ELEMENT segment
    ( segmentmember+
    , servant?
    , containermanagedpersistence?
    , extension*
    >
    <!ATTLIST segment
    name CDATA #REQUIRED
    segmenttag CDATA #REQUIRED >

  • Reported: CORBA 3.0.2 — Tue, 25 Feb 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA35-58
  • Legacy Issue Number: 5898
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In OMG document formal/02-06-65, in section "1.3.3 Component Body", there
    is this text:

    "Declarations for facets, receptacles, event sources, event sinks,
    and attributes all map onto operations on the component's equivalent
    interface. These declarations and their meanings are described in
    detail below."

    In the following sections, I see facets, receptacles, event sources,
    and event sinks described, but I see no mention of attributes.
    It would be usefult to have an example of attributes in an appropriate
    place, as outlined by section 1.3.3.

    In section "1.10 Configuration with Attributes", I see that configurators
    are described, but I see no example of using attributes directly
    to configure a component.

    It would be very useful to include a small example to illustrate
    how to configure a component directly by using attributes.

    Diego Sevilla Ruiz <dsevilla@ditec.um.es> gave this
    C++ example on the CCM mailing list ( http://moriarty.dif.um.es/mailman/listinfo/ccm ):

    ======================================================

    component Whatever

    { attribute long cacheMaxKb; }

    ;

    home WhateverHome manages Whatever
    {
    };

    // C++
    WhateverHome_var weh = // obtain ref
    Whatever_var we = weh->create();

    we->cacheMaxKb(200);

    we->configuration_complete();

    ======================================================

    I don't suggest that this example be used verbatim,
    but a similar example would be useful to have in the
    CCM spec.

  • Reported: CORBA 3.0.2 — Thu, 10 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA35-53
  • Legacy Issue Number: 5918
  • Status: open  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    In section 1.1.2 of the CCM specification:

    1.1.2 Ports
    ===========
    ..... The component model supports four basic kinds of ports:

    • Facets
    • Receptacles
    • Event sources
    • Event sinks
    • Attributes

    Well, that list includes five things, not four.

    So, is an attribute considered a port or not?

    The wording in this section needs to be clarified in the CCM
    specification, because it is not clear if an attribute
    is a port or not.

  • Reported: CORBA 3.0.2 — Mon, 28 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:11 GMT

Section 13C.1.3 Editorial

  • Key: CORBA35-2
  • Legacy Issue Number: 710
  • Status: open  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary: On page 9, paragraph beginning with "Within an interface...." should read "..attributes should appear after operations..."

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

issue on component supporting abstract interfaces

  • Key: CORBA35-54
  • Legacy Issue Number: 5910
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    The following information is sent in order for the specification to
    clearly state if components and local interfaces can support abstract
    interfaces (the specification is confusing on this point).

    CORBA 3.0.1 does not explicitely states if a component can support an
    abstract interface, thus it can be considered that it is possible. If so
    a big problem arises as local interfaces inheriting abstract ones is
    confusing in the specification.

    In addition, it is neither explicitely stated that provides and uses
    declarations can or cannot be of types defined through abstract
    interfaces. It does not seem to make sense for a port to be an abstract
    type. Facets will never be used by value, and an operation cannot
    (should not) return the reference of a facet or a valuetype (which would
    be in favor of provides to be defined using abstract interfaces).

      • Problem

    Consider the following definitions which are correct regarding
    formal/02-12-06:

    /* omg idl3 */

    abstract interface I

    { void foo () ; } ;


    component C supports I {
    } ;


    The mapping to OMG IDL2 of these definitions is not correct right now as
    they become:


    /* omg idl2 */


    abstract interface I { void foo () ; }

    ;

    interface C : Components::CCMObject, I { } ;

    local interface CCM_C : I { } ;

    According to formal/02-12-06, the last line may not be correct. Local
    interfaces may not inherit abstract interfaces (section 10.5.28). (I use
    may as it is confusing and can lead to various understanding of the
    spec.)

      • Potential solutions:

    1. State in the CORBA 3.0.1 that components cannot support abstract
    interfaces. In favor: Could ne considered as a minor change. Against: a
    component reference cannot be returned by an operation that can return
    an object by value or by reference. This solution looks cleaner that the
    second one from a software engineering point of view.

    2. Clearly state that components and local interfaces can support
    abstract interfaces. This use may be surprising from a software
    engineering point of view, but may be important for some users. This
    bring back the debate "quality vs powerfulness".

    In any case, I think it should be clearly stated if local interfaces may
    or may not inherit abstract ones.

  • Reported: CORBA 3.0.2 — Wed, 23 Apr 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

portability of CCM descriptors

  • Key: CORBA35-51
  • Legacy Issue Number: 6286
  • Status: open  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Sylvain Leblanc)
  • Summary:

    Identifier (FPI).

    These FPIs are required for the CAD, CSD, CCD and CPF DTDs.

    Proposed resolution:

    Adds the CCM DTDs on the OMG web site and adds the following text in the specification:

    • section 6.3, before subsection 6.3.1 :

    The CORBA Software Descriptor must refer to the DTD using the following statement: <!DOCTYPE softpkg PUBLIC "-//OMG//DTD CORBA Software Descriptor 3.0//EN" "http://www.omg.org/dtd/softpkg_3_0.dtd" />

    • section 6.4, before subsection 6.4.1 :

    The CORBA Component Descriptor must refer to the DTD using the following statement: <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.4.4:

    replace

    <!DOCTYPE corbacomponent SYSTEM "corbacomponen.tdtd">

    with

    <!DOCTYPE corbacomponent PUBLIC "-//OMG//DTD CORBA Component Descriptor 3.0//EN" "http://www.omg.org/dtd/corbacomponent_3_0.dtd" />

    • section 6.7, before subsection 6.7.1 :

    The Component Assembly Descriptor must refer to the DTD using the following statement: <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.7.1:

    replace

    <!DOCTYPE componentassembly SYSTEM "componentassembly.dtd">

    with

    <!DOCTYPE componentassembly PUBLIC "-//OMG//DTD Component Assembly Descriptor 3.0//EN" "http://www.omg.org/dtd/componentassembly_3_0.dtd" />

    • section 6.8, before subsection 6.8.1 :

    The Component Property File must refer to the DTD using the following statement: <!DOCTYPE properties PUBLIC "-//OMG//DTD Component Property File 3.0//EN" "http://www.omg.org/dtd/properties_3_0.dtd" />

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

How does an ORB implement Object::get_policy for PI defined policies?

  • Legacy Issue Number: 4065
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description for Object::get_policy (in the Core, section 4.3.7.1)
    states:

    "The get_policy operation returns the policy object of the specified
    type (see Policy Object on page 4-32), which applies to this object. It
    returns the effective Policy for the object reference. The effective
    Policy is the one that would be used if a request were made."

    For a policy defined by PI, I don't see anyway for the ORB to implement
    this operation correctly, since there isn't any way for it to know how
    to properly resolve any client override policies with the policy
    information stored in the IOR.

    When a invocation is actually in process, the ClientRequestInterceptor
    can use the information available in the ClientRequestInfo interface to
    get the client override and the IOR policy data and do the correct
    resolution before continuing with the request. However,
    Object::get_policy() needs to do the same type of thing, but it has no
    invocation context to do it in.

    I think the same problem also applies to the implementation of
    ClientRequestInfo::get_request_policy().

    I think we need a new interception point to do this work. Something
    like:

    local interface PolicyInterceptor

    { any determine_effective_policy(in PolicyInfo pi); }

    ;

    local interface PolicyInfo

    { readonly attribute Object target; readonly attribute Object effective_target; readonly attribute IOP::TaggedProfile effective_profile; IOR::TaggedComponent get_effective_component (in IOP::ComponentId id); IOP_N::TaggedComponentSeq get_effective_components (in IOP::ComponentId id); }

    ;

    If this turns out to be an acceptable solution, then we should also
    change ClientRequestInfo to:

    local interface ClientRequestInfo : RequestInfo, PolicyInfo

    { ... }

    ;

    and remove the redundant operations.

  • Reported: CORBA 2.4.1 — Sat, 18 Nov 2000 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:10 GMT

The association of entity component primary key and PSS key is unclear

  • Key: CORBA35-48
  • Legacy Issue Number: 6684
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Issue: The association of entity component primary key and PSS key is unclear. There is only one attribute as the primary key in the CCM entity component, PSS has no primary key. An entity can be identified uniquely by the PSS key, but currently PSS permits several keys, and each PSS key can be composed of several attributes. Consequently, it is difficult to establish association between entity component primary key and PSS key, and the create and find methods can not to be mapped to the corresponding methods of PSS.

  • Reported: CORBA 3.0.2 — Sat, 6 Dec 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:09 GMT

Generic connectivity for Receptacles, Emitters, Publishers

  • Key: CORBA35-45
  • Legacy Issue Number: 7556
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The CCMObject interface contains numerous operations for generic
    connection management (in addition to the type-specific operations
    defined by equivalent IDL for a component).

    However, there's a separate set of "connect" and "disconnect"
    operations for each kind of port, i.e., receptacles, emitters and
    publishers. This is inconvenient for generic software that treats
    ports generically, such as the deployment infrastructure in an
    implementation of the Deployment and Configuration specification.

    The set of operations might even get larger in the future, when
    Streams for CCM becomes available.

    I thus propose to add generic "connect_feature" and "disconnect_
    feature" operations that is able to interconnect compatible ports
    regardless of the type of port.

    Proposed resolution:

    In section 1.11.1, "CCMObject Interface," add the following two
    operations to the CCMObject interface:

    module Components {
    interface CCMObject : Navigation, Receptacles, Events

    { Cookie connect_feature (in FeatureName name, in Object connection) raises (InvalidName, InvalidConnection, AlreadyConnected, ExceededConnectionLimit); void disconnect_feature (in FeatureName name, in Cookie ck) raises (InvalidName, InvalidConnection, CookieRequired, NoConnection); /* other operations as before */ }

    ;
    };

    Add the following explanation to the same section:

    connect_feature

    The connect_feature operation connects the object reference
    specified by the connection parameter to the component feature
    specified by the name parameter. The feature must be either a
    receptacle, emitter or publisher port.

    If the feature identified by the name parameter is a receptacle
    port, the connect_feature operation acts equivalent to calling
    the connect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the connect_feature operation acts equivalent to calling
    the connect_consumer operation on the Events interface. A nil
    "cookie" value is returned.

    If the feature identified by the name parameter is a publisher
    port, the connect_feature operation acts equivalent to calling
    the subscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

    disconnect_feature

    The disconnect_feature operation dissolves the connection
    identified by the ck cookie to the component feature specified
    by the name parameter.

    If the feature identified by the name parameter is a receptacle
    port, the disconnect_feature operation acts equivalent to calling
    the disconnect operation on the Receptacles interface.

    If the feature identified by the name parameter is an emitter
    port, the disconnect_feature operation raises the InvalidConnection
    exception if a non-nil cookie is passed as the ck parameter;
    otherwise, it acts equivalent to calling the disconnect_consumer
    operation on the Events interface.

    If the feature identified by the name parameter is a publisher
    port, the disconnect_feature operation acts equivalent to calling
    the unsubscribe operation on the Events interface.

    If the feature identified by the name parameter is neither
    receptacle, emitter or publisher port, or if the component does
    not have any feature by that name, the InvalidName exception is
    raised.

  • Reported: CORBA 3.0.3 — Thu, 1 Jul 2004 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:09 GMT

"supports" keyword

  • Key: CORBA35-41
  • Legacy Issue Number: 9174
  • Status: open  
  • Source: nudt ( jhuang)
  • Summary:

    Issue: It is good to let CCM component definition can have operations directly, but not indirectly by "supports" keyword. The "supports" adds too much complexity when defining a compoment and compiler implementation

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:09 GMT

Contradictory sections in the CCM and Lightweight CCM specifications

  • Key: CORBA35-40
  • Legacy Issue Number: 10142
  • Status: open  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    I'd like to report an issue that exists in both the CORBA Component Model Specification (formal/06-04-01) and also the Lightweight CORBA Component Model specification (ptc/04-06-10) please.

    In section "6.11 Component Inheritance" of formal/06-04-01 there is the statement : "A derived component type may not directly support an interface."

    This same statement is made in "1.11 Component Inheritance" of ptc/04-06-10 and in "3.17.2.3 Component Inheritance" of the CORBA 3.0.3 spec (04-03-02).

    But, in both "6.3.2.4 Inheritance and supported interfaces" of formal/06-04-01 and "1.3.2.4 Inheritance and supported interfaces" of ptc/04-06-10 there is the following:

    "For a component declaration with the following form:

    component <component_name> : <base_name>
    supports <interface_name_1>, <interface_name_2>

    { … };


    the equivalent interface shall have the following form:
    interface <component_name>
    : <base_name>, <interface_name_1>, <interface_name_2> { … }

    ;"

    The above example is giving equivalent IDL for a declaration that the preceding statements regarding component inheritance say is not permitted. It should presumably be removed.

  • Reported: CORBA 3.0.3 — Fri, 25 Aug 2006 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:08 GMT

CCMHome should have a get_container method

  • Key: CORBA35-29
  • Legacy Issue Number: 6001
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for locating the container that created a home. The lack of a method to get a home's container is inconsistent with the rest of the CCM model. Furthermore, this method would be very useful as it would provide a means to navigate from a component to its ServerActivator, which is currently not possible.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); Container get_container(); }

    ;

    and add the operation description

    get_container

    The get_container operation returns a reference to the Container object that created this CCMHome

  • Reported: CORBA 3.0.2 — Thu, 17 Jul 2003 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:07 GMT

Traversal algorithm not sufficient

  • Legacy Issue Number: 2869
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Description:
    There may be some network topologies where the traversal
    algorithm is not sufficient for a firewall to find a server. This is due to
    an unstated assumption that all addresses within the outermost inbound
    firewall are addressable from the outermost inbound firewall. Consider for
    example the following topology:

    -----*Firewall
    B*-----Network B
    Internet -----Firewall A---------
    -----*Firewall
    C*-----Network C

    Service Network (DMZ)

    Assume that the addresses on the service network are
    globally routable addresses, Network B uses RFC 1597 addresses and Network C
    uses RFC 1597 addresses. This topology could be possible, say for a
    government agency that has sub-agencies that share some resources (service
    network) but maintain separately administrated networks. In this case the
    outermost inbound firewall for a server on Network B or C is Firewall A.
    However, when new target is invoked on Firewall A, it won"t know from the
    host address whether to open a connection to Firewall B or Firewall C.

    Proposed Solution:
    There are several possible solutions to this problem:
    1) Explicitly state the assumption described in the
    description section
    2) Mandate that implementations allow for the
    configuration of the next inbound firewalls
    3) Mandate that servers on Network B or C in such
    configurations use Firewall B or C as the outermost inbound firewall.

    There may be other solutions to this problem. These were
    the ones that immediately presented themselves.

  • Reported: CORBA 2.3.1 — Tue, 24 Aug 1999 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:05 GMT

Section number: 3.3.4 make factory creation operations conform to the IDL

  • Legacy Issue Number: 2585
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: make factory creation operations conform to the IDL style guide

    Proposed solution: change the capitalization and put in underscores between
    words

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:04 GMT

Title does not cover the use of SS7 as signaling transpor

  • Legacy Issue Number: 2583
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Problem: Title does not cover the use of SS7 as signaling transport. This case is
    not a TC interworking.

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:03 GMT

passthrough connection

  • Legacy Issue Number: 2261
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    I would like to get some clarification on the PASSTHROUGH/Untrusted Proxy
    issue.

    In page 4-45, the spec says "It is possible to support pass-through through
    multiple proxies. For example if in the above example there was another
    proxy B2 between B and C, during processing the new_target operation from A,
    B can try to establish a pass-through connection to C via a call to
    new_target on B2. If this fails, due to NO_PERMISSION for example, B should
    fall back to try to connect through B2 using the NORMAL mode.".

    If the connection (B - B2) is NORMAL, the whole connection is not a
    PASSTHROUGH since the client will see the B2"s identity in the SSL session.
    Should B throw back the NO_PERMISSION to the client if B get NO_PERMISSION
    from B2 for PASSTHROUGH connection? If the answer is no (seems to me that is
    what spec says), does this mean that it is possible that the client request
    a PASSTHROUGH connection but actually get a NORMAL connection?

  • Reported: CORBA 2.2 — Wed, 16 Dec 1998 05:00 GMT
  • Updated: Wed, 6 Dec 2023 23:03 GMT

"Tool" issue for IDL compilers too complex

  • Legacy Issue Number: 1932
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 2. The current language mapping mixes both generated code with user
    written code in the same source file. This poses a very complex "tool"
    issue for IDL compilers which is unnecessarily complex.

  • Reported: CORBA 2.2 — Tue, 1 Sep 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:03 GMT

P 5-44: use of base type

  • Legacy Issue Number: 1697
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-44, a new production has been added to the grammar to allow the use of ValueBase to be used as a base type. (<base_type_spec> ::= ... | <value_type_spec). My concern is that all other types of base type specifiers have a PrimitiveKind. However, either you guys forgot or didn"t want to have, that a value or ValueBase does not have a corresponding PrimitiveKind enum value. This becomes essential later on when we want to go into the InterfaceRepository, and find that some type is a ValueBase, we will need to know this. The easiest way to do this could be through a PrimitiveDef, where it"s def_kind attribute is a dk_Primitive, and to satisfy the IDLType interface for they type attribute, we could return a TCKind of tk_value or tk_ValueBase. An alternate could be to not go the PrimitiveDef route and use a different approach. Perhaps we could have a method in the Container or Repository interfaces called create_ValueBase. This would be much like creating an unnamed type such as a sequence, a string, primitive, or array (i.e. get_primitive(), create_string(), etc. in the Repository interface). This is less likely though because create_ValueBase would need to return a type. We could return a ValueDef, but create_ValueBase wouldn"t have enough information passed to it to create on and besides, a ValueDef is named. We could have a whole new definition interface called ValueBaseDef, but this way is a pain if you ask me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:02 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

  • Legacy Issue Number: 1699
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1. There are no write_Abstract and read_Abstract methods on
    DataInputCtream and DataInputStream. This looks like an oversight
    to me.

  • Reported: CORBA 2.2 — Mon, 20 Jul 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 23:00 GMT

Narrowing from abstract interfaces

  • Legacy Issue Number: 1382
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that we have no way of narrowing
    from abstract interfaces to non-abstract interfaces and value
    classes. In Java, the helper"s narrow method has a signature of
    org.omg.CORBA.Object, so it cannot take an abstract interface
    type. In C++, the generated classes for abstract interfaces
    have an _narrow method with the right signature (taking an
    AbstractBase_ptr), but generated classes for values and regular
    interfaces don"t have such a method. It seems like we would
    need to add overloaded narrow methods in all these places to
    make this work as envisaged in (for example) numbered paragraph
    3 of section 8.3.

  • Reported: CORBA 2.2 — Mon, 18 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private

  • Legacy Issue Number: 1380
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.3.1.2 says that non-public data members should be mapped
    so that "the private part of the state is only accessible to the
    implementation code and the marshaling routines."

    Section 6.3.1 says that non-public data members are mapped to
    private instance variables.

    The problem is that the Java marshaling routines are in the Helper
    class, which cannot see private instance variables in the value class.

    The proposed solution is to modify the Java mapping to map the default
    IDL state to the default (package visibility) Java state instead of
    private.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

No portable way to obtain list of type safe repository IDs

  • Legacy Issue Number: 1352
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In Section 5.9.1 on p. 5-55 of orbos/98-01-18, the spec says "the sending context is responsible for listing the repository ID"s for all the base types to which it is safe to truncate the real
    type, going up (the derivation hierarchy) to, and including if appropriate the formal type". Currently, there is no portable way to obtain the list of type safe repository ID"s
    from within the marshaling engine in order to be marshaled on-the-wire properly.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Keyword identifiers (04)

  • Legacy Issue Number: 1313
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    4) Finally, the keyword identifier approach gives the impression that
    IDL extensions can be made at no cost, which is simply not true.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Keyword Identifiers(03)

  • Legacy Issue Number: 1312
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications. It specifies that a keyword identifier
    is a word that is treated as a keyword only when used in a keyword
    context, and is otherwise treated as a regular identifier.
    3) It allows IDL specifications that, while not unparseable, are
    highly ambiguous, especially to a human reader. For example, Jeff
    recently posted answers on how the following is to be parsed, but
    there is no way that someone reading the OBV spec would be able to
    figure out the rules he gave:

    interface public

    { ... };
    interface custom { ... }

    ;
    value safe

    { ... };

    value foo : safe { ... }

    ; // Is this legal or an error?
    value foo2 : safe safe

    { ... }

    ; // What about this?
    value foo3

    { public x; // Is this legal or an error? public public y; // What about this? custom value(); // Is this a valid operation or a syntax error? }

    ;

    While all of these constructs can all be parsed using the appropriate
    number of look-ahead tokens (by the way, the grammar is not LALR(1)
    as the OBV Spec suggests), it is hard to read and even harder to
    parse correctly. Many IDL compilers still fail to properly implement
    the name lookup rules in the existing CORBA specification, and adding
    keyword identifiers will only make that situation much worse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Keyword identifiers (02)

  • Legacy Issue Number: 1311
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.It allows IDL specifications that are simply unparseable. For example:

    interface ValueBase {};
    struct S

    { ValueBase v; }

    ;

    This is ambiguous because the compiler cannot know whether the type
    of struct member "v" refers to the ValueBase interface or the
    ValueBase keyword identifier.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Keyword identifiers (01)

  • Legacy Issue Number: 1310
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The Objects By Value (OBV) Specification (orbos/98-01-18) introduced
    the concept of "keyword identifiers" in an effort to avoid breaking
    existing IDL specifications.
    1) First and foremost, the addition of keyword identifiers changes
    the IDL grammar into a context-sensitive grammar, which are known to
    be notoriously difficult to parse.

  • Reported: CORBA 2.2 — Fri, 8 May 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Reconcile RMI/IIOP upcall and helper class

  • Legacy Issue Number: 1286
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

p 5-50 2nd paragraph of 5.6.2.1

  • Legacy Issue Number: 1283
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: p 5-50, 2nd paragraph of 5.6.2.1: it seems to me that in existing
    ORBs, version inconsistencies between, eg, structs, may already corrupt
    memory. The difference now is that preservation of values sharing
    could make matters worse. It would be great to have this issue better
    explained.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Editorial: p 5-50

  • Legacy Issue Number: 1282
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

Suggested changes (to section 5.4.1 of orbos/98-01-18) are

  • Legacy Issue Number: 1280
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Suggested changes (to section 5.4.1 of orbos/98-01-18) are:

    1. Remove the ``;"" from the end of the definition of <value>. (It"s
    in the modified <definition>.)

    2. Remove [ <supports_token> <scoped_name>

    { ``,"" <scoped_name> }

    * ]
    from the <value_inheritance_spec> non-terminal move it to a new
    non-terminal, <value_supports_spec>.

    3. Change the definitions of <value_abs_dcl> and <value_header>,
    replacing [ <value_inheritance_spec> ] by [ <value_inheritance
    _spec ] [ <value_supports_spec> ].

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:59 GMT

New lexical type - Keyword Identifie

  • Legacy Issue Number: 1253
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 5.4.2 "New lexical type - Keyword Identifier" the statement is made that
    "new keyword identifiers should only be added such that the resulting grammar is
    still easily parsable, e.g. is LALR(1).". It seems to me that is not true even for
    the newly introduced keyword identifiers in many cases.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:57 GMT

"Safe" keyword identifier issue

  • Legacy Issue Number: 1251
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Above rules seem to imply that the
    "safe" keyword identifier can only occur before the first scoped name in the
    <value_parent_spec>, whereas I think the actual intent is that it can only
    occur before a non-abstract value type, of which there is at most one in the
    list, although it need not be the first. Since this can"t be expressed in the
    rules exactly, I would simply amend the rule to be:

    <value_parent_spec> ::= ":" [ <safe_token> ] <scoped_name>

    { "," [ <safe_token> ] <scoped_name> }

    *

    and simply express the semantic restriction in the text. There already is a
    brief mention of the semantics of the "safe" keyword in section 5.3.2.5
    "Substitutability Issues". Perhaps another sentence or two would help clarify
    the intended usage.

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:57 GMT

add a sequence of CCMHome typedef sequence CCMHomes;

  • Key: CORBA35-38
  • Legacy Issue Number: 13151
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We would like to add a request to add the following IDL type. Just add a sequence of CCMHome typedef sequence<CCMHome> CCMHomes;

  • Reported: CORBA 3.1 — Wed, 10 Dec 2008 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:45 GMT

The D&C IDL part doesn't match 06-04-02.

  • Key: CORBA35-39
  • Legacy Issue Number: 10582
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The D&C IDL part doesn't match 06-04-02. For example TargetManager is not correctly in 06-04-01 and has its errors in 06-04-02

  • Reported: CORBA 3.0.3 — Tue, 9 Jan 2007 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:44 GMT

NVList Section: 7.5

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

    The NVList has a count, which is defined as long, it would be better to make this an unsigned long. This has impact on ORB::create_list, change the type of argumetn count to unsigned long. Also update NVList::get_count to have an unsigned long argument.

  • Reported: CORBA 3.0.3 — Fri, 15 Jul 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:43 GMT

Page: 21-5

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

    In the Interceptor interface there is a destroy method which can throw a system exception just like all other corba calls. What is the behaviour when the orb shutdown is done and an Interceptor::destroy() call throws an exception? Should the ORB ignore this exception and continue the shutdown or should it return the exception to the caller. I would except ignore the exception and continue but the spec doesn't describe the behaviour.

  • Reported: CORBA 3.0.3 — Tue, 21 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:43 GMT

Section: Appendix A

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

    The tags for unreliable multicast are missing. // The following are defined in 03-01-11 const ProfileId TAG_UIPMC = 3; const ComponentId TAG_GROUP = 39; const ComponentId TAG_GROUP_IIOP = 40;

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:42 GMT

Section: 21.3.14.11

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

    The minor code for add_reply_service_context is not correct. The spec says: Indicates the behavior of this operation when a service context already exists with the given ID. If false, then BAD_INV_ORDER with a standard minor code of 11 is raised. If true, then the existing service context is replaced by the new one. The minor code should be 15.

  • Reported: CORBA 3.0.3 — Wed, 8 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:41 GMT

Section: 4.5.2

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

    This corba spec describes POAManagerFactory. I have been searching on the web and it seems for example Orbacus has the possibility to do a resolve_initial_references ("POAManager"). This seems not possible with the latest corba spec. This seems an usefull extension. The only option there is now is to get the RootPOA, get from there the POAManagerFactory and use that again.

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:41 GMT

Section: 11.3.9.16

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

    For activate_object_with_id it is described that when SYSTEM_ID has been set and the object id was not generated by this system or tis POA we throw a BAD_PARAM, but the minor code is not described. Shouldn't this have an unique minor code?

  • Reported: CORBA 3.0.3 — Thu, 16 Mar 2006 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:41 GMT

Page: 21-43

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

    The following methods are not described in this chapter: Object make_object (in string repository_id, in ObjectId id); IOP::TaggedProfileSeq make_profiles (in string repository_id, in ObjectId id); These are mentioned in 21.10.3

  • Reported: CORBA 3.0.3 — Tue, 25 Oct 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:40 GMT

Section: 22.11.1

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

    In the C++ example code of 22.11.3 Messaging::ExceptionHolder_ptr is used, for valuetypes there is no _ptr, the could should read Messaging::ExceptionHolder *

  • Reported: CORBA 3.0.3 — Mon, 17 Oct 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:39 GMT

Section: 22.16/

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

    There are some issues with the definition of ExceptionHolder. In 22.16 it is as below, see the raise_exception_with_list, this seems to have two arguments here, in 22.7 there is just one argument. The same problem also appears in the draft 3.1 spec. Also, there is no CORBA::ExceptionList defined in the spec at all, there is Dynamic::ExceptionList but no CORBA::ExceptionList. valuetype ExceptionHolder { void raise_exception() raises (UserExceptionBase); void raise_exception_with_list( in CORBA::ExceptionList exc_list) in Dynamic::ExceptionList exc_list) raises (UserExceptionBase); private boolean is_system_exception; private boolean byte_order;

  • Reported: CORBA 3.0.3 — Wed, 5 Oct 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:38 GMT

Section: 11.3.9

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

    The CORBA spec describes the following about the wait_for_completion parameter of the POA::destroy call: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA belonging to the same ORB as this POA, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA belonging to the same ORB as this POA, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur. We have a use case where we have an ORB with two POA's, A1 and B1, each POA again has a child A2 and B2. In case we get a request for a servant of A2 to destroy POA B2 and we specify TRUE for wait_for_completion then we get an exception back, but this doesn't seem locally. We understand that when we want to destroy A1 when handling a request using a servant of A2 that we get an exception at that moment. We propose the change the description as following: The wait_for_completion parameter is handled as follows: • If wait_for_completion is TRUE and the current thread is not in an invocation context dispatched from some POA that is a child of this POA or from this POA itself, the destroy operation returns only after all active requests have completed and all invocations of etherealize have completed. • If wait_for_completion is TRUE and the current thread is in an invocation context dispatched from some POA that is a child of this POA or from the POA itself, the BAD_INV_ORDER system exception with standard minor code 3 is raised and POA destruction does not occur.

  • Reported: CORBA 3.0.3 — Mon, 26 Sep 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:37 GMT

Section: 21.4.3.1

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

    In case get_slot is called from withing an ORB itializer chapter 21.4.3.1 says a BAD_INV_ORDER with minor code 10 is thrown, this should be 14 as mentioned also in 21.7.2.11

  • Reported: CORBA 3.0.3 — Mon, 6 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:36 GMT

Section: 21.9.1

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

    The draft document says the following in 21.9.1. The description about the type of exceptions sounds very vague. Shouldn't the spec be more detailed, which type of exceptions should be ignored specifically? Any exceptional return from the invocation of any operation of the ORBInitializer interface other than those resulting from the failure to instantiate a portable interceptor object shall result in the abandonment of the ORB initialization and destruction of the ORB. Any ORBInitializer implementation that needs the ORB to ignore any thrown exceptions can simply catch and discard them itself.

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:36 GMT

Section: 21.7

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

    In the draft 3.1 spec chapter 21.7 says the following: An Interceptor's behaviour may itself be modified by one or more Interceptor Policies. These Policy objects are created using a call to ORB::create_policy and are associated with an Interceptor during registration (see Section 21.7.2, ORBInitInfo Interface). All Policy interfaces defined in this section are local. The ORB can be accesed via the implicit get_orb operation of ORBInitInfo. The ORBInitInfo is passed on the pre_init and post_init call of the ORBInitializer but what should be the orb in the pre_init call? The orb is not initialized at that moment? Shouldn't it say that calling get_orb on the ORBInitInfo in the pre_init call gives the default exception that is given when get_orb is called on a local object?

  • Reported: CORBA 3.0.3 — Wed, 1 Jun 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:35 GMT

update the spec to not used anonymous types

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

    The spec describes that anonymous types are deprecated and will be removed in the future (as below), but this is used throughout the spec. Before deprecating this fully, update the spec to not used anonymous types: >From 3.11.6 IDL currently permits the use of anonymous types in a number of places. For example: struct Foo

    { long value; sequence<Foo> chain; // Legal (but deprecated) }

    Anonymous types cause a number of problems for language mappings and are therefore deprecated by this specification. Anonymous types will be removed in a future version, so new IDL should avoid use of anonymous types and use a typedef to name such types instead. Compilers need not issue a warning if a deprecated construct is encountered.

  • Reported: CORBA 3.0.3 — Wed, 18 May 2005 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:34 GMT

Section: 13.6.2

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

    Update: struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; to struct IOR

    { string type_id; TaggedProfileSeq profiles; }

    ; And also use CORBA::OctectSeq instead of sequence<octet>

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:30 GMT

Section: 7.4

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

    Minor formatting issue in: abstract valuetype Pollable

    { boolean is_ready( in unsigned long timeout ); PollableSet create_pollable_set( ); }

    ; boolean is_ready is in the wrong font in the idl overview

  • Reported: CORBA 3.0.3 — Fri, 25 Mar 2005 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:30 GMT

struct PolicyValue

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

    This section defines struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; Which should be as below because anonymous types are deprecated struct PolicyValue

    { CORBA::PolicyType ptype; CORBA::OctetSeq pvalue; }

    ;

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:29 GMT

Third line of 23.1.3.4, ACTIVE must be bold

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

    Third line of 23.1.3.4, ACTIVE must be bold

  • Reported: CORBA 3.0.3 — Sun, 30 Sep 2007 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:29 GMT

Proposal to change PortableInterceptor::AdapterState to a real enum

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

    Proposal to change PortableInterceptor::AdapterState to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum AdapterState

    { HOLDING, ACTIVE, DISCARDING, INACTIVE, NON_EXISTENT }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:28 GMT

Proposal to change PortableInterceptor::ReplyStatus to a real enum

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

    Proposal to change PortableInterceptor::ReplyStatus to a real enum. Now it is a short with constant values, but this means there is no real relationship between the type and the possible values as possible with an enum. With for example C++ we then can let the compiler check if we don't use incorrect values. module PortableInterceptor { enum ReplyStatus

    { SUCCESSFUL, SYSTEM_EXCEPTION, USER_EXCEPTION, LOCATION_FORWARD, TRANSPORT_RETRY, UNKNOWN }

    ; };

  • Reported: CORBA 3.0.3 — Tue, 25 Sep 2007 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:28 GMT

Section: 15.4.2/16.4.1

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

    In 15.4.2 and 16.4.1 get_implementation is mentioned, but this method is nowhere else in the spec. Should this method be there? So far as I can see this is deprecated and should be removed.

  • Reported: CORBA 3.0.3 — Fri, 7 Sep 2007 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:27 GMT

Section: 21.3.13

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

    Table 21-1 has the following note: When ClientRequestInfo is passed to send_request, there is an entry in the list for every argument, whether in, inout, or out. But only the in and inout arguments will be available. What is the behaviour when I request an out value? It says only that in/inout are available, but when I have an argument that is of out and I do get the value, do I then get an empty value (which could lead to a crash when using it), do I get an exception? That must be clearly specified by the spec

  • Reported: CORBA 3.0.3 — Tue, 13 Mar 2007 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:27 GMT

16.10 lists register_initial_reference

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

    16.10 lists register_initial_reference. It would be usefull for dynamic systems to also have a unregister_initial_reference (in ObjectId id).

  • Reported: CORBA 3.1 — Mon, 3 Nov 2008 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:26 GMT

add interface ORB { Object string_to_object ( in wstring str ); };

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

    We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB

    { Object string_to_object ( in wstring str ); }

    ;

  • Reported: CORBA 3.0.3 — Sun, 21 Sep 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:25 GMT

add CORBA::ORB::arg_list

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

    For a 24x7 system that doesn't shutdown and gets reconfigured it would be useful if we could for example change "-ORBDefaultInitRef" after the ORB has been initialized. That then would be used for any objects resolved after that. Maybe we could add CORBA::ORB::arg_list (inout arg_list argv); Which would change the arglist

  • Reported: CORBA 3.0.3 — Mon, 11 Aug 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:25 GMT

Section 13.7 ServiceContext

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

    ServiceContext is defined as: struct ServiceContext

    { ServiceId context_id; sequence <octet> context_data; }

    ; Anonymous types are deprecated, this should be struct ServiceContext

    { ServiceId context_id; CORBA::OctetSeq context_data; }

    ;

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:24 GMT

Section: 21.7.3

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

    This chapter defines register_orb_initializer. This itself is ok, but at the moment we have a 24*7 system and we get a new ORBInitializer shipped in for example a DLL we maybe want to get rid of a certain orbinitializer that we registered earlier. This is currently not possible, we propose to add an unregister_orb_initializer which makes it possible to unregister an orbinitializer again

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:23 GMT

Section: 4.8.1

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

    The corba spec defines a lot of policies. In 4.8.5 client exposed policies are listed. We do have several of them, also policies could be applied at several levels, but some of them can't be applied to each level. To our idea the scope at which policies can be applied should not only be in the possible, but also part of the policy itself. That way application code and the corba orb could check this. Maybe add this to policy typedef unsigned long PolicyScope; const PolicyScope POLICY_SCOPE_OBJECT = 0x01; const PolicyScope POLICY_SCOPE_CURRENT = 0x02; const PolicyScope POLICY_SCOPE_SCOPE = 0x04; const PolicyScope POLICY_SCOPE_POA = 0x08; const PolicyScore POLICY_SCOPE_CLIENT_EXPOSED = 0x10; Then add to the interface Policy readonly attribute PolicyScope policy_scope; This attribute can then be set in the policy with the values above as bitmask. This can be documented clearly in the documentation, orbs can check this, etc.

  • Reported: CORBA 3.0.3 — Wed, 25 Jun 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:22 GMT

move struct to IOP module

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

    The CORBA spec defines the following types to proposage messaging qos. This is really nothing more then propagating policies values. struct PolicyValue

    { CORBA::PolicyType ptype; sequence<octet> pvalue; }

    ; typedef sequence<PolicyValue> PolicyValueSeq; This is now in the Messaging module, but the propagation of policy values is something that we want to use for ZIOP but also seems usable for other libraries. Instead of duplicating this struct to different modules I propose to move this to the IOP module.

  • Reported: CORBA 3.0.3 — Tue, 24 Jun 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:21 GMT

Add create_policy with just the type as argument

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

    For several cases it would be helpful to have a:

    Policy create_policy(
    in PolicyType type) raises(PolicyError);

    The name of the method has to change, to not conflict with the existing method

  • Reported: CORBA 3.1 — Thu, 1 Mar 2012 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:21 GMT

context should be local interface

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

    The context has to be define as local interface instead of a regular interface

  • Reported: CORBA 3.1 — Thu, 12 Jan 2012 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:20 GMT

interface ORB should be local

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

    The ORB is intended to be a local object, it is not to be used outside of the process, so it should be a local interface

  • Reported: CORBA 3.0.3 — Tue, 7 Jun 2011 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:20 GMT

Make anonymous types illegal

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

    the specification already deprecated anonymous types, but to our idea it would be time to update the specification to say that anonymous types are illegal and remove all references to them

  • Reported: CORBA 3.0.3 — Wed, 2 Mar 2011 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:20 GMT

Appendix A

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

    The overview of all system exceptions is missing several ones which seem to be availalble in http://www.omg.org/docs/omg/03-01-04 For example NO_IMPLEMENT_TABLE minor code 8 is missing

  • Reported: CORBA 3.0.3 — Fri, 4 Feb 2005 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:19 GMT

Section: 4.3.13

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

    The spec describes respository_id which should be repository_id. Is on two places, in 4.3.14 and 4.3

  • Reported: CORBA 3.0.3 — Thu, 3 Feb 2005 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:18 GMT

The POA state inactive is not used consistent.

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

    The POA state inactive is not used consistent. On several places it is called deactivated instead of inactive. For example in 11.3.8.2, in the transient bullet, it mentions: "Once the POA's POAManager enters the dactivated state". Chapter 11.3.2.1 describes clearly the states are: active, inactive, holding and discarding. I would propose to scan the complete spec for these incorrect POA Manager state.

  • Reported: CORBA 3.0.3 — Wed, 1 Dec 2004 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:18 GMT

argument of the set_servant call has a small typo

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

    The argument of the set_servant call has a small typo, it must be p_servant to match the full IDL spec some pages further

  • Reported: CORBA 3.0.3 — Tue, 2 Nov 2004 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:17 GMT

change in the POAManager

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

    I would propose to change in the POAManager the following: State get_state(); string get_id(); to readonly attribute State the_state; readonly attribute string the_id; The get method just hide the fact that this are readonly attributes

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:15 GMT

Add a typedef for the POAManager id

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

    Add a typedef for the POAManager id and use this throughout the spec for POAManager, POAManagerFactory and IORInterceptor add typedef string POAManagerId change in POAManager string get_id(); to POAManagerId get_id(); Or better (see other issue). readonly attribute POAManagerId the_id;

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:15 GMT

methods on the POA

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

    A lot of the methods on the POA which have USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER as policies don't describe in detail what should happen when one of these policies is set, but no default servant/servant manager is set. For example reference_to_servant, when USE_DEFAULT_SERVANT is set and default servant is registered we return the default servant, but what when no default servant is set, is then the ObjectNotActive the correct exception? Shouldn't this be something like a system exception (bad inv order, obj adapter or something like that?)

  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Updated: Wed, 6 Dec 2023 22:14 GMT

Section: 15.4.5.1 struct has to be updated

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

    this section says: // GIOP 1.0 struct LocateRequestHeader_1_0

    { // Renamed LocationRequestHeader unsigned long request_id; sequence <octet> object_key; }

    ; Anonymous types are deprecated so this struct has to be updated

  • Reported: CORBA 3.0.3 — Tue, 23 Sep 2008 04:00 GMT
  • Updated: Wed, 6 Dec 2023 22:13 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, 6 Dec 2023 22:10 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, 6 Dec 2023 22:10 GMT

ConfigValues to a std map

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

    It would be a much easier API for the user when ConfigValues would be a IDL map of FeatureName and a any

  • Reported: CORBA 3.4 — Wed, 16 Aug 2023 07:27 GMT
  • Updated: Wed, 6 Dec 2023 22:06 GMT

CCMHome should have a get_components method

  • Key: CORBA35-28
  • Legacy Issue Number: 6438
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The CCMHome interface does not provide a mechanism for obtaining references to all CCMObjects that the home has created (those that have not been removed). The lack of a method to get all the components created by a home is inconsistent with other sections of the CCM model (specifically the deployment module APIs). Furthermore, this method would be very useful as it would provide a mechanism for querying a Container for all existent components.

    Resolution:

    Replace the following text in formal/02-06-05 on page 1-41

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); }

    ;

    with

    typedef sequence<CCMObject> CCMObjects;

    interface CCMHome

    { CORBA::IRObject get_component_def(); CORBA::IRObject get_home_def (); void remove_component ( in CCMObject comp) raises (RemoveFailure); CCMObjects get_components(); }

    ;

    and add the operation description

    get_components

    The get_components operation returns a sequence of all existent CCMObject references (i.e. those that have not been removed) created by this CCMHome.

  • Reported: CORBA 3.0.2 — Wed, 5 Nov 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 20:19 GMT

HomeConfigurator should not extend CCMHome

  • Key: CORBA35-26
  • Legacy Issue Number: 5769
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Document formal/02-06-05 on page 1-49 states the following:

    "The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly."

    The first statement does not offer a clear interpretation when considering the language mapping for homes. If the implementation of a component type's home optionally supports HomeConfigurator how is this information defined in IDL? Should the component type's home definition support HomeConfiguration? This would seem to be the proper interpretation but that leads to problems in the language mapping of the defined home. In section 3.3.3.6 on page 3-45

    Home Explicit Executor Interface

    The home explicit executor callback interface is defined by the following rules:

    1. For each home <home name>, a local explicit executor interface with the same
    name as the home, but with a prefix of "CCM_" and a postfix of "Explicit" is
    defined.

    2. The explicit executor interface contains all attributes and operations declared by the
    home.

    3. If the home has a base with a name of <base name>, the explicit executor
    interface inherits CCM_<base name>Explicit. If the home does not have a base,
    the explicit executor interface inherits Components::HomeExecutorBase.

    4. If the home has supported interfaces, they are inherited by the explicit executor
    interface.

    5. Additional operations are added to the explicit executor interface for factories and
    finders, see below.

    Item 4 would imply that the home explicit executor must include operations defined in both HomeConfigurator and CCMHome since HomeConfigurator extends CCMHome. This is clearly not the intended behavior of the home explicit executor since it specifically excludes any direct inheritance of CCMHome.

    Resolution

    The inheritance of CCMHome by HomeConfiguration should be removed since it is implied that every home will extend CCMHome and home definitions in IDL would then be able to explicitly support HomeConfiguration without the extra baggage of the CCMHome interface. Furthermore, the language mapping does not properly handle a component home that supports HomeConfiguration (if it extends CCMHome) since the component executor would include all CCMHome operations. The language mapping would work fine if HomeConfiguration did not extend CCMHome.

    Replace text in formal/02-06-05 on page 1-49

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. The HomeConfiguration interface is derived from
    Components::CCMHome. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    with

    The implementation of a component type's home object may optionally support the
    HomeConfiguration interface. In general, the HomeConfiguration interface is
    intended for use by an agent deploying a component implementation into a container,
    or an agent deploying an assembly.

    Replace IDL in formal/02-06-05 on page 1-49

    module Components {
    interface HomeConfiguration : CCMHome

    { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); };
    };


    with


    module Components {
    interface HomeConfiguration { void set_configurator (in Configurator cfg); void set_configuration_values ( in ConfigValues config); void complete_component_configuration (in boolean b); void disable_home_configuration(); }

    ;
    };

  • Reported: CORBA 3.0.2 — Mon, 2 Dec 2002 05:00 GMT
  • Updated: Wed, 6 Dec 2023 20:18 GMT

Generic port connections

  • Key: CORBA35-24
  • Legacy Issue Number: 5852
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I propose to introduce generic operations that allow
    interconnecting ports regardless of their type. This
    would ease generic programming.

    The first part of the proposal is to allow generic
    usage of the "connect" and "disconnect" operations
    that are (currently) in the Receptacles interface,
    i.e. to extend the functionality to not only work
    on receptacles, but also on event source ports
    (emits and publishes keywords).

    The names "connect" and "disconnect" are appropriate
    for any kind of port, and their signatures are the
    same as "subscribe" and "unsubscribe" in the Events
    interface.

    The second part of the proposal is to introduce a
    new operation "get_port" into the CCMObject interface.
    This operation would take a FeatureName parameter and
    return the object reference associated with that
    facet or event sink.

    So I propose the following steps:

    1.) Allow connect, disconnect and get_connections to
    operate on event source ports, and introduce a
    get_port operation.
    This change would be backwards compatible.

    2.) Move connect, disconnect and get_connections from
    the now inappropriate Receptacles interface into
    the CCMObject interface. This step might cause
    minor, easily fixable breakage for software that
    widens an object reference to Receptacles instead
    of CCMObject. (I don't think any such software
    exists, it's more of a theoretical issue.)

    3.) Discourage, then remove the "subscribe" and
    "unsubscribe" operations in the Events interface.
    They don't offer any more type safety than connect
    and disconnect.

    I believe that these changes would also be of interest
    for slimming down CCM for the Lightweight CCM RFP, and
    in light of the Streams for CCM RFP (which will likely
    add another port type that needs interconnecting).

    This change does not have any impact on component
    implementations. The change to CCM implementations
    (ORBs) is neglegible (I would expect a day to make
    these changes in MicoCCM, another day to test them).

    If there is general agreement on this issue, I will
    draft the text updates.

  • Reported: CORBA 3.0.2 — Thu, 6 Feb 2003 05:00 GMT
  • Updated: Wed, 6 Dec 2023 20:17 GMT

Add && setter

  • Key: CPP1117-28
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    For the optional mapping example a `void age(IDL::optional<float>&&)` is lacking, like described for some types in chapter 6.14

  • Reported: CPP11 1.6b1 — Tue, 31 Oct 2023 10:14 GMT
  • Updated: Tue, 7 Nov 2023 16:01 GMT


Formatting c++/idl in text

  • Key: CPP1117-26
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Within the text of chapter 6.31/6.32 (IDL4) all C++/IDL should use a different font to make it clear it is code, just as in the other chapters.

  • Reported: CPP11 1.6b1 — Tue, 31 Oct 2023 08:19 GMT
  • Updated: Tue, 7 Nov 2023 16:00 GMT

Fix bitset mapping

  • Key: CPP1117-24
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For anyone using the class mapping of a structure the spec should also provide a class mapping for a bitset, that way they have a consistent API. Also why is a inherited bitset not mapped to C++ inheritance, by removing the inheritance the inheritance relation can't be used in C++ also

  • Reported: CPP11 1.6b1 — Tue, 22 Aug 2023 07:26 GMT
  • Updated: Mon, 2 Oct 2023 22:38 GMT

Enumeration value ESTIMATED used twice in the same package

  • Key: C2INAV13-3
  • Status: open  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Using the value ESTIMATED for both accuracy_derivation_type and navigation_derivation_kind_type causes problems in some programming languages; it is also better practice to be more descriptive.

  • Reported: C2INAV 1.2b1 — Mon, 24 Jul 2023 14:26 GMT
  • Updated: Fri, 28 Jul 2023 15:37 GMT

Enumeration value ESTIMATED used twice in the same package

  • Key: C2INAV13-2
  • Status: open  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Using the value ESTIMATED in accuracy_derivation_type and navigation_derivation_kind_type causes problems when mapped to some programming languages; it is also better practice to be more descriptive.

  • Reported: C2INAV 1.2b1 — Mon, 24 Jul 2023 14:24 GMT
  • Updated: Fri, 28 Jul 2023 15:37 GMT

C2INav Model refers to an old OARIS Common Types package

  • Key: C2INAV13-1
  • Status: open  
  • Source: BAE SYSTEMS ( Mr. Ollie Newman)
  • Summary:

    The C2INav Model refers to a package defined by OARIS 1.1.
    OARIS 2.0 is about to be published and there are 2.1 RTF & 3.0 FTF in progress.

  • Reported: C2INAV 1.2 — Thu, 20 Jul 2023 09:09 GMT
  • Updated: Thu, 20 Jul 2023 09:09 GMT

Improve wording

  • Key: CPP13-82
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec has the following sentence:

    The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.

    This is not really clear and should be improved, maybe

    The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.

  • Reported: CPP 1.3 — Wed, 29 Mar 2023 07:35 GMT
  • Updated: Fri, 31 Mar 2023 18:26 GMT

Improve wording

  • Key: CPP1116-38
  • Status: open  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec has the following sentence:

    The _d discriminator modifier can only be used to set the discriminant to a value within the same union member.

    This is not really clear and should be improved, maybe

    The _d discriminator modifier can only be used to set the discriminant to a value that has the same union member as currently selected.

  • Reported: CPP11 1.6b1 — Wed, 29 Mar 2023 06:48 GMT
  • Updated: Fri, 31 Mar 2023 18:25 GMT

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


LCC ontologies and reference data should be refactored to use the Commons library

  • Key: LCC13-6
  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The Commons Ontology Library was recently published, and provides a set of classes and properties, such as identifier, that are more broadly useful than they are as embedded concepts in LCC. The LCC ontologies and reference data should be revised to reuse Commons rather than specifying these concepts and relationships locally.

  • Reported: COMMONS 1.0 — Fri, 10 Feb 2023 19:18 GMT
  • Updated: Fri, 10 Feb 2023 19:18 GMT

${issue.summary}

  • Legacy Issue Number: 473
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 472
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 471
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Thu, 9 Jan 1997 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

messaging router issue

  • Legacy Issue Number: 5621
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is a messaging router supposed to do if it receives multiple
    requests from a client with more than one type of QueueOrderingPolicy
    value? (Is this legal? Is it legal to have more than one QueueOrdering
    bit set in a single request?) How can it sort on priority, FIFO, and
    deadline simultaneously?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

module SendingContext

  • Legacy Issue Number: 7340
  • Status: open  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    The CORBA specification has module SendingContext { //... interface CodeBase

    { //... CORBA::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... }; but there is no CORBA::FullValueDescription defined in the specification, yet the supplied <SendingContext.idl> file declares module SendingContext { //... interface CodeBase

    { //... CORBA::ValueDef::FullValueDescription meta(in CORBA::RepositoryId x); //... }

    ; //... };

  • Reported: CORBA 3.0.3 — Sat, 15 May 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

What is the RSC when using a PersistentPoller

  • Legacy Issue Number: 5781
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the RSC when
    > using a PersistentPoller? Since it is a valuetype that can be passed
    > from one process to another, the RSC obviously can't be the same in the
    > other process as at the original invocation point.
    >
    > Anybody have any bright ideas for this one? Should it be empty? A copy
    > of the TSC at the poll point? Change MessageRouting:PersistentRequest
    > to have an attribute that provides access to a copy of the RSC, and
    > PersistentRequestRouter::create_persistent_request to have the RSC as an
    > "in" argument?

  • Reported: CORBA 3.0.1 — Mon, 25 Nov 2002 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7730
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 3, chapter 13.8, defines the Codec interface to encode
    arbitrary data values into CORBA::OctetSeq "blobs" and vice
    versa. This interface can be used, e.g., to supply and retrieve
    ServiceContext data using the PortableInterceptor interfaces.

    In practice, the Codec interface is also being used for data
    serialization, i.e., to store and retrieve arbitrary values in
    files or other databases.

    However, the interface is deficient in that it does not consider
    all possible variables that are needed for interoperability.
    It supports setting the CDR version that is to be used, but
    neglects byteorder and codeset settings.

    Consequently, the encoded values are platform-specific. If a
    value was encoded on a little-endian system, it will not decode,
    or worse, decode erroneously, on a big-endian system. The same
    caveats apply to codesets, e.g., when an ISO-8859-1 encoded
    blob is decoded using UTF-8 or Windows-1252.

    To support interoperability, the Codec interface needs to be
    extended.

    My recommendation is to extend the CodecFactory interface,
    so that it supports creating CDR version-, byteorder-, and
    codeset-specific Codec instances, either supplying user-
    provided values for each, or informing the user about chosen
    defaults.

    Example:

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct EncodingExt

    { EncodingFormat format; octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingExt enc) raises (UnknownEncoding); }

    ;
    };

    The create_codec_ext operation would create an appropriate
    Codec instance, if available; it will then set all "default"
    members of the EncodingExt structure to their actual values,
    so that the application can store this information along
    with any encoded values.

    One potential criticism of the above is that the encoding
    format's parameters depend on the encoding format. For example,
    there may be encoding formats that are byteorder-independent,
    or that consistently use UTF-32 for strings, thus not needing
    codeset parameters. Also, they may use wildly different
    versioning. So a "better" solution might involve passing
    the EncodingFormat, and an Any with a format-specific data
    type.

    That could look like:

    module GIOP {
    typedef short ByteorderFormat;
    const ByteorderFormat BYTEORDER_DEFAULT = -1;
    const ByteorderFormat BYTEORDER_BIGENDIAN = 0;
    const ByteorderFormat BYTEORDER_LITTLEENDIAN = 1;

    struct CDREncodingParameters

    { octet major_version; // set to 0 for default octet minor_version; ByteorderFormat byteorder; CONV_FRAME::CodeSetId char_data; // set to 0 for default CONV_FRAME::CodeSetId wchar_data; // set to 0 for default }

    ;
    };

    module IOP {
    const EncodingFormat ENCODING_DEFAULT = -1;

    local interface CodecFactory

    { // create_codec remains as before Codec create_codec_ext (inout EncodingFormat format, inout Any parameters) raises (UnknownEncoding); }

    ;
    };

    Once we have consensus on the approach, I will gladly volunteer
    to come up with a full set of editing instructions

  • Reported: CORBA 3.0.3 — Thu, 9 Sep 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

An extension of IOR to protect target objects Nature

  • Legacy Issue Number: 7592
  • Status: open  
  • Source: Computer Science Department, National University of Defence Technology ( jack_nudt)
  • Summary:

    Related Specification: CommonObject Request Broker Architecture: Core Specification November 2002 Version 3.0 - Editorial edit to cover formal/02-11-03 Nature: Revision Subject: An extension of IOR to protect target objects Nature: Enhancement Issue Summary: IOR (Interoperable Object Reference) is the distributed reference of a CORBA object. The IOR of a target object is distributed to client applications that want to access the target object. Clients can easily connect to the target objects based on the location information in IOR. As a kind of object discovery scheme, IOR publishes some attributes related to target object, such as IP address, port number, internal object id, etc. As we know, many kinds of attacks can be performed to a target server when the IP address and port number of the target is exposed. The exposition of internal object id may also leads to security problems. We use Abstract IOR (AIOR) to make the originate IOR (we call it regular IOR) transparent to client applications, thus the target objects is protected from potential attacks. Proposed solution: We use proxy technology to protect target servers, following is the architecture of a typical scenario. Service Proxy (SP) acts as a portal for all background servers. SP will handle all requests from clients to background servers. So background servers are transparent to clients. ------------ ----------- | Client | Abstract IORs | Service | | application ---------------+ Proxy | | | | | ----------- --+ BS1's IORs | | | ------------------------- | | | BS2's IORs | | + ------------ | -------+ + BS3's IORs | Background | --------+ + | Server 1 | | Background | -------+ ---------- | Server 2 | | Background | ---------- | Server 2 | ----------- The core concept of the above architecture is Abstract IOR (AIOR). AIOR can be described by a simple equation: AIOR = SP's regular IOR + logical name Logical name is uniquely corresponding to an IOR of an object running on background server. So the SP should set up the mapping before corresponding request comes, and map the logical name in the AIOR to the regular IOR of the target object at background server for a coming request. The structure of AIOR is compatible to regular IOR. Firstly let's have a look at the structure of regular IOR defined at page 13-15. Then we will discuss how to support AIOR based on existing IOR data structures and what interfaces and methods will be defined. module IOP { // IDL // Standard Protocol Profile tag values typedef unsigned long ProfileId; struct TaggedProfile

    { ProfileId tag; sequence <octet> profile_data; }

    ; typedef sequence <TaggedProfile> TaggedProfileSeq ; // an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR

    { string type_id; sequence <TaggedProfile> profiles; }

    ; // Standard way of representing multicomponent profiles. // This would be encapsulated in a TaggedProfile. typedef unsigned long ComponentId; struct TaggedComponent

    { ComponentId tag; sequence <octet> component_data; }

    ; typedef sequence<TaggedComponent> TaggedComponentSeq; }; CORBA specification defines 3 standard IOR profiles (at page 13-17): module IOP

    { const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; const ProfileId TAG_SCCP_IOP = 2; typedef sequence <TaggedComponent> MultipleComponentProfile; }

    ; The following are standard IOR components that can be included in TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS profiles, and may apply to IIOP, other GIOPs, ESIOPs, or other protocols. An ORB must not drop these components from an existing IOR (at page 13-19). module IOP

    { const ComponentId TAG_ORB_TYPE = 0; const ComponentId TAG_CODE_SETS = 1; const ComponentId TAG_POLICIES = 2; const ComponentId TAG_ALTERNATE_IIOP_ADDRESS = 3; const ComponentId TAG_ASSOCIATION_OPTIONS = 13; const ComponentId TAG_SEC_NAME = 14; const ComponentId TAG_SPKM_1_SEC_MECH = 15; const ComponentId TAG_SPKM_2_SEC_MECH = 16; const ComponentId TAG_KerberosV5_SEC_MECH = 17; const ComponentId TAG_CSI_ECMA_Secret_SEC_MECH = 18; const ComponentId TAG_CSI_ECMA_Hybrid_SEC_MECH = 19; const ComponentId TAG_SSL_SEC_TRANS = 20; const ComponentId TAG_CSI_ECMA_Public_SEC_MECH = 21; const ComponentId TAG_ GENERIC_SEC_MECH = 22; const ComponentId TAG_FIREWALL_TRANS = 23; const ComponentId TAG_SCCP_CONTACT_INFO = 24; const ComponentId TAG_JAVA_CODEBASE = 25; const ComponentId TAG_TRANSACTION_POLICY = 26; const ComponentId TAG_MESSAGE_ROUTERS = 30; const ComponentId TAG_OTS_POLICY = 31; const ComponentId TAG_INV_POLICY = 32; const ComponentId TAG_CSI_SEC_MECH_LIST = 33; const ComponentId TAG_NULL_TAG = 34; const ComponentId TAG_SECIOP_SEC_TRANS = 35; const ComponentId TAG_TLS_SEC_TRANS = 36; const ComponentId TAG_ACTIVITY_POLICY = 37; const ComponentId TAG_INET_SEC_TRANS = 123; }

    ; The following additional components that can be used by other protocols are specified in the DCE ESIOP chapter of this document and CORBAServices, Security Service, in the Security Service for DCE ESIOP section (at page 13-19, 13-20): const ComponentId TAG_COMPLETE_OBJECT_KEY = 5; const ComponentId TAG_ENDPOINT_ID_POSITION = 6; const ComponentId TAG_LOCATION_POLICY = 12; const ComponentId TAG_DCE_STRING_BINDING = 100; const ComponentId TAG_DCE_BINDING_NAME = 101; const ComponentId TAG_DCE_NO_PIPES = 102; const ComponentId TAG_DCE_SEC_MECH = 103; // Security Service The following is the description of our proposed supplement to CORBA core specification. We add one component into module IOP: const ComponentId TAG_AIOR_LOGICALNAME = XXX; // XXX is an undetermined ComponentId. The TAG_AIOR_LOGICALNAME component has an associated value of type string encoded as a CDR encapsulation. We have not defined the interface of mapping logical names to regular IOR because now this function is local and its interoperability is not necessary. But if two or more SPs want to exchange their mapping items to provide more intelegent services, we may need to define the coresponding interfaces.

  • Reported: CORBA 3.0.3 — Thu, 15 Jul 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Mapping from -ORBxxx to Java properties does not work for -ORBInitRef

  • Legacy Issue Number: 6007
  • Status: open  
  • Source: Syracuse University ( Joncheng Kuo)
  • Summary:

    The CORBA 3.0 spec adds the following note in Section 4.5.1: ORB Initialization.

    "Whenever an ORB_init argument of the form -ORBxxx is specified, it is understood that the argument may be represented in different ways in different languages. For example, in Java -ORBxxx is equivalent to a property named org.omg.CORBA.ORBxxx."

    The approach stated in the above note does not work for -ORBInitRef. For example, if you have
    -ORBInitRef NameService=URL,
    you cannot translate the above arguments into a property named "org.omg.CORBA.ORBInitRef" because there can be only one property of this name and there may be many different services. This issue was slightly cover by Issue 3643 (java-rtf), which was not resolved. This issue becomes obvious and important because the note added in the CORBA 3.0 spec.

    Proposed solution: Arguments like "-ORBInitRef id=url" should be equivalent to a property named "org.omg.CORBA.ORBInitRef.id" with value "url".

  • Reported: CORBA 3.0.2 — Sat, 19 Jul 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.0.3 ch. 3.4 OMG IDL Grammar

  • Legacy Issue Number: 7978
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    The grammar definition for valuetype <state_member> via the rule
    <declarators> includes <complex_declarator>.

    It should be clarified whether valuetype state members are intended
    to include <array_declarator>.

    IMHO clarification is needed as state members are usually mapped
    to accessor methods in programming languages. If permissible,
    the accessor methods would return a complex type.

  • Reported: CORBA 3.0.3 — Wed, 15 Dec 2004 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Code Set Conversion on Operations

  • Legacy Issue Number: 8244
  • Status: open  
  • Source: Motorola ( Gary Duzan)
  • Summary:

    The "operation" field in the RequestHeader_1_2 struct is a string,
    which implies that it should be subject to code set conversion. However,
    existing practice seem to be that it is not converted, and there are other
    factors which could make it difficult for implementations to convert it.
    In addition, since the operation name is based on IDL/ASCII, conversion
    doesn't necessarily make sense.

    The easiest remedy would be to specify this as an exception in the
    text of the spec. The "correct" remedy would probably be to change the
    operation field from "string" to "sequence<octet>". This could cause
    problems at some point, but it might not break too much since the CDR
    encodings are the same.

  • Reported: CORBA 3.0.3 — Mon, 7 Feb 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    REQUIREMENT

    To be able to use interceptors, and in particular ForwardRequest, in a client to perform active, per-request, load-balancing.

    PROBLEM

    It is not possible to detect in an interceptor whether ForwardRequest has previously been thrown for the same client request. Thus it is possible for a client to go into an infinite loop throwing ForwardRequest.

    DISCUSSION

    The basic problem is that although for a single client request the request-scoped PICurrent is shared across across interceptor invocations - even when ForwardRequest is thrown - it is not possible to modify this information in an interceptor to indicate to a future invocation that the invocation has been seen. The two relevant parts of the spec here are:

    21.3.6.5

    For retries, depending on the policies in effect, a new request may or may not follow
    when a retry has been indicated. If a new request does follow, while this request is a
    new request, with respect to Interceptors, there is one point of correlation between the
    original request and the retry: because control has not returned to the client, the request
    scoped PortableInterceptor::Current for both the original request and the retrying
    request is the same (see Chapter 21, Portable Interceptors on page 21-32).

    21.4.2

    Before an invocation is made, PICurrent is obtained via a call to
    ORB::resolve_initial_references ("PICurrent")
    From within the interception points, the data on PICurrent that has moved from the
    thread scope to the request scope is available via the get_slot operation on the
    RequestInfo object. A PICurrent can still be obtained via
    resolve_initial_references, but that is the Interceptor's thread scope PICurrent.
    See section 21.4.4.4, Request Scope vs Thread Scope on page 21-36 for a detailed
    discussion of the scope of PICurrent.

    Thus modifications to the thread's PICurrent are lost on retries and modifications to the request's PICurrent are not possible.

    PROPOSED RESOLUTION

    I have made several different attempts at coming up with a portable way of solving this problem without changing the spec, but have failed. It seems to me that it really should be possible for the interceptor to know that a retry is in effect and I can think of a number of different solutions to this:

    1. add:
    void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    to RequestInfo. This would allow interceptors to transfer information between invokes of the same client request and thus a retry could be detected.

    2. Add a new function to RequestInfo to indicate that a forward is in operation. The minimalist fix here would be to allow forward_reference() to be accessed in send_request() as well as in receive_other(). i.e. returning the object from the previous ForwardRequest if that has been thrown.

    I'm ambivalent about which of these is best but for the sake of simplicity I'm going to plump for (1) because this is already allowed in ServerRequestInfo.

    So:

    • Change the IDL in 21.3.12 to include
      void set_slot (in SlotId id, in any data) raises (InvalidSlot);
    • After 21.3.12.12 move in the text from 21.3.14.6
    • Change the IDL in 21.3.14 to remove set_slot()
  • Reported: CORBA 2.6.1 — Thu, 2 May 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: open  
  • Source: Oracle ( Harold Carr)
  • Summary:

    During the interceptor FTF we changed the server-side threading
    requirements such that all server-side points run in the same thread
    as the ServantManager and servant except receive_request_service_contexts.

    We attempted to update 21.4.4.4 "Request Scope vs Thread Scope"
    accordingly but knew we screwed the picture and wording up. So we
    punted to the RTF.

    The main problem with the current wording is that is forces a copy of
    of TSC/RSC before the servant manager and then receive_request are
    called. This is necessary because 21.4.4.5 item 5 says: "The
    receive_request points may modify the RSC, but this no longer affects
    the TSC."

    The only way to make RSC identical to TSC in receive_request with
    respect to reading but also have them be independent with respect to
    writing is to make a copy (which could be optimized to copy-on-write,
    but why?).

    I suggest we just state they are equivalent after
    receive_request_service_contexts.

    Here is a proposed revision to ptc/00-08-06 along these lines.

    Comments?
    Harold

    21.4.4.4 Request Scope vs Thread Scope

    ... On the server-side, the request scope PICurrent is attached to
    the ServerRequestInfo and follows the request processing. It is
    logically equivalent to the thread scope PICurrent after the list of
    receive_request_service_contexts interception points are processed.

    21.4.4.5 Flow of PICurrent between Scopes

    5. The ORB logically makes the RSC equivalent to the server-side TSC
    after the receive_request_service_contexts points are processed and
    before the servant manager is called. This TSC is within the context
    for both the receive_request points, the invocation of the servant
    manager, and the invocation of the target operation.

    The receive_request points are called. These points have access to the
    RSC. Modifying the RSC at this point makes corresponding
    modifications on the TSC. Since these points execute in the same
    thread as the target operation invocation, these points may modify the
    server-side TSC which makes corresponding modifications on the RSC.

    6. After the receive_request points are called, control transfers to
    the server threads which may also read and write this server-side TSC.
    Any modifications to the TSC makes corresponding modifications on the
    RSC.

    7. <No change>

    8. <DELETE THIS ITEM>

    9. The send interception points have access to the RSC (and the
    equivalent TSC) from which they may populate the reply service context
    list. After the invocation result is sent back to the client, the
    server-side RSC is logically destroyed.

    ...

    The picture would also need updating, but let's agree on wording first.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal for extension to CosNaming

  • Legacy Issue Number: 5214
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Since there doesn't appear to be a CosNaming mailing list this seems like as good a forum as any this discussion.

    It has long struck me that the use of CosNaming for JNDI in J2EE applications creates a significant outage in being able to bind and retrieve objects that are not remote (see the EJB 2.0 spec for details). In JNDI you can bind pretty much anything that is Remote (aka an Object reference) or Serializable (aka a valuetype), however CosNaming only allows you to do the former.

    One easy way to solve this would be to create a new NamingContext extension that allows one to bind and resolve Any's. This is in keeping with the Java-to-IDL spec's treatment of untyped Java objects and at the same time would not compromise non-java implementations. For JNDI it would only be necessary to support Any's containing:

    1. Object references
    2. valuetypes
    3. valueboxes

    An exception could be thrown for any other types. The candidate interface might look something like this:

    module CosNaming {
    interface NamingContextAny : NamingContextExt {
    exception TypeNotSupported {};

    void bind_any(in Name n, in any obj)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound, TypeNotSupported);

    void rebind_any(in Name n, in any obj)
    raises(NotFound, CannotProceed, InvalidName, TypeNotSupported);

    any resolve_any (in Name n)
    raises (NotFound, CannotProceed, InvalidName);

    any resolve_str_any(in StringName n)
    raises (NotFound, CannotProceed,
    InvalidName, AlreadyBound);
    };
    };

    The implementation of this interface in Java is trivial, although perhaps less so in other languages. Whether or not that matters is open to question.

  • Reported: CORBA 2.6 — Wed, 10 Apr 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

New issue: ForwardRequest()

  • Legacy Issue Number: 5231
  • Status: open  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Portable Object Adapter and Portable Interceptors both are able to
    raise a ForwardRequest exception to allow redirection to another
    object.

    What happens if the ForwardRequest is to a local object?

    Is this even possible?

    Should it be allowed?

    I suggest we change the specification to make this illegal.

  • Reported: CORBA 2.6 — Thu, 25 Apr 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

rule (85) is misplaced

  • Legacy Issue Number: 15715
  • Status: open  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The rule number (85) is indented, the rule number is not aligned with other rule numbers.

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

processing TaggedComponents within an IOR

  • Legacy Issue Number: 5439
  • Status: open  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The overhead of processing TaggedComponents within an IOR becomes
    significant when done many times, as in the case of J2EE
    implementations where multiple interceptors are used.

    The definition of IORs in the IOP module is intended to support
    transmission and interoperability, rather than efficient access to the
    local, ORB specific, internal structure.

    I would like to propose that an abstract model of an IOR is introduced
    which recognises that many of the constituent parts of IOR profiles are
    identical for different objects, along the following lines:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    with corresponding IDL definitions that allow the language bindings
    to optimise conversion between transmission and internal IOR formats
    to provide a performant and natural interface for IOR access.

    Rationale:
    In Java, for example, it should be possible to manipulate IOR
    TaggedProfiles and IIOPProfileTemplate TaggedComponents using the
    facilities of the Java collections framework, or at least some
    equivalent facility that is a natural Java idiom.

    Templates can be used to create IIOPProfiles because the basic object
    adapter model for object creation is to establish many of the properties
    of an IOR when the object adapter is created.

    • This has been present for the POA essentially from the beginning, since
      policies can only be passed to create_POA, and cannot be changed on an
      existing POA.
    • The Portable Interceptors work has also made this clear, since the IOR
      interceptor establish_components method, which is the only time that
      user code can add tagged components to an IOR, is only guaranteed to
      be called once for each distinct set of server policies i.e need only
      be run when an object adapter is created.
    • It is also likely that more than one object within an adapter will
      map to a TCP endpoint.

    TaggedProfile and TaggedComponent are intended as frameworks that may be
    extended to support application defined tagged profiles and components.
    To support this it is necessary to be able to register TaggedProfile and
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance will use the registered factory
    to unmarshal the tagged profile or component.

    Since there has already been quite a bit of discussion about this in the
    Java RTF, here is a proposal for review:-

    Proposal:

    • add the following sections after the IOR Interceptor Overview:-

    21.5.2 An Abstract Model for IORs

    To support efficient access to IORs, avoiding repeated marshaling and
    demarshaling of IOR components, it is helpful to have an abstract model
    of the, ORB specific, local representation of an IOR.

    Recognising that many of the constituent parts of IOR profiles are
    identical for different objects allows the following model to be
    defined:-

    • an IOR has a type ID string, and contains TaggedProfile instances
    • a TaggedProfile has an ID and data
    • an IIOPProfile is a TaggedProfile; it is composed of an
      IIOPProfileTemplate and an object ID.
    • an IIOPProfileTemplate has IIOP addressing information, and contains
      TaggedComponents.
    • a TaggedComponent has an ID and data
    • a TaggedComponentFactory creates a TaggedComponent
    • a TaggedProfileFactory creates a TaggedProfile

    21.5.3 Local IOR Interfaces

    The following interfaces provide access to the data within a local IOR
    using this model.

    TaggedProfile and TaggedComponent are generic interfaces. Users of the ORB
    may create implementations of them. Corresponding factories may be
    registered with the IORFactory.

    The IORFactory is obtained through a call to
    ORB::resolve_initial_references ("IORFactory") and may also be used to
    obtain an IOR for an Object.

    An ORB must return all tagged profiles in an IOR through the IOR
    getProfiles operations. The ProfileIterator interface allows a client
    to iterate through the TaggedProfiles using the next operation.
    Those profiles whose ids have a registered TaggedProfileFactory will
    be made available in the form returned by the registered factory's
    TaggedProfileFactory create operation, which must return a subtype of
    TaggedProfile.

    An ORB will provide a TaggedProfileFactory implementation for the
    IIOPProfile.

    Profiles with ids for which no TaggedProfileFactory has been registered
    will be made available as instances of a generic ORB implementation of
    TaggedProfile.

    Similarly, an ORB must return all tagged components in an IIOP profile
    through the IIOPProfile().getTemplate().getComponents() operations.
    The ComponentIterator interface allows a client to iterate through the
    TaggedComponents using the next operation.
    Those components whose ids have a registered TaggedComponentFactory
    will be made available in the form returned by the registered factory's
    TaggedComponentFactory create operation, which must return a subtype of
    TaggedComponent.
    Components with ids for which no TaggedComponentFactory has been
    registered will be made available as instances of a generic ORB
    implementation of TaggedComponent.

    module PortableInterceptor {

    local interface TaggedComponent

    { readonly attribute IOP::ComponentId component_id; readonly attribute CORBA::OctetSeq component_data; IOP::TaggedComponent convert(); }

    ;

    local interface ComponentIterator

    { TaggedComponent next(); boolean has_next(); }

    ;

    local interface TaggedProfile

    { readonly attribute IOP::ProfileId profile_id; readonly attribute CORBA::OctetSeq profile_data; IOP::TaggedProfile convert(); }

    ;

    local interface ProfileIterator

    { TaggedProfile next(); boolean has_next(); }

    ;

    local interface IOR

    { readonly attribute string type_id; ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    local interface IIOPProfileTemplate

    { readonly attribute IIOP::Version iiop_version; readonly attribute string host; readonly attribute unsigned short port; ComponentIterator get_components(); ComponentIterator get_components_by_id (in IOP::ComponentId id); }

    ;

    local interface IIOPProfile:TaggedProfile

    { readonly attribute CORBA::OctetSeq object_key; readonly attribute IIOPProfileTemplate profile_template; }

    ;

    local interface TaggedComponentFactory

    { readonly attribute IOP::ComponentId factory_id; TaggedComponent create_tagged_component (in CORBA::OctetSeq component_data); }

    ;

    local interface TaggedProfileFactory

    { readonly attribute IOP::ProfileId factory_id; TaggedProfile create_tagged_profile (in CORBA::OctetSeq profile_data); }

    ;

    local interface IORFactory

    { IOR create_ior (in Object obj); void register_tagged_profile_factory (in TaggedProfileFactory tpf); void register_tagged_component_factory (in TaggedComponentFactory tcf); }

    ;

    };

    21.5.3.1 IOR Factory Interface

    create_ior
    Return an IOR relating to the given Object.

    If create_ior is invoked when the object reference is not bound,
    standard system exception BAD_INV_ORDER with minor code n will be
    raised.

    register_tagged_profile_factory
    Register a TaggedProfileFactory to create TaggedProfiles with the id
    returned by the given factory's getId method. If a TaggedProfileFactory
    already exists for the given id, standard system exception
    BAD_INV_ORDER is raised with a standard minor code of n+1.
    Instances of this interface may be defined by users to support custom
    tagged profiles.

    register_tagged_component_factory
    Register a TaggedComponentFactory to read TaggedComponents with the id
    returned by the given factory's getId method. If a
    TaggedComponentFactory already exists for the given id, standard system
    exception BAD_INV_ORDER is raised with a standard minor code of n+2.
    Instances of this interface may be defined by users to support custom
    tagged components.

    21.5.3.2 IOR Interface

    This interface gives access to a local representation of an
    IOP::IOR.

    type_id
    The type id string from the IOR.

    get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    get_profiles_by_id
    Returns an iterator over the TaggedProfiles with the given
    Profileid.

    21.5.3.3 TaggedProfile Interface

    This interface gives access to a local representation of an
    IOP::TaggedProfile.

    profile_id
    This attribute is the identifier for this TaggedProfile.

    profile_data
    This attribute is the data from the TaggedProfile. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedProfile

    21.5.3.4 TaggedComponent Interface

    This interface gives access to a local representation of an
    IOP::TaggedComponent.

    component_id
    This attribute is the identifier for this TaggedComponent.

    component_data
    This attribute is the data from the TaggedComponent. It is
    normally a CDR encapsulation.

    convert
    Create an IOP representation of this TaggedComponent.

    21.5.3.5 TaggedProfileFactory Interface

    factory_id
    This attribute is the identifier of profiles created by this
    TaggedProfileFactory.

    create
    Create a TaggedProfile from the given profile_data.

    21.5.3.6 TaggedComponentFactory Interface

    factory_id
    This attribute is the identifier of components created by this
    TaggedComponentFactory.

    create
    Create a TaggedComponent from the given component_data.

    21.5.3.7 ProfileIterator Interface

    next
    Returns the next TaggedProfile in the iteration. If next is called
    after the last TaggedProfile has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If an IOR is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.8 ComponentIterator Interface

    next
    Returns the next TaggedComponent in the iteration. If next is called
    after the last TaggedComponent has been returned, BAD_INV_ORDER will
    be raised with a standard minor code of n+3.

    If a profile is modified in between calls to next, the behavior of
    further calls to next is implementation dependent.

    has_next
    Returns true if the iteration has more elements. In other words,
    returns true if next would return an element rather than throwing
    an exception.

    21.5.3.9 IIOPProfile Interface

    object_key
    This attribute is the Object key contained in this IIOPProfile.

    profile_template
    This attribute is the IIOPProfileTemplate associated with this
    IIOPProfile.

    21.5.3.10 IIOPProfileTemplate Interface

    iiop_version
    This attribute is the GIOP version of this profile. If the major
    value is 1 and the minor value is 0, this profile cannot contain
    any TaggedComponents.

    host
    This attribute is the host name string of this IIOPProfileTemplate.

    port
    This attribute is the port number of this IIOPProfileTemplate.

    get_components
    Return an iterator over the TaggedComponents within the
    IIOPProfileTemplate.

    get_components_by_id
    Returns an iterator over the TaggedComponents with the given
    ComponentId.

    In current Section 21.5.3:

    • add the following after the ORBInfo Interface

    local interface IORInfo_3_n:IORInfo

    { ProfileIterator get_profiles (); ProfileIterator get_profiles_by_id (in IOP::ProfileId profile_id); }

    ;

    • add the following sections:

    21.5.3.4 get_profiles
    Returns an iterator over the TaggedProfiles within the IOR.

    21.5.3.5 get_profiles_by_id
    Returns an iterator over the TaggedProfiles within the IOR with the
    given Profileid.

    Parameter Description
    profile_id The IOP::ProfileId of the profiles in the iteration
    to be returned.

    • add the IORFactory to the list of reserved ObjectIds for
      resolve_initial_references in section 4.5.2
  • Reported: CORBA 3.0 — Tue, 25 Jun 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad quotes and imported dot

  • Legacy Issue Number: 15714
  • Status: open  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    Is:
    A character literal is one or more characters enclosed in single quotes, as in ’x.’
    Should be:
    A character literal is one or more characters enclosed in single quotes, as in 'x'.

    (note that the present version uses curly quotes and the dot is probably misplaced)

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

missing document title

  • Legacy Issue Number: 15713
  • Status: open  
  • Source: stegny.2a.pl ( Christopher Yeleighton)
  • Summary:

    The document title in PDF metadata
    is "untitled",
    should be
    "Common Object Request Broker Architecture (CORBA)
    Specification"

  • Reported: CORBA 3.1 — Thu, 30 Sep 2010 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Redundant bullet

  • Legacy Issue Number: 16942
  • Status: open  
  • Source: Kestrel Institute ( Alessandro Coglio)
  • Summary:

    It seems that the last and 4th-to-last bullets both describe the Wstring type. Thus, one should suffice.

  • Reported: CORBA 3.2 — Fri, 30 Dec 2011 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle

  • Legacy Issue Number: 13105
  • Status: open  
  • Source: cs.agh.edu.pl ( Jacek Cala)
  • Summary:

    There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle. Having multiplex publisher port it would be easier to connect with dynamically created event consumers such that each consumer would have its own private communication channel with the publisher. In case of dynamically created consumers it is not possible to foresee the number of publisher ports required. For synchronous communication the elegant solution is a component with a multiplex receptacle for which we have separate communication channels.

  • Reported: CORBA 3.1 — Mon, 24 Nov 2008 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Part 2, Chapter 11 - MIOP

  • Legacy Issue Number: 12376
  • Status: open  
  • Source: Lockheed Martin ( Kenton Waller)
  • Summary:

    The MIOP does not provide an analogous operation to PortableServer::POA::create_POA() for the GOA (i.e. there is no PortableGroup::GOA::create_GOA). The lack of an operation of this nature prevents the ability for an interface (i.e. servant) to subscribe to multiple (i.e. more than one) multicast group. To specify to a POA to allow multiple entries in its Active Object Map, the POAs IdUniquenessPolicy would have to be set to MULTIPLE_ID. This can only be done via the POAs create_POA operation. Since there is no GOA create_GOA operation, a GOAs IdUniquenessPolicy cannot be set to MULTIPLE_ID, which prevents a servant from being able to be subscribed to more than one multicast group. I don't know if the OMG explicitly wants to prevent this capability, thus purposely leaving it out of the MIOP specification, or if this is simply an overlooked issue.

  • Reported: CORBA 3.1 — Tue, 8 Apr 2008 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

definition of Invalid Policies changed

  • Legacy Issue Number: 12229
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The CORBA/e FTF slightly changed the definition of Invalid Policies to: exception InvalidPolicies

    { UShortSeq indices; }

    ; since this avoids the use of an anonymous sequence type, consider changing it (also for consistency).

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

mention of (deprecated) function get_implementation removed from text

  • Legacy Issue Number: 12230
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    CORBA/e FTF (issue 11331): removed mention of (deprecated) function get_implementation from text. Consider making same change for consistency

  • Reported: CORBA 3.1 — Fri, 15 Feb 2008 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.10.1

  • Legacy Issue Number: 11161
  • Status: open  
  • Source: ADLINK Technology Ltd ( Steve Osselton)
  • Summary:

    The use of the '/' character to identify the object key component of a corbaloc URL is ambiguous where a protocol address also contains the character. Example: corbaloc:uiop:/tmp/uiop/xx/steve This could represent either a uiop address '/tmp/uiop' and an object key 'xx/steve/ or a uiop address '/tmp/uiop/xx' and an object key 'steve'. Suggest removing the '/' character from the list of non excaped object key characters (bottom of page 13-26)to resolve this ambiguity. The corbaloc would then become: corbaloc:uiop:/tmp/uiop/xx%27steve

  • Reported: CORBA 3.0.3 — Wed, 18 Jul 2007 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Two typo's in Annex A.4

  • Legacy Issue Number: 17273
  • Status: open  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    There are two typo's in section A.4 on page 495.
    1
    SERVENT_RETENTION_POLICY_ID should be SERVANT_RETENTION_POLICY_ID
    2
    PortableServer::ServentRetentionPolicy should be PortableServer::ServantRetentionPolicy

  • Reported: CORBA 3.1 — Tue, 27 Mar 2012 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Moving *Seq typedefs into ORB chapter

  • Legacy Issue Number: 8586
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the CORBA specification, chapter 5 (Value Type
    Semantics), section 5.5 (Custom Marshalling), defines
    sequences of primitive types in the CORBA module,
    i.e., CORBA::StringSeq et al. Some of these types are
    then used by the DynamicAny and Portable Interceptor
    chapters.

    The presence of these typedefs in section 5.5 seems
    to imply that they only need to be defined if the ORB
    implements custom marshalling – a feature still
    lacking in some open-source and commercial ORBs.

    In my experience, having worked with multiple ORBs,
    many of them do not provide the complete set of
    typedefs in their "orb.idl" file. Many ORBs only
    provide a limited set, usually, the set that is
    exercised by the other ORB features (such as PI).
    This implies that most ORBs added these typedefs
    on an "as needed" basis instead of simply referring
    to section 5.5.

    I suggest to move these typedefs from section 5.5
    into chapter 4 (ORB interface), e.g., into section
    4.2 (ORB operations) to highlight that these types
    should be present even if custom marshalling is not
    implemented by the ORB.

    Proposed resolution:

    In section 5.5.2 (Marshalling Streams), cut the
    type definitions, starting with AnySeq, up to and
    including WStringSeq.

    In section 4.2, in the IDL code fragment, at the
    beginning of the CORBA module, paste the type
    definitions cut above.

  • Reported: CORBA 3.0.3 — Thu, 17 Mar 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minor code ambiguity

  • Legacy Issue Number: 8618
  • Status: open  
  • Source: International Business Machines ( Mr. Neil Richards)
  • Summary:

    In the CORBA specification dated 04-03-12, the last two paragraphs on page 15-33 (section 15.4.1) describe the use of MARSHAL minor codes 7 and 8.
    However, this use of these minor codes is not reflected in the table of minor codes on page A-11 (appendix A).

    Furthermore, MARSHAL minor code 7 has also been assigned (at an earlier date?) to an issue resolved in the Java to IDL specification dated 03-09-04 (see page 1-50 / end of section 1.5.1.5).
    This use of minor code 7 is reflected in the table in the CORBA specification.
    However minor code 10, which is also specified in the same section in the Java to IDL specification, is not documented in the CORBA specification.

    In summary, MARSHAL minor code 7 is double-booked, whilst minor codes 8 (used in the CORBA specification) and 10 (used by the Java to IDL specification) are not documented in the table of codes.

    Proposed solution:

    Change section 15.4.1 to define the use of MARSHAL minor code 9 (in addition to minor code 8), instead of MARSHAL minor code 7.

    Update the table of minor codes on page A-11 with the definitions of MARSHAL minor codes 8, 9 and 10.

  • Reported: CORBA 3.0.3 — Mon, 21 Mar 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo in sections 22.10.1.1 and 22.10.1.2

  • Legacy Issue Number: 8629
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In section 2.10.1.1, page 22-26 (my copy is formal/04-03-01),
    enumerated item 3, second bullet, the text reads "232-1 - the
    maximum value for unsigned long [...]". The "32" needs to be
    in superscript, i.e., to indicate "2 to the power of 32 minus
    1".

    The same typo exists in section 2.10.1.2, page 22-28, fourth
    paragraph, second bullet (at the top of the page).

  • Reported: CORBA 3.0.3 — Thu, 24 Mar 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

FullInterfaceDescription and base_interfaces question

  • Legacy Issue Number: 9140
  • Status: open  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Regarding the base_interfaces attribute of the Interface Repository
    (IFR) InterfaceDef and the ExtInterfaceDef interfaces, the CORBA spec
    has only this to say:

    "The base_interfaces attribute lists all the interfaces from which
    this interface inherits."

    Does that sentence mean that the base_interfaces attribute lists only
    immediate base interfaces, or does it list all base interfaces,
    i.e., the transitive closure of the inheritance graph (minus the
    implied Object interface at the root)? I believe it is supposed to be
    a list of only immediate interfaces, as one can make further calls on
    the IFR to obtain more information about those bases, including
    their bases.

    However, both the FullInterfaceDescription and the
    ExtFullInterfaceDescription structures also have a base_interfaces
    member, which is specified as a sequence of repository IDs.
    Unfortunately, the specification contains no description whatsoever
    for this member. I argue that unlike the base_interfaces attribute
    described above, this member can't list only the immediate base
    interfaces.

    I believe that the base_interfaces member of the
    FullInterfaceDescription and the ExtFullInterfaceDescription
    structures should contain the transitive closure of all base
    interfaces. These structures are intended to supply full interface
    descriptions, after all. Specifying the base_interfaces as I suggest
    would match the operations and attributes fields of the same structs,
    which are already explicitly specified to contain all operations and
    attributes respectively from the transitive closure of the
    inheritance graph. Note also that if base_interfaces does not contain
    the transitive closure of all base interfaces, there's no way to
    obtain the information from TypeCodes, since names do not appear in
    TypeCodes in minimum CORBA.

    I therefore propose that the third paragraph of section 10.5.24.1 of
    CORBA 3.0.2 be changed from this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    The operations and attributes fields of the FullInterfaceDescription
    structure include descriptions of all of the operations and
    attributes in the transitive closure of the inheritance graph of the
    interface being described."

    to add a sentence defining the base_interfaces member, like this:

    "The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes.
    The operations and attributes fields of the FullInterfaceDescription
    structure include descriptions of all of the operations and
    attributes in the transitive closure of the inheritance graph of the
    interface being described. The base_interfaces field of the
    FullInterfaceDescription structure includes the repository IDs of all
    the base interfaces in the transitive closure of the inheritance
    graph of the interface being described, except for the repository ID
    of the implied Object base interface."

    Note that even if this change is made, the base_interfaces attribute
    of InterfaceDef and ExtInterfaceDef can (and should) remain as
    listing only immediate bases, assuming that's what the spec's
    original intent was.

  • Reported: CORBA 3.0.3 — Mon, 7 Nov 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing mutual recursion for IDL structs - clarification needed

  • Legacy Issue Number: 10558
  • Status: open  
  • Source: Borland Software Corporation ( Naveed Shaikh)
  • Summary:

    There was an issue 8969 (Allowing mutual recursion for IDL structures) posted sometime back on CORBA RTF (www.omg.org/issues/issue8969.txt). I am looking for a clarification in the proposed resolution, which allows for the mutual recursion between non-nested structures (CORBA 3.0 specification, section 3.11.2.3). The proposal essentially extends the definition of incompleteness of a struct/union as follows:

    The original definition was:
    o A struct/union is termed incomplete until its full definition is provided; that is, until the scope of the struct/union definition is closed by a terminating "}"

    The introduced proposal added to the original definition:
    o If a sequence member of a structure or union refers to an incomplete type, the structure or union itself remains incomplete until the member's definition is completed

    Section 3.11.2.3 also says that "an incomplete type can only appear as the element type of a sequence definition".

    Question 1:
    Is following legal under the new scheme?

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete since it is holding an incomplete sequence type

    struct FooX

    { Bar b; // Is this valid with Bar marked incomplete here? }

    ;

    struct Foo

    { Bar b; }

    ; // According to the proposal, Foo and Bar are complete now

    Use of Bar under FooX apparently conflicts with the condition that incomplete type can only appear in a sequence definition.

    Question 2:
    Also is it must that there is a mutual recursion between non-nested structures? Consider the following:

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ; // Bar remains incomplete

    struct Foo

    { long a; }

    ; // Is Bar also complete here when Foo is complete even though Foo doesn't recurse on Bar?

    Is the above IDL valid under the new proposal? There is no constraint in section 3.11.2.3, which doesn't allow for this so it stands valid as per spec. Was issue 8969 also intended to make such cases valid?

  • Reported: CORBA 3.0.3 — Fri, 1 Dec 2006 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA Exceptions

  • Legacy Issue Number: 9618
  • Status: open  
  • Source: condor networks ( ramesh babu boya)
  • Summary:

    I implemented CORBA functionality, in that implementation I got some exceptions. I am sending that exceptions list in the below. omniORB: ERROR – the application attempted to invoke an operation on a nil reference. terminate called after throwing an instance of 'CORBA::INV_OBJREF' Aborted (core dumped) I have some doubts on these exceptions. What is the cause for this exception? How can I solve this exception? Please clarify my doubts.

  • Reported: CORBA 3.0.3 — Thu, 4 May 2006 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 7-7

  • Legacy Issue Number: 8881
  • Status: open  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    CORBA3.0.2(formal/02-12-02), chapter 7.2.1, says "The implicit object reference operations non_existent, is_a, repository_id and get_interface may be invoked using DII. No other implicit object reference operations may be invoked via DII." However, I think we should add "get_component" to this list of allowable operations. Or else we can't use some features of CCM via DII, because the implementation of get_component resides on the server side.

  • Reported: CORBA 3.0.3 — Tue, 28 Jun 2005 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 9-1

  • Legacy Issue Number: 8879
  • Status: open  
  • Source: nudt ( cyberdb)
  • Summary:

    There are some inconsistent idl declarations in CORBA3.0.2 Chapter 9(with editorial update version) 1?page 9-10: the idl declaration of DynAnyFactory is not the same as the idl declared earlier(page 9-9). It seems that three new fuctions have been left out. 2?Page 9-5: DynUnion should have a member fuction is_set_to_default_member, which is declared on page 9-20

  • Reported: CORBA 3.0.3 — Mon, 27 Jun 2005 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.8 The simple Element, page 69-538

  • Legacy Issue Number: 5508
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    2. 69.8.2.8 The simple Element, page 69-538
    Simple Extensions and Changes
    a) Enumerations - Add an optional enumerations element to the simple
    definition.
    This allows a simple enumeration property to be defined. Each enumeration
    label
    has an associated value. The values are all of the same simple type.

    Change simple element to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , enumerations?
    , defaultvalue?
    ) >

    Define new enumerations element

    <!ELEMENT enumerations
    ( enumeration+
    )>
    <!ELEMENT enumeration EMPTY>
    <!ATTLIST enumeration
    label CDATA #REQUIRED
    value CDATA #IMPLIED>

    b) Short appears twice in the simple type attribute definition. Remove
    second
    occurrence.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #IMPLIED
    type ( boolean

    char
    double
    float
    short – 1st occurrence
    long
    objref
    octet
    short – 2nd occurrence
    string
    ulong
    ushort
    ) #REQUIRED >

    c) Units - add an optional units element to indicate the units of
    measurement for
    a simple property.

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , units?
    , defaultvalue?
    ) >

    <!ELEMENT units (#PCDATA)>

    d) Property Kind - The properties file for a component should not be
    restricted to
    only initial configuration properties. A component has many different types
    of
    properties and when defining a component one should be able to define these
    types of properties in a generic way. Add a kind element or attribute for a
    property definition. A component has readonly, writeonly, and readwrite
    properties. Simple properties can also be used for a component factory's
    create
    options parameter (home) or executable parameters/arguments. Only simple
    properties can be used for executable parameters.

    New simplekind element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam) "configure_readwrite">

    Change simple definition to:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , defaultvalue?
    ) >

    The propertykind can be an optional element or attribute for the stuct and
    sequence elements.

    New propertykind element

    <!ELEMENT propertykind EMPTY>
    <!ATTLIST propertykind
    kindtype (configure_writeonly | configure_readwrite |
    query_readonly | factoryparam) "configure">

    Change Struct and Sequence to

    <!ELEMENT struct
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    , propertykind?
    ) >
    <!ATTLIST struct
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    , propertykind?
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 9, Chapter 5

  • Legacy Issue Number: 8986
  • Status: open  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 9.2.9 says "A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents.", which defines the sharing semantics of DynAny. However, I think its precondition is that valuetype's sharing semantics can be preserved in Any. DynAny is usually used with Any, converted from or to Any. If Any can't preserve sharing semantics, there is no necessary for DynAny to keep them. Suppose we use a struct which consists of several valuetypes to store a graph. In order to ensure the correctness of an application based on DII/DSI, converting this struct to Any and then to DynAny should produce an identical graph. However, if Any can't preserve sharing semantics, this goal is impossible. Any's sharing semantics focuses on valuetype conversion, because we don't concern the concrete internal implementation of Any. It means that when we extracting valuetypes from an Any or converting an Any contains valuetypes into a DynAny, sharing semantics should be preserved. For example, different Anys contain same valuetype only produce one valuetype instance when their contents are extracted. We can implement this by the help of a global valuetype manager. To sum up, the sharing semantics of valuetype can be divided into three layers: valuetype itself, Any and DynAny. All of them constitute a complete hierarchy. Only after each layer has been implemented, we are able to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph. Because Any's sharing semantics is very fundamental, it is necessary for us to clarify it in the specification, though we haven't special chapter/section on Any. We can add it to Chapter 5 "Value Type Semantics". Section 5.2.4.2 only defined sharing semantics in the layer of valuetype itself. We should say something about sharing semantics in the other two layers at the end of this section.

  • Reported: CORBA 3.0.3 — Mon, 5 Sep 2005 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 11

  • Legacy Issue Number: 8985
  • Status: open  
  • Source: Office613, S6, NUDT ( DingBo)
  • Summary:

    Section 11.3.1 "The Servant IDL Type" defines the default implementations of get_interface, is_a, and non_existent. However, we should define the default implementation of "get_component" as well because this fuction is also an ORB-mediated implicit object reference operation. By default, this function returns a nil reference. When the object is a component or a facet, as other default implementations, this operation can be overridden by the servant's implementation.

  • Reported: CORBA 3.0.3 — Sun, 4 Sep 2005 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing Mutual Recursion for IDL Structures

  • Legacy Issue Number: 8969
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    CORBA 2.4 introduced forward declarations for IDL structures
    and unions in support of recursive structures, deprecating the
    prior practice of anonymous types.

    Also allowed were sequences of forward-declared structures
    ("incomplete types"), which could then be used as members in
    defining the structure. Currently, it is only allowed to use
    incomplete types in the actual definition of the type itself.

    As an example in section 3.11.2.3 demonstrates, this does
    allow indirect recursion – but only if the incomplete types
    are nested, as in [first example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Foo {
    struct Bar

    { FooSeq fs; }

    b;
    };

    Specifically not allowed – and this is the point of this
    issue – is the seemingly more intuitive definition of
    [second example]

    struct Foo;
    typedef sequence<Foo> FooSeq;

    struct Bar

    { FooSeq fs; }

    ;

    struct Foo

    { Bar b; }

    ;

    Currently, the spec says that, "sequence members that are
    recursive must refer to an incomplete type currently under
    definition," and thus Bar is not allowed to use FooSeq as
    a member.

    However, the second example is, in effect, no different than
    the first. In the first example, "Foo::Bar" is a well-defined
    stand-alone type that can be used elsewhere (e.g., as a
    structure member or operation parameter).

    If a developer intends to use both structures, the second
    example makes this much clearer, as it syntactically elevates
    "Foo::Bar" from a mere sub-type to an "independent" structure.

    Therefore, I would like to change the current wording of
    section 3.11.2.3 to allow the second example. A proposed
    update is below.

    This issue is all the more urgent because another available
    specification, the "Deployment and Configuration of
    Component-based Distributed Applications," depends on it,
    by using two IDL structures that mutually and indirectly
    recurse, effectively using [third example]

    struct Package;
    typedef sequence<Package> PackageSeq;

    struct Assembly;
    typedef sequence<Assembly> AssemblySeq;

    struct Package

    { AssemblySeq as; }

    ;

    struct Assembly

    { PackageSeq ps; }

    ;

    In reality, the IDL in question is a bit more complicated,
    using some intermediate structures, which makes rewriting
    the IDL without this mutual recursion impractical and
    non-intuitive – also because both "Package" and "Assembly"
    are meant to be potentially top-level, stand-alone items.

    Some might argue that the IDL restriction existed before
    the "Deployment" specification was adopted, and that CORBA
    should not be changed just because some later spec
    willingly (or rather, naively) used buggy IDL.

    So let me make some more arguments in favor of my request.

    First, as explained above, IDL already allows for indirect
    recursion. It just requires nesting.

    Second, defining structures as a "side-effect" of a member
    declaration is ugly, only marginally better than anonymous
    types. Allowing the type definition of a member to stand
    by itself is, in my opinion, much cleaner.

    Third, indirect recursion between non-nested types is no
    more difficult to implement in an ORB than indirect recursion
    between nested types.

    In fact, some existing ORB products already have no problem
    with indirect recursion, and are able to compile the IDL
    from the third example, resulting in correct code. The code
    works fine with Mico, TAO, JacORB and Combat, all of which
    apparently neglect to implement the check that "sequence
    members that are recursive must refer to an incomplete type
    currently under definition."

    OmniORB does issue a diagnostic, but simply removing the
    check, and making another trivial change to its IDL compiler,
    results in correct C++ code.

    Four, the existing IDL syntax, TypeCodes, CDR marshalling
    rules, and Interface Repository all allow indirect recursion
    to exist. In fact, it is already possible to create the
    above data types using the Interface Repository and
    TypeCode interfaces – as well as to create instances
    using DynamicAny, and to marshal them.

    With this background, I suggest to remove the statement
    that prevents indirect recursion between non-nested
    structures and unions.

    Proposed resolution:

    In section 3.12.2.3, change paragraphs (counting each IDL
    code example as a single paragraph) 10 to 12 (page 3-42)
    from

    If a recursive structure or union member is used,
    sequence members that are recursive must refer to
    an incomplete type currently under definition. For
    example

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Illegal, Foo is not an enclosing }

    ; // struct or union.

    Compilers shall issue a diagnostic if this rule is
    violated.

    to

    If a sequence member of a structure or union refers
    to an incomplete type, the structure or union itself
    remains incomplete until the member's definition is
    completed. For example

    struct Foo;
    typedef sequence<Foo> FooSeq;
    struct Bar

    { long value; FooSeq chain; // Use of incomplete type }

    ; // Bar itself remains incomplete
    struct Foo

    { // ... }

    ; // Foo and Bar are complete

    Thank you for listening. Also thanks to Jeff Parsons
    and Boris Kolpakov from Vanderbilt University for
    researching this issue.

    We, the submitters of the "Deployment" specification,
    genuinely believe that indirect recursion is useful,
    and its lack (and having to work around) would take
    considerable value from the specification.

    I am uncomfortable arguing to change another spec
    to fix ours. But one spec has to change, and I believe
    that indirect recursion is a useful feature that already
    (unwillingly) exists in many ORBs, that it is no more
    problematic to implement than the existing means of
    recursion, and that the resulting data types are already
    valid when obtained from the TypeCode or Interface
    Repository interfaces.

    Considering the conflict of available specifications,
    I am tempted to flag this issue as urgent. Andrew, is
    that even possible, given that there is no active Core
    RTF?

  • Reported: CORBA 3.0.3 — Wed, 17 Aug 2005 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Key: CORBA35-99
  • Legacy Issue Number: 5515
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Implementation Element Cardinality. Why does it make sense to have an empty
    implementation or to allow multiple elements such as code, description,
    humanlanguage, or to have no code? Suggested changes are to place the
    correct
    cardinality on the implementation elements. The suggested elements
    cardinality
    changes will make parsing the XML much simpler and reduce code footprint,
    and the
    XML more understandable.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    Suggested New Format for implementation

    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One code element is required for a given implementation
    • Zero or one complier element. A given source code element is compiled
      by a
      specific compiler. Specifying the compiler is optional.
    • Zero or one programminglanguage element. Specifying the
      programminglanguage is optional.
    • Zero or one humanlanguage element. Specifying the humanlanguage is
      optional.
    • Zero or more dependencies for a specific implementation.
    • Zero or more descriptors for a specific implementation. An
      implementation
      may contain multiple different components.
    • Zero or more runtimes. A given code element may be compatible with
      multiple runtime environments.
    • Zero or more os. A given code element may be compatible with multiple
      operating systems.
    • Zero or more processors. A given code element may be compatible with
      multiple processors.
    • Zero or more extensions.

    <!ELEMENT implementation
    ( description?
    , code
    , compiler?
    , humanlanguage?
    , programminglanguage?
    , propertyfile?
    , ( dependency

    descriptor
    extension
    os
    processor
    runtime
    usescomponent
    )*
    )>
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 Software Package Descriptor

  • Legacy Issue Number: 5514
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    69.3.2.1 The softpkg Root Element, page 69-473
    Softpkg Element Cardinality. Why does it make sense to have an empty
    softpkg
    file or to allow multiple elements such as title, pkgtype, description,
    license, or to
    have no implementations? Suggested changes are to place the correct
    cardinality
    on the softpkg elements to be similar to the CORBA Component and Component
    Assembly Descriptor definitions. The suggested elements cardinality changes
    will
    make parsing the XML much simpler and reduce code footprint, and the XML
    more understandable.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #OPTIONAL >

    Suggested New Format for Softpkg

    • Zero or one title ? for example, a book only has one title, not
      multiple titles.
    • One or more authors ? for example, a book can have multiple authors,
      but at
      least one.
    • Zero or one description, the CAD and CORBA Components DTDs define the
      description this way.
    • Zero or one package type.
    • Zero or one property file reference. Why are multiple property files
      needed?
    • One or more implementations, since the softpkg is an implementation
      for a
      component definition then it must have at least one implementation.
    • Zero or more dependencies for all implementations.
    • Zero or more descriptors for all implementations. An implementation
      may
      contain multiple different components.
    • Zero or more IDL files for all implementations.
    • Zero or more extensions.

    <!ELEMENT softpkg
    ( title?
    , author+
    , description?
    , propertyfile?
    , license?
    , pkgtype?
    , implementation+
    , ( idl

    dependency
    descriptor
    extension
    )*
    )>
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add the capability to define a component artifact property

  • Legacy Issue Number: 5513
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    7. Component Artifact - Add the capability to define a component artifact
    property. For
    example, a logical device component artifact could be used to specify the
    capacity for
    a device or the characteristic of a device. The artifacts for a component
    are referenced
    by a component's implementation dependency for using or deployed on
    relationships.
    The component artifact property could be defined in two ways: 1) a new
    element
    called artifact or modifying the simple definition with optional new
    artifact element.

    Artifacts are simple types. The action element defines the action that can
    be
    performed on an artifact. When a dependency references an artifact with a
    specified value this is the action that can be performed against a
    component's
    artifact. The ID is a DCE UUID to guarantee uniqueness of the artifact
    within the
    system; so 2 different artifacts, which are different, are not viewed to be
    the same
    artifact when they are not. The action denoted as external indicates the
    artifact is
    managed by the component. A referenced value for an artifact would have to
    be
    applied against the component.

    Example 1 of New Artifact Element

    <!ELEMENT artifact
    ( description?
    , simple
    , action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED>

    <!ELEMENT action EMPTY>
    <!ATTLIST action
    type ( eq | ne | gt | lt | ge | le | external ) "external">

    Change properties element to

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    artifact
    valuetype
    )+
    ) >

    Example 2 of Modified Simple Element with new Artifact element

    <!ELEMENT simplekind EMPTY>
    <!ATTLIST simplekind
    kindtype (configure_writeonly | configure_readwrite | execparam |
    query_readonly | factoryparam | artifact) "configure_readwrite">

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , simplekind*
    , artifact?
    , defaultvalue?
    ) >

    <!ELEMENT artifact
    ( action
    )>
    <!ATTLIST artifact
    id ID #REQUIRED
    action ( eq | ne | gt | lt | ge | le | external ) "external">

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.9 The sequence Element

  • Legacy Issue Number: 5511
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Simple Sequence -The current definitions for sequence allow invalid
    definitions to be
    built but be syntactically correct. A better definition for a simple
    sequence would be as
    follows:

    Current sequence element

    <!ELEMENT sequence
    ( description?
    , ( simple*

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    Change to

    Add a new simplesequence element:

    <!ELEMENT simplesequence
    ( description?,
    , values?
    , choices?
    , range?
    , enumerations?
    , units?
    )>
    <!ATTLIST simplesequence
    name CDATA #IMPLIED
    type ( boolean | char | double | float | short | long | objref |
    octet | string | ulong

    ushort ) #REQUIRED

    <!ELEMENT values
    ( value+
    )>

    Change sequence to:

    <!ELEMENT sequence
    ( description?
    , ( simplesequence

    struct*
    sequence*
    valuetype*
    )
    ) >
    <!ATTLIST sequence
    name CDATA #IMPLIED
    type CDATA #REQUIRED >

    One does not have to keep repeating the same simple definition. This
    definition
    then has the added advantage where simple name attribute can now be made
    mandatory.
    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >
    <!ATTLIST simple
    name CDATA #REQUIRED
    type ( boolean

    char
    double
    float
    short
    long
    objref
    octet
    string
    ulong
    ushort
    ) #REQUIRED >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Test Property - add a test property definition to the properties DTD

  • Legacy Issue Number: 5512
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    This allows one
    to define test properties for a component in a generic way. The Test
    property is based upon simple
    element.

    Add new test element

    <!ELEMENT test
    ( description
    , inputvalue?
    , resultvalue )>
    <!ATTLIST test
    name CDATA #REQUIRED>

    <!ELEMENT inputvalue
    ( simple+ )>

    <!ELEMENT resultvalue
    ( simple+ )>

    Change properties element to:

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    test
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.3 The choices Element, page 69-537

  • Legacy Issue Number: 5510
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Choices Element - It appears multiple ranges do not make sense for a simple
    definition. If so, then remove the range element from the choices element
    definition
    and make range an optional element for a simple.

    Current definition
    <!ELEMENT choices ( choice | range )+

    Change to

    <!ELEMENT choices ( choice )+

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , range?
    , defaultvalue?
    ) >

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The range Element, pages 69-537/538

  • Legacy Issue Number: 5509
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Range Element - why is the min and max order not specified?
    <!ELEMENT range (value, value) >

    I understand the software logic can do a compare to determine the min and
    max values, but it seems the following definition would be easier to
    understand from human reader.

    Change Range to

    <!ELEMENT range EMPTY>
    <!ATTLIST range
    min CDATA #REQUIRED
    max CDATA #REQUIRED>

  • Reported: CORBA 3.0 — Wed, 24 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Component Artifact Dependency

  • Key: CORBA35-92
  • Legacy Issue Number: 5522
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    An implementation may request a dependency on a specific component based
    upon
    its artifacts. Add artifactdependency to the dependency element.

    Current Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    ) >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    New Format

    <!ELEMENT dependency
    ( softpkgref

    codebase
    fileinarchive
    localfile
    name
    valuetypefactory
    )
    , artifactdependency*
    >
    <!ATTLIST dependency
    type CDATA #IMPLIED
    action (assert
    install)"assert">

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested
    or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.25 The propertyfile Element, page 69-482

  • Key: CORBA35-96
  • Legacy Issue Number: 5518
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Propertyfile clarification is needed for consistent behavior.
    The only statement made about propertyfile is that the implementation's
    propertyfile
    has precedence over the same propertyfile types at the softpkg level. Why
    are
    multiple property files needed at the softpkg and implementation levels? If
    more than
    one propertfile exist at any level, which property file has precedence in
    the list? If
    multiple property files exists are they merged together? Are the softpkg's
    descriptor
    element property files merge with the softpkg property files and which one
    has
    precedence? Are the implementation's descriptor property files merge with
    the
    implementation property files, and which one has precedence? Are
    implementation
    property files merge with the softpkg property files?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.2 The author Element, page 69-474

  • Key: CORBA35-93
  • Legacy Issue Number: 5521
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Change the format of author to group related authors together from a
    company. One
    does not need the capability to list multiple companies and web sites
    together in the
    author element, since there can be many authors listed in the softpkg
    element. The
    suggested elements cardinality changes will make parsing the XML much
    simpler
    and reduce code footprint, and the XML more understandable.
    Current format

    <!ELEMENT author
    ( name

    company
    webpage
    )* >

    New format

    <!ELEMENT author
    ( name*
    , company?
    , webpage?
    )>

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.14 The idl Element, page 69-478

  • Key: CORBA35-95
  • Legacy Issue Number: 5519
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add idl element to implementation element. Why is idl only at the
    softpkg level?
    This is saying that all implementations use the same IDL. This is
    inconsistent with
    descriptor element. An implementation can specify a descriptor, why not
    idl? Cannot
    an implementation use a specific IDL for its implementation?

    b) Why is IDL defined in the software package descriptor instead of the
    CORBA
    Component descriptor?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Descriptor

  • Key: CORBA35-94
  • Legacy Issue Number: 5520
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    How does the Assembly Descriptor support multiple components within an
    implementation?

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The code Element, pages 69-474

  • Key: CORBA35-98
  • Legacy Issue Number: 5516
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    a) Add the optional stacksize and priority elements to code element
    definition. The
    stack size and priority are options parameters for an operating system's
    execute()
    operation. The stack size is the memory space needed by the executable and
    the OS
    priority for the executable. Data types for the values of these options are
    unsigned
    long. Priority number should be based upon industry standard such as POSIX.

    Current Format

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    New Format for code

    <!ELEMENT code
    ( ( codebase

    fileinarchive
    link
    )
    , entrypoint?
    , stacksize?
    , priority?
    , usage?
    ) >
    <!ATTLIST code
    type CDATA #IMPLIED >

    <!ELEMENT stacksize (#PCDATA)>

    <!ELEMENT priority (#PCDATA)>

    b) Other valid values for type attribute
    Additional valid values for the type attribute are: "KernelModule",
    "SharedLibrary", and "Driver".

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Key: CORBA35-97
  • Legacy Issue Number: 5517
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Add license element to implementation element. Why is the license element
    restricted
    to the softpkg level only? This is saying all implementations have the same
    license.
    Cannot each implementation have its own different license? Suggest adding
    license
    element to implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    license
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >
  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Checking XML DTD elements related to the trader service

  • Key: CORBA35-67
  • Legacy Issue Number: 5590
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-533, there is the following note

    Issue The trader elements have to be reviewed to make
    sure that they serve the purpose intended.
    Also, consider using a property file.

    XML DTD elements related to the trader service would be checked

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Description for the impltype Element?

  • Key: CORBA35-68
  • Legacy Issue Number: 5589
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In formal/02-06-65, page 6-54, there is the following text

    Placeholder for future version.

    The section 6.7.2.33 would be written.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Uses Relationships

  • Key: CORBA35-70
  • Legacy Issue Number: 5524
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    The softpkg element only deals with deployed on and library load dependency
    relationships for implementations. Component implementations may also have
    specific using relationships with another component, such as a device
    within the
    system. This relationship can be stated at the softpkg or implementation
    level.

    Current Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT softpkg
    ( title

    pkgtype
    author
    description
    license
    idl
    propertyfile
    dependency
    descriptor
    implementation
    extension
    usescomponent
    )* >
    <!ATTLIST softpkg
    name ID #REQUIRED
    version CDATA #IMPLIED >

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    usescomponent
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT usescomponent
    ( artifactdependency+
    )>
    <!ATTLIST usescomponent
    id ID #REQUIRED
    type CDATA #REQUIRED>

    <!ELEMENT artifactdependency EMPTY>
    <!ATTLIST artifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Device Artifact Dependency

  • Key: CORBA35-71
  • Legacy Issue Number: 5523
  • Status: open  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    A component's implementation may have additional dependencies on a device's
    artifacts (e.g., capacity and/or characteristics) to ensure the right type
    of device is
    chosen for deployment and/or the device has sufficient capacities for
    deployment. To
    allow for this capability add a deviceartifactdependency element to the
    implementation element.

    Current Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    New Format

    <!ELEMENT implementation
    ( description

    code
    compiler
    dependency
    descriptor
    extension
    programminglanguage
    humanlanguage
    os
    propertyfile
    processor
    runtime
    deviceartifactdependency
    )* >
    <!ATTLIST implementation
    id ID #IMPLIED
    variation CDATA #IMPLIED >

    <!ELEMENT deviceartifactdependency EMPTY>
    <!ATTLIST deviceartifactdependency
    artifactrefid CDATA #REQUIRED
    artifactvalue CDATA #REQUIRED>

    Note: This concept is tied to the concept of component artifact property
    issue. The
    artifactrefid is a reference to a component's artifact property defined in
    a
    component's property file. The artifactvalue is the dependency value being
    requested or needed.

  • Reported: CORBA 3.0 — Wed, 17 Jul 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Dependency on D+C FTF

  • Key: CORBA35-72
  • Legacy Issue Number: 7363
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Lightweight CCM replaces CCM's Packaging and Deployment chapter
    with the "Deployment and Configuration of Component-based Distributed
    Applications" (D+C) specification, and thus Lightweight CCM cannot be
    finalized before D+C.

    I propose to defer this issue to a second FTF, to be resolved by the
    availability of D+C.

  • Reported: CORBA 3.0.3 — Wed, 19 May 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

A new exception specification is needed for CCM2Context::req_passivate()

  • Key: CORBA35-64
  • Legacy Issue Number: 5639
  • Status: open  
  • Source: THALES ( Hakim Souami)
  • Summary:

    Document ptc/2001-11-03, CORBA Component Model
    ----------------------------------------------
    62.4.1.1 The CCM2Context Interface
    ....
    local interface CCM2Context : CCMContext

    { HomeRegistration get_home_registration (); void req_passivate () raises (PolicyMismatch); CatalogBase get_persistence (in _TypeId catalog_type_id) raises (PersistenceNotAvailable); }

    ;

    ....
    req_passivate
    The req_passivate operation is used by the component to inform the container
    that it wishes to be passivated when its current operation completes. To be
    valid, the component must have a servant lifetime policy of component or
    container. If not, the PolicyMismatch exception shall be raised.
    ----------------------------------------------

    What happens if req_passivate() operation is not called in the scope of a
    callback operation?
    I think that req_passivate() can only make sense if called in the context of
    a callback operation. The IllegalState exception is appropriate for this
    case.

    The IDL might then look like this :
    void req_passivate () raises (IllegalState,PolicyMismatch);

    and the following sentence might be appended to the paragraph above:
    "If this operation is issued outside of the scope of a callback operation,
    the IllegalState exception is returned."

    This addition will ease implementation of CCM2Context objects based on
    POACurrent : implementing container and component servant lifetime policies
    on a POA with RETAIN servant retention policy and the other servant lifetime
    policies on a POA with NON_RETAIN servant retention policy can rely entirely
    on the POACurrent.

  • Reported: CORBA 3.0 — Fri, 6 Sep 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Derived component supported interface restriction (formal/2002-06-65)

  • Key: CORBA35-62
  • Legacy Issue Number: 5688
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    Both the CORBA spec (formal/02-06-01 page 3-61) and the CCM spec (formal/02-06-65 page 1-51) state that "A derived component type may not directly support an interface." Moreover the sentence you depicted is a contradiction with the formal/02-06-65 section 1.3.2.4 page 1-7.

    Resolution:

    In formal/02-06-65 page 1-51 and formal/02-06-01 page 3-61 replace the sentence

    "A derived component type may not directly support an interface."

    with

    "If a derived component type directly supports one or more IDL interfaces, the component interface is derived from both the interface of its base component type and the supported interfaces."

  • Reported: CORBA 3.0 — Thu, 10 Oct 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue on the description of the consumesidentifier element

  • Key: CORBA35-63
  • Legacy Issue Number: 5684
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    section 6.7.2.15, page 6-50, replace 'consumingcomponent' by
    'consumesport'.

    Proposed revised text:

    In formal/02-06-65 page 6-50, replace
    A child of consumingcomponent
    by
    A child of consumesport

  • Reported: CORBA 3.0 — Mon, 14 Oct 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using Configurator on CCMHome or any CORBA objects?

  • Key: CORBA35-66
  • Legacy Issue Number: 5591
  • Status: open  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 69-545, there is the following note

    Issue The Configurator interface takes an argument of type
    CCMObject and therefore cannot be used to configure component
    homes. I see no reason not to widen the type to CORBA::Object
    so that the Configurator can be used for objects other than
    CCMObjects. The StandardConfigurator is after all a basic name
    value pair configurator that simply executes calls on mutator
    operations resulting from attribute declarations. J.S.E.

    The Configurator interface could be updated to allow configuration
    of any CORBA objects.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3

  • Key: CORBA35-55
  • Legacy Issue Number: 5903
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    To maintain a consistent style and to provide a detailed
    description in an XML element's first appearance, Section 6.4.5.26
    and Section 6.4.5.30 should be moved under Section 6.3 and changed
    to referring them back to the corresponding subsections like
    Section 6.4.5.29 does.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.10 (page 6-26)

  • Key: CORBA35-56
  • Legacy Issue Number: 5902
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    Section 6.4.5.10 (page 6-26): one of the child elements of the
    "containermanagedpersistence" element is "psstransactionpolicy" where
    it should have been "psstransaction" instead (see Section 6.4.5.40
    on page 6-34 and Section 7.2 on page 7-6 and 7-7).

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

3.2.7 Compositions with Managed Storage

  • Key: CORBA35-59
  • Legacy Issue Number: 5871
  • Status: open  
  • Source: Opus Software ( Alexandre Ricardo Nardi)
  • Summary:

    Need to reflect the change in the PSS specification, in which the catalog is not user-defined anymore. The example and the cidl syntax (chapter 2) need to be changed too.

  • Reported: CCM 3.0 — Tue, 25 Feb 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.52 (page 6-38)

  • Key: CORBA35-57
  • Legacy Issue Number: 5900
  • Status: open  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    1. Section 6.4.5.52 (page 6-38): It says the the "storagehome" element
    is a child element of "segment" where it should really say it is a
    child element of "containermanagedpersistence" instead.

  • Reported: CORBA 3.0.2 — Fri, 18 Apr 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

'local executor mapping'

  • Key: CORBA35-52
  • Legacy Issue Number: 5937
  • Status: open  
  • Source: Anonymous
  • Summary:

    @@ It seems to me that generating 'local executor mapping' for supported
    by a component interfaces is not needed. Even though spec doesn't say
    directly that it's needed or not there are plenty of examples where it is
    shown generated.

    @@ According to the spec the following IDL is valid

    interface I;
    component C

    { provides I i; };


    while this is not:


    interface I;
    component C
    { uses I i; };


    Any reason for that?


    @@ According to the spec Home cannot be forward-declared. Any reason
    for that?



    @@ The following CIDL is legal according to the spec:


    interface I;
    component C
    { provides I i; }

    ;

    home H manages C
    {
    };

    composition session Impl
    {
    home executor H_Exec

    { implements H; manages C_Exec; };
    };


    However there is no way to generate valid local executor mapping for this
    CIDL. The resolution would be to require all forward-declared interfaces
    used by component's provides declarations to be defined before composition
    for this component is seen. I.e. the following CIDL would be a corrected
    version:


    interface I;
    component C
    { provides I i; };


    home H manages C
    {
    };


    interface I {};


    composition session Impl
    {
    home executor H_Exec
    { implements H; manages C_Exec; }

    ;
    };

    @@ The following legal according to the spec IDL:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    would result in local executor mapping that looks something like this:

    module M
    {
    module Components
    {
    struct EnterpriseComponent {};
    };

    component C {};
    };

    module M
    {
    local interface C : Components::EnterpriseComponent {};
    };

    which is illegal IDL. The resolution would be to require names like
    Components::EnterpriseComponent to be fully qualified e.g.
    ::Components::EnterpriseComponent.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA35-50
  • Legacy Issue Number: 6672
  • Status: open  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The EnterpriseComponent should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the EnterpriseComponent interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components { local interface EnterpriseComponent {}; };

    with

    module Components { local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CCM 3.0 — Thu, 4 Dec 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a set_persistent_object method

  • Key: CORBA35-44
  • Legacy Issue Number: 7732
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    There is no standard way for container to intercept component state management.
    By which container can implement O/R mapping and management component states.

    Resolution:

    Container can intercept state management by provide a storage object for executor segment.
    Replace the following text in formal/02-06-05 on page 3-39

    module Components
    {
    local interface EnterpriseComponent
    {

    };
    };

    with

    module Components
    {
    local interface EnterpriseComponent

    { void set_persistent_object(in StorageObjectBase); }

    ;
    };

    and add the operation description

    set_persistent_object

    Set context object for executors

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a set_context method

  • Key: CORBA35-43
  • Legacy Issue Number: 7733
  • Status: open  
  • Source: National Lab, Distributed Process, China ( Deng Bo)
  • Summary:

    Home executor cann't access context object. Thus some features like SMP(Self-Management Persistence) are not enabled.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { void set_context(in CCMContext con); }

    ;
    };

    and add the operation description

    set_context

    Set context object for home executor.

  • Reported: CORBA 3.0.3 — Fri, 10 Sep 2004 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA35-46
  • Legacy Issue Number: 6689
  • Status: open  
  • Source: Anonymous
  • Summary:

    This question is similar to the first one. When creating component or
    facet reference of service or session component, the first step is
    creating the object reference and associating its
    PortableServer::ObjectId with servant. Currently, the container manages
    executor, but the HomeExecutorBase interface does not provide a
    mechanism to get servant. The method would be very useful as it means
    the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components {
    local interface HomeExecutorBase {};
    };

    with

    module Components {
    local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA35-47
  • Legacy Issue Number: 6688
  • Status: open  
  • Source: Anonymous
  • Summary:

    When creating component or facet reference of service or session
    component, the first step is creating the object reference and
    associating its PortableServer::ObjectId with servant. Currently, the
    container manages executor, but the EnterpriseComponent interface does
    not provide a mechanism to get servant. The method would be very useful
    as it means the container can use executor to get servant, which is not
    possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-39

    module Components {
    local interface EnterpriseComponent {};
    };

    with

    module Components {
    local interface EnterpriseComponent

    { Servant get_servant() raises (CCMException); }

    ;
    };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Fri, 5 Dec 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA35-49
  • Legacy Issue Number: 6673
  • Status: open  
  • Source: National Lab. on Distributed Processing of P.R.China ( Deng Bo)
  • Summary:

    The HomeExecutorBase should have a get_servant method. When creating component or facet reference of service or session component, the first step is creating the object reference and associating its PortableServer::ObjectId with servant. Currently, the container manages executor, but the HomeExecutorBase interface does not provide a mechanism to get servant. The method would be very useful as it means the container can use executor to get servant, which is not possible now.

    Resolution:

    Replace the following text in formal/02-06-05 on page 3-40

    module Components { local interface HomeExecutorBase {}; };

    with

    module Components { local interface HomeExecutorBase

    { Servant get_servant() raises (CCMException); }

    ; };

    and add the operation description

    get_servant

    The get_servant operation returns a reference to the servant.

  • Reported: CORBA 3.0.2 — Thu, 4 Dec 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

add some feature to let an assembly look like a monolithic compoment

  • Key: CORBA35-42
  • Legacy Issue Number: 9173
  • Status: open  
  • Source: nudt ( jhuang)
  • Summary:

    It is better to add some feature to let an assembly look like a monolithic compoment. For example, add some discriptions in CAD(compoment assembly discription) file to identify the external interface of an assembly. There exists an delegate compoment behaving like the assembly. It can navigate one external interface of an assembly to another. This delegate compoment can be created by main component server automatically according to the CAD file.

  • Reported: CORBA 3.0.3 — Fri, 18 Nov 2005 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interface Introspection

  • Key: CORBA35-22
  • Legacy Issue Number: 6391
  • Status: open  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    Inspired by a recent paper by Doug Schmidt and Steve Vinoski
    and the resulting newsgroup discussion on comp.object.corba,
    I have a feature request to introduce a better reflection
    mechanism into CORBA.

    At the moment, there is the CORBA::Object::get_interface()
    operation to access a matching InterfaceDef entry in an
    Interface Repository. Since an Interface Repository is
    seldomly deployed, using this operation is pretty much
    futile and will either return a nil reference or throw
    an exception.

    Therefore, I propose to add a new get_interface_def()
    operation to the Object interface that returns a FullInter-
    faceDef structure, as defined by the Interface Repository.
    This structure contains all that a dynamic client (such as
    the ones proposed by Schmidt&Vinoski, or software like
    CorbaScript or Combat) needs to know about an interface.

    A new _interface_def pseudo-operation then needs to be added
    to GIOP. This could probably be done without a version change,
    as no marshalling changes or new messages are involved, it's
    just another operation.

    On the server side, the IDL compiler would generate a suitable
    implementation as part of the skeleton. This implementation
    could just contain a binary representation of the FullInterface-
    Description structure (just like a "precompiled" TypeCode) that
    is dumped to the GIOP stream. (So that you don't need the
    Interface Repository IDL around.)

    Proposed resolution:

    In chapter 4.3, "Object Reference Operations," add the following
    operation to the Object interface:

    module CORBA {
    interface Object

    { // PIDL ... other operations ... FullInterfaceDescription get_interface_def (); }

    ;
    };

    Add the following explanation to 4.3.1, "Determining the Object
    Interface"

    4.3.1.2 get_interface_def

    FullInterfaceDescription get_interface_def ();

    The get_interface_def operation returns a data structure
    describing the most derived type of the object addressed by
    the reference. The FullInterfaceDescription structure includes
    descriptions of all the operations and attributes in the
    transitive closure of the inheritance graph of the interface
    being described. See the Interface Repository chapter for the
    contents of the data structure. Note that if an Interface
    Repository is not available, object references contained in
    this structure may be nil or inaccessible.

    In chapter 15.4.2, "Request Message", update the text that
    reads

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers and _component.

    to read

    In the case of CORBA::Object operations that are defined in
    the CORBA Core (Section 4.2, "Object Reference Operations,"
    on page 4-12) and that correspond to GIOP request messages,
    the operation names are _interface, _is_a, _non_existent,
    _domain_managers, _component or _interface_def.

    In the C++ language mapping, section 1.37.1, "Mapping of
    PortableServer::Servant", add the following operation to
    class ServantBase:

    namespace PortableServer { // C++
    class ServantBase

    { ... other operations ... virtual CORBA::FullInterfaceDescription_ptr _get_interface_def (); }

    ;
    }

    Update the paragraph that reads,

    ServantBase provides default implementations of the
    _get_interface, _is_a and _non_existent object reference
    operations [...]

    to read

    ServantBase provides default implementations of the
    _get_interface, _is_a, _non_existent and _get_interface_def
    object reference operations [...]

    Add a new paragraph,

    For static skeletons, the default implementation of the
    _get_interface_def function returns information about the
    interface associated with the skeleton class. For dynamic
    skeletons, the default implementation uses the
    _get_interface function to determine its return value.

    Other language mappings might need similar updates.

    By the way, since FullInterfaceDescription is only used as
    a return value, only a pointer to FullInterfaceDescription
    is needed. Therefore, you don't need the full Interface
    Repository interface descriptions but only a pointer to an
    incomplete type.

    On the client side, you only need to pull in the Interface
    Repository IDL if you are actually calling _get_interface_def.

    On the server side, the skeleton can do some ORB-dependent
    magic to push a precompiled binary data structure into the
    result.

  • Reported: CORBA 3.0.2 — Mon, 27 Oct 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Session2Context interface

  • Key: CORBA35-27
  • Legacy Issue Number: 5909
  • Status: open  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    The Session2Context interface allows developers to create an object reference from an octet sequence (object id). The the Entity2Context allows developers to create an object reference from a ComponentId. Neither the Session2Context nor the the Entity2Context allows the developer to infer the octet sequence or ComponentId that is associated with an operation invocation on a component. In other words, a developer may use a context to create multiple references that are subsequently invoked by a client. When the client invokes an operation on the reference the component code will be required to satisfy the operation invocation (either through the monolithic or the locator language mapping strategy). There is no information, however, as to which of the created references is being invoked by a client. To resolve the ambiguity the component developer must be able to use the context to provide the current octet sequence or ComponentId corresponding to the reference that is currently being invoked.

    Resolution:

    Replace the following text in formal/02-06-05 on page 4-37

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); }

    ;

    with

    local interface Session2Context : SessionContext, CCM2Context

    { Object create_ref (in CORBA::RepositoryId repid); Object create_ref_from_oid ( in PortableServer::ObjectIdCORBA::OctetSeq oid, in CORBA::RepositoryId repid); PortableServer::ObjectId CORBA::OctetSeq get_oid_from_ref (in Object objref) raises (IllegalState, BadComponentReference); CORBA::OctetSeq get_current_oid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_oid

    The get_current_oid operation is used by the component to extract the oid
    associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

    Also, replace the following text in formal/02-06-05 on page 4-44

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); }

    ;

    with

    local interface Entity2Context : EntityContext, CCM2Context

    { ComponentId get_component_id () raises (IllegalState); ComponentId create_component_id ( in FacetId target_facet, in SegmentId target_segment, in SegmentDescrSeq seq_descrs); ComponentId create_monolithic_component_id ( in FacetId target_facet, in StateIdValue sid); Object create_ref_from_cid ( in CORBA::RepositoryId repid, in ComponentId cid); ComponentId get_cid_from_ref ( in Object objref) raises (BadComponentReference); ComponentId get_current_cid () raises (IllegalState); }

    ;

    and add the operation description

    get_current_cid

    The get_current_cid operation is used by a persistent component to retrieve the
    ComponentId associated with the current operation invocation. This operation must be called
    within an operation invocation. If not, the IllegalState exception shall be raised.

  • Reported: CORBA 3.0.2 — Tue, 22 Apr 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 and page 1-21 - editorial

  • Key: CORBA35-16
  • Legacy Issue Number: 5945
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    -page 1-20 and page 1-21 the names of the operations get_all_receptacles get_named_receptacles are written with italic font. This seems to be a mistake.

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

Change new GIOP Negotiate Session Message to Firewall Specific

  • Key: CORBA35-20
  • Legacy Issue Number: 6285
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Here is a small proposal for GIOP 1.4 with Firewall and Bidirectional. We
    would get rid of all the weird nasty service contexts and make it
    simplistic. The FireWall messages are only allowed before any other GIOP
    messages. BiDir messages can happen at any time according to their
    protocol.

    What do you think? Asside from some problems I see with BiDir
    offer/challenge/response correlation, it is essentially equivalent to the
    solution proposed in the adopted spec.

    module GIOP {
    enum MsgType_1_4

    { Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment, // GIOP 1.1 addition // GIOP 1.4 additions FirewallPathRequest, // 8 FirewallPathRepsonse, // 9 BiDirOffer, // 10 BiDirChallenge, // 11 BiDirResponse // 12 }

    ;

    // Firewall Traversal GIOP 1.4

    struct FirewallSpec

    { boolean is_intelligent; IOP::TaggedComponentSeq endpoints; }

    ;
    typedef sequence<FirewallSpec> FirewallPath;

    struct FirewallPathRequestHeader

    { unsigned long host_index; FirewallPath path; }

    ;
    // No body follows.

    enum FirewallPathResponseStatusType

    { NO_EXCEPTION, SYSTEM_EXCEPTION }

    ;

    struct FirewallPathResponseHeader

    { FirewallPathResponseStatusType status; boolean connection_complete; }

    ;
    // Marshalled body immediately follows

    // Bidirectional GIOP 1.4

    // To keep this file uncomplicated we can introduce the
    // headers and put the marshalled bodies in a separate BiDir module
    // Due due some issue about the challege/response protocol for this,
    // there may be a need of an offer_id to correlate them.

    struct BiDirOfferHeader

    { unsigned long offer_id; };
    // Marshalled body immediately follows.


    struct BiDirChallengeHeader { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.

    struct BiDirResponseHeader

    { unsigned long offer_id; }

    ;
    // Marshalled body immediately follows.
    };

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP Conformance and Interceptors

  • Key: CORBA35-19
  • Legacy Issue Number: 6314
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    GIOP Conformance and Interceptor don't play well together.

    GIOP minor version conformance mandates two things.

    1. That standard service contexts that are considered optional
    can be ignored should the implementation not understand them.

    2. That certain service contexts get processed according to the
    specification of where they are defined.

    This requirement works well for GIOP 1.2 where a lot of them are optional,
    since (1) will apply. An implementation can claim 1.2 conformance and not
    process any of them.

    However, 1.3 and upcoming 1.4 will mandate the processing of them
    according to their specification. In many cases, this means that some
    default response may be required, which means that a GIOP 1.3, or later
    engine must have a "default" response for these service contexts.

    In an ORB that uses interceptors and has a generic GIOP messaging engine
    there is no way for the engine to "know" when or not to process a
    particular service context. It requires strict processing by the GIOP
    engine, or it requires "default" interceptors to be installed to maintain
    the level of conformance.

    However, interceptors have no way of "declaring" which service contexts
    they handle, and whether they they are overriding already installed
    (default) interceptors for processing those particular service contexts.

    For example, an non-transactional ORB that is GIOP 1.2 compliant must
    process the Transaction Service Context by raising a
    TRANSACTION_UNAVAILABLE exception, because by default the ORB is in the
    OTS_NOT_CONNECTED state. It cannot be ignored to comply with GIOP 1.2 (but
    by certain in implementations it ALWAYS is). A default interceptor is
    needed in the ORB implementation to do this. However, for an ORB
    configuration that wants to process this, there is no way for an
    interceptor to "override" default processing.

  • Reported: CORBA 3.0.2 — Wed, 8 Oct 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

context interface for home implementation

  • Key: CORBA35-18
  • Legacy Issue Number: 5936
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The home interface could have freely defined operations or can support an
    interface with such operations. A home context interface may help to implement
    such operations. E.g. a home implementation needs this context interface to
    determine its own object reference.

    suggestion:

    Add a home context interface that is similar to the component context interface.
    Add a set_context operation at the HomeExecutorBase interface.

  • Reported: CORBA 3.0.2 — Wed, 7 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 the description of the get_connection operation

  • Key: CORBA35-17
  • Legacy Issue Number: 5944
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    page 1-20 the description of the get_connection operation refers to a ConnectionDescription struct. In fact it is a ConnectionDescription valuetype

  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet and CSIv2 Negotitaion

  • Key: CORBA35-21
  • Legacy Issue Number: 6283
  • Status: open  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    I believe that we send CSIv2 stuff in a GIOP Request until a corresponding
    GIOP reply has been containing corresponding CSIv2 context ids is sent.

    For Codeset, I think the policy is to send the service context in each
    GIOP request until a corresponding GIOP Reply is received, thereby saying
    that the "negotiation" is completed and excepted (otherwise an exception
    will be raised.

    We should probably look at the fact that multiple NSReq messages can be
    sent, and there are no corresponding reply messages depending on the
    service contexts.

    I think that these messages should be intercepted since they are
    delivering service contexts.

  • Reported: CORBA 3.0.2 — Thu, 2 Oct 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetype fragmentation ambiguous

  • Key: CORBA35-10
  • Legacy Issue Number: 5941
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    Although I now think I know the intent of the spec, its is ambiguous if not plain wrong with respect to valuetype fragmentation.

    In particular 15.3.4.6:

    Bullet 1 says:

    "End tags, chunk size tags, and value tags are encoded using non-overlapping ranges
    so that the unmarshaling code can tell after reading each chunk whether:
    • another chunk follows (positive tag).
    • one or multiple value types are ending at a given point in the stream (negative
    tag).
    • a nested value follows (special large positive tag)."

    Bullet 3 says:

    "• For the purposes of chunking, values encoded as indirections or null are treated as
    non-value data."

    And the pseudo-BNF says:

    "(1) <value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>

    <value_ref>
    (2) <value_ref> ::= <indirection_tag> <indirection>
    <null_tag>
    (3) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (4) <type_info> ::= <rep_ids>
    <repository_id>
    (5) <state> ::= <octets>
    <value_data>* [ <end_tag> ]
    (6) <value_data> ::= <value_chunk>
    <value>"

    Now clearly the implication of bullet 1 is that an indirection or null must appear inside a chunk in a chunked encoding, otherwise you would be able to see the value 0 or -1 after a chunk and the -1 in particular could mean an end tag or an indirection. However the possible implication of bullet 3 and the BNF (note the use of "value data") is that nulls and indirections are values and thus must appear outside of chunks. Clearly the former interpretation is the correct one otherwise anarchy ensues.

    So I propose that we change the 3rd bullet to say:

    "For the purposes of chunking, values encoded as indirections or null are treated as
    if they were not values and therefore must always appear inside a chunk when a chunked encoding is in effect."

    and then change the BNF to say:

    "(1) <value> ::= <concrete_value> | <value_ref>
    (2) <concrete_value> ::= <value_tag> [ <codebase_URL> ]
    [ <type_info> ] <state>
    (3) <value_ref> ::= <indirection_tag> <indirection> | <null_tag>
    (4) <value_tag> ::= long// 0x7fffff00 <= value_tag <= 0x7fffffff
    (5) <type_info> ::= <rep_ids> | <repository_id>
    (6) <state> ::= <octets> |<value_data>* [ <end_tag> ]
    (7) <value_data> ::= <value_chunk> | <concrete_value>"

    etc

  • Reported: CORBA 3.0.2 — Fri, 23 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 GMT

Clarification on multi-threaded codeset negotiation

  • Key: CORBA35-11
  • Legacy Issue Number: 5880
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We recently ran into a problem with a foreign Vendor's ORB and it appears the spec is unclear on this issue.

    The problem occurs when a multi-threaded client is connecting to a server. The spec says (13.10.2.6):

    "Codeset negotiation is not performed on a per-request basis, but only when a client
    initially connects to a server. All text data communicated on a connection are encoded
    as defined by the TCSs selected when the connection is established."

    but is silent on what is supposed to happen if the client has multiple threads all trying to connect at the same time. The issue is that priority inversion can occur - either because the client sends out a request without the negotiated codeset before the one with the negotiated codeset, or because the server processes the request without the negotiated codeset before the one with the negotiated codeset (even if the latter was sent first). The problem we encountered was the latter.

    There are two possible approaches to solving this:

    a) Require the server to serialize connection establishment requests until the codeset (and other connection information) is negotiated. This requires that the client impose appropriate ordering on connection requests.

    b) Require that the client keep sending codeset (and other connection information) until it is sure that the server has received the information (by getting a reply back). This works ok unless you are exclusively using oneways. In this instance you have to keep sending codeset information forever (somewhat costly, and very costly for codebase information).

    CSIv2 (26.2.2.3) explicitly calls out (b) but I prefer (a). Do we have any guidance on what is supposed to happen?

  • Reported: CORBA 3.0.2 — Tue, 11 Mar 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 GMT

15.3.3 - codesets must be "explicitly defined"

  • Key: CORBA35-12
  • Legacy Issue Number: 6050
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    For codesets in encapsulations we have:

    15.3.3 - codesets must be "explicitly defined"

    Issue 4824 - "it is an error for a Service Context to depend on information that is not contained within the encapsulation to determine the codeset used within it"

    But in 13.8 there is no prescribed way of "explicitly defining" the codeset.

    Please, please can we simply define that the fallbacks in 13.10.2.6 apply everywhere that the codeset is not known (whether negotiated or not) and be done with it.

    Another alternative would be to add codeset parameters to the encode() and decode() functions of 13.8.

  • Reported: CORBA 3.0.2 — Tue, 26 Aug 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 GMT

[Components] Contradiction between IDL and Interface Repository concerning

  • Key: CORBA35-13
  • Legacy Issue Number: 6671
  • Status: open  
  • Source: Humboldt-Universitaet ( Bertram Neubauer)
  • Summary:

    According to the IDL language it is allowed to define a facet/receptacle on a component with type of Object. The text says:

    A facet is declared with the following syntax:
    (120) <provides_dcl> ::= “provides” <interface_type> <identifier>
    (121) <interface_type> ::= <scoped_name>

    “Object”
    The interface type shall be either the keyword Object, or a scoped name that denotes
    a previously-declared interface type which is not a component interface, ...

    In contradiction to that the Interface Repository element for a component, the ComponentDef, does only allow the creation of facets/receptacles with type of InterfaceDef. The according operations are:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in InterfaceDef interface_type,
    in boolean is_multiple
    );

    Thus the ComponentDef can not be used to create a facet/receptacle that is of type Object, since Object is no InterfaceDef but a PrimitiveDef.
    One solution would be to use IDLType instead of InterfaceDef since PrimitiveDef and InterfaceDef inherit from that interface. My proposal is to change the Interface Repository IDL in the following way.

    1) replace in ComponentDef:

    // write interface
    ProvidesDef create_provides (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type
    );
    UsesDef create_uses (
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    in IDLType interface_type,
    in boolean is_multiple
    );

    2) replace ProvidesDef, ProvidesDecsription, UsesDef, UsesDescription with

    interface ProvidesDef : Contained

    { // read interface readonly attribute IDLType interface_type; }

    ;

    struct ProvidesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; }

    ;

    interface UsesDef : Contained

    { // read interface readonly attribute IDLType interface_type; readonly attribute boolean is_multiple; }

    ;

    struct UsesDescription

    { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; IDLType interface_type; boolean is_multiple; }

    ;

  • Reported: CORBA 3.0.2 — Wed, 3 Dec 2003 05:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 GMT

Chapter/section: 15.4.2.2 "Request Body"

  • Key: CORBA35-14
  • Legacy Issue Number: 6287
  • Status: open  
  • Source: 2AB ( Carol Burt)
  • Summary:

    Suppose you are sending a request (GIOP 1.2 or 1.3) and the request will
    be fragmented into two segments. The first segment is a Request message
    that has the GIOP Header and part of the Request Header. The second
    segment is a Fragment message that has a GIOP Header, a Fragment Header,
    and the body is the remainder of the Request Header and the Request Body.
    Section 15.4.2.2 of CORBA 3.0 states that the Request Body (in a Request
    Message) should always be aligned on an 8 octet boundary.

    My question is, in the above scenario, where the Request Body begins in
    the Fragment message, should the Request Body be aligned on an 8 octet
    boundary or not? I have not found anything in the specification that
    explicitly says what to do.

  • Reported: CORBA 3.0.2 — Wed, 1 Oct 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 GMT

page 1-20 second bullet of the description of the disconnect operation

  • Key: CORBA35-15
  • Legacy Issue Number: 5943
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    I found some minor editorial issues in the spec (referring to the document 02-06-65).

    • page 1-20 second bullet of the description of the disconnect operation. An 'and' is missing. This bullet should look like: "If the receptacle is a simplex receptacle and there is no current connection, then the NoConnection exception is raised."
  • Reported: CORBA 3.0.2 — Thu, 29 May 2003 04:00 GMT
  • Updated: Wed, 1 Feb 2023 21:58 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

Editorial corrections

  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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

Support alternative way of modeling single dimension CORBAArray

  • Key: CORP-10
  • Status: open  
  • Source: Airbus Group ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Mr. Oliver M. 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 ( Dr. 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 ( Mr. Oliver M. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Dr. 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: Adaptive ( Mr. 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 ( Dr. Daniel T. 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: Adaptive ( Mr. 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 ( Dr. 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 ( Dr. Daniel T. 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 ( Dr. Daniel T. 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 ( Dr. 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: Adaptive ( Mr. 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 ( Dr. Daniel T. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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 ( Dr. 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 ( Dr. Daniel T. 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: Adaptive ( Mr. 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 ( Dr. Daniel T. 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 ( Dr. Daniel T. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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 ( Dr. Daniel T. 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 ( Dr. Daniel T. 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 ( Dr. 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 ( Dr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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 ( Dr. Daniel T. 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 ( Dr. 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 ( Mr. 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 ( Mr. 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 ( Mr. 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 ( Mr. Oliver M. 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 ( Dr. 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 ( Dr. 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  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    after changing the fourth parameter of CadConnection::CadSystem::create_model from CadFeature::ParameterSeq to CosPropertySevice::Properties recently, the exception CadConnection::BadParameter does not match the method anymore.
    It should either be changed in a similar manner or kicked out completely (it is only used by create_model).

  • Reported: CAD 1.1 — Tue, 11 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

return value of CadFoundation::Entity::cad_model()

  • Key: CAD11-8
  • Legacy Issue Number: 5851
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    The return value of CadFoundation::Entity::cad_model() is Object. It would be clearer if it would return CadMain::Model (forward declaration).

  • Reported: CAD 1.0 — Wed, 29 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

method CadMain::Model::unique_ids_to_entities()

  • Key: CAD11-11
  • Legacy Issue Number: 5873
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    The method CadMain::Model::unique_ids_to_entities() can throw the CadMain::NotValidCadType exception but unlike the other methods able to throw this does not get TypeCodes as input. If the exception is there by accident I suggest it be removed.

  • Reported: CAD 1.1 — Thu, 27 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

description for CadMain::Model::unique_ids_to_entities() is missing

  • Key: CAD11-10
  • Legacy Issue Number: 5872
  • Status: open  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    In the PDF document for CADServices 1.1 (03-02-02) the description for CadMain::Model::unique_ids_to_entities() is missing

  • Reported: CAD 1.1 — Thu, 27 Feb 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Model creation parameters

  • Key: CAD11-5
  • Legacy Issue Number: 5843
  • Status: open  
  • Source: NASA ( Russ Claus)
  • Summary:

    Where can one get the CadFeature::Parameter instances from to use in CadSystem::create_model() ?
    As far as I know, the instance of a idl interface can only be created on the server (in a get method or in a factory) and I can see no way of creating empty CadFeature::Parameter instances.
    Besides, why was CadFeature::ParameterSeq used on Model level (CadMain::Model::create_model(), CadMain::Model::get_parameter_set()) and not as in other places CosProperyService::Properties? It is not clear to me, what information is supposed to be behind these parameters.

    This looks like a valid concern. We can fix this by using either CosProperyService::Properties in place of the CadFeature::ParameterSeq or we can created a CadFeature::ParameterFactory.

    I suggest the use of Properties.

  • Reported: CAD 1.1 — Tue, 21 Jan 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

File CadMain: Method add_child and remove_child

  • Key: CAD11-4
  • Legacy Issue Number: 5099
  • Status: open  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    File CadMain:

    1. Method add_child and remove_child from CadMain::Model should has
    CadMain::ModelInstance in parameter instead of CadMain::Model.

  • Reported: CAD 1.0 — Fri, 29 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

File CadGeometryExtens

  • Key: CAD11-1
  • Legacy Issue Number: 5096
  • Status: open  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    File CadGeometryExtens:

    1.
    struct SurfacePatchStruct

    { BoundedSurface parent_surface; TransitionCode u_transition; TransitionCode v_transition; boolean u_sense; boolean v_sense; }

    ;
    Should be
    struct SurfacePatchStruct

    { CadGeomerty::Surface parent_surface; TransitionCode u_transition; TransitionCode v_transition; boolean u_sense; boolean v_sense; }

    ;
    because parent_surface can be any type.

  • Reported: CAD 1.0 — Fri, 29 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

struct OffsetCurveStruct

  • Key: CAD11-3
  • Legacy Issue Number: 5098
  • Status: open  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    struct OffsetCurveStruct

    { double distance; CadUtility::VectorStruct ref_direction; boolean self_intersect; }

    ;
    Should contain also field CadGeometry::Curve BasisCurve.

  • Reported: CAD 1.0 — Fri, 29 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

struct HyperbolaStruct should be moved from CadSurface to CadCurve

  • Key: CAD11-2
  • Legacy Issue Number: 5097
  • Status: open  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    struct HyperbolaStruct

    { CadUtility::TransformationStruct location; double semi_axis; double semi_imag_axis; }

    ;
    Should be moved from module CadSurface to CadCurve, because it is used
    only by "curve"
    interfaces.

  • Reported: CAD 1.0 — Fri, 29 Mar 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 13.6 Server mapping

  • Key: CPP13-67
  • Legacy Issue Number: 11403
  • Status: open  
  • Source: Alcatel-Lucent ( Ou changhua)
  • Summary:

    Althrough I report my issue as a C++ issue, actually it is a common issue for other languages also. In current CORBA standard, a activated CORBA Servant object in the POA is shared by all the clients. But in many applications, a client connects to the server and calls some CORBA object methods to create a lot of connection related CORBA objects. Normally, the client will call "destroy" method of these CORBA object to destroy them before existing. But if the client exists abnormally, these created CORBA object will never be destroyed and never be used by any client. We can call this kind of CORBA object as "floating" CORBA object. The CORBA server application runs longer, the "floating" CORBA objects becomes more. And eventually, these "floating" CORBA objects will consume all the memory resources/CPU resources, then the CORBA server crashes and has to be restarted. The "floating" CORBA objects problem at the server side is not easy to be solved. For this problem, if the CORBA standard provides a method to solve it, the CORBA server will run more robust. Actually, the underlying network connection broken can be detected very effectively and rapidly. The CORBA server just simply ignores the network connection lost event and does not pass it to activated CORBA object even if the CORBA object is connection related object because current CORBA standard thinks that all the CORBA objects in the server are shared to all clients. If the server can notify the network connection lost event to the connection related CORBA objects, the developper can do the clean job on it. A simple method can solve the "floating" CORBA object problem. It is not required to add any new interface or data structure to current orb.idl. It is just required to add some new language mapping methods at server side only. I will give an example in C++ to show this simple method. A IShared,IConnSpec and IOtherConnectionSpec interfaces are defined below: interface IOtherConnectionSpec

    { ... }

    interface IConnectionSpec

    { IOtherConnectionSpec someMethod(); }

    interface IShared

    { IConnectionSpec createConnSpec( in string param ); }

    ; These interfaces will be used in this example. 1) the IShared will be shared by all the clients, it is activated like this: SharedImpl sharedImpl( ... ); ... sharedImpl._this(); 2) add new mapping method for the "POA_IShared::createConnSpec()" like this: IConnectionSpec_ptr POA_IShared::createConnSpec( char* param, const ConnectionContext& connCtx ); In this method, a parameter named ConnectionContext that represents the connection between the client and server is added. This method has a default implementation like this: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )

    { //just ignore the connCtx like the current CORBA standard defines return createConnSpec( param ); }

    3) If the user wants to create a connection related object, he/she must overload the "IConnectionSpec_ptr createConnSpec( char* param, const ConnectionContext& connCtx )" method and active the object with "this_( const ConnectionContext& connCtx )" method: IConnectionSpec_ptr POA_IShared::createConnSpec( const char* param, const ConnectionContext& connCtx )

    { ... IConnectionSpec *connSpecImpl = new IConnectionSpec( ... ); ... //use the connection related active method return connSpecImpl->this_( connCtx ); }

    in this method, the user uses the "this_( const ConnectionContext& connCtx)" method instead of the old "this()"" method to active the CORBA object. This activated CORBA object becomes a connection related object instead of shared object. Note: User can use the "this_( const ConnectionContext& connCtx)" method to active a shared object also. At this time, the ConnectionContext is a global variable "NO_CONNECTION_CONTEXT". 4) add a new mapping method named "getConnectionContext()" for every CORBA object. const ConnectionContext& IShared::getConnectionContext(); const ConnectionContext& POA_IConnectionSpec::getConnectionContext(); In this way, the IConnectionSpec can create and activate any other connection related CORBA object like this: IOtherConnectionSpec_ptr POA_IConnectionSpec::someMethod()

    { ... OtherConnectionSpecImpl *otherConnSpecImpl = new OtherConnectionSpecImpl(...); ... return otherConnSpecImpl->this_( getConnectionContext() ); //or ? //return otherConnSpecImpl->this_( this ); }

    5) add a new mapping method named "connectionLost()" for every CORBA object. When the network connection is lost, the CORBA server should find all the CORBA object associated with this network connection and call their "connectionLost()" method. The "connectionLost()" and its default implementation is listed below: void POA_IConnectionSpec::connectionLost()

    { //just delete this connection related object simply delete this; } void POA_IOtherConnectionSpec::connectionLost() { //just delete this connection related object simply delete this; }

    Because the SharedImpl object that created in the 1) step does not assicate with any connection, its "connectionLost()" method will not be called for ever.

  • Reported: CPP 1.1 — Fri, 14 Sep 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Concrete ValueType _init class problem

  • Key: CPP13-66
  • Legacy Issue Number: 6413
  • Status: open  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The second-to-last paragraph of section 1.17.10.3 says

    "For valuetypes that have no operations or initializers, a concrete type-specific factory class is generated whose implementation of the create_for_unmarshal function simply constructs an instance of the OBV_ class for the valuetype using new and the default constructor."

    As specified, that requires the generation of invalid C++. The OBV_ class is abstract since it does not have implementations of the ValueBase reference counting functions.

    Perhaps the intention is that the OBV_ classes in such cases should derive from DefaultValueRefCountBase. However, the wording and explanation in section 1.17.6 explicitly forbids this:

    "Note that it is the application-supplied concrete valuetype classes that must derive from these mix-in classes, not the valuetype classes generated by the IDL compiler."

    One solution that avoids the problem, and avoids restricting the application's use of the OBV_ classes is to generate yet another class that derives from both the OBV_ class and DefaultValueRefCountBase, for instantiation by the _init class's create_for_unmarshal function.

  • Reported: CPP 1.1 — Mon, 3 Nov 2003 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

_var's and valuetypes

  • Key: CPP13-63
  • Legacy Issue Number: 6163
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    1.9.1 says:

    "The copy constructor deep-copies any data pointed to by the T_var constructor
    parameter. This copy will be destroyed when the T_var is destroyed or when a new
    value is assigned to it. Compliant implementations may, but are not required to, utilize
    some form of reference counting to avoid such copies."

    and

    "The normal assignment operator deep-copies any data pointed to by the T_var
    assignment parameter. This copy will be destroyed when the T_var is destroyed or
    when a new value is assigned to it. Assigning a null pointer to a T_var is legal and
    results in deallocation of the data pointed to by the T_var."

    So my question is, is it legal to use ValueBase::_add_ref() and _remove_ref() instead of _copy_value() in this instance when T_var is representing a valuetype?

  • Reported: CPP 1.2 — Thu, 11 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

conversion algorithm not specified

  • Key: CPP13-62
  • Legacy Issue Number: 5466
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    C++ programmers will often want to use strings as
    object identifiers, the C++ mapping provides several conversion
    functions that convert strings to ObjectId and vice-versa:"

    The purpose is so the programmer can pick an arbitrary natural language
    string and use it as an ObjectId, not so that the programmer can
    generate a randomly unreadable string out of a binary ObjectId.
    [...] the C++ mapping provides several conversion functions
    that convert strings to ObjectId and viceversa:
    [...]
    If conversion of an ObjectId to a string would result in
    illegal characters in the string (such as a NUL), the first two
    functions throw the CORBA::BAD_PARAM exception.

    The conversion algorithm is not specified, and the ORB is free to
    choose whatever encoding it likes for its Object IDs. (Object IDs
    in stringified form need not be moved across address spaces (or,
    at least, not across ORB boundaries), so having a proprietary
    encoding is perfectly OK.)

  • Reported: CPP 1.1 — Fri, 19 Jul 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed and truncation/rounding?

  • Key: CPP13-58
  • Legacy Issue Number: 4533
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Suppose we have:

    typedef fixed<4,3> FT;

    interface I

    { FT op(); }

    ;

    Suppose the server does:

    FT
    I_impl::
    op() throw(CORBA::SystemException)

    { double d = 1.0/3.0; return CORBA::Fixed(d); }

    There are lots more digits in the return value than what is expected by the
    client. What should be returned to the client. The rounded value? The
    truncated value?

    Similarly, what if we have:

    double d = 10000000;
    return CORBA::Fixed(d);

    Do we return 9.999 to the client (which is the best we can do in this case)?

    Of course, it is the responsibility of the programmer to make sure that
    nonsense such as the second case doesn't happen. But the spec has to say
    what happens if it does happen

    Also, the first case will be very common – what should happen in this case?

  • Reported: CPP 1.1 — Thu, 23 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantBase needs _get_domain_managers()?

  • Key: CPP13-57
  • Legacy Issue Number: 4288
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Object::get_domain_managers() operation is a transmissible operation
    with CORBA 2.3. Does ServantBase need anything added to handle this or
    is this managed internally by the ORB/POA?

  • Reported: CPP 1.1 — Sun, 29 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence _var needs const operator []

  • Key: CPP13-65
  • Legacy Issue Number: 6276
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Footnote 11 on page 1-48 of the 1.1 version of the C++ language mapping states that sequence _var classes don't have a const version of "operator []". The justification in the footnote is incorrect.

    This footnote should be removed, and the operator provided, since it otherwise prevents accessing sequence members through a const reference to a sequence _var.

  • Reported: CPP 1.2 — Thu, 25 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

No portable way to create a OUT argument for a DII request

  • Key: CPP13-64
  • Legacy Issue Number: 6245
  • Status: open  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    Since the Any constructor from type code, void* value and boolean release flag has been eliminated, there is no longer any portable way to create an OUT argument for a DII request, without also assigning a value to it.

    I propose either a constructor from type code or changing the behavior of the type code set method to always succeed if the Any's TCKind is tk_null.

  • Reported: CPP 1.1 — Fri, 5 Sep 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Prohibit extracting from any into _out type?

  • Key: CPP13-61
  • Legacy Issue Number: 5440
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Just as we prohibited direct extraction from any any into a _var type
    due to the perils of memory management problems, we ought to prohibit
    extracting into _out types of variable sized structured types for the
    same reason

  • Reported: CPP 1.1 — Tue, 25 Jun 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add set of typedefs that would facilitate template programming

  • Key: CPP13-60
  • Legacy Issue Number: 4797
  • Status: open  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The addition amounts to a set of typedefs that would facilitate template
    programming, added to each C++ skeleton class created for an IDL interface,
    and analogous to the typedefs that already exist in the mapping for the stub
    side. Say we have an IDL file

    module foo
    {
    interface bar {};
    };

    Then in generated code we're talking about something like:

    namespace POA_foo
    {
    class bar

    { public: typedef foo::bar _stub_type; typedef foo::bar_ptr _stub_ptr_type; typedef foo::bar_var _stub_var_type; . . . }

    ;
    };

  • Reported: CPP 1.1 — Fri, 28 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

need unchecked narrow

  • Key: CPP13-70
  • Legacy Issue Number: 16892
  • Status: open  
  • Source: RTX ( Mr. Roy M. Bell)
  • Summary:

    need an _unchecked_narrow static operation that is similar to the _narrow. It will take in an object pointer but unlike _narrow will not check for compatibility before creating a new object reference.

  • Reported: CPP 1.2 — Mon, 12 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

valuetype example has errors

  • Key: CPP13-69
  • Legacy Issue Number: 16528
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In IDL it gives:

    // IDL
    valuetype V

    { factory create_bool(boolean b); factory create_(char c); factory create_(octet o); factory create_(short s, string p); ... }

    ;

    But it should be

    // IDL
    valuetype V

    { factory create_bool(boolean b); factory create_char(char c); factory create_octet(octet o); factory create_other(short s, string p); ... }

    ;

  • Reported: CPP 1.2 — Wed, 7 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

UTF-8 and IDL character types in C++

  • Key: CPP13-59
  • Legacy Issue Number: 4539
  • Status: open  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    implementing support for wchar/wstring I ran into some potential
    problems with the UTF-8 encoding for the IDL 'char' type.

    Lets suppose we have a C++ server with a native single-byte code set
    like ISO 8859-1.
    The Code Set Conversion specification states that UTF-8 is the fallback
    code set for 'char'.
    -> a client could decide to send characters in UTF-8 encoding.

    What happens on the server side with UTF-8 encoded characters that use
    more than 1 byte and thus don't fit into the single byte character as
    specified by the C++ mapping for IDL type 'char'?

  • Reported: CPP 1.1 — Wed, 29 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Describe operator != and == for all generated types

  • Key: CPP13-68
  • Legacy Issue Number: 14852
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the C++ mapping should explicitly list operator == and operator Unable to render embedded object: File (= in the examples and text. If it is not allowed to use ==/) not found.= the methods should be declared private

  • Reported: CPP 1.2 — Thu, 10 Dec 2009 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Optional parameters for _create_request?

  • Key: CPP13-53
  • Legacy Issue Number: 4150
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 1-119, the spec says the following about _create_request() and
    _create_request2():

    [...] the ORB requires:

    • a target object reference
    • an operation name
    • a list of arguments (optional)
      ^^^^^^^^^^
    • a place to put the result (optional)
      ^^^^^^^^^^
    • a place to put any returned exceptions
    • a Context (optional)
      ^^^^^^^^^^
    • a list of the user-defined exceptions that can be
      thrown (optional)
      ^^^^^^^^^^
    • a list of Context strings that must be sent with the
      operation (optional)
      ^^^^^^^^^^

    Note all the "optional" remarks.

    It's not clear what "optional" actually means. We have two cases for
    these parameters:

    • Arguments, user exceptions, and IDL contexts are sequences.
    • Result and context are object references.

    Two questions:

    • What does it mean for a sequence parameter to be "optional"?
      That I can pass a null pointer or that I can pass an empty
      sequence? I assume that an empty sequence is meant, but the spec
      doesn't say that.
    • What does it mean for a reference parameter to be "optional"?
      That I can pass a nil reference or that I must pass a reference
      to some dummy object that indicates that the value really isn't
      there?

    Where this is particularly annoying is for the return value. (The
    "result" parameter to _create_request()):

    • If I can pass a nil reference, no problem. This could
      be interpreted to mean the same thing as a void
      return type.
    • If I can't pass a nil reference, what should I pass?
      Obviously, it would have to be a reference to a valid
      NamedValue object. But how do I create that NamedValue
      object?

    I can call ORB::create_named_value(), but what should
    I do then?

    CORBA::NamedValue_var result;
    orb->create_named_value(result);

    At this point, I have a NamedValue containing an Any with
    tk_null (because that's what the Any default constructor
    creates). However, to correctly indicate that the operation
    I want to call has a void return type, I have to make a
    NamedValue that contains an Any with tk_void. But, how do
    I achieve that? I can't use one of the Any inserters to
    turn the TypeCode in the Any into tk_void, and I can't
    use the type() member of the Any because I can't change the
    type of an Any if it isn't consistent with the TypeCode that's
    already there...

    Even worse, the NamedValue doesn't seem to make sense as
    the return value at all. For one, it has a name attribute.

    • What is the value of that name for a return value?
    • How would I set that string after having create the NamedValue
      by calling create_named_value()?
    • What is the value of that string once I have called
      create_named_value()?

    Second, the NamedValue contains a flags attribute.

    • What is the value of that flags attribute for a return value?
      None of ARG_IN, ARG_INOUT, or ARG_OUT make sense. (One could
      argue that ARG_OUT could be used, but I think that sucks...)
    • How would I set that flag on the NamedValue I have just created?
      The mapping for NamedValue only offers accessor but no
      modifiers, so I can't set the value of the flag.
    • What is the value of the flag once I have called
      create_named_value()?

    It seems that the easiest way to fix the problem is to state that, if a
    parameter isn't needed, this is indicated by an empty sequence for lists,
    and by a nil reference for objects.

    However, the problems around create_named_value() and appear to be more
    serious. How should we fix those?

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB::destroy() missing

  • Key: CPP13-52
  • Legacy Issue Number: 4144
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The June 99 version of the C++ mapping doesn't mention ORB::destroy().
    It should.

  • Reported: CPP 1.1 — Thu, 11 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing two context lists to _create_request()

  • Key: CPP13-54
  • Legacy Issue Number: 4151
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The second version of _create_request() accepts two context lists:

    void Object::_create_request(
    Context_ptr ctx, // <===
    const char * operation,
    NVList_ptr arg_list,
    NamedValue_ptr result,
    ExceptionList_ptr,
    ContextList_ptr, // <===
    Request_out request,
    Flags req_flags
    );

    The spec then says:

    The ContextList differs from the Context in that the former supplies
    only the context strings whose values are to be looked up and sent
    with the request invocation (if applicable), while the latter
    is where those values are obtained.

    So, I think (but I'm not sure), this means to say that:

    • The Context parameter points at a tree of context objects.
    • The ContextList pointer points at an object that contains
      a sequence of strings.
    • The ContextList determines which context values are to be
      picked out of the tree pointed at by the Context parameter and
      to be sent with the invocation.

    If that is the intended interpretation, it's very difficult to discern
    from the words in the spec now. I think this needs clarification.

    Questions:

    • What happens if the ContextList contains the name of a context
      variable that isn't available in the context tree?
    • What happens if I have a non-empty context list but a nil
      context tree?

    Also, looking at the ContextList interface:

    pseudo interface ContextList

    { readonly attribute unsigned long count; void add(in string ctxt); string item(in unsigned long index) raises(Bounds); void remove(in unsigned long index) raises(Bounds); }

    ;

    There is no further documentation on this. Some questions:

    • As far as I can see, this interface is meant to maintain a
      simple sequence of strings. So, why not simply use a string
      sequence?
    • At what position does add() add the item? Presumably at the tail,
      but that isn't stated.
    • How can I replace the value of string at a certain position?
      It looks like I can't do that at all because there is no
      random-access modifier.

    This seems insanely complex.

    Suggestion: We should

    • add words to make it clear how the context parameters work
    • consider overloading _create_request() yet again to use
      an ordinary string sequence
    • deprecate the ContextList pseudo interface

    Or, we could drop support for IDL context altogether (but I suspect we
    can't get away with that

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::RequestSeq or CORBA::ORB::RequestSeq?

  • Key: CPP13-50
  • Legacy Issue Number: 4002
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    with 2.3, we got rid of all the C/C++ pseudo code for the DII and replaced
    it with IDL. Unfortunately, this has broken something in the C++ mapping...

    In the 2.0 spec, we had:

    pseudo interface ORB

    { typedef sequence<Request> RequestSeq; // ... }

    ;

    With 2.3, we changed this to:

    module CORBA

    { // ... typedef sequence<Request> RequestSeq; // ... }

    ;

    Unfortunately, the C++ mapping still shows the (now incorrect) definition
    from CORBA 2.0 in Section 1.33.1.

    In addition, the C++ mapping shows in Section 1.33.2:

    class ORB {
    public:
    class RequestSeq

    {...}

    ;
    // ...
    };

    But then, in Section 1.41.21:

    class ORB

    { public: typedef sequence<Request_ptr> RequestSeq; // ... }

    ;

    The latter definition isn't C++...

    So, we have several issues here:

    1) How can we fix the C++ mapping to be in line with the core?

    I'm toying with the idea of saying that RequestSeq is defined
    in the CORBA namespace, with a typedef for backward compatibility
    in the ORB interface. But I'm not sure what will break with
    this kind of aliasing (repository IDs might change unexpectedly?)

    2) Section 1.41.21 should be changed to show legal C++.

    3) Depending on the resolution to this issue, both 1.33.2 and
    1.41.21 will probably need updating to reflect the resolution.

  • Reported: CPP 1.1 — Fri, 27 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

_default_POA if no default ORB?

  • Key: CPP13-49
  • Legacy Issue Number: 3966
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    what should _default_POA() return if the default ORB was never initialized?
    The spec doesn't say...

  • Reported: CPP 1.1 — Tue, 17 Oct 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

questions to IDL - C++ mapping ( CORBA 2.3, valuebox)

  • Key: CPP13-51
  • Legacy Issue Number: 4119
  • Status: open  
  • Source: Fraunhofer FOKUS ( Dorota Witaszek)
  • Summary:

    I have the following questions to IDL - C++ mapping CORBA 2.3 (concerning valueboxes).
    Can somebody give me an answer?

    1. I assume that valueboxes T as a special kind of valuetypes also
    need in C++ the T_var and the T_out types and the T_out types will be
    used in function signatures for IDL out-parameters. Is it true?

    2. The mapping for strings and wstrings requires a definition of C++
    operators << and >> to allow a use of strings (wstrings) with the c++ iostreams.
    What about valueboxes of strings (wstrings) - chapter 1.17.7.4?
    Is it required to define (in C++) the operators <<, >> to use T_var and T_out
    with C++ iostreams, where T is a type for a valuebox T of string (wstring)?

  • Reported: CPP 1.1 — Tue, 14 Nov 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inserters/extractors for boxed strings?

  • Key: CPP13-56
  • Legacy Issue Number: 4199
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Given

    valuetype WStringValue wstring;

    is there any requirement to have stream inserters and extractors for the
    boxed value type itself? The spec is currently silent on this issue.

    Should the following work?

    WStringValue ws;
    cin >> ws;
    cout << ws;

  • Reported: CPP 1.1 — Mon, 12 Feb 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

publication of messaging / unchecked_narrow

  • Key: CPP13-55
  • Legacy Issue Number: 4157
  • Status: open  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Incorporate Messaging changes relevant to the C++ mapping, as shown in
    orbos/98-05-05 pages 115 and 116 together with any changes made to them
    by the Messaging RTF, into the IDL-C++ mapping chapter.

  • Reported: CPP 1.1 — Fri, 19 Jan 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting typedefs for _var types?

  • Key: CPP13-43
  • Legacy Issue Number: 3562
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    quite some time ago, we added the _var_type and _ptr_type definitions
    to proxies to make it easier to write templates. Similarly, we have
    the _whatever_seq typedefs for recursive structs and unions, to avoid
    problems with anonymous types.

    What's missing at the moment is a similar feature for _var types.
    When I'm writing a template that does it's job in terms of _var types,
    I also quite often want to do something to the underlying target type
    of the _var. However, I can't do that unless I pass in an extra template
    parameter (which, in turn, doesn't always work if I also want to use
    STL standard binders and such...)

    So, why not add a typedef for the target type to every _var type?

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Variable-length out params and exceptions

  • Key: CPP13-42
  • Legacy Issue Number: 3539
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec is currently not terribly clear about the server's responsibilities
    when throwing an exception from an operation that has a variable-length
    out param.

    The intent of the spec is that the server is responsible for deleting
    the memory it allocated to an out param before it throws an exception:

    // Correct implementation
    void
    Foo_impl::
    op(CORBA::String_out out_p) throw(CORBA::SystemException)

    { CORBA::String_var tmp = CORBA::string_dup("Hello"); bar(); // bar() may throw out_p = tmp._retn(); // No leak, even if bar() throws }

    // Incorrect implementation
    void
    Foo_impl::
    op(CORBA::String_out out_p) throw(CORBA::SystemException)

    { out_p = CORBA::string_dup("Hello"); bar(); // Leak if bar() throws }

    However, the spec never states this clearly. In fact, it sort of says
    the opposite. On page 1-110, table item 3:

    To maintain local/remote transparency, the caller must always
    release the returned storage, regardless of whether the callee
    is located in the same address space as the caller or is located
    in a different address space.

    There is no mention here of what should happen in the presence of exceptions.

    I think it would be nice to clarify that the skeleton will never look
    at an out param in the presence of exceptions and that the operation
    implementation is responsible for deallocating memory in this case.

  • Reported: CPP 1.1 — Tue, 11 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Read-only parameter remnants

  • Key: CPP13-41
  • Legacy Issue Number: 3538
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in the resolution to issue 863, we decided to get rid of the read-only
    restriction for parameters. However, we forgot to remove a few snippets.

    Page 1-110, table, case 3:

    Remove the following text:

    Following the completion of a request, the caller is not allowed
    to modify any values in the returned storage--to do so, the
    caller must first copy the returned instance into a new instance,
    then modify the new instance.

    Page 1-110, table, case 6:

    Remove the following text:

    Following completion of a request, the caller is not allowed
    to modify any values in the returned storage--to do so, the
    caller must first copy the returned array instance into a new
    array instance, then modify the new instance.

  • Reported: CPP 1.1 — Tue, 11 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence mapping & custom marshalling

  • Key: CPP13-40
  • Legacy Issue Number: 3537
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Section 1.17.11 of ptc/2000-01-02 says that DataInputStream &
    DataOutputStream are mapped according to the normal valuetype mappings.
    This mapping results in operations that are at best cumbersome to use in
    marshalling sequences of primitive types:

    Operations read_xxx_array and write_xxx_array are defined, taking argments
    of type CORBA::xxxSeq. These are obviously intended to be sufficient for
    marshalling all defined sequences of the corresponding primitive type xxx.

    However, the c++ mapping for sequences requires that each distinctly
    declared sequence type be unique and separately overloadable. This
    guarantees that a marshaller attempting to marshal an sequence of primitive
    other than CORBA::xxxSeq will not be able to pass that sequence to the
    corresponding read_xxx_array and write_xxx_array operations. Instead, code
    must be written to bypass strict typing.

    To fix this, either the mappings for DataInputStream and DataOutputStream
    need to be non-standard, the mapping of sequences needs to change, or the
    mapping of CORBA::xxxSeq needs to change to something special.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

set_servant and null servant

  • Key: CPP13-35
  • Legacy Issue Number: 3340
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the text for set_servant doesn't say what should happen if I call
    set_servant(0). I would suggest to throw BAD_PARAM in this case.

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ref counting ambiguous?

  • Key: CPP13-34
  • Legacy Issue Number: 3339
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For servant reference counting, the words "at least once" appear
    in a number of places when it comes to servant activation. set_servant(),
    activate_object(), activate_object_with_id(), servant_to_id(),
    servant_to_reference(), and _this() all use this language (pages 1-137 and
    1-138):

    ... will invoke _add_ref at least once on the Servant argument...

    Problem: suppose my ORB calls _add_ref() twice in each of these operations
    for some reason. I now have a problem. That's because, for servant
    activators, responsibility for calling _remove_ref() passes to
    etherialize(). However, if the ORB is permitted to call _add_ref() as
    many times as it likes, I have no idea how many times I have to call
    _remove_ref() from within etherealize(). I think that the spec should say
    that _add_ref() is called exactly once for these operations if the
    corresponding servant is not in the AOM already.

    I vaguely remember the discussion about optimization of the calls
    to _add_ref() and _remove_ref(). I think the idea was to permit the ORB
    to avoid redundant calls. However, it seems that the language in the spec
    isn't precise enough. Under one interpretation, the refcount counts
    the number of entries in the AOM. Under another interpretation, it counts
    the number of calls in progress as well (because an ORB could call _add_ref()
    when a call is dispatched and call _remove_ref() when it finishes).
    Under yet a third interpretation, the refcount counts the number of
    object references in my address space. That interpretation is happens
    if every call to _this() calls _add_ref()...

    The language is not precise enough, I think...

  • Reported: CPP 1.1 — Fri, 3 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Object Reference insertion/extration to Any

  • Key: CPP13-30
  • Legacy Issue Number: 3248
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    I believe the specification for insertion of object references to Anys is
    somewhat ambiguous. And, if it is intended to be as I think, it may also be
    less than ideal.

    Consider the following idl:

    interface B

    {...};
    interface D : B {...}

    ;

    And then consider the following code:

    D_ptr d; // initialize this to non-null value somehow
    B_ptr b = B::_narrow(d);
    Any ab;
    ab <<= b;
    Any ad;
    ad <<= d;
    // ...
    B_ptr b_val;
    if (ab>>=b_val)

    { /* do stuff with b_val */ }; // 1
    if (ad>>=b_val) { /* do stuff with b_val */ }

    ; // 2
    D_ptr d_val;
    if (ab>>=d_val)

    { /* do stuff with d_val */ }; // 3
    if (ad>>=d_val) { /* do stuff with d_val */ }

    ; // 4

    >From what I can see of the spec, it is a bit unclear about whether then
    insertion of an object should use the static type or the dynamic type of the
    object to initialize the typecode. Simplicity and consistency with other
    related operations suggests that it should use the static type. That is what
    we currently do, and a quick test of ORBIX 2000 seems to tell me it does it
    that way too.

    With that interpretation, 1&4 will work, while 2&3 will fail.
    Nobody should be surprised that 3 fails, but it is inconvenient
    that 2 doesn't work.

    If insertion used the dynamic type of its argument, then 1&2
    would work, while 3&4 would fail.

    To get reasonable behavior when derived types might be present,
    (and how often can you be certain they cannot?)
    it seems that one should almost never use type specific object
    extraction. Instead, one must do something like:

    Object_var o;
    B_var bv;
    if (ad>>=to_object(o._out()) &&
    !CORBA::is_nil(bv = B::_narrow(o)))

    { // do stuff with bv }

    ;

    This is unfortunately a bit inconvenient.

    So, is there any text in the spec that says, when inserting an object
    reference type into an any, if the repository id in the typecode should be
    the static type of the inserted argument or the dynamic type of the value of
    the argument?

    If not, I think we need to add some text.

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

DSI and implicit activation

  • Key: CPP13-39
  • Legacy Issue Number: 3532
  • Status: open  
  • Source: Anonymous
  • Summary:

    The C++ "Mapping of PortableServer Dynamic Implementation Routine" states
    that "If DynamicImplementation::_this() is invoked outside of the context
    of a request invocation on a target object being served by the DSI servant,
    it raises the PortableServer::WrongPolicy exception".

    This conflicts with the behaviour of _this() in static skeletons as de-
    fined in "Skeleton Operations".

    In particular, this means that DSI servants cannot be implicitly acti-
    vated, and therefore, the choice of DSI vs. static skeleton is not trans-
    parent to the application integrator.

    Is there any rationale behind this?

  • Reported: CPP 1.1 — Fri, 7 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

void * operations on Any?

  • Key: CPP13-38
  • Legacy Issue Number: 3401
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I seem to remember that we decided to deprecate the void * functions
    on type Any. However, looking at the latest C++ draft, they are not
    marked as deprecated.

    Can anyone remember what we decided to do? Is this a bug in the spec
    or a bug in my memory?

  • Reported: CPP 1.1 — Thu, 2 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetype "copying" semantics underspecified? (C++ issue # 1)

  • Key: CPP13-32
  • Legacy Issue Number: 3331
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    C++ issue #1: The C++ specification should state that valuetype
    parameters which are copied by the ORB for collocated invocations are
    done using an ORB internal mechanism, not _copy_value().

  • Reported: CPP 1.1 — Fri, 18 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueBase::_copy_value() function is underspecified

  • Key: CPP13-31
  • Legacy Issue Number: 3326
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ mapping is clear on what the use of
    ValueBase::_copy_value is, but is unclear as to who is responsible for
    providing an overriding definition of this pure virtual function. Is
    it the IDL compiler, generating an overriding _copy_value() function for
    each valuetype C++ class, or is the user, when he provides a valuetype
    implementation class?

  • Reported: CPP 1.1 — Wed, 16 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetype "copying" semantics underspecified? (C++ Issue # 2)

  • Key: CPP13-33
  • Legacy Issue Number: 3332
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    C++ issue #2: The ValueBase::_copy_value() function should be
    deprecated in favor of a new ValueBase::_clone_value() operation:

    // IDL
    module CORBA {
    abstract valuetype CloneContext { };
    };

    // C++
    namespace CORBA {
    ...
    class ValueBase

    { ... public: ValueBase *_clone_value(CloneContext *&); }

    ;
    ...
    };

    The _clone_value() function provides an independant copy of the
    valuetype it is invoked on. Any valuetypes reachable via the state of
    the original valuetype are also copied, and relationships between
    original valuetype(s) will be preserved in the cloned copies. The
    CloneContext argument provides the necessary state information for the
    ORB to properly maintain relationships between copied valuetypes. If
    _clone_value() is called with a null CloneContext, a new CloneContext
    will be generated and returned by the ORB as a result of the call.

  • Reported: CPP 1.1 — Fri, 18 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue with valuetypes & inout/out parameters

  • Key: CPP13-36
  • Legacy Issue Number: 3359
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ specification, section 1.22 states that valuetypes
    passed as in parameters to an invocation of an object are copied, even
    if the object is collocated with the caller. It does not make this
    statement for inout or out parameters (or return results), which
    strongly suggests that valuetype copying is not necessary. In fact, the
    text for valuetype inout parameters strongly suggests that copying is
    not performed.

    I think this is wrong and inout & out valuetypes should be copied as
    well (inout parameters should be copied before and after the invocation,
    while out and return values should be copied after the invocation
    completes.) Without the copies, call transparency will be broken and
    the client can distinguish between a local and a remote call.

  • Reported: CPP 1.1 — Thu, 24 Feb 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Constructor for structures?

  • Key: CPP13-37
  • Legacy Issue Number: 3380
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The mapping for user exceptions and structures is identical, except
    for one thing: user exceptions have an additional constructor with
    one parameter for each member, so I can construct and throw the exception
    with a single throw statement.

    However, structures are second-class citizens: I can't instantiate and
    initialize a structure at the same time. (Well, at least not in general,
    because static initialization only works for aggregates and, at any rate,
    I can only instantiate and initialize with compile-time constants.)

    So, why don't we add the same constructor to the mapping for structures?
    It seems inconsistent to have one mapping for structures and a slightly
    different one for exceptions, when in fact they both could be the same.

  • Reported: CPP 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Value Box Mapping

  • Key: CPP13-12
  • Legacy Issue Number: 2285
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This may be a naive question, but it seems like the C++ mapping
    for value boxes is incomplete. As far as I can tell, the specification
    defines the mapping for the following types:

    basic types, enum, objref, string, wstring, struct, union, sequence, array, fixed, any

    But what about the types that have not been mentioned?

    value, value box, TypeCode, Principal, native, except

    If these types aren"t allowed, does the specification say that somewhere?

  • Reported: CPP 1.0b1 — Wed, 23 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

portable includes

  • Key: CPP13-11
  • Legacy Issue Number: 2253
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We all know that the names of the C++ #include files generated from IDL are
    not standardized, and are thus the one remaining major source portability
    issue. One way to fix this would be to agree on some standard filenames,
    but we"ve tried this before and have never succeeded.

    Just thinking out loud here, but another way to fix it would be to agree on
    some standard macro names that applications could use to portably include
    the appropriate files. For example, define one macro for a client-side
    include and one macro for a server-side include, both taking the basename
    of the IDL file as an argument:

    #ifndef CORBA_CXX_CLIENT_INCLUDE
    #define CORBA_CXX_CLIENT_INCLUDE(base) <base ## Client.hh>
    #endif

    #ifndef CORBA_CXX_SERVER_INCLUDE
    #define CORBA_CXX_SERVER_INCLUDE(base) <base ## Server.hh>
    #endif

    Obviously, the exact definition of the macro would depend on the names of
    the generated files.

    I believe these could then be used portably in the client and server source
    code like this:

    #include CORBA_CXX_CLIENT_INCLUDE(file)

    With this approach, nobody has to change the names of the files they
    currently generate.

  • Reported: CPP 1.0b1 — Mon, 14 Dec 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Setting the TypeCode of an Any without setting a value

  • Key: CPP13-16
  • Legacy Issue Number: 2614
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following IDL:

    ----------------------------------------------------------------------
    // IDL
    typedef long MyArray[1000000];

    interface I

    { void set_array(in MyArray array); }

    ;
    ----------------------------------------------------------------------

    Now let"s assume that I want to implement this using the DSI:

    ----------------------------------------------------------------------
    // C++
    void
    I_impl::invoke(ServerRequest_ptr request) throw()
    {
    String_var name = request -> op_name();

    if(strcmp(name, "set_array") == 0)

    { NVList_ptr list; orb -> create_list(0, list); Any* any = list -> add(ARG_IN) -> value(); XXX request -> params(list); MyArray_forany arg; *any >>= arg; ... // Do something with arg; return; }

    else

    { NVList_ptr list; orb -> create_list(0, list); request -> params(list); Any* any = new Any; *any <<= new BAD_OPERATION(); request -> exception(any); }

    }
    ----------------------------------------------------------------------

    At the line I marked with XXX, I have to set the TypeCode of the
    Any.

  • Reported: CPP 1.0 — Tue, 20 Apr 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Value boxes and sensible value issue

  • Key: CPP13-15
  • Legacy Issue Number: 2497
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Value Boxes inherit from CORBA::ValueBase and
    must therefore implement get_value_def(), but
    cannot return a sensible value.

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ _var type widening proposal

  • Key: CPP13-3
  • Legacy Issue Number: 1418
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Michi Henning & Steve Vinoski have previously challenged people to come
    up with a modification to the C++ language mapping that would allow for
    type safe widening of object reference _var types for assignment or copy
    construction. I believe I have come up with the solution, and Michi
    agrees with me:

    Proposal:

    For object reference _var types, replace the copy and assignment
    operators:

    class T_var

    { public: ... T_var(const T_var &); T_var &operator = (const T_var &); ... }

    ;

    with:

    class T_var {
    public:
    ...
    template <class C_var>
    T_var(const C_var &cv) : ptr_(T::_duplicate(cv.in()) {
    }

    template <class C_var>
    T_var &operator = (const C_var &cv) {
    if ((void *)this != (void *)cv)

    { CORBA::release(ptr_); ptr_ = T::_duplicate(cv.in()); }

    return *this;
    }
    ...
    private:
    T_ptr ptr_;
    };

  • Reported: CPP 1.0b1 — Tue, 2 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

include files

  • Key: CPP13-2
  • Legacy Issue Number: 647
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be nothing in the spec that specifies the name of the include files for things in the CORBA module (e.g. type definitions). Add such a requirement to each language mapping

  • Reported: CPP 1.0b1 — Fri, 1 Aug 1997 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Is public _ptr member mandatory?

  • Key: CPP13-10
  • Legacy Issue Number: 2222
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In a number of places in the sample code for the C++ binding, the symbol
    _ptr is used as a member variable in _var types. In all of these the
    actual member is shown as private, so it is clear that actual
    implementations could use something else.

    The one exception to this is in section 20.10 on the Mapping for Struct
    Types. This discusses (without sample code) the mapping for string and
    object reference members of structs.

  • Reported: CPP 1.0b1 — Thu, 19 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need more info for custom marshalled value in C++

  • Key: CPP13-9
  • Legacy Issue Number: 2207
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The current C++ chapter for custom marshalled values on p. 20-94 lacks
    information about how one implements a custom value.
    The "Value Type Semantics" chapter in "ptc/98-10-06, 15 Oct. 98[REVIEW]"
    p. 5-11 says,
    " The implementer of a custom value type shall provide an
    implementation of the CustomMarshaller operations. The manner
    in which this [sic] done shall be specified for each language mapping..."

  • Reported: CPP 1.0b1 — Thu, 12 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Generic extraction of Fixed

  • Key: CPP13-8
  • Legacy Issue Number: 1984
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The C++ mapping does not permit extraction of a Fixed from an Any
    in a generic way – I must always specify matching digits and scale in
    order to call Any::to_fixed(). This is inconvenient if an application
    wants to deal with Fixed values generically (because Fixed is a generic
    type in C++ anyway).

    Proposal:

    Add an overloaded >>= operator for extraction of Fixed from an Any.
    The operator sets the Fixed value to whatever scale and digits
    are present in the type code.

    Cheers,

    Michi.

  • Reported: CPP 1.0b1 — Tue, 22 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraction of Fixed from Any

  • Key: CPP13-7
  • Legacy Issue Number: 1983
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The mapping right now offers Any::to_fixed to get a Fixed value out of an Any:

    to_fixed(Fixed &f, UShort d, UShort s);

    The spec doesn"t state what should happen if the digits and scale do
    not match what is in the type code. I believe extraction should fail in
    this case.

  • Reported: CPP 1.0b1 — Tue, 22 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

struct containing Fixed type

  • Key: CPP13-5
  • Legacy Issue Number: 1799
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.9, page 20-28 of orbos/98-07-12 describes what types are
    considered variable-length. Since the new Fixed class has non-trivial
    constructors, it should also be a considered a variable-length type. Note
    that any fixed-length struct containing one cannot be statically initialized.

  • Reported: CPP 1.0b1 — Tue, 11 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 7.3.6: PortableServer::ValueRefCountBase

  • Key: CPP13-4
  • Legacy Issue Number: 1659
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is no mention of PortableServer::ValueRefCountBase after this
    page. It is not clear why values that also implement interfaces
    do not use the same reference counting scheme as other values.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Valuetypes as operation arguments

  • Key: CPP13-13
  • Legacy Issue Number: 2306
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping document (98-09-03, p. 108) states that "... the callee
    shall receive a copy of each valuetype argument passed to it even if the
    caller and callee are collocated in the same process."

    In the collocated case, should the ORB invoke _copy_value() to produce
    the copy?

    Since the user could implement _copy_value() to return a nil value, it
    seems unlikely that the ORB could rely on this mechanism. However, a
    properly implemented _copy_value() would likely provide a significant
    speed improvement over marshalling and unmarshalling.

  • Reported: CPP 1.0b1 — Mon, 18 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Memory management of recursive value

  • Key: CPP13-14
  • Legacy Issue Number: 2309
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.21, "Argument Passing Considerations," says that for valuetypes:
    "The caller shall eventually invoked _remove_ref on the valuetype
    instance it receives back as either an inout, out, or return value."

    For memory management purposes, this is not sufficient in some cases.

  • Reported: CPP 1.0b1 — Wed, 20 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Extraction of strings from an Any

  • Key: CPP13-6
  • Legacy Issue Number: 1971
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What happens if I write

    CORBA::Any a = ...;
    const char *p;

    a >>= p;

    and the type code in the Any indicates a bounded string? Does the extraction
    succeed or fail? The mapping doesn"t say.

  • Reported: CPP 1.0b1 — Thu, 17 Sep 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

unclear semantics for valuetype insertion into Any

  • Key: CPP13-45
  • Legacy Issue Number: 3574
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The semantics for insertion of a valuetype into an Any are unclear.
    (Note, this is related to issue 2531 in the IDL-to-Java RTF.
    It is also related to orb_revision issue 3205.)

    In section 1.16.2 of ptc/2000-01-02, two forms of insertion are defined:
    copying and non-copying. The non-copying form is described as:

    "The noncopying valuetype insertion consumes the valuetype pointed to by the
    pointer that T** points to. After insertion, the caller may not access the
    valuetype instance pointed to by the pointer that T* points to. The caller
    maintains ownership of the storage for the pointed-to-T* itself."

    There is no specific description of the copying form specific to valuetypes,
    so the generic description must apply:

    "For the copying version of operator<<=, the lifetime of the value in the
    any is independent of the lifetime of the value passed to operator<<=. The
    implementation of the any may not store its value as a reference or pointer
    to the value passed to operator<<=."

    One possible interpretation (1) is that the copying form should be
    implemented via a call to the _copy_value virtual function, while the
    non-copying form should simply retain the provided pointer (without calling
    _add_ref) and eventually call _remove_ref when done with it.

    If so, what is the significance of the rule about the caller not continuing
    to use the pointer? It it only that it has lost a reference count, and may
    continue using the pointer if it has another reference count? Or does this
    imply that continued access to the value is forbidden regardless of
    reference count?

    Another possible interpretation (2) is that the description is nonsense, and
    that the non-copying form should use _add_ref and the copying form should
    use _copy_value. In this interpretation the caller would be free to continue
    using the original pointer and would be obligated to _remove_ref it
    eventually. This seems like a more practical interpretation, but is
    inconsistent with usage for other non-copying insertions.

    Suggested Resolution:

    Replace the paragraph on non-copying insertion of valuetypes (quoted above)
    with:

    "The noncopying valuetype insertion takes ownership of one reference count
    to the valuetype pointed to by the pointer that T** points to. After
    insertion, the caller should treat the pointer as if _remove_ref had been
    called on it. The caller maintains ownership of the storage for the
    pointed-to-T* itself."

    "For copying valuetype insertion, the lifetime of the value in the any is
    independent of the lifetime of the value provided. The implementation of the
    any shall duplicate the value using the virtual function _copy_value or an
    equivalent mechanism. The caller retains ownership of the T* pointer and
    remains obliged to call _remove_ref on it."

  • Reported: CPP 1.1 — Thu, 20 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any insertion for Boolean/Octet/Char

  • Key: CPP13-44
  • Legacy Issue Number: 3567
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The mapping is currently a bit ambiguous about the insertion/extraction
    operators for Any. It says:

    Assuming that boolean, char, and octet all map the C++ type
    unsigned char, the private and unimplemented operator<<= and
    operator>>= functions for unsigned char will cause a compile-time
    error if straight insertion or extraction of any of the
    boolean, char, or octet types is attempted.

    This is ambiguous. It is not clear what is qualified by the first part
    of the sentence "Assuming that...". It could qualify all of the paragraph,
    in which case the interpretation is:

    Only on platform where these three types indeed map to the same
    C++ type will it be necessary to have these unimplemented operators.

    // C++ Octet
    oct = 040;
    Any any;
    any <<= oct; // this line will not compile
    any <<= Any::from_octet(oct); // but this one will

    This is unambiguous, but it doesn't make it clear whether this will be
    the case for all mapping implementations, or only those where the
    IDL types map to ambiguous C++ types.

    It is important to note that the previous example is only one
    possible implementation for these helpers, not a mandated one.
    Other compliant implementations are possible, such as providing
    them via in-lined static any member functions if boolean, char,
    and octet are in fact mapped to distinct C++ types. All
    compliant C++ mapping implementations must provide these helpers,
    however, for purposes of portability.

    Again, this is slightly ambiguous because, even though it requires the
    presence of the helpers, it doesn't make any statement about whether the
    prohibition of the direct insertion operators is mandatory for all
    implementations.

    I would suggest to clarify the text to state that direct insertion/extraction
    of Bool, Octet, and Char must fail with a compile-time error, regardless
    of how these types are mapped.

  • Reported: CPP 1.1 — Tue, 18 Apr 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::Environment for EH compilers

  • Key: CPP13-47
  • Legacy Issue Number: 3616
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: Is it legal to do the following if I use a C++ mapping that
    uses C++ exceptions instead of using CORBA::Environment to
    handle errors?

    CORBA::Environment my_env;

    The spec says (page 114):

    The C++-PIDL specification differs from the C-PIDL specification
    as follows:
    [...]
    Supports a default constructor that initializes it to hold no
    exception information.

    However, the class definition that follows does not show the
    default constructor.

    So, the text disagrees with the class definition that is shown because
    "supports a default constructor" does not have a "may" or "might", so
    the text would appear to make the default constructor mandatory for
    both EH and non-EH mappings.

  • Reported: CPP 1.1 — Tue, 16 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

unspecified criterion for Any extraction

  • Key: CPP13-46
  • Legacy Issue Number: 3603
  • Status: open  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The C++ language mapping does not specify what criterion should be used to
    determine the validity of a typesafe extraction from an Any.

    The closest it ever comes is the statement in 1.16.3:
    "In this case, the version of operator>>= for type Long must be able to
    determine whether the Any truly does contain a value of type Long...".

    There are two obvious candidates: the equal and equivalent operations of
    TypeCode.

    Proposed resolution:

    Replace the first sentence of 1.16.3:

    "To allow type-safe retrieval of a value from
    an any, the mapping provides the following
    operators for each OMG IDL type T:"

    with:

    To allow type-safe retrieval of a value
    from an Any, the mapping provides an
    operator>>= for each OMG IDL type T.
    Each such operator returns a boolean
    indicating success or failure, and if
    successful, makes the value of the any
    available via a user supplied argument.
    The success of the operation is determined
    by applying the

    {equal | equivalent}
    operation to the typecode of the any and
    the typecode of the target type.

    The exact form of operator>>= varies
    according to the type T as follows:

    The choice of {equal | equivalent}

    needs to be discussed. I believe there
    are valid arguments for each.

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::release and CORBA::is_nil on POA_ptr

  • Key: CPP13-48
  • Legacy Issue Number: 3673
  • Status: open  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    I believe that the CORBA::release and CORBA::is_nil
    functions that take a POA_ptr argument do not
    reference the proper scope:

    1.41.11 release and is_nil
    // C++
    namespace CORBA

    { ... void release(POA_ptr); ... Boolean is_nil(POA_ptr); ... }

    Should be:

    1.41.11 release and is_nil
    // C++
    namespace CORBA

    { ... void release(PortableServer::POA_ptr); ... Boolean is_nil(PortableServer::POA_ptr); ... }

    I don't see in the specification where the scope
    of POA_ptr is explicitly defined. But, I believe
    that the correct definition of POA_ptr is in the
    PortableServer namespace (i.e. the enclosing scope
    of the POA class).

    Then again I can't find anything in the specification
    that asserts that any Foo_ptr type must go in the
    immediately enclosing class or namespace containing
    the Foo type. :-/

    Also, if POA_ptr is in PortableServer when an ORB is
    mapping of modules to classes the definition of the
    above release and is_nil functions in the CORBA class
    will be impossible.

    So I feel compelled to ask:

    Do we really need to have release and is_nil functions
    for types outside of the CORBA module?

  • Reported: CPP 1.1 — Wed, 7 Jun 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

fixed-length _var assignment from pointer

  • Key: CPP13-29
  • Legacy Issue Number: 3247
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the new mapping for _var types for fixed-length underlying types shows:

    T_var &operator=(T *t) {
    if (t != m_ptr)

    { delete m_ptr; m_ptr = t; }

    return *this;
    }

    This guards against self assignment when a pointer is assigned to the _var.

    I don't think this is right:

    • Assigning a pointer to a _var that already owns what the pointer
      points at is almost certainly an error:

    MyStruct * p = ...;
    MyStruct_var v = p; // OK

    // ...

    v = p; // Almost certainly an error

    • We don't do the same thing elsewhere. On page 1-13:

    A_var &operator=(const A_var& a)

    { reset(p); return *this; }

    This is inconsistent: assignment of a _ptr to a _var reference
    is not safe against self assignment, so assignment of a pointer
    to the _var for a fixed-length type shouldn't be either.

    Note that the other assignment operators are just fine – I'm only objecting
    to testing for self-assignment for operator= with a pointer as the RHS.
    (A nice compiler could even insert an assertions if a _var is assigned the
    same thing that it already points at.)

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UnknownUserException and stubs

  • Key: CPP13-28
  • Legacy Issue Number: 3246
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec currently says (page 1-101):

    Request invocations made through the DII may result in
    user-defined exceptions that cannot be fully represented
    in the calling program because the specific exception type
    was not known at compile-time. The mapping provides the
    UnknownUserException so that such exceptions can be represented
    in the calling process: [...]

    Here is a code snippet for the DII:

    req->invoke();
    if (req->env()->exception())

    { // Got an exception CORBA::Exception * ep = req->env()->exception(); // ... }

    The para on page 1-101, by implication, says that:

    • If there are concrete C++ types available in the caller that
      can represent the user exception, a real user exception is
      instantiated and the pointer returned by exception() points
      at the concrete user exception instance.
    • If there is no concrete C++ type available in the caller for
      a user exception, the pointer returned by exception() points
      at an instance of UnknownUserException.

    It's not as clearly spelled out as this, but it can be implied from the
    words on page 1-101.

    This is bad. For one, it implies "action at a distance". For example,
    linking the stubs for a user exception into a completely unrelated
    part of the same binary (possibly via a library) would change
    the behavior of the above DII call. Further, to make this behavior
    happen would require some form of global initialization data structure.
    In effect, there would have to be something that would let the ORB
    know (globally) for which user exceptions stub code is linked in.

    We rejected the need for global data recently in another context (for
    the proposed extraction operator for user exceptions). For the same reason,
    we should reject this here and mandate that, if I use the DII, all user
    exceptions are always returned as UnknownUserException.

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exceptions in servant constructors

  • Key: CPP13-22
  • Legacy Issue Number: 3150
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think we have a defect/omission in the C++ mapping with respect
    to exception safety. Consider a servant class with a constructor:

    class FooImpl : public virtual POA_Foo

    { public: FooImpl(); // ... }

    ;

    Consider what happens if FooImpl() throws an exception for some reason.
    By the time FooImpl() runs, the base class constructor POA_Foo() has run
    already. So, when the compiler deals with the exception, it invokes
    ~POA_Foo().

    The problem arises because, in our implementation at least, ~POA_Foo()
    checks if the reference count is zero and asserts if not.

  • Reported: CPP 1.0 — Mon, 20 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstract interface and DSI issue with C++

  • Key: CPP13-21
  • Legacy Issue Number: 3111
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There doens't appear to be any portable way to implement an object that
    inherits from an abstract interface using the DSI in C++ without compile
    time knowledge of the abstract interface. The basic problem is that I
    can create an object reference from a POA, but there is no way to
    convert the reference into an abstract interface reference so that I can
    send it out on the wire.

    We need some mechanism to coerce an object reference into an abstract
    interface reference (with a runtime check) to make this work.

  • Reported: CPP 1.0 — Fri, 10 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

_default_POA

  • Key: CPP13-19
  • Legacy Issue Number: 3055
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    what should _default_POA() return if no default ORB exists in the server
    (that is, ORB_init() with an empty ORB ID was never called)?

  • Reported: CPP 1.0 — Tue, 23 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueBase::_copy_value clarification

  • Key: CPP13-18
  • Legacy Issue Number: 2875
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The ValueBase::_copy_value() function is included in the discussion
    of the "reference counting interface" in section 1.17.5 of 99-07-41.
    Later, the description of the reference counting mix-in classes
    says:

    "Each of these classes shall be fully concrete and shall completely
    fulfill the ValueBase reference counting interface..."

    However, I do not believe that the intent was to require the mix-in
    classes to implement _copy_value().

    Therefore I suggest one of two clarifications:

    1) Move the discussion of _copy_value() out of the reference-counting
    section, or

    2) Specify which functions the mix-in classes are actually expected to
    implement, e.g.,

    "Each of these classes shall be fully concrete and shall completely
    fulfill the ValueBase reference counting interface (_add_ref,
    _remove_ref, and _refcount_value), ..."

  • Reported: CPP 1.0 — Thu, 9 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Construction of _var types

  • Key: CPP13-27
  • Legacy Issue Number: 3245
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec says (on page 1-23):

    The T* constructor creates a T_var that, when destroyed, will
    delete the storage pointed to by the T* parameter. The parameter
    to this constructor should never be a null pointer. Compliant
    implementations are not required to detect null pointers passed
    to this constructor.

    This seems broken for two reasons:

    • In an environment without real exceptions, null pointers must
      be returned for variable-length types in the presence of an
      exception. So if I write

    Foo_var fv(some_ref->op(my_corba_environment));

    and op() raises an exception (which will be returned in the
    environment), I'm hosed.

    • The assignment operator permits assignment of null, but the
      constructor doesn't. This is inconsistent, if nothing else.

    It seems that disallowing initialization from null pointer is some
    historical hangover? I think the restriction should be removed.

  • Reported: CPP 1.1 — Tue, 25 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ spec: Valuebase missing get_value_def

  • Key: CPP13-26
  • Legacy Issue Number: 3242
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In section 1.17.5, the C++ class for Valuebase does not show the
    get_value_def operation.

  • Reported: CPP 1.1 — Fri, 21 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ ValueBox & Fixed question

  • Key: CPP13-25
  • Legacy Issue Number: 3225
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.7.5 states: "Value boxes for these types [including Fixed]
    map to classes that have exactly the same public interfaces as the
    underlying boxed types...".

    Does this also include overloaded operators that are defined in the
    Fixed class?

    It sure seems weird to allow some operators to work but not others:

    // IDL
    valuetype FixedVal fixed<5,2>;

    // C++
    FixedVal *fv = ...;

    ++fv; // legal?

    CORBA::Fixed f = fv * 2; // illegal?

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problem with AbstractBase definition

  • Key: CPP13-20
  • Legacy Issue Number: 3074
  • Status: open  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In the CORBA 2.3 spec, section 6.2, CORBA::AbstractBase is defined as:

    module CORBA

    { native AbstractBase; }

    ;

    This implies that the C++ mapping for AbstractBase when used as a
    parameter is like this:

    class DataOutputStream

    { // from CORBA 2.3, section 5.5.2 void write_Abstract(AbstractBase value); }

    ;

    But section 1.18.1 of the CORBA 2.3 C++ mapping makes it clear that the
    signature should be:

    class DataOutputStream

    { // void write_Abstract(AbstractBase_ptr value); }

    ;

    Now I know that DataInputStream & DataOutputStream can be special cased
    to handle this, but if we need to add additional operations that use
    AbstractBase in the future, it would be nice if this could be fixed to
    behave consistently with the other native type mappings to C++.

  • Reported: CPP 1.0 — Thu, 2 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

IDL that is not IDL!

  • Key: CPP13-17
  • Legacy Issue Number: 2640
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping chapter contains many blocks of IDL like stuff
    with the comment

    // IDL

    in the first line, but the stuff in the block is not valid IDL for
    various reasons:

    Uses "pseudo" as an apparent keyword.

    (ii) Contains declarations like

    attribute exception exception;

    I suggest that the comment "// IDL" be replaced by "// Augmented IDL
    (see "Usage" on page x-y)" cross-referencing to section 20.23 Usage, so
    that people know for sure that this is not IDL.

    Furthermore, to make the claim in section 20.23 true, the declaration:

    attribute exception exception;

    should be fixed to be something else, or alternatively, the exceptional
    use of exception should be called out as a specific augmentation of IDL
    in section 20.23.

  • Reported: CPP 1.0 — Thu, 6 May 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

_out types and nested calls

  • Key: CPP13-23
  • Legacy Issue Number: 3161
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    consider:

    // IDL

    struct VariableStruct

    { ... }

    ;

    interface I

    { void foo(out VariableStruct s); void bar(out VariableStruct s); }

    ;

    Then:

    // C++
    void
    MyImplForI::foo(VariableStruct_out s)

    { bar(s); bar(s); // Leak here }

    void
    MyImplForI::bar(VariableStruct_out s)

    { s = new VariableStruct; }

    The freeing of memory for out params relies on the default conversion
    by the _out constructor from a pointer to the _out type which, as a
    side effect, frees the memory return by the previous call. However,
    in this case, and _out param is passed to another call, so the
    assignment operator runs, not the constructor:

    T_out& operator=(T* p)

    { ptr_ = p; return *this; }

    The assignment operator doesn't free the previous memory, so we get
    the leak.

    Should the assignment operator be changed?

  • Reported: CPP 1.0 — Wed, 22 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Any and UnknownUserException

  • Key: CPP13-24
  • Legacy Issue Number: 3217
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The mapping requires that it must be possible to insert CORBA::Exception
    into an any (section 1.19.2).

    Question: Is it possible to insert UnknownUserException into an Any?

    If the answer is yes, what are the members of UnknownUserException, what
    is its CDR representation, and what is its TypeCode?

    If the answer is no, we should clearly state this and specify what happens
    if I attempt to insert UnknownUserException into an Any.

  • Reported: CPP 1.1 — Thu, 13 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OpaqueValue needs to be documented in the C Language mapping

  • Key: C11-55
  • Legacy Issue Number: 5778
  • Status: open  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    OpaqueValue, a new native type introduced in Issue 2162 (void *
    in DII Chapter) for add_arg, was never documented in any of the language
    mappings. Language Mapping that claim that the DII interfaces map
    according to regular rules need to provide mapping rules for OpaqueValue
    and document it. The mapping would simply be OpaqueValue --> (void *) or
    equivalent.

  • Reported: C 1.1 — Wed, 27 Nov 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Order of structure members

  • Key: C11-54
  • Legacy Issue Number: 4341
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The C mapping says in section 1.9:

    OMG IDL structures map directly onto C structs. Note that all OMG
    IDL types that map to C structs may potentially include padding.

    This is not as clear as it should be. In particular, a requirement should
    be added to preserve the order of structure members as they appear in the
    IDL.

  • Reported: C 1.1 — Tue, 12 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bound seq buffer allocation

  • Key: C11-44
  • Legacy Issue Number: 334
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: What if user calls T_allocbuf for a bound sequence with a length that doesn"t match sequence constraint?Does this go undetected?. A related issue is issue # 108

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Seq buffer deallocation

  • Key: C11-43
  • Legacy Issue Number: 333
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Sequence buffers are allocated seperately from sequence which contain them, they can be released separately as well. Is this the job of the omnipotent CORBA_free?

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Mapping for Aliases

  • Key: C11-42
  • Legacy Issue Number: 331
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Mapping for IDL typedefs was dropped between CORBA 1.2 and 2.0. It should explicitly stated. Restoring text from 1.2 mapping is probably sufficient

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception id name

  • Key: C11-41
  • Legacy Issue Number: 329
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Loose specification of the #define generated for an exception id: Specification by example is never a good idea. The specification should be more explizit.

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence buffer release

  • Key: C11-38
  • Legacy Issue Number: 326
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate a Seq_releasebuf function for sequence Seq of type T to perform any buffer internal release. Function is called by Seq_freebuf prior to free buffer pointer acc. to release flag

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence buffer initialization

  • Key: C11-37
  • Legacy Issue Number: 325
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate a Seq_initbuf function to initialize a buffer for sequence Seq of type T. Seq__allocbuf allocates a buffer and calls seq_initbuf to initialize the allocated buffer

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allocation and initialization

  • Key: C11-34
  • Legacy Issue Number: 322
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate pairs of (T_init, T_alloc) functions for any type T (with descriptions described in issue # 309 concerning T_alloc)

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception initialization

  • Key: C11-33
  • Legacy Issue Number: 321
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define 2 functions, CORBA_exception_init and CORBA_systemException_init to initialize respectively user-defined exceptions and system exceptions to be raised

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Argument passing, cases 3 and 6

  • Key: C11-40
  • Legacy Issue Number: 328
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Table 22,p 14-20 of C mapping lists argument passing cases. In both cases(3+6) the value is either an out parameter or return value. How to handle CORBA_free as caller or callee

  • Reported: C 1.0b1 — Thu, 7 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception initialization and release

  • Key: C11-39
  • Legacy Issue Number: 327
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: generate pairs of (E_init, E_alloc) and (E_release, E_free) functions for exception E with behavior similar to the corresponding functions defined for any type T.

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence initialization

  • Key: C11-36
  • Legacy Issue Number: 324
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: State as undefined the behavior of a sequence as long as its Seq_init function (as specified in issue # 322) has not been called this function initializing the release flag.

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

De-allocation and release

  • Key: C11-35
  • Legacy Issue Number: 323
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate pairs of (T_release, T_free) functions for any type T T_release performs any internal memory release T_free calls T_release and frees the pointer argument

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

System Exception Type

  • Key: C11-32
  • Legacy Issue Number: 320
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define the type of system exceptions to be typedef definitions of a generic system exception type CORBA_SystemException

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

implementation hints not specification (Section 14.24.2 last para)

  • Key: C11-7
  • Legacy Issue Number: 172
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Para describes strategy an implementation will use for determining an exception TypeCode. Information not relevant to application developer. Mark as guidance to Implementor.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Parameter memory freeing problem (Section 14.24.1.para 6)

  • Key: C11-6
  • Legacy Issue Number: 171
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that all the parameter memory is freed as appropriate when DIR returns. Who frees memory? If DIR frees memory, then change the wording as appropriate.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C mapping for sequence (Section 14.11 CORBA 2.0)

  • Key: C11-11
  • Legacy Issue Number: 177
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section D.11 presents C mapping for sequence. For performance reasons, Sun prefers to embed the release flag in the sequence.

  • Reported: C 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

inconsistent parameter name and order

  • Key: C11-10
  • Legacy Issue Number: 176
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the definition of CORBA_ORB_init environment parameter comes last and it uses env instead of ev. Same inconsitency in CORBA_ORB_list_initial_services/CORBA_ORB_list_initial_references

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

vec10 and CORBA_sequence_long

  • Key: C11-15
  • Legacy Issue Number: 292
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: vec10 and CORBA_sequence_long: are these distinct types?Would they have distinct typecodes and distinct entries in the Interface Repository?

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Spec contains mutually inconsistent examples

  • Key: C11-14
  • Legacy Issue Number: 291
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Spec contains mutually inconsistent example (p 14-11 and 14-13. P 14-13 suggests that C structure MUST be named CORBA_sequence_long instead and must be enclosed in #ifdef...#endif

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

sequence as anonymous type in struct

  • Key: C11-18
  • Legacy Issue Number: 295
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When sequence occurs as anonymous (local) type in a struct,union,etc, how should this be treated?

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Declare and define Allocators for new sequence type

  • Key: C11-17
  • Legacy Issue Number: 294
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Are we supposed to declare and define allocators for new sequence Type? What is acceptable, required, forbidden (in terms of functions)?

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What happens when set_exception called more than once?

  • Key: C11-8
  • Legacy Issue Number: 174
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Sec 14.25.2: It"s not clear what happens if CORBA_BOA_set_exception is called more than once for a given object invocation. This should be specified.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C mapping for Any

  • Key: C11-13
  • Legacy Issue Number: 243
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section D.7 describes the mapping for CORBA_any. Sun would like to replace current C mapping for Any with opaque type, i.e conforming applications may not access members of CORBA_any struct

  • Reported: C 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Representation of "string" values in an "any"

  • Key: C11-12
  • Legacy Issue Number: 181
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In C mapping what is representation of "string" in _value field of an any? "char *" or "char **"? "char **" seems to be more applicable-usage requires an "_alloc" function

  • Reported: C 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Allocation Functions for sequences of "T"

  • Key: C11-16
  • Legacy Issue Number: 293
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The spec mentions 2 allocation functionsfor sequences of "T". These should better be inside the same (or similar) #ifdef...#endif as the struct typedef

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

confusing presentation (Section 14.25.4)

  • Key: C11-9
  • Legacy Issue Number: 175
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It refers to a "third case", but there are no cases described, and there are only 2 examples. What are the cases this paragraph refers to?

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Error in C language specification

  • Key: C11-53
  • Legacy Issue Number: 2307
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is very probably a small error in the C language specification.
    Below is what I wrote to the mailing list concerned with building the ORBit ORB. It
    was confirmed by one of the main coders behind ORBit.

    > This is something else, but I was more confused because the OMG "C language
    > mapping" spec at page 19-39 really seems to contain an error.
    > In that example, they also create an application specific servant structure called
    > AppServant, and they set the finalizer using
    >
    > AppServant my_servant = ...
    >
    > my_servant.epv._base_epv.finalize = my_finalizer_func;
    >
    > That should really have been (at least, that"s what I think):
    >
    > my_servant.base.vepv._base_epv.finalize = my_finalizer_func;
    >
    > I hope you agree with me there, or else I"m probably getting out of touch with C.

  • Reported: C 1.0b1 — Mon, 18 Jan 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistency in CORBA 2.0 C mapping

  • Key: C11-52
  • Legacy Issue Number: 636
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I currently implement a subset of CORBA 2.0. Not CORBA-compliant in terms of C-mapping for arguments to pseudo-objects and real objects. Give clear statement on argument order for real objects

  • Reported: C 1.0b1 — Tue, 29 Jul 1997 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Example inconsistent with table 20 and table 21

  • Key: C11-47
  • Legacy Issue Number: 462
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Example foo::bar on page 14-17 has fixed array out parameter. Mapping shown on this page doesn"t agree with tables 20 and 21.

  • Reported: C 1.0b1 — Wed, 11 Dec 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Seq buffer allocation

  • Key: C11-46
  • Legacy Issue Number: 336
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Sec 14.11 specifies generation of a buffer allocator for each sequence type of form T* sequence_T_allocbuf (CORBA_unsigned_long_len); very difficult to implement correctly.

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA_string is not defined

  • Key: C11-51
  • Legacy Issue Number: 620
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.28.1, 14.28.2, 14.29: CORBA_string is not defined anywhere in the code sample. These should be typedefed as CORBA_char * or char *

  • Reported: C 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

No defined value for CORBA_OBJECT_NIL

  • Key: C11-50
  • Legacy Issue Number: 606
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.3: Reference is made to CORBA_OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

  • Reported: C 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Delete 14.17 para 1

  • Key: C11-49
  • Legacy Issue Number: 486
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The first para of section 14.17 seems to have crept back after a deletion in a n earlier draft- it shouldn"t since it generalizes things (wrongly) which are properly described later

  • Reported: C 1.0b1 — Tue, 14 Jan 1997 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initial state of out parameter pointers

  • Key: C11-48
  • Legacy Issue Number: 485
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Spec. should be clear that the pointer passed in out parameters by caller should be uninitialized. This clarification should be in case (3) and (6) of Table 22

  • Reported: C 1.0b1 — Tue, 14 Jan 1997 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

release flag & returned data

  • Key: C11-45
  • Legacy Issue Number: 335
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Mapping should be explicit about how release flag interacts with inout, out, and return parameter. There probably is arelated C++ issue

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Pseudo-Object underspecification

  • Key: C11-4
  • Legacy Issue Number: 167
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Sect.14.23: Section indicates that ORBs may restrict the scope of legal operations on pseudo-objects. Minimal subset of operations should be defined so port. applications know what to rely on.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

C Language header question

  • Key: C11-3
  • Legacy Issue Number: 166
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.22: Al IDL compilers will generate a C language header. Does that mean that the C Language is required to be supported by all CORBA implementations?

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inappropriate information (Sect. 14.23. last paragraph

  • Key: C11-5
  • Legacy Issue Number: 169
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Information on implementation strategies for pseudo-objects is not relevant to application portability. It should be removed or appropriately annotated as guidance for ORB implementors.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inout sequence/any behavior with oversized return values

  • Key: C11-1
  • Legacy Issue Number: 111
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value specified?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong placement of asterics in table

  • Key: C11-2
  • Legacy Issue Number: 165
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.19: Asteriks in table are meant to indicate that item is a C Language pointer. They should not be subscribed.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

memory allocation functions

  • Key: C11-21
  • Legacy Issue Number: 309
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate T__alloc functions for any type T except interfaces: no function, any: CORBA_any_alloc string: CORBA_string_alloc

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

When MUST _buffer of sequence be allocated with _allocbuf

  • Key: C11-20
  • Legacy Issue Number: 297
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: When must this be done? always, whenever the release flag is TRUE, whenever the sequence elements contain secondary storage, whenever it is an out, inout, or return

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception release function

  • Key: C11-28
  • Legacy Issue Number: 316
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate a E_free function dual to Ealloc for exception E. /* C API / void E_free (E);

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception stringification

  • Key: C11-27
  • Legacy Issue Number: 315
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate string literal for exceptions as the stringification of the macro name e.g.for exception E: /*C code generation */ #define ex_E "ex_E"

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence buffer management

  • Key: C11-25
  • Legacy Issue Number: 313
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Generate a pair of (Seq_allocbuf, Seq_freebuf) functions, for sequence Seq of type T to manage resource of buffer sequences: Seqallocbuf and Seq_freebuf

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence behavior

  • Key: C11-24
  • Legacy Issue Number: 312
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The proposal is to state as undefined the behavior of a sequence as lon as its release flag has not been initialized

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Minor field of system exceptions

  • Key: C11-31
  • Legacy Issue Number: 319
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define the _minor field of system exceptions to be of type CORBA_ExceptionMinor

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Exception identification

  • Key: C11-30
  • Legacy Issue Number: 318
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Reserve the CORBA_exception_id function for user-defined exceptions only.

  • Reported: C 1.0b1 — Thu, 1 Jul 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Scoped sequence naming

  • Key: C11-26
  • Legacy Issue Number: 314
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Map sequence type names and sequence element type names enclosed within a scope according to the encoding scheme described as follows (/archives/issues/issue314)

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

memory release functions

  • Key: C11-22
  • Legacy Issue Number: 310
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Deprecate use of CORBA_free and generate T_free functions for any type T instead. Specification of T_free is current spec for CORBA_free suitable for type T

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping for sequences

  • Key: C11-23
  • Legacy Issue Number: 311
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Add release flag to generated C structure and map IDL sequence type from following definition (/archives/issues/issue311)

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA_Environment initialization

  • Key: C11-29
  • Legacy Issue Number: 317
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define a library function CORBA_Environment_init to initialize the non-opaque fields of CORBA_Environment (see file)

  • Reported: C 1.0b1 — Mon, 25 Nov 1996 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA_sequence_long

  • Key: C11-19
  • Legacy Issue Number: 296
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why is it not CORBA_sequence_CORBA_long? What is the precise rule by which these names are constructed?

  • Reported: C 1.0b1 — Tue, 22 Oct 1996 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Usage Context Binding Inappropriately Expressed

  • Key: CTS213-2
  • Legacy Issue Number: 18519
  • Status: open  
  • Source: Phast ( Ana Estelrich)
  • Summary:

    The Usage Context (in the PIM the applicableContext) is represented as an attribute of the ConceptDomainBinding class. applicableContext - a realm or context in which the particular binding applies. If not present, the binding applies in any context not stated in another binding.
    In the SFM it is represented as a class entirely apart providing detailed information about the binding. If we have two different value sets belonging to the same Concept Domain but with different usage contexts, this cannot work. Moreover, in most implementation guides, the Concept Domains are not specified, indicting just the Usage Context as Concept Domains are something very specific to HL7 (they can be inferred), and the Usage Contexts are expressed as OIDs and not as URIs (enforcing the fact that we need the possibility to simultaneously define an entity via an URI and an OID)

    Use Case:
    The value set epSOSActiveIngredient 1.3.6.1.4.1.12559.11.10.1.3.1.42.24 consists of the whole ATC and it is the most important piece of information in the medication identification in epSOS. The same value set is being used in 3 different documents in 4 different sections with 4 different entries:

    Prescription Item Entry 1.3.6.1.4.1.12559.11.10.1.3.1.3.2
    Dispensed Medicine Entry
    1.3.6.1.4.1.12559.11.10.1.3.1.3.3
    Medication Item Entry
    1.3.6.1.4.1.12559.11.10.1.3.1.3.4
    Allergy & Intolerance Concern Entry
    1.3.6.1.4.1.19376.1.5.3.1.4.5.3

    Prescription Section
    1.3.6.1.4.1.12559.11.10.1.3.1.2.1
    Dispensation Section
    1.3.6.1.4.1.12559.11.10.1.3.1.2.2
    Medication Summary Section 1.3.6.1.4.1.12559.11.10.1.3.1.2.3
    Allergies and Other Adverse Reactions Section
    1.3.6.1.4.1.19376.1.5.3.1.3.13

    In the follwing documents:
    ePrescription
    eDispensation
    Patient Summary
    Patient Summary

    The corresponding Concept Domain is EntityCode and the subdomain is ActiveIngredientDrugEntityType for all four Usage Contexts; however they are entirely different. Logged: https://github.com/cts2/cts2-specification/issues/146

  • Reported: CTS2 1.0 — Fri, 1 Mar 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Using enumerations instead of using code systems

  • Key: CTS213-3
  • Legacy Issue Number: 18518
  • Status: open  
  • Source: Phast ( Ana Estelrich)
  • Summary:

    The PIM uses enumeration rather than having a code system of its own. This does not allow for new codes to be added easily (need another enumeration), a separate documentation is needed for the definition of what the enumerations mean, and translations are not possible. Two such examples are the enumeration Resource Type with 7 possible values such as CODE_SYSTEM, CODE_SYSTEM_VERSION, CONCEPT_DOMAIN, MAP, MAP_VERSION, VALUE_SET, VALUE_SET_DEFINITION and the enumeration CHANGE TYPE with the enumerations: CREATE, UPDATE, METADATA, DELETE, CLONE, IMPORT. It would good terminology practice for the international specifications of terminology server to use an internal code system rather than use enumerations. Logged: https://github.com/cts2/cts2-specification/issues/145

  • Reported: CTS2 1.0 — Fri, 1 Mar 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: Documentation is incorrect in SpecificEntityList class

  • Key: CTS213-1
  • Legacy Issue Number: 18872
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    referencedEntity in SpecificEntityList is defined as "the namespace / name or URI of the entity to be included".

    It should read "the URI and optional namespace/name and description of the entity to be included".

    Logged: https://github.com/cts2/cts2-specification/issues/166

  • Reported: CTS2 1.1 — Tue, 13 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: ConceptDomain Binding has no property attribute

  • Key: CTS213-11
  • Legacy Issue Number: 18867
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    There is currently no way to extend a concept domain binding with tag/values. This prevents us from adding the HL7 codingStrength and effectiveDate attributes.

    We propose extending ConceptDomain Binding to support a property attribute.

    Logged: https://github.com/cts2/cts2-specification/issues/164

  • Reported: CTS2 1.1 — Mon, 12 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: Children/Descendants use inconsistent with Value Set

  • Key: CTS213-10
  • Legacy Issue Number: 18866
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The EntityDescription model provides hooks for children and descendants, the interpretation of which is left to the service. Value Set Definition, however, provides no equivalent ability where, instead, the associatedEntities have to provide the specific predicate.

    Would recommend making the predicate optional and, if present, describing the exact behavior that the service needs to exhibit.

    Logged: https://github.com/cts2/cts2-specification/issues/165

  • Reported: CTS2 1.1 — Mon, 12 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: SpecificEntityList description is incorrect

  • Key: CTS213-9
  • Legacy Issue Number: 18871
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The ValueSetDefinition SpecificEntityList states that "the service must include all entities in this list whether they are known to the service or not and whether they are ACTIVE or not".

    We do not believe that this is correct – the service still needs to validate this list when constructing a resolved value set and should NOT allow invalid or non-active entries to make it into a "valid" resolved value set.

    The SpecificEntityList description needs to be updated.

    Logged: https://github.com/cts2/cts2-specification/issues/167

  • Reported: CTS2 1.1 — Tue, 13 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: EntityDescription lacks workflow status entry

  • Key: CTS213-12
  • Legacy Issue Number: 18868
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    EntityDescriptionBase doesn't have a status element of type StatusReference. This prevents us from recording the organization's workflow status.

    We propose adding a status element to EntityDescriptionBase.

    Logged: https://github.com/cts2/cts2-specification/issues/163

  • Reported: CTS2 1.1 — Mon, 12 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: "readContext" missing on ResolvedValueSetResolution functions


AssociationQueryServices WSDL corrections

  • Key: CTS213-4
  • Legacy Issue Number: 17181
  • Status: open  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

    Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

    Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.

    In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression

    In method 'count' add parameter 'timeout'.

    In method 'getAllSourceAndTargetEntities' change the type of param 'directory' to EntityDirectoryURI

    In method 'restrict' change the type of param 'directory' to DirectoryURI

    In method 'restrictToTargetLiteral' change the type of param 'target' to String

    Logged: https://github.com/cts2/cts2-specification/issues/50

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: Wrong type in CompleteValueSetReference (ValueSetDefinition.xsd)

  • Key: CTS213-5
  • Legacy Issue Number: 18852
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    In ValueSetDefinition.xsd in the complex type CompleteValueSetReference, the type for valueSetDefinition is wrong:

    <xs:element name="valueSetDefinition" type="core:ValueSetReference" minOccurs="0" maxOccurs="1">

    The type should be core:ValueSetDefinitionReference.

    Logged: https://github.com/cts2/cts2-specification/issues/160

  • Reported: CTS2 1.1 — Tue, 6 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: ValueSetDefinitionListEntry in ValueSetDefinition.xsd has wrong cardinality

  • Key: CTS213-6
  • Legacy Issue Number: 18851
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The type ValueSetDefinitionListEntry in ValueSetDefinition.xsd contains an incorrect cardinality:

    <xs:element name="entry" type="ValueSetDefinition" minOccurs="0" maxOccurs="unbounded"/>

    It should contain one and only one entry:

    <xs:element name="entry" type="ValueSetDefinition"/>

  • Reported: CTS2 1.1 — Tue, 6 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

CTS2: ResourceList entries have double "entry" items

  • Key: CTS213-7
  • Legacy Issue Number: 18853
  • Status: open  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The resource List (example CodeSystemCatalogEntryList) specifies that the contents should be represented as
    <entry>
    <entry ...>
    <entry ...>
    </entry>

    This pattern is repeated across all lists.

    Logged: https://github.com/cts2/cts2-specification/issues/161

  • Reported: CTS2 1.1 — Tue, 6 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT