C Language Mapping Avatar
  1. OMG Specification

C Language Mapping — All Issues

  • Acronym: C
  • Issues Count: 2,426
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
CSRM11-3 Create examples of use of the profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-1 Icons for profile CSRM 1.0b1 CSRM 1.1b1 Resolved closed
CSRM11-2 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.1b1 Closed; Out Of Scope closed
CSRM11-4 Recommended Additions CSRM 1.0a1 CSRM 1.1b1 Closed; Out Of Scope closed
CPP1117-8 Incorrect constructor referenced in Fixed description CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-9 Typo CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-13 Missing annotation mapping CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-7 Missing description related to union member modifier CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-11 Change struct VariableExt constructor CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-10 Improve bitmask mapping CPP11 1.6b1 CPP11 1.7 Deferred closed
CPP1117-1 Add standardized annotation to override the IDL map to std::map mapping CPP11 1.7 CPP11 1.7 Deferred closed
CPP1117-2 Typo in example CPP11 1.7 CPP11 1.7 Closed; No Change closed
CPP1117-3 6.7.8 Argument Passing Considerations should refer to "Basic Data Types" not "primitive" CPP11 1.7 CPP11 1.7 Resolved closed
CPP1117-14 bit_bound CPP11 1.6b1 CPP11 1.7 Resolved closed
CPP1117-12 Add bit_bound/underlying_type for enum traits CPP11 1.6b1 CPP11 1.7 Duplicate or Merged closed
COMMONS11-8 Rename the new composites ontology to roles and compositions COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-4 Several OMG and external projects need a pattern for representing compositions COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-3 Need to add start and end time and explicit time period in Commons COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-1 Several OMG task forces have a need for a common ontology for quantities and units COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-5 Several OMG and external projects need a pattern for representing parties, the roles that they play and situations in which they are involved in COMMONS 1.0b2 $issue.fixedSpecification.name Resolved closed
COMMONS11-2 Need an ontology representing multidimensional arrays COMMONS 1.0b2 $issue.fixedSpecification.name Deferred closed
CSRM11-5 xmi profile CSRM 1.0b2 CSRM 1.1b1 Deferred closed
C2INAV12-1 Use @key instead of @Key C2INAV 1.0 C2INAV 1.2 Resolved closed
COMMONS-12 The properties in the collections ontology are confusing to users Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-11 Need to be able to indicate whether or not something can only be classified by a single classifier from a specific scheme Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-3 The format of the tables throughout the specification needs improvement Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-18 There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-16 Revise the abbreviation for the AboutCommons "make file Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-19 CodeSet should be a subclass of arrangement Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-14 Revise the version IRI for all of the Commons ontologies to agree for finalization purposes Commons 1.0a1 COMMONS 1.0 Closed; No Change closed
COMMONS-9 The constraint on a classifier that says it must classify something is too restrictive Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-2 The terms and definitions section of the Commons Ontology Library is incomplete Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-1 The use of rdfs:isDefinedBy is inconsistent in the annotation vocabulary Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-26 Revise the definition of designation to better align with the latest version of ISO 1087 Commons 1.0b1 COMMONS 1.0 Resolved closed
COMMONS-4 Some of the diagrams in Clause 8 are difficult to read Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-6 Some of the commons ontologies include double spaces in annotations Commons 1.0a1 COMMONS 1.0 Resolved closed
COMMONS-5 Examples are needed to help explain to Commons users how to use the ontologies Commons 1.0a1 COMMONS 1.0 Resolved closed
CORBA34-451 Ordering of user exception and return values CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-450 Standard uuid for interfaces (COM/CORBA Part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-453 CORBA section 11 struct PortableGroup::GroupInfo CORBAe 1.0b1 CORBA 3.4 Deferred closed
CORBA34-447 What should Automation View accept in bounded sequences? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-445 Section 4.1.12: DICORBA TypeCode::kind CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-446 Standard ProgramId CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-449 Section 4.1.18.5 enum should be named CORBA_CompletionStatus CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-448 VB cannot handle array out-parameters CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-443 Add CORBATCKind to end of enum list CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-442 Return value type of DICORBATypeCode::member_type should be changed CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-440 page 2-25 contradicts first sentence of 3rd full para on p 4-106 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-441 uuid for DForeignException has an extra 0 CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-444 Remove EX_repositoryID readonly property from IForeignException CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-435 boundary violations should cause View to propagate DISP_E_OVERFLOW CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-433 page 4-129, section 4.1.17: change term "CORBA proxy" CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-434 page 4-129, section 4.1.17.1: retval attribute CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-432 INSTANCE_Clone does not need an in-parameter CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-439 ODL is erroneous CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-438 Page 2-41, section 2.9.7.2 Add name for Automation View interface CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-437 page 2-30: There is a label "Examples", but no examples CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-436 page 4-109, section 4.1.5.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-425 "Safe" keyword identifier issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-426 Which TypeCode operations apply to Value and ValueBox? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-427 Section 5.5 Interface repository (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-424 Can Value type inherit from Value Box type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-429 Can value type inherit from Value Box type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-430 Automation View should generate HRESULT DISP_E_TYPEMISMATCH CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-428 Section 5.5 Interface repository (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-431 Dispatch versions of DCORBAObject and DORBObject CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-419 describe_value() operation issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-418 Missing member_kind and member_tc CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-421 p.6.68 boxed values of complex types map to same type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-423 New lexical type - Keyword Identifie CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-422 Section 5.3.3: can value inherit from a boxed value? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-420 Value type ansd Value Box"s single data member name CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-411 Semantics of computing the hash code.. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-410 Concrete value class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-412 Section 5.6.3 Hashing Algorythm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-414 Repository Id (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-415 Section 5.6.2 Repository Id CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-413 Repository Id (03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-417 Type code issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-416 Clarify the hash code algorithm CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-405 Section 7.3.10 Value Factories CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-407 Section 7 C++ Language mapping CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-406 Java mapping example and C++ mapping example CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-404 Why is ValueBase a value and not a native type? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-408 Section 7.3.6 Reference Counting Mix-in Classes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-409 Section 7.3.5 ValueBase and Reference Counting CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-398 p 5-50 2nd paragraph of 5.6.2.1 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-399 Editorial: p 5-50 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-400 Suggested changes (to section 5.4.1 of orbos/98-01-18) are CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-403 Can an instance of C be passed by value to an operation that expects an A? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-401 p 5-24, first paragraph of 5.3.1.3 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-402 Editorial page 8-107 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-395 Keyword identifiers (01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-397 Can public modifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-396 Reconcile RMI/IIOP upcall and helper class CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-391 No portable way to obtain list of type safe repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-393 Keyword Identifiers(03) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-392 Keyword identifiers (04) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-394 Keyword identifiers (02) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-384 OBV "chunking" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-387 "in". "out", and "inout" modifiers on value operation parameters CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-385 Can "public" mofifier be applied to value operations? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-386 Typo on page 8-107 of OBV specification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-388 Narrowing from abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-389 Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-390 Marshaling engine issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-379 OBV spec inefficient for dending large number of small objects CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-378 Some explicit semantics seem to be missing in section5.8.6 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-377 Forward declaration of value boxes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-376 TypeCodes for values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-380 OBV C++ problem with "supports" CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-382 TypeCodes defined in section 5.8.2 CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-381 ValueMemberSeq: What is to be done with the RepositoryID parameter? CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-383 CDR Streams CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-370 P 5-44: use of base type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-371 OBV TypeCode parameters wrong CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-368 No typecodes for abstract interfaces CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-369 Abstract Interface issue (write_Abstract/read_Abstract)(01) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-373 Custom marshalling support for IDL fixed type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-374 Default constructor for Java values CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-372 C++ boxed value member clashes CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-375 Boxed values need extension to write_Value call CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-363 Status of hashed repository IDs CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-362 "Tool" issue for IDL compilers too complex CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-361 ValueHelper Interface issue CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-367 TypeCode complexity for value types CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-366 Memory Management for Value Factories Unspecified CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-364 OBV init CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-365 CodeBase interface uses undefined type CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-353 Issue for Firewall RTF - HTTP tunnelling. CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-351 Section number: 3.3.4 and elsewhere CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-352 Title does not cover the use of SS7 as signaling transpor CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-355 passthrough connection CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-354 issue with TCPfirewallMechanism CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-356 Issue for Firewall RTF - Chapter 5 needs clarification CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-357 The values of these tags need to be assigned CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-360 Minimum CORBA and POA CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-345 Section number: 4.2.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-349 Sec.: 3.5.1.1, item 4 plus appropriate section of interaction translation CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-348 Section number: 3.5.1.1, item 3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-347 How can we bound the range of invoke ids in the IDL? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-346 It should be possible to have negative invoke ids CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-350 Section number: 3.3.4 make factory creation operations conform to the IDL CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-341 Section 4.3.2.1 Title and text should be changed CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-340 Section 4.7.1: RelativeRoundTripPolicy CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-344 Problem: Why is AssociationId a string? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-342 There is a difference between the responder and initiator interfaces CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-343 The current text for DialogFlowCtr is for outgoing only CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-337 Section number: 5.4.1 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-336 Shouldn’t it be typedef string CORBA::ScopedName? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-335 Section number: Fig. 27 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-339 Shouldn’t this section really be called TC Service Interface? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-338 Section number: 5.2 and other sub-sections CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-328 Bi-Directional GIOP: which connections may be used? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-329 Section number: 2.3 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-333 Should SIOP version number start with 1.2? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-331 Problem: There is no way to send dialogue data in a continue confirm. CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-332 Section number: 6.2.2 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-330 Section number: 5 CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-334 Could SIOP be changed to 7IOP, pronounced "seven-up"? CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-325 Firewall POA Policy does not control access CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-323 new_target CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-322 new_callback CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-324 Firewall Traversal algorithm CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-327 Bi-Directional GIOP: Masquerade security issue needs to be more explicit CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-326 Outgoing local port in Bi-directional IIOP CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-320 Proxified object references CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-318 Clarification is needed on the passing of credentials CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-319 Reusing PASSTHRU CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-321 How to obtain initial reference to the GIOPProxy object CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-311 TcPdu User and Provider interfaces CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-313 Why one to one association between a TcPduUser and TcPduProvider interface? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-312 Specification Translation from ASN to IDL issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-316 Traversal algorithm not sufficient CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-317 Problems with routing and/or traversal of firewalls. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-314 When does a multiassociation TcUse know that it has been finished with? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-315 Use of InvokeId as the type name for both invoke id and link id. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-305 BiDir GIOP Policy Clarification CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-306 Use of PolicyType id CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-309 Allow GIOP 1.3 messages to be transported. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-307 Missing definition on security tags in the SIOP CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-308 There is currently no valuetype support in SIOP. CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-310 use of the SSN number in the 1988 TCAP version CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-299 Discrepancy in the changes proposed to CSIIOP and CSI modules CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-298 GIOP version 2.0 issue CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-300 Bidirectional Policy insufficient for persistent objects CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-301 Server Authentication CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-304 MAIN_THREAD_MODEL questions CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-303 Negotiate Session Message Orientation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-302 Negotiation Session message is unwieldy CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-290 Implications about BiDirIds CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-291 paragraph limits use of BiDirOfferContext CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-292 Negotiate Session Message Issues CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-293 CodeSet issue (05) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-296 CodeSet issue (02) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-295 CodeSet issue (03) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-297 CodeSet issue (01) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-294 CodeSet issue (04) CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-284 What BiDirIds shall be sent over what bidirectional connections? CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-285 Interplay of Contexts allowed in NegotiateSession messages too ill-defined CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-283 Firewall FTF Issue: No ene-to-end security for firewall traversal CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-286 Firewall Issue: Random BiDirIds can't be used for persistent POAs CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-287 Firewall Issue: Connection over which BiDir offers are sent is unspecified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-288 Firewall Issue: Response to failed BiDir challenge is unclear CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-289 Firewall issue - Number of BiDirIds in a BiDirOffer CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-275 use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-277 Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-276 Bi-directional connections considered volatile at connection acceptor side CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-279 connection_complete field of the FirewallPathRespContext is under specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-278 How many BI_DIR_GIOP_OFFER service contexts are allowed CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-281 Targets of Export and Offer Policies incompletely specified CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-280 Expected behavior of a non-conformant implementation CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-282 Processing of NegotiateSession messages at various stages of connection set CORBA 2.5 CORBA 3.4 Deferred closed
CORBA34-269 Multiple objects on a stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-270 Definition of stream portability CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-273 Lifecycle Key type definition CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-272 Stream contexts and internalization CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-271 Start and end of context tags CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-274 when is a connection a "bi-directional connection"? UML 2.0 CORBA 3.4 Deferred closed
CORBA34-264 Coordinator remembering LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-263 Input values for "which" arg of non-trans. LockCoordinator CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-265 Freeing of locks at the end of a transaction CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-266 Getting the thread ID in a non-transactional lock request CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-267 Communication failure issue CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-268 Timeout while locking CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-255 CosCompoundExternalization Service CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-256 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-257 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-260 CosGraphs::deep CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-261 Common format on stream CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-259 performing a compound copy of relationship CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-258 $issue.summary CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-262 Using local thread identification for concurrency CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-249 Internalizing roles-IDL optimization CORBA 2.1 CORBA 3.4 Deferred closed
CORBA34-250 Who is responsible for releasing locks in transaction? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-252 Purpose of related LockSet CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-253 CosCompoundExternalization Service (3) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-251 Which model should ConcurrencyControl support? CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-254 CosCompoundExternalization Service (2) CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-244 QueryCollection::Collection -- finding index CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-245 Query Collection::Collection -- Sharing State CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-248 Circular References in CosStream and CosCompoundExternalization CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-247 QueryCollection::Collection -- membership scoping CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-246 QueryCollection::Collection -- Adding multiple elements CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-237 Questions on CosQuery::QueryableCollection interfaces CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-240 QueryCollection::Collection -- reset() exceptions CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-238 QueryCollection::Collection -- keyed collections CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-239 QueryCollection::Collection -- next_n() CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-241 QueryCollection::Collection -- destroy methods CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-243 QueryCollection::Collection -- Iterator Position Invalid CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-242 QueryCollection::Collection -- iterator updating CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-229 Query language for operations CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-232 Definition of NULL in datafiles without NULL as a concept CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-230 Delegating iterator functionality to the RDBMS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-233 Clarification request for section 11.1.5 CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-231 retrieve_element CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-234 How do iterators handle changing of the data they are pointing at CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-236 Use of MD5 on arguments CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-235 Updating information via query iterators CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-221 Inconsisten IDL in the Minimum CORBA chapter CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-223 TypedConsumerAdmin interface (4.9.2)) CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-222 Correction of CORBA specification (page 18-51) CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-224 WWW Form output CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-227 interface QueryEvaluator { CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-225 Malformed PropertyName CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-228 OQS relation to POS CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-215 COM/CORBA keywords CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-220 CosExternaliazation Service (bug?) CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-218 ObjectCreationError and Nofactory exceptions in Externilazition CORBA 2.2 CORBA 3.4 Deferred closed
CORBA34-219 CosConsurrencyControl service bug or not? CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-216 Compiler being able to translate from OMG-IDL into ANSI CORBA 1.2 CORBA 3.4 Deferred closed
CORBA34-213 Unclear and possibly harmful consequences of mandatory annotation definitions CORBA 3.1.1 CORBA 3.4 Deferred closed
CORBA34-212 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-214 Fixed Types in COM CORBA 2.4.2 CORBA 3.4 Deferred closed
CORBA34-207 How does DynValue handle derived valuetypes? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-205 Spec doesn't make clear what is valid mix of policies and what is invalid CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-206 messaging router issue CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-211 valuetypes and local interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-210 Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-209 CORBA 3.02, page 11-25, section 11.3.6 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-208 module SendingContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-199 rules for marshalling ValueBoxes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-198 BNF changes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-200 Problem with ServerRequestInterceptor::receive_request and DSI CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-201 restriction of where a valuetype chunk can end CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-202 Bad text in 22.6 mandates Routing for sendc/sendp CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-203 What is the RSC when using a PersistentPoller CORBA 3.0.1 CORBA 3.4 Deferred closed
CORBA34-204 Messaging Routing Protocol is broken for GIOP 1.0 & 1.1 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-195 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-194 methods on the POA CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-193 Add a typedef for the POAManager id CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-196 An extension of IOR to protect target objects Nature CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-197 Mapping from -ORBxxx to Java properties does not work for -ORBInitRef CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-189 The POA state inactive is not used consistent. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-188 CORBA 3.0.3 ch. 3.4 OMG IDL Grammar CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-191 argument of the set_servant call has a small typo CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-187 Section: 4.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-192 change in the POAManager CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-180 Issue: CSIv2 Identity Assertion CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-181 Polymorphic Valuetypes and the DII CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-182 DynValue & custom valuetypes CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-185 Code Set Conversion on Operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-184 Potential deadlock with POA::deactivate_object() CORBA 2.3 CORBA 3.4 Deferred closed
CORBA34-183 Custom Value Marshaling Issue CORBA 2.3.1 CORBA 3.4 Deferred closed
CORBA34-186 Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-174 ForwardRequest is impossible to detect in clients CORBA 2.6.1 CORBA 3.4 Deferred closed
CORBA34-177 Avoiding RSC/TSC copy on server side CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-178 Implications of any/valuetype marshalling CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-176 Proposal for extension to CosNaming CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-175 New issue: ForwardRequest() CORBA 2.6 CORBA 3.4 Deferred closed
CORBA34-179 How does an ORB implement Object::get_policy for PI defined policies? CORBA 2.4.1 CORBA 3.4 Deferred closed
CORBA34-170 rule (85) is misplaced CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-173 processing TaggedComponents within an IOR CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-171 Bad quotes and imported dot CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-172 missing document title CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-162 Section: 4.8.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-163 move struct to IOP module CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-164 Add create_policy with just the type as argument CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-165 context should be local interface CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-169 Make anonymous types illegal CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-166 Redundant bullet CORBA 3.2 CORBA 3.4 Deferred closed
CORBA34-168 interface ORB should be local CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-156 There is lack of multiplex publisher port that would mimic functionality of multiplex receptacle CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-155 Section: 21.3.13 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-157 16.10 lists register_initial_reference CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-161 Section: 21.7.3 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-159 add CORBA::ORB::arg_list CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-158 add interface ORB { Object string_to_object ( in wstring str ); }; CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-160 Section 13.7 ServiceContext CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-147 Section: Part 2, Chapter 11 - MIOP CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-149 definition of Invalid Policies changed CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-148 mention of (deprecated) function get_implementation removed from text CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-152 Proposal to change PortableInterceptor::ReplyStatus to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-151 Proposal to change PortableInterceptor::AdapterState to a real enum CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-153 Section: 15.4.2/16.4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-150 Third line of 23.1.3.4, ACTIVE must be bold CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-154 Section: 13.6.10.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-142 Missing PolicyValue encoding instructions ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-143 Invalid IDL (2) ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-145 Two typo's in Annex A.4 CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-144 Invalid IDL ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-146 struct PolicyValue CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-137 Section: 7.4 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-140 Moving *Seq typedefs into ORB chapter CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-139 Minor code ambiguity CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-141 Missing size information for decompress() ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-138 Typo in sections 22.10.1.1 and 22.10.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-132 Section: 21.7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-133 update the spec to not used anonymous types CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-131 Section: 21.9.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-130 Section: 21.4.3.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-134 Section: 4.2 (02) CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-135 Section: 4.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-136 Section: 13.6.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-124 FullInterfaceDescription and base_interfaces question CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-121 Allowing mutual recursion for IDL structs - clarification needed CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-122 CORBA Exceptions CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-123 Section: 11.3.9.16 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-129 Section: 11.3.9 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-128 Section: 22.16/ CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-126 Page: 21-43 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-127 Section: 22.11.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-115 Page: 7-7 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-116 Page: 9-1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-117 Page: 21-5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-119 Section: 21.3.14.11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-120 Section: 4.5.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-118 Section: Appendix A CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-110 69.8.2.8 The simple Element, page 69-538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-111 Section: Chapter 9, Chapter 5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-112 Section: Chapter 11 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-113 Allowing Mutual Recursion for IDL Structures CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-114 NVList Section: 7.5 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-103 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-104 69.3 Software Package Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-105 Add the capability to define a component artifact property CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-107 69.8.2.9 The sequence Element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-106 Test Property - add a test property definition to the properties DTD CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-108 69.8.2.3 The choices Element, page 69-537 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-109 69.8.2.7 The range Element, pages 69-537/538 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-96 Component Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-95 LWCCM issue - Section 1.5.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-100 69.3.2.25 The propertyfile Element, page 69-482 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-97 69.3.2.2 The author Element, page 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-99 69.3.2.14 The idl Element, page 69-478 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-98 Descriptor CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-102 69.8.2.7 The code Element, pages 69-474 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-101 69.3.2.15 The implementation Element, pages 69-478/479 CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-89 lwCCM issues - abstract storage type CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-91 lwCCM issues - entity components CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-92 lwCCM issues - persistence CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-90 lwCCM issues - section 4.1.2 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-94 lwCCM issues - transaction CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-93 lwCCM issues - security CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-88 lwCCM issues - abstract storage home CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-87 lwCCM issues - CIDL CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-86 lwCCM issues - locator CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-85 lwCCM issues - segmentation CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-79 lwCCM issues - home finders and finder operations CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-80 lwCCM issues - proxy homes CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-78 lwCCM issues - invalid rows CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-83 lwCCM issues - primary key CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-84 lwCCM issues - get_all_facet, ... CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-82 lwCCM issues - Section 4.1 CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-81 lwCCM issues - configurators CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-71 Checking XML DTD elements related to the trader service CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-72 Description for the impltype Element? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-74 Uses Relationships CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-73 69.3 AssemblyFactory Interface CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-75 Device Artifact Dependency CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-76 Dependency on D+C FTF CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-77 lwCCM issues - Entity2Context CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-68 A new exception specification is needed for CCM2Context::req_passivate() CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-65 CCM IDL style inconsistency CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-66 Derived component supported interface restriction (formal/2002-06-65) CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-67 Issue on the description of the consumesidentifier element CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-70 Using Configurator on CCMHome or any CORBA objects? CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-69 [CCM] Interface Repository Metamodel CORBA 3.0 CORBA 3.4 Deferred closed
CORBA34-59 Section 6.4.5.26 and Section 6.4.5.30 should be moved to section 6.3 CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-60 Section 6.4.5.10 (page 6-26) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-62 CCM spec: insufficient examples of component attributes CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-64 multiple lifetime policies declaration issue CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-63 3.2.7 Compositions with Managed Storage CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-61 Section 6.4.5.52 (page 6-38) CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-56 'local executor mapping' CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-55 portability of CCM descriptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-54 EnterpriseComponent should have a get_servant method CCM 3.0 CORBA 3.4 Deferred closed
CORBA34-58 issue on component supporting abstract interfaces CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-57 CCM Spec: attributes are listed in the ports section? CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-48 EnterpriseComponent should have a set_persistent_object method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-47 HomeExecutorBase should have a set_context method CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-49 Generic connectivity for Receptacles, Emitters, Publishers CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-50 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-51 EnterpriseComponent should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-52 The association of entity component primary key and PSS key is unclear CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-53 HomeExecutorBase should have a get_servant method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-44 Contradictory sections in the CCM and Lightweight CCM specifications CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-41 spec should define how the base class of an executor is generated by the framework ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-43 The D&C IDL part doesn't match 06-04-02. CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-42 add a sequence of CCMHome typedef sequence CCMHomes; CORBA 3.1 CORBA 3.4 Deferred closed
CORBA34-46 add some feature to let an assembly look like a monolithic compoment CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-45 "supports" keyword CORBA 3.0.3 CORBA 3.4 Deferred closed
CORBA34-36 two not used and document exceptions listed ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-38 Event mechanism proposal ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-39 typedef CCMObjectSeq ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-40 The spec mentions InvalidConfiguration as exception but there is no idl in this spec ZIOP 1.0b1 CORBA 3.4 Deferred closed
CORBA34-37 ResourceCommitmentManager lacking ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-31 CCMHome should have a get_components method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-32 CCMHome should have a get_container method CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-33 Incorrect statement that implies that connect_consumer returns a cookie ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-34 HomeConfiguration::set_configuration_values should document exception ZIOP 1.0 CORBA 3.4 Deferred closed
CORBA34-25 Interface Introspection CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-27 Generic port connections CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-26 LwCCM issue - Section 1.4.3.3 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-29 HomeConfigurator should not extend CCMHome CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-30 Session2Context interface CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-28 LwCCM issue - Section 1.6.8 Exclusion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-19 page 1-20 and page 1-21 - editorial CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-23 Change new GIOP Negotiate Session Message to Firewall Specific CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-22 GIOP Conformance and Interceptors CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-21 context interface for home implementation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-20 page 1-20 the description of the get_connection operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-24 CodeSet and CSIv2 Negotitaion CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-13 valuetype fragmentation ambiguous CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-14 Clarification on multi-threaded codeset negotiation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-15 15.3.3 - codesets must be "explicitly defined" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-16 [Components] Contradiction between IDL and Interface Repository concerning CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-17 Chapter/section: 15.4.2.2 "Request Body" CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-18 page 1-20 second bullet of the description of the disconnect operation CORBA 3.0.2 CORBA 3.4 Deferred closed
CORBA34-7 Duplicate union labels CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-6 COM Sequence changes CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-8 Changes to ForeignComplexType CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-9 Section 13A.5.2: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-10 Section 13A.2.3: editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-11 Capter 13C: Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-12 Incorrect mappings for systems exceptions (part A) CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-5 Section 13C.1.3 Editorial CORBA 2.0 CORBA 3.4 Deferred closed
CORBA34-4 Levels of Indirection for passing COM types CORBA 2.0 CORBA 3.4 Deferred closed
CSRM-14 Additions for convenience methods CSRM 1.0b2 CSRM 1.0 Resolved closed
CSRM-31 Add comments to 7.6.3 ExtRequirement source/Risk elements CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-28 MeasurementSpecification missing documentation CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-26 VerificationActivity missing documentation on verificaionMethod CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-3 Change 7.6 SysML Extentions CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-2 Add relationship convenience attribute for Validated and other relationships CSRM 1.0b1 CSRM 1.0 Duplicate or Merged closed
CSRM-41 Modify Paragraph 2 to remove redundant reference to the machine readable file. CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-35 Clarify usage of Group stereotype CSRM 1.0a1 CSRM 1.0 Resolved closed
CSRM-11 Change names from CubeSat to Satellite CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-17 Remove Section 0 (zero) CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-8 This issue created by mistake CSRM 1.0b2 CSRM 1.0 Closed; No Change closed
CSRM-12 Recommended Additions CSRM 1.0a1 CSRM 1.0 Deferred closed
CSRM-4 Add constraints to aid in correctness of profile useage CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-9 Change names from CubeSat to Satellite. CSRM 1.0b1 CSRM 1.0 Closed; No Change closed
CSRM-5 Create examples of use of the profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-1 Icons for profile CSRM 1.0b1 CSRM 1.0 Deferred closed
CSRM-16 Remove Section 0 from the document CSRM 1.0a1 CSRM 1.0 Closed; No Change closed
CORBARS_-1 Provide a simple sample application CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
CORBARS_-2 Provide example of authentication and security CORBA-REST 1.0b1 CORBA-REST 1.0 Resolved closed
C2INAV11-1 FTF-1 changes to be applied to GraphQL PSM C2INAV 1.0a1 C2INAV 1.1 Resolved closed
C2INAV11-3 Update GraphQL PSM Mapping C2INAV 1.0 C2INAV 1.1 Duplicate or Merged closed
CPP1116-19 Add mapping for @optional CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-20 Impact of @final on union/struct mapping CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-11 Add IDL::traits<>::bit_bound CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-12 Invalid constructor in example code CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-18 Use IDL::traits<>::make_reference instead of CORBA::make_reference CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-15 The page footers of https://www.omg.org/spec/CPP11/1.5/PDF (ptc-20-11-02.pdf) all say v1.4 CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-6 Struct inheritance mapping strange CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-5 Incorrect footer CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-7 IDL::traits missing for enum type for bitmask and use a C++11 strong enum CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-10 Remove std namespace from example code CPP11 1.5 CPP 1.6 Duplicate or Merged closed
CPP1116-9 Why not map bitset inheritance to struct inheritance CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-14 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-8 Remove std namespace from example code CPP11 1.5 CPP 1.6 Closed; No Change closed
CPP1116-13 Missing override CPP11 1.5 CPP 1.6 Resolved closed
CPP1116-3 Annotation for union discriminator name CPP11 1.5 CPP 1.6 Deferred closed
CPP1116-4 Add mapping for IDL4.2 standardized annotations CPP11 1.4 CPP 1.6 Deferred closed
CPP1116-1 Replace ServantBase with Servant CPP11 1.4 CPP 1.6 Resolved closed
CPP1114-29 Use C++11 using instead of typedef in all C++11 example code CPP11 1.3 CPP11 1.4 Resolved closed
CPP1115-18 IDL4 Extended Data-Types: struct inheritance CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-4 Add support for int8 CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-9 Example V_factory should list deleted assignment/copy CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-7 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Duplicate or Merged closed
CPP1115-6 valuebox should be final CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-5 Copy/move assignment operators should be deleted CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-8 Missing deleted assignment/copy operators CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-3 Operations tagged with override shouldn't have virtual CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-2 _default_POA should use override CPP11 1.4 CPP11 1.5 Resolved closed
CPP1115-1 Add support for bitset/bitfield/bitmask CPP11 1.4 CPP11 1.5 Resolved closed
C2MS-14 Data Dictionary Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2INAV-45 No Depth Accuracy Information Available C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-43 Placement of surge,sway and heave within the spec C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-13 Declaration of keys missing from IDL files C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-12 Circular dependency between modules Reporting and Attitude C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-11 offset_report_type is declared out of order C2INAV 1.0a1 C2INAV 1.0 Closed; No Change closed
C2INAV-10 Missing import statements C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-9 Strings should have a maximum size C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-8 Class version numbers are inappropriate C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-7 All Ext child packages are in the same file C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-6 navigation_report_type: composite_contributors needs a Length tag C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-5 Add notes to the navigation_report_kind_type in the IDL/DDS PSM enum literals C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-18 There are no notes for the report relation of navigation_covariance_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-17 Depth Report not a specialisation of navigation_report_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-15 Reference from navigation_covariance_type to navigation_report_type needs a length C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-49 FTF-1 changes to be applied to GraphQL PSM C2INAV 1.0a1 C2INAV 1.0 Deferred closed
C2INAV-47 Rotation should be about the centre of rotation not the platform reference point C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-4 implementation defined is miss-spelled C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-3 Accuracy compositions should have notes C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-2 write_rotational_attitude is not correctly entered in the UML model C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-1 navigation_covariance_type should have a max length C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-21 Unclear which OARIS files are required C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-20 Duplicate declaration from overloaded operation names C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-19 navigation_report_kind_sequence_type in unbounded in DDS PSM C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-16 Type mismatch in reference to navigation_report_type C2INAV 1.0a1 C2INAV 1.0 Resolved closed
C2INAV-14 Only top-level attributes can be declared as keys for DDS topic types C2INAV 1.0a1 C2INAV 1.0 Resolved closed
CORBA34-2 Extract IDL details from CORBA spec CORBA 3.3 CORBA 3.4 Resolved closed
CORBA34-1 Valuetypes should be added to the list of scopes CORBA 3.3 CORBA 3.4 Closed; Out Of Scope closed
C2MS-62 Specify multiplicity for required and optional fields C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-61 Add documentation within the model C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-60 "Mnemonic" should be called "Parameter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-59 For consistency, all message types should have a name that ends with "message" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-44 Requesting data via pub/sub requires knowing publisher's service name C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-42 Pub/Sub subscription status unknown C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-41 Acknowledge Final Status inconsistency C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-39 XML PSM recommended C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-15 Procedure Execution Status/Progress/Detail Messages C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-13 Parameter Mnemonic Messages Misses "setter" C2MS 1.0b1 C2MS 1.0 Deferred closed
C2MS-11 Archive Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-9 C2CX Heartbeat comments C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-3 Lack of a registry concept C2MS 1.0a1 C2MS 1.0 Deferred closed
C2MS-36 Fix C2CX Device message, field NUM-OF_DEVICES C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-84 Merge figures 8-1 and 8-2 C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-83 Add (back) Simple Service request and response messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-82 Change HEADER-VERSION and CONTENT-VERSION default values to 2019 in all Message Diagrams and all Message Contents tables C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-81 Add DESTINATION-COMPONENT field to the header and to the Miscellaneous Elements of REQ, RESP, and MSG messages that are associated with a REQ C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-80 Add field MSG-VERSION to the header C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-79 Add request-id to be one of the Miscellaneous Elements in subjects of MSG type messages that may be in response to a request C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-78 Add another row in the table, for operator entered log messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-57 Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-40 Non-satellite-related messages are not representable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-25 Change the type info for a field in the C2CX Device message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-24 Add Command Echo message C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-21 In Heartbeat message: fix typo in the name of the field CONNECTION-ENDPOINT C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-20 space/18-02-05 (C2MS zip file for XML schemas) contains corrupt file C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-19 space/18-02-03 XMI file doesn't 'validate' C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-17 use of color is discouraged C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-16 space/18-02-05 (C2MS zip file for XML schemas) - zip file unreadable C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-12 Product Messages comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-10 Mnemonic Value Request comments C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-43 Modifying a subscription is undefined C2MS 1.0b1 C2MS 1.0 Duplicate or Merged closed
C2MS-23 Flatten the message hierarchy re: C2CX, TLM, and NDM messages C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-22 Make sure CCSDS info is consistent and current C2MS 1.0b1 C2MS 1.0 Closed; No Change closed
C2MS-18 page numbers in early sections are messed up (i, ii, i, iii, etc.) C2MS 1.0b1 C2MS 1.0 Resolved closed
C2MS-8 Directive Request: strings, UNIQUE-ID and correlation IDs C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-7 Change comments regarding signed types C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-6 Have required attributes in the messages C2MS 1.0a1 C2MS 1.0 Resolved closed
C2MS-5 Acknowledge Final Status is not deterministic C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-4 Subject naming missing the concept of something not being directly tied to a satellite C2MS 1.0a1 C2MS 1.0 Closed; No Change closed
C2MS-2 Should GMSEC API enforce/recommend XML-formatted string constructor usage? C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
C2MS-1 Expecting that GMSEC will change to use C2MS as its Subject Standard C2MS 1.0a1 C2MS 1.0 Closed; Out Of Scope closed
CPP1114-31 Add Delegation-Based Interface Implementation CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-14 Remove the setter operation for the discriminator of a union CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-12 Bullets before IDL::traits::narrow(ap) lost CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-9 OBV_Example constructor CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-8 Text alignment CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-7 Typo fixes CPP11 1.3b1 CPP11 1.4 Resolved closed
CPP1114-13 Only single argument constructors have to be explicit CPP11 1.3 CPP11 1.4 Closed; No Change closed
CPP1114-4 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-3 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.4 Resolved closed
CPP1114-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.4 Closed; Out Of Scope closed
CPP1114-1 In-place construction of structure types CPP11 1.0 CPP11 1.4 Closed; No Change closed
CPP1114-11 Reduce indent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-10 Alignment _is_a and _non_existent CPP11 1.3 CPP11 1.4 Resolved closed
CPP1114-5 Structure mapping change should be reverted CPP11 1.2 CPP11 1.4 Closed; No Change closed
CPP1114-6 Fixed is now broken CPP11 1.2 CPP11 1.4 Resolved closed
CORBA31-112 Section: 15.4.5.1 struct has to be updated CORBA 3.0.3 CORBA 3.1 Deferred closed
CPP1113-11 Errors in IDL Built-in Annotations Usage Table CPP11 1.2 CPP11 1.3 Deferred closed
CPP1113-6 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-7 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.3 Deferred closed
CPP1113-5 In-place construction of structure types CPP11 1.0 CPP11 1.3 Deferred closed
CPP1113-10 Example C++ code in mapping for constants should use C++11 uniform initialization CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-1 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.3 Resolved closed
CPP1113-9 Fix assignment operator of ColorValue CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-8 CORBA::make_reference shouldn't explicitly imply perfect forwarding CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-4 Handle possible exception what conflict and improve Exception introduction text CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-3 Trivial grammatic fix in 6.14.1 CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-2 minor accessors of SystemException should use pass by value, minor should be uint32_t CPP11 1.2 CPP11 1.3 Resolved closed
CPP1113-13 Only a namespace level swap should be provided CPP11 1.2 CPP11 1.3 Resolved closed
CR-89 Tasks with RepetitionRule: how to restrict the number of task instances (at a given time)? CMMN 1.1 CMMN 1.1 Resolved closed
CR-141 DI Chapter Editorials CMMN 1.0 CMMN 1.1 Resolved closed
CR-140 Change the Notation of the OnPart so it does not conflict with Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-143 Editorial to section 5.1.5 CMMN 1.0 CMMN 1.1 Resolved closed
CR-131 Need for annotations and comments in CMMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-133 Need the ability to have repetition rules in Tasks and Stages without entry criterion CMMN 1.0 CMMN 1.1 Resolved closed
CR-137 Editorial: Update Table 2.1 - Conformance matrix CMMN 1.0 CMMN 1.1 Resolved closed
CR-128 Expressiveness of Task patterns CMMN 1.0 CMMN 1.1 Deferred closed
CR-127 Depicting Inputs and Outputs to Tasks CMMN 1.0 CMMN 1.1 Deferred closed
CR-126 Exit Criterion may be misleading (as a name or concept) CMMN 1.0 CMMN 1.1 Deferred closed
CR-124 Need to add names to contributors CMMN 1.0 CMMN 1.1 Resolved closed
CR-118 Missing constraint to prevent Human Task from being discretionary to itself CMMN 1.0 CMMN 1.1 Resolved closed
CR-98 Create classes to hold entry and exit criterion references CMMN 1.0 CMMN 1.1 Resolved closed
CR-96 Add name attribute to OnPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-92 Inconsistency between XSD and meta-model for condition on IfPart CMMN 1.0 CMMN 1.1 Resolved closed
CR-90 Missing attribute “name” for Process CMMN 1.0 CMMN 1.1 Resolved closed
CR-110 Missing "externalRef" in Process class CMMN 1.0 CMMN 1.1 Resolved closed
CR-104 Some figure in chapter 6 do not use the new Discretionary Association CMMN 1.0 CMMN 1.1 Resolved closed
CR-101 XSD Doesn't allow DiscretionaryItem to have entry/exit criteria CMMN 1.0 CMMN 1.1 Resolved closed
CR-107 Confusing Planning Table on figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-94 Add a new discretionary association CMMN 1.0 CMMN 1.1 Resolved closed
CR-87 We should add a Decision type task CMMN 1.0 CMMN 1.1 Resolved closed
CR-76 Missing PlanningTable on the CasePlanModel of figure 6.63 CMMN 1.0 CMMN 1.1 Resolved closed
CR-74 Missing notational element for discretionary Milestones and discretionary EventListeners CMMN 1.0 CMMN 1.1 Deferred closed
CR-67 Expression description prevent constant expressions CMMN 1.0 CMMN 1.1 Resolved closed
CR-69 CMMN does not include the notion of swim lanes CMMN 1.0 CMMN 1.1 Deferred closed
CR-120 Typo in the xsd: in Task we have inputs and outputs instead of input and output CMMN 1.0 CMMN 1.1 Resolved closed
CR-116 Missing attribute "name" in the XSD for ApplicabilityRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-114 Missing authorizedRoleRefs in XSD for tUserEventListener CMMN 1.0 CMMN 1.1 Resolved closed
CR-21 CMMN needs to support Diagram Interchange CMMN 1.0 CMMN 1.1 Resolved closed
CR-14 Ambiguous OnPart references for cross-stage-boundary plan items CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-7 CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries CMMN 1.0 CMMN 1.1 Resolved closed
CR-3 Undesired limitation on PlanItemDefinitions CMMN 1.0 CMMN 1.1 Resolved closed
CR-23 Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean? CMMN 1.0 CMMN 1.1 Resolved closed
CR-19 Incorrect Example image CMMN 1.0 CMMN 1.1 Resolved closed
CR-82 Unrequired “body” element in expression in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-79 Terminology inconsistency between Metamodel and XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-78 EventListeners erroneously listed for RequiredRule CMMN 1.0 CMMN 1.1 Resolved closed
CR-72 XML-Schema tCaseFileItem definitionRef attribute must not be mandatory CMMN 1.0 CMMN 1.1 Resolved closed
CR-70 CMMNElement should have Documentation CMMN 1.0 CMMN 1.1 Resolved closed
CR-88 We should allow for the State of a file item to be placed in [Square] brackets CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-75 CMMN XSD - Inconsistent with the spec text CMMN 1.0 CMMN 1.1 Resolved closed
CR-77 Issue with Human Task XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-35 Unclear CasefileItem TargetRef and SourceRef and instance operations referring to them CMMN 1.0 CMMN 1.1 Resolved closed
CR-34 XSD attribute "processRef" MUST be required CMMN 1.0 CMMN 1.1 Resolved closed
CR-27 Extensibility of DefinitionTypeEnum and Property types CMMN 1.0 CMMN 1.1 Resolved closed
CR-20 CMMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions) CMMN 1.0 CMMN 1.1 Resolved closed
CR-15 Timerevent based on data not possible CMMN 1.0 CMMN 1.1 Resolved closed
CR-13 Unclear when an IfPart only sentry must be evaluated CMMN 1.0 CMMN 1.1 Resolved closed
CR-12 CaseTask.CaseRef should allow for expressions to support dynamic subcases CMMN 1.0 CMMN 1.1 Resolved closed
CR-11 Sentry behavior for OnParts referring to Repeating PlanItems is unclear CMMN 1.0 CMMN 1.1 Resolved closed
CR-8 PerformerRole should be applied to PlanItem rather than HumanTask CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-5 Discretionary Items should also have a Name property CMMN 1.0 CMMN 1.1 Resolved closed
CR-1 Inconsistencies between class diagram figures and attribute tables CMMN 1.0 CMMN 1.1 Resolved closed
CR-16 Two entry criteria cannot be connected CMMN 1.0 CMMN 1.1 Closed; No Change closed
CR-46 Mislabled table CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-53 Table labeled as a figure in page 40 CMMN 1.0 CMMN 1.1 Resolved closed
CR-59 Usage of Terminate state as Completion CMMN 1.0 CMMN 1.1 Resolved closed
CR-55 Reference missformated CMMN 1.0 CMMN 1.1 Resolved closed
CR-57 Future sentence in specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-26 Missing "decimal" type in table 5.7 property types and their URIs CMMN 1.0 CMMN 1.1 Resolved closed
CR-22 Non-normative References do not include CMIS CMMN 1.0 CMMN 1.1 Resolved closed
CR-10 Table 7.9 contains invalid "To state" values for Resume transition CMMN 1.0 CMMN 1.1 Resolved closed
CR-9 Typo in specification, unclear what is intended here CMMN 1.0 CMMN 1.1 Resolved closed
CR-6 PlanItemControl of discretionaries should also allow repetitionrules CMMN 1.0 CMMN 1.1 Resolved closed
CR-4 "The construct in Figure 6.35" should be Figure 6.34 CMMN 1.0 CMMN 1.1 Duplicate or Merged closed
CR-2 The scope does not clarifies the relationship between CMMN and BPMN CMMN 1.0 CMMN 1.1 Resolved closed
CR-25 Missing reference to XML Schema and XPath specification CMMN 1.0 CMMN 1.1 Resolved closed
CR-24 CaseRoles have ugly definition in the XSD CMMN 1.0 CMMN 1.1 Resolved closed
CR-18 Incorrect References CMMN 1.0 CMMN 1.1 Resolved closed
CR-17 Inputs/outputs on task CMMN 1.0 CMMN 1.1 Closed; No Change closed
ITCR-57 Fix unclarity in IDL Union description CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-54 Update normative reference to point to CORBA 3.3 CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-38 IDL2C++11 mapping lacks support for the new IDL type map CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-28 Servant argument passing not precise enough CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-39 Missing public specifier CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-42 replace POA_B by adequate skeleton CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-41 _this for skeleton, not for implementation CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-44 Skeleton class as consistent template parameter for CORBA::servant_traits CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-43 abstract interfaces with corrected skeleton name CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-3 Errors on code snippet related to skeleton classes CPP11 1.0 CPP11 1.2 Resolved closed
ITCR-1 In-place construction of structure types CPP11 1.0 CPP11 1.2 Deferred closed
ITCR-12 Clarify valuetype factory mapping CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-11 Valuebox should also have swap support CPP11 1.1 CPP11 1.2 Closed; No Change closed
ITCR-8 provide unique class name as mapping of PortableServer::Servant CPP11 1.1 CPP11 1.2 Duplicate or Merged closed
ITCR-7 Constructor declarations in Servant code are wrong CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-6 Destructors of strong reference types should be public CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-17 Mention move constructor with abstract CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-16 usage of OBV trait should be improved CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-10 Add missing default initialization for valuetypes CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-9 wrong return type for Foo::some_function() CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-5 Question on unions default member CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-4 Code fragment should use skel class CPP11 1.0 CPP11 1.2 Closed; No Change closed
ITCR-15 Move constructor of ValueBase incorrect CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-14 Missing move assignment operator in class ColorValue CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-19 fixed member types use incorrect type CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-18 Destructor should just be virtual CPP11 1.1 CPP11 1.2 Resolved closed
ITCR-2 IDL2C++11 issue : CORBA dependency of the C++11 mapping CPP11 1.1 CPP11 1.2 Deferred closed
ITCR-13 Make mapping of sequences more flexible CPP11 1.1 CPP11 1.2 Deferred closed
CORBA31-218 ZIOP has to be part of the core CORBA specification ZIOP 1.0 CORBA 3.1.1 Resolved closed
CORBA23-247 question re BiDir IIOP CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-246 New OBV "supports" keyword conflicts with CosLifeCycle CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-245 Abstract Interface issue (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA3-134 IDL keyword clash in CosNotification.idl CORBA 2.6 CORBA 3.0 Resolved closed
CORBA23-244 Query Service IDL code CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA25-57 CORBAservices IDL CORBA 2.2 CORBA 2.5 Resolved closed
COLL-12 CORBAservices (editorial page 17-23) COLL 1.0b1 COLL 1.0 Resolved closed
COLL-11 CORBAservices (editorial page 17-22) COLL 1.0b1 COLL 1.0 Resolved closed
COLL-10 CORBAservices (editorial page 17-21) COLL 1.0b1 COLL 1.0 Resolved closed
COBOL-6 Name scooping inappropriate within some mainframe environments COBOL 1.0b1 COBOL 1.0 Resolved closed
CORP-7 Change the VMM CORP 1.0b1 CORP 1.0 Resolved closed
CORP-6 Name of the model element for CORBAUnions CORP 1.0b1 CORP 1.0 Resolved closed
CORP-5 Add long double to the coverage of CORBA primitive types. CORP 1.0b1 CORP 1.0 Resolved closed
CORP-4 The UML 1.4 RTF may tighten the definition of a UML profile. CORP 1.0b1 CORP 1.0 Resolved closed
CORP-3 Namespace rules CORP 1.0b1 CORP 1.0 Resolved closed
CORP-2 The spec. doesn't say precisely which version of CORBA it is targeted to CORP 1.0b1 CORP 1.0 Resolved closed
CORBA23-243 OBV TypeCode problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA26-99 Include GIOP over Bluetooth into Wireless CORBA 1.1 CORBA 2.5 CORBA 2.6 Resolved closed
CORBA23-242 Module separator within repository IDs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-241 DynAny::get_value collision CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-240 Problem with C++ language mapping for OBV CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-239 public static org.omg.CORBA.ValueDef get_value_def(); CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-238 Clarify semantics CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-237 Which exceptions should be raised? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-236 Grammar rule issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-235 "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ] CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-234 CODESET_INCOMPATIBLE exception is not defined CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-232 Wide String (and String encoding) CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-231 IDL TypeExtension correction CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-233 IDL Type Extensions: DATA_CONVERSION exception CORBA 1.2 CORBA 2.3 Resolved closed
CORBA24-203 What should an ORB do when it does not find any profile in an IOR CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-202 Standard System Exception minor codes missing in Chapter 13 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-201 Component ids in 13.6.2.2 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-230 OBV chunk boundaries CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-200 Transmission of type codes across 2.2/2.3 boundaries CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-199 LOCATE_FORWARD_PERM and hash() CORBA 2.2 CORBA 2.4 Resolved closed
CORBA23-229 Clarification requested on GIOP 1.1 and wstring CORBA 2.2 CORBA 2.3 Resolved closed
CORBA31-217 Japan CORBA Part 2 PAS Ballot Comments - comment 12 CORBA 3.1 CORBA 3.1.1 Resolved closed
CPP11-266 20.17.9 Valuetype Inheritance CPP 1.0 CPP 1.1 Resolved closed
CPP11-265 sequence max < length CPP 1.0b2 CPP 1.1 Resolved closed
CPP11-264 Rounding and truncation of Fixed CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-263 Fixed-point initialization CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-262 C++ Servants: Adding Reference counting CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-261 Add _narrow() operation to each POA servant CPP 1.0b2 CPP 1.1 Resolved closed
CORBA23-228 TypeCode constants for bounded strings? CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA23-227 DynValue::get_members/set_members CORBA 2.2 CORBA 2.3.1 Resolved closed
CORBA24-198 IDL constant declarations CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-197 Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST CORBA 2.3.1 CORBA 2.4.2 Closed; No Change closed
CORBA25-56 SYNC_WITH_SERVER CORBA 2.4.2 CORBA 2.5 Closed; No Change closed
CORBA24-196 Changebars missing from POA chapter CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-226 Type code parameter ordering CORBA 2.2 CORBA 2.3 Resolved closed
CORBA21-113 RMI repository ID references to serial version UID CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-112 Second bit of response_flags CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-111 Issue: Problem with issue 2801 resolution CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-110 fragmentation broken with bi-dir giop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-109 CODESET_INCOMPATIBLE exception CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-108 A Messaging related issue in GIOP 1.2 CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-107 IIOP 1.2 fragmentation presents an unrecoverable error situation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-106 New IDL types CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-105 Narrow Interop CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-104 Contents of MultiComponent component an encapsulation? CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-103 Type any marshalling rules force slow implementation CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-102 Marshalling of union type codes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-101 Typecode encoding is too long CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-100 Type code marshalling CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-97 CDR encoding of TypeCodes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-99 Typecode indirection issue CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-98 No provision for numbering the fragments in fragmented IIOP messages CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-96 Correct CDR encoding of an empty string CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-95 Typecode equality CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-94 Wchar and Char can both be multibyte CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-91 GIOP Exception formatting description (12.4.2) CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-93 Issue about CDR encoding for wide characters CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-92 Query about GIOP and IIOP version numbers in 98-01-03 CORBA 2.0 CORBA 2.1 Resolved closed
CCCMP-12 Section: 7.3.3 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-11 Section: 7.2.10 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-14 Section: 8.1.2, Figure 8.12 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-13 Section: 8.1.2 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-10 Section: 3 Normative References CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-9 More clarification text about order of CORBAStruct members is needed CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-8 clarification about relationships of specifications needed CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-7 Section: 8.1.2 p. 40 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-6 Section: 8.1.2 p. 44 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
CCCMP-5 Section: 8.1.2 CCCMP 1.0b1 CCCMP 1.0 Resolved closed
C2WSDL12-25 Section: 1.2.7.10 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-24 xsd:url type not defined in schema C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-23 CORBA to WSDL/SOAP: example for attributes mapping C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-22 'CORBA to WSDL/SOAP: example for operation mapping C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-21 'CORBA to WSDL/SOAP Section 1.2.8.2 C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-20 CORBA fixed types C2WSDL 1.0 C2WSDL 1.1 Resolved closed
C2WSDL12-19 CORBA-WSDL/SOAP: Section 1.2.7.4 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-16 CORBA-WSDL/SOAP: Section 1.2.7.10 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-18 CORBA-WSDL/SOAP: section 1.2.8.2 , 1.2.8.4 and 1.2.8.5 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-17 CORBA-WSDL/SOAP: Section 1.2.7.10.3 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-15 CORBA-WSDL/SOAP: section 1.2.4 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-14 Section 1.2.3 repository id inconsistency C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-13 CORBA-WSDL/SOAP: Section 1.2.3 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-12 CORBA-WSDL/SOAP: Section 1.2.2.1 C2WSDL 1.0b1 C2WSDL 1.0 Resolved closed
C2WSDL12-11 Section: 1.2.x (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Duplicate or Merged closed
CORBA31-216 Sections 8.1.1, 8.2.1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-212 Section 7.1, line1: CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-211 Figure 1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-215 Section 8.1.1 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-214 7.2, sentence 3 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-213 - Figure 2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-210 use the proper notation for expressing Profiles CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-209 Minor comments re Components FTF CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-208 Section 7.2 CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-207 On Page 18 - Figure 11 Home mapping CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-206 Section 7, Overview CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA31-205 sections 1, 3, 4, 5 essentially empty CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA3-133 insufficient examples of component attributes CORBA 3.0.2 CORBA 3.0.3 Duplicate or Merged closed
CORBA3-132 Derived component supported interface restriction CORBA 3.0 CORBA 3.0.1 Resolved closed
CTS212-26 OMG Architecture Board review issues, Nov 2013 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-25 The reference in B4 should instead be added to section 3 (assuming it is normative) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-24 Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L) CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-22 Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-21 The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-20 issue with rule 10 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-23 conflict between rules 10 and 13 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-19 The documents referenced in Rule 12 should appear in the normative references section CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-18 B2 rule 7: I’m not aware of such a thing as an “XML array” CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-17 Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01 CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-16 The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-15 the “Plan” in 6.2 with the RTF working in parallel is not being followed at all CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-14 No Beta document CTS2 1.1 CTS2 1.2 Resolved closed
CTS212-13 Section 1: should rephrase “this submission” – it’s now a specification CTS2 1.1 CTS2 1.2 Resolved closed
CORBA24-192 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-191 destroy on POA CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-190 Valuetype "copying" semantics underspecified? CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-189 Scope of inherited valuetype initializers CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA24-188 Null valuetypes not supported by DynValue CORBA 2.3.1 CORBA 2.4 Duplicate or Merged closed
CORBA25-55 International Strings in Encapsulations CORBA 2.3.1 CORBA 2.5 Resolved closed
CORBA24-187 Expected behavior of POA configured with ServantLocator receiving LocateRe CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-225 The insert_dyn_any and get_dyn_any operations are barely documented CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-224 OBV, value-reference substitution, Multiple Inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-223 WRONG_TRANSACTION CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA23-222 Proposal on floating point fixes CORBA 2.2 CORBA 2.3 Duplicate or Merged closed
CORBA24-186 Section 3.3.8.16:deactivate_object() operation CORBA 2.1 CORBA 2.4 Resolved closed
CORBA23-221 Object::is_a CORBA 2.0 CORBA 2.3 Resolved closed
CORBA23-220 DII operations "get_response and get_next_response CORBA 1.2 CORBA 2.3 Resolved closed
CORBA23-219 6.5.6. Repository Paragraph 2 - objection CORBA 1.2 CORBA 2.3 Closed; No Change closed
CPP11-260 mapping IDL Unicode escapes to C++ CPP 1.0b2 CPP 1.0 Resolved closed
CPP11-259 Mappings for hash, is_equivalent, _is_a and _non_existent CPP 1.0b1 CPP 1.0b2 Duplicate or Merged closed
CPP11-258 freebuf and destruction of elements CPP 1.0b1 CPP 1.1 Closed; No Change closed
CPP11-257 Re-opening modules CPP 1.0b1 CPP 1.0b2 Resolved closed
CORBAE-21 exception NoServant(); CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-20 Section: 8 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-19 Section: 5.2 and 5.7 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CPP1111-25 Reduce dependency on CORBA CPP11 1.0 CPP11 1.1 Resolved closed
CORBA32-1 Typo in set_values CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA32-2 context:delete_values has type CORBA 3.1.1 CORBA 3.2 Resolved closed
CORBA31-204 Section: exceptions CORBA 3.0.3 CORBA 3.1 Closed; No Change closed
CORBA31-203 Codec Interface Deficiencies CORBA 3.0.3 CORBA 3.1 Duplicate or Merged closed
CORBA3-131 Error in Chapter 21 of CORBA 3.0 CORBA 3.0.2 CORBA 3.0.3 Resolved closed
CORBA3-130 Wrong minor code listed in POAManager::deactivate CORBA 3.0 CORBA 3.0.1 Resolved closed
CORBA3-129 DATA_CONVERSION minor code 2 not listed in Table 4-3 CORBA 2.6.1 CORBA 3.0 Resolved closed
CORBA26-96 New core issue: need UNKNOWN reply status CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-98 TypeCode interface issue CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-97 Valuetype initialzers need exceptions CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-95 Syntax error in CORBA IDL CORBA 2.5 CORBA 2.6 Resolved closed
CPP12-43 Typedefs for struct members? CPP 1.1 CPP 1.2 Resolved closed
CPP12-42 Deprecated Ref identifier CPP 1.1 CPP 1.2 Resolved closed
CPP12-40 Server-side exception specifications and ISO C++ std::exception CPP 1.1 CPP 1.2 Resolved closed
CORBA25-54 Incorrect example for recursive definitions which can span multiple levels CORBA 2.4.2 CORBA 2.5 Resolved closed
CPP12-41 There is an incorrect page reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-39 Remnant of read-only return values and out params CPP 1.1 CPP 1.2 Resolved closed
CPP12-38 Backward compatibility with C CPP 1.1 CPP 1.2 Resolved closed
CPP12-37 Non-exception neutral code in C++ mapping. CPP 1.1 CPP 1.2 Resolved closed
CPP12-36 Need for TIE template for skeletons for valuetypes that support CPP 1.1 CPP 1.2 Resolved closed
CPP12-35 _name & _rep_id pure virtual? CPP 1.1 CPP 1.2 Resolved closed
CPP12-34 Requiring ref counting in ServantBase CPP 1.1 CPP 1.2 Resolved closed
CORBA24-185 Definition of TRANSIENT minor code 1 confusing CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-184 IDL format for RepositoryId CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-183 Valuetypes supporting local interfaces are local types? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-180 DynUnion incomplete CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-182 #pragma version issue CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CORBA24-181 Servant deactivation callback? CORBA 2.4.1 CORBA 2.4.2 Resolved closed
CPP12-33 CORBA::Fixed needs a to_string() conversion function CPP 1.1 CPP 1.2 Resolved closed
CORBA24-179 Format of RMI Hashed Format repid CORBA 2.4 CORBA 2.4.2 Resolved closed
CPP12-32 Another issue with String_var CPP 1.1 CPP 1.2 Resolved closed
CPP12-31 Missing conversion operator on String_var CPP 1.1 CPP 1.2 Resolved closed
CORBA24-178 Typo: "Wrongpolicy" CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-177 Minor typo CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-30 Any extraction widening to ValueBase CPP 1.1 CPP 1.2 Resolved closed
CORBA24-176 Section 4.3.7.1 get_client_policy? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-175 Typo on page 7-9 of 2.3.1 CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-29 Null assignment to String_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-28 _name and _rep_id CPP 1.1 CPP 1.2 Resolved closed
CORBA24-174 BAD_QOS system exception CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-27 Do valuetype POA servants get tie templates? CPP 1.1 CPP 1.2 Resolved closed
CPP12-25 Problem with OBV_ valuetype class constructor CPP 1.1 CPP 1.2 Resolved closed
CPP12-26 Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP12-23 C++ Value Type issue (02) CPP 1.1 CPP 1.2 Resolved closed
CPP12-24 Obsolete text in 1.40.3 CPP 1.1 CPP 1.2 Resolved closed
CPP12-22 Valuebox for object reference underspecified CPP 1.1 CPP 1.2 Resolved closed
CPP12-21 C++ valuetype issue (01) CPP 1.1 CPP 1.2 Resolved closed
CORBA24-173 attributes and system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CPP12-20 Valuetype code typo in CORBA 2.3 C++ mapping CPP 1.1 CPP 1.2 Resolved closed
CPP11-256 C++: ostream insertion CPP 1.0 CPP 1.1 Duplicate or Merged closed
CPP11-255 _var types for fixed-length underlying types CPP 1.0 CPP 1.1 Resolved closed
CORBA24-172 why was is_abstract added to structs in CORBA IR? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-218 Null Value semantics under specified CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-217 DynFactory or DynAnyFactory? CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-216 is_abstract parameter missing from create_interface() IDL CORBA 2.3 CORBA 2.3.1 Resolved closed
CPP11-254 string sequences and empty strings CPP 1.0 CPP 1.1 Resolved closed
CPP11-253 Incorrect types for type-safe Any extraction CPP 1.0 CPP 1.1 Resolved closed
CPP11-252 "Diamond of Death" in CosLifeCycleReference CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-215 Destruction of ORB CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-251 Typedef for ties? CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-214 OMG VMCID CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-250 Tie classes CPP 1.0b2 CPP 1.0 Closed; No Change closed
CORBA23-213 New proposal for recursive TypeCode creation CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-211 Typo on pages 10-53, 10-55, and 10-70 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-212 deactivate_object page no: 9-35 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-210 Proposal for creating recursive TypeCodes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-209 Types defined in the CORBA module? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-208 Missing orb.idl CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-206 Size of IDL char CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-207 Incorrect LifeCycle IDL? CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-249 Servant management rules CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-205 Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-204 CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-203 Illegal IDL in CosTime module CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-202 TypeCode comparison proposal (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-201 TypeCode comparison proposal (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-200 Description of Wide String type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-199 name scoping issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-198 IDL struct issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-197 Type codes cannot describe all unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-196 Type code operations under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-195 Type code typos (as only one issue) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-194 Typo in chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-193 Does the DII support the standard object operations? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-192 Typos in IR IDL in Specification (050 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-191 Typos in IR IDL in Specification (04) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-190 Typos in IR IDL in Specification (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-189 Typos in IR IDL in Specification (02) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-188 Typos in IR IDL in spec (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-187 / in prefix pragma? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-186 Versioning by the back door? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-185 GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-184 Domain Manager related specification shortcomings (03) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-183 Semantics and standard exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-182 Forward declarations and inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CPP11-248 Typos in parameter passing rules CPP 1.0b2 CPP 1.0 Resolved closed
CORBA23-181 Indentation on page 4-4 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-180 Editorial issue, chapter 8 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-179 ORB_init CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-178 IDl "module" construct - IDL files CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-177 How to deal with object identity CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-176 Typo in type code section (13.3.4) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-174 Fixed point constants issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-173 Wide character and wide string literals CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-175 Type of fixed point quotients CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-172 Fixed point constant typo in 2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-171 Marshalling is_equivalent CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-170 #pragma prefix issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-169 CORBA 2.2 - "native" and the interface repository CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-142 union typecode CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-141 CDR encoding of TypeCode names inconsistent with equal operation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA21-90 OMG IDL prefix pragma CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-89 Description of constant expression semantics is unclear CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-88 Object terminal missing from IDL grammar CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-87 WRONG_TRANSACTION CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-86 OTS 1.1 specification changes CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-85 Interface Repository CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-84 CORBA::Bounds and CORBA::TypeCode::Bounds CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-83 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Duplicate or Merged closed
CORBA21-82 Do simple/anonymous types have repository IDs? CORBA 1.2 CORBA 2.0 Resolved closed
CPP11-247 Efficiency issue in C++ mapping CPP 1.0b1 CPP 1.0b2 Resolved closed
CORBA21-81 Exception as explicit parameter CORBA 1.2 CORBA 2.0 Resolved closed
CPP1111-24 Remove user defined literal support CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-23 Add namespace level swap CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-20 Small typos in servant reference section CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-19 Replace all _downcase/downcase with narrow CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-22 Relax constructor argument rules CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-21 Remove final for structured types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-2 typo exists in section 6.21 CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-1 RFP requirement on DDS-PSM-Cxx compatibility is violated CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-3 Lack of factory reference type CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-14 Early detection of bound violation on bounded types CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-13 std::ostream insertion underspecified CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-5 Add missing implicit widening to any CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-4 Add support for _this on local objects CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-12 Missing specification of assignment operators of valuetypes CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-11 Meaning of (u)intN_t types unclear CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-10 Fixed type mapping should provide (explicit) operator bool CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-9 Invalid struct initialization example CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-15 CORBA::Exception should not use std::string type for name and repo_id CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-8 Remove _narrow methods CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-7 Extend IDL type traits for template meta programming CPP11 1.0b2 CPP11 1.1 Resolved closed
CPP1111-17 Use () instead of (void) CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-16 Minor typos CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-18 Introduce trait for local interface base type CPP11 1.0 CPP11 1.1 Resolved closed
CPP1111-6 Font issue CPP11 1.0b2 CPP11 1.1 Resolved closed
CWM11-93 We only need one COBOL Data Division model CWM 1.0 CWM 1.1 Resolved closed
CWM11-92 Logical-physical deployment modeling CWM 1.0 CWM 1.1 Resolved closed
CWM11-91 Diagram 8-7-3 missing lines CWM 1.0 CWM 1.1 Resolved closed
CWM11-90 Supplier and version underspecified CWM 1.0 CWM 1.1 Resolved closed
CURR11-47 ExchangeRateValue init interface need information CURR 1.0 CURR 1.1 Resolved closed
CURR11-46 IDL Changes to support date ranges on ExchangeRateValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-58 Correct interface symantics for createExchangeRate CURR 1.0 CURR 1.1 Resolved closed
CURR11-57 Correct Currency create method CURR 1.0 CURR 1.1 Resolved closed
CURR11-52 Change the name of getStateIdentifier to issueStateIdentifier CURR 1.0 CURR 1.1 Resolved closed
CURR11-51 Correct issues with CosObjectIdentity::IdentifiableObject in StateIDManage CURR 1.0 CURR 1.1 Resolved closed
CURR11-50 Clarification on whether stateID manages session or state access CURR 1.0 CURR 1.1 Resolved closed
CURR11-49 Legal value ranges for numerics in ExchangeRateValue should be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-53 Add validity checkign for StateIdentifier CURR 1.0 CURR 1.1 Resolved closed
CURR11-54 what values are used to determine if a currency exists in CurrencyBook CURR 1.0 CURR 1.1 Resolved closed
CURR11-55 Clarify the areEquivelent interface of the CurrencyBook CURR 1.0 CURR 1.1 Resolved closed
CURR11-48 Missing details on preconditions on the ExchangeRateValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-56 Change get Currency to retrieveCurrency CURR 1.0 CURR 1.1 Resolved closed
CWM11-82 stereotype reference is missing from ModelElement CWM 1.0 CWM 1.1 Resolved closed
CWM11-81 taggedValue reference is missing from ModelElement CWM 1.0 CWM 1.1 Resolved closed
CWM11-80 provide an example of extending the Management packages CWM 1.0 CWM 1.1 Resolved closed
CWM11-79 diagram named "CWM Package Dependencies" shows wrong dependency arrow CWM 1.0 CWM 1.1 Resolved closed
CURR11-42 Add description of isCurrency Active CURR 1.0 CURR 1.1 Resolved closed
CURR11-44 MoneyValue init interface need information CURR 1.0 CURR 1.1 Resolved closed
CURR11-43 Add mechanism to create Money instances for moneyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-45 exception semantics for MoneyValue CURR 1.0 CURR 1.1 Resolved closed
CWM-1 Specify meta-model & XMI parameters for CWM XMI formats CWM 1.0b1 CWM 1.0 Resolved closed
CURR11-74 Supplied Data for ISO Locales in MoneyFormatter needs to be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-73 Change name of CBO::DAmountOfTime interface to CBO::AmountOfTime CURR 1.0 CURR 1.1 Resolved closed
CURR11-76 Value types need state CURR 1.0 CURR 1.1 Resolved closed
CURR11-75 Add clarification on formatting string in MoneyFormatter CURR 1.0 CURR 1.1 Resolved closed
CWM11-89 Optimize Instance data values CWM 1.0 CWM 1.1 Resolved closed
CWM11-88 Attribute.initialValue incorrectly implemented as mandatory. CWM 1.0 CWM 1.1 Resolved closed
CWM11-87 CWM model needs to be augmented to allow specification of level& hierarchy CWM 1.0 CWM 1.1 Resolved closed
CWM11-86 CWM does not reflect the latest version of UML CWM 1.0 CWM 1.1 Resolved closed
CWM11-85 Missing letters in chapter 9 diagrams. CWM 1.0 CWM 1.1 Resolved closed
CWM11-84 Data mining metamodel CWM 1.0 CWM 1.1 Resolved closed
CWM11-83 Revise the IMS metamodel CWM 1.0 CWM 1.1 Resolved closed
CURR11-64 Clarify legal values for the MoneyFormatter format strings CURR 1.0 CURR 1.1 Resolved closed
CURR11-61 removeExchangeRate() interface issue CURR 1.0 CURR 1.1 Resolved closed
CURR11-60 Modify and specify the behavior of the insertExchangeRate interface CURR 1.0 CURR 1.1 Resolved closed
CURR11-69 Create mechanism to modify what negative prefix is for formatting string CURR 1.0 CURR 1.1 Resolved closed
CURR11-66 Clarify exceptions for setFormattingString in MoneyFormatter CURR 1.0 CURR 1.1 Resolved closed
CURR11-65 Clarify contradiction betw setFormatByLocale & setFormattingString CURR 1.0 CURR 1.1 Resolved closed
CURR11-68 Interface changes for MoneyFormatter pattern handling CURR 1.0 CURR 1.1 Resolved closed
CURR11-67 Typo on SetPatternMnemonicSymbol name CURR 1.0 CURR 1.1 Resolved closed
CURR11-71 Add interfaces for internal precision on MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-70 Clarify on comparison methods of the MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-63 Clarify MoneyFormatter use of the # symbol CURR 1.0 CURR 1.1 Resolved closed
CURR11-62 Proposed interface changes to ExchangeRateManager CURR 1.0 CURR 1.1 Resolved closed
CURR11-72 Fix omitted precondition for MoneyCalculator CURR 1.0 CURR 1.1 Resolved closed
CURR11-59 Change the name of addExchangeRate to insertExchangeRate CURR 1.0 CURR 1.1 Resolved closed
CORBA26-87 Length of wstring in GIOP 1.1 CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-86 padding at the end of a non-fragmented 1.2 request message CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-83 IANA ports for IIOP need to be documented in Ch 13 and 15 CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-85 Interop, 15.7.3 unclear wording CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-84 Is GIOP 1.x sustainable any more? CORBA 2.3 CORBA 2.6.1 Resolved closed
CORBA26-82 Use of undefined "id" attribute CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-93 Question about corbaname URL CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-92 Incomplete grammar in section 15.3.4.8 CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-91 Indirections with chunking & fragmentation CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-89 In RMI rep Id, when is inclusion of SUID legal? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-88 GIOP is silent about extra data in the Request or Reply body CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-90 GIOP issue : fragmented replies with exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-94 Changing VSCID prefix to 24 bits CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-72 Component port introspection CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-71 "supports" terminology issue for CCM CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-77 CCM: Definition of import declaration unclear CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-70 CCM: Chapter 66 should be removed CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-69 IDL out parameters can't map to EJB? CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-74 explicit definition of CCM exceptions mapped from EJB standard exceptions CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-73 Incorrect syntax in Components::Enumeration CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-81 minor IDL changes required in CCM API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-80 Little problem with introspection API CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-79 CCM: Meaning of "exposed" scopes unclear. CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-68 CCM: usage of the MOF profile CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-76 CCM: Isolated scope tokens CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-75 Issue for Components: Missing language mapping CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-78 CCM: import and re-opening of modules CORBA 2.5 CORBA 2.6.1 Resolved closed
CORBA26-63 Extended Interface Repository CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-62 Problems with the Components Notification Event Interface CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-61 Component home interface inheritance CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-56 Components, Facets, and Object References Unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-55 New component issue: connection failure recovery CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-65 Components FTF: TypeCodeFactory CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-64 ComponentIR Interface fixes CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-58 Component assemblies do not follow composition pattern CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-57 Inter-component type semantics unclear CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-54 Typo in assembly element paragraph heading CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-53 grammar rule for home_executor_body contradicts description CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-52 No Access to event filter form component CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-60 Component home polymorphism CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-59 Component assembly templates CORBA 2.4.1 CORBA 2.6.1 Resolved closed
CORBA26-67 CCM : Session2Context naming CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-66 CCM : Session2Context and Servants CORBA 2.4.2 CORBA 2.6.1 Resolved closed
CORBA26-51 No user access to filterable body in CCM spec. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-50 IDL question concerning CCM CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-49 CCM Events issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-48 typo in connections element definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-45 Deployment Object Life Cycles CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-44 Services available for a basic container CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-43 push() versus push_event() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-41 An assembly is always mono-vendor ??? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-40 Intent of Components::Events::(un)subscribe to bypass the notif. service ? CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-39 Channel Setup for Emits ports. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-38 exception raised by Components::Events::subscribe() CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-37 ExecutablePlacement definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-36 Local push() operation. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-47 repository element needed by softpkg DTD CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-46 description element need to be added to corbacomponent.dtd CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-42 equivalent interfaces issue CORBA 2.4 CORBA 2.6.1 Resolved closed
CURR11-34 Exchange rates need to be date based. CURR 1.0 CURR 1.1 Resolved closed
CURR11-33 Clearer information describing different rounding types is needed CURR 1.0 CURR 1.1 Resolved closed
CURR11-32 Text indicating that vendors shall provide default values CURR 1.0 CURR 1.1 Resolved closed
CURR11-31 Extend ExceptionType enumerations CURR 1.0 CURR 1.1 Resolved closed
CURR11-36 Propose modification to the init method of CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-35 vendor implementations can implement only parts and interoperate-Statement CURR 1.0 CURR 1.1 Resolved closed
CURR11-39 More clarification on the semantics of string arguements for CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CURR11-38 Missing details on preconditions on the Currency interface as a whole CURR 1.0 CURR 1.1 Resolved closed
CURR11-41 Typos in CurrencyValue section CURR 1.0 CURR 1.1 Resolved closed
CURR11-40 Legal value ranges for numerics in CurrencyValue init should be discussed CURR 1.0 CURR 1.1 Resolved closed
CURR11-37 missing description on the init method for CurrencyValue CURR 1.0 CURR 1.1 Resolved closed
CSIV2-10 ISL changes to break dependency on Security and SECIOP modules CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-9 Multiple Privilege Authorities and Supported Naming Types CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-6 inconsistent definition of target_name field CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-5 Format of GSSUP GSS exported name object undefined CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-1 CSIv2 Protocol CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-12 OIDs CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-11 Module suggestions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-2 GSSUP Names are inconsistent other security mechanisms. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-8 INVALID recommended cipher suites CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-7 CSIv2 IOR Tagged component Identifier values CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-4 GSSUP names are incompatible with the Identity Token CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-3 Service ID missing CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CURR11-30 StateID Exception CURR 1.0 CURR 1.1 Resolved closed
CURR11-29 Change double to short for internal precision CURR 1.0 CURR 1.1 Resolved closed
CURR11-28 Add idl and text to describe the getAllExchangeRates method CURR 1.0 CURR 1.1 Resolved closed
CURR11-27 Add text for formatter that the format string will be used for parsing CURR 1.0 CURR 1.1 Resolved closed
CURR11-26 Change text description of behavior of ROUND_FLOOR and ROUND_CEILING CURR 1.0 CURR 1.1 Resolved closed
CURR11-25 Clarify on comparison methods of the calculato CURR 1.0 CURR 1.1 Resolved closed
CURR11-24 clarification on how the "#" is used in the money formatter CURR 1.0 CURR 1.1 Resolved closed
CSIV2-21 CSIv2 TSS state machine lacks states to enforce target policy for CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-20 The encoding of GSSUP ICT's is not clearly specified CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-16 New minor codes for NO_PERMISSION Exception in CSIv2 CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-15 How to Partition the ServiceConfiguration syntax space to support vendor sp CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-19 CSIv2 Issue: SECIOP does not have multiple addresses. CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-18 Inability to specify per method target security requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-23 How to Partition the AuthorizationElementType regarding vendor extensions CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-22 clarification of csiv2 stateful conformance requirements CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-14 Issue: inconsistent definition of AuthorizationToken CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-13 Module SSLIOP Does Not Contain Host CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CSIV2-17 No Tokens in EstablishContext Message CSIv2 1.0b1 CSIv2 1.0 Resolved closed
CORBA25-53 Urgent issue: Alignment of LocateReply body CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-52 Incorrect table in section 15.4 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-48 Table 15-2 is missing entry for tk_local_interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-47 GIOP 1.2 AddressingDisposition processing on the client side CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-46 Fixed point marshalling CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-45 Null termination of strings CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-51 Incorrect text in 15.4.6.2 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-50 GIOP 1.1 Fragment problem CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-49 tk_indirect CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA26-32 operation get_implementation() referenced but not declared CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-31 Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events. CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-30 Issue on Assemblies and descriptors CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-33 What about valuetype factories? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-35 simple ELEMENT definition CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-34 range description in CPF files. CORBA 2.4 CORBA 2.6.1 Resolved closed
CORBA26-23 Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-22 CCM issue chapter 69 ptc/99-10-04 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-21 Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-20 EJB/CCM mappings for the IR CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-19 IFR backward compatibility broken CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-18 Missing Rights Combinator in Security deployment descriptor CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-13 Purpose of "name" element CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-12 CCM Issue: CIDL Syntax doesn't allow for modules CORBA 2.3.1 CORBA 2.6.1 Resolved closed
CORBA26-29 Issue On the use of typed home (or CCMHome subtypes) CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-28 Where is HomeExecutorBase interface defined? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-27 In example p.615-86 CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-26 p.615-85 ToonTownImpl CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-25 Why does not CCMHome include the operation create_component() ? CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-24 operation CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-15 PACKAGING AND DEPLOYMENT METAMODEL CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-14 atribute not part of definition CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-11 Versioning needed for CORBA Core CORBA 2.2 CORBA 2.6.1 Resolved closed
CORBA26-17 Components: readonly_attr_declarator slightly ambiguous CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA26-16 Components: Relationship of CIDL and PSDL unclear CPP 1.1 CORBA 2.6.1 Resolved closed
CORBA31-110 ValueMembersSeq CORBA 3.0.2 CORBA 3.1 Resolved closed
CORBA31-111 Make a typedef for the POA id new CORBA 3.0.3 CORBA 3.1 Resolved closed
CORBA26-10 section 7.1.1 claims to define the "NVList structure", but doesn't CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-9 Implied IDL for interfaces in modules CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-8 IDL for ORB::resolve_initial_references CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-7 set_length operation of the DynSequence interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-6 the IDL include directive should introduce declarations into the namespace CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-5 DynUnion operations CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-4 Problem with IDL Context interface CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-3 Chapter 11, section 11.3.8.19 (WrongPolicy)" CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-2 Support for is_a for local interfaces CORBA 2.5 CORBA 2.6 Resolved closed
CORBA26-1 Section 11.3.8.16 - ambiguity CORBA 2.5 CORBA 2.6 Resolved closed
CORBA25-44 Nil return from resolve_initial_references() CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-43 Interpretation of time field in UtcT? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-42 There is no mapping for fixed types in the COM/CORBA mapping CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-41 COBRA problem using pragma prefix for modules CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-40 CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion) CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-39 Local interface is-a Object? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-38 Wither pseudo-objects? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-37 Missing TypeCode identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-36 Problem with resolution to 4285 and 4306 CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-35 get_interface() underspecified CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-34 Typo in UML for POA CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-33 DII create_request CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-32 Ambiguity in non_existent CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-31 String literal definition incorrect. CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-30 Inconsistent minor code for MARSHAL CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-29 Minor code CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-28 Missing POAManager identity CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-27 BAD_OPERATION needs minor code and completion status CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-26 Cross-reference refers to wrong section CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-25 Issue: Error in section 4.5.3.2 ORBInitRef CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-24 Section 10.5.22.2 what happens when conditions not met CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-23 Restrictions on native types CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-22 Clarification about include files and IDL compiler behavior CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-21 Definition of NamingContextExt interface in IDL of Appendix A not consisten CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-20 3.7.4 Forward Declaration (for interfaces) doesn't mention local CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-19 What is the semantics of the DataInputStream::read_*_array() operations? CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-13 Introduction of identifiers CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-12 Type redefinition in derived interface CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-11 PortableServer::ObjectId CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-10 core issue: unchecked narrow CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-18 #include issue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-17 DynValueBox::set_boxed_value should also raise InvalidValue CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-16 misleading wording in 10.5.22.2 Write Interface CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-15 Inconsistent text for unknown system exception CORBA 2.4.2 CORBA 2.5 Resolved closed
CORBA25-14 ForwardRequest from normal operations CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-3 POAManager::deactivate should not mandate ORB::shutdown implementation CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-2 POAManager::deactivate does not specify behavior for "reject" CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-1 Can a valuetype support multiple non-abstract interfaces via inheritance? CORBA 2.4 CORBA 2.5 Resolved closed
CORBA25-6 CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-5 ServantLocator preinvoke/ postinvoke semantics CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-4 Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-9 Container::lookup() ordering requirements CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-8 Section 2.1.7 of CORBA 2.3 and 2.4 CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA25-7 Legal IDL? CORBA 2.4.1 CORBA 2.5 Resolved closed
CORBA3-124 Issues related to CCM's XML descriptors: chapter 69.4.5.4 CCM 3.0 CORBA 3.0.2 Resolved closed
CORBA3-128 Creating IORs CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-127 There is no way to modify a POA's ORT and append to it CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-126 Interoperability of ObjectReferenceTemplate and Factory. CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-125 Object Adapter name problem in ORT CORBA 2.4.2 CORBA 3.0.3 Resolved closed
CORBA3-116 Productions 140, 141, 142 and 143 must be removed CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-115 paragraph 60.2.1 : There is two mistakes in keywords CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-123 Update Table 5-13 in the EJB Chapter of formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-122 Editorial issues in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-120 Remove section 4.4.1.4 in formal/02-06-65 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-119 create operation of AssemblyFactory interface CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-114 CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ... CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-118 69.8.2 Property File XML Elements CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-117 Typo (??) in chapter 61 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-121 Corrections in XML DTDs for packaging CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-106 components-ftf: connectevent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-105 components-ftf: registercomponent element CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-104 components-ftf: repository id in software package descriptor CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-103 IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-113 Issues related to CCM's XML descriptors: chapter 695.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-112 Issues related to CCM's XML descriptors: chapter 69.7.2.38 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-107 Issue regarding language mapping for keyless homes CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-102 Generic operations for subscribing/unsubscribing at publishing ports CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-108 simple type element of the property file issue CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-111 Issues related to CCM's XML descriptors: chapter 69.7.2.25 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-110 Issues related to CCM's XML descriptors: chapter 69.4.5.16 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-109 Issues related to CCM's XML descriptors: chapter 69.4.4 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-95 add a ClientInterceptor then create_POA() in the post_init() method? CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-94 CORBA::WrongTransaction and Interceptors CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-93 How do Portable Interceptors interact with Messaging callbacks CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-92 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-91 ORBInitInfo::arguments() underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-90 Exception handling in Interceptor initialization CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-89 Derived component supported interface restriction (formal/2002-06-01) CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-88 Local types allowed as valuetype state? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-87 Why does PollableSet::number_left() return unsigned short? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-86 Pollable in more than one PollableSet? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-85 Oneway operations should not generate sendc_ and sendp_ variants CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-84 DII sendc reply delivery underspecified CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-83 Bad example code in 22.11.4.3 CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-82 Messaging Poller generation is broken for interfaces with multiple inherite CORBA 1.1 CORBA 3.0.2 Resolved closed
CORBA3-81 name disambiguation for AMI interface & poller names is confusing CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-80 potential name clash with Messaging type-specific poller timeout argument CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-101 What ORBInitInfo operations are legal during pre_init() and post_init()? CORBA 3.0 CORBA 3.0.2 Duplicate or Merged closed
CORBA3-100 AMI vs abstract & local interfaces CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-99 Sending codeset context more than once? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-98 Getting reply svc ctxts from PersistentRequests CPP 1.0 CORBA 3.0.2 Resolved closed
CORBA3-97 Type code creation CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-96 Unfortunate CDR Encapsulation of ASN.1 Encodings CORBA 3.0.1 CORBA 3.0.2 Resolved closed
CORBA3-79 Messaging type-specific poller valuetypes should be abstract CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-78 Errors in definition of Messaging poller types CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-77 Messaging: bad example code for type specific poller CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-76 SyncScope for oneway invocations CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-75 Messaging time based policy enforcement? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-74 determining TimeT or UtcT value CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-73 Is a router allowed to pick any value in the range for a priority? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-72 Who is responsible for generating the TIMEOUT exception CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-71 Object::validate_connection() CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-70 Sloppy text in CORBA 3.0, 4.3.8.1 get_policy CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-69 Object::get_client_policy problem CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-68 Inconsistent definition of semantics of RebindPolicy? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-63 pragma prefix syntax CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-62 Avoiding Interceptors for colocated method requests CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-61 Codeset negotiation and the CODESET_INCOMPATIBLE exception CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-60 Replace deprecated anonymous type declarations? CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-59 reference_to_servant CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-67 BAD_INV_ORDER minor code 5 and 10 mean the same thing? CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-66 Serious backward compatibility issue in the PI CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-65 OpaqueValue/add_arg never mapped to languages CORBA 3.0 CORBA 3.0.2 Resolved closed
CORBA3-64 Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent CORBA 2.6.1 CORBA 3.0.2 Resolved closed
CORBA3-58 Valuetypes supporting forward declared interfaces CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-57 Inconsitent exception handling with find_POA & unknown_adapter CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-56 IOR processing performance CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-47 Wide string in reply before codeset was negotiated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-46 conflict between CORBA specification and C++ mapping (_this method CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-51 Codeset negotiation requires clarification CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-50 The whole negotiation thing should be removed, Unicode should be mandated CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-53 discussion on the create_union_tc operation could use some clarifications CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-52 IDL inheritance issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-49 interaction of #pragma and typeid, typeprefix CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-48 IPv6 in corbaloc URLs CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-55 GIOP version in replies CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-54 definition of the TypeCode interface (4.11.1) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-43 Issue with chunking CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-42 TypeCode indirections CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-41 Chapters 13.10.1.9, and 13.10.1.12 -- issue CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-38 Alignment for empty sequence? CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-37 CORBA 2.5 and Portable Interceptors mismerged CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-36 Detecting Recursion in Other Interceptors CORBA 2.5 CORBA 3.0.2 Resolved closed
CORBA3-27 X/Open Codeset registry is obsolete needs to be replaced CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-26 Clarify that each interception point executes in a distinct logical thread CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-45 11.3.2.1 Processing States (end of second paragraph and third paragraph CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-44 Potential problem using BiDir GIOP and codeset conversion service context CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-40 GIOP 1.2 encoding of wstring CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-39 ORBs using BOMs for UTF-16 (closely related to issue 4008) CORBA 2.6 CORBA 3.0.2 Resolved closed
CORBA3-29 Problem with CSIv2 and GIOP LocateRequest CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-28 21.8.1 register_initial_reference CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-33 rep_id() operation on Object? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-32 Repository ID in nil references CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-31 Note on page 15-43, OBJECT_FORWARD_PERM CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-30 Interpretation of defined ServiceConfigurationSyntax constants is incomplet CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-35 CORBA components requires new GIOP version? CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-34 TypeCodes for custom marshaled valuetypes CORBA 2.4.2 CORBA 3.0.2 Resolved closed
CORBA3-25 Stateful boolean causes all CSI mechanisms to operate the same way. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA21-80 Bug in C++ NVList mapping CORBA 2.0 CORBA 2.1 Resolved closed
CORBA21-79 OMG C++ Mapping: Implicit Conversion Operators CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-78 Persistent Any values CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-77 DII and DSI are useless with current Any CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-76 iterating over Any primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-75 decompose Any into constituent primitives CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-69 Rethrowing exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-72 Return value of operator[] for array var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-71 Taking T out of T_var CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-70 Freeing inaccessible storage for T_var as out parameter CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-74 RTTI vs. _narrow for exceptions CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-73 Implementation of parameter passing for T_var types CPP 1.0b1 CORBA 2.1 Resolved closed
CORBA21-68 IDL grammar CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-67 8.1 Role of the Basic Object Adapter Para 1 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-66 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-65 7.4 ORB Initialization Last Paragraph - objection CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-64 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-63 7.2.4 Equivalence Checking Operation Paragraph 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-62 7.2.1 Determining the Object Implementation and Interface CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-61 7.1 Converting Object References to Strings Para 3 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-60 6.5.6 Repository Paragraph 4 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-59 6.5.4 Container Last Paragraph - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-58 6.4.3 Interface Objects Paragraph 2 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-57 6.4.3 Interface Objects Paragrapg 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-56 6.3.1 Managing Interface Repositories CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-55 5.3.2 Registering Dynamic Implementation Routines Para 1- comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-54 5.2 Explicit Request State: ServerRequest Pseudo Object CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-53 4.6.5 delete_values Paragraph 1 - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-52 4.3.3 get_response CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-51 4.2.3 invoke CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-50 4.1.2 Memory usage, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-49 4.1 Overview, Paragraph 3, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-48 3.15.2 Object Non-Existence, Para 1, editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-47 3.10.3 Raises Expressions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-46 3.9 Exception Declaration CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-45 2.5 Structure of an Object Adapter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-44 2.1 Structure of an Object Request Broker CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-43 1.2.2 Requests Paragraph last - editorial CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-42 CORBA2.0, 1.2.2 Paragraph 2 - comment CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-41 Scope of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-40 Unions with enum as discriminator type CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-39 _is_a with CORBA::Object as input parameter CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-38 Unqualified names in scopes CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-37 Usage of standard exceptions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-36 Ambiguity in DII and DSI CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-35 Request reuse CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-34 Whether unions carry exact discriminant information CORBA 1.2 CORBA 2.0 Resolved closed
CORBA21-33 Recusive Type Definitions CORBA 1.2 CORBA 2.0 Resolved closed
CORBA3-11 Detail lacking in when request interceptors are called CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-10 How correlate requests and replies when using pollable sets? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-18 no way to register value factory from ORB initializer CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-17 ORB accessor on POA? CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-16 RoutingPolicy issue CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-24 ORB::shutdown vs. ORB::destroy CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-23 Encodings of Sequences of Certificates are not standard. CORBA 2.4.1 CORBA 3.0.2 Resolved closed
CORBA3-20 Portable interceptors and invocation timeouts CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-19 Missing minor codes in Messaging Chapter CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-22 wchar endianness CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-21 No portable way to turn IOR components into object-reference policies CORBA 2.4 CORBA 3.0.2 Resolved closed
CORBA3-15 Portable Interceptors / register_initial_reference() CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-14 Policy Management in Portable Interceptors CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-9 ORBInitInfo needs the ORB CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-8 PI needs the ORB to be available in IDL CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-7 Question about routing policies CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-6 Portable Interceptors: object_to_string, string_to_object CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-5 Implementing proper handling of CloseConnection CORBA 2.3.1 CORBA 3.0.2 Resolved closed
CORBA3-13 Overriding POA policies CPP 1.1 CORBA 3.0.3 Resolved closed
CORBA3-12 Portable Interceptors: 9.2.3 text describing `Arguments' CPP 1.1 CORBA 3.0.2 Resolved closed
CORBA3-2 No way to detect that ORB has outstanding deferred synchronous requests CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-1 constant decls broken CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA3-4 scheme name for IORs CORBA 2.3 CORBA 3.0.2 Resolved closed
CORBA3-3 issue with ForwardRequest exception in POA CORBA 2.2 CORBA 3.0.2 Resolved closed
CORBA21-31 Page 13C-36: Editorials CORBA 2.0 CORBA 2.1 Resolved closed
CORBAE-17 More wrong references in chapetr 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-16 Wrong references in chapter 11 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-13 CORBA/e and get_interface CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-12 Section: 9.2.1.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-18 Section: 8.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-15 Section: 11.4.1 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-14 Section: 18.2.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-11 Section: 6.2.12 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-10 The removal of static any from micro CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-9 Servant_to_id clarification CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-8 Section: 11.2.3 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-7 document style and use of headings CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-6 Section: 6.2 CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-5 Add table that captures the features that are in/out of CORBA/e CORBAe 1.0b1 CORBAe 1.0 Resolved closed
CORBAE-4 state machine diagram CORBAe 1.0b1 CORBAe 1.0 Resolved closed
C2WSDL12-8 Section: 1.2.x (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-7 Section: 1.2.11 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-6 Section: 1.2.7.5 and 1.2.7.6 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-10 Section: 1.2.6.1 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-9 Section: 1.2.7.6 (CorbaToWsdl) C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-5 Section: 1.2.7.6 Multi-dimensional arrays in IDL C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-4 Section: 1.2.7.6 page 1-14 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-3 Section: 1.2.7.6 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
C2WSDL12-2 Section: 1.2.7.6 C2WSDL 1.1 C2WSDL 1.2 Resolved closed
CORBA24-150 Validity of object references CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-149 An ORB should not accept an IOR with no usable profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-148 Should an ORB be allowed to drop non-standard profiles CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-163 selected_profile_index origin CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-162 Absence of Wide Character Code Set CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-161 ORB throwing exception if it finds unknown service context CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-160 Wrong minor code specified in Chapter 13 CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-144 Table 13-1 needs update for valuetypes & abstract interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-143 marshalling of null values unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-142 CDR Encapsulation Issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-152 Preserving unencapsulated information CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-151 Indirection for value types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-147 chunked value encoding: CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-146 CORBA 2.3.1 missing text describing the response_expected field CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-145 Supporting TAG_MULTIPLE_COMPONENTS CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-157 GIOP version and CloseConnection CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-156 Valuetype in anys. Unmarshaling problem? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-153 Transferring Java exception reason string across the wire CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-159 Nesting depth in valuetype end tags CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-158 Valuetype encoding grammar in 15.3.4.7 is wrong CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-155 Marshaling fixed-point decimal types CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-154 IIOP 1.2 Early Reply message in presence of fragmented Request CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-141 Minor code allocation inconsistency CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-139 .Passing the interface repository ID of the method in IIOP CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-138 Chunked GIOP marshalling for variable-length types CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-137 TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-136 Optimization of LOCATION_FORWARD replies CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-135 Compacting GIOP Requests by hashing down operation names CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-140 GIOP encoding of nil Abstract Interface is unspecified CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-134 Compacting GIOP Messages by using templates CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-133 Compacting GIOP messages by using indirections CORBA 2.2 CORBA 2.4.2 Resolved closed
CORBA24-132 Use of the type ComponentHome CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-131 USING Components::Enumeration CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-130 destroy() for local objects CPP 1.1 CORBA 2.4 Resolved closed
CORBA24-129 New IDL keywords CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-128 Implementation of get_component CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-127 CORBA IR METAMODEL CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-126 Is the ccm_home method shown in Table 8-1 a typo? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-125 How is CCMHome::get_home_def mapped to EJB operations? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-124 What's the return type of CCM mappings of EJB finder and creator methods? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-123 Do EJB-mapped attributes go to the ComponentDefault interface? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-122 CCM Issue: Is CCMObject::remove intended to be available to the CCM client? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-168 Small optimization for the GIOP header CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-167 interop issue: CodeSets service context in GIOP 1.0 request CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-166 Version and byte order changes when fragmenting messages (interop) CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-165 Issue 2 -- resulting from UK comment UK-5: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-164 Issue 1 -- resulting from Japanese comment JPN-009E: CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-171 wchar alignment in GIOP 1.2 CORBA 2.4 CORBA 2.4.2 Resolved closed
CORBA24-170 Is padding necessary for empty Reply body? CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-169 GIOP _get_domain_managers ambiguous CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-121 CCM Issue: How are standard EJB exceptions mapped into the CCM View CPP 1.1 CORBA 2.4.2 Resolved closed
CORBA24-120 Should Components::Enumeration be an IDL interface or an IDL abstract value CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-119 CCM Issue: Is a home needed? CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-118 Components Issues - Interface Repository ptc/99-10-03 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-117 Components Issues - Chapter 61 ptc/99-10-04 CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-116 implementing import for C++ CORBA 2.3.1 CORBA 2.4.2 Resolved closed
CORBA24-115 Policies not locality-constrained? CPP 1.0 CORBA 2.4 Resolved closed
CORBA24-114 Locality-constrained objects CORBA 2.2 CORBA 2.4 Resolved closed
CORBA24-113 Locality constrained objects + externalization CORBA 2.2 CORBA 2.4 Closed; No Change closed
CORBA24-104 Nested Recursive Structs Legal in 2.3.x? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-103 incomplete rules for forward declaration of structs/unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-107 read_fixed() and write_fixed() methods missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-106 Initializers and user exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-105 IDL: Clashes with inherited identifiers CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-112 Should POA spec examples use string_to_ObjectId? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-111 Values for CORBA::ARG_IN,... not defined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-110 module IOP_N needs a real name CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-109 "omg.org" prefix missing from interceptor specification and its reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-108 ORB ID accessor CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-85 ValueMemberDef section omitted from CORBA 2.3.1 spec CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-84 Inheritance description incorrect CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-83 ORB mediation for servant managers, references for servant managers? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-92 Policy Management in the ORB core CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-91 Some problems CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-90 ORB shutdown vs destroy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-102 With reference to forward declarations of structs and unions. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-101 There is inconsistency in the POA.IDL and description in section 11.3.8.19 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-100 description of unknown_adapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-99 reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-98 Missing exception for activation CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-97 AbstractBase not declared. CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-82 POA deactivate_object description is ambiguous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-81 how are valid ORBids determined CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-80 POA namespace and ORB ID CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-94 servant_to_id versus servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-93 ORB::shutdown underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-87 Incorrect use of negative fixed scale CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-86 is_equivalent and policies CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-89 POA servant_to_id inconsistent with servant_to_reference CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-88 Valuetypes with multiple interfaces CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-96 Pragma version 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-95 Non-escaped keywords in published IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-79 return type of TypeCode::fixed_scale() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-78 POA status during destruction is unclear CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-77 Problem with valuetype parameter copying CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-64 Ordering issues in the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-63 Efficient construction of Any types w/o DynamicAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-68 Does a value in a valuebox make sense? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-67 Semantics for DynAny::equal underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-73 Definition of COMPLETED_NO needs to be clarified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-72 Minor glitch about forward declared things CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-70 Editorial mistake in IDL chapter CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-69 Can native be used in constructed IDL types? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-76 response_flags in interop draft CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-75 symbolic constants for minor exception codes CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-66 Inheritence table 3-10 wrong? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-65 poll_response() CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-71 #pragma rules are too restrictive CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-74 valuetype factory inheritence? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-62 special-casing TypeCode is unnecessary CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-165 CDR encoding for fixed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-166 LocateRequest and LocateReply messages CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-167 profile ids & component ids CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA23-168 Need clarification on GIOP::TargetAddress CORBA 2.3 CORBA 2.3.1 Resolved closed
CORBA24-51 Errors in published IDL for CORBA module CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-50 Non-standard system exceptions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-49 Use of Principal in GIOP Module erroneous CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-56 valuebox and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-55 OMG wchar <-> COM WCHAR in CORBA 2.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-61 local interfaces and the DII CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-60 servant_to_id CORBA 2.3.1 CORBA 2.4 Closed; No Change closed
CORBA24-54 What is the TypeCode for ValueBase? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-53 Do valueboxes have factories? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-52 DynAny & abstract interfaces don't mix! CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-48 create_POA and inactive state? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-47 value type substitutability CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-46 OMG IDL Syntax and Semantics issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-45 TypeCode issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-59 IDL scoping rules CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-57 null & void TCs and DynAny CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-58 Bug in 11.3.7.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-37 Problem with the "Special scoping" rules in 3.15.3 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-36 Meaningless sentence on page 3-11? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-32 Type Code Section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-31 Minor codes for Standard System Exceptions in Chapter 8 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-30 Minor codes for Standard System Exceptions in Chapter 5 missing CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-34 IDL and C++ relationship CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-33 PIDL vs Local CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-40 Missing "abstract" in forward declaration CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-39 The algorithm for TypeCode::equivalent in 10.7.1 was not updated CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-44 Editorial glitch in DynAny::destroy, section 9.2.3.6 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-43 What is the NO_RESPONSE exception good for? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-29 General Exception Question CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-28 Exception section issue CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-42 Section 7.6: IDL context housecleaning CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-41 Question about IDL \uxxxx escape format CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-35 Preprocessing of IDL CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-38 Codeset conversions and unions CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-17 Use of incomplete recursive TypeCodes underspecified CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-16 Semantics of DynAny with alias TypeCodes CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-15 URLs interact poorly with code set selection CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-12 DataInputStream specification is inefficient for Java CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-11 POA exception minor codes CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-10 Wchar as discriminator in union CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-23 Problem with text of POAManager::deactivate() CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-22 CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-19 creation of arguments to TypeCode creation ops CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-18 DynFixed editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-27 CORBA 2.3 Editorial issue for TypeCodes & abstract_interface CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-26 Editorial issue for CORBA 2.3, 1.3.8.20 CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-9 CORBA 2.3: minor editorial issue CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-8 chapter 3 and recursion CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-25 Component ids in 13.6.2.2 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-24 (CORBA Core) Data streams missing arrays of long double CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-14 Why are Standard Exceptions defined in IDL chapter? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-13 What is the RepId of Object? CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-21 formal/99-08-01.txt missing pragmas CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA24-20 CORBA::ORB::RequestSeq definition obsolete CORBA 2.3.1 CORBA 2.4 Resolved closed
CORBA23-84 Incorrect IDL is section 5.5.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-83 RMI style repository ID hash code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-82 forward declaration in ptc/98-10-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-4 $issue.summary CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-3 mixing giop versions CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-92 UNIQUE_ID and ServantActivator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-91 Clarification on IdUniquenessPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-95 New "opaque" data type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-94 DynAny::equal operator issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-93 sharing valuetypes across Anys CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-86 DynAny.insert_valuetype shoud be insert_val CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-85 confusing rules for operations on Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-7 ambiguity in wstrings having a Unicode escape sequence CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-6 POA: false placement of paragraph CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-5 OBV interface support inconsistencies CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-88 activate_object_with_id and exceptions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-87 Repository ID for Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA24-2 interop issue: what system exceptions may be raised on GIOP 1.0? CORBA 2.3 CORBA 2.4 Resolved closed
CORBA24-1 The syntax for stringified IORs in section 13.6.6 CORBA 2.3 CORBA 2.4 Resolved closed
CORBA23-90 deactivate_object asymmetry CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-89 ORB::shutdown again CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-70 Inconsistent spellings of "policy" related identifiers: CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-69 IR Changes in 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-63 Interceptors broken CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-62 clarification and bug in InterfaceDef::FullInterfaceDescription CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-61 Try to define obligatory and optional parts of the CORBA specification. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-60 Application Interface issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-59 Use UNICODE Character set CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-81 LocateReply body alignment issue CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-80 POA issue, section 11.3.8.10 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-79 POA that has IdAssignmentPolicy=SYSTEM--portability problem CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-76 Scope of SendingContextRunTime service context CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-75 Need to specify exception for abstract interface error CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-74 Error in IRObject definition in 98-12-04 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-73 What use is CORBA::exception_type? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-72 Inconsistent Definition of Flags type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-71 CORBA::Object::ping ? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-78 Can an any with a tk_null or tk_void TypeCode be encoded with CDR? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-77 omg.org prefix not well specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-68 What value type does ValueDef"s base_value() return? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-67 Inheritance of value types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-66 Problems in Chapter 5 IDL CORBA 2.2 CORBA 2.3 Closed; No Change closed
CORBA23-65 POA Construction Policy. CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-64 another problem with IDL specification section 3.9.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-58 Issue - no PIDL, just language bindings CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-57 Grammar section 3.9.2 missing "float" rules, and other problems CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-45 No description for NativeDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-44 Errors in figure 10-2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-43 Signature of unmarshal method is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-54 Value base and the IFR CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-53 Clarifications needed in section 5.2.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-42 Clarify meaning of no IDL initializers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-41 Misleading text in section 3.2.5.2 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-56 Calling get_response twice? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-55 Forward-Declared Interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-47 No description for ValueBoxDef CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-46 is_a description is wrong CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-50 RMI Repository ID missing from section 10.6 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-49 Text was inserted in wrong place CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-52 Clarify text in section 15.3.7 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-51 Error in text describing TypeCode interface CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-48 Error in ValueDef IDL CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-28 Core uses both "standard" and "system" exception terminology CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-27 create_policy specification needs to be completed CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-26 Need namespace for Policy Type CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-40 Codebases with multiple URLs CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-39 Supporting multiple abstract interfaces CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-38 Names of Data*Stream methods CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-25 Scoping resolution for member names CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-24 Typo in POA CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-23 void * in DII Chapter CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-30 is_a underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-29 Local operations on CORBA::Object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-31 uses of recursive_tc CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-37 Custom Marshaling clarification CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-36 Missing minor code CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-33 Custom marshalling & AbstractBase CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-32 Sequences of recursive structs/unions CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-35 POA SINGLE_THREAD_MODEL description ambiguous CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-34 POA threading policies CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-22 Exception for abstract interface inheritance CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-21 long double problem? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-6 Lifetime of ORB and validity of ORB pointe CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-5 Semantics of system exception completion_status CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-17 What does interface substitutability mean in CORBA? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-16 Which OBV initialiser to run is under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-12 Handling of minor codes for standard exceptions underspecified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-11 page 3-47: Identifiers CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-14 Missing equality for DynAny CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-13 set_servant_manager CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-10 Nested scopes CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-9 Multiple paths to a recursive sequence typecode CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-8 Change to IDL for anonymous types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-7 DynStruct::get_members needs exception CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-20 Recursive exceptions? CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-19 InconsistentTypeCode exception in CORBA 2.3 CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-18 Recursive IDL types CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-15 DynUnion::member() CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-4 resolve_initial_references under-specified CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-3 Domain Manager related specification shortcoming (02)-ConstructionPolicy CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-2 Domain manager related specification shortcoming(s) (01) CORBA 2.2 CORBA 2.3 Resolved closed
CORBA23-1 Operation to add to CORBA::ORB pseudo-object CORBA 2.2 CORBA 2.3 Resolved closed
CORBA22-133 marshalling service context CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-132 Alignment and offsets in the presence of fragmentation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-131 Changes to and strategy for 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-107 Type ids in OBJECT_FORWARD return message CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-111 Use of dynamic ports CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-110 CORBA::Object::non_existent CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-109 Correct IIOP marshalling of union TypeCodes CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-108 LOCATION_FORWARD byte alignment CPP 1.0b1 CORBA 2.2 Resolved closed
CTS2F2-82 CTS2 XML file appears to contain EA proprietary elements CTS2 1.0b1 CTS2 1.0 Resolved closed
CORBA22-140 Typos in PIDL to C++ mappings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-139 Typo in C++ mapping CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-138 C mapping for list_initial_services is incorrect CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-137 Defintion of Any CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-136 Any extractor signature problem CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-135 Missing Any inserter CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-134 IIOP object pointer resetting CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-128 Additional enumeration to the ReplyStatusType CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-127 Additional Requirement for GIOP 1.2 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-126 Clarification on IIOP2.1 12.3.2 fixed point type representation needed CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-130 Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-129 IIOP marshalling of empty strings CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-115 Problem with GIOP CancelRequest when fragments are used CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-114 Transport Level Bridge CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-119 IDL Type Extensions: wstring CDR encoding issue CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-118 IDL Type Extensions: wchar and wstring CDR encoding CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-123 1.0 backward compat (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-122 1.0 backward compat (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-113 IORs and identifying Object Keys CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-112 Callbacks in IIOP CPP 1.0b1 CORBA 2.2 Resolved closed
CORBA22-121 Fragment improvements (2) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-120 Fragment improvements (1) CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-117 Type extensions char code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-116 Type Extensions and code set negotiation CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-125 Issue with service context CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-124 CloseConnection messages CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-96 union typecode (02) CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-95 locally constrained CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-94 IDL types are ambiguous with inheritance CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-100 Question about typecode creation CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-99 #pragma processing CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-106 CORBA::Contained::describe() underspecified CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-98 Ambiguity in non_existent() specification CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-97 Appendix B lists incorrect CORBA Components IDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-103 Trader constraint language and international characters CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-102 defined_in member of ModuleDescription for top-level module CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-101 Inheritance of Exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-93 RIDs CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-92 Containers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-105 Incorrect definition of "object type" CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-104 Resetting #pragma prefix? CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-91 Proposed IFR exceptions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-90 TypedefDef issue CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-89 CORBA 2.1 IR Structdef typo CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-85 Issue with ObjectId_to_string and string_to_ObjectId CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-84 Bug in the 2.1.spec for IDL unions CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-83 Figure 2-2 in CORBA 2.0 and CORBA 2.1 CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-82 Octet and enum constants CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-81 Non ASCII alphabetics in IDL identifiers CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-80 Native types with respect to typecodes, DII, DSI,Interface Reposit. CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-79 TypeCode equality CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-88 Minor bug in 2.1 spec CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-87 Inheriting exceptions in IDL CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-86 Inclusion of standard exception CORBA 2.1 CORBA 2.2 Resolved closed
CORBA22-75 Syntax for basic types must be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-74 create_exception() is declared outside any interface scope CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-73 TCKind enum should be updated CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-78 Do identifiers and keywords clash if they differ in case? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-77 Section 3.7.2: take new IDL type extensions into account CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-76 Section 7.8: editorial CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-70 sec 17.7.1: IDL for interface request doesn"t match C++ mapping CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-69 Sequence parameter specified is ignored CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-68 request() should be added to IDL (section 17.13.2) CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-67 Section 16.7: only C++ mapping defines string_free and string_dup CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-72 No defined value for OBJECT_NIL CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-71 Section 7.2: get_implementation function CORBA 2.0 CORBA 2.2 Closed; No Change closed
CORBA22-64 "service"~~operation or interface? CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-63 What exactly is a request CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-61 Scope and use of prefix pragma in IDL-style repository IDs CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-60 Terminology consistency CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-52 6.6.4 Pragma Directives for RepositoryId Para 1 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-51 6.6.1 OMG IDL Format Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-56 6.7.2 TypeCode Constants Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-55 6.7.1 The Type Code Interface Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-59 Enums and enumerators CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-58 Internationalization CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-54 6.7.1 The TypeCode Interface All Paragraphs - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-53 6.7 TypeCodes Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-66 limited-length strings CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-65 Question about IDL grammar CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-57 CORE spec reference CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-62 inherit vs. include CORBA 2.0 CORBA 2.2 Resolved closed
CORBA22-50 6.5.22 InterfaceDef Paragraphs 7 and 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-49 6.5.22 InterfaceDef Paragraph 6 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-48 6.5.20 AttributeDef Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-38 6.5.4 Container Paragraph 6 - editorial CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-37 6.5.4 Container Paragraph 5 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-36 6.5.4 Container Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-35 6.5.3 Contained Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-43 6.5.4 Container Paragraph 15 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-42 6.5.4 Container Paragraph 12 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-46 6.5.10 StructDef Last paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-45 6.5.8 ConstantDef Interface Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-40 6.5.4 Container Paragraph 10 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-39 6.5.4 Container Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-44 6.5.6 Repository Paragraph 4 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-47 6.5.11 UnionDef Last Paragraph - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-41 6.5.4 Container Paragraph 11 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-34 6.5.3 Contained - Paragraph 7 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-33 6.5.3 Contained Paragraph 2 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-32 6.5.2 IRObject Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-22 4.6 Context Object Operations, Para 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-21 4.2.2 add_arg Paragraph 5-comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-24 4.6.2 set_on_value Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-23 4.3.1 sen3 - comment 23 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-28 4.6.4 get_values Paragraph 5 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-27 4.6.4 get_values Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-26 4.6.4 get_values Paragraph 2 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-25 4.6.3 set_values CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-18 4.1.1 Common Data Structures, Paragraph 6, comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-17 Interface for managing interceptors is missing CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-31 6.4.3 Interface Objects Paragraph 3 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-30 4.6.7 delete Paragraph 4 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-20 4.2.1 create_request Paragraph 8 - comment CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-19 4.1.3 Return Status and Exceptions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-29 4.6.5 delete_values Paragraph 3 - objection CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-4 Do typecodes need literal constant representations in all mappings? CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-3 Missing info about the semantics of ORB_init and OA_init CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-14 Similar structure to IR::Identifier CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-13 Pseudo-IDL identifiers differ by case only CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-8 Typecodes for recursive sequences CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-7 lookup() questions CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-10 DSI and oneway operations CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-9 ServerRequest::op_def() CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-6 Interface Repository Error Handling CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-5 CORBA::InterfaceDef name collision CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-12 Apparent error in CORBA 2.0 Interoperability CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-11 Repository IDs CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-16 Portability and the #include directive CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-15 Recursive sequence TypeCodes CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-2 IFR: union elements associated with case labels CORBA 1.2 CORBA 2.2 Resolved closed
CORBA22-1 Inheritance of describe_contents() CORBA 1.2 CORBA 2.2 Resolved closed
CTS2F2-73 Missing documentation on StatementSubject CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-72 CTS2: Change cardinality of defaultLanguage from [0..1] to [0..*] CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-74 Introduction section about conventions and notation needs to be in all modules CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-76 Exception listed twice in EntityDescriptionQueryService CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-75 EntityDescriptionQueryService knownCodeSystem type is incorrect CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-77 CTS2: Delta stereotype is opposite of isQuery CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-81 MatchValueFormatException missing from documentation CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-80 Boolean is a UML data type and shouldn't be part of the model CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-79 Missing ValidationResponse class CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS2F2-78 String is a UML dataType and cannot be included as part of the model data types CTS2 1.0b2 CTS2 1.0 Resolved closed
CTS211-12 CTS2: Additional options needed for Entity Read Query CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-11 CTS2: Format and language resolution precedence not described for REST CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-8 CTS2: Include the signature for the CLONE operation in Change Set CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-7 CTS2: Extensible Directories - Allow directories to be extended CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-15 CTS2: Rest signatures missing for ValueSetDefinitionResolution "resolveAsCompleteSet" function CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-14 CTS2: REST language signature "referencelanguage" needs to be more REST compliant CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-19 CTS2: CodeSystemCatalogEntry xml schema missing "hasOntologyLanguage" and "includes" elements CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-18 CTS2: Map Entry "MapFrom" and "MapTo" need optional description element CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-9 CTS2: No ROA link to value set resolution of current value set CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-17 CTS2: ValueSetDefinition REST signatures need to include shortcuts for tags CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-16 CTS2: Documentation for value set resolution needs to be corrected. CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-10 CTS2: "versiontag" has wrong type in MapVersion schema CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-13 CTS2: Redirect behavior isn't clear for uri reads CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-65 Create/Update in WADL use the wrong HTTP methods CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-64 CTS2: StructuralProfile - Statement and/or MapEntry CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-61 CTS2: currentVersion not typed in MapCatalogEntry CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-60 CTS2: ScopedEntityName.name type is too strong CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-63 CTS2: Message Header Documentation Missing CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-62 CTS2: Inconsistent element/complexType declarations CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-68 CTS2: AssociationQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-67 CTS2: ConceptDomainBindingReadService QueryControl parameters CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-66 CTS2: AssociationQueryService 'getAllSourceAndTargetEntities' wrong input parameter CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-70 CTS2: Concept Domain Catalog Query Service missing description CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-69 CTS2: Service map catalog typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-71 CTS2: section 1.1.2.1 Class CodeSystemCatalogEntryDirectory typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CDSS-10 Evaluation only conformance profile CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-9 EvaluationRequest and IterativeEvaluationRequest content ordering CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-8 Consider RESTful service specification CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-7 Security Issues CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-1 DSS: single targetNamespace "urn:dss.hssp.org" CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-4 Too many defined elements within one package name CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-3 Non UTF-8 character in schema comments CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-5 Use of xs:any data type for payload CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-2 All Defined Operations CDSS 1.0b1 CDSS 1.0 Resolved closed
CDSS-6 Use of "Exception" as a class name in the model CDSS 1.0b1 CDSS 1.0 Resolved closed
CMMN-19 The XML document dtc-13-11-05.xsd is NOT valid (1 errors) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-18 Figure 11 CMMN 1.0b1 CMMN 1.0 Resolved closed
CTS211-26 CTS2: Parents URI needed in EntityDescription CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-25 CTS2: CodeSystemCatalogQueryService (resolve and resolveAsList) parameter 'directory' type incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-31 CTS2: Complete binding operation missing from specification CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-30 CTS2: URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-29 CTS2: IteratableResolvedValueSet and ResolvedValueSet have inconsistent element names CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-28 CTS2: CTS2Exception doesn't match documentation CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-27 Need an optional attribute to carry the OID in addition to the URI CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-22 AssociationDirectory needs "associationID" CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-21 CTS2: Make "associationID" optional CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-32 CTS2: Filter PropertyReference documentation needs clarification CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-20 CTS2: Include a depth indicator for AssociationGraph CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-24 CTS2: ConceptDomainCatalogQueryService (resolve) parameter "directory" type incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-23 CTS2: URIAndEntityName XSD representation does not match UML CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-50 AssociationMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-49 AssociationHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-48 AssociationReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-47 AdvancedAssociationQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-59 EntityDescriptionMaintenanceServices WSDL changes CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-58 EntityDescriptionQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-46 EntityDescriptionReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-45 CodeSystemVersionCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-54 ConceptDomainBindingMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-53 ConceptDomainBindingQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-52 BaseImport/ExportServices WSDL correction CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-57 EntityDescriptionTransformService WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-56 ConceptDomainCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-51 AssociationTransformServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-55 ConceptDomainCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS211-1 CTS2: Possible issue with CTS2 URI CTS2 1.0b1 CTS2 1.1 Resolved closed
CTS211-5 CTS2: "documentURI" attribute description in ResourceVersionDescription is incorrect CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-2 CTS2: "entityType" description text incorrect - needs to be updated CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-4 CTS2: "SourceAndNotation" should be made optional in resource version CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-3 CTS2: referencedEntity in Value Set Definitions should include an optional description CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-6 CTS2: DocumentURI shouldn't be mandatory in ResourceVersionDescription CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-4 CTS 2: SortCriteria contains PropertyReference CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-3 CTS 2: Change 'applicableContext' cardinality in ConceptDomainBinding (XSD) to 0..1 CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-2 CTS2: Move 'bindingQualifier' in ConceptDomainBinding (XSD) to an Element CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-1 CTS 2: Change 'boundValueSet' cardinality in ConceptDomainBindingDirectoryEntry (XSD) to 1..1 CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-10 BaseMaintenanceService.updateChangeableMetadata parameters CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-9 Changeable/ChangeDescription typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-5 CTS 2: FilterComponent is a PropertyReference and contains a MatchAlgorithm reference CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-6 AnonymousStatement target cardinality CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-8 ChangeDescription stereotypes CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-7 AnonymousStatement typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS211-37 CTS2: Resource content filtering for Query CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-36 CTS2: WADL Graph URLs need to change to better reflect AssociationDirectory as input CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-34 CTS2: MapTargetList and MapTargetListList need a 'Message' wrapper for REST calls CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-33 CTS2: Cardinality of includesResolvedValueSet wrong on ResolvedValueSetHeader CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-41 CTS2: ValueSetDefinitionResolution 'resolve' method has incorrect return type CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-39 CTS2: Association derivation should be optional and not have a default CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-35 CTS2: MapEntry Read and Resolution need WADL 'byURI' REST signatures CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-38 CTS2: AssociationDirectory needs the derivation CTS2 1.0 CTS2 1.1 Resolved closed
CTS211-40 Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv) CTS2 1.0 CTS2 1.1 Resolved closed
CTS2F2-21 SpecificEntityList incorrectly supertyped CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-20 Designation and Note have inconsistent pattern in schema CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-22 NamedEntityDescription and AnonymousEntityDescription incorrectly defined in schema CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-12 UpdateCodesystemCatalogEntry.usedOntologyEngineeringTool optionality CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-11 Core spec typos CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-24 Documentation issue on ProfileElement CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-23 ImplementationProfiles.ProfileElement not RESTful CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-13 CodesystemCatalogEntry.usedOntologyEngineeringTool CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-19 UpdateEntityDescription is missing elements and does not support "optparam" semantics CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-18 EntityDescriptionQueryService lacking supportedVersionTag CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-16 ChangeSet element doesn't have a MSG header CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-15 AssociationGraph p45 typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-17 EntityDescriptionReadService lacking local variables CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-14 Entity description services p20 typo CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-38 Refactor inline XSD types from WSDLs (SOAP PSM) CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-37 ResolvedValueSetReadService and QueryService omitted from spec CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-36 ResolvedValueSetDirectory misnamed and mistyped CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-35 AdvancedAssociationQuerySerivce not in WADL (REST PSM) CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-34 Association Information Model derivation and derivationReasoningAlgorithm CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-33 Typo on page 11 of statement information model CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-32 Typo on page 3 of Statement Information model CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-31 Statement needs an identifier CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-42 CodeSystemVersionCatalogReadServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-41 CodeSystemCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-40 CodeSystemCatalogHistoryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-39 CodeSystemCatalogMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-30 ConceptDomainbinding needs an identifier CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-29 BaseQueryService filter property needs to be individualized CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-25 XML Schema for BaseService has wrong type for supported Profile CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-44 CodeSystemVersionCatalogMaintenanceServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-43 CodeSystemVersionCatalogQueryServices WSDL corrections CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-28 Changeable changeDescription cardinality constraint CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-27 EntityReferences - URIAndEntityNameList CTS2 1.0b1 CTS2 1.0 Resolved closed
CTS2F2-26 Remove CONCEPT_DOMAIN_BINDING from ReferenceType CTS2 1.0b1 CTS2 1.0 Resolved closed
COAS-35 COAS operations that return ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-32 Pg. 193 Under section - D.3 Secure Interoperability Concerns COAS 1.0b1 COAS 1.0 Resolved closed
COAS-31 Pg. 208 Under section - 12.7 AbbreviatedCorba.idl COAS 1.0b1 COAS 1.0 Resolved closed
COAS-34 Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio COAS 1.0b1 COAS 1.0 Resolved closed
COAS-33 Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram COAS 1.0b1 COAS 1.0 Resolved closed
COAS-29 Pg. 145-152 Under section - 3.8.1-3.8.17 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-28 Pg. 141 Under section - 3.7.1 General COAS 1.0b1 COAS 1.0 Resolved closed
COAS-26 Pg. 129 Under section - 3.5.4 Sequence Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-25 Pg. 120 Under section - 3.4.2 Supporting Types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-24 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-36 typedefs for TimeStamp and TimeSpan that are never used COAS 1.0b1 COAS 1.0 Resolved closed
COAS-27 Pg. 133 Under section - 3.6.1 Genera COAS 1.0b1 COAS 1.0 Resolved closed
COAS-30 Pg. 153 Under section - 3.9 Conformance Classes COAS 1.0b1 COAS 1.0 Resolved closed
COAS-17 interfaces are presented in alphabetical order and not in logical order COAS 1.0b1 COAS 1.0 Resolved closed
COAS-16 Pg. 108 Under section - 3.3.3.13 FederatedAccess COAS 1.0b1 COAS 1.0 Resolved closed
COAS-20 Pg. 70 Under section -3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-19 Pg. 5 Under section - 3.1.5 BOCA & CDL COAS 1.0b1 COAS 1.0 Resolved closed
COAS-23 Pg. 79 Under section - 3.3.2.4.9 TimeStamp COAS 1.0b1 COAS 1.0 Resolved closed
COAS-22 Pg. 75 Under section - 3.3.2.4.3 ObservationData COAS 1.0b1 COAS 1.0 Resolved closed
COAS-15 Pg. 95 Under section - 3.3.3.5 AsynchCallBack COAS 1.0b1 COAS 1.0 Resolved closed
COAS-14 Pg. 92 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-12 Pg. 90 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-11 Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10 COAS 1.0b1 COAS 1.0 Resolved closed
COAS-18 Pg. 5 Under section - 3.1.4 Objects By Value (OBV) COAS 1.0b1 COAS 1.0 Resolved closed
COAS-21 Pg. 71 Under section - 3.3.2.1 Include Files COAS 1.0b1 COAS 1.0 Resolved closed
COAS-10 Pg. 86 Under section - 3.3.2.8 Exceptions COAS 1.0b1 COAS 1.0 Resolved closed
COAS-13 Pg. 91 Under section - 3.3.3.3 AccessComponent COAS 1.0b1 COAS 1.0 Resolved closed
COAS-7 alternative verbs for Federated access and put_obsevations COAS 1.0b1 COAS 1.0 Resolved closed
COAS-9 Pg. 81 Under section - 3.3.2.5 Constants COAS 1.0b1 COAS 1.0 Resolved closed
COAS-8 how to use HL7 data types COAS 1.0b1 COAS 1.0 Resolved closed
COAS-37 GCPR issue: Exceptions COAS 1.0b1 COAS 1.0 Resolved closed
COBOL-5 CORBA sequence IDL type in COBOL COBOL 1.0b1 COBOL 1.0 Resolved closed
COBOL-4 COBOL Typedefs NOT universally available COBOL 1.0b1 COBOL 1.0 Resolved closed
CMMN-13 Missing statement on compliance CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-15 Errors in XML-Schema for CMMN (CMMN-1,2,3) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-14 Add CMMN logo to front page of the spec CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-12 Wrong Expression containment mutiplicity CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-11 Wrong multiplicity of the two containments of process parameter in process CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-16 Sentries SHOULD be allowed for DiscretionaryItem's (CMMN-8) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-17 Figure 72 (Example CMMN model) is wrong in spec CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-5 Improve Motivation for introducing an EventListener CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-4 More intuitive symbols for entry and exit criterion CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-2 Contradicting Definitions of Sentry CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-1 Expand TimeEventListener CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-8 Process and Case Task are inconsistent with BPMN call activity notation (CMMN-6) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-7 Inconsistent AutomaticActivation and Repetition Decorators between CMMN and BPMN (CMMN-5) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-10 CMMN FTF Issue: Wrong multiplicity of containment of case file item in case file CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-9 Required/Optional and Discretionary Tasks notation is inconsistent with BPMN (CMMN-7) CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-3 Error in description of Active state for a Stage or Task CMMN 1.0b1 CMMN 1.0 Resolved closed
CMMN-6 Reference from Section 5.4.10.5 CMMN 1.0b1 CMMN 1.0 Resolved closed
CAD12-5 CadConnection, CadSystem: Avaliable_models() enhancement CAD 1.1 CAD 1.2 Resolved closed
CAD12-2 Suggest altering the input parameter CadFeature::ParameterSeq model_params CAD 1.1 CAD 1.2 Resolved closed
CAD12-1 altering the use of EntitySeqs to LongSeqs CAD 1.1 CAD 1.2 Resolved closed
CAD12-4 CadMain::ModelInstance::component()' collides CAD 1.1 CAD 1.2 Resolved closed
CAD12-3 CadGeometry::Curve::tessellate() CAD 1.1 CAD 1.2 Resolved closed
CAD11-19 Model Instances vs. Top-Level Entities CAD 1.0 CAD 1.1 Resolved closed
CAD11-18 Add some operations to CadFoundation module's interfaces CAD 1.0 CAD 1.1 Resolved closed
CAD11-21 Euclidean Dimension CAD 1.0 CAD 1.1 Resolved closed
CAD11-20 EntityFactory and ModelInstanceFactory CAD 1.0 CAD 1.1 Resolved closed
CAD11-34 interface Parameter CAD 1.0 CAD 1.1 Resolved closed
CAD11-25 "Cadsystem" interface issue CAD 1.0 CAD 1.1 Resolved closed
CAD11-24 "Entity-Types" CAD 1.0 CAD 1.1 Resolved closed
CAD11-23 Curve Parameters CAD 1.0 CAD 1.1 Resolved closed
CAD11-22 Tessellation Types CAD 1.0 CAD 1.1 Resolved closed
CAD11-27 remove CadGeometryExtens interface CAD 1.0 CAD 1.1 Resolved closed
CAD11-26 interface Model : CadFoundation:: Attributable replaced CAD 1.0 CAD 1.1 Resolved closed
CAD11-33 struct PolyLineStruct is defined but not used anywhere CAD 1.0 CAD 1.1 Resolved closed
CAD11-32 CadFoundation.idl: In the CadFoundation::EntityPropsStruct CAD 1.0 CAD 1.1 Resolved closed
CAD11-31 bounding_box" behavior CAD 1.0 CAD 1.1 Resolved closed
CAD11-30 Add operations to CadMain::Model CAD 1.0 CAD 1.1 Resolved closed
CAD11-29 Operation to identify opened Models CAD 1.0 CAD 1.1 Resolved closed
CAD11-28 Set color on Layer interface CAD 1.0 CAD 1.1 Resolved closed
CAD-15 What are units for 'angle' field in TessParametersStruct CAD 1.0b1 CAD 1.0 Resolved closed
CAD-14 TessellationStruct normals field should be VectorStructSeq CAD 1.0b1 CAD 1.0 Resolved closed
CAD-13 Should there be a get_parameter_set function at the Model interface level? CAD 1.0b1 CAD 1.0 Resolved closed
CAD-12 CadBrep Edge.nearest_points function needs clarification CAD 1.0b1 CAD 1.0 Resolved closed
CAD-11 CadBrep Edge.nearest_points function incorrect CAD 1.0b1 CAD 1.0 Resolved closed
CAD-10 CAD Services IDL issue (02) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-9 CAD Services IDL issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-8 Binding for Face.nurbs_representation needs major design overhaul/removal CAD 1.0b1 CAD 1.0 Resolved closed
CAD-7 CAD Services needs to clarify 'exact' for nurbs_representation functions CAD 1.0b1 CAD 1.0 Resolved closed
CAD-6 Edge.nurbs_representation should h. 'tolerance' argument declared as inout CAD 1.0b1 CAD 1.0 Resolved closed
CAD-5 Surface.nurbs_approximation should 'tolerance' argument declared as inout CAD 1.0b1 CAD 1.0 Resolved closed
CAD-4 Surface.nurbs_approximation should be renamed nurbs_representation CAD 1.0b1 CAD 1.0 Resolved closed
CAD-3 Need to add a "ColorStruct color;" to the PresentationStruct CAD 1.0b1 CAD 1.0 Resolved closed
CAD-2 IDL extracts in document are inconsistent about showing module declarations CAD 1.0b1 CAD 1.0 Resolved closed
CAD-1 CAD FTF issue regarding UML which looks kind of like CORBA profile CAD 1.0b1 CAD 1.0 Resolved closed
CAD-43 Incompletely specified operations - issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-42 Several properties in the CadBrep::PropertyStruct need clarification. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-41 problems in the EntityCreation interface. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-40 Entity Factory issue (Function 5) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-39 Entity Factory issue (Function 4) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-38 Entity Factory issue (Function 3) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-37 Entity Factory issue (Function 2) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-36 Entity Factory issue (Function) CAD 1.0b1 CAD 1.0 Resolved closed
CAD-35 interface for STEP open shel CAD 1.0b1 CAD 1.0 Resolved closed
CAD-34 Deletion of CadFourndation::Entity descendants CAD 1.0b1 CAD 1.0 Resolved closed
CAD-33 Entity.Position() returns PointStructure instead of TransformationStructure CAD 1.0b1 CAD 1.0 Resolved closed
CAD-32 There is no way to delete any CadFoundation::Entity interface child. CAD 1.0b1 CAD 1.0 Resolved closed
CAD-31 CadFoundation::Entity interface CAD 1.0b1 CAD 1.0 Resolved closed
CAD-30 Surface.intersect_ray argument error CAD 1.0b1 CAD 1.0 Resolved closed
CAD-29 CadSystem Properties issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-28 I haven't found any way to create ModelInstance CAD 1.0b1 CAD 1.0 Resolved closed
CAD-27 Replace #include "CadFeature.idl with #include "CadFoundation.idl" CAD 1.0b1 CAD 1.0 Resolved closed
CAD-26 Method names in topological entities are not everywhere unified CAD 1.0b1 CAD 1.0 Resolved closed
CAD-25 how to add new topological entities to existing model with sharing of exist CAD 1.0b1 CAD 1.0 Resolved closed
CAD-24 method of CadMain::EdgeLoop has to be renamed CAD 1.0b1 CAD 1.0 Resolved closed
CAD-23 we have to generalize is_manifold() methods in all BRep entities CAD 1.0b1 CAD 1.0 Resolved closed
CAD-22 adding an attribute to the entity group CAD 1.0b1 CAD 1.0 Resolved closed
CAD-21 Section 3.4, Editorial CAD 1.0b1 CAD 1.0 Resolved closed
CAD-20 Sections 1.8, 2.8, 3.1, 3.2, Editorial CAD 1.0b1 CAD 1.0 Resolved closed
CAD-19 Support for STEP input / output? CAD 1.0b1 CAD 1.0 Resolved closed
CAD-18 Body.property_info, several values are calculated. What is the return accur CAD 1.0b1 CAD 1.0 Resolved closed
CAD-17 BodyTessellationStruct issue CAD 1.0b1 CAD 1.0 Resolved closed
CAD-16 Model level parameters for geometry creation issue CAD 1.0b1 CAD 1.0 Resolved closed
CPP11-228 CORBA::Bounds and CORBA::TypeCode::Bounds CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-227 Read-only restrictions on parameters CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-226 C++ mapping: missing from_wchar and to_wchar CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-225 C++ mapping for IN object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-224 IDL generated C++ types and stream operators CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-223 Wide string allocation (2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-218 Why does get_principal() take an Environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-217 POA_*_tie classes in 18.1.4 can"t be supported CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-214 Boolean type left undefined by C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-213 Defect with anonymus types in union mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-220 Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-219 PortableServer:ObjectId_tow_wstring() and string_to_ObjectId() CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-216 Section 8.2: set_exception() supported by BOA? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-215 Section 17..13.1 release()method should be added to mappping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-222 Wide string allocation (1) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-221 Bounded strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-212 Interpretation of _narrow semantics CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-183 Distinction between _var and _ptr types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-182 Return value of maximum() for unbounded sequences CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-195 Sequence buffer types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-194 Sequence lacks common features CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-185 get_principal () needs an environment parameter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-184 Names of anonymous types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-181 Bounded sequence problem (Section 16.11 p. 16-23) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-180 Problem with Any::to_object memory management CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-189 C++ mapping complexity CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-188 string and objrev members of constructed types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-191 State of release flag for sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-190 Sequence implementation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-193 References returned from sequence operator[] after realloc CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-192 Sequence maximum() call CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-187 fixed- vs. variable-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-186 Implementation dependency for _var and _ptr CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-179 Any string extractor CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-178 Adding T_copy function CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-136 Unknown parts of an IOR and interoperability CORBA 2.2 CPP 1.1 Resolved closed
CPP11-135 Potential interop. problem in CORBA 2.3: pseudo-operation marshalling CORBA 2.2 CPP 1.0 Resolved closed
CPP11-134 Clarification of OBV GIOP encoding rules CORBA 2.2 CPP 1.0 Resolved closed
CPP11-141 Mapping for wide strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-140 Old References in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-139 Semantics of >>= operator in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-153 Errors in example code for boxed struct CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-152 Object reference members, _var, and widening CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-151 98-09-03, exception inconsistency CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-150 Is SystemException supposed to be concrete? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-149 DSI C++ issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-145 resolve_initial_references missing from Orb interface CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-144 Section 7.3.5 ValueBase editorial changes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-143 C++ mapping for strings CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-142 Any and WChar issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-148 New C++ issue about T_out classes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-147 from_string issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-146 void * functions for Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-138 Alias type codes in any values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-137 Missing Mappings for Object CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-246 Signature of _narrow in exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-245 C++ issue to coordinate with proposed resolution of issue 752 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-244 Missing text describing fixed point constant mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-234 Missing constructor for Fixed CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-233 fixed_digits and fixed_scale member functions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-243 C++ Any mapping proposed change CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-242 How to put a generic CORBA exception into an Any CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-232 macros for fixed arithmetic results CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-231 Typos on p 20-34 of orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-230 Fixed types in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-229 CORBA::ORB::InvalidName ambigious in C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-238 C++ Fixed Type (03) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-237 Fixed type (02) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-241 _out parameter typo CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-240 Typo in orbos/98-01-11 CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-236 C++ Fixed type issue (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-235 C++ mapping for fixed is broken (01) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-239 String member initialization CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-202 Access to sequence elements CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-201 Any and IN_COPY_VALUE CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-200 operator>>= on strings and object references CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-199 A_ptr and A_var should be distinct types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-211 Default constructor for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-210 explicit copy/adopt for String_var CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-209 TypeCode interpreter CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-208 Any release flag and operator<<= CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-205 to/from string for Any type safety CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-204 nested ptr and var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-197 Typo in table 3? CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-196 Sequence creation CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-207 Accessors for release flag of sequence CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-206 T_copy for string and array CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-198 _var types for fixed-length types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-203 TypeCode mapping update for CORBA 2.) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-165 Interface issue CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-164 Transfer of C++ codes CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-163 ORB mapping re Policy CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-169 Access to sequence buffers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-168 Omission in union C++ mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-167 Any inserters for strings need to use const pointers CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-166 C++ keyword mapping ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-158 Extraction from Any by pointer CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-157 C++ spec uses reserved names in global namespace CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-156 string allocation functions -- description ambiguous CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-155 String sequence and allocbuff CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-154 _raise() should be const CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-160 boxed types for floating point values CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-159 Any inserters and extractors CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-162 CustomMarshal mapping type CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-161 CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2) CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-172 C++ classes for modules CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-171 Defining an operator for struct/union/sequence _var types CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-170 T__alloc in C mapping CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-175 Memory Management Clarification CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-174 Union discriminators in C++ CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-173 In String Argument Passing Question CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-177 inserter and extractor functions for exceptions CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-176 Union problem CPP 1.0b1 CPP 1.0 Resolved closed
CPP11-129 GIOP fragment alignment issue for CORBA 2.3 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-128 COMM_FAILURE and completion_status CORBA 2.2 CPP 1.0 Resolved closed
CPP11-127 Typo in page 15-44 CORBA 2.2 CPP 1.0 Resolved closed
CPP11-126 CloseConnection CORBA 2.2 CPP 1.0 Resolved closed
CPP11-125 How to handle unexpected exceptions? CORBA 2.2 CPP 1.0 Resolved closed
CPP11-124 IIOP server-initiated connection closure problem CORBA 2.0 CPP 1.0 Resolved closed
CPP11-133 Move recently added text to correct place CORBA 2.2 CPP 1.0 Resolved closed
CPP11-132 OBV GIOP clarification needed CORBA 2.2 CPP 1.0 Resolved closed
CPP11-131 Tagged Component interactions CORBA 2.2 CPP 1.0 Resolved closed
CPP11-130 Obsolete text in ptc/98-08-13.pdf CORBA 2.2 CPP 1.0 Resolved closed
CPP11-109 Fixed(const char *) constructor problem CPP 1.0 CPP 1.1 Resolved closed
CPP11-108 Editorial typo in Section 1.36.3 of C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-98 Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf) CPP 1.0 CPP 1.1 Resolved closed
CPP11-107 Object _out class copy constructor & assignment op wrong CPP 1.0 CPP 1.1 Resolved closed
CPP11-106 CORBA 2.3 Editorial problem in TypeCode CPP 1.0 CPP 1.1 Resolved closed
CPP11-101 Contents of string members (02) CPP 1.0 CPP 1.1 Resolved closed
CPP11-100 Contents of string members (01) CPP 1.0 CPP 1.1 Resolved closed
CPP11-102 String extractor semantics undefined? CPP 1.0 CPP 1.1 Resolved closed
CPP11-104 Exception constructors should be protected CPP 1.0 CPP 1.1 Resolved closed
CPP11-103 Exception::_raise() should be const? CPP 1.0 CPP 1.1 Resolved closed
CPP11-99 Union string member mapping defect? CPP 1.0 CPP 1.1 Resolved closed
CPP11-105 Unary operators for Fixed class have wrong return types CPP 1.0 CPP 1.1 Resolved closed
CPP11-114 1 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-113 NamedValue not only an NVList element CPP 1.0 CPP 1.1 Resolved closed
CPP11-117 4 of 4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-116 don't understand the last paragraph of 1.18.2: CPP 1.0 CPP 1.1 Resolved closed
CPP11-119 Extraction operator for system exceptions? CPP 1.0 CPP 1.1 Resolved closed
CPP11-118 Need Any::to_value operation? CPP 1.0 CPP 1.1 Resolved closed
CPP11-115 2 of4 issues with Abstract interfaces CPP 1.0 CPP 1.1 Resolved closed
CPP11-122 Supporting typedefs for _var types? CPP 1.0b1 CPP 1.1 Duplicate or Merged closed
CPP11-121 Any::to_abstract_base needs statement about memory management CPP 1.0 CPP 1.1 Resolved closed
CPP11-112 Standard object operations & DynamicImplementation CPP 1.0 CPP 1.1 Resolved closed
CPP11-111 Inconsistency in 1.7 and 1.9 of mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-123 Typographical problems CPP 1.0 CPP 1.1 Resolved closed
CPP11-120 allocbuf() for bounded sequences? CPP 1.0 CPP 1.1 Resolved closed
CPP11-110 Fixed::round and truncate issue CPP 1.0 CPP 1.1 Resolved closed
CPP13-72 ORB interface destroy() operation issue CPP 1.1 CPP 1.3 Resolved closed
CPP13-71 _ptr_type and _var_type typedefs CPP 1.0b1 CPP 1.3 Resolved closed
CPP13-76 make it possible to write more generic C++ code CPP 1.2 CPP 1.3 Resolved closed
CPP13-75 Servant_var + spec typo? CPP 1.2 CPP 1.3 Resolved closed
CPP13-79 valuetype classes should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-78 Interface should add _out_type typedef CPP 1.2 CPP 1.3 Resolved closed
CPP13-77 C++ keywords should be updated CPP 1.2 CPP 1.3 Resolved closed
CPP13-74 Section 4.5.4: parameter to _narrow CPP 1.2 CPP 1.3 Resolved closed
CPP13-73 Context PIDL mapping bug CPP 1.1 CPP 1.3 Resolved closed
CPP13-80 get_policy should return Policy, not Policy_ptr CPP 1.2 CPP 1.3 Resolved closed
CPP11-97 operator>> for String_var CPP 1.0 CPP 1.1 Resolved closed
CPP11-96 Valuetypes and _out classes in C++ mapping CPP 1.0 CPP 1.1 Resolved closed
CPP11-89 generate concrete classes and factories for valuetypes without initializer CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-88 add a _var type for each servant type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-87 tie doesn"t do ref counting CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-86 Misleading text for DSI invoke() and _primary_interface() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-95 Valuetypes and arbitrary graphs CPP 1.0 CPP 1.1 Resolved closed
CPP11-94 Factories for StringValue and WStringValue CPP 1.0 CPP 1.1 Resolved closed
CPP11-84 _primary_interface CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-83 The C++ mapping for valuetype _narrow should not _add_ref CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-92 Valuetype argument passing CPP 1.0 CPP 1.1 Resolved closed
CPP11-91 Add AbstractBase base type to IDL language? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-90 narrow abstract interface class to concrete object? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-93 Sequences and get_buffer() CPP 1.0 CPP 1.1 Resolved closed
CPP11-82 sequence allocbuf parameter != 0 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-85 Any missing LongLong operators, etc? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-43 Exception id for each exception type CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-42 Accessor for exception id CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-47 operator<< for ostreams and Exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-49 C++ semantics vs. IDL semantics CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-48 ANy release flag and operator CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-53 Legal IDL cannot map to C++ CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-52 Double underscore identifier mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-46 make String_var reference but not adopt CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-45 buffer classes for sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-50 u++ binding for ServerRequest pseudo object CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-51 [q] intf name == op name CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-44 TypeCode for each basic and IDL defined types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-41 Accessors for the Any release flag CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-40 Constructor taking discriminant as argument CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-39 Name field for SystemExceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-31 union accessors CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-30 callee-allocated storage modification CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-37 accessor members for structs CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-36 allocbuf and initialization of elements CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-34 Allocated storage for out and return strings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-33 accessor function on SystemException CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-28 void* from Any for constructed types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-27 handling void* from Any CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-32 Mapping for IDL context CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-38 union accessors require temporaries CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-29 anonymus types CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-35 C++ namespaces CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-63 Multiple inheritance of C++ Servants is ill-defined CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-59 Blocking semantics of get_next_response not well specified CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-58 Section 16.2, Section 16.6: editorial CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-67 No conversion defined from a B_var to an A_ptr CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-66 ServantBase mappings CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-62 C++ mapping of servants may result in ambigous run-time behavior CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-61 Implementation problem with policy objects using root POA CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-56 Interface definition must be standardized CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-55 String_var and Any_var are missing the T_ptr definition CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-65 C and C++ Mapping question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-64 inout strings modifiable? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-60 sec. 18.1.2: explicit information on _this() is missing CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-57 IDL from Ennvironment has invalid attribute CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-54 const method qualification should be removed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-25 Storage ownership issue CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-24 Global functions vs. T_var namespace CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-22 Array slice example CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-21 Semantics of sequence length() operation CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-17 Implementation description CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-16 Detection of initialization of T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-14 example incorrect? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-13 Levels of portability conformance requested CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-20 Copying of out parameters CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-19 C vs. C++ coding style CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-18 Autoextension of sequences CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-26 Pointers vs. values CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-15 Assignment to T_var CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-23 Array_forany CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-76 Problems with deactivate_object() CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-75 Do POA servant classes need to use virtual inheritance? CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-73 Spec does not mention the existance of an Any_out class CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-72 _var & _out types problems (01) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-74 Spec is too verse in defining the T_var types for fixed length CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-81 Passing Fixed to operations CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-80 Comparison operators for Fixed CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-70 C++ Sequence mapping Question CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-69 TypeCode_ptr base_typecode(TypeCode_ptr tc) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-79 Parameter passing rules for ValueFactory CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-78 C++ language mapping minor editorial revision CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-68 C++ mapping for fixed is broken (02) CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-71 Missing operators in orbos/98-01-11 CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-77 Section 5.3.6.3 Value Factories CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-2 Fixed structs CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-5 Inconsistent interfaces for the operation pairs *duplicate* and CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-4 Testing exceptions CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-8 Pseudo objects for DSI CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-7 Identifier conflicts resulting from the language mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-11 TypeCode/Value mismatch in ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-10 illegal union access when discriminator is wrong CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-3 Passing of object reference in pointers CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-12 Representation of void* returned from ANY CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-6 interface mapping CPP 1.0b1 CPP 1.1 Resolved closed
CPP11-9 _ptr member accessors for string and objref CPP 1.0b1 CPP 1.1 Resolved closed
CPP12-9 Escaped keyword mapping? CPP 1.1 CPP 1.2 Resolved closed
CPP12-8 Local interfaces issue 1 CPP 1.1 CPP 1.2 Resolved closed
CPP12-16 implementing local interfaces in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-15 Initialized T_var? CPP 1.1 CPP 1.2 Resolved closed
CPP12-14 Missin operations in Object interface, ptc/01-06-07 CPP 1.1 CPP 1.2 Resolved closed
CPP12-19 String_var and C++ implicit conversions CPP 1.1 CPP 1.2 Resolved closed
CPP12-18 need mapping for get_orb and get_component on CORBA::Object CPP 1.1 CPP 1.2 Resolved closed
CPP12-17 No Mapping for Local interface in C++ CPP 1.1 CPP 1.2 Resolved closed
CPP12-11 Bug on _var references CPP 1.1 CPP 1.2 Resolved closed
CPP12-10 Dangling reference CPP 1.1 CPP 1.2 Resolved closed
CPP12-7 Structure member ordering CPP 1.1 CPP 1.2 Resolved closed
CPP12-6 semantics of valuetype _downcast operation unclear CPP 1.1 CPP 1.2 Resolved closed
CPP12-13 ValueRefCountBase::_add_ref CPP 1.1 CPP 1.2 Resolved closed
CPP12-12 C++ mapping for CORBA::LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-3 LocalObject CPP 1.1 CPP 1.2 Resolved closed
CPP12-2 mapping of local interfaces CPP 1.1 CPP 1.2 Resolved closed
CPP12-5 How to create a local object reference? CPP 1.1 CPP 1.2 Resolved closed
CPP12-4 CORBA::Object & LocalObject CPP 1.1 CPP 1.2 Resolved closed
C11-82 How to allocate storage for a basic type you wish to place in an any? C 1.0b1 C 1.1 Resolved closed
C11-81 Use of "objref_ptr" C 1.0b1 C 1.1 Resolved closed
C11-83 Correct arguments to send multiple requests C 1.0b1 C 1.1 Resolved closed
C11-73 Out of bound value behaviour for _maximum and _length in sequences C 1.0b1 C 1.1 Resolved closed
C11-72 Type declaration C 1.0b1 C 1.1 Resolved closed
C11-76 Order of parameters in the C mapping C 1.0b1 C 1.1 Resolved closed
C11-75 Editorial C 1.0b1 C 1.1 Resolved closed
C11-80 CORBA_string_alloc C 1.0b1 C 1.1 Resolved closed
C11-79 Argument order inconsistent (Section 14.25.2) C 1.0b1 C 1.1 Resolved closed
C11-74 Portably getting the value of the bounds of a sequence C 1.0b1 C 1.1 Resolved closed
C11-78 Reference to undefined term DIR (Section 14.24.1) C 1.0b1 C 1.1 Resolved closed
C11-71 Order of arguments in C Language mapped operation C 1.0b1 C 1.1 Resolved closed
C11-77 Wrong order of parameters C 1.0b1 C 1.1 Resolved closed
C11-64 Semantics of CORBA_exception_id()"s return type C 1.0b1 C 1.1 Resolved closed
C11-63 Suggested optimization for string duplication C 1.0b1 C 1.1 Resolved closed
C11-59 Unions represented with either union or struct C 1.0b1 C 1.1 Resolved closed
C11-58 All interfaces must be defined at global scope? C 1.0b1 C 1.1 Resolved closed
C11-70 Confusion about ORB handling call to pseudo objects via DII C 1.0b1 C 1.1 Resolved closed
C11-69 Entire section 14.1 should not be there (CORBA 14) C 1.0b1 C 1.1 Resolved closed
C11-67 CORBA_BOA_set_exception() parameter issues C 1.0b1 C 1.1 Resolved closed
C11-66 Specification type on CORBA_ORB_object_to_string example C 1.0b1 C 1.1 Resolved closed
C11-60 Sequence release flag implementation C 1.0b1 C 1.1 Resolved closed
C11-68 Support for efficient DII invocation (Section 17.7.1 CORBA 2.)) C 1.0b1 C 1.1 Resolved closed
C11-65 Contents of string literal exception identifier C 1.0b1 C 1.1 Resolved closed
C11-62 Malloc problems with sequence types C 1.0b1 C 1.1 Resolved closed
C11-61 Confusing sequence example C 1.0b1 C 1.1 Resolved closed
C11-56 C keywords C 1.0b1 C 1.1 Resolved closed
C11-57 Problems with underscores C 1.0b1 C 1.1 Resolved closed
C11-84 Content of an Any is a pointer to the type -- Issue C 1.0b1 C 1.1 Resolved closed

Issues Descriptions

Create examples of use of the profile

  • Key: CSRM11-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    Add mention of Educational examples

    We have updated and feel that the CSRM is good enough to include, with the specification as educational attachments. We also need to change the text of the specification to mention the availability of MDZIP and XMI versions.

    Attached are example versions of the CSRM as ZIP collections in both MDZIP and XMI formats. I will attach a version with the latest version of XMI as part of the release.

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

Icons for profile

  • Key: CSRM11-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Resolved — CSRM 1.1b1
  • Disposition Summary:

    Icons supplied as educational attachment for use by implementors

    Add the following paragraph to section 2, Conformance.

    The profile of this version contains icons for most of the stereotypes. These icons are to be considered educational examples that may be replaced with implementation-specific versions. As an aid to implementers, a collection of Scalable Vector Graphic (SVG) files used for the current icons in the profile (currently embedded as encoded SVG) are included as an educational attachment that may be used as a starting point for implementers to create implementation-specific icons.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Add constraints to aid in correctness of profile useage

  • Key: CSRM11-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    Defer tp RTF 1.2

    Need a better set of actual uses of the model to create and test constraints. Defer to 1.2 RTF.

  • Updated: Mon, 25 Mar 2024 14:22 GMT

Recommended Additions

  • Key: CSRM11-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

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

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

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

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

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

    An Issue that Needs Resolution.

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

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

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

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Closed; Out Of Scope — CSRM 1.1b1
  • Disposition Summary:

    Close because this was against beta

    This issue is no longer relevant. Should have been closed in FTF instead of deferred.

  • Updated: Mon, 25 Mar 2024 14:22 GMT
  • Attachments:

Incorrect constructor referenced in Fixed description

  • Key: CPP1117-8
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    This chapter says:

    The Fixed(std::string&) constructor converts a string representation of a fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

    But there is no constructor that accepts a non-const std::string&, the text should say

    The Fixed(const std::string&) constructor converts a string representation of a
    fixed-point literal, with an optional leading sign (+ or -) and an optional trailing ‘d’ or ‘D’, into a real fixed-point value.

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 15:56 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Correct the spec text to match the source code

    Add the missing "const" as described in the issue.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo

  • Key: CPP1117-9
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Double "to to" in the first sentence:

    IDL bitset types are mapped to to C++ structs that meet the C++11 requirements for aggregate initialization.

    Should be

    IDL bitset types are mapped to C++ structs that meet the C++11 requirements for aggregate initialization.

  • Reported: CPP11 1.6b1 — Mon, 17 Jul 2023 08:54 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Fix typo

    As per issue description

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing annotation mapping

  • Key: CPP1117-13
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec should mention how the IDL4-mentioned annotations impact the mapping, I think the spec should list at least @value, @default_literal, @default, @range @min @max @bit_bound @external

    See IDL4 to CPP and the IDL4 spec itself

  • Reported: CPP11 1.6b1 — Fri, 4 Aug 2023 07:01 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add mappings for some more IDL 4 Standardized Annotations

    New mappings for @value, @default_literal, @default, and @bit_bound – in each case drawing from uses in the beta IDL4-to-C++ mapping and/or XTypes.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Missing description related to union member modifier

  • Key: CPP1117-7
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    In the specification an addition was made about the default argument when the union member has multiple legal discriminator values:

    Union members associated with the "default" label and those associated with multiple labels may have multiple legal discriminator values. For these members, the modifiers (those that return void) have a second parameter which has the discriminator's type. This parameter has a default argument. For members associated with multiple labels, the value of the default argument is the value of the case label that appears first in IDL. For members associated with the default label, the value of the default argument is an implementation-defined value that selects the member.

    There is nothing in the text that describes what happens when a discriminator value is passed which doesn't belong to the member, this is implicitly in the example code further down "u.obj(a, 2)", but this should be explicit in the text also, passing a not allowed discriminator should result in a BAD_PARAM exception

  • Reported: CPP11 1.6b1 — Tue, 10 Jan 2023 09:20 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Add description of error handling for 2-parameter union modifier functions

    To be consistent with the existing parts of the spec, make it clear that invalid parameters result in a BAD_PARAM exception.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Change struct VariableExt constructor

  • Key: CPP1117-11
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    Instead of `VariableExt(const Variable&, bool);` it should be `VariableExt(Variable, bool);` so that in the implementation we can use std::move, this is as all complex types are passed into the constructor of a struct

  • Reported: CPP11 1.6b1 — Wed, 2 Aug 2023 08:42 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    In example code, function signature of constructors is non-normative

    In section 6.31.3 make it clear that the specific types of the constructor parameters (if they use pass by value or pass by const-reference) is up to the implementation.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Improve bitmask mapping

  • Key: CPP1117-10
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bitmask mapping is very basic, it doesn't give any type safety or more modern API. The spec should be improved, the <X>Bits type should be removed, only one type should be used. Also when there are multiple bitmasks with the same bitfield name they could result in a name clash. Maybe map to a enum class and add the operators ~,|,^,& for the enum class as inline operations to modify the enum class as a bitmask. At that moment the Bit type can be removed.

    When time permits I will make a proof of concept for TAOX11

  • Reported: CPP11 1.6b1 — Mon, 31 Jul 2023 06:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer breaking change to the bitmask mapping

    The existing mapping in IDL-to-C++11 is based on DDS XTypes where it has been in a formal standard for a number of years.
    There are certainly reasons to have a mapping that makes better use of the C++ type system, but this would come at a cost in terms of divergence from OMG precedent.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add standardized annotation to override the IDL map to std::map mapping

  • Key: CPP1117-1
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    For some use cases it would be more efficient to map a IDL map to a std::unordered_map (see https://en.cppreference.com/w/cpp/container/unordered_map), maybe standardize an annotation which can be used to override the mapping to std::map to the type as specified by the annotation?

  • Reported: CPP11 1.7 — Wed, 17 Aug 2022 08:55 GMT
  • Disposition: Deferred — CPP11 1.7
  • Disposition Summary:

    Defer

    Other languages have similar issues like using TreeMap or HashMap in Java.

    Defer resolution on this until standard annotation can be provided in the IDL 4 spec or the IDL Working Group has a common approach to use across language mappings.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Typo in example

  • Key: CPP1117-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

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

    should be

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

  • Reported: CPP11 1.7 — Wed, 20 Oct 2021 06:24 GMT
  • Disposition: Closed; No Change — CPP11 1.7
  • Disposition Summary:

    Typo is not in base document

    ptc/21-11-02 doesn't have this typo

  • Updated: Tue, 9 Jan 2024 19:49 GMT

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

  • Key: CPP1117-3
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    The section says:

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

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

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

  • Reported: CPP11 1.7 — Fri, 10 Dec 2021 15:02 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update text in Arg Passing to refer to Basic Data Types

    Update as specified in parent issue

  • Updated: Tue, 9 Jan 2024 19:49 GMT

bit_bound

  • Key: CPP1117-14
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The spec defines the type trait bit_bound as `std::integral_constant<uint32_t, b>`, but as bit_bound is maximal of 64, this could be `std::integral_constant<uint8_t, b>`

  • Reported: CPP11 1.6b1 — Mon, 7 Aug 2023 07:29 GMT
  • Disposition: Resolved — CPP11 1.7
  • Disposition Summary:

    Update type used for bit_bound in bit mask traits

    The integral_constant template from the C++ standard library should be instantiated with uint8_t instead of uint32_t

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Add bit_bound/underlying_type for enum traits

  • Key: CPP1117-12
  • Status: closed  
  • Source: Remedy IT Expertise BV ( Johnny Willemsen)
  • Summary:

    The bit_bound annotation can be applied to the enum, so the bit_bound and underlying_type traits should also be added to the enum

  • Reported: CPP11 1.6b1 — Sat, 5 Aug 2023 14:47 GMT
  • Disposition: Duplicate or Merged — CPP11 1.7
  • Disposition Summary:

    Add type traits for enums

    Including this in the resolution to CPP1117-13.

  • Updated: Tue, 9 Jan 2024 19:49 GMT

Rename the new composites ontology to roles and compositions

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

    After additional review, RTF members suggested that a better name for the ontology would be roles and compositions. Other feedback identified a typo, suggested that we add the notion of independent identity in the definition of composition for clarification, and remove the functional axiom on the property isPlayedBy, which might overly constrain its utility.

  • Reported: COMMONS 1.0b2 — Thu, 17 Aug 2023 20:56 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Rename the new composites ontology and revise definitions per additional RTF discussion

    The resolution to this issue depends on the resolution to COMMONS-11-4, adding a new Composites ontology, and revises the results of that resolution, including renaming and moving the sections in the specification as well as renaming the ontology, per further RTF discussion.

    Note that the change barred version of the document does not reflect the original sections (i.e., adding and then deleting 8.5, for ease of managing the resulting document in LibreOffice.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG and external projects need a pattern for representing compositions

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

    In pharmaceuticals and other industries, products are often composed of other things. The 'recipe' for manufacturing a product includes various ingredients, which are roles that substances, components. or other things take on in the context of that product.

    Further, there are cases where the composition of some product is context specific. Product documentation may be jurisdictionally defined due to regulatory constraints, for example. The representation of some ingredients in certain pharmaceutical products, including the way these elements are described on packaging, is jurisdiction specific, even thought the product itself has exactly the same composition via exactly the same manufacturing processes world wide.

    A general pattern for this kind of composition would be quite useful for a number of domain areas and is a good candidate for inclusions in the Commons library.

  • Reported: COMMONS 1.0b2 — Sat, 5 Aug 2023 21:14 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Augment the Commons library with an ontology defining compositions and roles

    Introduce a new ontology representing composition and role as classes and relationships between them for use in addressing the requirements outlined in the issue description

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Need to add start and end time and explicit time period in Commons

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

    Currently we have an explicit date period, but not explicit time period, which is needed for PPMN, among other processes. This is also required for Robotics.

  • Reported: COMMONS 1.0b2 — Fri, 14 Jul 2023 18:05 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Added a number of properties to the Dates and Times ontology related to start and end time

    The resolution to this issue adds two classes to the ontology: TimePeriod and ExplicitTimePeriod, and a number of properties, including a general purpose hasTime property as well as hasDateOfIssuance, hasEnd, hasEndTime, hasStart, hasStartTime, and hasTimePeriod, per request of two task forces, Robotics Service Ontology (RoSO) and Pedigree and Provenance Metamodel and Notation (PPMN).

    Note: in the text revisions, under item 5, there are no sections labeled i and n because solitaire turned them into odd emojis.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG task forces have a need for a common ontology for quantities and units

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

    A preliminary quantities and units ontology was developed for FIBO for use with commodities. Several other groups at OMG need this ontology, as do external users of the Commons library. The ontology should be mappable to the SysML v2 library so that we can generate the individuals in that library for use in knowledge graph applications. It should also be consistent, to the degree possible, with the latest changes to the VIM, with BIPM requirements, and with ISO 11240 for use in the pharmaceutical domain.

    There is a dependency in the quantities and units ontology on a small documents ontology, to provide the reference documentation for certain units. This ontology is relatively small, however, and can easily be mapped to other ontologies defining documents.

  • Reported: COMMONS 1.0b2 — Fri, 16 Jun 2023 20:52 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Introduce two new ontologies, a documents ontology and a quantities and units ontology that depends on it

    Several OMG task forces and other external industry groups in pharmaceuticals, manufacturing, finance and others, there is a widely recognized need for a well-designed ontology supporting quantities and units. While a number of ontologies exist that claim to fill this gap, few are well designed and some have moved away from OWL in order to meet other demands. Within OMG, the healthcare, finance, robotics, and retail task forces all have requirements for a quantities and units ontology. Given the latest advances in SysML, such an ontology should align well with the library of quantities and units in SysML v2 so that the equivalent reference content in RDF/OWL can be automatically generated.

    The ontologies included in this resolution fill that need, although they are limited to scalar quantities at this juncture. The RTF intends to create a new arrays / vectors / tensors ontology and a companion quantities and units extension to support tensor and vector quantities over the coming months. Most applications do not need that level of sophistication however, and thus the RTF has determined that submission of the scalar version should happen sooner than later to fulfill requirements of other task forces.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Several OMG and external projects need a pattern for representing parties, the roles that they play and situations in which they are involved in

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

    A situation is a complex, typically time-bound, setting, state of being, or relationship that is relatively stable for some period of time. An ontology defining such situations, including the complex property chains that link the actors and undergoers in such situations to the roles that they play is essential in finance, pharma, retail, robotics, and many other industries.

    A well-tested ontology that describes these patterns would be a useful addition to the Commons library. In addition, this ontology (and the new composition ontology on which it depends) is urgently needed for the Robotics Service Ontology (RoSO), whose planned revised submission is planned for September 2023.

    Note that the resolution of this issue requires the ontology added under COMMONS-11-4.

  • Reported: COMMONS 1.0b2 — Sat, 5 Aug 2023 22:53 GMT
  • Disposition: Resolved — $issue.fixedSpecification.name
  • Disposition Summary:

    Augment the Commons library with an ontology defining parties and situations

    The parties and situations ontology defines concepts including agent and agent role, party and party role, situation - which is a state of affairs / reified relationship that holds for some period of time, and other related roles and relations that are commonly required across many domains.

    Note that the resolution to this issue depends on resolutions to COMMONS-11-1, COMMONS-11-3, and COMMONS-11-8 have been applied first, and that sections have been renumbered and organized alphabetically by ontology name prior to applying this resolution.

  • Updated: Wed, 20 Dec 2023 15:27 GMT
  • Attachments:

Need an ontology representing multidimensional arrays

  • Status: closed  
  • 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
  • Disposition: Deferred — $issue.fixedSpecification.name
  • Disposition Summary:

    Development of an ontology for Arrays, Tensors and Vectors

    This issue will take more time and thoughtful effort to resolve, and the task force agreed to defer it as well as this aspect of quantities and units to the next revision.The new quantities and units ontology supports scalar quantities, which is what most users, including robotics, retail, and finance, need. The tensor and vector aspects are primarily used in specific disciplines of engineering.

  • Updated: Wed, 20 Dec 2023 15:27 GMT

xmi profile


Use @key instead of @Key


The properties in the collections ontology are confusing to users

  • Key: COMMONS-12
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Users are confused as to whether they need comprises or hasConstituent or hasMember or hasPart.

    In order to address this, we need to augment some of the properties with disjointness, such as between comprises and hasPart. Then we need to make clear that membership involves discrete elements and constituency may or may not involve discrete elements. hasConstituent can be used with cardinality constraints whereas hasPart cannot be due to OWL reasoning constraints.

  • Reported: Commons 1.0b1 — Fri, 12 Aug 2022 19:13 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarify the use of several properties in the Collections ontology

    Clarify the definition of properties related to inclusion, including when to use comprises vs. hasPart (which is transitive), and hasConstituent vs. hasMember (whose elements are discrete and countable), making hasConstituent and hasMember disjoint in the Collections ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

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

  • Key: COMMONS-11
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

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

  • Reported: Commons 1.0a1 — Fri, 5 Aug 2022 18:37 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Supporting this feature should be done in a user ontology, but we provide a flag for those that might need it

    The simplest way to say that only one member of a specific classification scheme can be used to classify something is to add a restriction to the concept in question. Something like

    ClassifiedItem isClassifiedBy max 1 SpecificClassifier

    where the classified item is the concept in a user ontology being classified, and specific classifier is the one from the scheme that applies. For example, suppose that the classification scheme / controlled vocabulary includes the individual paint colors that are available to customize a vehicle for purchase for some model/model year and manufacturer. A vehicle manufactured by that manufacturer that is of that model and model year can only have one color from that scheme, i.e.,

    Vehicle isClassifiedBy exactly 1 VehicleColor

    where the VehicleColor is a member of that specific scheme.

    We could complicate the classifiers ontology to add several new classes, such as ClassifiedThing, UniquelyClassifiedThing, SpecificClassificationScheme (or ExclusiveClassificationScheme) and SpecificClassifer, where the SpecificClassifier is a member of the ExclusiveClassificationScheme, where all members of the scheme are disjoint/different from one another, and where a UniquelyClassifiedThing can be classified by max 1 SpecificClassifier. The FTF agreed that this would overly complicate the ontology, though, and that commons users can add the restriction on the thing that they are classifying as needed without requiring the "clutter".

    We will provide a boolean flag, called isExclusive to allow users that need it to add such a flag to their classification scheme.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

The format of the tables throughout the specification needs improvement

  • Key: COMMONS-3
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:45 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    Most formatting issues raised in AB review were addressed via errata

    We added gutter space and separators to make the tables easier to read in a revision via errata prior to AB approval and final voting at the June meeting. Moving labels (which are the human-readable rather than camel case names) to the middle column is something that we can do once we agree on a format for ontology generation in LaTeX in a future version of this specification. The format we used for the Commons is the same as recent FIBO, LCC, and other ontology specifications until such time as we are able to automate generation of the material.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

There needs to be an additional usage note on Text in the TextDatatype ontology with a stronger warning

  • Key: COMMONS-18
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This datatype is quite useful but most free and some commercial OWL tools don't support (1) custom datatypes in OWL, and (2) rdf:langString. We need to provide a stronger warning to users who might want to extend Text with the inherent risk in doing so depending on their application and tool infrastructure.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 22:51 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add a note to Text that warns people not to use it under certain circumstances

    The current scope note doesn't go far enough to warn potential users of some of the issues with this datatype. A stronger usage note should be added in addition to the current scope note.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the abbreviation for the AboutCommons "make file

  • Key: COMMONS-16
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The AboutCommons.rdf file is a convenience file that can be used to load all of the ontologies into ontology editors such as Protege, triple stores, and other applications. The namespace prefix for this ontology does not conform to the others in terms of its structure, however. It is currently "abt-cmns" and should be "cmns-abt".

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 02:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Revise the namespace prefix for AboutCommons to be "cmns-abt"

    The namespace prefix in the beta 1 specification for this ontology is "abt-cmns", which is different in structure from all the others, which are of the form "cmns-"<ontology prefix>.

    Fixing this requires a 1 line change to the specification and a revision to the AboutCommons ontology, attached.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

CodeSet should be a subclass of arrangement

  • Key: COMMONS-19
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This is a gap, as classification scheme and identification scheme are both already subclasses of arrangement.

  • Reported: Commons 1.0b1 — Sat, 20 Aug 2022 23:10 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Make CodeSet a kind of Arrangement

    CodeSets are essentially controlled vocabularies that conform to some scheme and that are collections. Every code set is both an arrangement and a collection in other words. Thus, code set should be a subclass of arrangement.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the version IRI for all of the Commons ontologies to agree for finalization purposes

  • Key: COMMONS-14
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    This issue involves updating the version IRIs for all of the ontologies to be 20220801 for finalization

  • Reported: Commons 1.0a1 — Sat, 20 Aug 2022 00:19 GMT
  • Disposition: Closed; No Change — COMMONS 1.0
  • Disposition Summary:

    The IRI changes can be made editorially thus no vote is required.

    After discussion within members of the FTF we determined that we can make the changes to the version IRIs editorially and a vote on this issue is not required.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

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

  • Key: COMMONS-9
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

    This issue affects the Classifiers ontology, only

  • Reported: Commons 1.0a1 — Thu, 14 Jul 2022 21:44 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Loosen the restriction on Classifier from at least one to min 0

    The original restriction on the property classifies on Classifier was too restrictive, i.e., it required all classifiers to reference at least one thing that they classify. For ontologies that represent things like industry classifiers such as NAICS, the "schema", or t-box, that represents those classifiers should not be required to include them. Typically such reference data would be in a separate controlled vocabulary, or a-box, i.e. a separate ontology that is only imported when in use.

    The solution is to change a someValuesFrom owl:Thing restriction to a minCardinality 0 restriction on the property classifies on the class, Classifier.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

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

  • Key: COMMONS-2
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:40 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Augment the terms and definitions clause with a few additional high-level definitions

    Add definitions for several top-level terms used in the ontologies that may be useful for specification users.

  • Updated: Tue, 28 Mar 2023 17:31 GMT

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

  • Key: COMMONS-1
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

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

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

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 18:25 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Normalize the use of rdfs:isDefinedBy for Dublin Core and SKOS declarations

    In the case of Dublin Core annotations in the annotation vocabulary, we used rdfs:isDefinedBy to refer to the same property in the Dublin Core namespace using an abbreviated IRI followed by the local name. In the case of SKOS annotations we used rdfs:isDefinedBy to reference the entire ontology IRI for SKOS.

    The fix to this issue is to revise all of the rdfs:isDefinedBy annotations for the Dublin Core annotations to use the same approach as we did for SKOS, i.e., to refer to the ontology using the IRI for Dublin Core.

    This revision affects the machine-readable AnnotationVocabulary ontology only, and has no impact on the specification document.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Revise the definition of designation to better align with the latest version of ISO 1087

  • Key: COMMONS-26
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    The definitions of designation and name need some additional work and don't align with the ISO definitions as well as they should. The definition of designation needs clarification and the definition of name should state that it is not linguistically neutral per its usage in the standard. Also, even if we clarify name, we probably don't want it to be disjoint with identifier as it is now (needs further discussion).

  • Reported: Commons 1.0b1 — Thu, 1 Sep 2022 16:34 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Clarification of the distinctions between kinds of designators

    1. Clarified the definition of designation, denotes, and name, and better aligned them with ISO 704 / ISO 1087 in the Designations ontology
    2. Augmented the definition of a contextual name to require a context in the Contextual Designations ontology
    3. Further clarified the distinction between an identifier, contextual identifer and code / code set by adding notes, making identfies a functional property, and adding the notion of a contextual identification scheme in the Identifiers, Contextual Identifiers, and Codes and Code Sets ontologies

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

Some of the diagrams in Clause 8 are difficult to read


Some of the commons ontologies include double spaces in annotations

  • Key: COMMONS-6
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    These double 'blanks' cause minor hygiene issues when using the EDM Council's test harness and should be addressed.

  • Reported: Commons 1.0a1 — Sun, 10 Jul 2022 00:16 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Eliminate double 'spaces' in several commons ontologies

    This is a trivial update but cleans up an issue identified through the EDM Council's hygiene test environment.

    Revisions impact the machine-readable files only, and include:

    1. Elimination of a double space in the scope note on CombinedDateTime in the Dates and Times ontology
    2. Elimination of double spaces in the abstract and a note on Designation in the Designators ontology
    3. Elimination of a double space in a note on ClassificationScheme in the Classifiers ontology
    4. Elimination of a double space in a note on ContextualName in the ContextualDesignators ontology

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:

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

  • Key: COMMONS-5
  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

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

  • Reported: Commons 1.0a1 — Fri, 1 Jul 2022 19:03 GMT
  • Disposition: Resolved — COMMONS 1.0
  • Disposition Summary:

    Add examples

    The attached document includes an informative annex representing examples that we hope will be helpful to implementers of the Commons library.

  • Updated: Tue, 28 Mar 2023 17:31 GMT
  • Attachments:
    • Annex B.odt 25 kB (application/vnd.oasis.opendocument.text)

Ordering of user exception and return values

  • Legacy Issue Number: 16
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard uuid for interfaces (COM/CORBA Part A)

  • Legacy Issue Number: 680
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

CORBA section 11 struct PortableGroup::GroupInfo

  • Legacy Issue Number: 12512
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

What should Automation View accept in bounded sequences?

  • Legacy Issue Number: 683
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred Automatically

    This proposal was generated automatically.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.12: DICORBA TypeCode::kind

  • Legacy Issue Number: 685
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Standard ProgramId

  • Legacy Issue Number: 684
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 4.1.18.5 enum should be named CORBA_CompletionStatus

  • Legacy Issue Number: 681
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

VB cannot handle array out-parameters

  • Legacy Issue Number: 682
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Add CORBATCKind to end of enum list

  • Legacy Issue Number: 687
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Return value type of DICORBATypeCode::member_type should be changed

  • Legacy Issue Number: 688
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 690
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

uuid for DForeignException has an extra 0

  • Legacy Issue Number: 689
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Remove EX_repositoryID readonly property from IForeignException

  • Legacy Issue Number: 686
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

boundary violations should cause View to propagate DISP_E_OVERFLOW

  • Legacy Issue Number: 695
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-129, section 4.1.17: change term "CORBA proxy"

  • Legacy Issue Number: 697
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-129, section 4.1.17.1: retval attribute

  • Legacy Issue Number: 696
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

INSTANCE_Clone does not need an in-parameter

  • Legacy Issue Number: 698
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

ODL is erroneous

  • Legacy Issue Number: 691
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 692
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

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

  • Legacy Issue Number: 693
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

page 4-109, section 4.1.5.3: editorial

  • Legacy Issue Number: 694
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

"Safe" keyword identifier issue

  • Legacy Issue Number: 1251
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Which TypeCode operations apply to Value and ValueBox?

  • Legacy Issue Number: 1140
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (02)

  • Legacy Issue Number: 1065
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can Value type inherit from Value Box type?

  • Legacy Issue Number: 1252
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can value type inherit from Value Box type

  • Legacy Issue Number: 1055
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Automation View should generate HRESULT DISP_E_TYPEMISMATCH

  • Legacy Issue Number: 700
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.5 Interface repository (01)

  • Legacy Issue Number: 1064
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Dispatch versions of DCORBAObject and DORBObject

  • Legacy Issue Number: 699
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

describe_value() operation issue

  • Legacy Issue Number: 1258
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Missing member_kind and member_tc

  • Legacy Issue Number: 1260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Missing member_kind and member_tc

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p.6.68 boxed values of complex types map to same type

  • Legacy Issue Number: 1256
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

New lexical type - Keyword Identifie

  • Legacy Issue Number: 1253
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.3.3: can value inherit from a boxed value?

  • Legacy Issue Number: 1255
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Value type ansd Value Box"s single data member name

  • Legacy Issue Number: 1257
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Semantics of computing the hash code..

  • Legacy Issue Number: 1267
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Concrete value class

  • Legacy Issue Number: 1268
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.3 Hashing Algorythm

  • Legacy Issue Number: 1266
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (02)

  • Legacy Issue Number: 1264
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 5.6.2 Repository Id

  • Legacy Issue Number: 1263
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Repository Id (03)

  • Legacy Issue Number: 1265
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Type code issue

  • Legacy Issue Number: 1261
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Clarify the hash code algorithm

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

    Summary: Clarify the hash code algorithm

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.10 Value Factories

  • Legacy Issue Number: 1273
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7 C++ Language mapping

  • Legacy Issue Number: 1271
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Java mapping example and C++ mapping example

  • Legacy Issue Number: 1272
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Why is ValueBase a value and not a native type?

  • Legacy Issue Number: 1274
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.6 Reference Counting Mix-in Classes

  • Legacy Issue Number: 1270
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Section 7.3.5 ValueBase and Reference Counting

  • Legacy Issue Number: 1269
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-50 2nd paragraph of 5.6.2.1

  • Legacy Issue Number: 1283
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial: p 5-50

  • Legacy Issue Number: 1282
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Suggested changes (to section 5.4.1 of orbos/98-01-18) are

  • Legacy Issue Number: 1280
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Can an instance of C be passed by value to an operation that expects an A?

  • Legacy Issue Number: 1275
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

p 5-24, first paragraph of 5.3.1.3

  • Legacy Issue Number: 1279
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Editorial page 8-107

  • Legacy Issue Number: 1277
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 22:00 GMT

Keyword identifiers (01)

  • Legacy Issue Number: 1310
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can public modifier be applied to value operations?

  • Legacy Issue Number: 1284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reconcile RMI/IIOP upcall and helper class

  • Legacy Issue Number: 1286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Reconcile RMI/IIOP upcall and helper class

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No portable way to obtain list of type safe repository IDs

  • Legacy Issue Number: 1352
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword Identifiers(03)

  • Legacy Issue Number: 1312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (04)

  • Legacy Issue Number: 1313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Keyword identifiers (02)

  • Legacy Issue Number: 1311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV "chunking"

  • Legacy Issue Number: 1522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"in". "out", and "inout" modifiers on value operation parameters

  • Legacy Issue Number: 1419
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Can "public" mofifier be applied to value operations?

  • Legacy Issue Number: 1421
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Typo on page 8-107 of OBV specification

  • Legacy Issue Number: 1420
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Narrowing from abstract interfaces

  • Legacy Issue Number: 1382
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private

  • Legacy Issue Number: 1380
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Marshaling engine issue

  • Legacy Issue Number: 1353
  • Status: closed  
  • 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 it"s formal parameter. Now supposet we wish to pass a Derived value type. When marshaling the list of repository id"s, the marshaling engine has no notion of the formal type of the parameter , thus it
    does not know how many safe repository id"s it needs to marshal.

  • Reported: CORBA 2.2 — Fri, 15 May 1998 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV spec inefficient for dending large number of small objects

  • Legacy Issue Number: 1614
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Some explicit semantics seem to be missing in section5.8.6

  • Legacy Issue Number: 1615
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Forward declaration of value boxes

  • Legacy Issue Number: 1624
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes for values

  • Legacy Issue Number: 1625
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV C++ problem with "supports"

  • Legacy Issue Number: 1539
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCodes defined in section 5.8.2

  • Legacy Issue Number: 1527
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ValueMemberSeq: What is to be done with the RepositoryID parameter?

  • Legacy Issue Number: 1528
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CDR Streams

  • Legacy Issue Number: 1523
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

P 5-44: use of base type

  • Legacy Issue Number: 1697
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV TypeCode parameters wrong

  • Legacy Issue Number: 1676
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

No typecodes for abstract interfaces

  • Legacy Issue Number: 1719
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Abstract Interface issue (write_Abstract/read_Abstract)(01)

  • Legacy Issue Number: 1699
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom marshalling support for IDL fixed type

  • Legacy Issue Number: 1673
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Default constructor for Java values

  • Legacy Issue Number: 1654
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

C++ boxed value member clashes

  • Legacy Issue Number: 1674
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Boxed values need extension to write_Value call

  • Legacy Issue Number: 1650
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Status of hashed repository IDs

  • Legacy Issue Number: 1817
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"Tool" issue for IDL compilers too complex

  • Legacy Issue Number: 1932
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ValueHelper Interface issue

  • Legacy Issue Number: 1934
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypeCode complexity for value types

  • Legacy Issue Number: 1726
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Memory Management for Value Factories Unspecified

  • Legacy Issue Number: 1748
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OBV init

  • Legacy Issue Number: 1816
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeBase interface uses undefined type

  • Legacy Issue Number: 1771
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - HTTP tunnelling.

  • Legacy Issue Number: 2455
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 and elsewhere

  • Legacy Issue Number: 2584
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Title does not cover the use of SS7 as signaling transpor

  • Legacy Issue Number: 2583
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

passthrough connection

  • Legacy Issue Number: 2261
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue with TCPfirewallMechanism

  • Legacy Issue Number: 2304
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue for Firewall RTF - Chapter 5 needs clarification

  • Legacy Issue Number: 2240
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The values of these tags need to be assigned

  • Legacy Issue Number: 1996
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minimum CORBA and POA

  • Legacy Issue Number: 2676
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 4.2.1

  • Legacy Issue Number: 2591
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2586
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.5.1.1, item 3

  • Legacy Issue Number: 2588
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2589
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

It should be possible to have negative invoke ids

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

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

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 3.3.4 make factory creation operations conform to the IDL

  • Legacy Issue Number: 2585
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.3.2.1 Title and text should be changed

  • Legacy Issue Number: 2595
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 4.7.1: RelativeRoundTripPolicy

  • Legacy Issue Number: 2596
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem: Why is AssociationId a string?

  • Legacy Issue Number: 2592
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is a difference between the responder and initiator interfaces

  • Legacy Issue Number: 2594
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The current text for DialogFlowCtr is for outgoing only

  • Legacy Issue Number: 2593
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.4.1

  • Legacy Issue Number: 2599
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2600
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: Fig. 27

  • Legacy Issue Number: 2601
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Shouldn’t this section really be called TC Service Interface?

  • Legacy Issue Number: 2597
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5.2 and other sub-sections

  • Legacy Issue Number: 2598
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-Directional GIOP: which connections may be used?

  • Legacy Issue Number: 2633
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 2.3

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

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

  • Reported: CORBA 2.3 — Thu, 1 Apr 1999 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Should SIOP version number start with 1.2?

  • Legacy Issue Number: 2603
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2605
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 6.2.2

  • Legacy Issue Number: 2604
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section number: 5

  • Legacy Issue Number: 2606
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Could SIOP be changed to 7IOP, pronounced "seven-up"?

  • Legacy Issue Number: 2602
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall POA Policy does not control access

  • Legacy Issue Number: 2639
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_target

  • Legacy Issue Number: 2648
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

new_callback

  • Legacy Issue Number: 2651
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Traversal algorithm

  • Legacy Issue Number: 2641
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-Directional GIOP: Masquerade security issue needs to be more explicit

  • Legacy Issue Number: 2634
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Outgoing local port in Bi-directional IIOP

  • Legacy Issue Number: 2638
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proxified object references

  • Legacy Issue Number: 2865
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification is needed on the passing of credentials

  • Legacy Issue Number: 2867
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Reusing PASSTHRU

  • Legacy Issue Number: 2866
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How to obtain initial reference to the GIOPProxy object

  • Legacy Issue Number: 2864
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TcPdu User and Provider interfaces

  • Legacy Issue Number: 2919
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2917
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Specification Translation from ASN to IDL issue

  • Legacy Issue Number: 2918
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Traversal algorithm not sufficient

  • Legacy Issue Number: 2869
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problems with routing and/or traversal of firewalls.

  • Legacy Issue Number: 2868
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2916
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 2915
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BiDir GIOP Policy Clarification

  • Legacy Issue Number: 4115
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of PolicyType id

  • Legacy Issue Number: 3363
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allow GIOP 1.3 messages to be transported.

  • Legacy Issue Number: 3184
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing definition on security tags in the SIOP

  • Legacy Issue Number: 3314
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

There is currently no valuetype support in SIOP.

  • Legacy Issue Number: 3313
  • Status: closed  
  • Source: Dublin City University ( Robert Brennan)
  • Summary:
  • Reported: CORBA 2.3.1 — Thu, 10 Feb 2000 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use of the SSN number in the 1988 TCAP version

  • Legacy Issue Number: 2982
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Discrepancy in the changes proposed to CSIIOP and CSI modules

  • Legacy Issue Number: 7167
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP version 2.0 issue

  • Legacy Issue Number: 7168
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bidirectional Policy insufficient for persistent objects

  • Legacy Issue Number: 6313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Server Authentication

  • Legacy Issue Number: 6312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

MAIN_THREAD_MODEL questions

  • Legacy Issue Number: 4155
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Orientation

  • Legacy Issue Number: 6284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiation Session message is unwieldy

  • Legacy Issue Number: 6311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications about BiDirIds

  • Legacy Issue Number: 7225
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

paragraph limits use of BiDirOfferContext

  • Legacy Issue Number: 7224
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Negotiate Session Message Issues

  • Legacy Issue Number: 7202
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (05)

  • Legacy Issue Number: 7201
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (02)

  • Legacy Issue Number: 7198
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (03)

  • Legacy Issue Number: 7199
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (01)

  • Legacy Issue Number: 7197
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet issue (04)

  • Legacy Issue Number: 7200
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What BiDirIds shall be sent over what bidirectional connections?

  • Legacy Issue Number: 7312
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interplay of Contexts allowed in NegotiateSession messages too ill-defined

  • Legacy Issue Number: 7311
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

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

  • Legacy Issue Number: 7313
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Random BiDirIds can't be used for persistent POAs

  • Legacy Issue Number: 7310
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Connection over which BiDir offers are sent is unspecified

  • Legacy Issue Number: 7309
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall Issue: Response to failed BiDir challenge is unclear

  • Legacy Issue Number: 7308
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Firewall issue - Number of BiDirIds in a BiDirOffer

  • Legacy Issue Number: 7307
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

use and interpretation of BI_DIR_GIOP_ACCEPT ambiguous

  • Legacy Issue Number: 7353
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Limitation and ambiguity in the use of BidirectionalOfferPolicy of DENY

  • Legacy Issue Number: 7351
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bi-directional connections considered volatile at connection acceptor side

  • Legacy Issue Number: 7352
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

connection_complete field of the FirewallPathRespContext is under specified

  • Legacy Issue Number: 7317
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How many BI_DIR_GIOP_OFFER service contexts are allowed

  • Legacy Issue Number: 7318
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Targets of Export and Offer Policies incompletely specified

  • Legacy Issue Number: 7315
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Expected behavior of a non-conformant implementation

  • Legacy Issue Number: 7316
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Processing of NegotiateSession messages at various stages of connection set

  • Legacy Issue Number: 7314
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Multiple objects on a stream

  • Legacy Issue Number: 22
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of stream portability

  • Legacy Issue Number: 21
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Lifecycle Key type definition

  • Legacy Issue Number: 18
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Stream contexts and internalization

  • Legacy Issue Number: 19
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Start and end of context tags

  • Legacy Issue Number: 20
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

when is a connection a "bi-directional connection"?

  • Legacy Issue Number: 7356
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    The discussion on when to send BiDirIds over connections is floundering.
    In part, I think this is due to a lack of precision in our thinking (and more
    importantly in the adopted firewall spec we are working from).

    When does a GIOP connection become bi-directional? The implementation
    of the connection-initiator protocol engine must know this. Before this
    event it has to treat a GIOP Request message as a protocol error and after
    the event it has to dispatch the request.

    There seems to be an assumption (or more than one) that there is a
    relationship between an Object Reference (i.e. the programming language
    artefact representing CORBA::Object) and a GIOP connection.

    Whilst it is true that an implementation of the CORBA spec will provide a
    relationship (else an invocation cannot result in a GIOP Request message)
    the particular relationship was left to ORB implementers to provide for
    flexibility of implementation. Specifically, such a relationship is not prescribed
    in the CORBA specification (nor should it be).

    I suggest it would be dangerous to define a GIOP connection to change state
    when an Object Reference that (in some ill-defined way) "points to" a server
    that is the target of that connection, undergoes a policy change (i.e. its BiDir
    Offer policy is set to Allow).

    Instead, a GIOP connection presumably becomes bi-directional when an
    invocation on an Object Reference, with an effective Offer Policy of Allow, results
    in a Request message being sent over that connection.

    The specification must be explicit over which event causes the connection to
    become bi-directional.

    Also, can a connection cease to be bi-directional? For example if either the
    Object Reference invoked above or the POA with "Export = Allow" are destroyed.
    Again this would appear to be fraught with problems, leading to the assumption
    that the GIOP connection, once bi-directional, remains bi-directional until it is
    closed.

    Lastly, the closing of idle connections and the subsequent re-connection has
    hitherto been a matter for ORB implementers (Messaging::RebindPolicy not
    withstanding). This is unfortunate as an application won't be aware of the ORB
    having conserved resources in this way and the ORB should not be expected to
    provide session semantics that span multiple tcp connections (this is currently
    stated in the description of NegotiateSession).

  • Reported: UML 2.0 — Tue, 18 May 2004 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Coordinator remembering LockCoordinator

  • Legacy Issue Number: 59
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Input values for "which" arg of non-trans. LockCoordinator

  • Legacy Issue Number: 60
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Freeing of locks at the end of a transaction

  • Legacy Issue Number: 58
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Getting the thread ID in a non-transactional lock request

  • Legacy Issue Number: 57
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Communication failure issue

  • Legacy Issue Number: 56
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Timeout while locking

  • Legacy Issue Number: 47
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service

  • Legacy Issue Number: 476
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 473
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 472
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Wed, 8 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosGraphs::deep

  • Legacy Issue Number: 469
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Common format on stream

  • Legacy Issue Number: 466
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

performing a compound copy of relationship

  • Legacy Issue Number: 470
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

${issue.summary}

  • Legacy Issue Number: 471
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 1.2 — Thu, 9 Jan 1997 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using local thread identification for concurrency

  • Legacy Issue Number: 61
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Internalizing roles-IDL optimization

  • Legacy Issue Number: 706
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Who is responsible for releasing locks in transaction?

  • Legacy Issue Number: 578
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Purpose of related LockSet

  • Legacy Issue Number: 576
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (3)

  • Legacy Issue Number: 478
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Which model should ConcurrencyControl support?

  • Legacy Issue Number: 577
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosCompoundExternalization Service (2)

  • Legacy Issue Number: 477
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- finding index

  • Legacy Issue Number: 6
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query Collection::Collection -- Sharing State

  • Legacy Issue Number: 5
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How do IteratorObjs and CollectionObjs share state?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Circular References in CosStream and CosCompoundExternalization

  • Legacy Issue Number: 1401
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- membership scoping

  • Legacy Issue Number: 3
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Adding multiple elements

  • Legacy Issue Number: 4
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Questions on CosQuery::QueryableCollection interfaces

  • Legacy Issue Number: 13
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarifications on interfaces which support QueryableCollection.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- reset() exceptions

  • Legacy Issue Number: 10
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- keyed collections

  • Legacy Issue Number: 12
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- next_n()

  • Legacy Issue Number: 11
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- destroy methods

  • Legacy Issue Number: 9
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- Iterator Position Invalid

  • Legacy Issue Number: 7
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

QueryCollection::Collection -- iterator updating

  • Legacy Issue Number: 8
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Query language for operations

  • Legacy Issue Number: 83
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Definition of NULL in datafiles without NULL as a concept

  • Legacy Issue Number: 80
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Delegating iterator functionality to the RDBMS

  • Legacy Issue Number: 82
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Clarification request for section 11.1.5

  • Legacy Issue Number: 79
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

retrieve_element

  • Legacy Issue Number: 81
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How does this operation work?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How do iterators handle changing of the data they are pointing at

  • Legacy Issue Number: 78
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Use of MD5 on arguments

  • Legacy Issue Number: 23
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Updating information via query iterators

  • Legacy Issue Number: 69
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Inconsisten IDL in the Minimum CORBA chapter

  • Legacy Issue Number: 4216
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

TypedConsumerAdmin interface (4.9.2))

  • Legacy Issue Number: 961
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Correction of CORBA specification (page 18-51)

  • Legacy Issue Number: 3342
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

WWW Form output

  • Legacy Issue Number: 535
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface QueryEvaluator {

  • Legacy Issue Number: 575
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Malformed PropertyName

  • Legacy Issue Number: 284
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

OQS relation to POS

  • Legacy Issue Number: 84
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

COM/CORBA keywords

  • Legacy Issue Number: 2009
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosExternaliazation Service (bug?)

  • Legacy Issue Number: 4188
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ObjectCreationError and Nofactory exceptions in Externilazition

  • Legacy Issue Number: 1293
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CosConsurrencyControl service bug or not?

  • Legacy Issue Number: 3522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Compiler being able to translate from OMG-IDL into ANSI

  • Legacy Issue Number: 184
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Unclear and possibly harmful consequences of mandatory annotation definitions

  • Legacy Issue Number: 19738
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Fixed Types in COM

  • Legacy Issue Number: 4507
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does DynValue handle derived valuetypes?

  • Legacy Issue Number: 5467
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Spec doesn't make clear what is valid mix of policies and what is invalid

  • Legacy Issue Number: 5624
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

messaging router issue

  • Legacy Issue Number: 5621
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetypes and local interfaces

  • Legacy Issue Number: 6318
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 22.2.4.6 interface RelativeRoundtripTimeoutPolicy

  • Legacy Issue Number: 6424
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.02, page 11-25, section 11.3.6

  • Legacy Issue Number: 6899
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

module SendingContext

  • Legacy Issue Number: 7340
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rules for marshalling ValueBoxes

  • Legacy Issue Number: 5899
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

BNF changes

  • Legacy Issue Number: 5952
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Problem with ServerRequestInterceptor::receive_request and DSI

  • Legacy Issue Number: 5895
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

restriction of where a valuetype chunk can end

  • Legacy Issue Number: 5892
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad text in 22.6 mandates Routing for sendc/sendp

  • Legacy Issue Number: 5856
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

What is the RSC when using a PersistentPoller

  • Legacy Issue Number: 5781
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Messaging Routing Protocol is broken for GIOP 1.0 & 1.1

  • Legacy Issue Number: 5662
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7730
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

methods on the POA

  • Legacy Issue Number: 7890
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add a typedef for the POAManager id

  • Legacy Issue Number: 7892
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

An extension of IOR to protect target objects Nature

  • Legacy Issue Number: 7592
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Mapping from -ORBxxx to Java properties does not work for -ORBInitRef

  • Legacy Issue Number: 6007
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The POA state inactive is not used consistent.

  • Legacy Issue Number: 7955
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA 3.0.3 ch. 3.4 OMG IDL Grammar

  • Legacy Issue Number: 7978
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

argument of the set_servant call has a small typo

  • Legacy Issue Number: 7896
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.3.13

  • Legacy Issue Number: 8221
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

change in the POAManager

  • Legacy Issue Number: 7893
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue: CSIv2 Identity Assertion

  • Legacy Issue Number: 3907
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Polymorphic Valuetypes and the DII

  • Legacy Issue Number: 3674
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

DynValue & custom valuetypes

  • Legacy Issue Number: 3459
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Code Set Conversion on Operations

  • Legacy Issue Number: 8244
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Potential deadlock with POA::deactivate_object()

  • Legacy Issue Number: 2772
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Custom Value Marshaling Issue

  • Legacy Issue Number: 3097
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Appendix A

  • Legacy Issue Number: 8230
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ForwardRequest is impossible to detect in clients

  • Legacy Issue Number: 5266
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Avoiding RSC/TSC copy on server side

  • Legacy Issue Number: 4169
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Implications of any/valuetype marshalling

  • Legacy Issue Number: 4137
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal for extension to CosNaming

  • Legacy Issue Number: 5214
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

New issue: ForwardRequest()

  • Legacy Issue Number: 5231
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

How does an ORB implement Object::get_policy for PI defined policies?

  • Legacy Issue Number: 4065
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

rule (85) is misplaced

  • Legacy Issue Number: 15715
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

processing TaggedComponents within an IOR

  • Legacy Issue Number: 5439
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Bad quotes and imported dot

  • Legacy Issue Number: 15714
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

missing document title

  • Legacy Issue Number: 15713
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.8.1

  • Legacy Issue Number: 12551
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

move struct to IOP module

  • Legacy Issue Number: 12550
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add create_policy with just the type as argument

  • Legacy Issue Number: 17208
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context should be local interface

  • Legacy Issue Number: 16996
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Make anonymous types illegal

  • Legacy Issue Number: 16047
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Redundant bullet

  • Legacy Issue Number: 16942
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

interface ORB should be local

  • Legacy Issue Number: 16315
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • 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: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.13

  • Legacy Issue Number: 10817
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

16.10 lists register_initial_reference

  • Legacy Issue Number: 13056
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7.3

  • Legacy Issue Number: 12555
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add CORBA::ORB::arg_list

  • Legacy Issue Number: 12773
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add interface ORB { Object string_to_object ( in wstring str ); };

  • Legacy Issue Number: 12857
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 13.7 ServiceContext

  • Legacy Issue Number: 12559
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Part 2, Chapter 11 - MIOP

  • Legacy Issue Number: 12376
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

definition of Invalid Policies changed

  • Legacy Issue Number: 12229
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

mention of (deprecated) function get_implementation removed from text

  • Legacy Issue Number: 12230
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::ReplyStatus to a real enum

  • Legacy Issue Number: 11514
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Proposal to change PortableInterceptor::AdapterState to a real enum

  • Legacy Issue Number: 11515
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 15.4.2/16.4.1

  • Legacy Issue Number: 11332
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Third line of 23.1.3.4, ACTIVE must be bold

  • Legacy Issue Number: 11525
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.10.1

  • Legacy Issue Number: 11161
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing PolicyValue encoding instructions

  • Legacy Issue Number: 18152
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    Section 17.3.1 of CORBA 3.1 / 3.2 says:

    17.3.1 Structures

    PolicyValue

    This structure contains the value corresponding to a Policy of the
    PolicyType indicated by its ptype. This representation allows the
    compact transmission of QoS policies within IORs and Service
    Contexts. **The format of pvalue for each type is given in the
    specification of that Policy.**

    When the ZIOP 1.0 specification describes the ZIOP policies, it does not
    give the format for pvalue.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL (2)

  • Legacy Issue Number: 18151
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, Annex A has:

    Compressor get_compressor(
    in CompressorId compressor_id,
    in CompressorLevel compression_level)
    raises (UnknownCompressorId);

    CompressorLevel should be CompressionLevel.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Two typo's in Annex A.4

  • Legacy Issue Number: 17273
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Invalid IDL

  • Legacy Issue Number: 18150
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    In the ZIOP 1.0 specification, the IDL in Annex A has:

    typedef unsigned short CompressorId { };

    The braces are invalid and should be removed.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

struct PolicyValue

  • Legacy Issue Number: 12549
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 7.4

  • Legacy Issue Number: 8630
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Moving *Seq typedefs into ORB chapter

  • Legacy Issue Number: 8586
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Minor code ambiguity

  • Legacy Issue Number: 8618
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Missing size information for decompress()

  • Legacy Issue Number: 18153
  • Status: closed  
  • Source: grisby.org ( Duncan Grisby)
  • Summary:

    The ZIOP body format contains the original length of the compressed
    data, which is important because it allows the compressor to efficiently
    allocate a buffer to uncompress it. Unfortunately, the
    Compressor::decompress() operation is not given that size, meaning that
    it has to guess how big the uncompressed data will be.

    The original data size should be given to the decompress() operation.
    One way to do that without changing the operation signature would be to
    specify that the inout Buffer target sequence should have its length
    pre-populated to the expected size.

  • Reported: ZIOP 1.0 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • 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: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.7

  • Legacy Issue Number: 8843
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

update the spec to not used anonymous types

  • Legacy Issue Number: 8783
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.9.1

  • Legacy Issue Number: 8844
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.4.3.1

  • Legacy Issue Number: 8856
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2 (02)

  • Legacy Issue Number: 8633
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.2

  • Legacy Issue Number: 8632
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 13.6.2

  • Legacy Issue Number: 8631
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

FullInterfaceDescription and base_interfaces question

  • Legacy Issue Number: 9140
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing mutual recursion for IDL structs - clarification needed

  • Legacy Issue Number: 10558
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CORBA Exceptions

  • Legacy Issue Number: 9618
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9.16

  • Legacy Issue Number: 9460
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 11.3.9

  • Legacy Issue Number: 9016
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.16/

  • Legacy Issue Number: 9075
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-43

  • Legacy Issue Number: 9112
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 22.11.1

  • Legacy Issue Number: 9082
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 7-7

  • Legacy Issue Number: 8881
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 9-1

  • Legacy Issue Number: 8879
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Page: 21-5

  • Legacy Issue Number: 8874
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 21.3.14.11

  • Legacy Issue Number: 8862
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: 4.5.2

  • Legacy Issue Number: 8860
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Appendix A

  • Legacy Issue Number: 8864
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.8 The simple Element, page 69-538

  • Legacy Issue Number: 5508
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 9, Chapter 5

  • Legacy Issue Number: 8986
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section: Chapter 11

  • Legacy Issue Number: 8985
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Allowing Mutual Recursion for IDL Structures

  • Legacy Issue Number: 8969
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

NVList Section: 7.5

  • Legacy Issue Number: 8929
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5515
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 Software Package Descriptor

  • Legacy Issue Number: 5514
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Add the capability to define a component artifact property

  • Legacy Issue Number: 5513
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.9 The sequence Element

  • Legacy Issue Number: 5511
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Test Property - add a test property definition to the properties DTD

  • Legacy Issue Number: 5512
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.3 The choices Element, page 69-537

  • Legacy Issue Number: 5510
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The range Element, pages 69-537/538

  • Legacy Issue Number: 5509
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Component Artifact Dependency

  • Key: CORBA34-96
  • Legacy Issue Number: 5522
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LWCCM issue - Section 1.5.3 Exclusion

  • Key: CORBA34-95
  • Legacy Issue Number: 6254
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.25 The propertyfile Element, page 69-482

  • Legacy Issue Number: 5518
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.2 The author Element, page 69-474

  • Key: CORBA34-97
  • Legacy Issue Number: 5521
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.14 The idl Element, page 69-478

  • Key: CORBA34-99
  • Legacy Issue Number: 5519
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Descriptor

  • Key: CORBA34-98
  • Legacy Issue Number: 5520
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.8.2.7 The code Element, pages 69-474

  • Legacy Issue Number: 5516
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3.2.15 The implementation Element, pages 69-478/479

  • Legacy Issue Number: 5517
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage type

  • Key: CORBA34-89
  • Legacy Issue Number: 7131
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - entity components

  • Key: CORBA34-91
  • Legacy Issue Number: 7129
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - persistence

  • Key: CORBA34-92
  • Legacy Issue Number: 7128
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - section 4.1.2

  • Key: CORBA34-90
  • Legacy Issue Number: 7130
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - transaction

  • Key: CORBA34-94
  • Legacy Issue Number: 7126
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - security

  • Key: CORBA34-93
  • Legacy Issue Number: 7127
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - abstract storage home

  • Key: CORBA34-88
  • Legacy Issue Number: 7132
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - CIDL

  • Key: CORBA34-87
  • Legacy Issue Number: 7133
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - locator

  • Key: CORBA34-86
  • Legacy Issue Number: 7141
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - segmentation

  • Key: CORBA34-85
  • Legacy Issue Number: 7142
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - home finders and finder operations

  • Key: CORBA34-79
  • Legacy Issue Number: 7148
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - proxy homes

  • Key: CORBA34-80
  • Legacy Issue Number: 7147
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - invalid rows

  • Key: CORBA34-78
  • Legacy Issue Number: 7149
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - primary key

  • Key: CORBA34-83
  • Legacy Issue Number: 7144
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - get_all_facet, ...

  • Key: CORBA34-84
  • Legacy Issue Number: 7143
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Section 4.1

  • Key: CORBA34-82
  • Legacy Issue Number: 7145
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - configurators

  • Key: CORBA34-81
  • Legacy Issue Number: 7146
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Checking XML DTD elements related to the trader service

  • Key: CORBA34-71
  • Legacy Issue Number: 5590
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Description for the impltype Element?

  • Key: CORBA34-72
  • Legacy Issue Number: 5589
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Uses Relationships

  • Key: CORBA34-74
  • Legacy Issue Number: 5524
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

69.3 AssemblyFactory Interface

  • Key: CORBA34-73
  • Legacy Issue Number: 5576
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Device Artifact Dependency

  • Key: CORBA34-75
  • Legacy Issue Number: 5523
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Dependency on D+C FTF

  • Key: CORBA34-76
  • Legacy Issue Number: 7363
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

lwCCM issues - Entity2Context

  • Key: CORBA34-77
  • Legacy Issue Number: 7150
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

A new exception specification is needed for CCM2Context::req_passivate()

  • Key: CORBA34-68
  • Legacy Issue Number: 5639
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM IDL style inconsistency

  • Key: CORBA34-65
  • Legacy Issue Number: 5858
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Derived component supported interface restriction (formal/2002-06-65)

  • Key: CORBA34-66
  • Legacy Issue Number: 5688
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Issue on the description of the consumesidentifier element

  • Key: CORBA34-67
  • Legacy Issue Number: 5684
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Using Configurator on CCMHome or any CORBA objects?

  • Key: CORBA34-70
  • Legacy Issue Number: 5591
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

[CCM] Interface Repository Metamodel

  • Key: CORBA34-69
  • Legacy Issue Number: 5594
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • 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: CORBA34-59
  • Legacy Issue Number: 5903
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.10 (page 6-26)

  • Key: CORBA34-60
  • Legacy Issue Number: 5902
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM spec: insufficient examples of component attributes

  • Key: CORBA34-62
  • Legacy Issue Number: 5898
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

multiple lifetime policies declaration issue

  • Key: CORBA34-64
  • Legacy Issue Number: 5870
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

3.2.7 Compositions with Managed Storage

  • Key: CORBA34-63
  • Legacy Issue Number: 5871
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Section 6.4.5.52 (page 6-38)

  • Key: CORBA34-61
  • Legacy Issue Number: 5900
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

'local executor mapping'

  • Key: CORBA34-56
  • Legacy Issue Number: 5937
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

portability of CCM descriptors

  • Key: CORBA34-55
  • Legacy Issue Number: 6286
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-54
  • Legacy Issue Number: 6672
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

issue on component supporting abstract interfaces

  • Key: CORBA34-58
  • Legacy Issue Number: 5910
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCM Spec: attributes are listed in the ports section?

  • Key: CORBA34-57
  • Legacy Issue Number: 5918
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a set_persistent_object method

  • Key: CORBA34-48
  • Legacy Issue Number: 7732
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a set_context method

  • Key: CORBA34-47
  • Legacy Issue Number: 7733
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic connectivity for Receptacles, Emitters, Publishers

  • Key: CORBA34-49
  • Legacy Issue Number: 7556
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-50
  • Legacy Issue Number: 6689
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

EnterpriseComponent should have a get_servant method

  • Key: CORBA34-51
  • Legacy Issue Number: 6688
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The association of entity component primary key and PSS key is unclear

  • Key: CORBA34-52
  • Legacy Issue Number: 6684
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeExecutorBase should have a get_servant method

  • Key: CORBA34-53
  • Legacy Issue Number: 6673
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Contradictory sections in the CCM and Lightweight CCM specifications

  • Key: CORBA34-44
  • Legacy Issue Number: 10142
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

spec should define how the base class of an executor is generated by the framework

  • Key: CORBA34-41
  • Legacy Issue Number: 14026
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The LwCCM removes the usage of cidl from CCM, but this looses also the fixed name of the base class of the executor. The spec should define how the base class of an executor is generated by the framework, so that the implementor of the executor can write a portable executor

  • Reported: ZIOP 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The D&C IDL part doesn't match 06-04-02.

  • Key: CORBA34-43
  • Legacy Issue Number: 10582
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add a sequence of CCMHome typedef sequence CCMHomes;

  • Key: CORBA34-42
  • Legacy Issue Number: 13151
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

add some feature to let an assembly look like a monolithic compoment

  • Key: CORBA34-46
  • Legacy Issue Number: 9173
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

"supports" keyword

  • Key: CORBA34-45
  • Legacy Issue Number: 9174
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

two not used and document exceptions listed

  • Key: CORBA34-36
  • Legacy Issue Number: 15052
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM we have the following exceptions

    exception LastConfiguration {
    };

    exception InvalidReference {
    };

    LastCOnfiguration is not listed at all in 06-04-01 and 06-04-02

    InvalidReference is listed in 06-04-02 in text and diagrams, but not in idl at all

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Event mechanism proposal

  • Key: CORBA34-38
  • Legacy Issue Number: 14087
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CCM spec describes the event mechanism default part of CCM. We want to propose to change this event machine to a connector based model as part of the DDS4CCM specification. Then there would be an event connector and the container then is much more light weight and easier to use. People that don't want to use CORBA event machinisms don't pull in all the dependent code

  • Reported: ZIOP 1.0b1 — Tue, 21 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

typedef CCMObjectSeq

  • Key: CORBA34-39
  • Legacy Issue Number: 14064
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 10.3.1.2 the typedef CCMObjectSeq is listed, we propose to move it to Section 6.11.1 just after the definition of CCMObject

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

The spec mentions InvalidConfiguration as exception but there is no idl in this spec

  • Key: CORBA34-40
  • Legacy Issue Number: 14061
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec mentions InvalidConfiguration as exception but there is no idl in this spec that describes this exception and its members

  • Reported: ZIOP 1.0b1 — Wed, 8 Jul 2009 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

ResourceCommitmentManager lacking

  • Key: CORBA34-37
  • Legacy Issue Number: 15051
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL file 07-02-01 related to CCM is lacking ResourceCommitmentManager

  • Reported: ZIOP 1.0 — Tue, 16 Feb 2010 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_components method

  • Key: CORBA34-31
  • Legacy Issue Number: 6438
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CCMHome should have a get_container method

  • Key: CORBA34-32
  • Legacy Issue Number: 6001
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Incorrect statement that implies that connect_consumer returns a cookie

  • Key: CORBA34-33
  • Legacy Issue Number: 15960
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    In chapter 6.6.8, sub paragraph "connect_consumer" the following statement is given:

    The cookie return value can be used to disconnect from the source.

    I think that this sentence should be removed from the specification since connect_consumer is declared as follows:

    void connect_consumer (
    in FeatureName emitter_name,
    in EventConsumerBase consumer)
    raises (InvalidName, AlreadyConnected,
    InvalidConnection);

    Also, disconnect_consumer doesn't provide a cookie as input parameter.

  • Reported: ZIOP 1.0 — Fri, 14 Jan 2011 05:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfiguration::set_configuration_values should document exception

  • Key: CORBA34-34
  • Legacy Issue Number: 15164
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    HomeConfiguration::set_configuration_values documentation should mention which exception to thrown when an any/name value pair has a not supported name or when the any can't be extracted

  • Reported: ZIOP 1.0 — Wed, 7 Apr 2010 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Interface Introspection

  • Key: CORBA34-25
  • Legacy Issue Number: 6391
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Generic port connections

  • Key: CORBA34-27
  • Legacy Issue Number: 5852
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.4.3.3 Exclusion

  • Key: CORBA34-26
  • Legacy Issue Number: 7027
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

HomeConfigurator should not extend CCMHome

  • Key: CORBA34-29
  • Legacy Issue Number: 5769
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Session2Context interface

  • Key: CORBA34-30
  • Legacy Issue Number: 5909
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

LwCCM issue - Section 1.6.8 Exclusion

  • Key: CORBA34-28
  • Legacy Issue Number: 7028
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 and page 1-21 - editorial

  • Key: CORBA34-19
  • Legacy Issue Number: 5945
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

Change new GIOP Negotiate Session Message to Firewall Specific

  • Key: CORBA34-23
  • Legacy Issue Number: 6285
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

GIOP Conformance and Interceptors

  • Key: CORBA34-22
  • Legacy Issue Number: 6314
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

context interface for home implementation

  • Key: CORBA34-21
  • Legacy Issue Number: 5936
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

page 1-20 the description of the get_connection operation

  • Key: CORBA34-20
  • Legacy Issue Number: 5944
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

CodeSet and CSIv2 Negotitaion

  • Key: CORBA34-24
  • Legacy Issue Number: 6283
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:59 GMT

valuetype fragmentation ambiguous

  • Key: CORBA34-13
  • Legacy Issue Number: 5941
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Clarification on multi-threaded codeset negotiation

  • Key: CORBA34-14
  • Legacy Issue Number: 5880
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

15.3.3 - codesets must be "explicitly defined"

  • Key: CORBA34-15
  • Legacy Issue Number: 6050
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

[Components] Contradiction between IDL and Interface Repository concerning

  • Key: CORBA34-16
  • Legacy Issue Number: 6671
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Chapter/section: 15.4.2.2 "Request Body"

  • Key: CORBA34-17
  • Legacy Issue Number: 6287
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

page 1-20 second bullet of the description of the disconnect operation

  • Key: CORBA34-18
  • Legacy Issue Number: 5943
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Duplicate union labels

  • Key: CORBA34-7
  • Legacy Issue Number: 704
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

COM Sequence changes

  • Key: CORBA34-6
  • Legacy Issue Number: 703
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Changes to ForeignComplexType

  • Key: CORBA34-8
  • Legacy Issue Number: 701
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.5.2: Editorial

  • Key: CORBA34-9
  • Legacy Issue Number: 708
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13A.2.3: editorial

  • Key: CORBA34-10
  • Legacy Issue Number: 707
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Capter 13C: Editorial

  • Key: CORBA34-11
  • Legacy Issue Number: 709
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Incorrect mappings for systems exceptions (part A)

  • Key: CORBA34-12
  • Legacy Issue Number: 679
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Section 13C.1.3 Editorial

  • Key: CORBA34-5
  • Legacy Issue Number: 710
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Levels of Indirection for passing COM types

  • Key: CORBA34-4
  • Legacy Issue Number: 702
  • Status: closed  
  • Source: Foretuit ( Daniel Foody)
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Mon, 25 Aug 1997 04:00 GMT
  • Disposition: Deferred — CORBA 3.4
  • Disposition Summary:

    Deferred

    This proposal was generated automatically by request of the Task Force Chair Adam Mitz.

  • Updated: Wed, 1 Feb 2023 21:58 GMT

Additions for convenience methods

  • Key: CSRM-14
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The following changes are proposed (note that there are some changes from the original proposal to make it more complete and correct):

    Changes to: 7.6.3 ExtRequirement
    1) add /validatedBy:ValidationActivity[0..*]
    Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    2) add getValidatedBy():ValidationActivity[0..*]
    documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

    Changes to: 7.6.3 VerificationActivity
    add:
    verifies : AbstractRequirement[0..*] - The requirements that this VerificationActivity verifies.
    add to doc (was already part of profile):
    verificationMethod : VerificationMethodKind -The verificationMethod indicates the primary method that «VerificationActivity» uses to verify a Requirement.

    added

    getVerifies():AbstractRequirement[0..*]
    Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    Documentation: The query getVerifies() returns all AbstractRequirement that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

    Change to: Figure 7 SysML Extensions Profile
    Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

    Change to: Figure 5 Validation and Verification Profile
    Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

  • Reported: CSRM 1.0b2 — Fri, 22 Apr 2022 20:31 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add derived properties and methods to improve usability.

    Add elements and add a clarifying note to model and specification:

    Changes to ExtRequirement

    1) add /validatedBy:ValidationActivity[0..*]
    Documentation: The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    2) add getValidatedBy():ValidationActivity[0..*]
    documentation: The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    specification: Validate.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier

    Note about this change: First, this is intended to mirror the same pattern as SysML. Second, the verifies and verifiedBy already exists in abstractRequirement. Because Verifies is a kind of Verify, no change is required.

    Changes to VerificationActivity
    1) add /verifies:VerificationActivity[0..*]
    2) add getVerifies():VerificationActivity[0..*]
    Specification: Verification.allInstances()->select(base_Abstraction.client=ref).base_Abstraction.supplier
    Documentation: The query getVerifies() returns all the NamedElements that are suppliers ( "to" end of the concrete syntax ) of a «Verifies» relationship whose client is the element input parameter, ref. This is a static query.

    Change to: Figure 7 SysML Extensions Profile
    Update diagram to reflect the addition of /validatedBy:ValidationActivity[0..*] element on the ExtRequirement Stereotype.

    Change to: Figure 5 Validation and Verification Profile
    Update diagram to show the addition of /verifies:AbstractRequirement[0..*] on the VerificationActivity stereotype.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Add comments to 7.6.3 ExtRequirement source/Risk elements

  • Key: CSRM-31
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 21:53 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    *Add comments to 7.6.3 ExtRequirement *

    Add the following text to 7.6.3 after the Generalization section. To be clear, when complete with all changes we have for 7.6.3, paragraph should look like this:

    Description
    The «ExtRequirement» is a mix-in stereotype that contains generally useful attributes for requirements.
    Note: This stereotype should be used instead of the «extendedRequirement» in the SysML non-normative extension of SysML
    Generalization:
    • SysML::Requirements::Requirement
    Attributes
    • risk : RiskKind - Risk level of the requirement.
    • source : String - Source (originating person and/or organization) of the requirement.
    • /validatedBy : ValidationActivity[0..*] - The validatedBy is derived from all elements that are the client of a «validation» relationship for which this requirement is a supplier.
    Operations:
    • getValidatedBy - The query getValidatedBy() returns all the NamedElements that are suppliers ( "to" end) of a «Validation» relationship whose client is the element input parameter, ref.
    specification:
    Validate.allInstances()->select(base Abstraction.client=ref).base_Abstraction.supplier

  • Updated: Tue, 27 Sep 2022 12:48 GMT

MeasurementSpecification missing documentation

  • Key: CSRM-28
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:38 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add documentation to summary and fix documentation in summary

    Add/change documentation as follows to the model and to the specification:

    MeasurementSpecification.summary
    add documentation: The summary is a textual description of constraints, and measurement activities used to provide insight into the progress made in the definition and development of the technical solution, risks, and issues.

    MeasurementSpecification.id
    From: The unique id of the requirement.
    to: The id of the MeasurementSpecification.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

VerificationActivity missing documentation on verificaionMethod

  • Key: CSRM-26
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    VerificationActivity.verificationMethod is missing documentation.

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

  • Reported: CSRM 1.0a1 — Sat, 30 Apr 2022 19:13 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    add documentation to VerificationMethod and show attributes of VerificationActivity

    Change to: 7.4.3 VerificationActivity
    Add the following text to 7.4.3:
    In the profile, add documentation to the verifies attribute of <<VerificationActivity>>:

    The requirements that this VerificationActivity verifies.

    Add previously undocumented attributes (verificationMethod and verifies) of <<VerificationActivity>>: to the specification by adding the revised text to paragraph 7.4.3.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change 7.6 SysML Extentions

  • Key: CSRM-3
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:51 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    No change to 7.6 SysML Extensions is required

    No change to 7.6 SysML Extensions is required.

    The creation of an official version of SysML Extensions seems unwise as all the vendors and lots of users would be affected. The current profile described in this section is adequate for our purposes.

    Note: We already voted on this, but having to recreate it because the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Add relationship convenience attribute for Validated and other relationships

  • Key: CSRM-2
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:38 GMT
  • Disposition: Duplicate or Merged — CSRM 1.0
  • Disposition Summary:

    Issue resolved in CSRM-14

    CSRM-2 was re-opened to change the priority (I did not realize this could be modified), CSRM-14 essentially duplicates the issue and was already resolved. Best thing to do is to close this issue as a duplicate of CSRM-14.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

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

  • Key: CSRM-41
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

    This line in paragraph 2 should be removed:

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

    Reported by Pete Rivett during FTF review.

  • Reported: CSRM 1.0a1 — Fri, 17 Jun 2022 19:49 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Remove the following text in section 2 Conformance

    Remove the following text in section 2 Conformance

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

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Clarify usage of Group stereotype

  • Key: CSRM-35
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

  • Reported: CSRM 1.0a1 — Thu, 16 Jun 2022 13:46 GMT
  • Disposition: Resolved — CSRM 1.0
  • Disposition Summary:

    Add Clairifying info and paragraph to documentation of 7.1.12 Group

    Change the existing documentation of 7.1.12 Group to help understand how the element is used and examples of use.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change names from CubeSat to Satellite

  • Key: CSRM-11
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    The original issue is perhaps incorrect as I misunderstood the intent. The name changes were to additions to the spec. I am proposing to close with no change as only CubeSatRequirement actually exists and a SatelliteRequirement is there if desired by a user of the profile.

  • Reported: CSRM 1.0b2 — Thu, 21 Apr 2022 20:06 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Incorrectly submitted issue was against a future plan

    JD complained that the priority was incorrect. Changed priority to trivial.
    This was originally written up as a bug of initial submission, but it is actually against a proposed plan, not the current version. It is therefore immaterial to the changes of the FTF, so Closed: No Change.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Remove Section 0 (zero)

  • Key: CSRM-17
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Remove section 0 (zero) from finalized specification.

  • Reported: CSRM 1.0b2 — Fri, 22 Apr 2022 20:47 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Change already made by OMG editor

    Added the task without realizing that taskj already performed by OMG editor. No change required

  • Updated: Tue, 27 Sep 2022 12:48 GMT

This issue created by mistake

  • Key: CSRM-8
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    This issue created by mistake

  • Reported: CSRM 1.0b2 — Thu, 21 Apr 2022 18:24 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Removal of incorrectly created subtask

    Parent task is closed; No Change, so doing the same with sub task.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Recommended Additions

  • Key: CSRM-12
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

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

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

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

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

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

    An Issue that Needs Resolution.

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

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

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

  • Reported: CSRM 1.0a1 — Thu, 21 Apr 2022 20:21 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Defer to RTF

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Add constraints to aid in correctness of profile useage

  • Key: CSRM-4
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:00 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer adding constraints to RTF

    This is rather complex and our team does not have the resources to address. It is also better to address the constraints as people begin to use the profile and as RTF possibly expands the standard.

    Note: We already voted on this in Ballot #1, but the result was lost.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Change names from CubeSat to Satellite.

  • Key: CSRM-9
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

    Dave Kaslow proposes the following changes to stereotypes:

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

    Document attached was where the issue was raised.

  • Reported: CSRM 1.0b1 — Thu, 21 Apr 2022 19:43 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Issue created by mistake

    This issue related to a proposal and this was mistakingly created against the FTF. Closing with no change required.

  • Updated: Tue, 27 Sep 2022 12:48 GMT
  • Attachments:

Create examples of use of the profile

  • Key: CSRM-5
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 22:08 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    The profile is fairly straight forward with much of the vocabulary in MBSE and space domains. Deferring issue to RTF to reconsider for a later version.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Icons for profile

  • Key: CSRM-1
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

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

  • Reported: CSRM 1.0b1 — Fri, 18 Mar 2022 21:30 GMT
  • Disposition: Deferred — CSRM 1.0
  • Disposition Summary:

    Defer to RTF

    Punting this issue to the next release.

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Remove Section 0 from the document

  • Key: CSRM-16
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Daniel Brookshier)
  • Summary:

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

  • Reported: CSRM 1.0a1 — Fri, 22 Apr 2022 20:42 GMT
  • Disposition: Closed; No Change — CSRM 1.0
  • Disposition Summary:

    Change already made by OMG editor

    Closing subtask that was created by mistake..

  • Updated: Tue, 27 Sep 2022 12:48 GMT

Provide a simple sample application

  • Key: CORBARS_-1
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

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

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

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:47 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add sample application walkthrough in Appendix A

    Add non-normative appendix A.

    The appendix walks through the steps involved in exposing a REST API to a sample CORBA application using the IDL-RS annotations.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

Provide example of authentication and security

  • Key: CORBARS_-2
  • Status: closed  
  • Source: OpenText Inc. ( Mr. Matteo Vescovi)
  • Summary:

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

    I think this would help with adoption.

  • Reported: CORBA-REST 1.0b1 — Fri, 11 Jun 2021 09:50 GMT
  • Disposition: Resolved — CORBA-REST 1.0
  • Disposition Summary:

    Add example showing how to secure an application in appendix B.

    Add non-normative appendix B.

    Appendix B illustrates how security might be added to the example REST for CORBA application described in Appendix A.

  • Updated: Tue, 27 Sep 2022 12:47 GMT
  • Attachments:

FTF-1 changes to be applied to GraphQL PSM

  • Key: C2INAV11-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Some but by now means all of the Issue Resolution from FTF-1 are applicable to the GraphQL PSM. These should be determined and applied as appropriate.

  • Reported: C2INAV 1.0a1 — Thu, 14 May 2020 20:13 GMT
  • Disposition: Resolved — C2INAV 1.1
  • Disposition Summary:

    Generate new GraphQL PSM Schema from the PIM

    The 1-1 FTF did not apply PIM changes to the GraphQL PSM. Furthermore the proposed schema mapping was in practice less than optimal for specialization-generalization relationships, leading to a complicated mapping in many GraphQL software language clients.
    This proposal uses an improved mapping where there is a base type for common attributes and union for the specialized attributes.

  • Updated: Wed, 13 Jul 2022 14:18 GMT
  • Attachments:

Update GraphQL PSM Mapping

  • Key: C2INAV11-3
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The GraphQL mapping in the specification and defined in the schema files leads to an unnecessarily complicated implementation of the standard and should be simplified

  • Reported: C2INAV 1.0 — Sat, 29 Jan 2022 19:02 GMT
  • Disposition: Duplicate or Merged — C2INAV 1.1
  • Disposition Summary:

    Regenerate GraphQL PSM with updated mapping

    The updated mappings from PIM to GraphQL as incorporated into the TDAI beta spec should be used.

  • Updated: Wed, 13 Jul 2022 14:18 GMT

Add mapping for @optional

  • Key: CPP1116-19
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification should specify the mapping of @optional, maybe maybe to IDL::optional which could be an using of std::optional with C+17, only for C11/C+14 at that moment the API of IDL::optional should be specified

  • Reported: CPP11 1.5 — Thu, 19 Aug 2021 08:21 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Map optional struct members

    Unlike other standardized annotations that are impact the middleware platform, the IDL @optional annotation impacts the language mapping.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Impact of @final on union/struct mapping

  • Key: CPP1116-20
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The @extensibilty(FINAL) or @final annotation is one of the new annotations in IDL4.2, see 8.3.16 of IDL4.2. Should the generated class for a struct/union which is annotated with @final be generated as a C++11 final class or not? So

    struct Foo final {}

    or

    struct Foo {}

  • Reported: CPP11 1.5 — Fri, 3 Sep 2021 11:32 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    Extensibility annotations do not impact the language mapping

    The concept of type extensibility is defined in IDL4.2 as "specifying how
    the element is allowed to evolve." The language mappings determine how each IDL source file is mapped. In terms of this "evolution," the mapping is just capturing a single point in time. Neither of the IDL4-specific mappings (C# or Java) map extensibility to a programming language feature.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add IDL::traits<>::bit_bound

  • Key: CPP1116-11
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For template programming it could be helpful to have a IDL::traits<>::bit_bound trait of type std::integral_constant which returns the bit_bound set in IDL for a bitmask

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:32 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Add traits member specification to Bit Masks section

    Specify the bit_bound member of IDL::traits for Bit Masks

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Invalid constructor in example code

  • Key: CPP1116-12
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The example code has

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type;

    But this is not correct, it should be

    OBV_Example (int16_t, int32_t, std::string, IDL::traits<Example>::ref_type);

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:05 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Fix invalid example code

    A closing parenthesis was missing from the example code.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use IDL::traits<>::make_reference instead of CORBA::make_reference

  • Key: CPP1116-18
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For creating a client side reference the specification uses currently CORBA::make_reference but this logic is not really CORBA specific and in a LwCCM system which only uses local interfaces the usage of CORBA is polluting user code. One of the key concepts of IDL to C++11 is that the user doesn't need to remember any special naming rules so we don't want to tie a factory function to some implementation name. The IDL to C++11 specification already uses the IDL::traits<> concept which is specialized based on the IDL type. We propose to extend the IDL::traits<> for interfaces/valuetypes for a make_reference factory method so that user code given an interface A can create an object reference using IDL::traits<A>::make_reference.

    In the specification we propose the following changes:
    6.7.1, replace CORBA::make_reference with IDL::traits<>::make_reference
    6.18.7.1 replace CORBA::make_reference <StringValue> with IDL::traits<StringValue>::make_reference
    6.18.10.2 replace CORBA::make_reference<> with IDL::traits<>::make_reference
    6.25 replace CORBA::make_reference<> with IDL::traits<>::make_reference and CORBA::make_reference <MyLocalIF> (); with IDL::traits<MyLocalIF>::make_reference ();

    The CORBA::make_reference() can be easily kept by an implementation for backwards compatibility but this proposal enables the user to write code that is more CORBA independent

  • Reported: CPP11 1.5 — Tue, 15 Jun 2021 09:24 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Move make_reference into the traits class

    The CORBA::make_reference function template as currently specified is a top-level member of the CORBA namespace. Some uses of IDL (and this mapping) are non-CORBA, for example lightweight CCM/UCM or DDS. This change moves make_reference into the traits which lives in the IDL top-level namespace.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

The page footers of https://www.omg.org/spec/CPP11/1.5/PDF (ptc-20-11-02.pdf) all say v1.4

  • Key: CPP1116-15
  • Status: closed  
  • Source: Leonardo S.p.A ( Simon McQueen)
  • Summary:

    Page footers look like:

    C++11 Language Mapping, v1.4 iii

  • Reported: CPP11 1.5 — Wed, 5 May 2021 11:25 GMT
  • Disposition: Duplicate or Merged — CPP 1.6
  • Disposition Summary:

    This issue is a duplicate of issue 5

    Apols for not checking before raising.

  • Updated: Thu, 31 Mar 2022 19:32 GMT
  • Attachments:

Struct inheritance mapping strange

  • Key: CPP1116-6
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec says the following:

    The constructor which “accepts values for each struct member in the order they are specified in IDL” also accepts, as its first parameter, an object of the mapped base type (passed by const reference)

    As user of a IDL inherited struct I would expect I can pass the members of the base type after the members of the inherited struct, not an instance of the base type. So, when there is a 2DPoint with members X and Y and a 3DPoint derived from that with member Z, I would expect to call a constructor with Z, X, Y .

    Also the spec should require that a the inheriting constructor concept should be supported (see https://arne-mertz.de/2015/08/new-c-features-inherited-and-delegating-constructors/), so we can initialize a 3DPoint with only X and Y where Z receives its default value.

    The remark of "passed by const reference" which is now part of the spec should be removed, that is an implementation decision, it could be that pass by value is more performant (see for example https://abseil.io/tips/117)

    An example would be really helpful in this case, provide an example IDL construct with the example C++11 code expected.

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 08:57 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update struct inheritance mapping

    The section "Structures with Single Inheritance" needs a minor update and an example

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Incorrect footer

  • Key: CPP1116-5
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the footer it says "C++11 Language Mapping, v1.4", but it should be "C++11 Language Mapping, v1.5"

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 08:33 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No RTF change needed

    Footer is correct in formal/21-05-01 (IDL-to-C++11 1.5).

  • Updated: Thu, 31 Mar 2022 19:32 GMT

IDL::traits missing for enum type for bitmask and use a C++11 strong enum

  • Key: CPP1116-7
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 tries to prevent the user from remembering all kind of special naming rules. The spec now uses "<Bitmask>Bits" but that is something we want to prevent, we propose to use a IDL::traits<>::bits which can be used as a generic way to use this special "<Bitmask>Bits" type in code. It could happen that there is also a user type "<Bitmask>Bits" in IDL, how is this now handled? When IDL::traits<>::bits is used the naming of the implied type is an implementation decision

    Also a C++11 strong enum should be used instead of an old enum to prevent the enumerator values to pollute the containing namespace, the current approach doesn't work when there are 2 bitmasks with the same set of enumerators, the code below doesn't compile

    enum MyBitMaskBits : std::uint8_t

    { flag0 = 1, flag1 = 2, flag4 = 16, f6 = 64};
    enum MyBitMask2Bits : std::uint8_t { flag0 = 1, flag1 = 2, flag4 = 16, f6 = 64}

    ;

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:08 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update bitmask IDL traits

    Update IDL traits for bitmask types.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Remove std namespace from example code

  • Key: CPP1116-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:31 GMT
  • Disposition: Duplicate or Merged — CPP 1.6
  • Disposition Summary:

    Duplicates issue 8

    Duplicate of issue 8

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Why not map bitset inheritance to struct inheritance

  • Key: CPP1116-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why is bitset inheritance not mapped to struct inheritance, that would simplify the code for BitSet2 in this example.

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:27 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No change needed

    Using struct inheritance would mean that the last member of the base couldn't share the same byte with the first member of the derived. Essentially this is a difference between what C++ inheritance of structs means when structs have bitfields and the semantics defined by IDL.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Missing override

  • Key: CPP1116-14
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The destructor should change from

    virtual ~V_factory();

    to

    ~V_factory() override;

    The virtual is redundant, that is already in the base

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:07 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update the code in 6.18.10.2

    Modern C++ usage is to prefer the override keyword to virtual.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Remove std namespace from example code

  • Key: CPP1116-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to replace std::uint8_t in the example code with uint8_t, for all integer types the spec doesn't list the std namespace

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 09:12 GMT
  • Disposition: Closed; No Change — CPP 1.6
  • Disposition Summary:

    No change needed

    The identifier uint8_t is defined by the ISO C++ standard as a member of namespace std, so this spec uses the namespace as well.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Missing override

  • Key: CPP1116-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the example code the destructor should change from

    virtual ~ColorValue();

    to

    ~ColorValue() override;

  • Reported: CPP11 1.5 — Thu, 22 Apr 2021 12:06 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Update the code in 6.18.7.2

    Modern C++ usage is to prefer the override keyword to virtual.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Annotation for union discriminator name

  • Key: CPP1116-3
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    For the switch of unions, the C++ mapping uses the name _d.
    It would be desirable to permit names that reflect the users' application domain.
    Example:

      enum environment_t { air, water, land };
    
      union env_info_t switch (@switchname("environment") environment_t) {
        case air:
          air_info_t air_info;
        case water:
           [...]
      };
    

    The @switchname annotation would cause a getter/setter of the given name to be generated in addition to the _d() accessors.
    In the above example:

      void environment(environment_t);  // alias for _d(environment_t)
      environment_t environment() const;  // alias for _d()
    
  • Reported: CPP11 1.5 — Thu, 1 Apr 2021 14:23 GMT
  • Disposition: Deferred — CPP 1.6
  • Disposition Summary:

    Depends on an IDL spec change

    Defer until the IDL 4.3 RTF resolves IDL43-42.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Add mapping for IDL4.2 standardized annotations

  • Key: CPP1116-4
  • Status: closed   Implementation work Blocked
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    IDL4.2 defines in section 8.3 a set of standardized annotations where it looks some of them impact the IDL to C++11 language mapping like @optional, @final, @range, @default and maybe others. There should be a new paragraph in the IDL to C++11 language mapping which describes how these standardized annotations map to C++11, like @optional to std::optional, @final to final, etc

  • Reported: CPP11 1.4 — Thu, 1 Apr 2021 16:24 GMT
  • Disposition: Deferred — CPP 1.6
  • Disposition Summary:

    Defer work on this issue

    IDL 4.2 has 24 Standardized Annotations which vary widely in terms of their applicability to a language mapping. Since other RTF issues request specific annotations that are more urgent, defer this broad issue to the next RTF.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Replace ServantBase with Servant

  • Key: CPP1116-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the TIE chapter replace ServantBase with Servant, ServantBase is from the old IDL to C++ spec, in C++11 this should be Servant, see CPP1115-2

  • Reported: CPP11 1.4 — Fri, 30 Oct 2020 15:03 GMT
  • Disposition: Resolved — CPP 1.6
  • Disposition Summary:

    Replace ServantBase with Servant

    The term ServantBase appears in section 6.26.8, this is a holdover from the original IDL-to-C++ mapping. The term Servant should now replace it.

  • Updated: Thu, 31 Mar 2022 19:32 GMT

Use C++11 using instead of typedef in all C++11 example code

  • Key: CPP1114-29
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    C++11 introduced the "using" keyword (see https://en.cppreference.com/w/cpp/language/type_alias) as alternative way to specify a type alias. In terms of C++11 support usage it would be a good thing to update all example C++11 code within the specification to use "using" instead of "typedef"

  • Reported: CPP11 1.3 — Mon, 29 Oct 2018 10:56 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Use the C++11 type alias feature in examples

    C++11 has type aliasing with the "using" keyword, which is typically preferred to using the "typedef" syntax inherited from C.

  • Updated: Wed, 3 Nov 2021 16:29 GMT

IDL4 Extended Data-Types: struct inheritance

  • Key: CPP1115-18
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    The IDL to C++11 language mapping section 6.31 should be extended for struct inheritance as it is now part of IDL4 (Building Block Extended Data-Types)

  • Reported: CPP11 1.4 — Fri, 9 Oct 2020 13:31 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Support for struct inheritance

    Add mapping for IDL4 struct inheritance

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Add support for int8

  • Key: CPP1115-4
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Add support for int8 which is a new type, the other (u)int(8/16/32/64) are just aliases so don't need to be in the language mapping

  • Reported: CPP11 1.4 — Tue, 22 Sep 2020 06:20 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add int8/uint8 mapping

    Add a new subsection in 6.31 for IDL int8/uint8

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Example V_factory should list deleted assignment/copy

  • Key: CPP1115-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The V_factory should have deleted assignment/copy so add
    private:
    V_factory (const V_factory&) = delete;
    V_factory (V_factory&&) = delete;
    V_factory& operator =(const V_factory&) = delete;
    V_factory& operator =(V_factory&&) = delete;

    In the text change
    Each generated factory class has a protected virtual destructor, a protected default constructor.
    to
    Each generated factory class has a protected virtual destructor, a protected default constructor, deleted copy/move constructors, and deleted copy/move assignment operators

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:49 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add deleted special member functions to type-specific value factories

    Use the "= delete" feature of C++11.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Copy/move assignment operators should be deleted

  • Key: CPP1115-7
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

    Protected copy and move assignment operators

    to

    Private deleted copy and move assignment operators

    And in the code example

    ColorValue& operator=(const ColorValue&);
    ColorValue& operator=(ColorValue&&);

    to

    ColorValue& operator=(const ColorValue&) = delete;
    ColorValue& operator=(ColorValue&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:36 GMT
  • Disposition: Duplicate or Merged — CPP11 1.5
  • Disposition Summary:

    Duplicates issues CPP1115-5

    This appears to be a duplicate

  • Updated: Mon, 29 Mar 2021 12:21 GMT

valuebox should be final

  • Key: CPP1115-6
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The valuebox created should be using final, so add to the bullets of 6.18.7.2 a first bullet saying "Must be final" and change in the code
    class ColorValue : public ValueBase
    to
    class ColorValue : public ValueBase final

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:22 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Use the C++ final specifier on value box classes

    Make use of the "final" capability of C++11

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Copy/move assignment operators should be deleted

  • Key: CPP1115-5
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueBase has only a protected copy/move copy constructor to allow a derived class to make a copy, the assignment operators are deleted, because of this also for a valuebox the assignment operators should be deleted, so the 3rd bullet should be updated from

    Protected copy and move assignment operators

    to

    Private deleted copy and move assignment operators

    And in the code example

    ColorValue& operator=(const ColorValue&);
    ColorValue& operator=(ColorValue&&);

    to

    ColorValue& operator=(const ColorValue&) = delete;
    ColorValue& operator=(ColorValue&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:06 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Value box classes shouldn't be assignable

    Update to work with ValueBase

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Missing deleted assignment/copy operators

  • Key: CPP1115-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    ValueFactoryBase should have deleted assignment/copy operators so add to the code part

    private:
    ValueFactoryBase (ValueFactoryBase&&) = delete;
    ValueFactoryBase (const ValueFactoryBase&) = delete;
    ValueFactoryBase& operator =(const ValueFactoryBase&) = delete;
    ValueFactoryBase& operator =(ValueFactoryBase&&) = delete;

  • Reported: CPP11 1.4 — Mon, 28 Sep 2020 14:38 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Add deleted special member functions to ValueFactoryBase

    Use the C++11 "= delete" feature for ValueFactoryBase.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Operations tagged with override shouldn't have virtual

  • Key: CPP1115-3
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Any C++11 operation in the spec which uses override shouldn't have virtual, that is redundant and shouldn't be done, so for example

    virtual void val2 (int32_t) override;

    Should be

    void val2 (int32_t) override;

    Easiest is to search for override and check that any operation that has override doesn't have virtual

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 08:23 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Remove uses of the C++ virtual keyword that aren't needed

    Member functions declared with "override" should not also have "virtual"

  • Updated: Mon, 29 Mar 2021 12:21 GMT

_default_POA should use override

  • Key: CPP1115-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The operation _default_POA currently declared as

    IDL::traits<PortableServer::POA>::ref_type _default_POA()

    Should be

    IDL::traits<PortableServer::POA>::ref_type _default_POA() override

    Also the formatting of the constructor of the TIE template should be changed, hard to read. Initializing the members could use std::move so change

    : tied_object_(t), poa_(poa)

    to

    : tied_object_(std::move(t)), poa_(std::move(poa))

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 07:43 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Updated code for Delegation-Based Interface Implementation

    Update code to reflect C++ best practices

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Add support for bitset/bitfield/bitmask

  • Key: CPP1115-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping section 6.31 should be extended for bitset/bitfield/bitmask from IDL4 (Building Block Extended Data-Types)

  • Reported: CPP11 1.4 — Fri, 18 Sep 2020 07:03 GMT
  • Disposition: Resolved — CPP11 1.5
  • Disposition Summary:

    Bitset and Bitmask mapping

    Bitsets and bitmasks are "top-level" IDL4 extended data types that can each be mapped to C++11.

  • Updated: Mon, 29 Mar 2021 12:21 GMT

Data Dictionary Messages

  • Key: C2MS-14
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1. (Also, FYI, GMSEC project has drafted messages for retrieval of display related meta-data. They will be available with GMSEC Fall 2018 release.

  • Updated: Wed, 9 Dec 2020 21:52 GMT

No Depth Accuracy Information Available


Placement of surge,sway and heave within the spec

  • Key: C2INAV-43
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The inclusion of surge/sway/heave & the associated rates under Attitude::offset_report_type seemed slightly odd at first glance. I would have expected these to be more logically included as variations in Position, not attitude. (Albeit typically measured using a different frame of reference). But I can also see a counter-argument that says as surge/sway/heave are normally assessed in terms of current platform attitude, it’s a more logical place. I guess it comes down to whether you’re interested in position on a macro scale or a micro scale ? On the macro scale you probably don’t care so much about headings at all … on the micro scale you absolutely do. I don’t’ know whether the specs or their requirements make any indication about their intended use and associated limitations ?

  • Reported: C2INAV 1.0a1 — Thu, 14 May 2020 14:31 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Explain rationale for attitude and position packages

    Explain that services relating to the micro-scale are in attitude and that services relating to macro-scale are in the position

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Declaration of keys missing from IDL files


Circular dependency between modules Reporting and Attitude

  • Key: C2INAV-12
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Reporting::navigation_request depends on Attitude::measurement_kind;
    Attitude::offset_report depends on Reporting::navigation_report

    This means that the DDS API does not cleanly generate from the IDL

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 19:08 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Move navigation_request_type to a new package Requests

    Break the circular dependency by moving the type involved to a new sibling package
    Create a new package 'Requests' in Navigation_Domain that contains navigation_report_type.

  • Updated: Fri, 18 Sep 2020 17:02 GMT

offset_report_type is declared out of order

  • Key: C2INAV-11
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In Attitude.idl struct offset_report_type is declared out of order. This means that the DDS API does not cleanly generate.

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 19:07 GMT
  • Disposition: Closed; No Change — C2INAV 1.0
  • Disposition Summary:

    Superceded as offset_report_type attribute now inlined

    To allow for keyed attributes needing to be top-level the attributes of abstract type offset_report_type are proposed to be inlined into the classes that inherit from it in the DDS/IDL PSM mapping.
    Therefore no particular change is required in response to this observation as the struct is not present in the new mapping proposed.

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Missing import statements


Strings should have a maximum size

  • Key: C2INAV-9
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    So that application can bound the size of their data structures dynamically sized types should have a maximum size.
    A maximum string length of 32 should be added to attribute specific_system in class navigation_report_type.

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:54 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Add Length Tag to Specific_System attribute

    Add Length Tag, value = 32, to Specific_System attribute in struct navigation_report_type

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Class version numbers are inappropriate

  • Key: C2INAV-8
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The Beta generation scheme included a version comment for each class. This is inappropriate as there isn't a sense in which classes can be independently versioned.

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:51 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Remove Version Numbers from IDL Type Definitions

    Remove version number from the head of the comments for each type definition

  • Updated: Fri, 18 Sep 2020 17:02 GMT

All Ext child packages are in the same file


navigation_report_type: composite_contributors needs a Length tag

  • Key: C2INAV-6
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    To allow applications to bound the size of their data structures dynamically sized data structures should have a bounding size.
    The composite_contributors attribute of class navigation_report_type should have a Length tag, size = 6

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:46 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Add length tag to composite contributors

    Add length tag value = 6 to composite contributors attribute

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Add notes to the navigation_report_kind_type in the IDL/DDS PSM enum literals

  • Key: C2INAV-5
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    To be clear on the meaning notes/comments should be added to each of the literals of navigation_report_kind_type in the IDL/DDS PSM (implementation is PSM specific).

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:40 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Add notes to the literals

    Due to need to also reference the keys for specialised topics the relevant enumeration in the PSM mapping is now navigation_report_key_kind_type. The class navigation_report_kind_type is now a struct with an attribute of this enumeration.

    A note of the form
    "The literal for referencing the

    {specialised class}

    specialisation of navigation_report_type." to each attribute

  • Updated: Fri, 18 Sep 2020 17:02 GMT

There are no notes for the report relation of navigation_covariance_type


Depth Report not a specialisation of navigation_report_type

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

    Unlike other reports from the Navigation subsystem a Depth Report does not inherit from navigation_report_type even though it should be qualified by the attributes of navigation_report_type.

  • Reported: C2INAV 1.0a1 — Mon, 11 May 2020 15:07 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    *depth_report_type to Inherit from navigation_report_type *

    Add an inheritance of navigation_report_type from depth_report_type

  • Updated: Fri, 18 Sep 2020 17:02 GMT
  • Attachments:

Reference from navigation_covariance_type to navigation_report_type needs a length

  • Key: C2INAV-15
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    To enable static calculation of memory requirements in applications using the standard sequences should be bounded.

  • Reported: C2INAV 1.0a1 — Mon, 11 May 2020 15:03 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Add length tag to bound report_id sequence

    Add a length tag, value = 6 to the association from navigation covariance type to navigation_report_type with role report.
    This means that sequence navigation_report_kind_sequence_type has a bound of 6 elements

  • Updated: Fri, 18 Sep 2020 17:02 GMT

FTF-1 changes to be applied to GraphQL PSM

  • Key: C2INAV-49
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Some but by now means all of the Issue Resolution from FTF-1 are applicable to the GraphQL PSM. These should be determined and applied as appropriate.

  • Reported: C2INAV 1.0a1 — Thu, 14 May 2020 20:13 GMT
  • Disposition: Deferred — C2INAV 1.0
  • Disposition Summary:

    Determine GraphQL PSM changes in FTF-2

    GraphQL PSM changes should be determined and applied in FTF-2, when there will be the opportunity to validate them with respect to a more mature implementation.

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Rotation should be about the centre of rotation not the platform reference point


implementation defined is miss-spelled

  • Key: C2INAV-4
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    The 'inherit' relation 'implementation defined' for navigation_report_kind_type is miss-spelled (missing first 'e').

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:35 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Correct typo in navigation_report_kind_type

    Change inheritance to "implementation defined" for class navigation_report_kind_type.

  • Updated: Fri, 18 Sep 2020 17:02 GMT
  • Attachments:

Accuracy compositions should have notes


write_rotational_attitude is not correctly entered in the UML model

  • Key: C2INAV-2
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    In the supporting modelling tool (auxiliary file) the rotation parameter of the write_rotational_attitude operation does not have its classifier entered correctly. This means that it appears as a built-in type in the XMI and IDL generated from the XMI is incorrect.

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:31 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Fix parameter assignment in XMI model

    Assign class from pick-list rather than the typed-in text

  • Updated: Fri, 18 Sep 2020 17:02 GMT

navigation_covariance_type should have a max length

  • Key: C2INAV-1
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    To allow application to statically size (bound) their data structures variably sized datatypes should have a tag to bound the size.
    Accordingly navigation_covariance_type should have a Length tag.
    The maximum value = 253
    (sum(3n+1; n=7) = 22 * 23 / 2) (as there are seven topics each with three values - plus time that can contribute to the covariance; this is very much a worst-case upper bound)

  • Reported: C2INAV 1.0a1 — Wed, 6 May 2020 15:28 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    Add Length Tag to covariance value attribute

    Add Length tag value = 253 as per issue description

    State that sequences are bounded in the IDL PSM

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Unclear which OARIS files are required

  • Key: C2INAV-21
  • Status: closed  
  • Source: BAE SYSTEMS ( Mr. Simon Mettrick)
  • Summary:

    Section 8.1 states that IDL files defined by OARIS, but referred to by this spec are in the OARIS distribution, but it does not specify which files. It would be helpful to do so.

  • Reported: C2INAV 1.0a1 — Mon, 11 May 2020 15:27 GMT
  • Disposition: Resolved — C2INAV 1.0
  • Disposition Summary:

    State the IDL dependencies from OARIS explicitly

    Refer to Time Base, Common Type and Coordinates and Positions

  • Updated: Fri, 18 Sep 2020 17:02 GMT

Duplicate declaration from overloaded operation names


navigation_report_kind_sequence_type in unbounded in DDS PSM


Type mismatch in reference to navigation_report_type


Only top-level attributes can be declared as keys for DDS topic types


Extract IDL details from CORBA spec

  • Key: CORBA34-2
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    IDL is now in its own OMG spec. Remove content from the CORBA spec that repeats what's in the IDL spec. Add a Normative Reference to the IDL spec.

    It may be preferable to keep a "skeleton" of the Part 1 - Chapter 7 outline in the revised document so that existing cross-references (those in the document and especially those not in the document) still resolve. The skeletal sections (such as "7.2.5 Literals") can contain references to the corresponding section in IDL4.

  • Reported: CORBA 3.3 — Thu, 14 Feb 2019 23:23 GMT
  • Disposition: Resolved — CORBA 3.4
  • Disposition Summary:

    Refer to IDL 4.2

    Instead of containing a verbatim copy of key specification details, refer to the standalone IDL 4.2 spec document (formal/2018-01-05).

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Valuetypes should be added to the list of scopes

  • Key: CORBA34-1
  • Status: closed  
  • Source: Self ( Jonathan Biggar)
  • Summary:

    In this section, there are two places where the list of IDL constructs that have scopes is given:

    "interface, struct, union, or exception"

    valuetype should be added to this list to be consistent with the rest of the specification.

  • Reported: CORBA 3.3 — Wed, 18 Oct 2017 23:48 GMT
  • Disposition: Closed; Out Of Scope — CORBA 3.4
  • Disposition Summary:

    Should be revised in the IDL specification

    With the upcoming version of the CORBA specification, all IDL details will be removed and replaced with references to the IDL specification.
    I will create a linked issue for the IDL revision task force to consider.

  • Updated: Mon, 30 Mar 2020 19:47 GMT

Specify multiplicity for required and optional fields

  • Key: C2MS-62
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

  • Reported: C2MS 1.0a1 — Wed, 12 Dec 2018 21:37 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Received after RFC 4-week deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Add documentation within the model

  • Key: C2MS-61
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1 (But good idea)

    Issue received after the RFC 4 week deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

"Mnemonic" should be called "Parameter"

  • Key: C2MS-60
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:48 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Issue received after 4 week RFC deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

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

  • Key: C2MS-59
  • Status: closed  
  • Source: Braxton Technologies, LLC ( Gerry Simon)
  • Summary:

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

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

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

  • Reported: C2MS 1.0b1 — Tue, 11 Dec 2018 21:39 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Received after 4-week RFC deadline.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

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

  • Key: C2MS-44
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    Requesting data, such as telemetry, via pub/sub requires knowing the publisher's server name. There should be a way to request data without this being already known. Solutions could include not requiring the publisher name in the subject or a registry capability.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:48 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to FTF 1.1

    Issue received after RFC comment deadline

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Pub/Sub subscription status unknown

  • Key: C2MS-42
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

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

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:43 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Checking validity of a Request is an implementation concern - add verbiage that it is PSM responsibility

    Add to section 6.3.1 that: A mechanism to determine validity of previously issued requests should be implemented by the PSM."

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Acknowledge Final Status inconsistency

  • Key: C2MS-41
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer to next revision

    This issue has ripple effects to more of the document. Needs more thought.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

XML PSM recommended

  • Key: C2MS-39
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Add the GMSEC xsd files to C2MS as a PSM

    Larger scope than FTF 1.0. Suggest adding in C2MS RTF 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Procedure Execution Status/Progress/Detail Messages

  • Key: C2MS-15
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Parameter Mnemonic Messages Misses "setter"

  • Key: C2MS-13
  • Status: closed  
  • 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
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    Defer - out of scope for this FTF.

    SDTF Ottawa recommended deferral to next release of C2MS, ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Archive Mnemonic Value Request comments

  • Key: C2MS-11
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (Archive Mnemonic Value Request) Section 7.9.1

    • Need official registry for FORMAT values
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:25 GMT
  • Disposition: Deferred — C2MS 1.0
  • Disposition Summary:

    This issue is out of scope of FTF type of work.

    Recommend that this issue be deferred to C2MS ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

C2CX Heartbeat comments

  • Key: C2MS-9
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (C2CX Heartbeat) Section 7.5.4

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

    Not necessary for now - fields are optional

    Referenced fields in HB are optional, so not necessary to use them. And others have indicated the comment re: memory leaks is useful. SDTF Ottawa recommended deferring until next update cycle, i.e., Ver 1.1.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Lack of a registry concept

  • Key: C2MS-3
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

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

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

    *This issue is out of scope of FTF type of work. *

    Recommend that this issue be deferred.

    A potential workaround is that Heartbeat messages be used to discover other components/services.

  • Updated: Fri, 3 Jan 2020 20:50 GMT

Fix C2CX Device message, field NUM-OF_DEVICES

  • Key: C2MS-36
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The field NUM-OF_DEVICES should be NUM-OF-DEVICES - that is, the underscore should be a dash for consistency with all other messages' field names.

  • Reported: C2MS 1.0b1 — Mon, 22 Oct 2018 18:03 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Replace figure 8-11 on page 99, Device Message Diagram, with the attached figure.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Merge figures 8-1 and 8-2

  • Key: C2MS-84
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    There's no need for these to be separate. Merge them into one.

  • Reported: C2MS 1.0b1 — Thu, 9 May 2019 19:15 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    *Merge the 2 "high-level uml class diagram" figures (8-1 and 8-2) into one. *

    All classes on one diagram for ease of reference. Figure 8-2 is deleted and Figure 8-1 is updated.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add (back) Simple Service request and response messages

  • Key: C2MS-83
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    These messages were a part of the heritage source spec (i.e., GMSEC project) for C2MS, but were not included in the final C2MS RFC submission. AF/EBIG would like these messages added back in.

  • Reported: C2MS 1.0b1 — Wed, 8 May 2019 15:22 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    As issue states, add the Simple Service messages into C2MS

    Make the new messages consistent with other changes being done as part of this FTF 1.0 work.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Change HEADER-VERSION and CONTENT-VERSION default values to 2019 in all Message Diagrams and all Message Contents tables

  • Key: C2MS-82
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    This change is to match the (expected) publication year of C2MS.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:57 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Update values for CONTENT-VERSION and HEADER-VERSION fields to 2019

    Expected publication is 2019, update Message Diagram figures and tables, as shown in attachments.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add DESTINATION-COMPONENT field to the header and to the Miscellaneous Elements of REQ, RESP, and MSG messages that are associated with a REQ

  • Key: C2MS-81
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Add an optional message field of type HEADER STRING called DESTINATION-COMPONENT to all messages, via the message header. Reasoning: many C2MS messages already specify to add this value to one of the miscellaneous subject elements. This change is to make consistent the desire that all subject elements are also elements of the message body; note that COMPONENT (name of the sender) is already a field in the message header.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:36 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add DESTINATION-COMPONENT to the message header and appropriate messages' miscellaneous elements

    Add an optional message field of type HEADER STRING called DESTINATION-COMPONENT to all messages, by adding it to the message header. Reasoning: many C2MS messages already specify to add this value to one of the miscellaneous subject elements.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add field MSG-VERSION to the header

  • Key: C2MS-80
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Add MSG-VERSION to the header (type: string, status: optional, description: “Version information for the message”). Reasoning: AF/EBIG has already added these to their messages and would like to codify it as part of the standard. This field provides more granular versioning than the HEADER-VERSION and CONTENT-VERSION fields currently available.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:27 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add MSG-VERSION field to the Message Header

    Add MSG-VERSION to the header (type: string, status: optional, description: “Version information for the message”).

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add request-id to be one of the Miscellaneous Elements in subjects of MSG type messages that may be in response to a request

  • Key: C2MS-79
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Subject filtering on request-id may be useful for receivers (clients) of data. Use the new field request-id (see issue C2MS-8) to populate the new miscellaneous element in subjects.
    This change applies to MSG type of messages that are in response to a REQ type of message - currently MVAL, AMVAL, and PROD.

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 18:13 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add a row to the Miscellaneous Element tables for MVAL, AMVAL, and PROD messages

    add request-id to be in the miscellaneous element list for subjects for MVAL, AMVAL, and PROD messages.
    Due to other concurrent changes being made, table numbers are now different. Original tables are numbers were 8-79, 8-80, 8-96, 8-97, 8-121, 8-122.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add another row in the table, for operator entered log messages

  • Key: C2MS-78
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Add a row to table 8-13 for operator entered log messages; this issue at the request of the NASA JPSS mission and also potentially for use by the NASA GMSEC Note component.
    Table is alphabetical, so add a row between FDN and ORB rows, as follows:
    OPER Operator Information Operator entered log message

  • Reported: C2MS 1.0b1 — Tue, 7 May 2019 17:55 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add row for "OPER" to table 8-13

    Add row between "FDN" and "ORB" as follows:
    OPER | Operator Information | Operator entered log message

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Figure 7-1, C2MS Message Exchange Patterns Diagram, misspells RESPONSE


Non-satellite-related messages are not representable

  • Key: C2MS-40
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    The subject naming of messages expects the constructs of a mission, constellation, and satellite. It is undefined how subjects should be formed that are not associated with these. This has been dealt with in specific ISDs with MISSION=ENTERPRISE, CONSTELLATION-ID=SERVICE, SAT-ID-PHYSICAL=<service_name>.

    An example is how ground equipment should be addressed, as it might support being used by several spacecraft.

    This is based on inputs from C2MS-4.

  • Reported: C2MS 1.0b1 — Mon, 26 Nov 2018 21:13 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    For non-satellite-related services, suggest using the service name in the SAT-ID-PHYSICAL

    Append final paragraph 6.2.3.3 with:
    For services not associated with a constellation or a satellite, place the service name in the "Sat" element.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Change the type info for a field in the C2CX Device message

  • Key: C2MS-25
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    The type for the Device message field DEVICE.n.PARAM.m.VALUE should be Variable, not Binary.

  • Reported: C2MS 1.0b1 — Fri, 21 Sep 2018 14:59 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change type of DEVICE.n.PARAM.m.VALUE to Variable

    In figure 8-11, change the type of DEVICE.n.PARAM.m.VALUE from "Binary" to "Variable"

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Add Command Echo message

  • Key: C2MS-24
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Rich Monteleone of RTLogic suggested adding a command echo message. Here is an email from him about it. I (Jay Bugenhagen) also have available Rich's sample schema and some other info re: the potential new message.
    ----------------------------------
    Per our discussions recently I’ve created a draft for a Command Echo GMSEC Message Schema (GMSEC.MSG.CMD.ECHO) for consideration by NASA/EGS.

    Notes/Rationale:
    Since Command Echo is executed out-of-band with Command Request/Response (GMSEC.REQ.CMD) I’ve elected to construct the schema for publish/subscribe messaging.
    I based the schema’s off of the 2016.00 spec delivered with the GMSEC 4.3 API
    I also attached the GMSEC.REQ.CMD schema, I’ve added an optional field that we found we needed for commanding (see CMD-ENCODING).

    Discussion topics: We need to determine whether or not we should add the comparison of metadata associated with a commands to command echo. Right now we are not comparing command metadata.
    Example metadata (SPACECRAFT-EXECUTION-TIME, LATEST-UPLINK-TIME, EARLIEST-UPLINK-TIME, RELEASE-TIME)

  • Reported: C2MS 1.0b1 — Fri, 21 Sep 2018 14:53 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    There is a need to be able to echo commands from front-end equipment. The addition of this message allows for that capability.

    Draft originally from Rich Monteleone (RTLogic). Eric Ogren supported final development of new message.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

In Heartbeat message: fix typo in the name of the field CONNECTION-ENDPOINT

  • Key: C2MS-21
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Change "CONNECTION-ENDPOINT" to MW-CONNECTION-ENDPOINT in table 8-12.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:55 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change the name of field CONNECTION-ENDPOINT to MW-CONNECTION-ENDPOINT

    Minor edit to one field name. This change appears in figure 8-12 and table 8-43.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-05 (C2MS zip file for XML schemas) contains corrupt file

  • Key: C2MS-20
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    GMSEC_Defaults.xsd is mangled

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:53 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    File space-18-02-05.zip contained a zip archive within a zip archive. That has been corrected in the attached.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-03 XMI file doesn't 'validate'

  • Key: C2MS-19
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    see line 3 extraneous namespace; line 5849 <NUL> character

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:51 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Replace the machine-readable XMI file with dtc-19-06-07.xmi to correct the invalid version that included extraneous namespaces and nul character, with the file attached to this resolution.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

use of color is discouraged

  • Key: C2MS-17
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    For all message diagrams, color is problematic. Make black/white for printing, copying, etc.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:50 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    lighten front 3 images and make all message diagram color lighter; also, remove table row header colors

    Spoke with Jason Smith at recent meetings (either Seattle or Ottawa) and he said this is not a show-stopper. I propose we meet in the middle and I lighten the color so that there is still some color for aesthetics but printing in black/white shows up better (and uses less ink/toner).

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

space/18-02-05 (C2MS zip file for XML schemas) - zip file unreadable

  • Key: C2MS-16
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    space/18-02-05 is corrupt

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:49 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    space-18-02-05.zip contained a corrupt file.
    This was a glitch in the creation of the zip file. Fixed now. New zip attached.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Product Messages comments

  • Key: C2MS-12
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (Product Messages) Section 7.11 (Though these comments are related to guidance for custom messages

    • Consider providing guidance regarding what the minimal set of attributes should be for a custom message type.
    • Indicate that custom messages can be considered to become sponsored message types in future versions of the specification.
    • Extending the lexicon should be encouraged by the implementation, not discouraged, as the strictest of the GMSEC 4.x MIST modes does.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:26 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change section 8.1 to mention extensions

    Change: "The Message Header is a super-class for all C2MS messages in the sense that all fields in the Message Header appear in all of the C2MS messages." to "The Message Header is a super-class for all C2MS messages and any extensions in the sense that all fields in the Message Header appear in all of the C2MS messages.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Mnemonic Value Request comments

  • Key: C2MS-10
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    (Mnemonic Value Request) Section 7.8.1

    • In GMSEC, re-requesting on the same name is (per an e-mail thread with GSFC) defined as replacing the previous subscription instead of being additive/subtractive. Is that notion being kept in this spec? If so, this should be explicitly defined in the specification.
    • DURATION: When there is no DURATION specified, but a component decides to have a maximum duration anyway, data will arbitrarily stop. This is problematic for subscriptions by a non-UI system component, like a script that checks telemetry values or a roll-up / derived capability that subscribes to data to produce second-level data. Mechanisms to avoid such stoppages in data, such as periodically resubscribing are wasteful and potentially inconsistent between components.
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:23 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Part covered by issue 8, DURATION issue to be fixed by adding final message

    Rerequesting will be solved by resolution to issue 8, request-id. Duration will be solved by adding paragraph near duration description that final-message flag should always be set on sending final message. At the very end of section 8.8.1.3, where self-imposed duration is discussed, add this: "If a data provider does self-impose a maximum duration, the FINAL-MESSAGE field should be set appropriately in the last message sent."

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Modifying a subscription is undefined

  • Key: C2MS-43
  • Status: closed  
  • Source: Kratos RT Logic, Inc. ( Mr. Justin Boss)
  • Summary:

    The current specification does not detail how to handle a modification of a subscription. How this is performed should be included in the specification, such as repeating a new subscription with those items that are to remain in the subscription versus just the changes.

  • Reported: C2MS 1.0b1 — Tue, 27 Nov 2018 22:45 GMT
  • Disposition: Duplicate or Merged — C2MS 1.0
  • Disposition Summary:

    This issue solved by resolution to issue #8, adding REQUEST-ID

    Duplicate - no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Flatten the message hierarchy re: C2CX, TLM, and NDM messages

  • Key: C2MS-23
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    There is an intermediate sub-layer that is not needed in the C2CX, TLM, and NDM messages that makes common processing more difficult. I suggest removing the sub-layer so that all messages are uniquely identifiable by their type and sub-type.

    For example, heartbeat messages are currently categorized like this:
    type - MSG
    subtype - C2CX
    c2cx-subtype - HB

    I suggest there is no need for the C2CX layer. it should be like this:
    type - MSG
    subtype - HB

    Similarly for other C2CX messages, TLM messages, and NDM messages.

  • Reported: C2MS 1.0b1 — Tue, 18 Sep 2018 19:14 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    C2CX and TLM messages were done; NDMs require more thought

    C2CX Messages:

    • re-organized section 8.5 to match other message sections
    • made all messages have a unique MESSAGE-SUBTYPE value (CFG, CNTL, DEV, HB, RSRC)
    • removed C2CX-SUBTYPE field from all messages

    TLM Messages:

    • re-organized section 8.6 to match other message sections
    • made all messages have a unique MESSAGE-SUBTYPE value (TLMFRAME, TLMPKT, TLMPROC, TLMTDM)
    • removed FORMAT field from all messages

    Updated table 6-6 to remove the row (2 cells) that shows C2CX as a Subtype value "C2CX | Component-to-Component Transfer"

    NDM Messages:
    Not flattened because the NDM-TYPE field is not fixed for the sub messages. For example, for AEM messages the value is CCSDS-AEM or AEM. Therefore, to flatten it out would require addition of 6 new messages - deemed out of scope for this revision.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Make sure CCSDS info is consistent and current

  • Key: C2MS-22
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Review all references and content related to CCSDS for currency, correctness, etc. For example, some fields in messages map to fields in CCSDS messages - these should be double-checked.

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:56 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    Reviewed CCSDS specs - no changes needed

    No inconsistencies or inaccuracies were found.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

page numbers in early sections are messed up (i, ii, i, iii, etc.)

  • Key: C2MS-18
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    self-explanatory

  • Reported: C2MS 1.0b1 — Fri, 14 Sep 2018 17:50 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Page numbers in preface section (i, ii, etc.) were incorrect

    This issue was resolved as part of preparing the Beta 1 spec version. It was a word to pdf translation problem.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Directive Request: strings, UNIQUE-ID and correlation IDs

  • Key: C2MS-8
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    • (Directive Request) Section 7.4.1

    • Note that directive strings are highly vendor-specific
    • There needs to be a unique ID that is set by the directive requester, not just the API. Otherwise, retrying is not deterministic. (Maybe the other side got the first directive. Maybe it didn’t. Sending the same request twice when the first was received might be dangerous.)
    • Table 8-3: UNIQUE-ID is filled in by the transport/bus layer, not the user application, so this does not remove the need for correlation IDs
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:19 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    *Add field REQUEST-ID to all REQ, RESP, and applicable MSG messages *

    Field is set by requestor and echo'd by responder in RESP and MSG messages. Same Request-ID will mean replacement, else, new request.

    Added field REQUEST-ID to all REQ messages. Field is: Required, U16, "ID to identify the request message – if different request messages have the same value, the request is a replacement; else, it is a new request."

    Added field REQUEST-ID to all RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

    Added field REQUEST-ID to the MSG messages that have associated REQ and RESP messages. Field is: Required, U16, "This field’s value is to be the same as the REQUEST-ID in the associated REQ message."

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Change comments regarding signed types

  • Key: C2MS-7
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Table 8-1: Suggest changing comments regarding signed types. As written, they read like signed magnitude, even though the range implies twos complement.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:17 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Change verbiage on I16, I32 and I64 in the types table 8-1

    In Table 8-1, Field Type Definitions, make 3 changes removing the following phrase "composed of [15, 31, 63] bits for the number and 1 bit for the sign" from the I16, I32, and I64 rows.

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Have required attributes in the messages

  • Key: C2MS-6
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Suggest favoring having required attributes in the messages rather than encouraging applications to hardcode looking for the nth element of the subject, as different existing GMSEC-based systems already have different numbers of tokens in the subject.

    • While these items may exist in the body of a message, it has been found that some existing GMSEC consuming apps are extracting from subjects
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:16 GMT
  • Disposition: Resolved — C2MS 1.0
  • Disposition Summary:

    Add verbiage re: required attributes in messages; move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields

    In Figure 8-3 (Message Header), move CONSTELLATION-ID, and the 2 SAT-IDs to Required Fields.
    Edit paragraph 8.1.1 to change "Some of the elements of the C2MS subject name can be made up from fields in the C2MS Message Header." to "All of the elements of the C2MS subject name can be made up from required fields in the C2MS Message Header."

  • Updated: Tue, 8 Oct 2019 17:51 GMT
  • Attachments:

Acknowledge Final Status is not deterministic

  • Key: C2MS-5
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Table 6-9: Acknowledge Final Status is not deterministic (rather than Yes). It is a final status in MEP2, but not a final status in MEP 4, 5

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:15 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    Remove table from specification

    The table referenced is confusing and not needed.
    It's table 6-9 in the MCMS pdf (which is what this issue was created against).
    In the Beta 1 spec pdf (dtc/2018-07-01) it's on page 21 as table 0-2.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Subject naming missing the concept of something not being directly tied to a satellite

  • Key: C2MS-4
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Subject naming still missing the concept of something not being directly tied to a satellite. CC2/EGS has the MISSION==ENTERPRISE, CONSTELLATION==SERVICE concept.

    • Should more generic attribute names for these positions be considered?
  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:12 GMT
  • Disposition: Closed; No Change — C2MS 1.0
  • Disposition Summary:

    *The existing fields Domain1 and Domain2 in the header portion satisfy this comment. *

    The Domain1 and Domain2 fields already present in C2MS are intended for the purpose described in this issue. Therefore, no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Should GMSEC API enforce/recommend XML-formatted string constructor usage?

  • Key: C2MS-2
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    Being that C2MS is standardizing the XML representation of a message entering the API, should the constructor that takes an XML-formatted Message be deemed the preferred way of using GMSEC going forward?

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:09 GMT
  • Disposition: Closed; Out Of Scope — C2MS 1.0
  • Disposition Summary:

    This issue is against the GMSEC API, not C2MS

    This issue does not affect the C2MS document.

    Also, the C2MS document is not standardizing the XML representation of messages; XML files are provided by the GMSEC team as a convenience, but are not part of the standard.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Expecting that GMSEC will change to use C2MS as its Subject Standard

  • Key: C2MS-1
  • Status: closed  
  • Source: NASA ( Mr. John Bugenhagen)
  • Summary:

    GMSEC uses a different value for Subject Standard Specification (in table 6.4). Expecting that GMSEC will change to use C2MS as its value to be a compliant PSM.

  • Reported: C2MS 1.0a1 — Mon, 10 Sep 2018 19:04 GMT
  • Disposition: Closed; Out Of Scope — C2MS 1.0
  • Disposition Summary:

    This comment is towards the GMSEC implementation, not C2MS

    The GMSEC implementation supports either C2MS or GMSEC as the SPECIFICATION, but this does not affect the C2MS document. Therefore, no change needed.

  • Updated: Tue, 8 Oct 2019 17:51 GMT

Add Delegation-Based Interface Implementation

  • Key: CPP1114-31
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The current IDL to C++11 language mapping only describes an inheritance based interface implementation in chapter 6.26.6. The IDL to C++ language mapping also described a delegation based implementation. We propose to add a delegation based implementation to the IDL to C++11 specification.

    I will attach a proposal new chapter 6.26.7, only the formatting of IDL and C++ types has to be done in the final document, especially types in the text itself need to be formatted. In the first paragraph there is a number 126, that has to be updated.

  • Reported: CPP11 1.3 — Wed, 31 Oct 2018 12:43 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Mapping for implementing interfaces via delegation

    This issue adds the mapping for implementing interfaces via delegation, a feature of the IDL-to-C++ mapping that has been lacking in this spec.

  • Updated: Mon, 1 Apr 2019 18:18 GMT
  • Attachments:

Remove the setter operation for the discriminator of a union

  • Key: CPP1114-14
  • Status: closed  
  • Source: ZettaScale Technology ( Mr. Erik Hendriks)
  • Summary:

    The C++11 mapping of an IDL union seems to follow that of the classic C++ mapping, where the discriminator does not only have a getter-operation, but also a setter operation. This operation has been added for situations where more than one case label applies to to the same union branch, and the setter operation for that union branch implicitly sets the discriminant value to the first case label that was specified. If you want to pick another value, you should do so by invoking the setter function for the discriminant.

    However, this setter operation is confusing to many users, and some seem to think you need to use it every time you passed a value into a branch different than the current branch. On top of that. it seems cumbersome to have to make two separate method invocations to request a single modification that is intended to set branch value and corresponding discriminator value atomically.

    Much better would be to take the route that has been adopted in the Java language mapping for the union: if there is more than one case label that applies to a union branch, you add an overloaded setter method for that branch that does not only allow you to pass the value for that branch, but also the value for the discriminator. This overloaded setter function will than validate whether the discriminant value you pass actually applies to the branch that you are trying to set.

  • Reported: CPP11 1.3 — Tue, 25 Sep 2018 20:14 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Unions: Provide a way to set both the discriminator and value at the same time

    Enhance the mapping of IDL union to allow setting the discriminator at the same time a new union element value is provided. This change maintains compatibility for applications written to the current spec version.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Bullets before IDL::traits::narrow(ap) lost

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

    Compared to V1.2 in 6.7.6 four bullets before IDL::traits<A>::narrow(ap) got removed

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:53 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Make part of 6.7.6 a bulleted list

    This was somehow lost between v1.2 and v1.3.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

OBV_Example constructor

  • Key: CPP1114-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The OBV_Example constructor has multiple arguments and shouldn't be explicit. Also a closing ) is lacking from the example code. The operations for val2 should also use "override"

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:40 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update OBV_Example class in 6.18.4

    Updates as suggested, making the C++ example code consistent with the prose of 6.18.2 and common conventions.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Text alignment

  • Key: CPP1114-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The operation "virtual int16_6& val1() = 0;" is not aligned correctly in the code example

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:38 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Fix C++ code in 6.18.4

    Fixing a minor typo/formatting bug in this section.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Typo fixes

  • Key: CPP1114-7
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Section 6.11 on page 11, 2nd paragraph:

    Implementations of the bounded wide string are under no oblication to perform a bounds check [...]

    obligation

    Table 6.10 on page 14, bottom row, right column

    dimensions std::integral_constant type of value_type uint32_t indicating the
    number of dimensaions of the array

    [...] dimensions of the array

    Section 6.18.7.2 page 30 top, continuation of code from p.29

    protected:
          ColorValue();
          xplicit ColorValue(Color);
    

    explicit ColorValue(Color);

    Section 6.19.1 on page 34, code for class AbstractBase

    class AbstractBase {
          public:
                virtual IDL::traits<Object>::ref_type _to_object();
                virtual IDL::traits<ValueBase>::ref_type _to_value();
          protected:
                AbstractBase();
                bstractBase(const AbstractBase&);
    

    AbstractBase(const AbstractBase&);

    Section 6.22.2 on page 40 top (code continued from p.39)

                int16_t fixed_scale() const;
                Visibility member_visibility(uin32_t index) const;
    

    Type of index argument should be uint32_t.

  • Reported: CPP11 1.3b1 — Sat, 3 Mar 2018 13:21 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Fix typos

    The submitted issue (CPP1114-7) lists a few other typos, but those are already fixed in formal/18-01-06.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Only single argument constructors have to be explicit

  • Key: CPP1114-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For struct/exception/valuetype the spec describes that a constructor accepting values for all members has to generated as explicit constructor, but it only has to be explicit when there is one (1) member, when there are >1 member the constructor doesn't need to be explicit. This has to be updated in the text and examples

  • Reported: CPP11 1.3 — Tue, 7 Aug 2018 10:48 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Reporter of the Issue has asked for it to be withdrawn

    Closing this one by request of Reporter.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Errors in IDL Built-in Annotations Usage Table

  • Key: CPP1114-4
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.

    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

  • Reported: CPP11 1.2 — Thu, 16 Mar 2017 00:36 GMT
  • Disposition: Closed; Out Of Scope — CPP11 1.4
  • Disposition Summary:

    Issue was added to the wrong RTF

    This issue is not in IDL-to-C++11.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Make mapping of sequences more flexible

  • Key: CPP1114-3
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Flexible mapping for sequence and map types

    Allow implementations more flexibility: in certain cases when the spec currently requires use of a C++ standard library type, the implementation should be able to use a substitute type that's interface-compatible.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1114-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Closed; Out Of Scope — CPP11 1.4
  • Disposition Summary:

    IDL v4 is a standalone specification

    This specification has no normative reference for IDL v4.

    I have implementation experience applying portions of this spec to a non-CORBA middleware (which happens to be a DDS implementation). Those sections of this spec that apply (6.3, 6.4, 6.5, 6.6, 6.8-16, 6.30-31) do not use the CORBA module/namespace.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

In-place construction of structure types

  • Key: CPP1114-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Existing alternatives for struct construction appear to be sufficient

    Since the issue has been unresolved for a number of RTFs I'm proposing we close it now.
    The proposed enhancement could be provided by implementations as an extension to the spec-mandated behavior.
    I don't argue that there is some benefit from this approach, but there is also implementation complexity: when generating a struct constructor, the tool will need to know, for each struct member, which constructor parameters that member can take. Those parameters can vary based on versions of the C++ standard library (for types like std::string, vector, array, map).

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Reduce indent

  • Key: CPP1114-11
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Reduce the indent of public, should start on the first line, makes it all more readable

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:52 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update source code formatting

    Remove extra indenting that can force line wrapping and make embedded source code hard to read.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Alignment _is_a and _non_existent

  • Key: CPP1114-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There are tabs between bool and the method names, they should be removed

  • Reported: CPP11 1.3 — Fri, 30 Mar 2018 09:48 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Update code in 6.26.2

    Minor formatting change as suggested.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Structure mapping change should be reverted

  • Key: CPP1114-5
  • Status: closed   Implementation work Blocked
  • Source: Self ( Jonathan Biggar)
  • Summary:

    The C++11 IDL language mapping for IDL struct datatypes was changed to a Java-style getter & setter interface. This should be reverted for the following reasons:

    1. The original struct mapping (just use data members) performs better at compile and runtime. The new mapping compiles slower by changing each data member to 4! different accessor functions, and at runtime is slower due to the need for the function call. (Modern compilers cannot optimize this call away without global optimization, which is not generally available in C++ implementations, or else the accessor functions must all be defined inline for the compiler to optimize away the function call.)

    2. Java style getter and setter interfaces are not considered good C++ style by the experts. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c131-avoid-trivial-getters-and-setters

    3. The change breaks massive amount of user code for no benefit.

  • Reported: CPP11 1.2 — Mon, 6 Nov 2017 01:15 GMT
  • Disposition: Closed; No Change — CPP11 1.4
  • Disposition Summary:

    Structure mapping shouldn't change within a minor revision of IDL-to-C++11

    Keep in mind that IDL-to-C++ and IDL-to-C++11 are independent specifications. In cases where IDL-to-C++11 takes a different approach to mapping the same IDL features, this isn't a "change" from the spec's point of view.

    However, I'm sympathetic to the notion that it could be a "change" from an implementer/user's point of view as a single IDL translation tool that previously used just IDL-to-C++ could, in a new version, use IDL-to-C++11 (either exclusively or as an option). Since I help maintain some IDL translation tools that do this, I've had to deal with this myself.

    One thing to note is that nothing in IDL-to-C++11 prevents the implementation from providing public data members in mapped structs. Unfortunately the names of those data members would be non-standard. Also, as described in the comments on the parent issue, direct data member usage makes upcoming IDLv4 features like @min/@max harder to support.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Fixed is now broken

  • Key: CPP1114-6
  • Status: closed   Implementation work Blocked
  • Source: Self ( Jonathan Biggar)
  • Summary:

    The fixed type was changed from the old C++ mapping, removing the non-template Fixed class and mandating that Fixed be implemented as a template. These changes disrupted the careful design of Fixed support for C++ in several ways:

    1. There is now no information or guidance about what type is used when declaring a fixed constant in IDL.

    2. The original specification was careful to not mandate whether the C++ mapping used a template definition to enforce constant digits and scale values for fixed point data defined in IDL, yet specifically states that the user should only use the typedefs generated by the IDL compiler Thus the current specification unnecessarily limits implementation choice for fixed point support for no useful implementation purpose.

    3. Removal of the non-template Fixed class makes it harder for the implementation to meet the "double precision (62 digit)" arithmetic guarantee.

    The C++ mapping for Fixed should be restored use the language of the old C++ 1.3 language mapping.

  • Reported: CPP11 1.2 — Mon, 6 Nov 2017 00:58 GMT
  • Disposition: Resolved — CPP11 1.4
  • Disposition Summary:

    Updates to the mapping of the IDL Fixed data type

    Change the mapping of the IDL fixed type data to allow some more implementation flexibility and familiarity from the IDL-to-C++ mapping.

  • Updated: Mon, 1 Apr 2019 18:18 GMT

Section: 15.4.5.1 struct has to be updated

  • Legacy Issue Number: 12858
  • Status: closed  
  • 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
  • Disposition: Deferred — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 18 Feb 2019 00:01 GMT

Errors in IDL Built-in Annotations Usage Table

  • Key: CPP1113-11
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Fernando Garcia-Aranda)
  • Summary:

    In the submission document, Table 21 "IDL Built-in Annotations" does not list where the annotation @hashid can be applied.

    Also, the @id annotation is can be applied to both Structure members and union members (except union discriminator), so it should be moved to the second row on the table.

  • Reported: CPP11 1.2 — Thu, 16 Mar 2017 00:36 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force

  • Updated: Tue, 19 Dec 2017 20:21 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: CPP1113-6
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred to future RTF

  • Updated: Tue, 19 Dec 2017 20:21 GMT

Make mapping of sequences more flexible

  • Key: CPP1113-7
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Deferred

  • Updated: Tue, 19 Dec 2017 20:21 GMT

In-place construction of structure types

  • Key: CPP1113-5
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.3
  • Disposition Summary:

    Deferred

    Without specific spec wording from someone who has implemented it, I don't think we can standardize this feature.

  • Updated: Tue, 19 Dec 2017 20:21 GMT

Example C++ code in mapping for constants should use C++11 uniform initialization

  • Key: CPP1113-10
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping for constants should use uniform initialization in section 6.8 instead of using the assignment. The code
    const std::string name = "testing";
    static constexpr float pi = 3.14159;

    Should be
    const std::string name

    {"testing"}

    ;
    static constexpr float pi

    {3.14159}

    ;

  • Reported: CPP11 1.2 — Tue, 10 Nov 2015 07:56 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    IDL constants should use C++ direct list initializaiton

    When IDL constants are mapped to C++, they become namespace or class scoped const (or constexpr) objects. Use direct list initialization to give these objects values.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: CPP1113-1
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Import the mapping of IDL Map from XTypes 1.2

    XTypes 1.2 (beta) ptc/17-03-06 section 7.5.1.3.4 maps the IDL Map type to "Modern C++", that mapping can be used by this spec directly

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Fix assignment operator of ColorValue

  • Key: CPP1113-9
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The code example as part of 6.18.7.2 has:
    ColorValue& operator=(const Color&);

    but this should be
    ColorValue& operator=(const ColorValue&);

  • Reported: CPP11 1.2 — Mon, 3 Aug 2015 17:32 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Fix argument type of copy assignment operator in 6.18.7.2

    Looks to be a typo in the original spec. The class name is ColorValue which should be used here

  • Updated: Tue, 19 Dec 2017 20:10 GMT

CORBA::make_reference shouldn't explicitly imply perfect forwarding

  • Key: CPP1113-8
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 6.7.1 in the 4th paragraph the CORBA::make_reference<> is mentioned, but it ends using "using perfect forwarding". Where this is probably the best way to implement this, it shouldn't be mandated by the specification. Propose to remove "using perfect forwarding" from the text of this paragraph

  • Reported: CPP11 1.2 — Fri, 22 May 2015 14:03 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Relax requirement for perfect forwarding in 6.7.1

    The C++ idea of "perfect forwarding" doesn't need to be specified here. An implementation may decide to use it.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Handle possible exception what conflict and improve Exception introduction text

  • Key: CPP1113-4
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Because of the mapping of Exception to something derived from std::exception where is a possible conflict when the user has an exception member with the member name "what" because std::exception provides an operation what(). We propose to change the start of section 6.20 to the text below instead of the first two bullets currently in the specification

    An OMG IDL exception is mapped to a C++ class that derives from the standard UserException class. Each OMG IDL exception member maps to a set of corresponding member methods as described in “Mapping for Structured Types” on page 14. When the IDL exception member identifier is "what", the string “cxx” is prepended to the identifier to resolve a conflict with the std::exception what() operation.

    The copy constructor, move constructor, copy assignment operator, move assignment operator, and destructor automatically copy, move, or free the storage associated with the exception. For convenience, the mapping also defines an explicit constructor with one parameter for each exception member in the order they are specified in IDL—this constructor initializes the exception members to the given values. The default constructor initializes all members to their default values as described in “Mapping for Structured Types” on page 14.

  • Reported: CPP11 1.2 — Mon, 13 Apr 2015 08:36 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Possible name conflict involving "what" and exceptions.

    See Johnny's comment on issue #4

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Trivial grammatic fix in 6.14.1

  • Key: CPP1113-3
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.14.1 (mapping for struct type) the second sentence is

    Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for struct each member in the order they are specified in IDL.

    This should be

    Additionally to the methods as described in “Mapping for Structured Types” on page 14 an explicit constructor accepting values for each struct member in the order they are specified in IDL.

    The order of "struct" and "each" should be swapped

  • Reported: CPP11 1.2 — Sun, 12 Apr 2015 17:43 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Edit section 6.14.1 for clarity

    Updated prose description of mapped struct, C++ remains unchanged.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

minor accessors of SystemException should use pass by value, minor should be uint32_t

  • Key: CPP1113-2
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For SystemException class on page 36 mentions

    const int32_t& minor() const;
    void minor(const int32_t&);

    But this is a basic type which we pass by value. Also minor should be an uint32_t, the code should list

    uint32_t minor() const;
    void minor(uint32_t);

    Also the CompletionStatus is returned by value, no need for a const, so change

    const CompletionStatus completed() const;

    to

    CompletionStatus completed() const;

    As last the constructor

    explicit SystemException(int32_t minor, CompletionStatus status);

    Should be

    SystemException(uint32_t minor, CompletionStatus status);

  • Reported: CPP11 1.2 — Sun, 12 Apr 2015 17:35 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    SystemException updates

    Proposed resolution is included in Issue #2 description

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Only a namespace level swap should be provided

  • Key: CPP1113-13
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification mentions that besides a namespace level swap a specialization of std::swap<> has to be provided, but that shouldn't, see http://en.cppreference.com/w/cpp/concept/Swappable. Only a namespace level swap should be enough. This impacts the text of section 6.7.1, the example and text of 6.14.1, example of 6.14.2

  • Reported: CPP11 1.2 — Mon, 19 Jun 2017 14:05 GMT
  • Disposition: Resolved — CPP11 1.3
  • Disposition Summary:

    Remove std::swap requirement

    Overload swap() in the appropriate namespace, do not do anything with std::swap.

  • Updated: Tue, 19 Dec 2017 20:10 GMT

Tasks with RepetitionRule: how to restrict the number of task instances (at a given time)?

  • Key: CR-89
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    With repeating tasks (symbol *|||*) there are situations, where you want to restrict the number of task instances being "active" (or "not in a terminal status") at a given time.

    Attached is a CMMN model example:
    Whenever the entry Sentry is satisfied (e.g. data "Grundstücke" is updated) the model creates a new instance of task "Objektbewertung". Without a restriction every data change triggers the creation of a new task instance, which in this case you want to restrict.
    The idea here is to have exactly one task which handles all last changes on the referenced data "Grundstücke".

    Solution 1:
    Would there be the need for an additional attribute like "multiplicity" (on repeating tasks only?), set to "exactlyOne" or similar, to implement the desired behaviour. (One can think of more complex restriction / settings here, but we leave it to that for now.)

    Solution 2:
    Or can this be handled in the RepetitionRule of "Objektbewertung" itself: with Introspection in the runtime model --> get "active" instances of task "Objektbewertung" and depending on that --> RepetitionRule evaluates to true or false --> control if further instances can be created

    Harald

  • Reported: CMMN 1.1 — Fri, 26 Jun 2015 15:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Re-evaluating the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied

    This proposal is to re-evaluate the repetition rule every time the entry criteria of a repeating Task, Stage, or Milestone is satisfied. This will allow people to control both the number of repetitions (by having a counter) and concurrent repetitions (by introspection of the runtime for concurrent instances – assuming implementers provide a way to do so). In both cases, race conditions can occur, and implementers must provide a way to deal with them (a potential implementation may want to serialized the evaluation of repetition rules).
    Note that in this proposal several statements mix repetition rule and required rules. To avoid mixing proposals, the sentences with required rule were treated as if issue 23 and proposal 52 does not exist.

    Relevant paragraphs in the specification:

    Section 5.4.11.3 RepetitionRule, page 42. Add a third statement as follows as follows:

    A RepetitionRule specifies under which conditions Tasks, Stages, and Milestones will have repetitions. Each repetition is a new instance of it. The first instantiation is not considered a repetition. The trigger for the repetition is a Sentry, that is referenced as entry criterion, being satisfied, whereby an OnPart of that Sentry occurs. For example: A Task might be repeated each time a certain document is created. The Task (as PlanItem) might have an entry criterion, referring to a Sentry, having on OnPart, whereby the onPart refers to the CaseFileItem that represents the type of document, and whereby the standardEvent of the OnPart is specified as “create.” When the RepetitionRule as contained in the PlanItemControl of the Task (as PlanItem) also evaluates to “true,” the Task is repeated upon creation of the document.

    Section 5.4.11.3 RepetitionRule, Table 5.42 - RepetitionRule attributes, cell (2,4) condition : Expression[1], page 43, second paragraph. Reads:

    An Expression that MUST evaluate to boolean. If the Expression evaluates to “true,” then the instance of the Task, Stage, or Milestone maybe repeated, otherwise it MUST NOT be repeated.

    Leave alone.

    Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, cell (4, 2), page 72. The sentence that reads:

    The RepetitionRule and the RequiredRule Boolean expressions MUST be evaluated in this transition, and its Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance.

    Change as follows:

    The RepetitionRule Boolean expression MUST be evaluated in this transition. and t The RequiredRule Boolean expression s MUST be evaluated in this transition, and their Boolean value s SHOULD be maintained for the rest of the life of the Stage or Task instance.

    Section 7.4.3 EventListener and Milestone Lifecycle, Table 7.11 - EventListener and Milestone instance transitions, cell (4,2), page 77. The sentence that reads:

    For a Milestone instance, the RepetitionRule and RequiredRule Boolean expression MUST be evaluated in this transition, and its Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

    Change as follows:

    For a Milestone instance, the RepetitionRule Boolean expression MUST be evaluated in this transition. and For a Milestone instance, RequiredRule Boolean expression MUST be evaluated in this transition, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone instance.

    Section 7.6.4 RepetitionRule, page 79. Reads:

    This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance.

    Stage and Task instances with a RepetitionRule evaluating to “true” will create an instance every time an entry criterion with an onPart is satisfied. Under that condition a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

    Change as follows:

    This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state , and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance . The first time, a Milestone, Stage, or Task instance is instantiated and transitions to the Available state, it is not considered a repetition, nevertheless the RepetitionRule MUST be evaluated and its result discarded.

    Stage and Task instances with a RepetitionRule evaluating to “true” will create , will try to create an a new instance every time an entry criterion with an onPart is satisfied. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” then a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

DI Chapter Editorials

  • Key: CR-141
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    To account for other issues and proposals in this last ballot (CR74, CR131, and CR140 – proposals CR129, CR132, CR145), we need to make minor corrections and changes to the Diagram interchange proposal (issue CR21 proposal CR102) that was already approved. The main change is to fix the depictions to be consistent with proposals CR129, CR132, CR145 is this ballot.

  • Reported: CMMN 1.0 — Fri, 23 Oct 2015 15:30 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    New updated DI Chapter

    Changes to the DI proposal approved in issue 21 are needed to reflect changes that came after.
    For simplicity and convenience a new DI chapter is attached containing all these changes applied.

    1. Given that Issue 74 (Proposal 129) was deferred, in “Table 7.9 Depiction for PlanItem and DiscretionaryItem” we removed the provided depictions for Discretionary Milestone, Discretionary EventListner, Discretionary UserEventListner and TimeEventListener and replaced them by N/A
    2. With the introduction of Artifacts and Associations at Issue 131 (Proposal 132), many changes were done to the DI chapter. These changes are all applied in the attached convenience document. Namely:
      1. Section 7.4.6 CMMNShape. Second paragraph changed as per proposal 132
      2. Section 7.4.6 CMMNShape, Table 7.4 - CMMNShape attributes, cell (2, 3). Paragraph changed as per proposal 132
      3. Section 7.4.7 CMMNEdge. Figure 7.3 was replaced as per proposal 132
      4. Section 7.4.7 CMMNEdge. Second paragraph changed as per proposal 132
      5. Section 7.4.7 CMMNEdge. Paragraph after the fourth paragraph as per proposal 132
      6. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 3). First paragraph changed as per proposal 132
      7. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 4). First paragraph changed as per proposal 132
      8. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (1, 5). Changed as per proposal 132
      9. Section 7.4.7 CMMNEdge, Table 7.5 - CMMNEdge attributes, cell (2, 5). New paragraph added before first paragraph as per proposal 132
      10. Section 7.5.2 CMMNShape Resolution. New sub-section: 7.5.2.9 Artifacts added as per proposal 132
      11. Section 7.5.3 CMMNEdge Resolution. New sub-section: 7.5.3.4 Association added as per proposal 132
    3. Furthermore, with the introduction of Association, we wanted Association to be depicted as dotted line to be aligned with BPMN, thus we had to change the depiction of OnPart
      1. Figure 7.6 OnPart connector displaying the OnPart name and the Standard Event was changed for the new depiction
      2. Table 7.17 Depiction Resolution of OnPart connector referring to a CaseFileItemOnPart, cell(5,2) and cell (5,3), both changed for the new depictions
      3. Table 7.18 Depiction Resolution of OnPart connector referring to a PlanItemOnPart, cell(5,2) and cell (5,3), both changed for the new depictions
  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Change the Notation of the OnPart so it does not conflict with Association


Editorial to section 5.1.5

  • Key: CR-143
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    We need to make changes to the approved proposal for Issue 20 (vendor extensions - proposal CR66). The revised text of the approved proposal 66 mention a figure that was not included in the proposal. There is no changes to the text of the approved proposal, just to the list of instructions on how to apply the proposal in the revised text.

  • Reported: CMMN 1.0 — Fri, 23 Oct 2015 19:54 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Editorial to section 5.1.5

    We need to make changes to the approved proposal in Issue 20 (vendor extension - proposal 66).
    Item 7 of the proposal CR 66 states:

    • 7. Figure of the meta model should be inserted at the end of section 5.1.5 just before talking about Relationship. Relationship is a new class that extends CMMNElement and is related to the Definition

    There is no meta model figure to be inserted at the end of section 51.5.
    The rest should be as proposed in proposal CR 66

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Need for annotations and comments in CMMN


Need the ability to have repetition rules in Tasks and Stages without entry criterion

  • Key: CR-133
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    There are situations in which users may want to repeat a Task or Stage that has no entry criterion. Currently, the specification requires that a repetition rule can only be placed in a Task or Stage that has a entry criterion with an onPart.

  • Reported: CMMN 1.0 — Tue, 20 Oct 2015 15:04 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Repeat Task/Stage without entry criteria upon completion of previous instance

    This proposal extends the proposal CR-130 to allow repetition of Tasks or Stages without entry criteria. In this case, the evaluation of the repetition rule and creation of new instances happens, when the previous instance completes or terminates.

    In a nutshell this scenario works like a do while loop in programming languages. Or speaking in terms of CMMN, one could think of it as an implicit onPart pointing to itself, which is ignored for the first instance.

    All the relevant paragraphs in the specification

    Section 5.4.11 PlanItemControl, Figure 5.12 - PlanItemControl attributes and associations, cell (2,4), page 41 (PDF 55)

    Third paragraph can be deleted completely, as the alternative semantics do work for DiscretionaryItems:

    A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

    Fifth paragraph:

    A PlanItem that has a PlanItemControl that contains a RepetitionRule, MUST have either an entry criterion that refers to a Sentry that has at least one OnPart or no entry criteria at all. (This is because the concept of “repetition” depends on the semantics of Sentries with onParts (see 5.4.11.3)).

    Section 5.4.11.3 RepetitionRule, page 42 (PDF 56)

    The trigger for the repetition is a Sentry, that is referenced as entry criterion, being satisfied, whereby an OnPart of that Sentry occurs.

    New text after first paragraph:

    Alternatively, a RepetitionRule MAY be used on a Task or Stage that does not have any entry criteria. In that case, the RepetitionRule is evaluated when an instance of the Task or Stage completes or terminates. If it evaluates to "true", a new instance will be created.

    Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, transition complete, cell (4, 9), page 73 (PDF 87)

    New text at the end:

    If the Task or Stage has a RepetitionRule but no entry criteria, the RepetitionRule Boolean expression MUST be re-evaluated in this transition and if the expression evaluates to “true”, a new instance is created.

    Section 7.4.2 Stage and Task Lifecycle, Table 7.8 - Stage and Task instance transitions, transition terminate, cell (4, 10), page 73 (PDF 87)

    New text at the end:

    If the Task or Stage has a RepetitionRule but no entry criteria, the RepetitionRule Boolean expression MUST be re-evaluated in this transition and if the expression evaluates to “true”, a new instance is created.

    Section 7.6.4 RepetitionRule, page 79 (PDF 93)

    text of CMMN 1.0:

    This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or Task instance.

    Stage and Task instances with a RepetitionRule evaluating to “true” will create an instance every time an entry criterion with an onPart is satisfied. Under that condition a new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule .

    revised text of CR-130:

    This rule MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the Available state. The first time, a Milestone, Stage, or Task instance is instantiated and transitions to the Available state, it is not considered a repetition, nevertheless the RepetitionRule MUST be evaluated and its result discarded.

    Stage and Task instances with a RepetitionRule, will try to create a new instance every time an entry criterion with an onPart is satisfied. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” then the new instance is created and because the entry criteria is satisfied it moves from the Available state to either Active or Enabled state depending on the ManualActivationRule.

    New text after second paragraph:

    Stage and Task instances with a RepetitionRule that do not have any entry criteria, will try to create a new instance every time an instance transitions into the Complete or Terminate state. Under that condition the RepetitionRule is re-evaluated and if the Expression evaluates to “true,” a new instance is created.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Editorial: Update Table 2.1 - Conformance matrix

  • Key: CR-137
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    With the approval of issues CR-20 Diagram interchange and CR-87 Decision Tasks (which added a new compatibility conformance) table 2.1 needs to be updated.
    Table 2.1 needs to be updated as follows:

    • add a DMN Compatibility Conformance column
    • add sections 2.5, 6.8.4.1 and fill appropriate
    • correct for the section shift after CR-20 added moved section 7 to 8
  • Reported: CMMN 1.0 — Wed, 21 Oct 2015 05:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Update Table 2.1

    Current table after approval of CR 20 and CR87 looks as follows:

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Expressiveness of Task patterns

  • Key: CR-128
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It is currently not obvious to a modeler how to depict/express some desirable Task execution patterns such as Exclusive Choice, Inclusive Choice, etc. or even more advanced patterns such as Racing Conditions. We should ensure that CMMN provides the required expressiveness to a select set of such patterns both in the MM and via the Notation

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 16:53 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    defer Expressiveness of Task patterns

    defer Expressiveness of Task patterns to next revision

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Depicting Inputs and Outputs to Tasks

  • Key: CR-127
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It may be desirable for a modeler to be able to depict Inputs and Outputs to Task

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 15:41 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Defer depict Inputs and Outputs to Task

    Defer depict Inputs and Outputs to Task to next revision

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Exit Criterion may be misleading (as a name or concept)

  • Key: CR-126
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    It may be misleading to a modeler what the purpose of an Exit Criterion may be. Many may think these are conditions under which a Task may Complete when in fact these are conditions under which a Task be Terminated (interrupted)

  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 15:39 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Defer: Exit Criterion may be misleading

    deferred

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Need to add names to contributors

  • Key: CR-124
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    The following people were involved in the Case Diagram example on page 64, figure 6.63 of the spec:

    • Torsten Winterberg (Opitz Consulting)
    • Danilo Schmiedel (Opitz Consulting)
    • Juergen Kress (Oracle)
      and hence should be mentioned in section 4.4 of the spec
  • Reported: CMMN 1.0 — Tue, 22 Sep 2015 11:55 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add contributors to section 4.4 of the spec

    Add contributors to section 4.4 of spec

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing constraint to prevent Human Task from being discretionary to itself

  • Key: CR-118
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In section 5.4.9.2 you can read “A Stage MUST NOT be discretionary to itself or its nested Stages.” But no similar sentence can be found for Human Task.

  • Reported: CMMN 1.0 — Tue, 15 Sep 2015 20:45 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add sentence to prevent Human Task from being discretionary to itself

    In section 5.4.9.2 after the sentence “A Stage MUST NOT be discretionary to a HumanTask that is PlanItemDefinition of a PlanItem that is contained by the Stage or its nested Stages.”, add the following paragrah:

    A HumanTask MUST NOT be discretionary to itself.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Create classes to hold entry and exit criterion references

  • Key: CR-98
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently, entry and exit criteria are just a list of sentries references. Since these criteria are depicted in a CMMN diagram, it would be easier to refer them if they had their own ids. To do so, they should become first class citizen that inherited CMMNElement. This would also allow to use an exitcriterionRef in PlanItemOnPart instead of a Sentry ref (which was the original intention anyway.)

  • Reported: CMMN 1.0 — Fri, 24 Jul 2015 14:01 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Create classes to hold entry and exit criterion references

    1. Modify figure 5.6 to include Criterion, EntryCriterion and ExitCriterion classes
    2. Modify table 5.18
    3. Add section 5.4.5.1 Criterion
    4. Add section 5.4.5.2 Entry Criterion
    5. Add section 5.4.5.3 Exit Criterion
    6. Modify figure 5.8
    7. Modify table 5.26
    8. Modify figure 5.7
    9. Modifiy table 5.22
    10. Modify XSD to add new elements entryCriterion and exitCriterion
    11. Modify tPlanItem complexType in the XSD
    12. Modify tStage complexType in the XSD
    13. Modify tPlanItemOnPart in the XSD

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Add name attribute to OnPart

  • Key: CR-96
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently, OnPart only have an id and description. Since they can be depicted on a diagram with a connector, it would be useful to be able to name them and to potentially use that name on the label of the connector.

  • Reported: CMMN 1.0 — Fri, 24 Jul 2015 13:45 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add name attribute to OnPart

    1. Modify Figure 5.7 to add “name” in the OnPart class
    2. Modify section 5.4.6.1 to add a table with the name attribute after the text
    3. Modify CMMN10CaseModel.xsd to add name to tOnPart

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inconsistency between XSD and meta-model for condition on IfPart

  • Key: CR-92
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The meta-model specifies that the IfPart of a Sentry can have 0..1 condition. However, in the XSD, an IfPart can have 0…* condition.

  • Reported: CMMN 1.0 — Fri, 3 Jul 2015 19:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Change cardinality of tIfPart

    1. In tIfPart complex type, replace sequence with the following:
    <xsd:sequence>
    <xsd:element name="condition" type="tExpression" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing attribute “name” for Process

  • Key: CR-90
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In figure 5.10 representing the Task metamodel, the class Process has a “name” attribute. However, in table 5.37 listing the process attributes, name is not listed.

  • Reported: CMMN 1.0 — Tue, 30 Jun 2015 13:15 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add attribute “name” to the process attributes in table 5.37

    1. Add this row to table 5.37

    name: String the name of the Process
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing "externalRef" in Process class

  • Key: CR-110
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    ProcessTask refers to a Process defined in the definitions. But this Process element doesn't have any field to relate to the external process.

  • Reported: CMMN 1.0 — Mon, 10 Aug 2015 15:20 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add externalRef to Process class

    1. Modify figure 5.1
    2. Modify table 5.37
    3. Modify CMMN10CaseModel.xsd

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Some figure in chapter 6 do not use the new Discretionary Association

  • Key: CR-104
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Figure 6.43 and 6.47 were not changed by the original proposal.

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 19:26 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Update figure 6.43 and 6.47

    1. Replace figure 6.43
    2. Replace figure 6.47

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

XSD Doesn't allow DiscretionaryItem to have entry/exit criteria

  • Key: CR-101
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Section 5.4.9.2 DiscretionaryItem clearly states that DiscretionaryItem can have entry/exit criteria. However, those attributes are not part of tDiscretionaryItem complextType in CMMN10CaseModel.

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 18:14 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Changes applied by CR-99 will fix this issue

    Changes applied by CR-99 will fix this issue

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Confusing Planning Table on figure 6.63

  • Key: CR-107
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The PlanningTable on HumanTask "Create Claims Notification" is confusing since it is shown expanded but the HumanTask doesn't have any DiscretionaryItem.

  • Reported: CMMN 1.0 — Fri, 31 Jul 2015 20:35 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Change applied to CR-76 will resolve this issue

    Resolution 106 solve this issue.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Add a new discretionary association

  • Key: CR-94
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Currently, the same “connector” is used to depict a link between a Discretionary task and its User Task and OnParts. A new connector should be introduce so those two different meaning have a different representation.

  • Reported: CMMN 1.0 — Fri, 17 Jul 2015 12:40 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add a new discretionary association

    1. Rename section 6.11 from “Connectors” to “Links”

    2. Replace the first paragraph of section 6.11 with the following:
    Certain dependencies between elements that are shown inside expanded Stages or PlanFragments are depicted using links. The shape of the connector object is a dotted line. The connector MUST not have arrowheads.

    3. Remove figure 6.29

    4. Modify the second paragraph of 6.11 to be the following:
    One such depicted dependency is the onPart of a Sentry. Those dependencies are depicted using a connector. This connector is a dotted line. The connector MUST not have arrowheads. For example, the following diagram illustrates a situation where the entry criteria of Task B depends on the completion of Task A.

    5. Place figure 6.29 after that paragraph

    6. Before figure 6.30 and after figure 6.29 add the following paragraph:
    For example, the following diagram illustrates a situation where the entry criteria of Task B depends on the completion of Task A.

    7. Modify the third paragraph of 6.11
    The other type of dependency that is visualized is the dependency between a HumanTask and DiscretionaryItems in its PlanningTable, when the HumanTask is shown with its PlanningTable expanded. These dependencies are also depicted by the same dotted line connector depicted with a discretionary association. A Discretionary Association is a dashed line. The line MUST not have arrowheads.

    8. Add a new figure to show the new link

    Figure 6.31 - Discretionary Association

    9. Change actual figure 6.31 for the following

    Figure 6.32 - Dependency between a blocking HumanTask and its associated Discretionary Tasks

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

We should add a Decision type task


Missing PlanningTable on the CasePlanModel of figure 6.63

  • Key: CR-76
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In figure 6..63 - Claims Management Example there should be a PlanningTable on the CasePLanModel in the expanded status as there are discretionary tasks showing in that CasePlanModel.

    The Stage "Identify Responsibilities" has a planing table showing in the expanded state but that stage does not show discretionary task(s) which is questionable.

  • Reported: CMMN 1.0 — Wed, 27 May 2015 21:23 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Replace figure 6.63

    1. Replace figure 6.63

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Missing notational element for discretionary Milestones and discretionary EventListeners

  • Key: CR-74
  • Legacy Issue Number: 19761
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Stages and Tasks (generalizations of PlanItemDefinitions) have discretionary notations (dashed lines), but Milestones and EventListeners (also generalizations of PlanItemDefinitions) don't have discretionary notations.
    Reading the specification seems like all PlanItemDefinitions can be discretionary, but there is no notation shown for Milestones and EventListeners.
    There is no written limitation in the specification that prevents Milestones and EventListeners from being discretionary.
    The ability to model discretionary milestones is important in situations where other discretionary items are added.

  • Reported: CMMN 1.0 — Tue, 19 May 2015 04:00 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Add notational element for discretionary Milestones and discretionary EventListeners

    Stages and Tasks (generalizations of PlanItemDefinitions) have discretionary notations (dashed lines), but Milestones and EventListeners (also generalizations of PlanItemDefinitions) don't have discretionary notations. Reading the specification seems like all PlanItemDefinitions can be discretionary, but there is no notation shown for Milestones and EventListeners. The ability to model discretionary milestones is important in situations where other discretionary items are added.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Expression description prevent constant expressions

  • Key: CR-67
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Section 5.4.7 Expressions (page 28). State that "Expressions specify String objects that are evaluated over information in the CaseFile." This sentence leaves out simple constant expressions like "true", "12", or "Mike".

    The sentence in Section 5.4.7 also contradicts the description of timerExpression in table 5.13 (page 19) "An expression string that is conforming to the ISO-8601 format for date and time, duration, or interval representations."

    The sentence in section 5.4.6 Sentry (page 24) states that " The IfPart specifies a condition, as Expression that evaluates over the CaseFile." That seems correct, but maybe over-specified.

  • Reported: CMMN 1.0 — Tue, 21 Apr 2015 19:09 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix expression description to allow constant expressions

    Section 5.4.7 Expressions (page 28). State that "Expressions specify String objects that are evaluated over information in the CaseFile." This sentence leaves out simple constant expressions like "true", "12", "Mike", or time expressions.

    Change first sentence in Section 5.4.7 Expressions (page 28), as follows:

    Expressions specify are String objects. Expressions operate over Properties and CaseFileItems that are evaluated over information in the CaseFile. In addition to CaseFile content, constant expressions are also allowed. Expressions do also specify the language in which the String objects MUST be specified.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN does not include the notion of swim lanes

  • Key: CR-69
  • Legacy Issue Number: 19751
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To clearly reflect the intent of a case style application - it is essential to provide business context. Central to that context is who does (or is responsible for) what. The existing model definition does not facilitate a clear graphical context to roles / swimlanes.
    The absence of this visual and execution definition will likely severely limit the clarity and ease of use of CMMN thereby restricting it's utility and adoption.

  • Reported: CMMN 1.0 — Tue, 21 Apr 2015 04:00 GMT
  • Disposition: Deferred — CMMN 1.1
  • Disposition Summary:

    Swimlanes is a new feature and it is out of the scope for the RTF

    The introduction of swim lanes is a complete new feature that will require more work that intended by an RTF, and so it is out of the scope of the RTF. However this feature should be considered during the next revision of the specification.

    Note that it is possible for implementers to add swim lanes to a compliant CMMN implementation, because the specification is silent about swim lanes.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Typo in the xsd: in Task we have inputs and outputs instead of input and output

  • Key: CR-120
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Task, as Case and Process, holds a list of input and a list of output. For Case an Process, input and output is used for every entry while Task use inputs and outputs, which is wrong.

  • Reported: CMMN 1.0 — Wed, 16 Sep 2015 13:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Remove "s" to input/output of tTask in the XSD

    1. In tTask complex type change

    <xsd:element name="inputs" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
    <xsd:element name="outputs" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
    

    to

    <xsd:element name="input" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
    <xsd:element name="output" type="tCaseParameter" minOccurs="0" maxOccurs="unbounded" /> 
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing attribute "name" in the XSD for ApplicabilityRule

  • Key: CR-116
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The Spec states that Applicability Rule have a "name" attribute but this attribute is missing in CMMN10CaseModel.xsd

  • Reported: CMMN 1.0 — Fri, 11 Sep 2015 14:34 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add attribute name to tApplicabilityRule

    Add the following to tApplicabilityRule just before the contextRef attribute:

    <xsd:attribute name="name" type="xsd:string"/>
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing authorizedRoleRefs in XSD for tUserEventListener

  • Key: CR-114
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The specification and the meta-model states that UserEvenListener have an authorizedRoleRefs attribute, but this attribute is missing in the CMMN10CasePlanModel.xsd

  • Reported: CMMN 1.0 — Fri, 4 Sep 2015 23:28 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add authorizedRoleRefs attribute to tUserEventListener

    Add the following to tUserEventListener inside the extension block:

    <xsd:attribute name="authorizedRoleRefs" type="xsd:IDREFS">
        <xsd:annotation>
            <xsd:documentation>authorizedRoleRefs refers zero or more "role" elements.</xsd:documentation> 
        </xsd:annotation>
    </xsd:attribute>
    
  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN needs to support Diagram Interchange

  • Key: CR-21
  • Legacy Issue Number: 19507
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    CMMN needs to support Diagram Interchange

    Given that a notion was provided a diagram interchange capability is missing

  • Reported: CMMN 1.0 — Wed, 2 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    New chapter, MM, and Schema(s) providing CMMN Diagram Interchange Capability

    1. Add Chapter 7
    2. Update chapters numeration
    3. Update CMMN1.0.xsd
    4. Update Distribution Package
    5. Update Normative References
    6. Update figure 5.1
    7. Update table 5.2
    8. Update the CMMN Meta-Model

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Ambiguous OnPart references for cross-stage-boundary plan items

  • Key: CR-14
  • Legacy Issue Number: 19496
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Suppose we have the following case definition, expressed in XML.
    <definitions>
    <case name="stages" xmlns="http://www.omg.org/spec/CMMN/20121031/MODEL">
    <caseRoles />
    <input />
    <output />
    <caseFileModel />
    <casePlanModel name="casePlan">
    <planItem name="Stage1" definitionRef="Stage" />
    <planItem name="Stage2" definitionRef="Stage" />

    <planItem name="Milestone1" definitionRef="Milestone" entryCriteriaRefs="Task1Completed" />
    <sentry name="Task1Completed">
    <planItemOnPart sourceRef="Task1">
    <standardEvent>Complete</standardEvent>
    </planItemOnPart>
    </sentry>

    <stage name="Stage">
    <planItem name="Task1" definitionRef="Task" />
    </stage>
    <milestone name="Milestone" />
    <humanTask name="Task" />
    </casePlanModel>
    </case>
    </definitions>

    Within this case, we have a Milestone1, with an entry criterion referring to Sentry called Task1Completed.
    Task1 is a plan item within Stage, hence can be referenced from the sentry.

    At runtime, however, there will be 2 instances of Task1: one in Stage1, and another within Stage2 (as both have the same stage definition).

    The specification does not say anything as to which instance plan item the sentry refers, making it ambiguous. Well ... in page 26, at SentryRef, the specification says that the sentry ref must refer to a plan item within the same stage. However, this is conflicting with the image on page 64, as indicated in the issue logged as "CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries"

  • Reported: CMMN 1.0 — Mon, 30 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicate of issue CR-7

    Duplicate

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN spec inconsistent with respect to Sentry dependencies crossing Stage boundaries

  • Key: CR-7
  • Legacy Issue Number: 19477
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Table 5.22 says, with respect to the sourceRef attribute: "SourceRef represents a PlanItem that MUST be contained by the same PlanFragment (or Stage) that also contains theSentry that contains the PlanItemOnPart."

    This implies that sentry-based dependency cannot cross stage boundaries, which is in conflict with what is suggested by the claims management example in Figure 6.63.

    The solution should be to remove the constraining text from Table 5.22.

    A similar constraint is found (and must be removed) on page 32 in the section 5.4.9.2 DiscretionaryItem

    "When entryCriteriaRefs or exitCriteriaRefs of a DiscretionaryItem have OnParts that are PlanItem
    OnParts, these OnParts MUST have a sourceRef that is contained
    • in the Stage that also contains the PlanningTable that contains the DiscretionaryItem, directly or recursively
    through a hierarchy of PlanningTables, or
    • in the Stage that also contains the HumanTask that has the PlanningTable that contains the DiscretionaryItem,
    directly or recursively through a hierarchy of PlanningTables."

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Allow Sentry to cross Stage boundaries for PlanItems only (not for Discretionary Items)

    • We'd like to allow sentries to cross Stage boundaries
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Undesired limitation on PlanItemDefinitions

  • Key: CR-3
  • Legacy Issue Number: 19444
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    The statement "PlanItemDefinitions MUST NOT be contained by any
    other Stage than the casePlanningModel of the Case." impose an undesired limitation of having all PlanItemDefinitions in the casePlanningModel.

    This imposes all kind undesired references. Simply removing this sentence will allow for local definition of PlanItemDefinitions and reduce potential for referential integrity problems.

  • Reported: CMMN 1.0 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *Remove limitation on PlanItemDefinitions, add a constraint for scoping of PlanItem, and add an example of scoping *

    1. In table 5.18 in the definition of defintionRef, add a sentence explaining constraints on PlanItem
    2. Add a new section 5.4.5.1 containing an example explaining the constraints on PlanItem
    3. Remove first bullet at top of page 29
    4. In table 5.26, modify the description of planItemDefinition
    5. In table 5.29 add a sentence to definitionRef description
    6. Add example in section 5.4.9.2
    7. Add paragraph at the end of section 5.4.1

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Evaluation/Re-evaluation of RequiredRule unclear - what does "maintained" mean?

  • Key: CR-23
  • Legacy Issue Number: 19588
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    In Table 7.8, Transition "create", the Description says: "The RepetitionRule and the RequiredRule Boolean expressions MUST be evaluated in this transition, and their Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance".

    In this Issue we are interested in the usage of the RequiredRule only.

    The first part is clear: "The [...] RequiredRule Boolean expression MUST be evaluated in this transition" - so far, so good.

    The second part of the sentence needs clarification: "and the Boolean values SHOULD be maintained for the rest of the life of the Stage or Task instance".

    Does this mean (1 OR 2):
    1) The Boolean expression of the RequiredRule is evaluated ONLY ONCE (in the 'create' transition) and then gets 'frozen' for the rest of the life cycle of the Stage or Task

    OR

    2) The Boolean expression is evaluated in the 'create' transition AND can be updated by re-evaluating the same RequiredRule-expression at some point(s) during the rest of the life of the Stage or Task? (The re-evaluation might be triggered by any event or item-transition in the case)

    Background:
    We would like to model an optional Task, which CAN turn to a required Task, while in the state 'Available' or 'Enabled' (because the parent-stage of this (Discretionary) Task is already Active).
    The change from optional to required is accomplished with a RequiredRule expression. In our case the change from an optional Task to a required Task should be triggered with an CaseFileItemTransition. Or put it simple: An optional Task changes "suddenly" to 'required' because somebody added a piece of data to the case.

    We would appreciate the clarification of the execution semantics of the RequiredRule.

  • Reported: CMMN 1.0 — Thu, 28 Aug 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix termination criteria for stages

    This issue touches in three areas:
    First, RequiredRule is evaluated in the creation transition, but it is not clear if it is set only once.
    Second, there is a desire to have RequiredRule to be set after creation.
    Third, is that the termination criteria in table 7.8 (page 73) is inconsistent with page 79 section 7.6.1 Stage.autoComplete, table 7.12 Stage Instance termination criteria.

    Note that to solve the second area, we have two options:
    a- try to evaluate RequiredRule of all the milestones, stages, and tasks that are in available or in enabled, when the stage is going to complete. The problem here is that a stage may have a autoComplete false and so a human try to complete it and finds out it cannot be completed because a new required plan item is found. This does not seems right, in addition is expensive to evaluate
    b- evaluate RequiredRule when entering Available or Enabled states. Note that after the plan item reaches Active it is required by default, so we only concerned with Available and Enabled states. Today, we do it when it enters Available, so we just need to consider adding this extra evaluation to Enabled state. In the case described in this issue, this will satisfy the situation. The task transition to Available and RequiredRule evaluates to false, but then a new case file item is added to the case, that can trigger the sentry transition to Enabled (or to Active) and we can then evaluate again the RequiredRule. This seems the best option.

    Proposal

    1- We certainly need to fix the second issue
    2- We should also evaluate RequiredRule on entrance to Enabled state (if it is in "false")

    Page 72, Table 7.8, column 4, row 2 (enable, Available, Enabled): Add the following sentence (at the end):

    If the RequiredRule Boolean expression exists and the current value is "false", then it MUST be re-evaluated in this transition and its Boolean value SHOULD be maintained for the rest of the life of the Stage or Task instance.

    Page 73, Table 7.8, column 4, row 8 (complete, Active, Completed): Rewrite as follows:

    Transition when the Stage or Task instance completes normally. For a Stage instance, this means that all its child Task and Stage instances have reached a terminal or semi-terminal state (all child Task and Stage instances have reached disabled, terminated, completed, or fault). For a Stage instance the termination criteria described in table 7.12 "Stage instance termination criteria" must be satisfied. For a Task instance, this means its purpose has been accomplished (CaseTask instances have launched a new Case instance; ProcessTask instances have launched a Process instance and if output parameters are required, then the Case or Process instance has completed and returned the output parameters; HumanTask instances have been completed by a human; etc.)

    Page 73, Table 7.8, column 4, row 13 last row (re-enable, Disabled, Enabled): Add the following sentence (at the end):

    If the RequiredRule Boolean expression exists and the current value is "false", then it MUST be re-evaluated in this transition and its Boolean value SHOULD be maintained for the rest of the life of the Stage or Task instance.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Incorrect Example image

  • Key: CR-19
  • Legacy Issue Number: 19504
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    I believe the example on page 64 is incorrect according to the specification. The example depicts sentries listening to events of plan items not contained inside the same stage.

    On page 26 following requirement is specified:
    'SourceRef represents a PlanItem that MUST be contained by the same PlanFragment (or Stage) that also contains the Sentry that contains the PlanItemOnPart'

    e.g. the sentry placed on top of 'Create claim' is contained by 'Process claims' whereas the sourceref('Base information attached') is contained by 'Claims file'

  • Reported: CMMN 1.0 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fixed by CR-106

    Resolution is in CR-106

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Unrequired “body” element in expression in the XSD

  • Key: CR-82
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In the class diagram, body is a required element to hold the actual expression. But in the XML, the body is simply the content of the Expression element, no need for another nested element for it.

  • Reported: CMMN 1.0 — Thu, 4 Jun 2015 18:40 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Remove body from tExpression in CMMN xsd

    1)
    <xsd:complexType name="tExpression" mixed="true">
    <xsd:complexContent>
    <xsd:extension base="tCmmnElementWithMixedContent">
    <xsd:sequence>
    <xsd:element name="body" type="xsd:string" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
    <xsd:attribute name="language" type="xsd:anyURI" use="optional" default="http://www.w3.org/1999/XPath" />
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Terminology inconsistency between Metamodel and XSD

  • Key: CR-79
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In the XSD, we have timerEvent, userEvent and event but in the meta-model, we have timerEventListener, userEventListener and eventListener.

  • Reported: CMMN 1.0 — Mon, 1 Jun 2015 14:09 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Rename event, timerEvent, and userEvent to eventListener, timerEventListener and userEventListener in the XSD

    In CMMN11CaseModel.xsd
    1) Rename complexType tEvent to tEventListener
    2) Rename element event to eventListener
    3) Change the type of eventListener to tEventListener
    4) Rename complexType tTimerEvent to tTimerEventListener
    5) Change the extension base of tTimerEventListener to tEventListener
    6) Rename element timerEvent to timerEventListener
    7) Change the type of timerEvent to tTimerEventListener
    8) Rename complexType tUserEvent to tUserEventListener
    9) Change the extension base of tUserEventListener to tEventListener
    10) Rename element userEvent to userEventListener
    11) Change the type of userEventListener to tUserEventListener

  • Updated: Tue, 29 Mar 2016 15:06 GMT

EventListeners erroneously listed for RequiredRule

  • Key: CR-78
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In section 5.4.11.2 Required rule you can read the following sentence:
    “A RequiredRule specifies under which conditions Tasks, Stages, EventListeners, and Milestones will be “required” to complete or terminate before their containing Stage can complete.”

    But this is contradict in many places in the spec:
    • in table 5.43, it is said that Required rule is N/A for EventListener,
    • section 5.4.11 doesn’t apply RequiredRule to EventsListener
    • in figure 5.12 you can read the following “A PlanItemControl that is the defaultControl of an EventListener, or that is the itemControl of a PlanItem or DiscretionaryItem that is defined by an EventListener, MUST NOT contain a RequiredRule.”
    • table 6.1 listing decorator applicability doesn’t appliy required to Event Listener
    • section 7.6.3 doesn’t apply RequiredRule to EventsListener

  • Reported: CMMN 1.0 — Mon, 1 Jun 2015 14:06 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Remove EventListeners from section 5.4.11.2

    In section 5.4.11.2 change the first sentence as followed:
    “A RequiredRule specifies under which conditions Tasks, Stages, EventListeners, and Milestones will be “required” to complete or terminate before their containing Stage can complete.”

  • Updated: Tue, 29 Mar 2016 15:06 GMT

XML-Schema tCaseFileItem definitionRef attribute must not be mandatory

  • Key: CR-72
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    This is to reverse the resolution to issue CR-42 since we want to allow for underspecified models.
    It was accidentally proposed and passed the ballot for issue CR-42

  • Reported: CMMN 1.0 — Tue, 28 Apr 2015 14:27 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Modify XSD tCaseFileItem and make definitonRef optional

    • Make attribute "definitionRef" of complex type "tCaseFileItem" optional again.
  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMNElement should have Documentation

  • Key: CR-70
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    The current base class CMMNElement has an attribute "description" of type string. This should be replaced by a Documentation class with attributes text and textFormat to allow documentation of CMMN Elements in various formats (PDF, HTML etc.)

  • Reported: CMMN 1.0 — Tue, 28 Apr 2015 07:12 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Introduction of Documentation class

    • Add new class "Documentation"
    • Add new diagram for CMMNElement
  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

We should allow for the State of a file item to be placed in [Square] brackets

  • Key: CR-88
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    Many time the on part will on a file item particular state.
    We should allow for the State of a file item to be placed in [Square] brackets making the intention of the modeler more explicit in a CMMN diagram

  • Reported: CMMN 1.0 — Fri, 12 Jun 2015 12:02 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    Solved within the CMMN DI

    Nothing to be done solved in CR-21

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN XSD - Inconsistent with the spec text

  • Key: CR-75
  • Status: closed   Implementation work Blocked
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In table 5.25 – Expression Attributes in CMMN 1.0 specification, it is mentioned that “The language attribute is optional.” But in the XSD, it has a default value of “http://www.w3.org/1999/XPath” so it is always set to something.

  • Reported: CMMN 1.0 — Thu, 21 May 2015 21:58 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Remove default from complexType tExpression attribute "language"

    • Remove default value from complexType "tExpression" attribute "language"
    • This is identical to what is done in BPMN 2.0 "tFormalExpression"
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Issue with Human Task XSD

  • Key: CR-77
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    In table 5.35, it is clearly stated that a HumanTask can have 0 or 1 Planning Table

    But the XML XSD of tHumanTask allows 0 or many

    minOccurs="0" maxOccurs="unbounded"

    The class diagram is fine (0..1)

  • Reported: CMMN 1.0 — Wed, 27 May 2015 21:25 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Modify XSD complextType tHumanTask to allow max. 1 planning table

    • Modify complexType "tHumanTask" element "planninTable" to allow 0 or 1 planning table.
  • Updated: Tue, 29 Mar 2016 15:06 GMT

Unclear CasefileItem TargetRef and SourceRef and instance operations referring to them

  • Key: CR-35
  • Legacy Issue Number: 19701
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    pg 16 text and table 5.11 (CaseFileItem attributes) describe how to create hierarchical structures (that could correspond to CMIS folders) using children and parent, but it is not clear the reason for targetRef and sourceRef. Clarification is needed, or they should be removed.
    pg 67. getFileItemInstanceTarget and getFileItemInstanceChild have the same description with the only exception that Target or child is used. The same is true for operations getCaseFileItemInstanceSource and getCaseFileItemInstanceParent.

  • Reported: CMMN 1.0 — Tue, 30 Dec 2014 05:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Clarify CaseFileItem containment and references

    Clarify CaseFileItem parent child relationships. With the clarification of children/parent and targetRefs/sourceRef the table 7.3 on page 67 should become clear.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

XSD attribute "processRef" MUST be required

  • Key: CR-34
  • Legacy Issue Number: 19670
  • Status: closed  
  • Source: Loydl Unternehmensberatung ( Harald Loydl)
  • Summary:

    According to Chapter 5.4.10.5 ProcessTask, Table 5.36 - ProcessTask attributes, the attribute 'processRef' (a reference to a Process) is required.
    The XSD in OMG Document dtc/14-01-01 does not reflect this:
    <xsd:attribute name="processRef" type="xsd:QName">

    In my opinion is must be:
    <xsd:attribute name="processRef" type="xsd:QName" use="required">

    The same applies to definitionRef of tCaseFileItem.

    So one of the two must be corrected: either the XSD or the class diagram.

    Also I am wondering why 'use="optional"' is used at the attributes level quite often. I thought this is the default setting anyway.

  • Reported: CMMN 1.0 — Tue, 25 Nov 2014 05:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add definitionRef use="required" in XSD definition of tCaseFileItem

    1. We should leave processRef optional because of resolution to issue CR-12 (make CaseRef and ProcessRef an expression)

    2. Modify the XSD and define attribute "definitionRef" for tCaseFileItem as follows:
    <xsd:attribute name="definitionRef" type="xsd:QName" use="required">

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Extensibility of DefinitionTypeEnum and Property types

  • Key: CR-27
  • Legacy Issue Number: 19642
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Few problems,
    a)- xsd has a DefinitionTypeEnum and table 5.4 refer to it as DefinitionType (should be DefinitionTypeEnum). Same is true for table 5.5
    b) The specification does not describe how to extend the DefinitionTypeEnum in table 5.5
    c) The specification does not describes how to extend the property types described in table 5.7.

  • Reported: CMMN 1.0 — Wed, 15 Oct 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add XML-Schema PropertyType to CMMN10CaseModel.xsd

    Proposal is to add a new PropertyTypeEnum XML-Schema enumeration and modify type tProperty

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CMMN needs to provide a standard way for vendors to serialize extensions (Vendor Extensions)

  • Key: CR-20
  • Legacy Issue Number: 19506
  • Status: closed  
  • Source: Trisotech ( Mr. Denis Gagne)
  • Summary:

    CMMN nees to provide a standard way for vendors to serialize extensions (Vendor Extensions)

    It is proposed that a schema resembling what was done in BPMN be used

  • Reported: CMMN 1.0 — Wed, 2 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add new extension capability to CMMN as per that of BPMN

    1. Add two rows to table 5.1
    -. Add a new figure of the meta model showing the relation between CMMNElement and extension in section 5.1.1 (This figure comes from resolution CR-71)
    2. Add two rows to table 5.2 after imports line
    3. Add a row at the end of table 5.2
    4. Figure 5.1 – Definitions class diagram need to be updated with Extensions depiction.
    5. A complete new section 5.1.5 Extesibility need to be added. This will have a ripple effect on table and figure numbering
    6. Figure of the meta model should be inserted after first para of section 5.1.5, in the meta model we need to add the four classes described
    7. Figure of the meta model should be inserted at the end of section 5.1.5 just before talking about Relationship. Relationship is a new class that extends CMMNElement and is related to the Definition
    8. Some changes needed to CMMN.xsd
    9. Some changes needed to CMMNCaseModel.xsd

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Timerevent based on data not possible

  • Key: CR-15
  • Legacy Issue Number: 19500
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    According to the specification, a timereventlistener can have a timerexpression (ISO-8601 format) and a starttrigger (event).

    What I seem to be missing here is the following:
    In the data of a case, I can enter a date (e.g. in a certain task). I would like to set the timer to trigger at the date (or duration) specified in the data.

    This does not seem possible when following the specification. Only a fixed time or duration can be entered.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *Modify table 5.13 attribute timerExpression to be of type Expression *

    1. The timerExpression attribute in Figure 5.5 should be defined as follows

    timerExpression : Expression
    with the following text

    "An expression that MUST evaluate to an ISO-8601 conforming representation for date, time, duration or interval."

    2. We need to modify the metamodel and add an Expression class right to TimerEventListener and timerExpression becomes an association from TimerEventListener to Expression

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Unclear when an IfPart only sentry must be evaluated

  • Key: CR-13
  • Legacy Issue Number: 19495
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    In section 7.5 it is stated that if a sentry has only an IfPart, and it's condition evaluates to true, then the sentry is satisfied.

    However, it is not specified WHEN the IfPart should be evaluated. Most logical seems when the plan item that refers to the sentry in an entry or exit criterion becomes Available.

    Also, it will be great if it is stated that the outcome of the IfPart should be preserved during the rest of the lifecycle of the plan item.

    I propose a text similar to what is said in section 7.6.4

    "This condition MUST be evaluated when the Milestone, Stage, or Task instance is instantiated and transitions to the
    Available state, and their Boolean value SHOULD be maintained for the rest of the life of the Milestone, Stage, or
    Task instance."

  • Reported: CMMN 1.0 — Mon, 30 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Clarify sentry evaluation with ifPart only

    The execution semantic for sentries is described in page 78, section 7.5 Sentry. However it is not clear on when are sentries evaluated. The onPart is easy, because it is clear that when an event happens it should be evaluated, however for sentries with no onPart it is unclear when that sentry should be evaluated. In addition the first paragraph does not mention milestones or CasePlanModel.

    Page 78, Section 7.5 Sentry: Change first paragraph as follows:

    When multiple entry criteria (sentries) are used only one is required to trigger the transition of the Stage , or Task , or Milestone instance out of Available state. The same is true for exit criteria. When multiple exit criteria (sentries) are used only one is required to trigger to transition the Stage , or Task , or CasePlanModel instance from Active to Terminated.

    Page 78, Section 7.5 Sentry: Add to the end of the section:

    Entry criterion sentries are considered ready for evaluation while the task, stage, or milestone is in Available state. Exit criterion sentries are considered ready for evaluation while the CasePlanModel, Stage, or Task is in Active state. Sentries are evaluated when events arrive to the system or when events are generated by the system. A single event may satisfy multiple sentries. Sentries with no onPart must have an ifPart, and that ifPart will be evaluated for all CaseFileItem events, because ifPart expressions are based on CaseFileItem properties.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CaseTask.CaseRef should allow for expressions to support dynamic subcases

  • Key: CR-12
  • Legacy Issue Number: 19487
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    There are several use cases with my current client where we do not know in advance what will be the actual case that is going to be invoked as a CaseTask. Broadly, the main case has 2 phases, each lasting for about 6 months. The second phase is implemented mostly by means of a subcase (plus some other things). We only know which specific subcase will be invoked right before the phase starts.
    However, in the current CMMN spec, we must know the precise subcase at the time of modeling (through the caseref property). We need a mechanism to have some logic determine the subcase at the moment it becomes Active (i.e., not when it becomes Available). Preferably through some sort of expression.
    Also at my previous employer we ran into various situations where we had a standard main case model (in COTS software) and then per customer implementation we could vary the specific subcases and subprocesses to be invoked, by means of an expression that would look into e.g. a lookup table.

    Note: when we add this to the spec, we need obviously a fixed input/output contract to which the subcase must adhere in order to be able to do parameter binding.

  • Reported: CMMN 1.0 — Tue, 24 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add "caseRefEpression" to CaseTask and "processRefExpression" to ProcessTask

    Make the selection of a specific Case or Process task an expression so that a process or case can be selected at runtime and doesn't have to be specified at design-time.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Sentry behavior for OnParts referring to Repeating PlanItems is unclear

  • Key: CR-11
  • Legacy Issue Number: 19481
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Suppose we have a plan item A that has an entry criterion and the onPart refers to a Complete transition of a plan item B that is repeatable.
    This referenced plan item B obviously has it's own lifecycle.

    The plan item A remains Available until the entry criterion is satisfied.

    But when is the entry criterion satisfied if multiple instances of B get added to the plan? Is it upon the first plan item A that is completed, or should all instance of A be completed?

    This is especially intriguing if the referenced planitem is a milestone.
    Evaluation of the RepetitionRule is clear, it should happen on create. Repeating the plan item is clear for Task and Stage, see 7.6.4: Whenever a Task or Stage becomes Active, a new instance of the plan item is added to the plan in state Available, triggering same cycle of evaluation of the repetition rule and potentially adding a new plan item if the plan item becomes Active.
    However, for Milestones this behavior of adding the repeated plan item is not specified in 7.6.4. But it seems rather intuitive to do this when the milestone Occurs.
    However, now comes the problem with sentries listening to this repeating milestone: when the sentry listens to the "Occur" of the milestone, then the entry criterion get's satisfied, and the listening plan item can go to Active ... However, at the time of the Occur transition of the milestone to Complete, a new plan item for the milestone is added to the plan, making immediately the transition Create (to have it go from Null to Available state) ... the listening sentry now immediately gets dissatisfied because of the new plan item's transition ...

    I guess this is a place to reconsider or make more explicit what the intended execution semantics should be.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Clarify sentry behaviour under repetition rule

    The question in here is what happens (what is the execution semantics) when a sentry is waiting in a plan item that has a repetition rule true.
    This clarification should be added in page 79, section 7.6.4 RepetitionRule

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

PerformerRole should be applied to PlanItem rather than HumanTask

  • Key: CR-8
  • Legacy Issue Number: 19478
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    A HumanTask can have a reference to a performer role. But why was this not done at the level of the PlanItem?
    E.g., i could have the same human task to review, referred to from 2 different plan items. In the first occurrence the review must happen by the role "knowledge worker", and if we plan the second plan item, the review must happen by the role "expert". It is the same human task, but to be done by someone else.

    Same counts for 5.4.2.2 UserEventListener reference to role, again, it would be better to have this on PlanItem level.

    Perhaps the best would be to apply a concept similar to what is done with ItemControl, where a plan item can override the default item control of a task.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    Better to keep performer role to Human Task only

    Human Task instances can be planned based on Plan Items, as well as Discretionary Items. As Human Task as PlanItemDefinition provides the definition for both, it was logical to at least link the Role there. And not to both of the others. But even when we would do it in all three, similar to the way ItemControl is used (with default in the PlanItemDefinition), we would still have a problem with the use of Role in relation to TableItem, where Role reference is used to specify whether a user is authorized to plan. And it should be possible also, when the PlanningTable is owned by a the HumanTask, that the performerRole of the HumanTask would be one of the Roles that are authorized to plan. The ItemControl-like solution would not work in relation to TableItem. Hence it is best to link the Role to HumanTask (as PlanItemDefinition), and not to PlanItem etc.
    And this “limitation” should not cause a problem, because when different “instances” of Tasks (as PlanItems) should be performed by different persons, this is possible, by assigning the Role to different organization roles or users. This assignment is outside the scope of CMMN. When it is really required that different Roles (functional and design-time Roles) perform the Tasks, then different Tasks (as PlanItemDefinitions) can be defined. This should not be a problem.
    More-over, even when we would link Role to PlanItem, the model would be complicated further, as we would also have to specify constraints, as we cannot link Roles to any PlanItem, but only to PlanItems of the PlanItemDefinition kind of HumanTask and UserEventListener. And furthermore: for different types of PlanItems, the Role reference would be named differently, like performerRole versus roleRefs, etc. It would become more complicated, and we better want to avoid that.
    And after all, the issue does not look like that important, as, based on what is suggested above, there are sufficient ways to use CMMN to achieve what you want here.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Discretionary Items should also have a Name property

  • Key: CR-5
  • Legacy Issue Number: 19475
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Currently PlanItems have a 'name' property. This is very handy to be able to distinguish a 2 planitems that refer to e.g. the same HumanTask. E.g., we have a Review Task, and we could have then 2 plan items, one to do InitialReview and the other to do SecondReview.

    The 'name' property is missing on the DiscretionaryItem ... It must be added there too for the same reasons

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add "name" property to DiscretionaryItem

    Part of that is solved as proposal from CR-1 j.)

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inconsistencies between class diagram figures and attribute tables

  • Key: CR-1
  • Legacy Issue Number: 19440
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Multiple inconsistencies between class diagram figures and attribute tables, as follows:

    a) Inconsistence between Figure 5.1 (page 9), figure 5.3 (page 15) and table 5.4 (page 11). Note that CaseFileItemDefinition has “name” in the figures, but name does not appear in the table. It has name in the xsd.

    b) Inconsistence between Figure 5.1 (page 9), figure 5.3 (page 15) and table 5.3 (page 11). Note that Import has “name” in the figure, but name does not appear in the table. Does not have name in xsd.

    c) Inconsistence between Figure 5.1 (page 9), Figure 5.10 (page 34) and table 5.33 (page 38). Note that Process has “name” in the figure, but name does not appear in the table. It has name in the xsd.

    d) Inconsistence between Figure 5.2 (page 13), Figure 5.6 (page 21) and table 5.26 (page 29). Note that Stage in the figures is missing autoComplete.

    e) Inconsistence between Figure 5.4 (page 17) and table 5.31 (page 34). Note that Task in the figure is missing isBlocking.

    f) Inconsistence between Figure 5.5 (page 19) and table 5.9 (page 14). Note that Role is missing “name” in the figure.

    g) Figure 5.7 (page 24) has two copies of CaseFileItem, and they have different attributes.

    h) Inconsistence between Figure 5.9 (page 30) and table 5.11 (page 16). Note that CaseFileItem is missing “name” and “multiplicity” in the figure.

    i) Figure 5.10 (page 34) has two copies of Expression, and they have different attributes.

    j) Inconsistence between Figure 5.11 (page 40), Figure 5.9 (page 30) and table 5.29 (page 32). Note that DiscretionaryItem has “name” in figure 5.11, but name does not appear in the table, or in figure 5.9. Does not have name in xsd.

    k) Section 5.4.11 PlanItemControl, page 40, instead of having a table for PlanItemControl, it was labeled “Figure 5.12”, which is wrong. It should be a table.

  • Reported: CMMN 1.0 — Sun, 1 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    *Fix inconsistencies in UML model diagrams and attribute tables in spec *

    Fix the issues reported in the tables and diagrams.
    The issue reported on DiscretionaryItem is handled separately as part of issue
    CR-37

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Two entry criteria cannot be connected

  • Key: CR-16
  • Legacy Issue Number: 19501
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    If you have a task contained by a stage, you cannot connect an entry criterion from the stage with an entry criterion from the task.

    This could be handy if a task should only be available if the stage was entered through a specified entry criterion.

    Only a exit criterion can be connected to an entry criterion based on this sentence on page 26:

    SentryRef, if specified, MUST refer to a Sentry that is referenced by an exitCriteriaRef of the PlanItem that is referred to as the sourceRef of the PlanItemOnPart.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    Do not remove constraints on sentryRef

    You refer to the semantics of sentryRef in table 23.
    This is a very specific, though useful situation. It is the CMMN counterpart of what is aka “state transition”: when an event comes, and one state (here stage) is exited, another state is entered, in one consistent (transition) transaction.
    We should however not remove the constraints on sentryRef, and do as if any Sentry can then reference, via its OnPart, to another Sentry. Because that would not make good semantics.
    What we provided with sentryRef is a specific, and therefore special (exceptional) situation. We should not make the exception the rule.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Mislabled table

  • Key: CR-46
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    in page 40, the table is labelled as figure 5.12

  • Reported: CMMN 1.0 — Fri, 6 Feb 2015 01:33 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicate of issue CR-53

    Duplicate of issue CR-53

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Table labeled as a figure in page 40

  • Key: CR-53
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    In page 40 and 41, the table is labeled Figure 5.12 (should be Table 5.40).

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:21 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix table label in pages 40 & 41

    The table in page 40 (which continues in page 41) is labelled Figure 5.12 (instead of table 5.40).

    Page 40, Figure 5.12 (which in reality is a table):

    Figure 5.12 Table 5.40 - PlanItemControl attributes and model associations

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Usage of Terminate state as Completion

  • Key: CR-59
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    page 39 has the sentence: "Under which conditions will Tasks, Stages, and Milestones be “required” to complete or terminate before their containing Stage can complete. This is specified by RequiredRules, as part of PlanItemControls (see 5.4.11.2)."

    Note that RequiredRules does not affects Terminate.

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:46 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    fix usage of Terminated state as completion

    Page 39, Section 5.4.11 PlanItemControl, second bullet: Change as follows:

    Under which conditions will Tasks, Stages, and Milestones be “required” to complete or terminate before their containing Stage can complete. This is specified by RequiredRules, as part of PlanItemControls (see 5.4.11.2).

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Reference missformated

  • Key: CR-55
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    The last non-normative reference has an URL enclosed in squared brackets. None of the other references have that weird formating.

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:28 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix missformated reference

    The last reference in page 4 has extra squared brackets around the URL.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Future sentence in specification

  • Key: CR-57
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    The last paragraph in page 18, reads as if CMMN will have in the future some extra event functionality.

  • Reported: CMMN 1.0 — Tue, 17 Feb 2015 01:34 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    fix future statement

    Page 18, last sentence should be changed.

    Page 18, last sentence. Change as follows:

    This will enable enables CMMN, to handle any event in a uniform way, namely as “standard events” that denote transitions in CMMN-defined lifecycles. These standard events are handled via Sentries. Sentries and these “standard events” are specified in 5.4.6.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing "decimal" type in table 5.7 property types and their URIs


Non-normative References do not include CMIS

  • Key: CR-22
  • Legacy Issue Number: 19515
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    CMIS is mentioned in several pages in the specification (for example, page 11 and 15), but it is not listed in section 3.2 Non-normative References.

    Need to add CMIS to section 3.2

  • Reported: CMMN 1.0 — Fri, 11 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add the CMIS specification as a non-normative reference in chapter 3.2

    CMIS is mentioned in several pages in the specification (for example, page 11 and 15), but it is not listed in section 3 References.

    Note that BPMN 2.0.2 only list as normative references (section 3.2) UML, MOF, and RFC-2119. All other references including XML Schema, WSDL, XPath, etc. are listed as non-normative (section 3.3).

    Therefore the proposal is to list CMIS as non-normative reference in CMMN.

    Add to section 3.2 Non-normative References, the following (reference) paragraph:

    Business Process Model and Notation (BPMN) Version 2.0, OMG, January 2011, http://www.omg.org/spec/BPMN/2.0/PDF/

    Content Management Interoperability Services (CMIS), Florian Müller, Ryan McVeigh, Jens Hübel, eds., OASIS, 23 May 2013. http://docs.oasis-open.org/cmis/CMIS/v1.1/os/CMIS-v1.1-os.html

    Davenport, Th. H. and Nohria, N., Case Management and the Integration of Labor, Sloan Management Review, 1994.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Table 7.9 contains invalid "To state" values for Resume transition

  • Key: CR-10
  • Legacy Issue Number: 19480
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Table 7.9 contains improper values for the transition propagation. E.g., when a state is active, and (parent)resume is triggered, then it says that the child state goes to "Suspended". Obviously this is wrong, as it ought to be that the child state goes from "Suspended" back to it's history state.

    In addition a suggestion: instead of mentioning each state of each type of child, perhaps it is better to mention the transition that should be invoked on the child plan items. The state machine behavior of the child already sufficiently describes from/to state combinations per transition.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix table 7.9 page 74

    There are errors in the rows 5 to 9 (last 5 rows on page 74).

    Current page 74 table 7.9

    Proposed changes to page 74 table 7.9 (five last rows in this page)

    Add new note to the table as follows:

    Notes:
    (1) If the exception is fixed and the restart transition is taken to Active, then it should continue transition into Suspended state.
    (2) Return the child to the state it has before the "parent suspend" or "suspend" transition to Suspended state.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Typo in specification, unclear what is intended here

  • Key: CR-9
  • Legacy Issue Number: 19479
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Quote: "The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e., it
    is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e., it
    is based on the same CaseFile and is “embedded” in the same Case."

    It says "... a Stage represents behavior that share the same context with the Stage ..." Perhaps the second occurrence of the word Stage should have been Case?

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Clarify difference between case task and stage

    Section 5.4.10.6 CaseTask (page 38), second paragraph reads,

    The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e. it is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same Case.

    Which is redundant.

    5.4.10.6 CaseTask (page 38), second paragraph reads,

    The difference between using a CaseTask and a Stage is that a CaseTask calls a Case that has its own context, i.e. it is based on its own CaseFile, whereas a Stage represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same Case.

    Rewrite as follows

    The difference between using a CaseTask and a Stage is that a CaseTask calls a invokes a new Case that has its own context, i.e. it is based on its own CaseFile (implements reuse), whereas a Stage executes is in the context of the current case represents behavior that shares the same context with the Stage, i.e. it is based on the same CaseFile and is “embedded” in the same current current Case (implements composition).

  • Updated: Tue, 29 Mar 2016 15:06 GMT

PlanItemControl of discretionaries should also allow repetitionrules

  • Key: CR-6
  • Legacy Issue Number: 19476
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    Literal text on page 41:

    "A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)"

    However, discretionaries can also have sentries, hence this is an illogical rule, and it must be removed.

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Clarify PlanItemControl of Discretionary items

    With exception of one paragraph in the specification discretionary items are allow to have a repetition rule. In particular the notation shows an example (figure 6.55 page 61).

    Page 41 repetionRule : RepetitionRule[0,1] explanation text read:

    A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

    Remove that text, as follows:

    A PlanItemControl that is the itemControl of a DiscretionaryItem, MUST NOT contain a RepetitionRule. (This is because the concept of “repetition” depends on the semantics of Sentries (see 5.4.11.3), and DiscretionaryItems are not associated with Sentries.)

  • Updated: Tue, 29 Mar 2016 15:06 GMT

"The construct in Figure 6.35" should be Figure 6.34

  • Key: CR-4
  • Legacy Issue Number: 19474
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    The reference to the figure is wrong. It is figure 6.34 that denotes the stage transition ...

  • Reported: CMMN 1.0 — Tue, 17 Jun 2014 04:00 GMT
  • Disposition: Duplicate or Merged — CMMN 1.1
  • Disposition Summary:

    Duplicated with part of issue 18

    duplicate with part of issue CR-18. The solution to issue CR-18 will fix this issue

  • Updated: Tue, 29 Mar 2016 15:06 GMT

The scope does not clarifies the relationship between CMMN and BPMN

  • Key: CR-2
  • Legacy Issue Number: 19441
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    The scope section should clarify the relationship between CMMN and BPMN. It is my impression that “CMMN is complementary to BPMN”, but it is not explicitly said in the specification. There is currently a debate on the relationship between CMMN and BPMN, and the specification is silent on this topic. It is important to note that CMPM RFP (Bmi/2009-09-23) request was to enhance BPMN with case management, and I believe CMMN does that, but it is not mentioned in the specification scope section.

  • Reported: CMMN 1.0 — Mon, 2 Jun 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add text to the summary session

    Add "This specification is intended to be consistent with and complementary to BPMN."

    Current text in 1 Scope session (page 1):

    This specification defines a common meta-model and notation for modeling and graphically expressing a Case, as well as an interchange format for exchanging Case models among different tools. The specification is intended to capture the common elements that Case management products use, while also taking into account current research contributions on Case management. It is to Case management products what the OMG Business Process Model and Notation (BPMN) specification is to business process management products.

    BPMN has been adopted as a business process modeling standard. It addresses capabilities incorporated in a number of other business process modeling languages, where processes are described as the predefined sequences of activities with decisions (gateways) to direct the sequence along alternative paths or for iterations. These models are effective for predefined, fully specified, repeatable business processes.

    For some time, there has been discussion of the need to model activities that are not so predefined and repeatable, but instead depend on evolving circumstances and ad hoc decisions by knowledge workers regarding a particular situation, a case (see Davenport 1994 and 2005; and Van der Aalst 2005). Applications of Case management include licensing and permitting in government, application and claim processing in insurance, patient care and medical diagnosis in healthcare, mortgage processing in banking, problem resolution in call centers, sales and operations planning, invoice discrepancy handling, maintenance and repair of machines and equipment, and engineering of made-to-order products.

    Change first paragraph as follows:

    This specification defines a common meta-model and notation for modeling and graphically expressing a Case, as well as an interchange format for exchanging Case models among different tools. The specification is intended to capture the common elements that Case management products use, while also taking into account current research contributions on Case management. It is to Case management products what the OMG Business Process Model and Notation (BPMN) specification is to business process management products. This specification is intended to be consistent and complementary to BPMN.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Missing reference to XML Schema and XPath specification

  • Key: CR-25
  • Legacy Issue Number: 19638
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Chapter 3 References is missing references to XML Schema and XPath specifications.
    XML Schema: That is important because section "5.1.4.1 Property" indicates that "Property types are derived from the top-level built-in primitive types of XML Schema". Furthermore, it indicates the reader should "see the description of the individual types in the XML Schema specification for an exact definition of the value space."
    XPath: That is important because Table 5.2 describe the default expression language as “http://www.w3.org/1999/XPath.” and section 7.3 indicates that "An implementation that uses XPath as expression language (see 5.1.2), MIGHT use XPath Extension Functions to implement those operations."

  • Reported: CMMN 1.0 — Mon, 13 Oct 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add the XML Schema and XPath specifications as a non-normative reference in chapter 3.2

    CMMN section "5.1.4.1 Property" indicates that "Property types are derived from the top-level built-in primitive types of XML Schema". Furthermore, it indicates the reader should "see the description of the individual types in the XML Schema specification for an exact definition of the value space." Therefore, we should add XML Schema to chapter 3 references. in addition, Table 5.2 describe the default expression language as “http://www.w3.org/1999/XPath.” and section 7.3 indicates that "An implementation that uses XPath as expression language (see 5.1.2), MIGHT use XPath Extension Functions to implement those operations."

    Note that BPMN 2.0.2 only list as normative references (section 3.2) UML, MOF, and RFC-2119. All other references including XML Schema, WSDL, XPath, etc. are listed as non-normative (section 3.3).

    Therefore the proposal is to list XML Schema and XPath as non-normative in CMMN.

    Add to section 3.2 Non-normative References, the following two (reference) paragraphs:

    Man, H. de, Case Management: A Review of Modeling Approaches, BPTrends, January 2009. [http://www.bptrends.com/
    publicationfiles/01-09-ART-%20Case%20Management-1-DeMan.%20doc--final.pdf ]

    XML Schema Part 2: Datatypes, Paul V. Biron and Ashok Malhotra, eds., W3C, 28 October 2004. http://www.w3.org/TR/xmlschema-2/

    XML Path Language (XPath) 1.0, James Clark and Steve DeRose, eds., W3C, 16 November 1999. http://www.w3.org/TR/xpath

  • Updated: Tue, 29 Mar 2016 15:06 GMT

CaseRoles have ugly definition in the XSD

  • Key: CR-24
  • Legacy Issue Number: 19624
  • Status: closed  
  • Source: hidera.nl ( Thijs Petter)
  • Summary:

    In the XSD, CasePlanModel and CaseFileModel are top level elements. However, CaseRoles is a "multi" element at top level, leading to XML like

    <case>
    <casePlanModel> ... </casePlanModel>
    <caseFileModel> ... </caseFileModel>
    <caseRoles name="Employee" />
    <caseRoles name="Admin" />
    </case>

    I would expect that caseRoles is also a single top level element, with <caseRole> elements inside it.

  • Reported: CMMN 1.0 — Mon, 29 Sep 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Add tCaseRoles to XSD and modify element caseRoles in tCase

    1. Add a new complexType to the XSD

    2. Modify element "caseRoles" in complexType "tCase" :

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Incorrect References

  • Key: CR-18
  • Legacy Issue Number: 19503
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    In the conformance matrix on page 2, following references should be fixed:
    2.1 --> 2.2
    2.2 --> 2.3
    2.3 --> 2.4
    2.4 --> 2.5
    6.7.2.1 --> 6.8.2.1
    6.7.2.2 --> 6.8.3.1

    On page 55, following reference should be fixed: reference to picture 6.35 should be 6.34

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Resolved — CMMN 1.1
  • Disposition Summary:

    Fix references in specification

    a- In the conformance matrix (table 2.1) on page 2, fix following references (column 1):
    2.1 --> 2.2
    2.2 --> 2.3
    2.3 --> 2.4
    2.4 --> 2.5
    6.7.2.1 --> 6.8.2.1
    6.7.2.2 --> 6.8.3.1

    Current conformance matrix (table 2.1) on page 2

    New conformance matrix (table 2.1) on page 2

    b- On page 55, change reference to picture 6.35 to 6.34

    Current text in page 55

    The construct in Figure 6.35 may be considered a “Stage transition,” triggered by a particular event. Stage B is enabled via its entry criterion (depicted on its boundary), the OnPart of which may specify as standardEvent the termination of Stage A, given that it terminates based on the exit criterion (as depicted on its boundary). That exit criterion may itself has an OnPart (not depicted as connector) that refers e.g., to the creation of a document (CaseFileItem instance). So, when an instance of the document is created, Stage A terminates, and Stage B is enabled upon termination of Stage A, given that it terminates based on that document creation event.

    Change text in page 55, as follows:

    The construct in Figure 6.35 6.34 may be considered a “Stage transition,” triggered by a particular event. Stage B is enabled via its entry criterion (depicted on its boundary), the OnPart of which may specify as standardEvent the termination of Stage A, given that it terminates based on the exit criterion (as depicted on its boundary). That exit criterion may itself has an OnPart (not depicted as connector) that refers e.g., to the creation of a document (CaseFileItem instance). So, when an instance of the document is created, Stage A terminates, and Stage B is enabled upon termination of Stage A, given that it terminates based on that document creation event.

  • Updated: Tue, 29 Mar 2016 15:06 GMT
  • Attachments:

Inputs/outputs on task

  • Key: CR-17
  • Legacy Issue Number: 19502
  • Status: closed  
  • Source: LoQutus nv ( Jochen Firey)
  • Summary:

    A task can have zero or more inputs/outputs elements.

    The naming convention seems a bit off here. Logically, it should be input instead of inputs and output instead of outputs.

  • Reported: CMMN 1.0 — Mon, 7 Jul 2014 04:00 GMT
  • Disposition: Closed; No Change — CMMN 1.1
  • Disposition Summary:

    Follow naming conventions of metamodel

    I would propose to close this issue since the association names "inputs" and "outputs" follow the naming conventions we have in place in the metamodel.

  • Updated: Tue, 29 Mar 2016 15:06 GMT

Fix unclarity in IDL Union description

  • Key: ITCR-57
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 4 of paragraph 6.14.2 it says " If a modifier for a union member with multiple legal discriminant values is used to set the value of the discriminant, the union implementation will take the first discriminant specified in IDL.". It is not the "first discriminant" but the "first discriminant value". This is triggered by the resolution of ITCR-5

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 15:50 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify discriminant

    The text should be clear to refer to "discriminant value"

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Update normative reference to point to CORBA 3.3

  • Key: ITCR-54
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The IDL to C++11 language mapping refers to CORBA v3.2, in the meantime CORBA v3.3 is there, so update the normative reference in section 3 to point to CORBA 3.3

  • Reported: CPP11 1.1 — Tue, 13 Jan 2015 08:08 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Update reference

    Update the reference to CORBA 3.3, there are no changes in CORBA 3.3 that impact IDL2C++11 but it is good to refer to the latest version of the CORBA specification

  • Updated: Wed, 8 Jul 2015 11:43 GMT

IDL2C++11 mapping lacks support for the new IDL type map

  • Key: ITCR-38
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS-XTypes specification extends the IDL type system which will be integrated into the IDL4 specification. The IDL2C++11 mapping should be extended with a new section describing the support for the IDL map type.

  • Reported: CPP11 1.1 — Tue, 26 Aug 2014 11:43 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    We propose to defer this to the next RTF because we haven't been able to prototype this in order to validate some ideas we had. Especially the needed IDL::traits<> has to be tested and tried

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Servant argument passing not precise enough

  • Key: ITCR-28
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 6.26.4 describes the argument passing for Servant, but this should use CORBA::servant_traits<PortableServer::Servant>::ref_type instead of CORBA::servant_traits<T>::ref_type

  • Reported: CPP11 1.1 — Thu, 21 Aug 2014 11:06 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Servant argument passing not precise enough

    The servant argument passing should be corrected as proposed by the issue

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Missing public specifier

  • Key: ITCR-39
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The last code example of section 6.26.6 lacks the public specifier for the class MyA. Instead of "class MyA : virtual" it should be "class MyA : public virtual"

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 12:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing public specifier

    The issue is correct, the code example should use "public virtual" instead of just "virtual"

  • Updated: Wed, 8 Jul 2015 11:43 GMT

replace POA_B by adequate skeleton

  • Key: ITCR-42
  • Legacy Issue Number: 19678
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    drop POA_B for skeleton class deriveved from abstract class and replace it adequately:

    // C++
    class A

    { ... }

    class B_skel : public virtual ... /* maybe PortableServer::Servant */,
    protected virtual A

    { ... }

    ;

  • Reported: CPP11 1.1 — Wed, 10 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Remove usage of B_Skel and remove mentioning of PortableServer::ServantBase

    The report is correct, POA_B is a left over of the old IDL to C++ language mapping. At the same time we want to remove the mandatory inheritance of PortableServer::ServantBase, that is something for the vendor to decide, not important for the user.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

_this for skeleton, not for implementation

  • Key: ITCR-41
  • Legacy Issue Number: 19672
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    _this() method example should be given for the skeleton (eg. A_skel), not for implementation (A_impl):

    // C++
    class A_skel
    : public virtual PortableServer::Servant

    { IDL::traits<A>::ref_type _this(); ... }
  • Reported: CPP11 1.1 — Mon, 8 Dec 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct code example for _this

    The code example defines the _this in the wrong class, it should be done in the skeleton class, not in the user implementation class. Because the example inheritance of the skeleton classes is up to the vendor also the inheritance of CORBA::servant_traits<A>::base_type should be removed and replaced with three dots. As last is the override something that should be removed.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Skeleton class as consistent template parameter for CORBA::servant_traits

  • Key: ITCR-44
  • Legacy Issue Number: 19697
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    Instead of the IDL interface class, the skeleton class should be used as template parameter for CORBA::servant_traits<>.

    Rationale:

    1. The servant which the traits describe is realized by an instance of a class derived from the skeleton class which in turn (directly or indireclty) inherits PortableServer::Servant but not necessarily the interface class.

    PortableServant::Server < ... < CORBA::servant_traits<A_skel>::base_type < A_impl

    instead of

    PortableServant::Server < ... < CORBA::servant_traits<A>::base_type < A_impl

    (A, A_skel and A_impl are arbitrary names denoting the interface, the skeleton and the implementation class, resp.).

    2. In chapter 6.26.4 "Servant argument passing", we have CORBA::servant_traits<PortableServer::Servant>; this takes (the very basic) servant class as template parameter.

    CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A_skel>::ref_type

    instead of

    CORBA::servant_traits<PortableServer::Servant>::ref_type < CORBA::servant_traits<A>::ref_type

    3. In chapter 6.26.3 "Servant references" CORBA::make_reference<...> takes the implementation class as argument to create a CORBA::servant_traits<...>::ref_type. This would be more consistent with CORBA::make_reference<...> taking an interface class as parameter to create IDL::traits<...>::ref_type.

    CORBA::make_reference<A_impl> -> CORBA::servant_traits<A_skel>::ref_type

    like

    CORBA::make_reference<A> -> IDL::traits<A>::ref_type

    instead of

    CORBA::make_reference<A_impl> -> CORBA::servant_traits<A>::ref_type

    4. CORBA::servant_traits<...>::base_type is used as base class for implementation classes in §§ 6.26.6 and 6.26.7. Having CORBA::servant_traits<A_impl>::base_type instead of CORBA::servant_traits<A>::base_type is more consistent with the use of IDL::traits<LocalIF>::base_type denoting CORBA::LocalObject or something derived from CORBA::LocalObject.

    CORBA::servant_traits<A_skel>::base_type < A_impl

    like

    IDL::traits<LocalIF>::base_type < MyLocalIf

    instead of

    CORBA::servant_traits<A>::base_type < A_impl

    This affects all uses of servant_traits in §§ 6.26.3, 6.26.5, 6.26.6, 6.26.7.

    The disadvantage to be considered is that the naming of the skeleton class is not standardized, so implementation classes to be provided by a programmer using an IDL to C++11 framework package cannot longer inherit a well-specified base class like CORBA::servant_traits<A>::base_type. Instead something like CORBA::servant_traits<skeleton<A>>:base_type would be required where skeleton<...> is a framework-specific template.

  • Reported: CPP11 1.1 — Sat, 27 Dec 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Keep referring to A instead of A_skel

    One of the basic rules we defined for IDL2Cpp11 is that we don't want the user to remember all kind of rules to translate between the IDL name and some Cpp11 type. At the moment a IDL type is translated to multiple C++ types we are using the IDL traits. The concept of a skeleton exists in IDL2Cpp11 but the exact class of the skeleton is accessed by the user using the CORBA::servant_traits. The proposed change will complicate the life for the user without any benefit.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

abstract interfaces with corrected skeleton name

  • Key: ITCR-43
  • Legacy Issue Number: 19686
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    § 6.26.6, to the end, about abstract interfaces:

    I guess the C++ snippet should be like

    // C++
    class A

    { ... }

    class B_skel : public virtual ... /* maybe PortableServer::Servant */,
    protected virtual A

    { ... }

    ;

    dropping the old POA_B thing.

  • Reported: CPP11 1.1 — Mon, 15 Dec 2014 05:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Duplicated issue

    This issue ITCR-43 looks to be a duplicate of ITCR-42

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Errors on code snippet related to skeleton classes

  • Key: ITCR-3
  • Legacy Issue Number: 18761
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There is an error in 6.25.6 related to the skeleton classes. The skeleton classes should derive from each other, not from the traits, so it should be as below, also C_skel is lacking.

    // C++
    class A_skel : public virtual PortableServer::ServantBase {};
    class B_skel : public virtual A_skel {};
    class C_skel : public virtual A_skel {};
    class D_skel : public virtual B_skel, public virtual C_skel {};

    The other code bits in this section also have to be checked and see if they are ok.

  • Reported: CPP11 1.0 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct skeleton inheritance

    The traits shouldn't be used in this example, those are for user code.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

In-place construction of structure types

  • Key: ITCR-1
  • Legacy Issue Number: 17420
  • Status: closed  
  • Source: Real-Time Innovations ( Sumant Tambe)
  • Summary:

    There are two main motivations:

    (1) Performance: IDL types may be large and not all IDL types may have C++11 mapping with efficient move constructors. For example, an IDL structure containing an array does not have an efficient move-ctor. Current mapping for an IDL struct type (section 6.13.1) requires an explicit constructor accepting values for each member by value in the order they are specified in IDL. Although this method is sufficient in most cases, it is not optimal. Particularly, the types that don't support efficient move-ctor.

    (2) Usability: Often C+11 standard library containers could be constructed using several alternatives. For instance, a string member in a struct may be constructed using any of its 9 constructors or a vector may be constructed using any of its 7 constructors. Currently, the IDL2C+11 specification allows construction of members of a structure using only two kinds of constructors: copy-ctor and move-ctor. (due to the pass-by-value rule mentioned above)

    Resolution: The IDL2C++11 mapping of structures could be enhanced to construct large objects in-place. Provide a way to construct the member objects of a struct in-place using a perfect-forwarding constructor. The intent is to support all the ways of constructing all the member objects from the constructor of the parent object. Moreover, a perfect-forwarding constructor may eliminate the need for a move, which may lead to some performance improvements.

    The solution relies on an idiom known as piecewise_construct idiom. It relies on a perfect-forwarding constructor that takes as many tuples as there are members in a struct. Each tuple encapsulates the parameters to construct one member. Tuples are needed because member ctor could take several parameters and the user may be interested in using them. For instance, using an allocator for std::vector. The user of the struct calls std::forward_as_tuple for each member object to group the parameters in a tuple. The special constructor simply forwards the tuples to the respective member.

    The C++ standard library uses this idiom for std::map and std::unordered_map to construct complex objects in-place using the emplace operations. However, more general uses have been identified: http://cpptruths.blogspot.com/2012/06/perfect-forwarding-of-parameter-groups.html

  • Reported: CPP11 1.0 — Mon, 11 Jun 2012 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    The issues proposes an extension to the construction of structured types. A vendor could already add this as performance improvement without being it as part of the specification. Before adding this to the specification this addition first have to be shown in a concrete product to make sure it can be implemented and is usable for users. This hasn’t been done by any vendor yet which made us decide to defer this issue to a future RTF.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Clarify valuetype factory mapping

  • Key: ITCR-12
  • Legacy Issue Number: 19498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The valuetype factory mapping is too focused on the implementation, it should just refer to IDL<T>::factory_type as base class for the user provided factory implementation and shouldn't refer to ValueFactoryBase, that is an internal detail.

    Ref devportal 3617

  • Reported: CPP11 1.1 — Wed, 20 Aug 2014 04:05 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Clarify valuetype factory mapping

    The current valuetype factory mapping ties the implementor of the specification to too much details, we should just mention the classes with their signatures and the traits.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Valuebox should also have swap support

  • Key: ITCR-11
  • Legacy Issue Number: 19260
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For valueboxes the spec should also describe swap support, they are complete so they can support swap. To be added:

    A namespace level swap and a specialization of std::swap<> must be provided to exchange the values of two valueboxes in an efficient matter.

  • Reported: CPP11 1.1 — Wed, 26 Feb 2014 05:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Valueboxes should have swap support

    The issue proposed the support of swap for valueboxes but valueboxes are valuetypes which are reference types which already have swap support, also the boxed type has swap support. It doesn't add any value to define swap support for valueboxes because that can't be used at all, it is the valuetype reference and the boxed type that can be swapped and they have already swap support

  • Updated: Wed, 8 Jul 2015 11:43 GMT

provide unique class name as mapping of PortableServer::Servant

  • Key: ITCR-8
  • Legacy Issue Number: 19035
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    Both Servant and ServantBase for the same purpose are used in the declaration of the mapping of PortableServer::Servant.

    Throughout this chapter Servant should be used unambiguously.

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Duplicate or Merged — CPP11 1.2
  • Disposition Summary:

    Provide correct mapping for Servant

    Both Servant and ServantBase are used in 6.26.2, this should be Servant, but that has already been resolved as part of ITCR-7

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Constructor declarations in Servant code are wrong

  • Key: ITCR-7
  • Legacy Issue Number: 18850
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    The code on page 42 has a class named 'Servant' but the constructors in this piece of code are declared as 'ServantBase'. Also the =-operators are referring to 'ServantBase' instead of 'Servant'.

    The text that follows this piece of code also talks about 'ServantBase' (in bold) instead of 'Servant'

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructor declarations of Servant

    ServantBase is a left over of the old IDL to C++ specification, in IDL to C++11 we only should use Servant

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Destructors of strong reference types should be public

  • Key: ITCR-6
  • Legacy Issue Number: 18849
  • Status: closed  
  • Source: Remedy IT ( Marcel Smit)
  • Summary:

    The spec dictates that the destructor of a strong reference type should be protected. Implementing this will lead to compile errors. Seems that this is a left over from the beta 1 spec.

  • Reported: CPP11 1.1 — Fri, 2 Aug 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Destructor of reference types should be public

    Reference types just have a regular destructor, not protected, else they can't be put on the stack.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Mention move constructor with abstract

  • Key: ITCR-17
  • Legacy Issue Number: 19580
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for 6.19.1 to the bullet list should be added

    a protected move constructor

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct constructors of AbstractBase

    As proposed by the submitter the move constructor should be mentioned, but also the copy/move assignment operators should be mentioned. The val argument name should be removed because it doesn't add any value

  • Updated: Wed, 8 Jul 2015 11:43 GMT

usage of OBV trait should be improved

  • Key: ITCR-16
  • Legacy Issue Number: 19577
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specicification currently lists:

    The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the OBV
    trait.

    It is not precise enough to juset say OBV traits, it should say

    The application developer then overrides the pure virtual functions corresponding to valuetype operations in a concrete class derived directly or indirectly from the IDL::traits<>::obv_type
    trait.

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct usage of OBV trait

    The concept of a OBV class is coming from the IDL to C++ language mapping, IDL to C++11 should use the concept of the obv_type trait

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Add missing default initialization for valuetypes

  • Key: ITCR-10
  • Legacy Issue Number: 19207
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.18.2 Constructors, Assignment Operators, and Destructors the default constructor of the OBV classes is mentioned. This lacks a description that it should initialize members, proposal is to add to 6.18.2, OBV part, after the first sentence add:

    The default constructor initializes object
    reference members to appropriately-typed nil object references, basic datatypes to their default value as listed in
    Table 6.2, and enums to their first value. All other members are initialized using their default constructors.

  • Reported: CPP11 1.1 — Fri, 7 Feb 2014 05:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Add missing behavior of the default constructor

    As suggested by the submitter the behavior of the default constructor for the OBV classes should be mentioned

  • Updated: Wed, 8 Jul 2015 11:43 GMT

wrong return type for Foo::some_function()

  • Key: ITCR-9
  • Legacy Issue Number: 19036
  • Status: closed  
  • Source: langensoft.com ( T. Langen)
  • Summary:

    The return type should be

    IDL::traits<Test::Hello>::ref_type

    instead of

    CORBA::servant_traits<Test::Hello>::ref_type

  • Reported: CPP11 1.1 — Mon, 28 Oct 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct return type of example method

    In the example code as part of section 6.23.3 the incorrect return type is given. The correction as suggested by the submitter is the correct one

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Question on unions default member

  • Key: ITCR-5
  • Legacy Issue Number: 18832
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    In the section 6.14.2 on union mapping, it says :
    "If there is a default case specified, the union is initialized to this default case. In case the union has an implicit default member it is initialized to that case. In all other cases it is initialized as empty."

    I don't get the meaning of "empty" and it doesn't seem to be defined. For example, if we have a union with a boolean discriminator which defines the two cases true and false, what happens if we read one of the fields or if we call _d (with or without parameter)? Should they all throw BAD_PARAM?

  • Reported: CPP11 1.1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Improve description of union

    After some prototyping and looking at the normal C+11 unions we propose to initialize the union in all other cases to the first discriminant in IDL, this is matching C+11 unions

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Code fragment should use skel class

  • Key: ITCR-4
  • Legacy Issue Number: 18762
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:



    The code snippet for the _this method should be using the A_skel class which is derived from PortableServer::ServantBase, not the impl class

  • Reported: CPP11 1.0 — Fri, 7 Jun 2013 04:00 GMT
  • Disposition: Closed; No Change — CPP11 1.2
  • Disposition Summary:

    Code fragment should use skel class

    After carefully reviewing the specification and comparing it with our implementation we came to the conclusion that this issue is not correct. The specification is correct and nothing has to be changed in this chapter.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Move constructor of ValueBase incorrect

  • Key: ITCR-15
  • Legacy Issue Number: 19576
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The listed move constructor of ValueBase is incorrect, it should be

    ValueBase(ValueBase&&);

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct move constructor of ValueBase

    Proposal is to accept the changed as made by submitter

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Missing move assignment operator in class ColorValue

  • Key: ITCR-14
  • Legacy Issue Number: 19575
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The class ColorValue as example is missing the move assignment operator which should be:

    ColorValue(& operator= (ColorValue(&&)

  • Reported: CPP11 1.1 — Wed, 13 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Correct provided signature for valuebox types

    Triggered by this issue we addressed the incorrectly provided signature for valuebox types. Also the argument name "val" got removed because it doesn't add any value and we don't want to propose a specific name (which could clash when the user for example defines a valuebox of type val)

  • Updated: Wed, 8 Jul 2015 11:43 GMT

fixed member types use incorrect type

  • Key: ITCR-19
  • Legacy Issue Number: 19582
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In table 6.11 digits/scale are described, they should use uint16_t instead of uint32_t, see the above template, there also uint16_t is used

  • Reported: CPP11 1.1 — Mon, 18 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Replace uint32_t with uint16_t as proposed

    Proposal is to replace uint32_t with uint16_t as proposed, the digits and scale are both uint16_t

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Destructor should just be virtual

  • Key: ITCR-18
  • Legacy Issue Number: 19581
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for 6.19.1 to the bullet list mentions

    a protected pure virtual destructor

    This should be

    a protected virtual destructor

    it is not pure, see the example later on

  • Reported: CPP11 1.1 — Fri, 15 Aug 2014 04:00 GMT
  • Disposition: Resolved — CPP11 1.2
  • Disposition Summary:

    Make destructor just virtual

    Proposal is to make the destructor of abstract base "protected virtual" as proposed by the submitter

  • Updated: Wed, 8 Jul 2015 11:43 GMT

IDL2C++11 issue : CORBA dependency of the C++11 mapping

  • Key: ITCR-2
  • Legacy Issue Number: 18533
  • Status: closed  
  • Source: THALES ( Nawel Hamouche)
  • Summary:

    A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL
    interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException.
    Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA.
    I would suggest the following changes in the IDL2CPP11 specification :

    • To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException.
    • To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly.
    • To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly.
    • To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include :
      6.16 Mapping for the Any Type
      6.17 Mapping for Valuetypes
      6.18.1 Abstract Interface Base
      6.21 TypeCode
      6.22 ORB
      6.23 Object
      6.24 LocalObject
      ... until 6.28
  • Reported: CPP11 1.1 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    The IDLC+11 language mapping explicitly refers to CORBA v3.2 because there is no clean IDL specification yet. There should first be a clean IDL4 specification that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. After that someone has to implement this and see if there are no unforeseen issues, when that all has been done we can update the IDL2C+11 specification accordingly

  • Updated: Wed, 8 Jul 2015 11:43 GMT

Make mapping of sequences more flexible

  • Key: ITCR-13
  • Legacy Issue Number: 19499
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 6.12 we define:

    An unbounded sequence is mapped to a C++ std::vector.

    For example a sequence of octets is now not optimal, in order for implementations to optimize sequences but users not to harm we propose to change this definition to

    An unbounded sequence is mapped to a type delivering C++ std::vector semantics.

  • Reported: CPP11 1.1 — Tue, 1 Jul 2014 04:00 GMT
  • Disposition: Deferred — CPP11 1.2
  • Disposition Summary:

    Defer to future RTF

    Deferring to RTF because we haven't been able to prototype this in order to validate that there are no unforeseen problems.

  • Updated: Wed, 8 Jul 2015 11:43 GMT

ZIOP has to be part of the core CORBA specification

  • Legacy Issue Number: 16922
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ZIOP specification is an addition to CORBA and should be merged into the main CORBA specification instead of being a stand alone specification

  • Reported: ZIOP 1.0 — Tue, 20 Dec 2011 05:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Move the ZIOP Compression module to CORBA Part 1, section 18
    Move the ZIOP Module to CORBA Part 2, section 12

  • Updated: Thu, 12 Mar 2015 02:25 GMT

question re BiDir IIOP

  • Legacy Issue Number: 2461
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I am having difficulty understanding the intended use of
    BiDirPolicy::BidirectionalPolicy. This is described (in section 15.9) as
    a POA policy to be passed to create_POA. That section also says that
    both client and server must have the policy with the value of BOTH for
    bi-directional communication to take place.

    My problem is that I don"t see how this policy applies to a particular
    POA. Once bi-directional communication has been negotiated on a
    connection, it applies to any request targetted at the negotiated
    address(es), regardless of what POA is the recipient of the request. Nor
    is it tied to the lifetime of a particular POA. And, what is supposed to
    happen if one POA has the policy with value BOTH, and another POA has
    the policy with value NORMAL?

  • Reported: CORBA 2.2 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :BidirectionalPolicy. This is described (in section 15.9) as

  • Updated: Wed, 11 Mar 2015 04:29 GMT

New OBV "supports" keyword conflicts with CosLifeCycle

  • Legacy Issue Number: 1782
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The new OBV keyword "supports" collides with the operation "supports"
    defined in CosLifeCycle::GenericFactory.

  • Reported: CORBA 2.2 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :GenericFactory.

  • Updated: Wed, 11 Mar 2015 04:26 GMT

Abstract Interface issue (02)

  • Legacy Issue Number: 1720
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If we accept 2 above, we may want to revisit the following:
    – 8.8.2, page 8-104, bullet 4:
    "Inserting an abstract interface reference into a CORBA::Any
    operates polymorphically. Either the object reference or value to
    which the abstract interface reference refers is what actually gets
    inserted into the Any. This is because there is no TypeCode for
    abstract interfaces. Since abstract interfaces can not be inserted into
    an Any, there is no need for abstract interface extraction operators."

  • Reported: CORBA 2.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Wed, 11 Mar 2015 04:24 GMT

IDL keyword clash in CosNotification.idl

  • Key: CORBA3-134
  • Legacy Issue Number: 4901
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    CosNotification.idl contains a struct named 'EventType', which
    clashes with the new CCM-related keyword 'eventtype'.

  • Reported: CORBA 2.6 — Tue, 5 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    purely editorial issue

  • Updated: Wed, 11 Mar 2015 04:16 GMT

Query Service IDL code

  • Legacy Issue Number: 2488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Query Service IDL code (document 97-12-18) has multiple syntax
    errors. I have checked it with Orbix, OrbixWeb and Visibroker IDl
    compiler.

  • Reported: CORBA 2.3 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Wed, 11 Mar 2015 04:16 GMT

CORBAservices IDL

  • Key: CORBA25-57
  • Legacy Issue Number: 959
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CosStream Module the CompoundExternaliztion.idl is included
    > (needed for CosCompoundExternalization::Node), and in the
    > CosCompoundExternalization Module the Stream.idl is included (needed
    > for CosStream::Streamable and CosStream::StreamIO). Now correct me
    > if I am wrong but isn"t this self-referential loop going to cause
    > problems with the IDL compiler, in that either CosStream will not
    > know about CosCompoundExternalization or vice-versa causing a
    > compiler error.

  • Reported: CORBA 2.2 — Tue, 24 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    refer to formal/98-12-16

  • Updated: Wed, 11 Mar 2015 04:16 GMT

CORBAservices (editorial page 17-23)

  • Key: COLL-12
  • Legacy Issue Number: 762
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the description of the first parameter "collection_interface" of type Istring, ther starting quote of the word collection_interfaceis missing.

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Disposition: Resolved — COLL 1.0
  • Disposition Summary:

    editorial

  • Updated: Wed, 11 Mar 2015 04:13 GMT

CORBAservices (editorial page 17-22)

  • Key: COLL-11
  • Legacy Issue Number: 761
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are three comments in the interface description that do not have the same style (font) as the other comments

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Disposition: Resolved — COLL 1.0
  • Disposition Summary:

    editorial

  • Updated: Wed, 11 Mar 2015 04:13 GMT

CORBAservices (editorial page 17-21)

  • Key: COLL-10
  • Legacy Issue Number: 760
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: After ElementInvalid and KeyInvalid, you discuss ParameterInvalid. There is a space written in it: Paramete_rInvalid

  • Reported: COLL 1.0b1 — Mon, 29 Sep 1997 04:00 GMT
  • Disposition: Resolved — COLL 1.0
  • Disposition Summary:

    editoral

  • Updated: Wed, 11 Mar 2015 04:13 GMT

Name scooping inappropriate within some mainframe environments

  • Key: COBOL-6
  • Legacy Issue Number: 602
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Within some mainframe environments, only the first 8 bytes of a name within a CALL statement are significant. This restriction means that current mapping is not usable within such environments

  • Reported: COBOL 1.0b1 — Fri, 11 Jul 1997 04:00 GMT
  • Disposition: Resolved — COBOL 1.0
  • Disposition Summary:

    issue resolved, closed

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Change the VMM

  • Key: CORP-7
  • Legacy Issue Number: 3733
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The VMM elements derived from CORBAWrapper need not be stereotypes of
    Class; Classifier would suffice. Cleaning this up would require a small
    rearrangement of the VMM. This only affects abstract stereotypes, so it
    doesn't change how one actually models.

    Recommendation: Change the VMM accordingly.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    resolved

  • Updated: Mon, 9 Mar 2015 00:40 GMT

Name of the model element for CORBAUnions

  • Key: CORP-6
  • Legacy Issue Number: 3732
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The name of the model element for CORBAUnions may conflict with
    legitimate member names of the union.

    Recommendation: Instead of specifying a naming convention for the model
    element representing a switch, define a stereotype for a switch and use this
    stereotype to denote that a model element represents a switch. There will
    need to be one stereotype that extends AssociationEnd and one that extends
    Attribute, because the model element representing a switch is an
    AssociationEnd if the switch's type is non-primitive, and is an Attribute if
    the switch's type is primitive.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    resolved

  • Updated: Mon, 9 Mar 2015 00:40 GMT

Add long double to the coverage of CORBA primitive types.

  • Key: CORP-5
  • Legacy Issue Number: 3731
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The submission's coverage of CORBA primitive types (section 6.5.1.1)
    does not cover the long double primitive type.

    Recommendation: Add long double to the coverage of CORBA primitive types.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    long double will be added to the set of primitives in the same style as long long.

  • Updated: Mon, 9 Mar 2015 00:40 GMT

The UML 1.4 RTF may tighten the definition of a UML profile.

  • Key: CORP-4
  • Legacy Issue Number: 3730
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Recommedation: If possible, synchronize the FTF report with the UML RTF
    report.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    I have no way to resolve this issue, and I suggest we close this issue without further action.

  • Updated: Mon, 9 Mar 2015 00:40 GMT

Namespace rules

  • Key: CORP-3
  • Legacy Issue Number: 3729
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: Namespace rules have been changed in the latest CORBA core
    specification. Specifically, a parent and child can't have the same name.
    This restriction holds only for children and does not hold for grandchildren
    and more distant descendants.

    Recommendation: Fix the formal constraints about namespace containment
    specified in the submission.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    An English constraint and equivalent OCL expression will be inserted to reflect this IDL constraint.

  • Updated: Mon, 9 Mar 2015 00:40 GMT

The spec. doesn't say precisely which version of CORBA it is targeted to

  • Key: CORP-2
  • Legacy Issue Number: 3728
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Recommendation: Specify this (probably CORBA 2.4) and flag IDL features that
    the submission covers but that haven't been made available yet. (Since
    local has been placed in 2.4, attributes raising exceptions is the only
    feature that falls into this category). The conformance language for
    forward engineering tools should be correspondingly tightened.

  • Reported: CORP 1.0b1 — Wed, 28 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 9 Mar 2015 00:40 GMT

OBV TypeCode problems

  • Legacy Issue Number: 1685
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For valuetypes that inherit from concrete valuetypes, the
    ORB::create_value_tc operation is insufficient. In particular, it does not
    allow the TypeCode for the base valuetype to be supplied. This means that
    if a valuetype with a concrete base valuetype is passed in an Any to a
    process that has no compile-time information concerning that valuetype, the
    receiving process will be unable to marshal it. Having the RepositoryId of
    the concrete base in the TypeCode does not solve the problem because the
    two processes might not have an Interface Repository (IFR) in common, or
    the concrete base RepositoryId may not be in the IFR known to the receiving
    process. Also, never in CORBA should unmarshaling require lookups in the
    IFR (this in fact should be an absolute ORB Core rule).

    Proposal: change create_value_tc to

    TypeCode create_value_tc(
    in RepositoryId id,
    in Identifier name,
    in boolean is_custom,
    in TypeCode concrete_base,
    in ValueMembersSeq members
    );

    If the valuetype has no concrete valuetype base, the concrete_base argument
    shall be a nil TypeCode reference.

  • Reported: CORBA 2.2 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :create_value_tc operation is insufficient. In particular, it does not

  • Updated: Sun, 8 Mar 2015 21:52 GMT

Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Key: CORBA26-99
  • Legacy Issue Number: 5994
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    Include GIOP over Bluetooth into Wireless CORBA 1.1

  • Reported: CORBA 2.5 — Mon, 14 Jul 2003 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Sun, 8 Mar 2015 21:43 GMT

Module separator within repository IDs

  • Legacy Issue Number: 1727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The module separator within "IDL: style" repository IDs is a "/".
    The module separator within "H: style" repository IDs is a "::".
    Was this difference intentional? If so, why? It seems confusing
    to treat scoped names differently in the two kinds of IDs.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    style" repository IDs is a "::".

  • Updated: Sun, 8 Mar 2015 21:43 GMT

DynAny::get_value collision

  • Legacy Issue Number: 1529
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OBV specifies a DynAny::get_value operation to retrieve a value from a
    DynAny, but this operation breaks the existing DynFixed::get_value
    operation. I suggest renaming the DynAny::get_value to avoid the collision
    (gee, if we didn"t use "value" as one of those funny keyword identifiers,
    this wouldn"t be a problem).

  • Reported: CORBA 2.2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :get_value

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Problem with C++ language mapping for OBV

  • Legacy Issue Number: 1526
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The following IDL cannot be translated into C++ code by an IDL
    compiler for a C++ environment that does not support namespaces:

    // IDL
    module M {
    struct S

    { boolean b; }

    ;

    interface I

    { void op(in S arg); }

    ;

    value V supports A {
    };
    };

    The reason for this is that module M maps to a C++ class when namespaces
    are not available, and you end up with the following definition loop:

    POA_M::I must be defined before M::V, since M::V inherits from it
    M must be defined before POA_M, because POA_M::I depends on M::S
    but defining M also defines M::V

  • Reported: CORBA 2.2 — Tue, 16 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

public static org.omg.CORBA.ValueDef get_value_def();

  • Legacy Issue Number: 1321
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 6-63 of orbos/98-01-18, the get_value_def() method is defined in
    the helper class as:

    public static org.omg.CORBA.ValueDef get_value_def();

    Currently, there is no portable way to implement this method for all
    vendor ORB"s. One suggestion is to pass an ORB implementation instance
    as parameter:

    get_value_def(org.omg.CORBA.ORB orb);

    and then add a method to the ORB class such as:

    get_value_def(String idl_name);

    Thus a portable implementation could be

    public static org.omg.CORBA.ValueDef get_value_def(org.omg.CORBA.ORB
    orb)

    { return orb.get_value_def(id()); }
  • Reported: CORBA 2.2 — Thu, 14 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

Clarify semantics

  • Legacy Issue Number: 1285
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    issue was missing information, no action

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Which exceptions should be raised?

  • Legacy Issue Number: 1281
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify which exception should be raised when no local class is
    available to support an incoming value:
    p 5-29, item 3 says it should be NO_IMPLEMENT
    p 5-34, 3rd paragraph says it should be MARSHAL
    p 5-34, last paragraph says it should be BAD_PARAM
    p 6-67, last item says it should be MARSHAL
    p 7-93, first paragraph of 7.3.10.2 says it should be MARSHAL

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

Grammar rule issue

  • Legacy Issue Number: 1254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The new grammar rule:
    <state_member> ::= <public_token> <type_spec> <declarators> ";"

    <type_spec> <declarators> ";"
    seems to open up another large hole for making the grammar non-LALR(1), which may
    or may not have been intentional. This becomes clear as you work your way back
    through the set of grammar rules. For example, according to the way I read the rules,
    the following is legal "new" IDL:
  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    := <public_token> <type_spec> <declarators> ";"

  • Updated: Sun, 8 Mar 2015 21:42 GMT

"Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ]

  • Legacy Issue Number: 1250
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve come across another small glitch in the orbos/98-01-18
    "Objects by Value" spec. This is in section 5.4.1 "Syntax", for the grammar rule:

    <value_inheritance_spec> ::= ":" [ <safe_token ] <scoped_name>

    { "," <scoped_name> }*

    [ <supports_token> <scoped_name> { "," <scoped_name> }

    * ]

    As the rule (and the rules referring to this rule) are written now, a value
    inheritance spec is either optional, or if specified, MUST begin with an
    inheritance relation to another value type (e.g. : value foo2: foo1

    { ... }

    ).

  • Reported: CORBA 2.2 — Tue, 28 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 21:42 GMT

CODESET_INCOMPATIBLE exception is not defined

  • Legacy Issue Number: 495
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CODESET_INCOMPATIBLE is not defined in CORBA 2.0, and so must be added to the list of standard exceptions in section 3.15.1

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current core 2.3 draft, issue closed

  • Updated: Sun, 8 Mar 2015 21:42 GMT

Wide String (and String encoding)

  • Legacy Issue Number: 140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are the string lengths number of bytes or characters (in 3.1.2 of orbos/96-02-03)?

  • Reported: CORBA 1.2 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved in current 2.3 draft, close issue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

IDL TypeExtension correction

  • Legacy Issue Number: 131
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an error in the grammar as written, so that you cannot (for example) have attributes of type wstring.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved in Core 2.3 draft, close dissue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

IDL Type Extensions: DATA_CONVERSION exception

  • Legacy Issue Number: 494
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Algorithm on p. 27 says to raise DATA_CONVERSION exception, but textual description on p. 28 par 1 specifies CODESET_INCOMPATIBLE exception when client and server native codesets aren"t compatible

  • Reported: CORBA 1.2 — Tue, 4 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved is current 2.3 draft, closed issue

  • Updated: Sun, 8 Mar 2015 21:42 GMT

What should an ORB do when it does not find any profile in an IOR

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

    As per the discussion in the Interop RTF meeting in Mesa, it was decided to
    split up 2457 into two parts as follows:

    Part 1: What should an ORB do when it does not find any profile in an IOR that
    it is able to use? This should usually not happen in a CORBA interoperability
    compliant ORB, but the possibility should be covered in the spec anyway.

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with agreed resolution

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Standard System Exception minor codes missing in Chapter 13

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

    Chapter 13 (formal/99-07-17) is missing specification of minor codes for many
    the standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    correct the erroneous minor codes and add ones where missing in chaps 13 and 15. Leave the resolutio

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Component ids in 13.6.2.2

  • Legacy Issue Number: 2914
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Also, 13.6.2.2 claims "ORB services are assigned component identifiers
    in a namespace that is distinct from the the profile identifiers".
    What is the significance of this statement?

  • Reported: CORBA 2.3.1 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    duplicate

  • Updated: Sun, 8 Mar 2015 19:20 GMT

OBV chunk boundaries

  • Legacy Issue Number: 2155
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 15.3.4.4. of ptc/98-10-11 includes the following statement wrt to
    ObV chunking:

    "The data may be split into multiple chunks at arbitrary points except
    within primitive CDR types, arrays of primitive types, strings, and
    wstrings."

    Unfortunately, this provides only dubious benfits, but introduces
    significant problems. Traditionally, CDR has been designed so that encoding
    engines are only responsible for marshalling CDR primitives, and remain
    independent of the actual constructed IDL type being marshalled. The above
    clause violates this rule: the CDR stream must know that the primitives
    being marshalled are part of an array, understand the size of the array,
    distinguish sequences from arrays, etc.

    In addition, this is impossible to implement using the Java portable
    streams.

  • Reported: CORBA 2.2 — Fri, 30 Oct 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 19:20 GMT

Transmission of type codes across 2.2/2.3 boundaries

  • Legacy Issue Number: 1962
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suppose I am using a 2.3 ORB and receive a type code from a 2.2 ORB without
    a repository ID. What am I supposed to do if I want to send that type
    code somewhere else? (This could happen for an event channel, for example.)

  • Reported: CORBA 2.2 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    In this case, we need to add the case for empty repository ID string implies that a repositoryID is

  • Updated: Sun, 8 Mar 2015 19:20 GMT

LOCATE_FORWARD_PERM and hash()

  • Legacy Issue Number: 1486
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: With GIOP 1.2, we added LOCATE_FORWARD_PERM to the protocol, which
    permanently replaces an IOR with a different one. I believe we shouldn"t
    have done this because it creates an internal inconsistency. The
    Object::hash() operation requires that the hash value for a reference
    must be immutable during its life time. (Unfortunately, "life time" isn"t
    well-defined.)

  • Reported: CORBA 2.2 — Wed, 3 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved

  • Updated: Sun, 8 Mar 2015 19:20 GMT

Clarification requested on GIOP 1.1 and wstring

  • Legacy Issue Number: 1948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Document interop/98-08-02 states:

    For GIOP versions prior to 1.2, interoperability for Wstring is limited
    to the use of two octet fixed length encodings.

    Does this mean simply that only fixed length character encodings that
    are use 2 byte characters are allowed for GIOP versions prior to 1.2?

    The statement is slightly ambiguous, in that it can be parsed as: "(two
    octet) fixed length encodings" or "two (octet fixed length encodings)".

  • Reported: CORBA 2.2 — Mon, 14 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue without change

  • Updated: Sun, 8 Mar 2015 19:03 GMT

Japan CORBA Part 2 PAS Ballot Comments - comment 12

  • Legacy Issue Number: 14394
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Summary:
    Location:
    7.5
    Comment:
    "see CORBA part1, clause 4" is ambiguous.
    Proposed change:
    Replace "see CORBA part1, clause 4" with "in clause 5 of ISO/IEC 19500-1, The Object Model".

  • Reported: CORBA 3.1 — Tue, 29 Sep 2009 04:00 GMT
  • Disposition: Resolved — CORBA 3.1.1
  • Disposition Summary:

    Agree to refer to named clause in 19500-1

  • Updated: Sun, 8 Mar 2015 18:08 GMT

20.17.9 Valuetype Inheritance

  • Key: CPP11-266
  • Legacy Issue Number: 2489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For an IDL valuetype derived from other valuetypes or that supports
    interface types, several C++ inheritance scenarios are possible:
    ...

    • Interface classes supported by the IDL valuetype are not inherited. Instead,
      the operations on the interface (and base interfaces, if any) are mapped to
      pure virtual functions in the generated C++ base value class. In addition to
      this abstract base value class and the OBV_ class, the IDL compiler generates
      a POA skeleton for this value type; the name of this skeleton is formed by
      prepending the string "POA_" to the fully-scoped name of the valuetype. The
      base value class and the POA skeleton of the interface type are public virtual
      base classes of this skeleton.

    Consider this example:

    // IDL
    interface I {};
    abstract valuetype A supports I {};
    valuetype B : A {};

    Is a POA skeleton generated for A? Is one generated for B?

  • Reported: CPP 1.0 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:33 GMT

sequence max < length

  • Key: CPP11-265
  • Legacy Issue Number: 1947
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens when you pass a maximum argument that is less than the length
    argument to the "T* data" constructor of an unbounded sequence? Should the
    length argument be treated as equal to the max argument, or should an
    implementation-defined error (such as an assert) be allowed?

    What happens if you pass a null pointer for the buffer argument to the "T*
    data" constructor of a sequence? Should the constructor create the sequence
    as if it was created with the default constructor, or should an
    implementation-defined error (such as an assert) be allowed? Should a null
    pointer argument be allowed if the maximum and length arguments are zero?

  • Reported: CPP 1.0b2 — Sun, 13 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:33 GMT

Rounding and truncation of Fixed

  • Key: CPP11-264
  • Legacy Issue Number: 1899
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens if I do:

    Fixed f = "999999.999";
    Fixed f2;

    f2 = f.round(3, 1); // ???
    f2 = f.truncate(3, 1); // ???

    Should these throw DATA_CONVERSION? I think so – if we agree on this,
    the spec should state it.

  • Reported: CPP 1.0b2 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:33 GMT

Fixed-point initialization

  • Key: CPP11-263
  • Legacy Issue Number: 1898
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Fixed mapping requires throwing DATA_CONVERSION if a value has more
    than 31 integral digits:

    Fixed f = 1E32; // DATA_CONVERSION

    This raises the question of how to deal with Fixed types in environments
    without C++ exceptions. Presumably, we need to add a CORBA::Environment
    parameter everywhere. Unfortunately, that isn"t possible with the overloaded
    operators that are currently defined.

  • Reported: CPP 1.0b2 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:33 GMT

C++ Servants: Adding Reference counting

  • Key: CPP11-262
  • Legacy Issue Number: 1631
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for the Portability Specification does not provide
    reference counting for servants. This proposal adds reference
    counting to the C++ mapping to ease memory management of
    implementations. It borrows from the C++ language mapping from the
    Objects by Value specification which does have reference counting for
    values. Specifying the reference counting calls is important so that
    both the Adapter implementation and multi-threaded application code
    can cooperate to ensure that implementations are only deleted when no
    longer used by any thread. Without specifying these calls, deadlocks
    are extremely easy to introduce into the system.

  • Reported: CPP 1.0b2 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:33 GMT

Add _narrow() operation to each POA servant

  • Key: CPP11-261
  • Legacy Issue Number: 1534
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The C++ spec requires that all POA servant classes derive from
    PortableServer::ServantBase as a virtual base class. For C++
    environments without RTTI, it is then impossible for the programmer to
    narrow a servant received from the POA via reference_to_servant() or
    id_to_servant() back to the programmer"s specific servant class.

    Proposal: Add a _narrow() operation to each POA servant class in the
    same fashion that _narrow() operations are defined for exception
    classes:

    // IDL
    interface A { };

    // C++
    class POA_A : public virtual PortableServer::ServantBase

    { public: POA_A *_narrow(PortableServer::Servant); }

    ;

    The _narrow() operation will return a valid pointer if the servant isa
    POA_A, otherwise it returns 0.

  • Reported: CPP 1.0b2 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    :ServantBase as a virtual base class. For C++

  • Updated: Sun, 8 Mar 2015 15:33 GMT

TypeCode constants for bounded strings?

  • Legacy Issue Number: 2007
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.2 has the following sentences near the beginning of section
    8.7.2:

    In the case of an unnamed, bounded string type used directly in an
    operation or attribute declaration, a TypeCode constant named
    TC_string_n, where n is the bound of the string is produced. (For
    example, "string<4> op1();" produces the constant "TC_string_4".)

    CORBA 2.3 is missing these sentences.

  • Reported: CORBA 2.2 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:27 GMT

DynValue::get_members/set_members

  • Legacy Issue Number: 2252
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The final draft (ptc/98-10-16 - from 15-Nov-98) defines
    DynValue::get_members/set_members as:


    struct NameValueAccess

    { FieldName id; Visibility access; any value }

    ;

    typedef sequence<NameValueAccess> NameValueAccessSeq

    NameValueAccessSeq get_members();
    void set_members(in NameValueAccessSeq values) raises (InvalidSeq),

    and goes on to say "Any attempt to set or get a member which has been
    declared private in the IDL definition of the value contained in the
    dynamic any raises the exception NO_PERMISSION."

  • Reported: CORBA 2.2 — Thu, 10 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    :get_members/set_members as:

  • Updated: Sun, 8 Mar 2015 15:26 GMT

IDL constant declarations

  • Legacy Issue Number: 2883
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the spec makes no statement as to the legality of the following constant
    definitions:

    const long C1 = 3.14;
    const short C2 = 1.0;
    const unsigned long C3 = -1;
    const char C4 = 10;
    const char C5 = 500;
    const long C6 = 999999;
    const short C7 = C6;
    const octet C8 = 1000;
    const short C9 = C5;
    const short C10 = 100 * 100 * 100;

    I"m sure that there are lots of others I haven"t thought of, but you get
    the idea...

    There are certainly lots of holes in the spec, with respect to both the
    legal types of the RHS and rules for overflow/underflow and mixed-type
    arithmetic. Looks like this will require a major cleanup...

  • Reported: CORBA 2.3.1 — Sun, 12 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:24 GMT

Conflict between POA & Exceptions spec for OBJECT_NOT_EXIST

  • Legacy Issue Number: 3919
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is a conflict between the specification of the OBJECT_NOT_EXIST
    exception and its use in the POA spec. The exception definition says
    that OBJECT_NOT_EXIST means that an object has gone away forever, and
    that clients should tidy up references to it. However, the POA spec
    requires an ORB to raise this exception in cases where the object may
    not have gone away for ever.

    In particular, 11.2.6 (in the 5 May 2.4 Draft) requires an ORB to raise
    OBJECT_NOT_EXIST if request comes in for a child POA that is not active
    and was not activated by the application's POA Activator. While this
    may mean that the object has gone away for ever, it doesn't always
    mean that. For example:

    1) If the server admin has stuffed port number allocations, a server
    may accidentally get requests for POAs that it doesn't know about.

    2) If the server has been incorrectly (re-)built one of its "static"
    child POAs might not be activate.

    3) If the server is buggy and / or its persistent state is flakey,
    it may temporarily fail to dynamically activate a child POA.

    In each case, the problem MAY be one that can be fixed, allowing the
    missing POA to reappear in a few minutes. It is therefore inappropriate
    for the ORB to be telling the client that the Object has gone away for
    ever.

    For what it is worth, I think the ORB should raise another exception,
    say OBJ_ADAPTER, in the default case. It might raise OBJECT_NOT_EXIST
    if it (somehow) tracks the lifecycle of transient and / or persistent
    POAs, or if the application code tells it the POA no longer exists.
    Note: I'm not suggesting that an ORB be required to support such things.

    The other alternative is to change the definition of OBJECT_NOT_EXIST
    to remove the implication that the object has gone away forever and
    the suggestion that clients should throw away references to the object.
    [I think that's wrong though ...]

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4.2
  • Disposition Summary:

    Close no change

  • Updated: Sun, 8 Mar 2015 15:23 GMT

SYNC_WITH_SERVER

  • Key: CORBA25-56
  • Legacy Issue Number: 4317
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 22-6, we say for SYNC_WITH_SERVER:

    For a server using a POA, the reply would be sent after invoking
    any ServantManager, but before delivering the request to the target
    Servant.

    What's the motivation for this? Why wait that long? The ServantManager
    may still fail to return a servant for the request, meaning that
    the ORB might as well acknowledge the request before the ServantManager is
    called without losing anything.

    Also, as specified, the receiving ORB has to first run any adapter
    activators. Again, there doesn't seem any point in waiting this long.
    Why can't the receiving ORB simply acknowledge the request as soon as
    it has read the request header off the wire?

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sun, 8 Mar 2015 15:22 GMT

Changebars missing from POA chapter

  • Legacy Issue Number: 2843
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Many changes between CORBA 2.2 and CORBA 2.3 are not changebarred. Some
    examples from the POA chapter (docs/formal/99-07-15.pdf):

    • Page 11-20: added PortableServer::POAManager::get_state() method.
    • Page 11-28: change in the TRANSIENT lifespan policy"s semantics
      (from "cannot outlive the process" to "cannot outlive the POA instance")
    • Page 11-35: change in PortableServer::POA::set_servant_manager()
      semantics wrt multiple invocations

    I wonder which other tidbits I"ve overlooked so far. Is there a complete
    list of changes (such as a CVS log) anywhere?

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:
  • Updated: Sun, 8 Mar 2015 15:20 GMT

Type code parameter ordering

  • Legacy Issue Number: 1543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    the TypeCode pseudo interface makes no mention about the order of parameters
    for structured types. For example, given the IDL struct

    struct MyStruct

    { char c_mem; string s_mem; }

    ;

    it is legal for member_name(0) to return "s_mem" and member_name(1) to
    return "c_mem" (provided member_type(0) returns a char type code and
    member_type(1) returns a string type code).

    The same comments apply to unions, exceptions, and enums, where the order
    in which members are presented is not necessarily the same order as in the IDL
    definition.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:20 GMT

RMI repository ID references to serial version UID

  • Legacy Issue Number: 4283
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    CORBA formal 00-11-03 10.6.2 states

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    Please comment on the following assertions. The CORBA spec is vague
    here, and it has resulted in incompatible interpretations which must be
    resolved quickly.

    1) The "actual serialization version UID" mentioned is as defined in
    the Java Object Serialization specification.

    http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100

    Based on this Java specification and its note that "If the SUID is not
    declared for a class, the value defaults to the hash for that class":

    2) If a serialVersionUID field is defined in the class with the proper
    modifiers, its value is used as the "actual serialization version UID"
    mentioned in the CORBA spec

    3) If a serialVersionUID field with the proper modifiers is not
    explicitly defined in a class, its value is computed as explained in the
    Java Object Serialization spec, and this computed value is used as the
    "actual serialization version UID" mentioned in the CORBA spec

    4) It is required by the CORBA spec to always include the Java
    serialVersionUID (as computed in assertions 2 and 3 above) in the RMI
    repository ID if the value is different than the OMG hash code (for
    which the algorithm is defined in CORBA formal 00-11-03 10.6.2)

    5) It is not acceptable to leave off the SUID portion of the RMI
    repository ID if the serialVersionUID field is merely absent from the
    Java class

  • Reported: CORBA 2.0 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed, withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Second bit of response_flags

  • Legacy Issue Number: 2968
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The question below was posted to the corba-dev list. I have to admit
    that I don't understand the purpose of the second-least significant bit
    of response_flags either. From the text in the spec, it appears that
    this bit is set if a request expects a response and is not invoked via
    the DII, whereas if a request is oneway or invoked via the DII with
    INV_NO_RESPONSE set, the bit is clear.

  • Reported: CORBA 2.0 — Tue, 2 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue ...clarified

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue: Problem with issue 2801 resolution

  • Legacy Issue Number: 2863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: > > Add the following paragraph to 15.8:
    > >
    > > "To avoid collisions of requestId in fragment messages when
    > > bi-directional GIOP is in use:
    > >
    > > - a request may not be sent by an endpoint if a reply has been
    > > sent by that endpoint without a terminating fragment.
    > >
    > > - a reply may not be sent by an endpoint if a request has been
    > > sent by that endpoint without a terminating fragment."
    > >
    >
    > Why is a plain (non-fragmented) request/reply prohibited here? There has
    > never been and feature interaction between fragmented request/replies and
    > non-fragmented ones, so why have this restriction.

    Jishnu Mukerji wrote:

    > After poking around some it seems to me that the following words address
    > Martin"s concern and hence the issue of inadvertently disallowing something
    > that wasn"t broken in the current resolution of 2801. The additional word
    > "fragmented" in two places is bracekted between "*"s.
    >
    > "To avoid collisions of requestId in fragment messages when
    > bi-directional GIOP is in use:
    >
    > - a fragmented request may not be sent by an endpoint if a
    > fragemented reply has been sent by that endpoint without a terminating
    >fragment.
    >
    > - a fragemented reply may not be sent by an endpoint if a
    > fragmented request has been sent by that endpoint without a terminating
    >fragment."

  • Reported: CORBA 2.0 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, see below

  • Updated: Sat, 7 Mar 2015 04:35 GMT

fragmentation broken with bi-dir giop

  • Legacy Issue Number: 2801
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I wish to raise the following as an urgent issue:

    The way that message fragments are encoded in giop 1.2, in conjunction
    with the giop 1.2 specification for bi-directional use of a connection,
    can lead to situations where the protocol is ambiguous.

    (This is urgent because it is impossible to implement the bi-directional
    part of GIOP 1.2 without it.)

  • Reported: CORBA 2.0 — Tue, 13 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CODESET_INCOMPATIBLE exception

  • Legacy Issue Number: 2620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: if a code set negotiation fails the CORBA 2.3 specfication says that a
    CODESET_INCOMPATIBLE exception is to be raised. There doesn"t seem to be
    any further reference to a CODESET_INCOMPATIBLE exception elsewhere. So
    where is the CODESET_INCOMPATIBLE exception defined? Or should it read
    INV_OBJREF?

  • Reported: CORBA 2.0 — Thu, 22 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

A Messaging related issue in GIOP 1.2

  • Legacy Issue Number: 2077
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Tom and I have discovered a minor outage in GIOP 1.2 relative to the
    Messaging spec. The outage exists if we want to keep the door open for
    publishing Messaging before GIOP is revved again. If we do not fix this
    the publishing of Messaging will have to wait until the next rev of
    GIOP. The outage is the following:

    1) In the Request header the boolean field "response_expected" was
    changed to an octet field "response_flags" in Messaging, with more
    precise definition of the meanings of various flag values.

    2) The Messaging spec defines a IOP::TaggedComponent for including QoS
    policies in an IOR.

    3) The Messaging service defines a ServiceContext for carrying QoS
    policies in GIOP messages that carry ServiceContexts.

  • Reported: CORBA 2.0 — Tue, 13 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Close with No change required

  • Updated: Sat, 7 Mar 2015 04:35 GMT

IIOP 1.2 fragmentation presents an unrecoverable error situation

  • Legacy Issue Number: 1857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IIOP 1.2 fragmentation presents an unrecoverable error situation
    1.2 IIOP attempted to provide fragment interleaving by defining a 1.2
    fragment header containing request id. This does not solve the
    possibility of receiving multiple first fragments over the same
    connection which do not contain request id"s. There is no way to
    associate subsequent fragments with these initial fragments since the
    initial request id is received after the 1.2 Fragment header specified
    request_id.

  • Reported: CORBA 2.0 — Mon, 24 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

New IDL types

  • Legacy Issue Number: 1707
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When the new IDL types were added (fixed, long double, etc), no new
    IIOP or GIOP version was introduced, and no new version of CDR was introduced.
    Instead, the marshaling rules for the new types were simply added to CDR,
    and the type code interface was extended to handle these.

    Unfortunately, this creates some rather serious problems for interoperability.

  • Reported: CORBA 2.0 — Tue, 21 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Narrow Interop

  • Legacy Issue Number: 1669
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Narrowing is used in CORBA to check if an object reference obtained by
    a client is of the desired type, ie. supports a specific IDL interface
    that the client wants to use.

    The client program has static information about the interface it wants
    to use from the IDL specification. However, this is not enough as it
    must also be possible to invoke remote objects that support an IDL
    interface derived from the interface the client knows of.

    There are at least 4 possiblities how the type checking can be resolved
    (+ combinations of them):

    Narrow makes a query to an interface repository.
    (ii) Narrow makes a call to the remote object.
    (iii) The object reference contains enough information, e.g. the whole
    interface type hierarchy that the remote object supports.
    (iv) There is no narrow; the type check is made when a request is
    received by the server-side ORB.

  • Reported: CORBA 2.0 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Contents of MultiComponent component an encapsulation?

  • Legacy Issue Number: 1588
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I can"t find any text in the CORBA 2.2 spec which says explicitly
    whether the "component_data" field of IOP::TaggedComponent is actually
    an encapsulation, or something else.

    Why don"t we define a typedef "Encapsulation" for "sequence<octet>",
    and use it in the IDL for those octet sequences which are really
    encapsulations?

  • Reported: CORBA 2.0 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    :TaggedComponent is actually

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type any marshalling rules force slow implementation

  • Legacy Issue Number: 1581
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: type any marshalling rules force slow implementation

    Proposal: require that type any are marshalled as encapsulations

  • Reported: CORBA 2.0 — Thu, 25 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Marshalling of union type codes

  • Legacy Issue Number: 1544
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 13-14, the spec says for marshaling of type codes:

    "Note that the tuples identifying struct, exception, and enum
    members must be in the order defined in the OMG IDL definition
    text."

    This is right and proper, otherwise I wouldn"t know in what order things are
    encoded or what their ordinal values are. However, the text does not
    mention unions, so the order in which a type code describes the union
    members is left to the implementation.

    Suggestion: Require union members to also appear in the order in which
    they are defined in the IDL.

  • Reported: CORBA 2.0 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode encoding is too long

  • Legacy Issue Number: 1531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Proposal: allow for alternate, compact encoding of typecodes
    It is clear that typecodes are quite long when encoded into CDR and
    transmitted over the wire. This is particularly painful when the CORBA::Any
    type is used in interfaces. Besides, the use of any is becoming increasingly
    important in multiple CORBA specifications, and a global solution to this
    problem should be provided.

    My proposal is to allow for an alternate encoding of typecodes, for those
    specific cases where type identification can be achieved either by other
    application specific mechanisms (for example, Name-Value pairs) or where
    the Repository Id of the type is enough to reconstruct the full typecode
    information locally on the receiving side.

  • Reported: CORBA 2.0 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Type code marshalling

  • Legacy Issue Number: 1525
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If a type code does not have a repository ID

    (e.g. dynamic type ) then the member names for
    structs and unions etc. should be required to be
    sent on the wire for GIOP marsalling of Typecodes.
    This may help the type code comparision issue to be resolved.

  • Reported: CORBA 2.0 — Sun, 14 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

CDR encoding of TypeCodes

  • Key: CORBA21-97
  • Legacy Issue Number: 1292
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

  • Reported: CORBA 2.0 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode indirection issue

  • Key: CORBA21-99
  • Legacy Issue Number: 1503
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have come across the following issue with regard to typecode
    indirections. The specification states:

    the indirection is a numeric octet offset within the scope of some
    "top level" TypeCode and points to the TCKind value for the
    typecode.

    The question arrises then is it legal to point to the (possible)
    padding bytes preceeding the TCKind value or must the numberic value
    indicate the position of the actual TCKind value. If you assume the
    former then having rewound the required number of bytes you would word
    align before interogating the TCKind enum value.

  • Reported: CORBA 2.0 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

No provision for numbering the fragments in fragmented IIOP messages

  • Key: CORBA21-98
  • Legacy Issue Number: 1302
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be no provision for numbering the fragments in fragmented
    IIOP messages. It is apparently assumed that the fragments will always
    be received in the order that they are generated, however in unreliable
    networks, such as mobile networks, this may not be a safe assumption.

  • Reported: CORBA 2.0 — Fri, 1 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Correct CDR encoding of an empty string

  • Key: CORBA21-96
  • Legacy Issue Number: 1138
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the correct encoding for an empty string according to GIOP?

    In section 13.3.2, page 13-11 of CORBA 2.2, the following paragraph
    describes the encoding of strings:

    "A string is encoded as an unsigned long indicating the length of the string
    in octets, followed by the string value in single- or multi-byte form
    represented as a sequence of octets. Both the string length and contents
    include a terminating null."

    This does not clarify what is the correct encoding for empty strings,
    as there are two possibilities:
    a) length=0, no string follows
    b) length=1, "\0" (one-char with the terminating null)

  • Reported: CORBA 2.0 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Typecode equality

  • Key: CORBA21-95
  • Legacy Issue Number: 1136
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I just stumbled on the following paragraph in 13.3.4 describing the CDR
    encoding of TypeCodes:

    "The name parameters in tk_objref, tk_struct, tk_union, tk_enum,
    tk_alias, and tk_except TypeCodes and the member name parameters in
    tk_struct, tk_union, tk_enum and tk_except TypeCodes are not specified
    by (or significant in) GIOP. Agents should not make assumptions about
    type equivalence based on these name values; only the structural
    information (including RepositoryId values, if provided) is significant.
    If provided, the strings should be the simple, unscoped names supplied
    in the OMG IDL definition text. If omitted, they are encoded as empty
    strings."

    This would suggest that the name and member name parts of a typecode
    should never be considered significant when an ORB compares typecodes.

    Of course, this still leaves the issue of what to do about aliases up in
    the air.

  • Reported: CORBA 2.0 — Sun, 29 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:
  • Updated: Sat, 7 Mar 2015 04:35 GMT

Wchar and Char can both be multibyte

  • Key: CORBA21-94
  • Legacy Issue Number: 1111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: With regard to the character encoding issue.

    This is not just a problem with Wchar, and Wstring, it can happen
    with char and string as well. Multibyte encodings are used for
    normal strings in the enhanced IDL as well as for
    Wchars.
    I think the problem is in the definition of char. For interop, the char type could be either:
    1) restricted to a syntactic thing which can only be used with single byte encodings, or
    2) we need to bite the bullet and make the encoding for char a sequence
    of bytes if a multibyte encoding is chosen.

  • Reported: CORBA 2.0 — Wed, 25 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

GIOP Exception formatting description (12.4.2)

  • Key: CORBA21-91
  • Legacy Issue Number: 935
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.1"s GIOP Exception formatting description (12.4.2)
    partitions the space of valid minor codes, with
    20 bits reserved for unique vendor IDs and only 12 bits
    (4096) for possible minor codes for each exception.
    This seems backwards (1 million vendors each with
    only 4 thousand minor codes!) and I would like
    to request a change to (at least) swap these
    numbers with the following textual change:

    The high order 10 bits of minor_code_value contain a 10-bit
    "vendor minor codeset ID" (VMCID); the low order 22 bits
    contain a minor code. A vendor (or group of vendors)
    wishing to define a specific set of system exception
    minor codes should obtain a unique VMCID from the OMG, and
    then define up to (22 bits of) 4194304 minor codes for each
    system exception. Any vendor....

  • Reported: CORBA 2.0 — Mon, 2 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Issue about CDR encoding for wide characters

  • Key: CORBA21-93
  • Legacy Issue Number: 1096
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. When encoding a wchar, always put 4 bytes into the CDR stream,
    > adding any zero pad bytes as necessary to make the value 4 bytes
    > long.
    2. When encoding a wstring, always encode the length as the total
    > number of bytes used by the encoded value, regardless of whether the
    > encoding is byte-oriented or not.

  • Reported: CORBA 2.0 — Tue, 24 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Query about GIOP and IIOP version numbers in 98-01-03

  • Key: CORBA21-92
  • Legacy Issue Number: 960
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve been reading through 98-01-03.pdf (Change pages from Interop 1.2
    RTF), and come across a problem concerning version numbers.

    On page 13-39, the following paragraph has been added:

    "The version number published in the Tag Internet IIOP Profile body
    signals the highest GIOP minor version number that the server supports
    at the time of publication of the IOR"

    As far as I can see, the only version information in the profile body is
    "iiop_version", which has the following note in its description:

    "Note - This value is not equivalent to the GIOP version number
    specified in GIOP message headers. Transport-specific elements of the
    IIOP specification may change independantly from the GIOP specification"

    Which is correct?

  • Reported: CORBA 2.0 — Thu, 5 Feb 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:35 GMT

Section: 7.3.3

  • Key: CCCMP-12
  • Legacy Issue Number: 10983
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The last sentence of the bullet defining the Basic Stream type: "The data is consumed and produced by component implementation logic as octet sequences, unless the basic stream type". The last clause seems misplaced, and should probably be dropped

  • Reported: CCCMP 1.0b1 — Mon, 7 May 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    Resolution: Delete the last clause

  • Updated: Sat, 7 Mar 2015 04:15 GMT

Section: 7.2.10

  • Key: CCCMP-11
  • Legacy Issue Number: 10982
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The following constraints in 7.2.10 are incorrect: [1] A ConstantDef must be defined in a Container [2] A TypedefDef must be defined in a Container [6] An ExceptionDef must be defined in a Container [8] An InterfaceDef must be defined within a ModuleDef [9] A ValueDef must be defined within a ModuleDef Each of these can be defined as "global scope" (as is acknowledged in 7.2.3: "Modules can contain any definition that can appear at global scope (type, constant, exception, and interface definitions)"

  • Reported: CCCMP 1.0b1 — Mon, 7 May 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:15 GMT

Section: 8.1.2, Figure 8.12

  • Key: CCCMP-14
  • Legacy Issue Number: 11010
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    Figure 8.12: A first attribute should have type A::B rather than B with clarification

  • Reported: CCCMP 1.0b1 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    For more clarification the Figure 8.12 should be updated

  • Updated: Sat, 7 Mar 2015 04:15 GMT

Section: 8.1.2

  • Key: CCCMP-13
  • Legacy Issue Number: 11009
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    The replacement text, first bullet: "Array ... multidimensional array dimension (e.g.: “index”=n, m)." is unclear why there are two ways to represent array index. Do all arrays representations have a Tag for index, even if the attribute multiplicity is used in the case of one dimensional array. It should state that the multiplicity for a multi dimension array is the product of all the dimension values (e.g, integer [2][3] has multiplicity 6. Also, it needs to be clarified whether the member attribute is in row major or collumn major order

  • Reported: CCCMP 1.0b1 — Wed, 16 May 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see resolution to issue 10835

  • Updated: Sat, 7 Mar 2015 04:15 GMT

Section: 3 Normative References

  • Key: CCCMP-10
  • Legacy Issue Number: 10981
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    The list of Normative References contains the CORBA Component Model Specification, Version 4.0 twice, but does not have a normative reference to the CORBA specification

  • Reported: CCCMP 1.0b1 — Mon, 7 May 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:15 GMT

More clarification text about order of CORBAStruct members is needed

  • Key: CCCMP-9
  • Legacy Issue Number: 10838
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    More clarification text about order of CORBAStruct members is needed

  • Reported: CCCMP 1.0b1 — Wed, 21 Mar 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see resolution to issue 10836

  • Updated: Sat, 7 Mar 2015 04:14 GMT

clarification about relationships of specifications needed

  • Key: CCCMP-8
  • Legacy Issue Number: 10837
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    Initiated by Frank Pilhofer (Mercury Computer Systems: At the moment there are two OMG specification documents: the UML Profile for CORBA (formal/02-04-01) and the UML Profile for CORBA Component Model (formal/05-07-06). More clarification is needed about relationships between mentioned above two specs and this current final adopted spec. What are the differences between all profiles and migration rules from one to another?

  • Reported: CCCMP 1.0b1 — Wed, 21 Mar 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:14 GMT

Section: 8.1.2 p. 40

  • Key: CCCMP-7
  • Legacy Issue Number: 10836
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    Initiated by Tom Rutt (Fujitsu) "According to the metamodel for UML (uml super fig 7-12 and 7-13) the OwnedAttribute association end of class and data type is ordered, and includes both "attributes" and "association ends". So from UML point of view the Struct mapping is ok in the current spec. (However some tools have trouble ordering across attributes and association ends). The FTF may decide to not use the association version of containment for Struct members which are themselves complex types

  • Reported: CCCMP 1.0b1 — Wed, 21 Mar 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 04:14 GMT

Section: 8.1.2 p. 44

  • Key: CCCMP-6
  • Legacy Issue Number: 10835
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    Initiated from Tom Rutt (Fujitsu): "Something similar to Sequences could be done for array mappings as well."

  • Reported: CCCMP 1.0b1 — Wed, 21 Mar 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:14 GMT

Section: 8.1.2

  • Key: CCCMP-5
  • Legacy Issue Number: 10834
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Julia Reznik)
  • Summary:

    Initiated from Tom Rutt (Fujitsu: "The sequence mapping needs either fixing or clarification. I am still concerned about the complexity and yet incompleteness of the profile mapping for CORBA sequences and arrays. Suggestion: AnonymousSequence types are named by concatenation containing type "::" "m"<n> , where n is the member number of the anonymous sequence in containing type, e. g bar::m2 for second member of Struct bar (P. 31, Figure 8.15). Also I suggest to represent the sequence element values as a multivalued attribute with lower bound 0 and upper bound = sequence size or "*". This seems to work and is much easier to understand. Also, it requires NO NEW TAGGED VALUES for Sequencies."

  • Reported: CCCMP 1.0b1 — Wed, 21 Mar 2007 04:00 GMT
  • Disposition: Resolved — CCCMP 1.0
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 04:14 GMT

Section: 1.2.7.10

  • Legacy Issue Number: 8806
  • Status: closed  
  • Source: cpan ( Francois Perrad)
  • Summary:

    The section "ValueType" needs to describe inheritance. The order between member (not inherited, inherited, indirectly inherited) must be defined. // IDL valuetype sampleY : sampleX

    { public char c; }

    ; // XSD <xsd:complexType name="sampleY"> <xsd:sequence> <xsd:element name="a" maxOccurs="1" minOccurs="1" type="xsd:short"/> <xsd:element name="b" maxOccurs="1" minOccurs="1" type="xsd:int"/> <xsd:element name="c" maxOccurs="1" minOccurs="1" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="optional"/> </xsd:complexType>

  • Reported: C2WSDL 1.1 — Tue, 24 May 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    Agree to add description of value type inheritance

  • Updated: Sat, 7 Mar 2015 04:12 GMT

xsd:url type not defined in schema

  • Legacy Issue Number: 8807
  • Status: closed  
  • Source: AIP Safe ( Jan Vomlel)
  • Summary:

    I have some notes and questions to CORBA IDL to WSDL mapping. 1. corba.wsdl contains xsd:url type. But this type is not defined in schema. There is only xsd:anyURI. I think corba.wsdl is not valid wsdl!!! 2. TypeCode is mapped to url to wsdl document and type name. Why TypeCode is not mapped to QName? 3. Any is mapped to CORBA:TypeCode and xsd:any. I think better is mapping to xsd:any. Type is defined by xsi:type attribute in soap message. 4. Object reference is mapped to sequence of url. But this urls are urls to CORBA interfaces. It is not usefull for me. I neednot return corba reference (it is irrelevant for soap client), I need to return address of webservice or whole EndpointReference from ws-addresing, which transform soap messages to calls on this CORBA::reference. 5. Contact information for this specification mars@omg.org is not valid.

  • Reported: C2WSDL 1.1 — Tue, 24 May 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    close without change

  • Updated: Sat, 7 Mar 2015 04:11 GMT

CORBA to WSDL/SOAP: example for attributes mapping

  • Legacy Issue Number: 6996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 1.2.8.2
    In the example for attributes mapping.
    The get accessor maps to an operation with only an output message. It seems like a notification operation according to WSDL specification. But the semantics of attribute accessors should be request-response .So a get accessor should be mapped to a couple of messages.
    Proposed solution :
    Define the incoming message as a message without any parameter as the following:
    <message name="MyAttrs._get_strAttr" />
    <message name="MyAttrs._get_strAttrResponse" >
    <part name="_return" type="xsd:string"/>
    </message>
    ¡­
    <portType name="MyAttrs" >
    <operation name="_get_strAttr" >
    <output message="tns:MyAttrs._get_strAttrResponse"/>
    <fault message=¡±tns:CORBA.SystemException¡±/>
    </operation>

  • Reported: C2WSDL 1.0 — Thu, 19 Feb 2004 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.1
  • Disposition Summary:

    Accept proposal from source

  • Updated: Sat, 7 Mar 2015 03:58 GMT

'CORBA to WSDL/SOAP: example for operation mapping

  • Legacy Issue Number: 6995
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 1.2.8.2
    Also, in the example for operation mapping.
    <portType name="SomeInterface" >
    <operation name="bar" >
    <input message="tns:SomeInterface.bar"/>
    <output message="tns:SomeInterface.barResponse"/>
    <fault message=¡±tns:CORBA.SystemException¡±/>
    </operation>
    </portType>
    Here defines the fault message, yet its type is not CORBA.SystemExceptionMessage defined ahead, but CORBA.SystemException, which is defined as a complextype.
    Proposed solution: Maybe the following is right:
    <fault message=¡±tns:CORBA.SystemExceptionMessage¡±/>

  • Reported: C2WSDL 1.0 — Thu, 19 Feb 2004 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.1
  • Disposition Summary:

    Accept proposal from source

  • Updated: Sat, 7 Mar 2015 03:58 GMT

'CORBA to WSDL/SOAP Section 1.2.8.2

  • Legacy Issue Number: 6994
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 1.2.8.2
    In the example:
    <message name="CORBA.SystemExceptionMessage" >
    <part name="_return" type="CORBA.SystemException"/>
    </message>
    CORBA Specification says that CORBA Exception cannot be passed as paramters or return value. But the example seems to ¡°return¡± a SystemException.
    Proposed solution: Maybe the example should be defined as the following according to the exception mapping rules:
    <message name="CORBA.SystemExceptionMessage" >
    <part name="exception" type="CORBA.SystemException"/>
    </message>

  • Reported: C2WSDL 1.0 — Thu, 19 Feb 2004 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.1
  • Disposition Summary:

    Close with no change. While confusing, the use of "_return" for the name is not invalid

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA fixed types

  • Legacy Issue Number: 6613
  • Status: closed  
  • Source: cpan ( Francois Perrad)
  • Summary:

    CORBA fixed types are mapped to the XML Schema "decimal" type (not "integer")

    And the element "restriction" of the map becomes : <xsd:restriction base="xsd:decimal">

    The xsd:integer type have a facet fractionDigits fixed to 0.

  • Reported: C2WSDL 1.0 — Thu, 13 Nov 2003 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.1
  • Disposition Summary:

    : Accept solution proposed by source

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: Section 1.2.7.4

  • Legacy Issue Number: 5793
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The mapping does not state what value should be used for the default
    case.

    Proposed Resolution:
    Add text stating that any valid value for the discriminant, other than
    those used
    in the union definition, can be inserted for the default case.

  • Reported: C2WSDL 1.0b1 — Wed, 18 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    Accept proposal from source

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: Section 1.2.7.10

  • Legacy Issue Number: 5790
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 1.2.7.10 ­
    Only public state members are mapped. Since use of the Dynamic Any api
    allows access to both the private
    and public members, this restriction was challenged by the AB reviewer
    as unwarranted.
    Also the sentence "For example, DII/DSI bridges will be unable to
    process value types." is not justified.

    The dynamic ANY api can be used to access value type state members in a
    DII/DSI based gateway.
    If private state cannot be represented, an input value type parameter
    which has private state will not be mapped to the IDL server.

    Proposed Solution:
    Delete offending sentence about dynamic gateways.
    Unless the private member restriction can be justified, change the spec
    to map both private and public value type state members.

  • Reported: C2WSDL 1.0b1 — Wed, 18 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    Remove the restriction of not mapping Private state members

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: section 1.2.8.2 , 1.2.8.4 and 1.2.8.5

  • Legacy Issue Number: 5792
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    section 1.2.8.2 , 1.2.8.4 and 1.2.8.5 - In all the Example WSDL, the
    target namespace in definitions and the namespace in import using URL
    "http://tempuri.org/anExample/.." do not seem correct.

    Proposed Resolution: fix the example after resolving the Type prefix FTF

    issue on namespace and module name uniqueness.

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    Fix the examples to use the correct target namespace url

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: Section 1.2.7.10.3

  • Legacy Issue Number: 5791
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 1.2.7.10.3 - need to represent value type in IDL sequence as an
    IdRef/value choice.

    Proposed Resolution:
    fix spec to use the idRef/Value choice for sequence<valueType>.

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: section 1.2.4

  • Legacy Issue Number: 5788
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    section 1.2.4 - The sentence "The most significatn is that XML flattens
    the constructed namespace to a single targeted namespace when an XML
    schema is imported." does not seem quite correct. Avoiding a large
    number of files for the wsdl processor to deal with is a major reason
    cited by the submitters.

    Proposed Solution: Replace the offending sentence, with: "Having a
    separate namespace for each imported module results in a large number of

    files for the WSDL processor to deal with when constructing a gateway."

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    Agree to editorial fix

  • Updated: Sat, 7 Mar 2015 03:58 GMT

Section 1.2.3 repository id inconsistency

  • Legacy Issue Number: 5787
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 1.2.3 - there is an inconsistency, in that the documentation
    schema for the repository ID dos not include the version of the mapping,

    as included in the URL source documentation schema.
    Knowing what version of the IDL to WSDL mapping produced the WSDL is
    important for gateway design.

    Proposed Resolution: add mapping version to the respositoryID
    documentation schema.

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    Add mapping version to the repositoryID documentation schema

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: Section 1.2.3

  • Legacy Issue Number: 5786
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 1.2.3 - need to have appropriate text to describe the nature of
    the source "hint". Examples might be included, using filenames.

    Proposed Resolution: FTF should determine appropriate text.

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    The nature of the hint can remain an implementation specific matter

  • Updated: Sat, 7 Mar 2015 03:58 GMT

CORBA-WSDL/SOAP: Section 1.2.2.1

  • Legacy Issue Number: 5785
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Section 1.2.2.1 -
    tns is a single namespace for all mapped IDL from the entire corba
    world.
    The module names for IDL across this vast namespace, need to be
    sufficiently qualified with pre-fixes (such as Type ID, or Pragma
    Prefix) to avoid module name collisions.

    Proposed Resolution: FTF needs to determine appropriate prefixes or
    namespaces to assure module name uniqueness in the generated WSDL

  • Reported: C2WSDL 1.0b1 — Tue, 17 Dec 2002 05:00 GMT
  • Disposition: Resolved — C2WSDL 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 03:58 GMT

Section: 1.2.x (CorbaToWsdl)

  • Legacy Issue Number: 9603
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Duplicate or Merged — C2WSDL 1.2
  • Disposition Summary:

    duplicate of issue # 9602

  • Updated: Sat, 7 Mar 2015 03:58 GMT

Sections 8.1.1, 8.2.1:

  • Legacy Issue Number: 7920
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1, 8.2.1: the description of the metamodel is very skimpy: for
    example there is no description anywhere about what FinderDef is. There
    should be a separate section for each class with a description of each
    attribute/reference. Conversely the text also talks about 'component
    types' which have 'attributes' (and ports) - this has no obvious
    correspondence with the metamodel (are the attributes in the BaseIDL
    package?). Likewise the text refers to a component being able to inherit
    from one other interface - this is not depicted.

    • most of the OCL constraints make use of 'isStereotyped()' which is
      not OCL, UML nor defined in this specification.
    • Table 10: most of the Tags seem to have no correspondence in the
      metamodel e.g. containerType.
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.1, line1:

  • Legacy Issue Number: 7916
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.1, line1: It's not strictly true to say that the CCM Profile
    'specializes' the UML Core package: the latter is the reference
    metamodel for the former.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Figure 1

  • Legacy Issue Number: 7915
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 1 - the import dependencies should be shown with an 'import'
    stereotype

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 8.1.1

  • Legacy Issue Number: 7919
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    8.1.1 the heading is 'IDL metamodel' but the caption is 'IDL3
    Metamodel', and in 7.2 it is 'ComponentIDL'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

7.2, sentence 3

  • Legacy Issue Number: 7918
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    7.2, sentence 3: it is confusing to refer to BaseIDL as the
    'reference metamodel' since that terminology has a specific meaning for
    Profiles which does not apply here.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

- Figure 2

  • Legacy Issue Number: 7917
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:
    • Figure 2: the arrows are not correct: they should represent a valid
      MOF 1.4 Package relationship (one of clustering, generalization,
      nesting, import). More seriously, since ComponentIDL is nested within
      metamodel CCM it is not allowed to have an import/cluster relationship
      with an external metamodel (BaseIDL in this case): MOF constraint [C49]
      states that "Nested Packages cannot import or cluster other Packages or
      Classes.".
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

use the proper notation for expressing Profiles

  • Legacy Issue Number: 7914
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Should use the proper notation for expressing Profiles. The
    presentation of the Profile (e.g. in Table 1) is confusing in mixing
    references to the equivalent metamodel with references to the reference
    metamodel (UML) being extended by the Profile. Though the diagrams in
    the separate section 8.1.3 make things a lot clearer.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Minor comments re Components FTF

  • Legacy Issue Number: 7913
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Report should reference the document number of the Final Adopted
    Spec as the base document.

    • Issue 7628: the final line of the resolution is too vague "add the
      package...and update relations"
    • There should be accompanying MOF XMI (for the metamodel) and UML XMI
      (for the profile).
  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7.2

  • Legacy Issue Number: 7912
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7.2 states says that "BaseIDL that is a MOF-compliant
    description of the pre-existing CORBA Interface Repository that is
    already specified in the UML Profile for CORBA" - however in the
    document referred to for the latter (ptc/00-10-01) there is no mention
    of BaseIDL - in fact there is no metamodel only a pure profile. BTW a
    more up-to-date reference would be formal/02-04-01. This spec is clearly
    dependent on BaseIDL and so it's important to have a proper reference
    (and this should be in Section 3). In fact the appropriate reference for
    BaseIDL seems to be the CORBA components spec.

    The front page of convenience document, and document footer, still refer
    to it as a (Final) Adopted Specification

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

On Page 18 - Figure 11 Home mapping

  • Legacy Issue Number: 7911
  • Status: closed  
  • Source: Technical University Berlin ( Christian Hein)
  • Summary:

    On Page 18 - Figure 11 Home mapping. To me, it doesn't seems properly that CORBAValue inherits from AssociationClass. Perhaps it make sense that the HomeDef gets an attribute with name 'primary key'.

  • Reported: CORBA 3.0.3 — Tue, 16 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Section 7, Overview

  • Legacy Issue Number: 7903
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7, Overview consists only of 3 bullets that are instructions to an author rather than an overview e.g. "Explain relations to BaseIDL package"

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

sections 1, 3, 4, 5 essentially empty

  • Legacy Issue Number: 7902
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Convenience Document has sections 1, 3, 4, 5 essentially empty except for 'Editorial Comment: Needs to be completed'. They do need to be completed!
    Even worse, section 2, Conformance, also has a similar 'needs to be completed': though it does contain some text it is nothing like a conformance statement.
    I found it unclear whether the spec was providing a normative metamodel or just a normative profile: the text to be added to Section 1 (Scope) and Section 2 (Conformance) should clarify.

  • Reported: CORBA 3.0.3 — Thu, 4 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    see below

  • Updated: Sat, 7 Mar 2015 03:37 GMT

insufficient examples of component attributes

  • Key: CORBA3-133
  • Legacy Issue Number: 5906
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — CORBA 3.0.3
  • Disposition Summary:

    duplicate of issue 5898

  • Updated: Sat, 7 Mar 2015 03:37 GMT

Derived component supported interface restriction

  • Key: CORBA3-132
  • Legacy Issue Number: 5683
  • Status: closed  
  • Source: Anonymous
  • 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
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 03:37 GMT

OMG Architecture Board review issues, Nov 2013

  • Key: CTS212-26
  • Legacy Issue Number: 19308
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    This is my OMG Architecture Board review of:

    CTS2 XML to JSON Transformation Rules RFC (2nd Rdg) ad/13-09-04
    Inventory ad/13-09-05

    Here are the comments I did have - mostly minor, and all addressable during finalisation:

    1. PDF page 7. For reference, OMG's office has moved: http://www.omg.org/contact.htm

    2. Section 1 (Scope), PDF page 8. It would be useful to have definitive references to Badgerfish & Parker, the XML to JSON transformation conventions mentioned. It would also be useful to include one or two sentences explaining why they aren't thought suitable for CTS2 XML.

    3. Section 3 (Normative references), PDF page 8. We definitely need a normative reference for JSON. One possibility is IETF RFC 4627 (July 2006):

    http://www.ietf.org/rfc/rfc4627.txt

    However, it looks as though ECMA has just published a JSON specification as ECMA 404 (an amusing coincidence, no doubt):

    http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

    Is either of these an appropriate reference?

    4. Section 6.2 (Specification adoption plan), PDF page 9.

    The FTF process is designed to accommodate a specification adopted with the intention of merging it into an existing specification, as here. We simply charter an FTF that takes as input both the newly-adopted specification (in this case, the XML to JSON mapping RFC) and the already-adopted specification with which it is being merged (the CTS2 specification), and delivers as its result the merged specification (along with a finalisation report).

    In this case, we should simply dissolve the CTS2 1.2 RTF, and charter an FTF that takes the XML/JSON RFC and CTS 1.1 as inputs, and delivers CTS 1.2 (including the JSON mapping) as its result (along with a finalisation report that tracks all the changes made to CTS 1.1 and to the RFC).

    This is basically what you have proposed with the "common convenience document", but without the complication of having a separate RTF and FTF.

    5. Section 6.4 (Patents containing essential claims). Unfortunately, we can't say that there are definitely none. The best we can say is that there are "none known to the authors". (But that's still useful to know).

    6. Section B2 (Transformation patterns and Rules). I'm not an expert, but this all looks reasonable to me. However, "shall" should be used to express the rules instead of "will". For example "Repeating XML attribute values shall be treated as a single JSONValue.", "XML comments and processing instructions shall be ignored.", "The following JSONStringCharacters shall be escaped:" It's just a style issue - the meaning is already clear, and not affected by the change.

  • Reported: CTS2 1.1 — Mon, 31 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    1. Address of the OMG office changed in RFC
    Delete: Section B4, which referenced the emacs document was deleted and the following normative reference:
    The JSON Data Interchange Format 1st Edition / October 2013. http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
    Was added to section 3

  • Updated: Sat, 7 Mar 2015 03:03 GMT

The reference in B4 should instead be added to section 3 (assuming it is normative)

  • Key: CTS212-25
  • Legacy Issue Number: 19307
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The reference in B4 should instead be added to section 3 (assuming it is normative)

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    The reference in B4 was deleted and a subsequent, normative reference was added to section 3:

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L)

  • Key: CTS212-24
  • Legacy Issue Number: 19306
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Rule 10 example uses xsi2:nill – I think this should be xsi2:nil (only one L)

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Change "xsi:nill" to "xsi:nil" in 4 places on Rule 10

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable

  • Key: CTS212-22
  • Legacy Issue Number: 19304
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Rule 10 does not cover the case where the removal of namespaces causes names to be indistinguishable (that’s the point of namespaces after all). Do such now-identical names then get treated as “arrays” per Rule 7. Or is this disallowed (similar to B3 rule 2)? This needs clarifying

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Rule 10 included the statement “This rule is specific to the CTS2 specification. Other OMG specifications may choose the option to keep the namespace.” As, for the time being, this is a CTS2 only specification, the statement above was removed and, instead, a third B3 rule was added

  • Updated: Sat, 7 Mar 2015 03:03 GMT

The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data”

  • Key: CTS212-21
  • Legacy Issue Number: 19303
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The following in rule 10 is very unclear “In certain situations, this may cause issues for opaque data”

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Remove the sentence as it is already addressed in the _CDATA section

  • Updated: Sat, 7 Mar 2015 03:03 GMT

issue with rule 10

  • Key: CTS212-20
  • Legacy Issue Number: 19302
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Rule 10: it says to remove the “namespace prefixes” but the examples show removal of complete namespace declarations not just the prefix

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    The previous sentence states “XML namespaces are removed in the JSON.” We have already added the caveat involving _CDATA (issue 19305), but do need to add one additional exception for the root namespace

  • Updated: Sat, 7 Mar 2015 03:03 GMT

conflict between rules 10 and 13

  • Key: CTS212-23
  • Legacy Issue Number: 19305
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    There seems to be a conflict between rule 10 which seems to state to strip all XML namespaces, and rule 13 which says to retain them if they are in _CDATA

  • Updated: Sat, 7 Mar 2015 03:03 GMT

The documents referenced in Rule 12 should appear in the normative references section

  • Key: CTS212-19
  • Legacy Issue Number: 19301
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The documents referenced in Rule 12 should appear in the normative references section

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    References added (the first one was already added from Issue 19306)

  • Updated: Sat, 7 Mar 2015 03:03 GMT

B2 rule 7: I’m not aware of such a thing as an “XML array”

  • Key: CTS212-18
  • Legacy Issue Number: 19300
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    B2 rule 7: I’m not aware of such a thing as an “XML array”

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Reworded to clarify the intent

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01

  • Key: CTS212-17
  • Legacy Issue Number: 19299
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 7 has the wrong document number for CTS2 – it should be formal/13-12-01

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Fix document number

  • Updated: Sat, 7 Mar 2015 03:03 GMT

The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec

  • Key: CTS212-16
  • Legacy Issue Number: 19298
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Normative References in section 3 must be added to the Normative References section in the main CTS2 spec. However section 7 does not describe such a change

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Add a section to the revision document saying to add a section to the CTS2 document that contains the normative references in the annex.

  • Updated: Sat, 7 Mar 2015 03:03 GMT

the “Plan” in 6.2 with the RTF working in parallel is not being followed at all

  • Key: CTS212-15
  • Legacy Issue Number: 19297
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    And in fact the “Plan” in 6.2 with the RTF working in parallel is not being followed at all. The whole section is at variance with reality and people reading this document coming out of the FTF could get very confused as to what is happening.

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    This had been corrected as an earlier issue reported by Andrew Watson

  • Updated: Sat, 7 Mar 2015 03:03 GMT

No Beta document

  • Key: CTS212-14
  • Legacy Issue Number: 19296
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    6.2 references “The FTF beta document” but this is not referenced by document number – nor does it seem to exist as per comments above

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    Change to “this submission"

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Section 1: should rephrase “this submission” – it’s now a specification

  • Key: CTS212-13
  • Legacy Issue Number: 19295
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 1: should rephrase “this submission” – it’s now a specification

  • Reported: CTS2 1.1 — Mon, 24 Mar 2014 04:00 GMT
  • Disposition: Resolved — CTS2 1.2
  • Disposition Summary:

    revised

  • Updated: Sat, 7 Mar 2015 03:03 GMT

Typo: "Wrongpolicy"

  • Legacy Issue Number: 3635
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
    "WrongPolicy".

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate of 3634.

  • Updated: Sat, 7 Mar 2015 02:37 GMT

destroy on POA

  • Legacy Issue Number: 3402
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    ection 11.3.8.4 of the 2.3 spec states: "After all descendant POAs have
    been destroyed and their servants etherealized, the POA continues to
    process requests until there are no requests executing in the POA."

    does that mean new requests are rejected or that new requests for that
    POA are processed?

    also, if a parent POA is being destroyed, once a descendant has been
    destroyed, can an adapter activator be called for the descendant during
    this period? in the same paragraph, the spec says "After destruction has
    become apparent, the POA may be recreated .. via an Adapter Activator".
    should the request block, or can it be rejected?

  • Reported: CORBA 2.3.1 — Mon, 6 Mar 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    closed no change

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Valuetype "copying" semantics underspecified?

  • Legacy Issue Number: 3330
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Core issue #1: The Core should explicitly state that valuetype
    parameters are copied for collocated interface invocations.

  • Reported: CORBA 2.3.1 — Fri, 18 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with issue 3364 and close this issue

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Scope of inherited valuetype initializers

  • Legacy Issue Number: 3329
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    Are the names of valuetype initializers introduced into the
    scope of a derived valuetype? I'm proposing that they are
    not introduced. The implication is that derived valuetypes
    are free to reuse the names of base type initializers.

    Proposed resolution:

    Change the last sentence of the first paragraph in 3.8.1.5:

    "The names of the initializers are part of the name scope of
    the value type, but are not part of the name scope of derived
    valuetypes."

  • Reported: CORBA 2.3.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3305, Therefore same resolution as 3305

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Null valuetypes not supported by DynValue

  • Legacy Issue Number: 3250
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    DynValue is missing support for null valuetypes. There is no
    way to determine whether a DynValue represents a null valuetype,
    nor is there any way to dynamically construct an Any containing
    a null valuetype.

    Proposed resolution:

    Add the following operations to the DynValue interface:

    boolean is_null();
    void set_to_null();
    void set_to_value();

    And replace the description of the interface with the following text:

    The DynValue interface can represent both null and non-null
    valuetypes. For a DynValue representing a non-null valuetype, the
    DynValue's components comprise the public and private members of
    the valuetype, including those inherited from concrete base valuetypes,
    in the order of definition. A DynValue representing a null valuetype
    has no components and a current position of -1.

    boolean is_null();

    The is_null operation returns TRUE if the DynValue represents
    a null valuetype.

    void set_to_null();

    The set_to_null operation changes the representation of a DynValue
    to a null valuetype. Specifically, the current components of the DynValue
    are destroyed, component_count returns zero and the current position is
    set to -1.

    void set_to_value();

    The set_to_value operation changes the representation of a DynValue
    to a non-null valuetype. The state of the DynValue is initialized
    exactly as if create_dyn_any_from_type_code had been invoked.
    The set_to_value operation has no effect when invoked on a DynValue
    representing a non-null valuetype.

    The remaining operations of the DynValue interface have equivalent
    semantics to DynStruct. When invoked on a DynValue representing a
    null valuetype, get_members and get_members_as_dyn_any return an empty
    sequence.

  • Reported: CORBA 2.3.1 — Tue, 25 Jan 2000 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.4
  • Disposition Summary:

    Merge with 3135 and provide resolution as part of 3135

  • Updated: Sat, 7 Mar 2015 02:37 GMT

International Strings in Encapsulations

  • Key: CORBA25-55
  • Legacy Issue Number: 3221
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    It seems that the only time an international string will ever appear in an
    encapsulation
    would be a private IOR component.

    If we can keep the issue down to International strings in encapsulations
    this will
    simplify the solution.

    If anyone has an example of how any other GIOP header string could carry an
    international
    string please come forth with it quickly.

    The use of international strings in GIOP 1.1 and 1.2 is dependant on the
    asserted use
    of service context code set negotiation. In particular:
    1) if the negotiatiation is not initiated, then strings are passed
    as latin-1 only and wstrings are not allowed to be passed as parameters.
    2) If the negotiation is initated and successfully completed, the
    agreed codesets are used
    respectively for string and wstring
    3) If negotiation is initated by no comon codeset is agreed, then
    UTF-8 is the default for
    string and UTF-16 is the default for Wstring (note: the current codeset
    negotiation does not
    discuss the big endian or litte endian aspects of UTF-16).

    There is also text somewhere in GIOP stating that Encapsulations in IORs
    should be
    encoded in giop 1.0 for maximum interoperability.

    It just occured to me that disallowing international strings in IOR
    encapsulations (i.e., private
    IOR components) is equivalent to assuming that negotiation is not initiated
    for encapsulations.
    This seems to be a consistent set of semantics.

    The only problem with this interpretation, is that it does not allow
    international strings
    in IOR encapsulations.

  • Reported: CORBA 2.3.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    closed in interop/2000-05-01

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Expected behavior of POA configured with ServantLocator receiving LocateRe

  • Legacy Issue Number: 2791
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is an issue with the Portable Object Adapter:

    If a POA configured with a ServantLocator receives a LocateRequest, what
    is the expected behavior? A ServantLocator expects to receive an operation
    name as a parameter to preinvoke() and postinvoke(), but there is no
    operation name in a LocateRequest.

    We could just return a true response to the LocateRequest and not involve
    the ServantLocator. That might mislead the sender though. If the sender
    received a true response and then sent a message they might get an
    OBJECT_NOT_EXIST exception back.

    We could pass an operation name like "_locate" to the manager. That would
    let the manager know that a location request was being processed, and the
    underscore would signify that it is an internal message since it"s not a
    _get or _set.

  • Reported: CORBA 2.3 — Thu, 8 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add a subsection to section 11.3.6 specifying "_locate" and its usage.

  • Updated: Sat, 7 Mar 2015 02:37 GMT

The insert_dyn_any and get_dyn_any operations are barely documented

  • Legacy Issue Number: 2615
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The insert_dyn_any and get_dyn_any operations are barely documented. It
    seems the only explanation is given on 9-15: "The get_dyn_any and
    insert_dyn_any operations are provided to deal with any values that contain
    another any." The insert_dyn_any function should be specified as behaving
    identically to insert_any, except that it allows an any in the form of a
    DynAny to be inserted. The get_dyn_any should be specified as behaving
    identically to get_any, except that it returns its result in the form of a
    DynAny rather than an any.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    "The get_dyn_any and

  • Updated: Sat, 7 Mar 2015 02:37 GMT

OBV, value-reference substitution, Multiple Inheritance

  • Legacy Issue Number: 2258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Hi, is it possible to pass a supporting value type by value when used as
    a interface? It looks like this is droped from the OBV spec
    (ptc/98-10-06.pdf says when a supporting value type is used as a
    interface then an object reference will be used).

  • Reported: CORBA 2.2 — Tue, 15 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

WRONG_TRANSACTION

  • Legacy Issue Number: 2218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: WRONG_TRANSACTION Exception

    The CosTransactions module adds the WRONG_TRANSACTION exception
    that can be raised by the ORB when returning the response to a
    deferred synchronous request. This exception is defined in Chapter 4
    of the Common Object Request Broker: Architecture and Specification.
    This para doesn"t state what module is to be used for
    WRONG_TRANSACTION. I assume what is meant is that it should be
    a system exception?

    • I can"t find this exception in either chapter 4 or chapter 3
      of the 2.3 spec. Looks like it needs to be added. I don"t know
      why the above para refers to chapter 4 though – it seems that
      this exception should be added to the list of system exceptions
      in chapter 3?
  • Reported: CORBA 2.2 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    issue merged with issue1963

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Proposal on floating point fixes

  • Legacy Issue Number: 1667
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m preparing a proposal to "fix" fixed point types, but I"d like to
    outline what I am thinking before I have it completed, in order to give
    people a chance to comment.
    Michi has pointed out a few issues with the fixed point constant
    grammar, but I think I can resolve those pretty easily by making changes
    so that fixed point constants are only allowed to be defined using the
    syntax:

    const fixed FOO = 1.2D;

    Some people have expressed the idea that the fixed point type
    specification is lacking sufficient semantic content, and they are
    afraid that since different languages or even implementations of
    languages might do the math differently that portability or
    interoperability is affected. Frankly, I don"t see the problem as
    serious for the CORE RTF. In most cases, the fixed point type is mapped
    to the native fixed point facility of the language. If that isn"t
    sufficiently robust to support stuff like banking applications, the CORE
    RTF can"t do much to fix it anyway.

    For the C++ RTF:

    For the C++ binding, of course, things are broken. However, I think I
    may have a solution to the problem:

    First, define a new class CORBA::FixedValue which is used as the results
    of all of the Fixed arithmetic operations, as well as for the type for
    fixed point constants. FixedValue would store the digits and scale
    information dynamically. All of the defined fixed point types would be
    convertable from/to the FixedValue type, with the DATA_CONVERSION
    exception available to signal overflow.

    Second, get rid of the explicit reference to a template type. Since the
    grammar will be changed to no longer allow anonymous fixed point
    declarations (as parameter types), there is no longer a specific need to
    define the exact type name for the Fixed types, and in fact,
    implementations no longer must implement fixed as a template type.

  • Reported: CORBA 2.2 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Section 3.3.8.16:deactivate_object() operation

  • Legacy Issue Number: 675
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section states that the deactivate_object() operation doesn"t wait for etherialize operation to complete before it returns. This is impossible to implement in single-threaded ORB

  • Reported: CORBA 2.1 — Wed, 13 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:37 GMT

Object::is_a

  • Legacy Issue Number: 551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Some ORBs are sloppy about existence. One ORB used raises INV_OBJREV whenever object doesn"t exist, even when server can be reached. Behavior is compliant..tighten spec here.

  • Reported: CORBA 2.0 — Tue, 22 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change in 2.4

  • Updated: Sat, 7 Mar 2015 02:37 GMT

DII operations "get_response and get_next_response

  • Legacy Issue Number: 464
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception.

  • Reported: CORBA 1.2 — Wed, 18 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved, closed issue

  • Updated: Sat, 7 Mar 2015 02:37 GMT

6.5.6. Repository Paragraph 2 - objection

  • Legacy Issue Number: 434
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that there may be more than 1 interface Repository in any given environment. How can portable application determine this, and how can it determine what the requirements are?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    the application should use either the naming or trading service to determine which IR to use.

  • Updated: Sat, 7 Mar 2015 02:37 GMT

mapping IDL Unicode escapes to C++

  • Key: CPP11-260
  • Legacy Issue Number: 2035
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The question has arisen how the new Unicode escapes that were
    introduced in the Java to IDL mapping should be mapped to C++.
    There"s nothing about this in the C++ mapping chapter.

  • Reported: CPP 1.0b2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 02:11 GMT

Mappings for hash, is_equivalent, _is_a and _non_existent

  • Key: CPP11-259
  • Legacy Issue Number: 914
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for CORBA::Object does not specify the mappings for
    hash, is_equivalent, is_a and non_existent methods. I am assuming
    these map to _hash, _is_equivalent, _is_a and _non_existent. Is this
    correct ?

  • Reported: CPP 1.0b1 — Mon, 19 Jan 1998 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.0b2
  • Disposition Summary:

    duplicate of issue # 800, closed

  • Updated: Sat, 7 Mar 2015 02:09 GMT

freebuf and destruction of elements

  • Key: CPP11-258
  • Legacy Issue Number: 242
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.2 para 25 describes freebuf. It doesn"t specify if storage associated with each element is released, i.e deep-free. Sun prefers that freebuf deep-free...

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Closed; No Change — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Sat, 7 Mar 2015 02:09 GMT

Re-opening modules

  • Key: CPP11-257
  • Legacy Issue Number: 95
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it legal to split IDL module declarations and to re-open a module similarly to what is done with C++ namespaces?

  • Reported: CPP 1.0b1 — Fri, 30 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0b2
  • Disposition Summary:

    obsolete, cloe issue

  • Updated: Sat, 7 Mar 2015 02:09 GMT

exception NoServant();

  • Key: CORBAE-21
  • Legacy Issue Number: 9921
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    exception NoServant(); is included in local interface POA but had been removed from minimumCORBA. Is it definitely back in?

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    In “full” CORBA, the exception NoServant is used on in the operation
    get_servant. Since this operation is not present in either the Compact Profile or the
    Micro Profile, the exception should be removed to save the corresponding footprint.

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

Section: 8

  • Key: CORBAE-20
  • Legacy Issue Number: 9920
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    The following are included in the Micro Profile but missing from the Compact Profile // Factories for Policy objects LifespanPolicy create_lifespan_policy ( in LifespanPolicyValue value ); IdUniquenessPolicy create_id_uniqueness_policy ( in IdUniquenessPolicyValue value ); IdAssignmentPolicy create_id_assignment_policy ( in IdAssignmentPolicyValue value ); This appears to be an oversight because they are present in minimumCORBA.

  • Reported: CORBAe 1.0b1 — Fri, 14 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    These operations should not have been included in the Micro Profile. They should only
    be available in the Compact Profile. In the Micro Profile, the policy settings supported for
    these policies by the Root (and only) POA are specified. Therefore, there is no need to
    create these policy objects

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

Section: 5.2 and 5.7

  • Key: CORBAE-19
  • Legacy Issue Number: 9879
  • Status: closed  
  • Source: PrismTech ( Donald Sharp)
  • Summary:

    Under ORB Operations register_initial_reference is inside #if ! defined(CORBA_E_MICRO) on page 5-4. Under Consolidated IDL on page 5-35 it is outside the #if ! defined(CORBA_E_MICRO). Where should it fall?

  • Reported: CORBAe 1.0b1 — Fri, 30 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    The intent is that register_initial_reference is not in the Micro profile. The consolidated
    IDL should be corrected

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

Reduce dependency on CORBA

  • Key: CPP1111-25
  • Legacy Issue Number: 17534
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    This new language mapping has CORBA in several places. Part of it are really dependent on CORBA, but not all places. In order to make it more generable usable the spec has to be updated to reduce the dependency on CORBA by

    • Rename all CORBA::foo_traits<> to IDL::traits<>
    • Move CORBA::Fixed to IDL::Fixed
  • Reported: CPP11 1.0 — Wed, 1 Aug 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    As proposed by the issue we are removing the CORBA::foo_traits<> and use the generic new IDL::traits<>. This makes the client code independent on CORBA. We do keep the CORBA::make_reference to create a CORBA reference, CORBA::servant_traits<> for CORBA servant, and CORBA::Any

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

Typo in set_values

  • Key: CORBA32-1
  • Legacy Issue Number: 16994
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The set_values is defined as

    void set_values(
    in NVLis values // property values to set
    );

    but should be

    void set_values(
    in NVList values // property values to set
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section8.6.2.2 change
    in NVLis
    to
    in NVList

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

context:delete_values has type

  • Key: CORBA32-2
  • Legacy Issue Number: 16995
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    delete_values is define as

    void delete_values(
    in Identifie prop_name // name of property(s) to delete
    );

    but should be

    void delete_values(
    in Identifier prop_name // name of property(s) to delete
    );

  • Reported: CORBA 3.1.1 — Thu, 12 Jan 2012 05:00 GMT
  • Disposition: Resolved — CORBA 3.2
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.6.2.4 replace:
    in Identifie
    with
    in Identifier

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

Section: exceptions

  • Legacy Issue Number: 11027
  • Status: closed  
  • Source: wipro ( Rashmi)
  • Summary:

    org.omg.CORBA.NO_PERMISSION: vmcid: 0x0 minor code: 103 completed: No | | at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native | | Method) | | at | | sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces | | sorImpl.java:39) Feb 19 15:48:44 NMADR2CMT1 root: [NotificationChannel]NotificationChannel( ). Creating channel NpmChannel Feb 19 15:52:28 NMADR2CMT1 root: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No Feb 19 15:52:28 NMADR2CMT1 root: above mentioned are the errors we are getting from the the client appilcation. can anybody provide us the information why these execptions are generated and how to fix this kind of errors.

  • Reported: CORBA 3.0.3 — Mon, 21 May 2007 04:00 GMT
  • Disposition: Closed; No Change — CORBA 3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

Codec Interface Deficiencies

  • Legacy Issue Number: 7731
  • Status: closed  
  • 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
  • Disposition: Duplicate or Merged — CORBA 3.1
  • Disposition Summary:

    duplicate

  • Updated: Fri, 6 Mar 2015 22:25 GMT

Error in Chapter 21 of CORBA 3.0

  • Key: CORBA3-131
  • Legacy Issue Number: 6912
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    there is a serious error in Chapter 21 in both the CORBA 3.0 specification and the 3.1 drafts. The ORT final adopted specification (ptc/01-08-31 mentioned above) does NOT contain the methods ObjectReferenceFactory::equals an ObjectReferenceFactory::make_profiles. These methods were first added in the ORT FTF in issue 4476, then removed after further discussion in issue 4478. The final adopted specification reflects this, but somehow the incorrect text was incorporated into the official CORBA 3.0 specification. Unfortunately I only noticed this recently

  • Reported: CORBA 3.0.2 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    issue closed editorially

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Wrong minor code listed in POAManager::deactivate

  • Key: CORBA3-130
  • Legacy Issue Number: 5449
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 11.3.2.5 states that BAD_INV_ORDER with minor code 6 is raised
    if POAManager::deactivate is called from an invocation on a POA that
    would be affected by the deactivate call.

    This minor code ought to be 3 instead

  • Reported: CORBA 3.0 — Mon, 1 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.1
  • Disposition Summary:

    editorially fixed in 3.0

  • Updated: Fri, 6 Mar 2015 21:40 GMT

DATA_CONVERSION minor code 2 not listed in Table 4-3

  • Key: CORBA3-129
  • Legacy Issue Number: 5322
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is used by RealTime CORBA as documented in 24.17.2

  • Reported: CORBA 2.6.1 — Thu, 23 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0
  • Disposition Summary:

    non issue...editorial, issue withdrawn

  • Updated: Fri, 6 Mar 2015 21:38 GMT

New core issue: need UNKNOWN reply status

  • Key: CORBA26-96
  • Legacy Issue Number: 4747
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The Java RTF recently passed a resolution to fix some problems with the
    use of portable interceptors with the co-located call optimization. This
    resolution introduced a new abstract class ServantObjectExt that extends
    org.omg.CORBA.portable.ServantObject with methods for reporting
    normal and exceptional completion of the co-located call.

    When we look at the issue of mixed versions of stubs and ORBs with
    this change, there is one case that is particularly interesting:
    an old stub (uses only ServantObject) with a new ORB (provides
    ServantObjectExt). In this case, the ORB can detect that an old
    stub was used, because neither one of the two new methods was called.
    However, this leaves the ORB with no way to report the reply status
    correctly in the RequestInfo::reply_status attribute.

    To handle this special case, I propose that we add a new value of
    UNKNOWN for the reply status. This will only be used if the ORB
    cannot determine the reply status of an operation. This occurs
    with any co-located optimized call with the existing Java mapping.
    With the passage of the resolution to issue 4701, the scope of
    this occurence is smaller but still possible.

    Revised text:

    In section 21.3.12.10, add after PortableInterceptor::TRANSPORT_RETRY:

    PortableInterceptor::UNKNOWN

    In section 21.3.12.10, replace the third bullet under client with:

    Within the receive_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, TRANSPORT_RETRY, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD
    as its status. TRANSPORT_RETRY means that the transport mechanism
    indicated a retry - a GIOP reply with a status of NEEDS_ADDRESSING_MODE,
    for instance. UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

    In section 21.3.12.10, replace the third bullet under server with:

    Within the send_other interception point, this attribute will
    be any of: SUCCESSFUL, LOCATION_FORWARD, or UNKNOWN.
    SUCCESSFUL means an asynchronous request returned successfully.
    LOCATION_FORWARD means that a reply came back with LOCATION_FORWARD
    as its status. UNKNOWN means that the ORB was unable to determine
    the correct status. This can occur for example in the Java language
    mapping when the optimized path for a co-located call is used.

    In section 21.10, add the following after const ReplyStatus TRANSPORT_RETRY = 4:

    const ReplyStatus UNKNOWN = 5;

  • Reported: CORBA 2.5 — Wed, 12 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

TypeCode interface issue

  • Key: CORBA26-98
  • Legacy Issue Number: 4803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The section concerning with the TypeCode interface was removed from the Interface Repository chapter into the ORB Interface chapter, but the Minimum CORBA chapter refers to it in the old place.

  • Reported: CORBA 2.5 — Thu, 10 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Valuetype initialzers need exceptions

  • Key: CORBA26-97
  • Legacy Issue Number: 4785
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Valuetype initializers need exception declarations in order to provide
    complete mapping of Java declarations to IDL declarations in Java to IDL
    mapping.

    Discussion: This was discussed in te past and rejected because of the
    backward non-compatible changes required in the IFR. This time
    around.... the IFR changes are already part of the backward compatible
    changes maded in connection with the addition of exeptions to attributes
    etc in CCM in resolution to issue 3233. So all that is needed is change
    to one grammar rule and provision of language mappings. As the results
    of Components FTF is merged into Core to create CORBA Core 3.0
    everything then falls into place to give us initializers with exceptions
    for valuetypes.

    Issue 3641 in Java-IDL RTF is handling the Java language mapping issue,
    and Simon is shepherding that.

    We need to create a C++ language mapping issue and resolve it with the
    obvious mapping in C++ (Michi?)

    Specfic text changes:

    All changes specified here relative to document ptc/01-06-10:

    1. On page 3-13 change grammar production rule 23 to read:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” [ <raises_expr> ] “;”

    instead of:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” “;”

    2. On page 3-26 in section 3.8.1.5 change grammar production
    rule 23 to read:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” [ <raises_expr> ] “;”

    instead of:

    (23) <init_dcl> ::= “factory” <identifier>
    “(“ [ <init_param_decls> ] “)” “;”

  • Reported: CORBA 2.5 — Mon, 17 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Accept the proposed change based on discussion above

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Syntax error in CORBA IDL

  • Key: CORBA26-95
  • Legacy Issue Number: 4742
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In formal/01-11-01.txt, the second occurrence of create_native reads

    NativeDef create_native(
    in RepositoryId id,
    in Identifier name,
    in VersionSpec version,
    );

    This is incorrect; the comma after version must be removed.

  • Reported: CORBA 2.5 — Sun, 9 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Typedefs for struct members?

  • Key: CPP12-43
  • Legacy Issue Number: 4344
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I recently got a query from a customer. Basically, they have a CORBA system
    that interfaces to some legacy library. Lots of structures are being passed
    back and forth, many of which contain strings; these need to be passed
    as char * or as std::string, depending on where they go.

    So, the customer defined conversion functions that correctly copied a
    std::string or char * into and out of a string member (using string_dup()
    or whatever, as appropriate). The problem is that they have to use
    an undefined type name as the type of the parameter. For example:

    void copy(const std::string & from, CORBA::string_mgr & to);

    Of course, "string_mgr" is a mapping-internal type name and therefore the
    code is non-portable.

    I don't see an easy work-around that would be within the current mapping.
    I could use a function that accepts a reference to a struct instead of
    the string inside the struct, but that then means that I need a different
    function for each structure type. Or I can write macros that are specific
    to each ORB to handle it (but that is truly ugly and breaks if the vendor
    decides to tinker with the internals of their mapping).

    One way around it all would be to require a typedef to be generated for
    string members. For example:

    // IDL
    struct Foo

    { string s; }

    ;

    // C++

    namespace CORBA {
    // ...
    class string_mgr

    { /* ... */ }

    ; // Mapping-internal class

    typedef string_mgr string_member; // New standard name
    };

    struct Foo

    { CORBA::string_mgr s; // Mapping-internal type name }

    ;

    This would allow me to portably pass a string member to a function because
    the mapping would guarantee the existence of a type named "string_member"
    (or whatever name we can settle on).

    void copy(const std::string & from, CORBA::string_member & to);

    (Depending on the mapping implementation, there may be similar issues for
    other types, such as references or arrays. If there are such mappings,
    we'd need typedefs for those too.)

    Basically, wherever a type name that is internal to the mapping can appear,
    we end up with this kind of problem – I can't pass a value of that type
    because I don't know the type name. I'd like to fix that, if possible.

  • Reported: CPP 1.1 — Fri, 15 Jun 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Deprecated Ref identifier

  • Key: CPP12-42
  • Legacy Issue Number: 4325
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In the first para of section 1.3.1, we still have a sentence about
    the deprecated Ref names for object references. Those have been deprecated
    for a long time now.

    Proposal:

    Remove the sentence beginning with "For historical reasons, the
    type ARef..."

  • Reported: CPP 1.1 — Tue, 29 May 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Server-side exception specifications and ISO C++ std::exception

  • Key: CPP12-40
  • Legacy Issue Number: 4265
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    In CORBA C++ 2.4 and before, the exception specification of generated
    POA skeleton member functions is CORBA::SystemException plus the mapped C++
    class for exceptions specified in the raise expression of the corresponding
    IDL operation [see CORBA C++ 2.4 paragraph 23.27].
    As a result, a servant programmer needs to convert any exception other than
    those in the exception specification to one in the exception specification
    – else the C++ runtime will call std::unexpected() if an unexpected
    exception is thrown.

    This makes exception handling on the server-side quite painful:
    for example if a servant programmer calls operator new(), s/he's supposed
    to catch std::bad_alloc and convert it to CORBA::NO_MEMORY. Similarly,
    if s/he uses any of the ISO C++ libraries, s/he's supposed to convert the
    std::exception objects raised by the library into CORBA::SystemExceptions,
    or user-defined IDL exceptions.

    Given that C++ compilers provide more and more features of ISO C++,
    in particular the standard libraries, this is a real world issue!

    Proposal
    ========

    Add std::exception in the exception specification of generated
    POA-skeleton member functions. The POA (or POA skeleton) implementation
    is responsible to perform the following conversions:
    std::bad_alloc to CORBA::NO_MEMORY
    other std::exception to CORBA::UNKNOWN (see 3.17.1.1 in CORBA 2.3 core)

    Source-code backward-compatibility
    ----------------------------------
    I propose to make exception specifications in generated skeletons a bit
    less restrictive than they were in CORBA C++ 2.4 (and before).
    C++ servants written with the CORBA C++ 2.4 (and before) mapping do not
    require any change – their exception specifications will be more
    restrictive than required by the new mapping, which is perfectly correct.

    Interoperability
    ----------------
    It does not affect interoperability: only CORBA exceptions go on the
    wire. An ORB-mediated operation can only raise a CORBA::SystemException
    or a user-defined IDL exception.

    Alternative Mapping for C++ Dialects
    ------------------------------------
    Unfortunately, not all C++ compilers comply (or almost comply) with
    ISO C+. With such a "C+ compiler", the ORB/POA implementation will
    behave as in CORBA C++ 2.4 (i.e. no std::exception is the exception
    specification). Or maybe we can allow the ORB/POA to add an
    implementation-dependent class in the generated exception
    specifications?

    Portable user-written servants will simply include
    CORBA::SystemException (or something more restrictive) in their
    exception specifications.

  • Reported: CPP 1.1 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Incorrect example for recursive definitions which can span multiple levels

  • Key: CORBA25-54
  • Legacy Issue Number: 4261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Incorrect example for recursive definitions which can span multiple levels. I and my IDL compiler are missing an identifier in the following example union for the last struct member.

    union Bar; // Forward declaration typedef sequence<Bar> BarSeq; union Bar switch(long) { // Define forward-declared union case 0: long l_mem; case 1: struct Foo

    { double d_mem; BarSeq nested;// OK, recurse on enclosing type being defined }

    ?identifier missing?; };

  • Reported: CORBA 2.4.2 — Mon, 9 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    This has already been fixed in the previous RTF see orbrev/2001-03-01

  • Updated: Fri, 6 Mar 2015 21:38 GMT

There is an incorrect page reference

  • Key: CPP12-41
  • Legacy Issue Number: 4274
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Details: This section (entitled 1.16.10 The Any Class) refers the reader to the full definition of the Any class. However, it provides the page number and section heading of itself – it is self referential.

    Suggested Correction: The reference should refer to the section on page 1-150 (entitled 1.41.5 The Any Class)

  • Reported: CPP 1.1 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Remnant of read-only return values and out params

  • Key: CPP12-39
  • Legacy Issue Number: 4244
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    About two or three years ago, we decided to deprecate the read-only
    nature of in params on the server side, and out params and return values
    on the client side.

    The second-last para of 1.13.2 still contains a remnant that we forgot
    to clean up back then:

    As with other out and return values, out and return sequences must
    not be assigned to by the caller without first copying them.

    I would suggest to modify this sentence to read:

    For a sequence passed to an operation as an in parameter, the
    operation must not assign to the sequence if its release flag
    is false and the sequence has variable-length elements.

    For a sequence passed to a client as an out parameter or return
    value, the client must not assign to the sequence if its
    release flag is false and the sequence has variable-length elements.

    This captures more correctly the intent and the semantics of the release
    flag (because assigning to a sequence with the release flag set to true
    is perfectly OK).

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Backward compatibility with C

  • Key: CPP12-38
  • Legacy Issue Number: 4243
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec talks about backward compatibility with the C mapping in a number
    of places:

    • 1.1.14
    • at the beginning of 1.7
    • in the footnote on page 1-29
    • at the end of 1.10
    • at the end of 1.12
    • at the beginning of 1.13.3
    • at the end of 1.16.10
    • at the end of 1.20
    • at the end of 1.23
    • at the beginning of 1.26
    • 1.31.3
    • 1.42.1

    Binary compatibility with the C mapping has never existed and never will.

    Proposal: Remove all mention of the C mapping from the above places.

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Remove all mention of the C mapping from the above places.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Non-exception neutral code in C++ mapping.

  • Key: CPP12-37
  • Legacy Issue Number: 4210
  • Status: closed  
  • Source: University of California, Irvine ( Carlos O'Ryan)
  • Summary:

    formal/99-07-41 in section 1.36.3 includes the following code:

    ---------------- cut here ----------------
    class ServantBase_var {
    public:

    ~ServantBase_var ()

    { if (_ptr != 0) _ptr->_remove_ref (); }

    ServantBase_var& operator=(ServantBase* p)
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = p; return *this; }

    ServantBase*& out()
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = 0; return _ptr; }
    };
    ---------------- cut here ----------------

    unfortunately this code is not exception safe: if
    _remove_ref() throws the class is left in an inconsistent state (for
    out() and operator=). The fact that the destructor can potentially
    throw exceptions makes it extremely hard for application developers to
    write exception safe classes.
    A better implementation could be:

    ---------------- cut here ----------------
    class ServanBase_var
    {
    ServantBase_var& operator=(ServantBase* p)
    { if (p == _ptr) return *this; ServanBase_var tmp (p); std::swap (p._ptr, p); return *this; }

    ServantBase*& out()
    { if (_ptr != 0) _ptr->_remove_ref (); _ptr = 0; return _ptr; }
    };
    ---------------- cut here ----------------

    The implementation above also prevents silly mistakes like:

    ServantBase_var foo = ...;
    foo = foo.in ();

    The destructor is a little trickier:

    ---------------- cut here ----------------
    ServantBase_var::~ServantBase_var ()
    {
    // do not propagate exceptions out of the destructor
    try { if (_ptr != 0) _ptr->_remove_ref (); }

    catch (...)
    {
    }
    }
    ---------------- cut here ----------------

    Event better would be to add some throw spec to _remove_ref()
    and _add_ref(). The spec is, as far as I can tell, silent in this
    respect, thus those operations can throw anything. This is
    unfortunate because it makes it harder to write exception-safe code,
    both for application developers and ORB implementors alike.

  • Reported: CPP 1.1 — Tue, 20 Feb 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Need for TIE template for skeletons for valuetypes that support

  • Key: CPP12-36
  • Legacy Issue Number: 4166
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The third bullet of 1.17.9 states that a POA skeleton class is generated
    for valuetypes that support interfaces, but is silent about whether a
    _tie template is also generated.

    Proposal:

    Add the following to the end of the third bullet in 1.17.9:

    "No tie skeleton class is generated for the valuetype because the tie
    for the inherited class can be used instead."

  • Reported: CPP 1.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    duplicate of issue 3328 close issue

  • Updated: Fri, 6 Mar 2015 21:38 GMT

_name & _rep_id pure virtual?

  • Key: CPP12-35
  • Legacy Issue Number: 4153
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The definition for Exception in the current spec is:

    // C++
    class Exception

    { public: virtual ~Exception(); virtual void _raise() const = 0; virtual const char * _name() const; virtual const char * _rep_id() const; }

    ;

    Why aren't _rep_id() and _name() pure virtual?

  • Reported: CPP 1.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Requiring ref counting in ServantBase

  • Key: CPP12-34
  • Legacy Issue Number: 4114
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    The current requirement that the default implementations of _add_ref
    and _remove_ref in ServantBase do nothing creates several problems:

    1. The text in the C++ mapping that states that _remove_ref
    must be called on a servant means nothing unless the ref
    counting mix-in was used by the servant author.

    2. The intended semantics of _var types as "smart pointers"
    is upheld only if the servant author goes to the extra
    step of using the ref counting mix-in.

    3. In many places the C++ mapping explicitly or implicitly
    states that _var types will recover memory for the application
    developer:

    1.3.1:

    Client code frequently will use the object reference
    variable type (A_var) because a variable will
    automatically release its object reference when it is
    deallocated or when assigned a new object reference.

    1.3.6:

    When a _var is passed as an out parameter, any
    previous value it refers to must be implicitly
    released.

    In addition, there are many places in the C++ mapping where
    the specification of _var types for arrays, structs, strings,
    sequences, type Any, type codes, value types, value boxes,
    value factories, etc. guarantees that the memory will be
    reclaimed when the _var goes out of scope. This makes it
    easy for users to believe that all _var types will release
    storage for the objects that point to.

    Benefits of Proposed Resolution:

    Users can depend on ORB's to manage servant memory by default
    rather than by exception.

    Specification text that promises or implies automatic memory
    reclamation need not change.

    Existing user code will still compile.

    Resolution:
    Revised Text:

    Replace the text in section 1.36.1 beginning with the sentence:

    Servant instances may implement reference counting to prevent
    themselves from being destroyed while the application is
    still using them.

    and section 1.36.2 in its entirety with:

    Servant instances may implement reference counting to prevent
    themselves from being destroyed while the application is still
    using them. Servant reference counting is performed using the
    _add_ref and _remove_ref functions declared in ServantBase. The
    default implementations of _add_ref and _remove_ref supplied by
    ServantBase provide true reference counting. An instance of a
    servant class derived from ServantBase initially has a reference
    count of one. Invoking _add_ref on the servant instance
    increases its reference count by one. Invoking _remove_ref on
    the servant instance decreases its reference count by one; if the
    resulting reference count equals zero, _remove_ref invokes delete
    on its this pointer in order to destroy the servant. For ORBs
    that operate in multi-threaded environments, the implementations
    of _add_ref and _remove_ref that the ServantBase class provides
    shall be thread-safe.

    ServantBase supports copy construction and the default assignment
    operation. Copy construction always sets the reference count of
    the new servant instance to one. The default assignment
    implementation merely returns *this and does not affect the
    reference count.

    For servants that require that servants are not reference
    counted, these functions are virtual and thus may be overridden
    by derived servant classes. A default mix-in class is also
    provided to remove the reference counting in the PortableServer
    namespace; please see Section 1.36.2, "Servant No Reference
    Counting Mix-In," on page 1-??? for more details. Details
    concerning POA and application responsibilities with respect to
    reference counting can be found in Section 1.36.4, "Servant
    Memory Management Considerations," on page 1-???.

    Note that for applications that depended on the the
    RefCountServantBase provided in previous revisions of this
    specification ORBs must provide a default implementation of this
    mix-in class in the PortableServer namespace that essentially
    does nothing:

    // C++
    namespace PortableServer
    {
    class RefCountServantBase : public virtual ServantBase

    { public: ~RefCountServantBase(); protected: RefCountServantBase(const RefCountServantBase&); RefCountServantBase& operator=(const RefCountServantBase&); private: // ...other implementation details... }

    ;

    }

    1.36.2 Servant No Reference Counting Mix-In

    The PortableServer namespace also provides a standard servant
    mix-in class to remove the reference counting:

    // C++
    namespace PortableServer
    {
    class NoRefCountServantBase : public virtual ServantBase
    {
    public:
    ~NoRefCountServantBase();
    virtual void _add_ref() {}
    virtual void _remove_ref() {}
    protected:
    NoRefCountServantBase() {}
    NoRefCountServantBase(const NoRefCountServantBase&) {}
    NoRefCountServantBase& operator=(const NoRefCountServantBase&);
    private:
    // ...other implementation details...
    };
    }

    The NoRefCountServantBase mix-in class overrides the inherited
    _add_ref and _remove_ref functions it inherits from ServantBase,
    in order to override and remove the default reference counting in
    ServantBase.

  • Reported: CPP 1.1 — Thu, 6 Apr 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Definition of TRANSIENT minor code 1 confusing

  • Legacy Issue Number: 4036
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    >From CORBA 2.4, Table 4-3: TRANSIENT minor code 1 is described as:

    "Request discarded due to resource exhaustion in POA."

    However, section 11.3.2.1 states that minor code 1 is used when the
    POAManager is in the DISCARDING state.

    I think it would be better to reword this description as:

    "Request discarded because POAManager is in DISCARDING state (e.g.
    server lacks resources to complete request.)"

  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDL format for RepositoryId

  • Legacy Issue Number: 4035
  • Status: closed  
  • Source: UBS ( Karsten Starr)
  • Summary:

    Following statement in CORBA V2.3 (06/1999),
    P10-39, Chapter 10.6.1, OMG IDL Format concerning
    the OMG IDL format for Repository IDs:

    >> The RepositoryId consists of three components, separated by
    colons, (":")

    The first component is the format name, "IDL."

    The second component is a list of identifiers, separated by
    "/" characters.

    These identifiers are arbitrarily long sequences of alpha-
    betic, digit, underscore ("_"), hyphen ("-"), and period (".")
    characters. Typically, the first identifier is a unique prefix,
    and the rest are OMG IDL Identifiers that make up the scoped
    name of the definition. <<

    There are two issues here:

    • Firstly I propose to change >>"IDL."<< into >>"IDL".<<
    • Furthermore, I propose be more specific on the definition
      of the Repository Id. The above definition does not
      exclude a RepositoryId in the following style (which
      in my opinion does not make sense and effects inter-
      operability between ORBs): "IDL:/A/B:1.0"
      A regular expression could clarifiy this issue:
  • Reported: CORBA 2.4.1 — Thu, 9 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Valuetypes supporting local interfaces are local types?

  • Legacy Issue Number: 4031
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The semantics for local interfaces states:

    A valuetype may support a local interface.

    This brings up two questions.
    1. Can it support multiple? In addition to a unconstrained non abstract
    interface?
    2. Does it then become a local type (I think not, I think it becomes a
    local type only when it contains state that is a local type)

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

DynUnion incomplete

  • Legacy Issue Number: 4005
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    given the a DynUnion value, I want to find out whether the discriminator
    currently indicates the default case. For example:

    union u switch (long)

    { case 0: long l; case 1: char c; case 2: double d; default: float f; }

    ;

    For this union, I want to know whether the default member is active, that is,
    whether the discriminator has a value other than 0, 1, or 2.

    Finding out whether the discriminator indicates the default case is currently
    rather difficult. I have to:

    1) get the union type code
    2) collect the values of all the explicit case labels from
    the type code
    3) check if the discriminator currently has a value that is not
    one of the explicit case labels values

    It would be much nicer to add the following to DynUnion:

    interface DynUnion : DynAny

    { boolean is_set_to_default_case(); // ... }

    ;

    The is_set_to_default_case operation returns true if a union has
    an explicit default label and the discriminator value does not
    match any of the union's other case labels.

  • Reported: CORBA 2.4 — Mon, 30 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add the is_set_to_default_member function with the functionality as described for is_set_to_default_

  • Updated: Fri, 6 Mar 2015 21:38 GMT

#pragma version issue

  • Legacy Issue Number: 4016
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    In the CORBA 2.4 spec, chapter 10, the definition of #pragma ID has
    been modified so that later re-declarations of the same ID for a type
    are permitted. Before, it was explicitly an error to use #pragma ID
    for a type more than once, even if the same IDs were given.

    The section of #pragma version has not been updated. This means that
    handling of the two similar pragmas is now inconsistent:

    interface A {};
    #pragma ID A "LOCAL:foo"
    #pragma ID A "LOCAL:foo" // OK in 2.4, error in 2.3

    interface B {};
    #pragma version B 3.4
    #pragma version B 3.4 // Error in 2.4 and 2.3

    Should #pragma version be updated to be consistent with #pragma ID?

  • Reported: CORBA 2.4.1 — Fri, 3 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Servant deactivation callback?

  • Legacy Issue Number: 4014
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Consider a servant for a persistent object that sits in front of a database.
    Assume a simple implementation model, using RETAIN and
    USE_ACTIVE_OBJECT_MAP_ONLY.

    We have n CORBA objects with n servants, and each servant implements
    its operations by reading/writing through to the persistent store, possibly
    also caching some state and maintaining other resources, such as database
    connections or memory buffers.

    I want to implement a life cycle destroy() operation. In the body of
    destroy, I have to write something like:

    void
    Foo_impl::
    destroy() throw(CORBA::SystemException)

    { my_poa->deactivate_object(my_oid); // Cannot remove database record here or do any other // cleanup. }

    The problem is that the servant can't simply blow things away at that
    point because there may be other operations running concurrently in the
    same servant, and those operations would get awfully surprised if their
    state suddenly disappeared.

    So, I delay reclaiming resources and deleting the database record until
    the servant becomes idle. In C++, that's no problem. Eventually, the
    servant's AOM entry disappears and (at least if I use reference-counted
    servants) that triggers the destructor of the servant, and I can
    clean up in the destructor.

    However, it appears that this doesn't work for other languages because they
    may not have destructors or, like Java, make no guarantees about when
    the destructor will be called.

    The problem is that there is no way for me to find out at what
    point the servant becomes idle, so that I could clean up.

    I think we need a callback from the ORB to the server application code that
    notifies the server when a servant finally becomes idle. Otherwise, it is
    pretty much impossible to implement life cycle support in languages other
    than C++, especially for threaded servers.

  • Reported: CORBA 2.4.1 — Thu, 2 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close no change.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

CORBA::Fixed needs a to_string() conversion function

  • Key: CPP12-33
  • Legacy Issue Number: 3944
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA::Fixed should have a to_string() member function to allow an
    explicit conversion to a string. Otherwise the only way to get a string
    version of the information in a fixed is via a string stream, which can
    be awkward.

    namespace CORBA {
    class Fixed

    { public: ... char *to_string(); ... }

    ;
    }

    The caller of Fixed::to_string() must deallocate the return value by
    calling CORBA::string_free or assigning it to a String_var.

  • Reported: CPP 1.1 — Tue, 10 Oct 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Format of RMI Hashed Format repid

  • Legacy Issue Number: 3970
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The format of the "hash code" element of an RMI Hashed Format repid
    needs to be clarified. Section 10.6.2 gives the algorithm for computing
    the 64-bit number to be used as the hash code, but does not specify the
    on-the-wire format for this number. In contrast, the spec explicitly
    states that the 64-bit number representing the SUID is transcribed as
    a 16-digit upper-case hex string.

  • Reported: CORBA 2.4 — Wed, 18 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Clarify as suggested below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Another issue with String_var

  • Key: CPP12-32
  • Legacy Issue Number: 3797
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Why is it that String_var contains the following?

    operator char *();

    The mapping never passes strings as a char *. The only parameter
    passing signatures are const char * for in params, char * & for inout params,
    and String_out for out params.

    It seems that this operator is redundant?

    The only reason I can think of for it having been added are sloppy signatures
    (such as old implementations of strcpy or some such, which sometimes used
    char * instead of const char *). However, wouldn't it be better to remove
    operator char *() from String_var and force a cast for such broken function
    signatures?

  • Reported: CPP 1.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Remove operator char*() from class String_var.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Missing conversion operator on String_var

  • Key: CPP12-31
  • Legacy Issue Number: 3796
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 1-153, section 1.41.2:

    String_var has:

    operator char*();
    operator const char*() const;

    What is missing here is:

    operator char*&();

    Without that, a String_var cannot be passed as an inout param.

  • Reported: CPP 1.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Add operator char*&() to class String_var.

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Typo: "Wrongpolicy"

  • Legacy Issue Number: 3634
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 11-47, reference_to_servant, uses "Wrongpolicy". That should be
    "WrongPolicy".

  • Reported: CORBA 2.3.1 — Sun, 21 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Minor typo

  • Legacy Issue Number: 3621
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pages 11-30 (twice), 11-31 (three times), and 11-52 (once) mention
    the OBJECT_ADAPTER exception. That's wrong – it should be OBJ_ADAPTER.

  • Reported: CORBA 2.3.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Editorial, fixed editorially in 2.4

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Any extraction widening to ValueBase

  • Key: CPP12-30
  • Legacy Issue Number: 3604
  • Status: closed  
  • Source: International Business Machines ( Michael Cheng)
  • Summary:

    Currently there is Any extraction with widening to Object, and
    AbstractBase.
    It seems useful to also have one that widens to ValueBase.

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    duplicate of issue 3092...closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Section 4.3.7.1 get_client_policy?

  • Legacy Issue Number: 3582
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 4.3.7.1 refers to a get_client_policy operation, but it is not
    defined anywhere in the CORBA specification.

  • Reported: CORBA 2.3.1 — Thu, 27 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    temporary bug....fixed, and issue closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Typo on page 7-9 of 2.3.1

  • Legacy Issue Number: 3564
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 7-9 of 2.3.1 shows

    boolean poll_response(in Request req);

    However, on page 7-5, we have:

    boolean poll_response();

    The version on page 7-5 is the correct one because poll_response() is
    an operation on Request.

    Proposal:

    Change the signature on page 7-9 to read:

    boolean poll_response();

  • Reported: CORBA 2.3.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue...editorial

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Null assignment to String_var?

  • Key: CPP12-29
  • Legacy Issue Number: 3534
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    page 1-23 says:

    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.

    So, I can't explicitly initialize with null:

    T_var tv = 0;

    This seems strange, seeing that the default constructor does initialize
    with null.

    Also, the spec doesn't say anything about assignment. Is the following legal?

    T_var tv = ...;
    tv = 0;

    I don't understand the restriction. What's the motivation for
    disallowing this? Especially for String_var, the prohibition against null
    null seems rather draconian. For example, I may be using a temporary local
    String_var for exception safety and then, at some point, decide to
    assign null to it to force an early deallocation of the string instead
    of having to create a separate scope to achieve this.

    At any rate, we should clarify so that, whatever the eventual decision is,
    the text for the assignment operator agrees with the text for the constructor.

  • Reported: CPP 1.1 — Fri, 7 Apr 2000 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

_name and _rep_id

  • Key: CPP12-28
  • Legacy Issue Number: 3381
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: do I need to deallocate the string returned by Exception::_name()
    and Exception::_rep_id() or not? The spec doesn't say...

    Given that these are PIDL, and that the return value is const char *
    (rather than non-const char *), I'd say that I shouldn't have to deallocate
    the return value. But I think we should clarify this in the spec.

    Also, the Exception class in section 1.41.7 doesn't show the _name and
    _rep_id members, so we need to add them there.

    Further, Exception doesn't show up in section 1.23 (Mapping of Pseudo
    Objects). I suspect that we need to add Exception there as well and
    mention the exception to the memory management rules? Another interesting
    thing is that, if Exception is a pseudo object, then UserException and
    everything derived from it is also a pseudo object. But, user exceptions
    can't be pseudo objects. But, if they are not pseudo-objects, we can't
    really make special-purpose memory managment rules. Sigh...

  • Reported: CPP 1.1 — Wed, 1 Mar 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

BAD_QOS system exception

  • Legacy Issue Number: 3337
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    This system exception is listed in the notification specification but
    does not exist in CORBA 2.3 (nor CORBA 2.0 AFAIK).

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed issue, available in current draft

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Do valuetype POA servants get tie templates?

  • Key: CPP12-27
  • Legacy Issue Number: 3328
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.9 states that valuetypes that support a non-abstract
    interface have a POA skeleton class generated for them. Is a tie
    template class also supposed to be generated?

  • Reported: CPP 1.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Problem with OBV_ valuetype class constructor

  • Key: CPP12-25
  • Legacy Issue Number: 3298
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 specification does not cover the case of code generation
    for the OBV_ class constructor for a valuetype that inherits from
    another concrete valuetype:

    // IDL
    valuetype A

    { octet o1; }

    ;

    valuetype B : A

    { octet o2; }

    ;

    The generated OBV constructor for class B needs to take both o1 and o2
    arguments, so it should look like this:

    // C++
    class OBV_B

    { ... protected: ... OBV_B(Octet init_o1, Octet init_o2) }

    ;

    Proposal:

    Change the second paragraph of 1.17.2 to read:

    "For the same reasons, a C++ OBV_ class defines a protected default
    constructor, a protected constructor that takes an initializer for each
    valuetype data member, and a protected default constructor. The
    parameters of the constructor that takes an initializer for each member
    appear in the same order as the data members appear, top to bottom, in
    the IDL valuetype definition, regardless of whether they are public or
    private. If the valuetype inherits from a concrete valuetype, then
    parameters for the data members of the inherited valuetype appear
    first. All parameters for the member initializer constructor follow the
    C++ mapping parameter passing rules for in arguments of their respective
    types."

  • Reported: CPP 1.1 — Sun, 6 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Problem with type specific valuetype factories in CORBA 2.3.1 C++ mapping

  • Key: CPP12-26
  • Legacy Issue Number: 3304
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.10.3 states that type specific valuetype factories are
    generated with a public destructor. This conflicts with the reference
    counting requirement for factories, since it makes it easier for
    application code to delete a factory that still has outstanding
    references.

    Proposal:

    Change the text in 1.17.10.3 to make destructors for type specific
    valuetype factories protected rather than public.

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

C++ Value Type issue (02)

  • Key: CPP12-23
  • Legacy Issue Number: 3224
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    2. Valuetypes should have _var typedef inside the class to aid template
    programming just like objects, structs and unions.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Obsolete text in 1.40.3

  • Key: CPP12-24
  • Legacy Issue Number: 3239
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The last C++ RTF made changes that identify specific inheritence
    strategies must be used for generating code for interfaces that inherit
    from abstract interfaces. The text in 1.40.3 was not updated to reflect
    this, and still suggests that other strategies are possible, when they
    are no longer allowed.

  • Reported: CPP 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Valuebox for object reference underspecified

  • Key: CPP12-22
  • Legacy Issue Number: 3223
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ mapping for valueboxes (1.17.7.2) does not specify the
    behavior of the constructors, assignment operator and _value modifier
    method with respect to the object reference argument. These methods
    clearly need to call _duplicate on their argument, since the valuebox
    must manage its own memory.

    Proposal:

    Add the following paragraph just before the example in 1.17.7.2:

    Value box classes for object reference maintain a private managed copy
    of the object reference. The constructor, assignment operator and
    _value modifier method for these classes call _duplicate on the object
    reference argument, and the destructor calls CORBA::release on the boxed
    reference.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

C++ valuetype issue (01)

  • Key: CPP12-21
  • Legacy Issue Number: 3222
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ mapping makes no mention of _out types for
    valuetypes. Clearly this is needed and should be mentioned.

  • Reported: CPP 1.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

attributes and system exceptions

  • Legacy Issue Number: 3219
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The components spec permits attributes to raise user exceptions, to
    bring them in line with operations. That's a really nice idea, but
    raises yet another versioning problem. In particular, no new IDL that
    uses an attribute with a raises clause can be compiled by an older IDL
    compiler. (Simply deleting the raises clause and then compiling with
    an older compiler is risky at best – marshaling code won't in general
    expect to get a user exception in reply to accessing an attribute...)

  • Reported: CORBA 2.3.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Valuetype code typo in CORBA 2.3 C++ mapping

  • Key: CPP12-20
  • Legacy Issue Number: 3206
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 1.17.10.2, the definition of operator= for ValueFactoryBase_var
    has "ValueFactoryBaseBase_var".

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    fixed editorially...issue closed

  • Updated: Fri, 6 Mar 2015 21:37 GMT

C++: ostream insertion

  • Key: CPP11-256
  • Legacy Issue Number: 3165
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Many ORBs provide ostream insertion for exceptions as an extension to C++
    mapping. Typically, applications are required to use them (there is not really
    a usable alternative) to write code in the following style:

    try

    { // do some operations }

    catch (CORBA::Exception & ex)

    { cerr << "some operation failed: " << ex << endl; }

    This breaks portability as not all ORBs provide the functionality in the same
    way. Therefore ostream insertion should be part of the standard.

  • Reported: CPP 1.0 — Thu, 23 Dec 1999 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.1
  • Disposition Summary:

    closed issue, duplicate of 266

  • Updated: Fri, 6 Mar 2015 21:37 GMT

_var types for fixed-length underlying types

  • Key: CPP11-255
  • Legacy Issue Number: 3101
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the spec currently is extremely vague about how _var types for fixed-length
    underlying types are supposed to work. The only words are:

    The T_var types are also produced for fixed-length structured
    types for reasons of consistency. These types have the same
    semantics as T_var types for variable-length types. This allows
    applications to be coded in terms of T_var types regardless of
    whether the underlying types are fixed- or variable-length.

    This has long been a source of confusion to me. In particular, it doesn't
    answer questions such as

    • Can a _var for a fixed-length type be initialized with a pointer
      to the fixed-length type? If so, does the _var adopt it?
    • Can a _var for fixed-length type be initialized with a value?
    • What does assignment between _vars for fixed-length types do?
    • Does the _var for a fixed-length type work like a reference
      and remain bound to the same block of memory?
    • What does default-initialization of such a _var do?
    • etc, etc.
  • Reported: CPP 1.0 — Thu, 9 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    duplicate of issdue 1521...close issue

  • Updated: Fri, 6 Mar 2015 21:37 GMT

why was is_abstract added to structs in CORBA IR?

  • Legacy Issue Number: 3015
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was wondering if anyone can explain the rationale for adding the field
    'is_abstract' to the CORBA::InterfaceDescription and
    CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA
    2.3 Interface Repository specification. (I do know about abstract interfaces,
    I am really looking for the rationale for breaking backwards compabitility).

    Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot
    interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB,
    because virtually any client of the IR will want to obtain a
    FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will
    not marshal the 'is_abstract' field for the description struct, thereby the
    CORBA 2.3 client will fail to unmarshal the struct.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    flagged as urgent....resolved

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Null Value semantics under specified

  • Legacy Issue Number: 2817
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    he description of null value semantics (in ptc/99-03-07) is insufficient to ensure an adequate mapping to an
    implementation language. Issues that should be specified include: - Creation. How are null values created? Are all declared (but
    uninitialized) values born null? Is this a language mapping requirement or allowance? - Invocation. Presumably invoking an
    operation ON a null value should result in an exception. But, what exception? Shouldn't the exception be specified for application
    portability? - Passing. Presumably, it is allowable to provide a null value as the actual parameter for a non member operation (i.e.,
    not on itself). True? - Typing: are null values typed, untyped, or is this governed by the language mapping? - Substitutability (see
    "typing" above): – Presumably: a null value may be successfully widened to a null value of an ancestor stateful value type. True?
    – Can a null value be successfully widened to a (null) supporting concrete interface? (Can a null value be activated as a servant?)
    – Can a null value be successfully widened to a (null) supporting abstract interface? – Can a null value be successfully widened
    to a (null) ancestor abstract value type? The only mentions of null values currently are: - the bullet in 5.2 - 5.2.4.2

  • Reported: CORBA 2.3 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

DynFactory or DynAnyFactory?

  • Legacy Issue Number: 2617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 9-10 of the new DynAny draft says that you pass "DynFactory" to
    resolve_initial_references() to get a DynAnyFactory. The third comment on
    page 9-2, however, says the string should be "DynAnyFactory". I believe the
    latter is correct.

  • Reported: CORBA 2.3 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

is_abstract parameter missing from create_interface() IDL

  • Legacy Issue Number: 2579
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I noticed the IDL for Container in ptc/98-12-04, page 10-59 is missing
    is_abstract parameter in create_interface() operation.
    The instance on page 10-16 does include it.

  • Reported: CORBA 2.3 — Thu, 8 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

string sequences and empty strings

  • Key: CPP11-254
  • Legacy Issue Number: 2525
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For string sequences, new string elements, that are created when the
    sequence length is increased, should be initialized to the empty string.

    I therefore raise this herewith as an official issue.

    I also don"t think it makes sense to vote on issue 2234 before we
    decided on the issue above. As I already pointed out, I raised issue
    2234 in the believe that the spec already says that new string sequence
    elements are initialized as empty string. But this assumption was wrong.

  • Reported: CPP 1.0 — Wed, 10 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed and fixed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Incorrect types for type-safe Any extraction

  • Key: CPP11-253
  • Legacy Issue Number: 2463
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The first bullet point at the bottom of page 20-61 is incorrect. It
    states that Boolean, Char, and Octet can be extracted using >>=. However,
    on page 20-66, the mapping requires a compile-time error for attempts
    to extract these types with >>=.

    Proposal:

    Delete Boolean, Char, and Octet from teh list of types at
    the bottom of page 20-61.

  • Reported: CPP 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

"Diamond of Death" in CosLifeCycleReference

  • Key: CPP11-252
  • Legacy Issue Number: 2345
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following MIGHT be considered an issue for CosLifeCycle and/or
    CosReference.

    The inheritance of CosReference::Relationship and
    CosCompoundLifeCycle::Relationship by CosLifeCycleReference::Relationship
    creates a "Diamond of Death" inheritance structure, in which
    CosRelationships::Relationship is inherited by two distinct paths:

    CosRelationships::Relationship
    / \
    / \
    CosReference::Relationship CosCompoundLifeCycle::Relationship
    \ /
    \ /
    CosLifeCycleReference::Relationship

  • Reported: CPP 1.0b2 — Tue, 26 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Destruction of ORB

  • Legacy Issue Number: 2254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: how is the ORB object destroyed? There is no ORB::destroy() operation,
    like for the POA. (With "destroy", I mean to remove it from memory
    (C++), or to allow it to be garbage collected (Java).)

    Is shutdown to be meant to destroy the ORB? If so, then this must be
    clarified in the specification. For example, if shutdown() destroys the
    ORB, all subsequent calls to ORB operations (via ORB references) must
    raise OBJECT_NOT_EXIST, just as it is with any other (locality
    constrained) object.

    If shutdown() does not destroy the ORB, but just shuts down
    communications and stops handling of further requests, then some other
    operation is needed to destroy the ORB.

  • Reported: CORBA 2.2 — Mon, 14 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Typedef for ties?

  • Key: CPP11-251
  • Legacy Issue Number: 2032
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We currently have the _ptr_type and _var_type definitions for interface
    classes. These are useful for template functions that need to deal with
    the proxy type as well as the _ptr and/or _var references.

    In a similar vein, we could add a typedef to the tie template for the
    tied object class:

    template<class T>
    class POA_A_tie : public POA_A

    { public: typedef T _tied_object_type; // <=== New // }

    ;

  • Reported: CPP 1.0b2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OMG VMCID

  • Legacy Issue Number: 2000
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Well, it looks like I get to choose what OMG"s VMCID is going to be. My
    > current thoughts are to allocate 65613 as OMG"s VMCID. This will make
    > the minor code value unsigned long appear on the wire as \x00, "M",
    > \x0<e>, <E>; where <e> is the high four bits of the minor code and <E>
    > is the lower 8 bits of the minor code.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Tie classes

  • Key: CPP11-250
  • Legacy Issue Number: 2003
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be nice to have a trait in the Tie classes of the class that the requests are being forwarded to. Something like this:

    template <class T>
    class POA_Foo_tie : public POA_Foo

    { public: // .... typedef T tie_object_type; }

    ;

  • Reported: CPP 1.0b2 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Closed; No Change — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

New proposal for recursive TypeCode creation

  • Legacy Issue Number: 1967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The basic problem of creating recursive TypeCodes has become more
    complex with the addition of valuetypes. The current mechanism for
    creating TypeCodes (as adopted by the last RTF) cannot create
    TypeCodes for a large number of cases, and can be quite confusing.
    The new proposal solves the problem of creating recursive TypeCodes in
    general and would deprecate all existing mechanisms for creating
    recursive TypeCodes.

  • Reported: CORBA 2.2 — Thu, 17 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Typo on pages 10-53, 10-55, and 10-70

  • Legacy Issue Number: 1944
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The create_value_tc() api and C++ example use ValueMembersSeq, but the name
    should match the ValueMemberSeq ( no "s" after Member) definition given on page
    10-33 & 10-65

  • Reported: CORBA 2.2 — Fri, 11 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

deactivate_object page no: 9-35

  • Legacy Issue Number: 1950
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: deactivate_object page no: 9-35

    void deactivate_object(in Objectid oid)
    raises (ObjectNotActive,WrongPolicy)

    If a servant manager is associated with the poa, ServantLocator:: etherealize will be invoked with the oid and the servant.
    It should be ServantActivator::etherealize instead of ServantLocator:: etherealize.

    The Note of deactivate object it should be ServantActivator::etherealize instead of ServantLocator:: etherealize

  • Reported: CORBA 2.2 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposal for creating recursive TypeCodes

  • Legacy Issue Number: 1928
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have spent some time pondering the various issues surrounding
    recursive TypeCodes and OBV, and have come up with a proposed
    solution. This is not a formal proposal (it does not include actual
    changes to the CORBA spec) and is intended mostly to promote
    discussion.

    For this discussion a recursive TypeCode is defined as a TypeCode
    which contains data members which refer to the containing type or any
    type containing the containg type.

    The basic problem of creating recursive TypeCodes has become more
    complex with the addition of valuetypes. The current mechanism for
    creating TypeCodes (as adopted by the last RTF) cannot create
    TypeCodes for a large number of cases, and can be quite confusing.
    The new proposal solves the problem of creating recursive TypeCodes in
    general and would deprecate all existing mechanisms for creating
    recursive TypeCodes.

  • Reported: CORBA 2.2 — Wed, 2 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Types defined in the CORBA module?

  • Legacy Issue Number: 1797
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Where am I supposed to pick up the types defined in the CORBA module,
    such as CORBA::Identifier, if I want to use them in my IDL?

    The (now apparently missing) orb.idl file gave me access to the
    TypeCode interface and the IFR interfaces, but mentioned nothing about
    other types defined in the CORBA module.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Identifier, if I want to use them in my IDL?

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Missing orb.idl

  • Legacy Issue Number: 1796
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears that during the editing for the POA changes for 2.2, Appendix A
    of the old BOA chapter was dropped without a trace. As a result, it looks
    like the definition for the orb.idl include file has disappeared.

  • Reported: CORBA 2.2 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Size of IDL char

  • Legacy Issue Number: 1753
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL chapter says on page 3-24:

    OMG IDL defines a char data type that is an 8-bit quantity which...

    This seems to imply that chars must map to an 8-bit type in the target
    language. Not all CPUs can do this. For example, on a Cray, chars are a
    32-bit type.

    I would suggest to remove the size requirement.

  • Reported: CORBA 2.2 — Thu, 30 Jul 1998 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Incorrect LifeCycle IDL?

  • Legacy Issue Number: 1772
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.2 of formal/98-07-05 mentions

    typedef Naming::Name Key;

    I believe it should be CosNaming::Name instead.

  • Reported: CORBA 2.2 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Servant management rules

  • Key: CPP11-249
  • Legacy Issue Number: 1735
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is a list of all the POA-related operations that deal with the Servant
    type, and how I believe they need to act with respect to reference
    counting. Because there aren"t that many operations in this list, I believe
    that by spelling them out in detail rather than trying to capture their
    behavior in general rules accomplishes two things:

    1) We make it crystal clear to POA implementors and application developers
    how each operation handles reference counting for the Servants it deals
    with, and how the POA interacts with those servants.

    2) We make it clear to future maintainers of the C++ mapping for the
    PortableServer module that any new operations that deal with servants must
    have their servant reference counting semantics explicitly specified.

    Again, because there are so few operations to cover, explicitly specifying
    rules for each one is simple and precise.

  • Reported: CPP 1.0b2 — Sat, 25 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration

  • Legacy Issue Number: 1728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Firstly, in Section 3.10.2, "Parameter Declarations" on
    page 3-32, the last paragraph states:

    When an unbounded string or sequence is passed as an
    inout parameter, the returned value cannot be longer
    than the input value.

    This seems like an undesirable and unnecessary restriction to me.
    Is there any chance that you could remove this restriction in a
    future version of the specification? Alternatively, if there is
    a good reason for this restriction then perhaps you could document
    it in a future revision of the specification.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

CosObjectIdentity::ObjectIdentifiers can"t be UUIDs?

  • Legacy Issue Number: 1725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does anyone know why the CosObjectIdentity::ObjectIdentifier was changed
    from "typedef sequence<octet,16>" to "typedef unsigned long"? This
    happened some time ago between the 3/94 and 3/95 versions of the
    CosRelationships specification.

    It seems odd since the earlier version could support the 128 bit UUIDs
    used in DCE and the 128 bit GUIDs found in Microsoft but the current
    version is only one quarter the size. Also, all available literature I
    can find on the topic indicates that the 128 bit version is necessary
    for uniqueness "across space and time". In large distributed object
    environments, I don"t think the 32 bit version will cut it.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Illegal IDL in CosTime module

  • Legacy Issue Number: 1688
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL in module CosTime for the compare_time and
    time_to_interval operations is illegal. Reference
    http://www.omg.org/archives/experts/msg00890.html
    for further information.

  • Reported: CORBA 2.2 — Thu, 16 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

TypeCode comparison proposal (02)

  • Legacy Issue Number: 1623
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 10. Define two new operations on TypeCodes:

    pseudo interface TypeCode

    { ... TypeCode get_compact_typecode(); TypeCode get_canonical_typecode(); ... }

    ;

    TypeCode::get_compact_typecode() strips out all optional name & member
    name fields. TypeCode::get_canonical_typecode() looks up the TypeCode
    in the Interface Repository and returns the fully fleshed-out TypeCode.
    If the top level TypeCode does not contain a RepositoryId, (such as
    array and sequence TypeCodes, or TypeCodes from older ORBs), then a new
    TypeCode is constructed by calling TypeCode::get_canonical_typecode() on
    each member TypeCode of the original TypeCode. If the Interface
    Repository is unavailable, or does not contain the information needed,
    the call raises the INTF_REPOS system exception.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

TypeCode comparison proposal (01)

  • Legacy Issue Number: 1622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Points 1 through 9 need to be considered as one unit. Point 10 can be
    voted on independently, but does provide a useful capability for
    controlling the size and content of TypeCodes.

    Proposal:

    1. Make RepositoryIds mandatory for all TypeCodes that have them. [This
    was done by the previous core RTF. I am just reiterating it here for
    completeness.]

    2. All TypeCode constants generated by the IDL compiler, as well as all
    TypeCodes returned by the Interface Repository must include alias
    TypeCodes wherever a typedef declaration appears in the original IDL
    source.

    3. Each IDL programming language mapping must provide a mechanism for
    the programmer to ensure that values of the IDL any type contain the
    exact typecode desired by the programmer.

    4. The name() and member_name() fields of the TypeCode are for
    documentary purposes only, and are never considered significant when
    comparing TypeCodes.

    5. Define a new equivalent operation for TypeCodes:

    pseudo interface TypeCode

    { ... boolean equivalent(in TypeCode other); ... }

    ;

    with the following semantics:

    a) If the two TypeCodes are the same primitive type (null, void, short,
    long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
    longlong, ulonglong, longdouble, wchar) then equivalent() returns true.

    b) If the two TypeCodes are string, wstring or fixed with the same
    parameters (bounds, digits or scale) then equivalent() returns true.

    c) If the two TypeCodes are both arrays or both sequences, with the
    same bounds and their component types are equivalent(), then
    equivalent() returns true.

    d) If the two TypeCodes are both object references, return true if the
    their RepositoryIds are the same.

    e) If the two TypeCodes are both structs, exceptions, unions, enums or
    aliases, and they have the same RepositoryId, then equivalent() returns
    true. Note in this case that member TypeCodes are not compared.

    f) If either or both of the TypeCodes have an empty RepositoryId, then
    equivalent() falls back to a structural comparison, and returns true if
    all members of the two TypeCodes also are equivalent(). This case will
    only occur when interoperating with an older ORB that does not yet
    require RepositoryIds as mandatory for these TypeCodes. Note that the
    name() and member_name() fields are not used in this comparison.

    g) Otherwise, equivalent() returns false.

    6. The ORB uses TypeCode::equivalent for all internal TypeCode
    comparisons, such as for supporting any (and thus DII and DSI) and
    DynAny.

    7. If the programmer needs to distinguish between a type and/or
    different aliases of that type, he can call TypeCode::id() and compare
    the RepositoryIds.

    8. All DynAny insert & get operations do not consider aliases as
    significant. The type() operation however, will return the TypeCode
    with all of the aliases intact, including type() from any DynAny member
    components. DynAny::assign() and DynAny::from_any compare the internal
    TypeCode of the DynAny with the TypeCode of its argument using
    TypeCode::equivalent() and raise Invalid if equivalent() returns false.

    9. The TypeCode::equal() operation is not used internally by the ORB
    and is deprecated.

  • Reported: CORBA 2.2 — Wed, 1 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Description of Wide String type

  • Legacy Issue Number: 1612
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Null termination is a marshalling and language mapping issue and should not
    appear as part of the semantic description of the IDL type. It should be
    completely valid for a language with a native wide string type to handle the
    varying length nature of the wide string with or without use of null
    termination and certainly without exposing it to the user. Therefore, the
    description of the wide string type in 3.8.3 should not mention null
    termination.

    Also the syntax should be included.

  • Reported: CORBA 2.2 — Mon, 29 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

name scoping issue

  • Legacy Issue Number: 1587
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the course of a discussion Philippe Gautron pointed out to me that in
    ISO-C++, the scope of a class begins with its declaration, and hence a
    member or type declaration in the class may not introduce the same name
    as that of the class, exception being constructors of the class.
    Analogous rules apply to struct and namespace. When this principle is
    extended to the case insensitivity of IDL a consequence is that

    interface I

    { void i(); }

    ;

    is illegal as is:

    module M {
    interface m

    {....}

    ;
    };

    The basic rule is that the name of the scope, if it has one is
    implicitly inserted into the scope and hence cannot be reused for other
    purposes in that scope. Given that IDL has to be mapped to C++ this
    seems like an eminently reasonable restriction. However, I could not
    find this explicitly stated anywhere. Do y"all feel this is reasonable?
    If so, and if it is indeed not mentioned then I think we should add a
    line or two in 3.13 clarifying this?

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDL struct issue

  • Legacy Issue Number: 1585
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL structs are specified to have "one or more" members rather than
    "zero or more".

    Whilst it might be argued from a stylistic point of view that an empty
    struct is of limited use, of should be avoided, there are places where
    it may be desirable to specify a placeholder struct for later expansion,
    or for machine generated code where there happens to be nothing to fill
    the struct with.

    I can see no compelling technical reasons for requiring that a struct
    contain at least one member, so I propose that the grammar be revised to
    alow for a struct with zero members.

    Such a change would not break any existing IDL.

  • Reported: CORBA 2.2 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type codes cannot describe all unions

  • Legacy Issue Number: 1545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Fix this by stating that member_label returns an Any containing
    a sequence of labels if a single member has more than label.

    Add a typedef to the TypeCode pseudo-IDL:

    typedef sequence<any> LabelSeq;

    A sequence of this type would be contained in the Any returned by
    member_label() if a member has multiple labels (this avoids changing the
    signature of member_label()).

    For the above union, the member_count() operation would return 2, not 5.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type code operations under-specified

  • Legacy Issue Number: 1542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 8-38:

    Member_count [sic] returns the number of members
    constituting the type.

    This is a little ambiguous and easily confused with the number of parameters.
    For clarity, I would suggest to add a sentence to make this clearer, e.g.
    "For example, the member count of a structure with three members is three."

    This would help to avoid confusion with parameters (if I am not careful,
    I might think the number is six, because a the three members of a structure
    are described by six parameters, or I might think that the number is nine,
    because a three-member structure has a total of nine parameters).

    The origin for the index to the member_name operation is never defined.
    Presumably, indexes start at zero? If so, this must be stated.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type code typos (as only one issue)

  • Legacy Issue Number: 1541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a few typos in the spec for type codes.

    Page 8-40:

    A structure with N members results in a tk_struct TypeCode with
    2N+1 parameters.

    This is no longer correct. Because of the Repository ID parameter that
    was added, this is now 2N+2.

    Similar fixes need to be applied to the text for unions (3N+3 parameters,
    not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by
    the text), and aliases (they have three parameters, not two).

    The text for tk_objref also needs updating, because it states that
    it has one parameter instead of two.

    Also, Table 7-1 for tk_objref should be updated because it is internally
    inconsistent.

  • Reported: CORBA 2.2 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typo in chapter 8

  • Legacy Issue Number: 1537
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Table 8-1 on page 3-39 of the CORBA spec contains a typo.
    "tx_fixed" should be "tk_fixed".

  • Reported: CORBA 2.2 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Does the DII support the standard object operations?

  • Legacy Issue Number: 1422
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are two types of standard operations: ones that are transmitted
    over the wire, and ones that are not. Now it seems reasonable to
    support the over-the-wire operations via the DII, such as "is_a",
    "non_existent", "get_interface" and "get_implementation" (obsolete), but
    what about the ones that don"t go over the wire:

    hash
    is_equivalent
    get_policy
    get_domain_managers

    I would guess that the DII should not support these operations, but the
    spec does not explicitly say that. So, should we add a statement to the
    DII part of the spec that an attempt to invoke these non-over-the-wire
    operations should raise BAD_OPERATION?

  • Reported: CORBA 2.2 — Tue, 2 Jun 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (050

  • Legacy Issue Number: 1398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - Section 8.8 page 8-55: change "element type" to "element_type" in
    operation create_sequence_tc.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (04)

  • Legacy Issue Number: 1397
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - Section 8.8 page 8-53: add "," after "tk_except" in definition of TCKind.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (03)

  • Legacy Issue Number: 1396
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - Section 8.8 page 8-48: remove incorrect "};" between "create_array" and
    "create_fixed".

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in Specification (02)

  • Legacy Issue Number: 1395
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - Section 8.8 page 8-47: need forward declarations of WstringDef and
    FixedDef before use on page 8-48. Again, it would seem that they were
    left out of the list of forward declarations on 8-47.

  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in IR IDL in spec (01)

  • Legacy Issue Number: 1394
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following problems appear in the 2.2 spec (98-02-23) and the IDL
    summary extracted from it (98-03-01.idl).

    • Section 8.8 page 8-45: need forward declaration of ExceptionDef, i.e.,
      "interface ExceptionDef" before use on page 8-47. There are a number of
      forward declarations in the middle of 8-45 that would seem to be the
      logical place for it.
  • Reported: CORBA 2.2 — Wed, 20 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

/ in prefix pragma?

  • Legacy Issue Number: 1241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: currently, #pragma prefix is completely unconstrained and can contain
    any character. This includes potentially troublesome things such as space
    and "/", or non-printing characters.

    I would suggest to define a syntax for #pragma prefix. In particular, I think
    that "/" should be forbidden in a prefix. This is because otherwise, given
    a repository ID, I cannot work out where the prefix ends and the scoped
    name starts. In addition, things that cannot normally be part of file names
    or identifiers should probably be forbidden as well, otherwise we could
    get problems with things like the class path in Java.

  • Reported: CORBA 2.2 — Mon, 27 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Versioning by the back door?

  • Legacy Issue Number: 1164
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"ve always been under the impression that CORBA does not have versioning.
    it looks like we
    actually do have versioning. Could someone please let me know what
    the correct interpretation should be? Has this versioning stuff sort
    of quietly snuck in via the back door?

    I find this section of the spec particularly stunning because a few pages
    earlier, it says about #pragma directives:

    An IDL compiler must eithe rinterpret these annotations
    as specified, or ignore them completely.

    So, on the one hand, we can happily ignore #pragma, and a few pages
    later, we go and add semantics to the version pragma?!

  • Reported: CORBA 2.2 — Wed, 22 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

GIOP typo, section 4.2 (page 4.4) of CORBA 2.2

  • Legacy Issue Number: 1160
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.2 (page 4.4) of the corba 2.2 spec defines a "non_existent" operation
    on CORBA::Object. In Section 13.4.1 (page 13-23) it sates that the operation
    name for such a request is encoded as the string "_not_existent". This latter
    string looks like a typo, and we propose to change this (on page 13.23) to
    "_non_existent".

  • Reported: CORBA 2.2 — Mon, 20 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    :Object. In Section 13.4.1 (page 13-23) it sates that the operation

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Domain Manager related specification shortcomings (03)

  • Legacy Issue Number: 1155
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) There is no way at present to implement the
    Object:get_domain_managers operation in an interoperable fashion. To fix
    this it seems a new GIOP message needs to be defined to carry the
    implicit get_domain_managers operation. There of course may be other
    ways to fix this. Some of the submitters of the original security spec
    saw domain managers as replicated objects such that a replica of it was
    present in each ORB instance where there was an object belonging to that
    domain manager was instantiated, thus relegating the problem of getting
    the domain manager information to the replication mechanism. Well, the
    hoped for replication facility has not happened yet and there is no
    other way to implement this interoperably. This needs to be fixed.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    get_domain_managers operation in an interoperable fashion. To fix

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Semantics and standard exceptions

  • Legacy Issue Number: 1146
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec lists the standard exceptions in section 3.15.1.

    However, for many of these, there are no semantics specified anywhere.
    Instead, for the majority of standard exceptions, the only "semantics"
    are what is in the comments in section 3.15.1.
    We badly need an explanation of which standard exception indicates what
    error condition in the spec, otherwise we"ll never get agreement on which
    exception means what...

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Forward declarations and inheritance

  • Legacy Issue Number: 1145
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL spec explains forward declarations at the end of section 3.5.2.
    However, it does not make the following illegal:

    interface base; // Forward declaration

    interface derived: base

    { // Should be illegal // ... }

    ;

    interface base

    { // ... }

    ;

    The problem here is that a forward-declared interface is used as a base
    interface before the definition for that interface has been seen.
    In the absence of further words in the spec, this is legal, but clearly,
    it should be illegal (otherwise, I can"t use a single-pass compiler).

  • Reported: CORBA 2.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typos in parameter passing rules

  • Key: CPP11-248
  • Legacy Issue Number: 1137
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 20-74 of orbos/98-01-11 shows the tables for the parameter passing
    rules. There are six notes on page 20-76 that are meant to be referenced
    by the tables. However, those references are no longer correct.

    For example, the array parameter passing rules in table 19-2 (should be
    table 20-2) have the index 2, but note 2 actually refers to the rules
    for passing references.

    Notes 3 to 6 are no longer referenced by the table, but should be.

  • Reported: CPP 1.0b2 — Mon, 30 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Indentation on page 4-4

  • Legacy Issue Number: 1094
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: interface Object on page 4-4 shows:

    interface Object

    { ImplementationDef get_implementation(); InterfaceDef get_interface(); boolean is_nil(); Object duplicate(); void release(); boolean is_a(...); boolean non_existent(); boolean is_equivalent(...); unsigned long hash(...); <====== // ... }

    ;

    The first four declarations use no indentation, the fifth declaration
    uses one indentation level, and the final four declarations use a different
    indentation level. This could be tidied up a bit.

  • Reported: CORBA 2.2 — Sun, 22 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorial issue, chapter 8

  • Legacy Issue Number: 1091
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the recap IDL at the end of chapter 8, there is a missing comma after
    the tk_except enumerator in the definition of TCKind.

  • Reported: CORBA 2.2 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ORB_init

  • Legacy Issue Number: 1088
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 4-9 of CORBA 2.2:

    ORBid strings other than the empty string are intended to be used
    to uniquely identify each ORB used within the same address space
    in a multi-ORB application.

    I don"t believe this is possible, mainly because the language mappings
    do not permit multiple ORB run-time libraries to be linked into the same
    address space.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDl "module" construct - IDL files

  • Legacy Issue Number: 1087
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears that the IDL concept of a module is tightly bound to
    the storage of IDL statements in files. In other words, it does not
    seem to be possible to distribute IDL statements in the same logical
    module across multiple files. Consequently, few people use the
    concept, and name collisions occur sooner or later when trying to
    integrate systems that have not been developed by only one group.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

How to deal with object identity

  • Legacy Issue Number: 1086
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m not quite sure where this should go, but there should be an explicit
    statement somewhere in the CORBA descriptions that states how to deal
    with object identity with respect to subscribe/unsubscribe schemes.

    The (language/CORBA/etc independent) pattern
    interface SomeSender

    { void addSomeListener( in SomeListener theListener ); void removeSomeListener( in SomeListener theListener ); ... }

    is very commonly found, and as far as I understand it (I might be wrong,
    but if so, it needs to be documented that this would be incorrect),
    SomeListener actually needs to implement a "is_identical( Object )"
    operation that would be called by the removeSomeListener() operation
    in order to find out which of the registered listeners should be removed.

  • Reported: CORBA 2.2 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Typo in type code section (13.3.4)

  • Legacy Issue Number: 1074
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 13-13, CORBA 2.2:

    A "simple" parameter list has a fixed number of fixed length entries,
    or a single parameter which is has its length encoded first.

    This should probably be

    ... single parameter which has is length encoded first.

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Fixed point constants issue

  • Legacy Issue Number: 1068
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 3-20 of CORBA 2.2:

    A fixed-point literal has the apparent number of total and
    fractional digits, except that leading an trailing zeros are
    factored out, including non-significant zeros before the decimal
    point. For example, 0123.450d is considered to be fixed<5,2> and
    3000.00 is fixed<1,-3>.

    Apart from the fact that 3000.00 is not a fixed point constant literal,
    I"m confused about something else...

    If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>.

    These rules result in

    3000.00d being fixed<1,-3>
    BUT
    3000.01d being fixed<6,2>

    This doesn"t seem to make sense. If I bother to write the trailing zeros,
    surely I have a reason, namely, that I mean to use that scale. In other words,
    I think that

    3000.00d should be fixed<6,2>
    and
    3000.0000d should be fixed<8,4>

    Why are fractional trailing zeros thrown away but fractional trailing
    non-zeros retained?

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Wide character and wide string literals

  • Legacy Issue Number: 1067
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.2.5 on page 3-9, 2nd para says:

    Wide character and wide string literals are specified exactly
    like character and string literals. All character and string
    literals, both wide and non-wide, may only be specified
    (portably) using the characters found in the ISO 8859-1 character
    set, that is interface, names, operation names, type names, etc., will
    continue to be limited to the ISO 8859-1 character set.

    • The first part says that wide character literals and wide string literals
      are to be specified exactly like character and string literals.

    This seems to be impossible - if they were exactly the same, there would
    be no point in having them... At any rate, the sentence seems to
    imply that I must restrict myself to ISO Latin-1 characters in
    wide literals.

    • The second part then says that wide literals are restricted to 8859-1,
      but that interface names (etc.) will continue to be limited to 8859-1.

    Now what is that supposed to mean? Interface names have always (and
    incorrectly) been limited to 8859-1. Nothing has changed. Am I to
    imply then that the sentence was meant to suggest that wide literals
    can actually contain wide characters other than 8859-1?

    This paragraph simply doesn"t make sense as it stands.

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type of fixed point quotients

  • Legacy Issue Number: 1071
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as:

    fixed<(d1-s1+s2) + Sinf, Sinf>

    I"m having a problem with this: The type of the result cannot be known
    at compile-time because it depends on the actual values.

    This differs from the add, subtract, and multiplication operators,
    where the result type can be determined statically.

    There is a C++ mapping problem too. The C++ mapping uses a template
    type for fixed point, where the digits and the scale are template parameters
    (i.e. must be compile-time constants).

  • Reported: CORBA 2.2 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Fixed point constant typo in 2.2

  • Legacy Issue Number: 1066
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.7.2 of CORBA 2.2 contains an error on page 3-20, last para:

    For example, 0123.450d is considered to be fixed<5.2> and
    3000.00 is fixed<1,-3>.

    This is in conflict with section 3.2.5 on page 3-9, last para:

    A fixed-point decimal literal consists of an integer part, a
    decimal point, a fraction part and d or D. [ ... ]
    Either the integer part of the fraction part (but not both)
    may be missing; the decimal point (but not the letter d (or D))
    may by missing.

    So, it seems that the "3000.00" on page 3-20 really should be
    "3000.00d" or "3000.00D".

  • Reported: CORBA 2.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Marshalling is_equivalent

  • Legacy Issue Number: 1054
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.2 GIOP does not define a way to invoke is_equivalent on an object remotely

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close no change with above explanation

  • Updated: Fri, 6 Mar 2015 21:35 GMT

#pragma prefix issue

  • Legacy Issue Number: 999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How does the scope of #pragma prefix interact with #include? Find details in the corresponding archive

  • Reported: CORBA 2.2 — Fri, 13 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CORBA 2.2 - "native" and the interface repository

  • Legacy Issue Number: 992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Whilst implementing the POA I noticed that there were no extensions to
    the Interface Repository or TypeCodes to handle native types.

    The nett result appears to be that there is no way to express some of
    the POA interfaces in the Interface Repository. Obviously the native
    interfaces themselvse can"t be expressed, but nor can some of the IDL
    specified interfaces.

    e.g. ServantLocator has two operations (preinvoke and postinvoke) both
    of which have a Cookie listed as a parameter. There appears to be no way
    to generate a TypeCode for the Cookie (native) paramter and therefore no
    way to perform an InterfaceDef.create_operation to desribe either of
    preinvoke or postinvoke.

  • Reported: CORBA 2.2 — Thu, 5 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

union typecode

  • Legacy Issue Number: 811
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The label value corresponding to a default label should be
    designated explicitly either as an ignored field whose size equals the
    size for the discriminator type, as some value that does not coincide
    with another label value, as reserverd for future use, or as absent
    (Table 12-2 and page 12-16, "encoding the tk_union Default Case" of
    IIOP 2.1).

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CDR encoding of TypeCode names inconsistent with equal operation

  • Legacy Issue Number: 719
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name()

  • Reported: CORBA 2.1 — Wed, 10 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Duplicate of issue 665

  • Updated: Fri, 6 Mar 2015 21:34 GMT

OMG IDL prefix pragma

  • Key: CORBA21-90
  • Legacy Issue Number: 566
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

  • Reported: CORBA 2.0 — Thu, 22 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Description of constant expression semantics is unclear

  • Key: CORBA21-89
  • Legacy Issue Number: 564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Object terminal missing from IDL grammar

  • Key: CORBA21-88
  • Legacy Issue Number: 563
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

  • Reported: CORBA 2.0 — Thu, 1 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, closed in "97

  • Updated: Fri, 6 Mar 2015 21:34 GMT

WRONG_TRANSACTION

  • Key: CORBA21-87
  • Legacy Issue Number: 557
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    issue resolved, see revised text

  • Updated: Fri, 6 Mar 2015 21:34 GMT

OTS 1.1 specification changes

  • Key: CORBA21-86
  • Legacy Issue Number: 556
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

  • Reported: CORBA 2.0 — Mon, 28 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Interface Repository

  • Key: CORBA21-85
  • Legacy Issue Number: 542
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

  • Reported: CORBA 2.0 — Tue, 15 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

CORBA::Bounds and CORBA::TypeCode::Bounds

  • Key: CORBA21-84
  • Legacy Issue Number: 457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does Bounds have data members or not? At what scope should Bounds be defined? Given that Bounds exception is also used by Request interface, I suspect what is meant is CORBA::Bounds

  • Reported: CORBA 1.2 — Wed, 13 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

3.10.3 Raises Expressions

  • Key: CORBA21-83
  • Legacy Issue Number: 390
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would make iDL definition of an interface much more complete if they were permitted. X/Open would like OMG to consider permitting listing of Standard Exceptions in raises clauses.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Duplicate or Merged — CORBA 2.0
  • Disposition Summary:

    Duplicate of issue # 389...closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Do simple/anonymous types have repository IDs?

  • Key: CORBA21-82
  • Legacy Issue Number: 137
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do simple types like "long" have specified repository IDs? ("IDL:CORBA/long:1.0") How about anonymous types, like "sequence <long, 10>"?

  • Reported: CORBA 1.2 — Thu, 26 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    clarified, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Efficiency issue in C++ mapping

  • Key: CPP11-247
  • Legacy Issue Number: 91
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with the C++ mapping which requires excessive memory copying in order to be exception safe while constructing a return value.

  • Reported: CPP 1.0b1 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0b2
  • Disposition Summary:

    This issue was fixed by Portability Submission

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Exception as explicit parameter

  • Key: CORBA21-81
  • Legacy Issue Number: 87
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it permissible to declare an exception as an explicit parameter?

  • Reported: CORBA 1.2 — Sun, 18 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Remove user defined literal support

  • Key: CPP1111-24
  • Legacy Issue Number: 18660
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The fixed mapping uses operator"" and _fixed as user defined literal. This doesn't work with a C++ template, only with a class, so the usage of user defined literals should be removed

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The usage of operator”” and _fixed will be removed from the specification

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

Add namespace level swap

  • Key: CPP1111-23
  • Legacy Issue Number: 18656
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Everywhere where a specialization of std::swap is mentioned also mention the need for a namespace level swap

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Small typos in servant reference section

  • Key: CPP1111-20
  • Legacy Issue Number: 18536
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Two small typos in sectin 6.25.3:
    aks CORBA::weak_servant_reference<>
    to
    aka CORBA::weak_servant_reference<>

    Than
    Foo some_function()
    to
    Foo::some_function()

  • Reported: CPP11 1.0 — Fri, 8 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Change text as proposed

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

Replace all _downcase/downcase with narrow

  • Key: CPP1111-19
  • Legacy Issue Number: 18527
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    As done for the interfaces already, we propose to remove _downcase/_narrow for abstract/valuetype and only support IDL::traits<>::narrow. In the spec this has to be updated in text and code.

  • Reported: CPP11 1.0 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Relax constructor argument rules

  • Key: CPP1111-22
  • Legacy Issue Number: 18655
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Currently the std::array doesn't have an efficient move constructor, passing an array by value to the constructor of a valuetype/struct isn't efficient. Instead of adding an exception to the spec we propose to relax the spec so that it just mentions that the constructor must be there, but not that arguments have to be passed by value, that is up to the implementor to decide

  • Reported: CPP11 1.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We remove the restriction that the arguments have to be passed by value to the
    constructor of a structured type. This is a way implementations can deliver optimizations
    if needed. This change will not impact any user code in terms of portability

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

Remove final for structured types

  • Key: CPP1111-21
  • Legacy Issue Number: 18578
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The mapping defines the mapping of IDL struct/union to a final class. The work "final" should be removed from the IDL to C++11 language mapping because it will prevent the implementation of the DDSXTypes Type Extensibility.

  • Reported: CPP11 1.0 — Fri, 22 Mar 6013 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

typo exists in section 6.21

  • Key: CPP1111-2
  • Legacy Issue Number: 18385
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The following typo error exists in section 6.21:

    Following text in spec
    ... TypeCode reference constants, <type> refer to the local name of the type ...
    should be
    ... TypeCode reference constants, <type> refers to the local name of the type ...

    Refs #2877

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The V1.0 spec doesn’t have this typo, so closing this with no change
    Disposition: Closed

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

RFP requirement on DDS-PSM-Cxx compatibility is violated

  • Key: CPP1111-1
  • Legacy Issue Number: 18149
  • Status: closed  
  • Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
  • Summary:

    The current mapping for struct violates the RFP requirements that mandated compatibility with the DDS-PSM-Cxx. Areas of incompatibilities include the use of the C++11 array type and the use of move operators.

  • Reported: CPP11 1.0b2 — Wed, 10 Oct 2012 04:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    The revised submission explicitly mentioned that this requirement was not met because
    this is a C+11 language mappping, not focusing on C+03 which is the focus of the
    DDS-PSM-Cxx. Also in the mean time the DDS-PSM-Cxx has adopted the same
    mapping for arrays/enums and mentions move semantics when C++11 support is
    available. Given the fact this is a C++11 language mapping this issue has been closed
    without a change.
    Disposition: Closed, no change

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

Lack of factory reference type

  • Key: CPP1111-3
  • Legacy Issue Number: 18386
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification defines IDL::traits<A>::factory_type as C++ trait for getting the base C++ class for the factory. It does lack a trait for passing a reference for a certain factory around.

    To be added:
    For a valuetype A, a strong reference to its valuetype factory is known as IDL::traits<A>::factory_ref_type. The weak object reference to its valuetype factory is known as IDL::traits<A>::weak_factory_ref_type.

    Refs #2727

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

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

Early detection of bound violation on bounded types

  • Key: CPP1111-14
  • Legacy Issue Number: 18453
  • Status: closed  
  • Source: Airbus Group ( Mr. Oliver M. Kellogg)
  • Summary:

    Addressee: IDL to C++11 1.1 RTF <idl2cpp11-rtf@omg.org>
    Nature: Enhancement
    Summary: Early detection of bound violation on bounded types

    In the IDL to C++11 Mapping v1.0 (formal/13-02-04), the sections
    6.9, 6.10, and 6.11 describe the mapping for string, wstring, and
    sequence types, respectively. These sections also address the bounded
    variant of those types:

    " Implementations must (at run time) detect attempts to pass a
    [string|wstring|sequence] value that exceeds the bound as a parameter
    across an interface. It must raise a BAD_PARAM system exception to
    signal the error. "

    In practice, the point at which such a value is passed into an interface
    method may be far away from the assignment causing a bound violation,
    which makes the error source hard to find.

    I propose doing a bound check not only at interface methods but also
    at the setter functions for struct, union, and valuetype members.

    The section quoted above could thus be extended as follows:

    " Implementations must (at run time) detect attempts to pass a
    [string|wstring|sequence] value that exceeds the bound as a parameter
    across an interface, or passed to a setter method of a struct, union,
    or valuetype. It must raise a BAD_PARAM system exception to
    signal the error. "

    Furthermore, the mapping standard does not define the bound check
    behavior for arrays and sequences of bounded types.
    IMHO the mapping standard should make explicit that the bound check
    shall be performed on each bounded-type element of an array or sequence.

    Example:

    // IDL
    typedef string<12> string12_t;
    typedef string12_t string_arr_t[2][3];
    typedef sequence<string12_t, 4> string_seq_t;
    struct struct_t

    { string_arr_t sarr; string_seq_t sseq; }

    The sarr() and sseq() setter methods generated for struct_t should
    iterate over their input parameter and perform the bound check on
    each element. Similar checks should happen in the explicit constructor
    which accepts values for each struct member.

  • Reported: CPP11 1.0 — Wed, 13 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Adding the bounds check to the place where the bounded type is used leads to
    inconsistent behavior for users. After discussion we decided to map bounded types
    (string/wstring/sequence) to a distinct type and that this type could do a bounds check.
    The exact type doesn’t need to be standardized because bound types can only be used
    through a typedef in IDL and never are used directly by the programmer. Because the
    standard containers don’t have the concept of bounds enforcing a bound will be very
    hard to accomplish on all places.

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

std::ostream insertion underspecified

  • Key: CPP1111-13
  • Legacy Issue Number: 18433
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    The wording in 6.29 says

    "For each IDL type (T) of type: [..] an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, T);

    For all other types an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, const T&);"

    1) This wording is not clear in which namespace the operator<< overload shall be provided. It could be within the global namespace or within the namespace of type T.

    The prototype implementation that I have seen provides these operators in the global namespace which makes them behave irregular:

    The reason is that overloaded operators such as these IO inserters are found by argument-dependent name-lookup. The lookup will consider all declarations that are found at the point of usage and will look in the associated namespaces of the operands to find them. Consider the following example:

    #include <iostream>
    #include <vector>
    #include <iterator>

    namespace n {
    struct A {};
    }
    std::ostream& operator<<(std::ostream& os, n::A)

    { return os; }


    int main() { std::vector<n::A> v; std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout)); }


    This program will not compile, because the involved template cannot "see" the operator<< overload. TRhis is so, because it is provided in the global namespace, but the operands are in namespace std:: and namespace n, resp. Adding overloads to namespace std is not valid, therefore the only option is to add the operator<< overload to namespace n:


    #include <iostream>
    #include <vector>
    #include <iterator>


    namespace n {
    struct A {};
    std::ostream& operator<<(std::ostream& os, n::A) { return os; }

    }

    int main()

    { std::vector<n::A> v; std::copy(v.begin(), v.end(), std::ostream_iterator<n::A>(std::cout)); }

    This works and lets the ostream operator<< of A::n behave normally.

    This example was intended to demonstrate that the provided operator<< overloads should be provided in the same namespace as the declared mapped types from the IDL (that is within the IDL module). The wording in 6.29 should be clarified in that regard.

    2) The second part of above wording,

    "For all other types an ostream inserter with the following signature will be provided:

    // C++
    std::ostream& operator<<(std::ostream &, const T&);"

    can be read to be applicable for the arithmetic IDL types (bool, short, wchar_t, char, double, uint32_t, ...) or typedefs thereof, but that surely cannot be intended, because that would result in a compiler ambiguity when user code would include such a mapping header and would attempt to print such an arithmetic type on any std::ostream, e.g.

    #include <iostream>
    #include "some_idl.h"

    int main()

    { std::cout << 12; // Error, ambiguity }

    The wording in 6.29 should make clear that no operator<< overloads shall be provided for the basic data types or for typedefs thereof.

  • Reported: CPP11 1.0 — Wed, 6 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    We had a detailed looked at the argument dependent lookup and what would technically
    be feasible. We also had users that wanted to define their own ostream operators and
    our spec defined methods were conflicting with that approach. Given that this feature
    was mostly focused on debugging systems, we decided to remove this section
    completely from the specification

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

Add missing implicit widening to any

  • Key: CPP1111-5
  • Legacy Issue Number: 18388
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The description for Any lacks the support for implicit widening as it was available with the C++ mapping. Proposal is to add implicit widening to section 6.16.3. The following text is proposed to be added:

    Any object reference, valuetype reference, or abstract references has to extractable as its base reference type from an Any.

    Also in the last sentence of 6.13, any as bold should be Any with a capital A

    Refs #2873

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed with the remark that 6.13 should be 6.17.3 and it
    talks about the Any C++ class, not the any IDL type.

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

Add support for _this on local objects

  • Key: CPP1111-4
  • Legacy Issue Number: 18387
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    With the new IDL2C+11 mapping we can't create object references with new, we have to use the CORBA::make_reference<> factory method. In a servant we can use _this to get a reference to itself, but that is not available for local objects. With the old C+ binding people could just use the C++ this to get a _ptr to a local object, but that is not possible with the C++11 binding in general.

    Proposal is to add to 6.24:

    In order to get an object reference referring to an already created local object the _this() method must be used.

    In the code part add as method

    class LocalIF

    { protected: IDL::traits<LocalIF>::ref_type _this (); }

    ;
    Refs #2804

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

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

Missing specification of assignment operators of valuetypes

  • Key: CPP1111-12
  • Legacy Issue Number: 18418
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Section 6.17.2 is titled "Constructors, Assignment Operators, and Destructors" but does not say anything about assignment operators albeit the title promises to do so.

    The following examples seems to indicate that both assignment operators are supposed to be deleted. This should be spelled out.

    It also seems as if the maiing for interfaces as of 6.6 is intended to create class types with deleted copy/move assignment operators. This should also be made more clear.

  • Reported: CPP11 1.0b2 — Tue, 5 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Meaning of (u)intN_t types unclear

  • Key: CPP1111-11
  • Legacy Issue Number: 18406
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Section 6.5 (Table 6.1) loosely describes that the OMG IDL integer types are mapped to "a basic C++11 type" denoted by

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

    It doesn't really say, what these typedefs are supposed to be. Furthermore 6.5 (Table 6.2) describes the names

    int16_t int32_t int64_t uint16_t uint32_t uint64_t uint8_t

    as "keywords from the C++11 specification (ISO/IEC 14882:011)".

    Surely there are no such keywords in C+11 (nor in C11 or C99) and never had been. What C+11 inherits from the C99 library specification are the typedefs

    std::int16_t std::int32_t std::int64_t std::uint16_t std::uint32_t
    std::uint64_t std::uint8_t

    from header <cstdint>, but those are not keywords and they are library components that belong to namespace std. I think that the specification of the basic integer type mapping (6.5) intends to refer to these typedefs from <cstdint>, but this should be made clear in 6.5.

    Also, section 6.30 should not declare them as C+11 keywords, even though these names need to be protected by a cxx prefix as described by 6.2. Presumably a better name is needed (e.g. "protected C+11 names" or some such)

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Fixed type mapping should provide (explicit) operator bool

  • Key: CPP1111-10
  • Legacy Issue Number: 18405
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    Given the specification of the class template Fixed provides

    operator int64_t () const;
    operator long double() const;

    and

    bool operator!() const;

    This allows to test some Fixed instantiation within a boolean context as in a useful way as follows:

    typedef IDL::Fixed<5,2> F;
    F f = ...;
    if (!f)

    { ... }


    But the similar inverse form


    if (f) { ... }

    will cause an ambiguity error between the two conversion functions to int64_t and long double. User code is required to write the obfuscated form

    if (!!f)

    { ... }

    to realize the same thing. This is unfortunate and there is a simple means to solve this problem: The specification should add

    explicit operator bool() const;

    to the class template synopsis with the same semantics as negating operator!

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed. Also during the discussion it was proposed to add a
    namespace level to_string

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

Invalid struct initialization example

  • Key: CPP1111-9
  • Legacy Issue Number: 18404
  • Status: closed  
  • Source: gmail.com ( daniel.kruegler@gmail.com)
  • Summary:

    The example in the middle of the page starts with:

    // C++
    S s =

    {10};


    but the struct mapping (6.13.1 p.23) clearly says that "an explicit constructor accepting values for struct each member" shall be provided. Above initialization context is a copy-initialization context and would require a non-explicit constructor. The example should be fixed to use a direct-initialization context instead, either:


    // C++
    S s{10}

    ;

    or

    // C++
    S s = S

    {10}

    ;

  • Reported: CPP11 1.0b2 — Fri, 1 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

CORBA::Exception should not use std::string type for name and repo_id

  • Key: CPP1111-15
  • Legacy Issue Number: 18463
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    CORBA::Exception should not use std::string type for name and repo_id for 2 reasons:

    1. C++ standard conformance; member types like std::string are discouraged because their constructors may throw exceptions where std::exception and derivatives are expected not to throw exceptions themselves
    2. (minor) performance; using std::string these member values are unnecessarily copied while they immutable constant strings only ever read, never mutated

    Changing the members to const char* values makes CORBA::Exception and the CORBA::SystemException classes optimal and c++ standard conformant.

    This will not be the case for CORBA::UserException derivatives as these may have IDL defined attributes having IDL defined types which may definitely throw exceptions. However the ORB should be expected to handle situations where creating user exceptions unexpectedly throws another exception.

    Refs #2958

  • Reported: CPP11 1.0 — Mon, 18 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Update exception as proposed. During the discussion also it was proposed to define
    what() as noexcept which also has been done

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

Remove _narrow methods

  • Key: CPP1111-8
  • Legacy Issue Number: 18392
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Given interface T the specification defines IDL::traits<T>::narrow as a way to narrow to T. As convenience it also defined T::_narrow. The issue is that T::_narrow is implicitly linked to IDL::traits<T>::narrow and can cause confusion and possible misuse when other traits are added for more specific traits. We propose to remove T::_narrow from the specification completely, users must just use IDL::traits<T>::narrow

  • Reported: CPP11 1.0b2 — Tue, 29 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Extend IDL type traits for template meta programming

  • Key: CPP1111-7
  • Legacy Issue Number: 18390
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification defines IDL::traits<> as type trait, but uses it only for reference types.

    We propose to extend IDL::traits<> as generic type trait for IDL2C++11. This type trait delivers traits with information coming from IDL.

    For example object reference traits it can also deliver local and abstract as traits, which are booleans that indicate whether the IDL type was local or abstract.

    For sequence we can add traits indicating the type of the element and in case of bounded sequences the bound.

    The proposal is to add a new paragraph which describes the IDL type traits that are all available as part of IDL::traits<> for a specific IDL type.

    Ref #2802

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Extending the IDL::traits<> with more types for template meta programming will be useful
    for the users that would like to program C++11 templates using the IDL defined types.
    Therefor a new set of type traits will be added to the specification.

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

Use () instead of (void)

  • Key: CPP1111-17
  • Legacy Issue Number: 18500
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification uses in some examples like in 6.13.1 the construct "(void)" for a method with no arguments. This is old style, it should use "()"

  • Reported: CPP11 1.0 — Mon, 25 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Minor typos

  • Key: CPP1111-16
  • Legacy Issue Number: 18498
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    2.1 refers to ISO/IEC 14822:2011 (which should be 14882:2011)

    6.30 instead refers to ISO/IEC 14882:011 (again should be 14882:2011)

    the table in 6.30 contains typos (alinas, alineof, constrexpr), names
    that aren't keywords (int32_t, ...) and misses some keywords
    (noexcept, char16_t, char32_t).

  • Reported: CPP11 1.0 — Sun, 24 Feb 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Introduce trait for local interface base type

  • Key: CPP1111-18
  • Legacy Issue Number: 18523
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The specification uses IDL::traits<T> for everything related to interface T, but for a local interface we just use T as base class. Proposal is to use IDL::traits<T>::base_type as base type trait for the local object implementation. This makes everything related to interfaces available through IDL::traits<T>

  • Reported: CPP11 1.0 — Mon, 4 Mar 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this issue as proposed

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

Font issue

  • Key: CPP1111-6
  • Legacy Issue Number: 18389
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 6.25.6, in the line:

    This guarantees that the POA skeleton class inherits only one version of each operation, and also allows optional
    inheritance of implementations. In this example, the implementation of interface B reuses the implementation of interface
    A:

    The font of A should also be IDL type just as B

  • Reported: CPP11 1.0b2 — Wed, 23 Jan 2013 05:00 GMT
  • Disposition: Resolved — CPP11 1.1
  • Disposition Summary:

    Accepting this addition as proposed

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

We only need one COBOL Data Division model

  • Key: CWM11-93
  • Legacy Issue Number: 4834
  • Status: closed  
  • Source: Deere & Company ( Dave Smith)
  • 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].

    The primary purpose of the COBOL DATA DIVISION metamodel extension package
    in CWM is to allow the structure of DATA DIVISIONs to be captured so that
    their usage of other model elements (such as RecordDefs and Fields) can be
    modeled. This allows definition of files and databases created by COBOL
    programs as well as direct support for tools that attempt to track the
    lineage and determine the impact of proposed changes to COBOL application
    programs. The metamodel does not, however, provide sufficient structure to
    support tools that want to capture the structure of a DATA DIVISION source
    into a CWM repository and then be able to faithfully reproduce the source on
    demand.

    The COBOL DATA DIVISION metamodel extension also serves as an example of
    the use of the CWM Record metamodel. The CWM Record package is intended as a
    foundation upon which many record-oriented programming languages can be
    described. The COBOL Data Division extension package is provided as example
    demonstrating appropriate usage of CWM and UML classes in modeling the data
    structure representation parts of this and similar programming language
    environments."

    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 partial COBOL language meta models with different levels of
    detail. We only need one COBOL Data Division model.

  • Reported: CWM 1.0 — Mon, 18 Feb 2002 05:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see above

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

Logical-physical deployment modeling

  • Key: CWM11-92
  • Legacy Issue Number: 4518
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    DataManager contains a reference to the specific data (at the schema level) that is being managed but is constrained to be a DeployedComponent on a specific Machine. Though a DataManager refers to the Component that it 'instantiates' there is nothing associated with Component that allows one to record what data it can manage.

    For example, I would like to be able to create an element called "Peopleware Payroll Application" which references the relational schema for the application. This should be possible without having to say anything about its deployment onto specific machines.

    A separate but related point is the lack of support for physical databases. For example, When deploying an application I then want to be able to say what physical database it's using. The value of tracking this is for backup purposes etc, and the fact that actual WarehouseOperations will need to be applied to specific databases.

    Proposed resolution

    Add new class 'PhysicalDatabase' to SoftwareDeployment Model; this will inherit from Package and will have a many-to-many association 'LogicalPhysical' with Package, and be contained by Machine (as for DeployedComponent). [May want a subslcass of Dependency between PhysicalDatabases to represent replication/federation/partitioning. Or alternatively use containment by one 'abstract' PhysicalDatabase of others to represent this, though this does not allow the exact relationship to be expressed.]

    Move the 'dataPackage' reference from DataManager to SoftwareSystem. Add new many-to-many reference 'databases' to DataManager with target type PhysicalDatabase.

  • Reported: CWM 1.0 — Tue, 25 Sep 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see below

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

Diagram 8-7-3 missing lines

  • Key: CWM11-91
  • Legacy Issue Number: 4517
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Diagram 8-7-3 could be made a clearer by using associations (lines) in addition to the references.

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    No change is required. This diagram intends to represent inheritances only

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

Supplier and version underspecified

  • Key: CWM11-90
  • Legacy Issue Number: 4514
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Supplier and version of SoftwareSystem should be optional: they are not always known or relevant.

    The description for supplier should clarify whether it represents any/all of: a) the original developer (e.g. "Oracle"); b) the entity who sold the software to the organization (e.g. a reseller); c) the IT support group within the organization who deployed it for a particular set of business users.

    It would make more sense to model supplier as a reference to BusinessInformation::ResponsibleParty, since this would allow reuse, contact information and impact analysis ("supplier X has gone out of business, what have they supplied us?"). Version might also make sense on DeployedSoftwareSystem (at a logical/design level one might not care what the version is: but it might be required to record which version is actually deployed).

  • Reported: CWM 1.0 — Sun, 19 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see below

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

ExchangeRateValue init interface need information

  • Key: CURR11-47
  • Legacy Issue Number: 2392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The init() interface appears in the consolidated IDL Specifications portion
    of the document, but does not appear and is not documented or discussed in
    section 2.3.8.

  • Reported: CURR 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

IDL Changes to support date ranges on ExchangeRateValue

  • Key: CURR11-46
  • Legacy Issue Number: 2391
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Propose the addition of the following interface(s):

    void setDateRange(in CBO::Dtime beginDateTime,
    in CBO::Dtime endDateTime) – Sets the window in
    time over which the ExchangeRate instance is valid.
    CBO::Dtime getStartDate() – Returns the date and time at which
    the ExchangeRate took effect.
    CBO::Dtime getEndDate() – Returns the date and time at which the
    ExchangeRate is no longer valid.

    Will also need an appropriate exception to throw when the date
    range is attempted to be set and beginDateTime >= endDateTime. Do
    not think that the beginDateTime should be allowed to be equal to
    the endDateTime as that then means that the ExchangeRate is valid
    for zero seconds.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Correct interface symantics for createExchangeRate

  • Key: CURR11-58
  • Legacy Issue Number: 2403
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The createExchangeRate() and getExchangeRate() interfaces accept arguments
    sourceCurrencyMnemonic and targetCurrencyMnemonic. There is no mention in
    the document regarding how the component should react (e.g. throw an
    exception) if the passed arguments are the same mnemonic.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed issue, resolved by Currency 2 RTF

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

Correct Currency create method

  • Key: CURR11-57
  • Legacy Issue Number: 2402
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currency create(
    in wstring name,
    in wstring fractionName,
    in wstring mnemonic,
    in short numericCode,
    in wstring symbol,
    in wstring fractionSymbol,
    in short ratioOfFractionToWhole,
    in wstring description,
    in CBO::DTime introductionDate,
    in CBO::DTime expirationDate,
    in boolean isISO,
    in wstring ISOVersion,
    in StringCollection locales)

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Change the name of getStateIdentifier to issueStateIdentifier

  • Key: CURR11-52
  • Legacy Issue Number: 2397
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: getStateIdentifier() implies an accessor which it is not. Change name of
    the interface to issueStateIdentifier().

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Correct issues with CosObjectIdentity::IdentifiableObject in StateIDManage

  • Key: CURR11-51
  • Legacy Issue Number: 2396
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Use of CosObjectIdentity::IdentifiableObject as the interface for a
    stateIdentifier. There is a particularly concerning paragraph in v1.0 of
    the Relationship Service regarding the interface: “The value of this
    attribute [readonly attribute ObjectIdentifier constant_random_id] is not
    guaranteed to be unique; that is, another identifiable object can return
    the same value. However, if objects return different identifiers, clients
    can determine that two identifiable objects are not identical”.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed, no changes

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

Clarification on whether stateID manages session or state access

  • Key: CURR11-50
  • Legacy Issue Number: 2395
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In general the decision needs to be made as to whether a given
    stateIdentifier is used to indicate the boundaries of a session or a simple
    configuration, as it currently seems to attempt to support both. Whichever
    direction is chosen, all of the interfaces that accept a stateIdentifier as
    an argument should be revisited to ensure that the intent of the interface
    is still properly supported. e.g. Should the currency component still offer
    a “connectionless” interface to its consumers?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed, no action taken

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

Legal value ranges for numerics in ExchangeRateValue should be discussed

  • Key: CURR11-49
  • Legacy Issue Number: 2394
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can conversionFactor represent a value <= 0.0? I would think not. An
    exception should be thrown if the conversion factor is attempted to be set
    with a Ddecimal that represents a value <= 0.0
    The beginDateTime must be < endDateTime in the init() call correct? Throw
    an exception if this is not the case.
    The source and target currency mnemonics cannot be the same in the init()
    call correct? Throw an exception if they are.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Closed, no change. This issue is fixed by Issue 2393

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

Add validity checkign for StateIdentifier

  • Key: CURR11-53
  • Legacy Issue Number: 2398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add the boolean valid(in CosObjectIdentifier::IdentifiableObject
    stateIdentifier) interface. This must be included so that each interface
    that accepts a stateIdentifier can do validity checking against it before
    servicing the request.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed issue, resolved by Currency 2 RTF

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

what values are used to determine if a currency exists in CurrencyBook

  • Key: CURR11-54
  • Legacy Issue Number: 2399
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: addCurrency() will raise an exception “if the currency already exists in
    the CurrencyBook …”. There is no mention of what elements of a currency are
    required to determine if one “already exists”. What
    needs to be fully
    detailed are those Currency elements which must be used to determine
    uniqueness. e.g. mnemonic, numeric code, etc.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed, resolved by Currency 2 RTF

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

Clarify the areEquivelent interface of the CurrencyBook

  • Key: CURR11-55
  • Legacy Issue Number: 2400
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: areEquivalent() “determines whether the two passed-in Currency objects
    contain the same elements”. Again, what needs to be fully detailed are
    those Currency elements which must be to determine uniqueness. e.g.
    mnemonic, numeric code, etc.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed, resolved by Currency 2 RTF

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

Missing details on preconditions on the ExchangeRateValue

  • Key: CURR11-48
  • Legacy Issue Number: 2393
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Missing details on preconditions on the
    ExchangeRateValue interface as a whole

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Change get Currency to retrieveCurrency

  • Key: CURR11-56
  • Legacy Issue Number: 2401
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The getCurrency() method name lends the consumer to believe that it is
    simply an accessor method, which it is not. It is a searching method.
    Change the method name to retrieveCurrency() or something that indicates
    searching semantics.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed issue, resolved by Currency 2 RTF

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

stereotype reference is missing from ModelElement

  • Key: CWM11-82
  • Legacy Issue Number: 4431
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    In the Core package, the stereotype reference, that maps to the
    stereotype end of the StereotypedElement association, is missing from
    ModelElement. This is a result of an error in the construction of the final
    CWM 1.0 spec (the same error is associated with Issue #4408).

  • Reported: CWM 1.0 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    No change is required. The metamodel is less restrictive without the stereotype reference

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

taggedValue reference is missing from ModelElement

  • Key: CWM11-81
  • Legacy Issue Number: 4408
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    The taggedValue reference is missing from ModelElement, which existed in the CWM Adapted Specification. This is an error and must be corrected immediately. TaggedValue is a critical, light-weight extension mechanism and is used extensively in our implementation of CWM. Without the taggedValue reference on ModelElement, we will not be able to support CWM 1.0. (This is a revised write-up for issue #4408.)

  • Reported: CWM 1.0 — Tue, 24 Jul 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see below

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

provide an example of extending the Management packages

  • Key: CWM11-80
  • Legacy Issue Number: 4406
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    Volume 2 of the CWM Specification does not provide an example of extending the Management packages (Warehous Process and Warehouse Operation). It will be very useful to provide an example of extending these packages (and their dependent packages) based on IBM's DB2 Data Warehouse Center. This product has implemented the CWM Management packages and has demonstrated the need for such extensions as well as how they can be done.

  • Reported: CWM 1.0 — Tue, 17 Jul 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    Resolved by CWM 1.1 RTF

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

diagram named "CWM Package Dependencies" shows wrong dependency arrow

  • Key: CWM11-79
  • Legacy Issue Number: 4405
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    In the CWM .mdl file, the diagram named "CWM Package Dependencies"
    contains a dependency arrow showing that the Relational package depends on
    the SoftwareDeployment package. This dependency arrow is erroneous and
    should be removed (the dependency does not appear in the definitional CWM
    XMI file).

  • Reported: CWM 1.0 — Wed, 18 Jul 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    Resolved by CWM 1.1 RTF

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

Add description of isCurrency Active

  • Key: CURR11-42
  • Legacy Issue Number: 2387
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no description of isCurrentlyActive() and when/why it would return
    true vs. false. Since it is described in the same area as the
    introduction/expiration date, does it simply perform a check to see if the
    current system time falls between the introduction and expiration
    date/times?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed , resolved by Currency 2 RTF

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

MoneyValue init interface need information

  • Key: CURR11-44
  • Legacy Issue Number: 2389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The init() interface appears in the consolidated IDL Specifications portion
    of the document, but does not appear and is not documented or discussed in
    section 2.3.7.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Add mechanism to create Money instances for moneyValue

  • Key: CURR11-43
  • Legacy Issue Number: 2388
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: There is no mechanism to create Money instances via a
    factory/type manager method.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF, close

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

exception semantics for MoneyValue

  • Key: CURR11-45
  • Legacy Issue Number: 2390
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no descriptive text stating why an FbcException would be raised
    when calling init(), [gs]etCurrencyMnemonic(), or [gs]etValue().

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Specify meta-model & XMI parameters for CWM XMI formats

  • Key: CWM-1
  • Legacy Issue Number: 3899
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    As of XMI 1.1, an XMI format depends on both the input MOF meta-model(s)
    AND some other parameters.

    The CWM specification should state what XMI parameters have been used to
    generate the CWM / XMI interchange formats. In particular, it should
    specify:

    1) what XML namespaces were used

    2) what (if any) "domain data type metamodels" were used, and what
    they are

    3) any custom data value <-> XML string encoding rules used, and

    4) whether the format supports "incomplete models".

    There may be some other XMI parameters that I haven't discovered yet.

    Finally, the CWM spec or an appendix should include the definitive CWM
    meta-model expressed as a MOF / XMI document.

    Without this information, it is difficult for someone other than the
    CWM submitters to instantiate CWM repositories and CWM / XMI interchange
    software.

  • Reported: CWM 1.0b1 — Fri, 22 Sep 2000 04:00 GMT
  • Disposition: Resolved — CWM 1.0
  • Disposition Summary:

    resolved

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

Supplied Data for ISO Locales in MoneyFormatter needs to be discussed

  • Key: CURR11-74
  • Legacy Issue Number: 2775
  • Status: closed  
  • Source: Anonymous
  • Summary:

    : Need explanation that the ISO locale and it's associated format data will be provided by the vendor supplying the implementation.

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Change name of CBO::DAmountOfTime interface to CBO::AmountOfTime

  • Key: CURR11-73
  • Legacy Issue Number: 2428
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: Change name of CBO::DAmountOfTime interface to
    CBO::AmountOfTime

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    :AmountOfTime

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

Value types need state

  • Key: CURR11-76
  • Legacy Issue Number: 2886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The value types in FbcCurrency (Currency, Money and ExchangeRate) need
    state added to them as defined by Objects By Value.

  • Reported: CURR 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Add clarification on formatting string in MoneyFormatter

  • Key: CURR11-75
  • Legacy Issue Number: 2779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Need clarification on formatting in MoneyFormatter. Can literal text be added to the formatting string, or is it strictly pattern based? If literal text cannot be added, add text to indicate the formatting string must contain only pattern characters.

  • Reported: CURR 1.0 — Wed, 30 Jun 1999 04:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Fixed in issue 2409

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

Optimize Instance data values

  • Key: CWM11-89
  • Legacy Issue Number: 4482
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Instances (hence MultiDimensional) metamodel is very wasteful
    in requiring a separate DataValue object for each simple string slot value:
    this in effect doubles the number of objects for value-oriented schemas such
    as Dimension definitions (in MultiDimensional where DataValue is inherited
    into MemberValue). This is a problem for XMI files and their processing, but
    even more so for repository implementations which tend to have management
    overheads associated with each object. Moreover these DataValue objects end
    up being directly contained in the MemberSet for the Dimension, which surely
    was not the intention. This means that when navigating from the Dimension to
    process its Members one also has to filter out a large number of these
    unwanted Data/MemberValue objects.

  • Reported: CWM 1.0 — Fri, 10 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see below

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

Attribute.initialValue incorrectly implemented as mandatory.

  • Key: CWM11-88
  • Legacy Issue Number: 4475
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The XMI representation of the CWM metamodel does not implement the specification for the initialValue attribute of the Core.Attribute class: in the specification (section 7.3.2.1 on p7-71) it clearly states the "multiplicity: zero or one"). However in the XMI file the lower bound is 1. Note: the lower bound of 0 is consistent with the UML metamodel.

    The impact is that,despite the DTD not being affected, XMI imports fail when any subclass of Attribute (see below IDL changes for a list) does not specify an initialValue Expression.

    This affects the XMI file, the Rose model, and the IDL. It does not affect the DTD since DTDs do not reflect attribute multiplicity.

    Proposed resolution: Update the CWM XMI file, document ad/01-02-03 to change the value of Core.Attribute.initialValue.multiplicity.lower from 1 to 0.

    Update the CWM Rose model, document ad/01-02-07 for attribute initialValue of Core:Attribute to change the value of the tag 'rose2mof.multiplicity' from "1" to "0..1".

    Update the following in the CWM IDL files, document ad/01-02-06: In core.idl change the declaration of Attribute and its class proxy to:

    typedef sequence<Expression> ExpressionBag; interface AttributeClass : StructuralFeatureClass

    { readonly attribute AttributeSet all_of_type_attribute; readonly attribute AttributeSet all_of_class_attribute; Attribute create_attribute ( in Core::Name name, in VisibilityKind visibility, in ScopeKindBag owner_scope, in ChangeableKind changeability, in MultiplicityBag multiplicity, in OrderingKindBag ordering, in ScopeKindBag target_scope, in ExpressionBag initial_value) raises (Reflective::MofError); }

    ; interface Attribute : AttributeClass, StructuralFeature

    { Expression initial_value () raises (Reflective::NotSet, Reflective::MofError); void set_initial_value (in Expression new_value) raises (Reflective::MofError); void unset_initial_value () raises (Reflective::MofError); }

    ; // end of interface Attribute

    And in the following files and the following class proxies change the initial_value parameter of the 'create_x' constructor to be of type Core::ExpressionBag rather than Core::Expression:

    Multidimensional.idl: DimensionedObjectClass Olap.idl: MeasureClass Record.idl: FieldClass, FixedOffsetFieldClass Relational.idl: ColumnClass CML.idl: XMLAttributeClass, ElementTypeReferenceClass, TextClass InformationReporting.idl: ReportAttribute DataTypes.idl : UnionMemberClass DataMining.idl: MiningAttributeClass, NumericAttributeClass, CategoricalAttributeClass, Ordinal,AttributeClass, ApplicationAttributeClass COBOLData.idl: COBOLFieldClass, RenamesClass DMSII.idl: DataItemClass, RemapItemClass ER.idl: ErAttributeClass Essbase.idl: AliasClass, CommentClass, ConsolidationClass, CurrencyConversionClass, DataStorageClass, FormulaClass, GenerationClass, ImmediateParentClass, LevelClass, MemberNameClass, TimeBalanceClass, TwoPassCalculationClass, UDAClass, VarianceReportingClass Express.idl: VariableClass, FormulaClass, ValueSetClass, RelationClass IMSDatabase.idl: ImsFieldClass, SenFieldClass.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see below

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

CWM model needs to be augmented to allow specification of level& hierarchy

  • Key: CWM11-87
  • Legacy Issue Number: 4474
  • Status: closed  
  • Source: Oracle ( David Mellor)
  • Summary:

    The CWM model currently defines the physical mapping of a Cube based only on a level of a dimension. The model needs to be augmented to allow the specification of both a level and a hierarchy.

  • Reported: CWM 1.0 — Tue, 7 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    Add a new sub-type of MemberSelectionGroup which contains a reference to a hierarchy

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

CWM does not reflect the latest version of UML

  • Key: CWM11-86
  • Legacy Issue Number: 4471
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    CWM aims to be a subset of UML. Various changes have occurred in Core at UML 1.4 which are not reflected in CWM. CWM 1.1 should be updated to reflect the latest UML. For example, the old TaggedValue now has been split between new TaggedValue which just holds the value (in a multivalued 'dataValue' attribute or as a 'referenceValue' ModelElement) and a new TagDefinition class which provides the tag name, reference to Stereotype and a multiplicity. Document ad/01-02-24 contains the UML 1.4 changes, though only changes to the Core will be relevant to CWM.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    see above

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

Missing letters in chapter 9 diagrams.

  • Key: CWM11-85
  • Legacy Issue Number: 4469
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Figure 9-1 has initial letters missing from ModelElement and Constraint classes. Figure 9-9 has initial letter missing from Table class. Figure 9-10 has initial leters missing from the Parameter and SQLParameter classes. Figure 9-13 has initial letter missing from DataValue class.

  • Reported: CWM 1.0 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    No Data Available

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

Data mining metamodel

  • Key: CWM11-84
  • Legacy Issue Number: 4458
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    This is an issue deferred from the CWM FTF. The Data Mining metamodel should be revised based on feedback from the JSR-73 (JDMAPI) work

  • Reported: CWM 1.0 — Fri, 3 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    No Data Available

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

Revise the IMS metamodel

  • Key: CWM11-83
  • Legacy Issue Number: 4442
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    IBM has implemented the IMS metamodel of CWM 1.0. In doing so, we have found it necessary to make some significant changes to improve usability and completeness, and to handle new facilities of IMS. The CWM RTF should revise the IMS metamodel incorporating these changes.

  • Reported: CWM 1.0 — Wed, 1 Aug 2001 04:00 GMT
  • Disposition: Resolved — CWM 1.1
  • Disposition Summary:

    Resolved by CWM 1.1 RTF

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

Clarify legal values for the MoneyFormatter format strings

  • Key: CURR11-64
  • Legacy Issue Number: 2409
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify legal values for the MoneyFormatter format strings

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

removeExchangeRate() interface issue

  • Key: CURR11-61
  • Legacy Issue Number: 2406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The removeExchangeRate() interface may be too heavy handed. Modify
    the semantics of this interface to support making an exchange rate
    instance unsuitable for use (e.g. inactive). In this way, the exchange rate
    instance would still be known to the component, but could no longer be used
    in computations. It could however be extracted for reporting purposes, etc.
    Would need interface accommodations though to indicate the extraction of
    exchange rates that are “inactive”.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Not an issue

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

Modify and specify the behavior of the insertExchangeRate interface

  • Key: CURR11-60
  • Legacy Issue Number: 2405
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The behavior of the insertExchangeRate() interface should be modified.
    Since ExchangeRates will now have a window in time over which they are
    effective, the behavior needs to address what happens when an exchange rate
    is attempted to be inserted that overlaps (in time) an existing exchange
    rate. i.e. Suppose an exchange rate exists in the system for a certain rate
    type, source currency mnemonic, target currency mnemonic, and is effective
    from 12:00 15 July 1998 until 12:30 15 July 1998. Now suppose we attempt to
    insert an exchange rate for the same rate type, source/target currency
    mnemonics and is effective from 11:45 15 July 1998 until 12:15 15 July
    1998. How does the insertExchangeRate() interface react in this case, or in
    any other case where the exchange rate to be inserted has an effective
    window in time that in whole or in part overlaps existing exchange rate
    data?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Create mechanism to modify what negative prefix is for formatting string

  • Key: CURR11-69
  • Legacy Issue Number: 2414
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no mechanism to modify what the negative prefix is, in a formatted
    string. You can modify what the placeholder for the negative prefix is, but
    not the actual prefix. This then means that "-" is to be used in every
    locale. I would bet that we should support changing that character ... much
    like we allow changing the radix character or the grouping character.
    Hence, [gs]etNegativePrefixSymbol() above.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Clarify exceptions for setFormattingString in MoneyFormatter

  • Key: CURR11-66
  • Legacy Issue Number: 2411
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need to indicate that an exception will be thrown if setFormattingString()
    is called with formattingString being an empty string or one containing
    white space only.

  • Reported: CURR 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Clarify contradiction betw setFormatByLocale & setFormattingString

  • Key: CURR11-65
  • Legacy Issue Number: 2410
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears that setFormatByLocale() and setFormattingString() override each
    other, but the supporting text for each does not support this conclusion.
    If setFormatByLocale() is executed, and then a call to
    getFormattingString() is executed, a format specification for the given
    locale should be returned correct? If a call to setFormattingString() is
    then executed (which would change the format specification for the given
    state identifier from the locale based specification previously),
    getFormattingString() then returns the format specification just assigned
    correct? The supporting text needs to address this behavior.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Interface changes for MoneyFormatter pattern handling

  • Key: CURR11-68
  • Legacy Issue Number: 2413
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Interface changes for MoneyFormatter pattern handling

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Typo on SetPatternMnemonicSymbol name

  • Key: CURR11-67
  • Legacy Issue Number: 2412
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Fix typo to setPatternMnemonicSymbol()

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Add interfaces for internal precision on MoneyCalculator

  • Key: CURR11-71
  • Legacy Issue Number: 2416
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Propose the following interface change(s):
    short getInternalPrecision(in
    CosObjectIdentity::IdentifiableObject stateIdentifier)
    void setInternalPrecision(in
    CosObjectIdentity::IdentifiableObject stateIdentifier,
    short precision) – See example of use of this in the
    MoneyCalculator Interface section.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Already resolved in a previous issue (2271)

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

Clarify on comparison methods of the MoneyCalculator

  • Key: CURR11-70
  • Legacy Issue Number: 2415
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify on comparison methods of the calculator that no rounding etc. would
    take place before the comparison, it would be the raw numbers in each
    money instance that is compared.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Clarify MoneyFormatter use of the # symbol

  • Key: CURR11-63
  • Legacy Issue Number: 2408
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify how the ‘#’ is used in the money formatter – i.e. if the digit is
    zero and doesn’t contribute to the value, 0 will not show.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Proposed interface changes to ExchangeRateManager

  • Key: CURR11-62
  • Legacy Issue Number: 2407
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Propose the following interface changes:
    ExchangeRate createExchangeRate(
    in wstring rateTypeId,
    in wstring sourceCurrencyMnemonic,
    in wstring targetCurrencyMnemonic,
    in CBO::Ddecimal conversionFactor,
    in CBO::Dtime beginDateTime,
    in CBO::Dtime endDateTime)

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Close, no action

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

Fix omitted precondition for MoneyCalculator

  • Key: CURR11-72
  • Legacy Issue Number: 2417
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue Description: What are the legal short precision values which can be
    presented to setInternalPrecision()? Should it be limited to values >= 0?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Change the name of addExchangeRate to insertExchangeRate

  • Key: CURR11-59
  • Legacy Issue Number: 2404
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The addExchangeRate() method name could connote mathematical summation.
    Change the method name to insertExchangeRate().

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF

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

Length of wstring in GIOP 1.1

  • Key: CORBA26-87
  • Legacy Issue Number: 3075
  • Status: closed  
  • Source: Fujitsu ( Masayoshi Shimamura)
  • Summary:

    I have a question about GIOP wstring encoding. Section "15.3.2.7 Strings
    and Wide Strings" in CORBA 2.3.1 says:

    For GIOP version 1.1, a wide string is encoded as an unsigned long
    indicating the length of the string in octets or unsigned integers
    (determined by the transfer syntax for wchar) followed by the
    individual wide characters. Both the string length and contents
    include a terminating null. The terminating null character for a
    wstring is also a wide character.

    In the sentence above, I believe that the "length" represents number of
    octets (in the case of byte oriented codeset) or number of unsigned
    integers (in the case of non-byte oriented codeset).

    For example,

    "abc" (ASCII code) ----> length is 4 (including one null terminate)
    L"abc" (Unicode, USC2) ----> length is 4 (including one null terminate of wchar)

    Is my understanding right?

  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

padding at the end of a non-fragmented 1.2 request message

  • Key: CORBA26-86
  • Legacy Issue Number: 3014
  • Status: closed  
  • Source: AT&T ( Sai-Lai Lo)
  • Summary:

    Suppose a GIOP 1.2 request message is sent for an operation with no
    argument. In this case the request body is empty because there is no
    argument.

    Furthermore, the whole request message is non-fragmented, i.e. the
    2nd least significant bit of Flags in the request header is 0. Now if the
    request message header ends on a boundary which is not 8-byte
    aligned. Should the request message be extended with extra padding after the
    request message header to make the whole request message multiple of 8?

    I think the relevant statement is in section 15.4.1 (page 15-31):

    "For GIOP version 1.2, if the second least significant bit of Flags is 1,
    the sum the message_size value and 12 must be evenly divisible by 8"

    My intepretation of the statement is that the condition I just described
    does not meet this critera. Hence the message should not be padded to
    multiple of 8. It should just be ended with the end of the message header,
    just like previous GIOP versions.

    I'm asking for clarification on this issue because I'm seeing a different
    behaviour in another ORB implementation and would like to pre-empt any
    interoperability problem in future.

  • Reported: CORBA 2.3.1 — Tue, 9 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

IANA ports for IIOP need to be documented in Ch 13 and 15

  • Key: CORBA26-83
  • Legacy Issue Number: 2939
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 15 (formal/99-07-19), page 15-51 last para of section 15.7.2, and
    Chapter 13 (formal/99-07-17), page 13-36 last para, assert that "no 'well known'
    ports have been allocated", and then proceeds to state that individual
    implementations must use some unallocated port and document it.

    The statement about "no well known port has been allocated" needs to be revised
    to reflect that a well known port (683 for IIOP) has been allocated. Then we can
    change the statement about what individual implementations are expected to do by
    merely replacing the "must use some unallocated port" by a "may use the well
    known port or may use some unallocated port and document it" or some such.

  • Reported: CORBA 2.3 — Tue, 21 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Interop, 15.7.3 unclear wording

  • Key: CORBA26-85
  • Legacy Issue Number: 2952
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I do have a quick question on one part and that is
    Section 15.7.3 IIOP IOR Profile Components. This first paragraph has the
    following line in it: " All these components are optional presence in the
    IIOP profile
    and cannot be dropped from an IIOP 1.1 or 1.2 IOR". Now I must admit that I
    am
    new to this CORBA thing, but is there something wrong with this sentence?
    I am not quite sure what this means and the grammar seems quite odd ("are
    optional prensence"?). Any chance someone could translate?

  • Reported: CORBA 2.3.1 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Is GIOP 1.x sustainable any more?

  • Key: CORBA26-84
  • Legacy Issue Number: 2941
  • Status: closed  
  • Source: ( Adrian St. John)
  • Summary:

    Is GIOP 1.x really sustainable any more?
    We've got implementation nightmares because:

    • Features haven't been thought through properly
      eg Fragment in 1.1, BiDir in 1.2
    • Simple backwards compatibility is being lost
      eg ReplyHeader v1.2 has fields in completely different places to
      previous versions, albeit for very good reasons.
    • The TypeCode CDR version problems
    • Not enough information in certain messages
      eg MessageError can't indicate which message may have caused a
      problem, and certainly can't describe in what way there was an error.
  • Reported: CORBA 2.3 — Thu, 23 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Use of undefined "id" attribute

  • Key: CORBA26-82
  • Legacy Issue Number: 3197
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    I have a number of issues with the Software Package Descriptor section of
    the CCM specification (Component Spec - Volume I, orbos/99-07-01.) I have
    not found answers to issues raised below in either the components-ftf
    archive, or the issues list.

    ISSUE - The softpkg descriptor example uses an "id" attribute, which isn't
    defined in the softpkg.dtd.

    >From page 10-305, 10.2.1 A softpkg Descriptor Example, CORBA Components -
    orbos/99-07-01:

    <idl id="IDL:M1/Bank:1.0" ><link href="ftp://x/y/Bank.idl"/></idl>

    According to the softpkg.dtd, (page B-435, B.1 softpkg.dtd, CORBA Components

    • orbos/99-08-05, ) the idl element is defined as follows:

    <!ELEMENT idl
    ( link

    fileinarchive
    repository
    ) >

    The same definition can also found in section 10.2.2.14, The idl Element (,
    page 10-311, CORBA Components - orbos/99-07-01.) There are no attributes
    defined for the idl element.

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Question about corbaname URL

  • Key: CORBA26-93
  • Legacy Issue Number: 4342
  • Status: closed  
  • Source: Raytheon ( Craig Rodrigues)
  • Summary:

    I have an interoperability question regarding the
    corbaname URL in the CORBA 2.4.2 specification and would appreciate
    clarification.

    In 13.6.7.3, it states that for a corbaloc URL which
    uses IIOP, if the port number of the endpoint is
    not specified, then the IIOP profile should default
    to port 2809 which is specified by IANA as the corbaloc
    port.
    eg.
    corbaloc:iiop:myhost.com/SomeKey

    In 13.6.7.5, the corbaname URL is described.
    If a corbaname URL is specified for IIOP, but the port
    number is omitted, should the ORB assume that the
    root naming context will be on port 2809 of the host
    specified?

    eg.
    corbaname:iiop:myhost.com:3000#path/obj

    will look for the root naming context on port
    3000 of myhost.com.

    eg.
    corbaname:iiop:myhost.com#path/obj

    Should this look to port 2809 for the root
    naming context?

  • Reported: CORBA 2.4.2 — Fri, 8 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above

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

Incomplete grammar in section 15.3.4.8

  • Key: CORBA26-92
  • Legacy Issue Number: 4339
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In orbrev/01-03-01:

    Production rule two at the end of this sections has a comment that it
    should include all IDL types, but in actuality is missing "long long",
    unsigned long long" and "long double".

    Suggest we add these to the production rule in question.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    No Data Available

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

Indirections with chunking & fragmentation

  • Key: CORBA26-91
  • Legacy Issue Number: 4328
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    When chunking and fragmenting, it is possible for a chunk length to be
    inserted between the indirection tag and indirection offset.
    Implementations must be careful to compute the indirection offset
    correctly both when writing and reading to avoid errors.

    For interoperability, we should elminate this possibility. From an
    implementation point of view, the code for handling this special case
    should already be there. Please see the original message (see
    attachment) for a detailed description of the problem scenario and two
    implementation possibilities.

    Proposed resolution:

    Elminate the possibility of chunk lengths between indirection tag and
    indirection offset by changing the following paragraph in CORBA formal
    00-11-03 15.3.4.6.

  • Reported: CORBA 2.4.2 — Fri, 25 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

In RMI rep Id, when is inclusion of SUID legal?

  • Key: CORBA26-89
  • Legacy Issue Number: 4280
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    In formal 00-11-03 10.6.2 in the discussion of the serial version UID in
    the RMI hashed format, the spec defines the repository ID format as

    RMI: <class name> : <hash code> [ : <serialization version UID> ]

    and says

    "If the actual serialization version UID for the Java class differs from
    the hash code, a colon and the actual serialization version UID
    (transcribed as a 16 digit upper-case hex string) shall be appended to
    the RepositoryId after the hash code."

    The Java to IDL spec ptc-00-01-06 1.3.5.7 says

    "The syntax of the repository ID is the standard OMG RMI Hashed format,
    with an initial “RMI:” followed by the Java class name, followed by a
    hash code string, followed optionally by a serialization version UID
    string."

    Questions:

    1) Is it legal to include the serial version UID in the repository ID
    even when it is equal to the hash code? (Alternatively: Is it legal
    for an ORB to throw an exception/fail if the hash code and serial
    version UID in the repository Id are the same?)

    2) If it is not legal to include the serial Version UID in the
    repository ID when equal to the hash code, what should an ORB do?

    Discussion:

    Other than it not harming anything to include the SUID, there are rare
    cases that the same Java class compiled with different compilers can
    result in different default serial version UIDs, so it would be wise to
    explicitly specify the serialVersionUID field even in the first version
    of a class. If it is legal to always include the serial version UID
    part of the repository ID, ORBs with classes from two different
    compilers would still be able to interoperate.

  • Reported: CORBA 2.4.2 — Mon, 23 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

GIOP is silent about extra data in the Request or Reply body

  • Key: CORBA26-88
  • Legacy Issue Number: 4273
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The specification does not say whether extra data after the invocation
    parameters in a Request or Reply body is ignored or considered an
    error. For interoperability purposes, the spec should require one or
    the other.

  • Reported: CORBA 2.4.2 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

GIOP issue : fragmented replies with exceptions

  • Key: CORBA26-90
  • Legacy Issue Number: 4289
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Let us assume that the server has sent a few reply fragments. But before sending all the reply
    fragments, an exception occurs (say while marshalling the response).
    What does the server and the client (which has already seen reply fragments) do ?

    Just to note, notice that if the same problem happens while the client is in the midst of sending
    request fragments, the client can choose to send a CancelRequest message to intimate the server.

    Since there are various possible behaviours for the client and server, the GIOP specification needs
    to clarify the standard behaviour, in order for different implementations to remain interoperable.

    One possible behaviour :

    The server could send back a seperate response (containing the exception with
    CompletionStatus.COMPLETED_YES). The client on receipt of the new reply, and noticing the fact that
    another reply with the same requestId is pending, could discard the pending reply and process the
    latest reply.

    Another behaviour :

    The client could simply timeout the request and discard any new reply streams (with the same
    requestId), and raise an exception with CompletionStatus.COMPLETED_MAYBE.

  • Reported: CORBA 2.4.2 — Mon, 30 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    This issue is resolved by the resolution to issue 4273.

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

Changing VSCID prefix to 24 bits

  • Key: CORBA26-94
  • Legacy Issue Number: 4618
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    In section 13.6.8 of CORBA 2.4.2 (formal/01/02-01), at the top of page
    13-29, it says:

    The high-order 20 bits of service-context ID contain a 20-bit vendor
    service context codeset ID (VSCID); the low-order 12 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wish to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCID of zero is reserved for use for OMG-defined standard service
    context IDs (i.e., service context IDs in the range 0-4095 are reserved as
    OMG standard service contexts).

    The VSCID-related text was added by the Interop 1.2 RTF as per RTF report
    as in document number interop/98-01-04, and revised pages as in document
    number interop/98-01-03. However, at about the same time OMG staff
    established a convention that OMG should allocate vendors a 24-bit "service
    tag", which is in fact the same as a VSCID. Since then, some 47 of these 24
    bit service tags have been assigned to various vendors.

    At the risk of having the tail wag the dog, I propose we resolve this
    conflict by revising these paragraphs in the CORBA spec as follows:

    The high-order 24 bits of a service context ID contain a 24-bit vendor
    service context codeset ID (VSCID); the low-order 8 bits contain the rest
    of the service context ID. A vendor (or group of vendors) who wishes to
    define a specific set of system exception minor codes should obtain a
    unique VSCID from the OMG, and then define a specific set of service
    context IDs using the VSCID for the high-order bits.

    The VSCIDs of zero to 15 inclusive (0x000000 to 0x00000f) are reserved for
    use for OMG-defined standard service context IDs (i.e., service context
    IDs in the range 0-4095 are reserved as OMG standard service contexts).

  • Reported: CORBA 2.5 — Fri, 12 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component port introspection

  • Key: CORBA26-72
  • Legacy Issue Number: 4412
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Components::Navigation interface that is implemented by all
    components provides introspection ("generic navigation") capabilities.
    There are lots of use cases for introspection, so I wonder why there
    is introspection for facets, but not for receptacles or event ports.
    I suggest to add such introspection capabilities. All introspection
    features should be alike as much as possible for ease of usage.

  • Reported: CORBA 2.4.2 — Mon, 16 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

"supports" terminology issue for CCM

  • Key: CORBA26-71
  • Legacy Issue Number: 4329
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    . I don't
    think OMG specifications should use a single term in two distinctly
    different ways. The text of the issue starts with the sentence,
    "the Components spec and valuetype spec treat "supports" exactly
    *OPPOSITE* in semantics regarding widening/narrowing." and continues
    for about 3 or 4 paragraphs. Ed's comment should go in there too.

  • Reported: CORBA 2.4.2 — Fri, 18 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

CCM: Definition of import declaration unclear

  • Key: CORBA26-77
  • Legacy Issue Number: 4577
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    After reading the definition of the import declaration, it is not at
    all clear what its effect is.

    Suppose the "well-known set of IDL specifications" consists of

    module A {
    module B {
    interface C {
    struct S

    {long a;}

    ;
    };
    };
    };

    Now consider the import statement

    import A::B;

    According to the draft, "Names that occur in IDL declarations within
    the importing specification may be resolved to definitions in imported
    scopes." What is a "Name" in this context? Is it an <identifier>, or
    is it a "<scoped_name>"?

    It is unclear whether in this context, the definition

    interface D : C {};

    would be correct or not. The spec may be interpreted that name "C"
    resolves to ::A::B::C, i.e. that the name "C" is appended to the
    imported scopes, forming a fully-scoped name. If that is the intended
    meaning, the text should explain how to deal with conflicts.

    Alternatively, given the text "Imported IDL name scopes exist in the
    same space as names defined in subsequent declarations in the
    importing specification." would suggest that

    interface D : B::C {};

    is well-formed: "B" would be the name of the imported scope, so it
    exists in the same space "D", and can thus be used for qualifications.

    Furthermore, the text could be understand to mean that

    interface D : ::A::B::C {};

    is allowed. The "definition in the imported scope" has the name
    "A::B::C", so this is the name to be used in the importing
    specification.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: Chapter 66 should be removed

  • Key: CORBA26-70
  • Legacy Issue Number: 4307
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    Looking at ptc/99-10-04, it is not clear to me which parts of this
    document are intended as normative.

    For example, the introduction to chapter 66, "Component Container
    Architecture", states that the presented design "is not the only
    possible design choice." Consequently, it appears that the entire
    chapter 66 is not intended as normative. However, looking at the
    actual text, a reader might be easily confused into taking aspects of
    the design as normative.

    While this text was helpful in the submission to give readers an
    insight how the submitters might design their implementations, it
    should be removed from the specification, to really give implementors
    the freedom of design choice that was apparently intended with the
    submission.

  • Reported: CORBA 2.4.2 — Tue, 15 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

IDL out parameters can't map to EJB?

  • Key: CORBA26-69
  • Legacy Issue Number: 4269
  • Status: closed  
  • Source: Progress Software ( Alan Conway)
  • Summary:

    Section 8.3.1 says "The signatures of the CORBA component operations are mapped to signatures of EJB remote interface methods following the IDL to Java mapping rules."

    As far as I can see, this only works if the IDL signature has no out or inout parameters. The Holder classes for out and inout parameters cannot be used in an EJB interface signature because they need not be Serializable, which breaks the rules for an RMI compliant class. Even if they could the EJB stubs and skeletons would not implement their special return value behavior without modifications to the EJB spec.

    Someone please tell me I've missed something!

  • Reported: CORBA 2.4.2 — Thu, 12 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

explicit definition of CCM exceptions mapped from EJB standard exceptions

  • Key: CORBA26-74
  • Legacy Issue Number: 4540
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The CCM exceptions mapped from EJB standard exceptions need to be defined
    explicitly in OMG IDL. The resolution to issue 3182 introduces new CCM
    standard exceptions Components::CreateFailure, Components::FinderFailure
    and Components::RemoveFailure but it does not define them explicitly.

  • Reported: CORBA 2.4.2 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Incorrect syntax in Components::Enumeration

  • Key: CORBA26-73
  • Legacy Issue Number: 4529
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    The use of the state keyword in the Components::Enumeration valuetype,
    introduced by issue 3099 and extended in issue 3418, is not correct
    syntactically. Also, anonymous sequences have been deprecated, so the
    definition of the Components::Enumeration state is incorrect in this sense
    as well.

  • Reported: CORBA 2.4.2 — Fri, 13 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

minor IDL changes required in CCM API

  • Key: CORBA26-81
  • Legacy Issue Number: 4717
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In order to compile the Components.idl file with a compiler
    compliant with OMG IDL2/IDL3/CIDL/PSDL grammars simultaneously,
    it is required to apply some changes in CCM APIs:

    • In ptc/2001-11-03 draft chapter 61 page 61-225, the following IDL

    valuetype FacetDescription : PortDescription

    { public Object facet; }

    ;

    should be replaced by

    valuetype FacetDescription : PortDescription

    { public Object facet_ref; }

    ;

    because 'facet' is a CIDL keyword.

    • In ptc/99-10-04 chapter 62 page 62-141, the following IDL is defined

    exception Rollback { };
    // ...
    local interface Transaction

    { // ... void commit () raises (Rollback, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    Here there is a conflit name between the exception Rollback
    and the operation rollback.

    In order to avoid this, the exception Rollback should be renamed
    RollbackError. Then the previous IDL should be replaced by:

    exception RollbackError { };
    // ...
    local interface Transaction

    { // ... void commit () raises (RollbackError, NoTransaction, HeuristicMixed, HeuristicRollback, Security, SystemError); void rollback () raises (NoTransaction, Security, SystemError); // ... }

    ;

    In the commit operation description page 62-142, the Rollback exception
    should be replaced by RollbackError.

    In table 64-7 page 64-197, the Rollback exception of the commit operation
    should be replaced by RollbackError.

    • In ptc/99-10-04 chapter 62 page 62-151, the 1st 'home' parameter
      of the HomeRegistration::register_home and unregister_home operations
      implies a parser error with a CCM IDL compiler as 'home' is a keyword.

    The 'home' parameters should be replaced by 'home_ref'
    Ditto in the following 'register_home' and 'unregister_home'
    operation descriptions.

    • In ptc/99-10-04 chapter 62 page 62-155, the following IDL

    get_oid_from_ref (in Object ref)

    should be replaced by

    get_oid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_oid_from_ref' operation description page 62-156,
    replace 'The ref parameter' by 'The objref parameter'.

    • In ptc/99-10-04 chapter 62 page 62-162, the following IDL

    get_cid_from_ref (in Object ref)

    should be replaced by

    get_cid_from_ref (in Object objref)

    because 'ref' is a PSDL keyword.

    In the 'get_cid_from_ref' operation description page 62-163,
    replace '(ref)' by '(objref)'.

    • In ptc/2001-11-03 draft chapter 69 page 69-551, the following IDL

    void remove_container(in Container ref) raises (RemoveFailure);

    should be read as

    void remove_container(in Container cref) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

    • In ptc/2001-11-03 draft chapter 69 page 69-553, the following IDL

    void remove_home(in CCMHome ref) raises (RemoveFailure);

    should be read as

    void remove_home(in CCMHome href) raises (RemoveFailure);

    because 'ref' is a PSDL keyword.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Accept the previous required changes.

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

Little problem with introspection API

  • Key: CORBA26-80
  • Legacy Issue Number: 4716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I wanted to point out that the use of the name "ref" or "Ref" in
    > the introspection API may be a problem because "ref" is a
    > reserved word in PSDL and therefore any PSDL file that
    > includes the CCM IDL file will cause compiler errors (this has
    > happened to me when using the OpenORB PSDL compiler). If at
    > all possible we should change the use of "ref" to "reference"
    > or something else in the final version of the spec.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: Meaning of "exposed" scopes unclear.

  • Key: CORBA26-79
  • Legacy Issue Number: 4579
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    ccm/01-08-04 says

    "When a name scope is imported, the names of the enclosing scopes in
    the fully-qualified pathname of the enclosing scope are exposed within
    the context of the importing specification, but their contents are not
    imported. An importing specification may not re-define or re-open a
    name scope which has been exposed (but not imported) by an import
    statement."

    Now consider the following "well-defined set of IDL specs":

    module X {
    module Y {
    module Z{};
    };
    };

    and the following import statement

    import X::Y;

    Now, it appears that this declaration would make it ill-formed to
    specify

    module X{
    interface another_interface{};
    };

    since "X" is an exposed scope. That appears to be inconsistent, since
    clearly, reopening "X" is allowed without the import statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: usage of the MOF profile

  • Key: CORBA26-68
  • Legacy Issue Number: 4214
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The CCM MOF IR draft (ptc/99-10-05) uses UML to denote the MOF model
    of the IR. Without missing elaboration, it is not possible to mentally
    construct the metamodel. For example, the enumeration, primitive, and
    unchangeable stereotypes don't have a well-defined relationship to MOF
    concepts. It seems that the MOF chapter should use the UML MOF profile
    (ad/01-02-29). In addition, it would be desirable if a normative XML
    document that defines the metamodel (following the MOF DTD) is
    provided.

  • Reported: CORBA 2.4.2 — Thu, 1 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: Isolated scope tokens

  • Key: CORBA26-76
  • Legacy Issue Number: 4576
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, section 3.6, there is a sentence

    "In isolation, the scope token represents the scope of the
    specification in which it occurs."

    It is not clear what an "isolated scope token" is, since the scope
    token is allowed only as part of a <scoped_name>, but never appears in
    isolation. The intended meaning of this sentence should be clarified.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue for Components: Missing language mapping

  • Key: CORBA26-75
  • Legacy Issue Number: 4574
  • Status: closed  
  • Source: Humboldt-Universitaet ( Harald Boehme)
  • Summary:

    in both documents orbos/99-07-01/6.3 and ptc/99-10-40/615.3 the language
    mapping is noted as open issue.
    Where are the language mappings for components ?

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM: import and re-opening of modules

  • Key: CORBA26-78
  • Legacy Issue Number: 4578
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ccm/01-08-03, a sentence says "IDL module definitions may re-open
    modules defined in imported name scopes."

    Now, consider the following "well-defined set of IDL definitions":

    module Y{};
    module A{
    module Y{};
    };
    module B{
    module Y{};
    };

    and the import statements

    import A;
    import B;

    Clearly, A::Y and B::Y are "modules defined in imported name
    scopes". Does that mean that specifying

    module Y{
    interface another_interface{};
    };

    is now valid? If so, which namespace is extended?

    It may be that this is meant to be an error (if so, where does it say
    that?). In that case, consider the case that there was only a single
    import:

    import A;

    Then, if this means that A::Y is extended, how could I specify a
    re-opening of ::Y?

    Alternatively, it may be that the authors thought of re-opening Y in
    the form of

    module A::Y{
    interface another_interface{};
    };

    That, of course, is illegal syntax. Yet another interpretation is that
    the draft intended to allow

    module A{
    module Y{
    interface another_interface{};
    };
    };

    However, this appears to be possible even without any import
    statement.

  • Reported: CORBA 2.5 — Mon, 17 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 4577.

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

Extended Interface Repository

  • Key: CORBA26-63
  • Legacy Issue Number: 4116
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I am somewhat surprised over the ExtendedIR interface in 00-11-01.
    I am very aware of problems with extensibility in the Interface Repo-
    sitory. In the past, a lot of problems have been caused because modi-
    fications like InterfaceDef::is_abstract have been worked in and out.
    We certainly desperately need a backwards-compatible Interface Repo-
    sitory.

    This is unachievable with version pragmas, because then a client's
    is_a inquiries with "old" Repository Ids will fail, and the client
    will refuse to talk any further.

    Backward compatibility is instead achieved by not changing data types
    (such as InterfaceDescription) and by not changing the signature of
    existing attributes and operations.

    Adding new types that are used by new operations on existing interfaces
    does not break compatibility, because the client will simply be unaware
    that there are more operations than it knows of (such as describe_inter-
    face_2_3).

    Whether changing interfaces sensible is debatable, surely it's more
    consistent to use derived interfaces instead – this has the least im-
    pact on compatiblity.

    In that light, I wonder whether the proposal in 00-11-01 gets us any
    further. It adds more fixed interfaces in another module, and this new
    ExtendedIR module is just as static as the old ones have been. If any
    further changes were necessary, backwards-incompatible changes were
    just as necessary.

    The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
    with its use of "extended" everywhere, and its usage of multiple inheri-
    tance from the original interfaces is confusing.

    Yet there is one item from 00-11-01 that I like much better than the
    proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
    LocalInterfaceDef. I think that's the way to go.

    Therefore, I tend to vote against issue 3233 and its proposed resolution
    in 00-11-01.

    Rather, I propose to go back to the original version instead, and

    • to add AbstractInterfaceDef, LocalInterfaceDef and the related
      container operations
    • to add an AttributeWithExceptionsDef and InterfaceDef::create_
      attribute_with_exceptions and ValueDef::* operations.

    Whether the Interface Repository should be moved to a different module
    should be a separate discussion. I support the idea, but I don't think
    that the implementation should be forced to offer access to the IFR
    using both the CORBA:: and IR:: modules.
    Note that vendors could still offer the old interfaces in their imple-
    mentation.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Problems with the Components Notification Event Interface

  • Key: CORBA26-62
  • Legacy Issue Number: 4081
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The CCM standard indicates that all CCM Event functions will delegate to
    the container. Chapter 7 of the CCM Volume 1 further dictates the
    interface the container will provide to the component, called
    Components::Notification::Event, referred to as the "Event Interface"
    hereafter. This interface contains many problems and does not address
    all the required functionality. The problems are listed below:<p>

    • The create_channel() method returns an EventConsumerBase for the
      publisher to use to publish events to the channel. It is not possible
      for the Event Interface to construct a concrete EventConsumerBase,
      specifically the interface defined as
      <publishing_component>EventConsumers::
      <event_type>Consumer (per section 5.6.6 and 5.6.7 giving the
      publisher and emitter IDL expansion). The Event::obtain_channel()
      method has the same problem
    • The subscribe() method implies that the container supplying events
      will hold the supplier proxy that will be used to send events to the
      subscriber’s EventConsumerBase. This is an inefficient model. Also,
      this model is in direct conflict with the listen() method, which
      supports a more efficient model (see next bullet).
    • The standard does not provide any documentation on when a consumer
      would call the listen() method. The standard also does not provide a
      means for the consumer’s component to realise the "csmr_name", the
      name used to find the ConsumerAdmin from the Naming Service [see
      possibly related issue #3940]. Nor does the standard indicate when
      the ConsumerAdmin would have ever been added to the Naming Service.
      It might be possible that this would work for emitters, but it does
      not work for publishers (the standard dictates that a consumer cannot
      distinguish between being connected to an emitter or a publisher).
      This method does imply that the consuming component will have a proxy
      local to its container, separate from the publishing component’s
      container (contradictory to the subscribe() method, see previous
      bullet).
    • The push() method does not provide a means to indicate which channel
      the event should be pushed to see possibly related issue #3928.<p>

    The Event Interface is a local interface ­ that is, the client will
    never see this interface, and so it is possible to hide the use of this
    interface inside the generated code and thus replace the interface.
    Internally we have added a PortManager interface to be used in place of
    the Event Interface. This interface provides better management of the
    Event Channels and it also manages receptacle connections. Two
    interfaces will derive from the PortManager, a TransientPortManager and
    a PersistentPortManager. These two derived interfaces will permit
    connections between components to be managed as defined by the type of
    the container. Where meaningful, this permits the port connections to be
    made persistent as part of the overall state so that connections
    (specifically, notification channels) can be more reliably and robustly
    managed. The CCM2Context::get_event() operation is replaced by
    get_port_manager()

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3937. rejected

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

Component home interface inheritance

  • Key: CORBA26-61
  • Legacy Issue Number: 4080
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The definition of homes does not permit interface inheritance. It
    appears this is an oversight as the omission seems unreasonable and
    counter-intuitive, especially since homes must follow a parallel
    derivation hierarchy with their component types. I have found cases in
    which a home would expose the same interface as its component in which
    the home subsequently delegates to a specific component instance (even a
    persistent instance) however selected. (The component instance may or
    may not be hidden from the client.) Interfaces are a perfect mechanism
    whereby the operational signatures could be standardized, thus
    eliminating potential errors caused by changing one but not the other.
    This could be accomplished using a supports clause in the inheritance
    specification similar to that of valuetypes.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components, Facets, and Object References Unclear

  • Key: CORBA26-56
  • Legacy Issue Number: 4073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components specification, orbos/99-07-01, chapters 5, 6,
    7, and 9. The semantics, life cycle, and mechanisms behind components,
    facets, "regular" objects, and their related object references is weakly
    specified. In particular, it is not clear how a component interacts
    with a container to generate an object reference to a facet, especially
    a facet in a secondary segment. The description of component
    identifiers indicates that the component object id, the facet number,
    and the segment number are used to generate the facet's object reference
    (or perhaps only the ObjectId), but the sequence of operations is not
    given. It appears that not all the necessary methods have been formally
    specified, nor are the code generation examples adequate for this
    siutation.

    Consider the following IDL:

    interface A {};
    component C

    { provides A a_facet; A get_another_A(); }

    ;

    What is the life-cycle of the A object returned as the provided facet?
    Is it limited to the life-cycle of the component? Is the member
    operation returning an object of the same type as a provided facet
    permitted? Should this return the same object as the facet? If not, is
    the life-cycle of this extra object limited to the life-cycle of the
    component? Should such objects be considered facets, even if not
    explicitly declared such (which, please note, provides the equivalent of
    the deprecated "provides multiple" capability)? What information needs
    to be encoded in its object reference, especially for component
    dependency? How will the context for this be established, and are any
    additional interfaces or operations required to accomplish this?

  • Reported: CORBA 2.4.1 — Tue, 21 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

New component issue: connection failure recovery

  • Key: CORBA26-55
  • Legacy Issue Number: 4025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM does not describe the behavior of the system in case of various fault situations. In particular, this issue only concerns itself with the recovery mechanisms of event subscriptions or facet receptacles that were automatically established through an assembly. While it is outside the scope of the CCM to describe general fault behavior, it is felt that recovery mechanisms (or their absence) should be explicitly identified for connections automatically built between ports. Otherwise, why go to the trouble of building them, since error detection and recovery wrappers would be needed around any use of them?

    The following scenario highlights the various situations. It assumes that the components are deployed in separate processes on different platforms so that one of the two components remains operational despite failure or inaccessibility of the other. The scenario primarily deals with the recovery of an interface provided by Component X and used by Component Y. Appropriate questions related to event channels are also given where applicable. Event channels are themselves more difficult because the notification services adds yet another object to the set that may fail during the scenario.

    Scenario: Component X declares that it provides an interface A. Likewise, Component Y declares that it uses interface A. (Or, X emits or publishes event A to which Y subscribes.) Instances of the components are combined through an assembly. Now, the assembly description indicates that a connection is to be built between X and Y. That is, the descriptor defines connections in which a connection element defines the association. Said element’s providesport acquires X’s facet A and assigns that through the usesport to Y’s interface receptacle. (For events, read these as emitsport or publishesport and subscribesport.)

    The following questions arise:

    When does the connection take place, during assembly construction or on reference to the port’s receptacle inside Y? That is, is this immediate or lazy initialization? When are event channels created or attached? Can the producer delay creation or attachment until a push() operation? Can the consumer accomplish the creation? Can an m:n emitter to consumer notification matrix be built? (The specification is unclear on this.)
    What happens if the interface reference to A cannot be acquired because (1) X has failed or is inaccessible, (2) X fails during the get operation, or (3) X returns a nil reference?
    What happens during run-time when Y invokes an operation on A and:
    The application server process containing X has terminated (COMM_FAILURE returned)?
    Derived valuetype arguments cannot be marshalled (MARSHALL/BAD_PARAM returned)?
    The underlying object supporting A in X has been deleted (INV_OBJREF returned)?
    An unexpected application error occurs (UNKNOWN returned)?
    With respect to error detection and recovery:
    How does one indicate the set of objects that can detect the error? Possible objects are Y, Y’s home, Y’s container, X’s container, X’s home, the assembly, an independent third party.
    How does one indicate the set of objects that can recover the error?
    How does one indicate whether the error should be detected?
    How does one indicate whether recovery should be attempted?
    How does one indicate the recovery strategy, especially if there are several objects that can recover the error?
    If the strategy has multiple fallback conditions, should this logic be placed into a single object or should it be given as a precedence-ordered list?
    Where should this information be specified: IDL, CIDL, or XML?
    What are the implications when the components have different type and container semantics?
    Let component X be transient and component Y be an entity. If component X fails, can a new X be safely created for its corresponding Y?
    Assume a new X was created and the old X still exists but became inaccessible. Can the old X be detected and one of the X’s be deleted [dismissed] after the old X is again accessible?
    Assume a request to X completes successfully in X but fails during the reply to Y. Can the operation be retried or the previous results retransmitted, either on the old X after recovery or on a new X?
    In these questions, what happens if X is an entity and Y is transient?
    In these questions, what happens if Y aborts rather than X?

    Ideally, it would be nice if either the IDL extensions or the CIDL constructions permitted specification of an error recovery wrapper around access to a receptacle (or event channel). This could actually work as a general mechanism for any component and not just components grouped in an assembly. The wrapper would be a specialized object implemented specifically in the context of the component or assembly that provided the desired error detection and recovery behavior. It would be a proxy similar to a stub: it would have the same interface as the target object to which it delegates. Errors would be caught (as described) and recovered automatically, if possible. This includes the initial reference to an object, which would now be built or acquired dynamically at run-time rather than semi-statically at assembly instantiation. Multiple inheritance, in languages that support it, would be very useful in standardizing proxy behavior. The component DTD could be used to specify desirable run-time operation and associated characteristics.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Components FTF: TypeCodeFactory

  • Key: CORBA26-65
  • Legacy Issue Number: 4140
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The third part of the adopted CCM submission (orbos/99-07-03)
    moves all the create_..._tc operations from the ORB interface
    to a new PIDL interface, CORBA::TypeCodeFactory.

    This change breaks source-compatibility: source code that creates
    typecodes with a pre-CORBA 3.0 ORB will need to be updated to use
    a CORBA 3.0 ORB with such a TypeCodeFactory interface.

    And there is no clear benefit from this update:

    • ORB is still PIDL – it even creates an additional PIDL
      interface.
    • type code kinds are not more extensible (TCKind is still an
      enum)

    I suggest to undo this update, i.e. keep the create_..._tc
    operations on the CORBA::ORB interface.

  • Reported: CORBA 2.4.1 — Tue, 9 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

ComponentIR Interface fixes

  • Key: CORBA26-64
  • Legacy Issue Number: 4136
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    While reviewing the ComponentIR interfaces in 00-11-01, I have found
    some problems with it. (These are unrelated to the current discussion
    about the Interface Repository itself.)

    Many interfaces inherit Contained::describe(), which is supposed to
    return information about the element. In the basic IFR, this data is
    designed to contain all possible information about that type. This
    is very convenient, since then a map mapping RepositoryIds to
    Contained::Description contains all of the IFR's information.

    By referring to InterfaceDefs rather than RepositoryIds, the client
    will need to store that association elsewhere, or repeatedly invoke
    the Interface Repository.

    Suggested resolution:

    • In ProvidesDescription, replace
      InterfaceDef interface_type
      with
      RepositoryId interface_type
    • Ditto for UsesDescription
    • In EventDescription, replace
      ValueDef event
      with
      RepositoryId event
    • In ComponentDescription, replace
      ProvidesDefSeq provides_interfaces
      UsesDefSeq uses_interfaces
      EmitsDefSeq emits_events
      PublishesDefSeq publishes_events
      ConsumesDefSeq consumes_events
      with
      ProvidesDescriptionSeq provides_interfaces
      UsesDescriptionSeq uses_interfaces
      EmitsDescriptionSeq emits_events
      PublishesDescriptionSeq publishes_events
      ConsumesDescriptionSeq consumes_events
    • In PrimaryKeyDescription, replace
      ValueDef primary_key
      with
      RepositoryId primary_key
    • In HomeDescription, replace
      PrimaryKeyDef primary_key_def
      FactoryDefSeq factories
      FinderDefSeq finders
      with
      PrimaryKeyDescription primary_key
      OpDescriptionSeq factories
      OpDescriptionSeq finders

    Next, all parts of the "basic" Interface Repository are mutable, but
    most attributes of the Components interfaces are declared as readonly.
    I propose to remove the readonly modifier from

    • ProvidesDef::interface_type
    • UsesDef::interface_type
    • UsesDef::is_multiple
    • EventDef::event
    • ComponentDef::supported_interfaces
    • ComponentDef::base_component
    • ComponentDef::provides_interfaces
    • ComponentDef::uses_interfaces
    • ComponentDef::emits_events
    • ComponentDef::publishes_events
    • ComponentDef::consumes_events
    • PrimaryKeyDef::primary_key
    • HomeDef::base_home
    • HomeDef::managed_component
    • HomeDef::primary_key
    • HomeDef::factories
    • HomeDef::finders

    Last but not least, there seems to be some confusion about Primary Keys.
    When a Home is created with Repository::create_home, a ValueDef should
    be passed, while the terminology seems to dictate a PrimaryKeyDef instead.
    You can get a PrimaryKeyDef using HomeDef::create_primary_key, but that
    would be a chicken-egg scenario.

    Proposed resolution:

    • Change the ValueDef in Repository::create_home to PrimaryKeyDef
    • Move the create_primary_key() operation from HomeDef to Repository
  • Reported: CORBA 2.4.1 — Fri, 5 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Component assemblies do not follow composition pattern

  • Key: CORBA26-58
  • Legacy Issue Number: 4077
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    I have noticed that assemblies do not follow the composition pattern.
    Thus, assemblies cannot themselves be used as building blocks for other
    assemblies. I think part of this comes from the fact that installation
    and management of assemblies is mostly "magic" done behind the scenes by
    various installation and support utilities. In order to "reuse" an
    existing assembly, one must copy an existing assembly definition (I
    guess constructed completely by hand) to a new definition, which must
    then be tailored to incorporate the new strategy and pieces. This seems
    counter-intuitive, besides being manually intensive, for if an assembly
    does useful work, why would I want to expose its internal details just
    to take advantage of that usefulness? As pointed out by Mr. Dubois in
    issue 3939, because all of that "magic" is not specified by various
    formal interfaces, it is highly likely approaching certainty that
    assemblies will only work for the particular vendor on which they were
    built. Since I believe the intention was to promote interoperability in
    general and as much code automation as possible for components in
    particular, it would seem that we want to restrict the "magic" by taking
    the formalisms behind assemblies to another level.<p>

    I suggest that, just as a <i>composition</i> exists to tie a component,
    its home, and various configuration properties together, we can create
    for the CIDL grammar productions for an <i>assembly</i> to tie multiple
    compositions together. Subsequently, an assembly could be treated as a
    composition, to be used by other assemblies, only exposing selected
    facets or events from its constituent entities. I think there are a
    number of advantages to this approach: (1) It solves certain semantic
    ambiguities with assemblies, for instance whether facets, receptacles,
    and events are private or public to the assembly. (2) The assembly
    implementation, its XML, and its relation to its constituents and home,
    can be generated automatically from the CIDL description [we have been
    working on this extensively]. Our approach is to use an assembly
    exactly like a composition, as the realization of a component and home
    definition. Our research efforts imply that all of the assembly
    component and home code can be automatically generated - no user
    tailoring will be needed. (3) Because the assembly now acts as a
    component (composition), it can be reused by other assemblies without
    knowledge of its internal structure. (4) Activation of an assembly
    appears the same as for any other component; it merely requires formal
    specification of previously undefined interfaces to accomplish it, thus
    promoting portability and interoperability. (5) The assembly
    "deployment magic" becomes exposed through the interfaces above, thus
    removing several of the deployment tools and servers/services identified
    in the specification. The only real drawbacks I see are the complexity of the assembly
    productions (we can really get out of control with this) and that
    assemblies now have an actual code base rather than being "magical
    creatures" managed by the deployment tools. I guess these are both
    two-edged swords. There might be a run-time footprint change for all of
    these extra interfaces, but those had to be lying around in other places
    anyway.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Inter-component type semantics unclear

  • Key: CORBA26-57
  • Legacy Issue Number: 4075
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    The semantics of components of a particular type (session, entity)
    residing in a compatible container type that access components of a
    different type residing in a corresponding but different compatible
    container type are unclear. Are there any expected or preferred
    combinations? Are any disallowed or discouraged? See, for example, the
    discussion under issue 4025 on automated recovery. In his replies, Mr.
    Dubois seems to assume that entity components create transient (service
    or session) components but not the reverse. In the telecommunications
    domain, however, a session object may share access to an entity, and
    then create additional entities based on external events, even though
    the session itself is not persistent. Could someone please articulate
    the possibilities and their utility (or lack thereof)?

  • Reported: CORBA 2.4.1 — Wed, 22 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Typo in assembly element paragraph heading

  • Key: CORBA26-54
  • Legacy Issue Number: 4024
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, paragraph
    10.6.2.52, page 10-365. See also the DTD appendices document, orbos/99-08-05.

    The title of this paragraph heading is incorrect. The element is "usesport",
    not "usingcomponent". It has occasionally been hard to find the description
    because of this textual error.

  • Reported: CORBA 2.4.1 — Tue, 7 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

grammar rule for home_executor_body contradicts description

  • Key: CORBA26-53
  • Legacy Issue Number: 4011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In ptc/99-10-04 on page 15 the grammar rule of home_executor_body in chapter
    60.7 "Home Executor Definition" contains bars implying alternatives. These
    bars have to be removed to match the subsequent description.

  • Reported: CORBA 2.4 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

No Access to event filter form component

  • Key: CORBA26-52
  • Legacy Issue Number: 3998
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    As the CCM spec is not giving any mean (or very little) to fill in the
    filterable body part, no services are provided for a component to set its
    event filters when sending or receiving events.

    This seems to be a very usefull service to me for application such as:

    • limiting the number of events emitted by a component based on a config
      parameter (like messages with priority > config value can go out, other are
      discarded. when the config value change at runtime the filter could also
      change.
    • filtering events received from a notification channel.

    I agree that these 2 function could be achieve by user code in the component
    but it means that unecessary events are passed between components and the
    netwok load and CPU load is higher than necessary.

    I guess the point I am trying to make is that using the notification service
    without using filters and/or filterable body doesn't seem to make a lot of
    sense.

    What is the intend of the sepc on this issue?

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

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

Component home polymorphism

  • Key: CORBA26-60
  • Legacy Issue Number: 4079
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the CORBA Component Specification, orbos/99-07-01, and Persistent
    State Service issue #4074. Is there any reason why homes cannot support
    (manage) multiple component types? This seems like a perfect case for
    polymorphism; the only time you really need a new home type is when you
    change the behavior or have some other incompatibility. Is it possible
    to do instances of homes, one per component type (perhaps instances of
    components acting as managers for other components)? I simply do not
    understand why these are one-to-one with parallel but distinct
    derivations. I realize the requirements were to maximize code
    generation, but I don't see that this is a conflict.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Component assembly templates

  • Key: CORBA26-59
  • Legacy Issue Number: 4078
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    In a complex distributed environment, the implementation of highly
    available and highly reliable services requires redundant placement of
    software components in all their manifestations. Assemblies provide a
    nice, convenient way of specifying the deployment and activation of
    components and the connections that relate them for a particular
    purpose. Now, for various reasons and Fault Tolerant CORBA
    notwithstanding, in corporate reality this sequence and specification
    will occur in multiple places in basically identical fashion. About the
    only thing that changes are the host names and their network addresses;
    everything else from the hardware configuration to the size of the disk
    drives and file systems is (and inherently must be) exactly the same
    among all deployments. This, for example, is one technique to support
    geographic site failover.

    My question is, has anyone thought of a two or more stage XML process,
    one in which the package or assembly composition and deployment XML is
    specified as a template or configurable, parameterized entity, and
    another where the parameters have been substituted for "finalization"?
    This can occur at two distinct points in the life-cycle: one set of
    substitutions occurring when an artifact is deployed (installed?) on the
    various computer systems involved, and another when the home [and
    possibly individual instances] of the artifacts are activated
    (instantiated?) to run on those computer systems. My work in the
    telecom and defense industries has show that deployment of anything is
    rarely a singleton event; there are always redundancies, replications,
    and backups to take into account. Templates seem to provide a nice
    solution to all of the manual editing required.

  • Reported: CORBA 2.4.1 — Fri, 24 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

CCM : Session2Context naming

  • Key: CORBA26-67
  • Legacy Issue Number: 4204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Is there any reason to name the context interface for extended session
    components as Session2Context in module Components::Extended? Why not simply
    SessionContext like in the Basic module?

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM : Session2Context and Servants

  • Key: CORBA26-66
  • Legacy Issue Number: 4203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    How to activate servants by only using the Session2Context interface from
    the Extended module? It only offers operations to create references like
    create_ref() and create_ref_from_id() similar to those from the POA but no
    means to activate servants are available in the whole container API!

  • Reported: CORBA 2.4.2 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

No user access to filterable body in CCM spec.

  • Key: CORBA26-51
  • Legacy Issue Number: 3997
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The CCM spec seems to have make the choice to prevent the component
    implementor to fill in the filterable body part of a structured event sent
    to the a notification channel.

    What are the reasons of this choice?

    2 remarks:

    • The filtrable body part of a structured event seems to be the most usefull
      part of the event. Not using it (or leaving it to the container to fill in
      from obscure sources) doesn't seem to make a lot of sense.
    • Other standard bodies (like T1M1.5) are using the filterable body part of
      the event and are making the remainder of the boby (where the EventBase
      derived value type should be put) optional and unnecessary.

    Any comment/explanation of the choice is welcome.

  • Reported: CORBA 2.4 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3938. rejected

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

IDL question concerning CCM

  • Key: CORBA26-50
  • Legacy Issue Number: 3996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have the following question (problem). The Corba Component Model Spec
    (volume 1) defines the following :
    module CORBA_3 {
    module Components {
    interface Events

    { ... }

    ;
    ...
    module Events

    { ... }

    ;
    };
    };

    So the word 'Events' is used for defining an interface and a module!! Is
    this correct IDL, because ther JavaORB idl-compiler nor the ORBACUS
    idl-compiler is able to compile such idl.

  • Reported: CORBA 2.4 — Sat, 21 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM Events issue

  • Key: CORBA26-49
  • Legacy Issue Number: 3993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was researching the CCM Event Corba 3 to Corba 2.3 mappings in
    chapter 5 of Volume I, and found that the resulting interfaces did not
    permit a consumer to subscribe to a publisher because the interface
    type returned by the get_consumer_<name>() does not match the
    subscribe_<name)() parameter. I am not sure if I made a mistake when
    mapping the 3.0 to 2.3 idl or if it is a problem in the standard. I
    also provide an alternative that might work, though I'm sure it will
    need some work.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746

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

typo in connections element definition

  • Key: CORBA26-48
  • Legacy Issue Number: 3987
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the componentassembly DTD has a typo in the "connections"
    element definition. "connecthome" should be spelled "connecthomes"

    <!ELEMENT connections
    ( connectinterface

    connectevent
    connecthomes
    extension
    )* >
  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Deployment Object Life Cycles

  • Key: CORBA26-45
  • Legacy Issue Number: 3982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The description of the life cycle and system dynamics of the various
    objects that contribute to component deployment and execution is
    incomplete. From an implementation perspective, there are many run-time
    objects involved that contribute to, or are required for, the overall
    operation of a component. But the CCM does not adequately show the
    interrelationships among such objects. Even the most rudimentary
    implementation depends on the assumptions hidden behind these
    interrelationships.

    The following questions need to be addressed in order to build a
    portable implementation:

    1. Deployment support services:

    • What is the life cycle of the support services needed to create an
      Assembly object?
    • Do these already need to be executing in, known to, or exposed by one
      or more servers?
    • How are these services contacted in a dynamic environment?
    • Is this structure equivalent to the TINA DPE concepts?
    • What is the life cycle of the Assembly object itself?
    • When and how is an Assembly object deleted?

    2. Application servers, containers, homes, components:

    • What is the exact life cycle of these various objects?
    • The specification identifies how component instances are created. How
      are they deleted?
    • When and how is a home removed from a container?
    • When and how is a container removed from an application server?
    • When and how is an application server terminated?

    3. Related or referenced objects:

    • What is the life cycle of event channels?
    • Does the life cycle of objects vary if they are "private" to an
      assembly?
    • When and how are event subscriptions released from their publisher or
      emitter?
    • When and how are objects "registered" with the naming service or
      trader unregistered?

    A full and representative life cycle description of the run-time objects
    denoted above is necessary to understand the dynamic system model and
    its inherent limitations. This will be critical for systems that must
    exhibit very high reliability and availability. There appear to be many
    assumptions, particularly with respect to the deployment tools, that
    affect recovery operations from fault conditions. These must all be made
    explicit. Thus, the CCM description should include a comprehensive state
    transition model. This may be documented as cooperating or nested state
    machines for the various pieces.

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Services available for a basic container

  • Key: CORBA26-44
  • Legacy Issue Number: 3977
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CCM describes the services available for a basic container as being
    one of two sets: security, transactions, and naming or security,
    transactions, and persistence. Could someone please describe the exact
    services available to basic containers and the particular semantics for
    each? Are these differences related to one set for the component home
    and the second set for the instance?

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

push() versus push_event()

  • Key: CORBA26-43
  • Legacy Issue Number: 3955
  • Status: closed  
  • Source: Anonymous
  • Summary:

    See the CORBA Components Model specification, orbos/99-07-01, section
    5.6, pages 5-84 through 5-89, approximately.
    Could someone clarify the push() and push_event() operations, their
    purposes, and their interaction, if any. There is no description
    whatsoever of the relationship between the push() and push_event()
    operations, even though push_event() is declared in the
    inherited Components::EventConsumerBase. The producing component
    invokes its push() operation, which then performs any peculiar
    formatting to the event before transmission to the underlying channel
    through its container. It is unclear when, if ever, the push_event()
    operation will be invoked. A text search of the document reveals the
    operation appears only in the interface definition and its immediate
    descriptive paragraphs.

    Would a better model be to use push_event() as the interface to and from
    the container? (Perhaps this should be independent operations,
    produce_event() and consume_event()?) On the producer side, let push()
    perform any component specific formatting of the event before passing
    the [now modified] event on to push_event(). This latter interacts with
    the container to send the event to the event channel, as
    described. (Most push() implementations will do nothing to the event.
    This could be provided as a default generated implementation.) On the
    consumer side, push_event() will be invoked by the container as part of
    event delivery. The push_event() operation performs type checks, as
    described, before it invokes the consumer agent’s push() operation. This
    process correctly handles the semantics and permits suitable places to
    intercept or override event processing.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

An assembly is always mono-vendor ???

  • Key: CORBA26-41
  • Legacy Issue Number: 3939
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    Because the interfaces between the Assembly and the
    container/componentServer/servantActivator is not defined, these ones have
    to be vendor specific.

    Because the ExecutorSegmentBase and the HomeExecutorBase are not specified a
    component is always container specific.

    As a result an assembly provided by one vendor can only speak to
    container/componentServer/servantActivator provided by the same vendor and
    the container can only run (even in Java???) components that have
    specifically ported to it.

    The conclusion is that it is not possble to build an asembly that combine
    components build on different CCM platform. All of the component have to be
    ported to a single CCM platform.

    Is it what is intended?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Intent of Components::Events::(un)subscribe to bypass the notif. service ?

  • Key: CORBA26-40
  • Legacy Issue Number: 3938
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    a component wants to publish an event. So, it calls
    Components::Notification::Event::create_channel(). The container contact the
    (remote) Notification service, create a dedicated channel, connect to it and
    return an EventConsumerBase to be used by the component to push any event to
    the channel. Each time the push() method is called on the EventConsumerBase
    it will create a structured_event and push it to the notification channel.

    Now, another component (in another container/memory space/system) wants to
    receive these events. So it calls Components::Event::subscribe() on the
    first component passing a reference to an EventConsumerBase. The component
    internally calls Components::Notification::Event::subscribe() passing the
    remote EventConsumerBase reference. So now the container has to create a
    (local) strutured_push_consumer and connect it to the channel it has
    created. By doing this any event that it send to the channel will be bounced
    back to it so that it can then push them to the (remote) EventConsumerBase
    that have subscribed to the publish port.

    This scenario doesn't seem right to me because the notification service is
    then useless as all events are bounced back to the publisher. The container
    could just call the push() method on each registered EventConsumerBase.

    What seems to be really needed is a way to pass the reference to the
    NotificationAdmin back to the second component so that the second component
    can then subscribe through its own container to the Notification channel.

    Another possiblity would be that the subscribe call accept a (remote)
    strutured_push_consumer as parameter instead of the EventConsumerBase.

    The last solution is that the publisher port is not designed to work with
    the notification service but on its own.

    I am certaimly missing something!!!!!

    Could you explain how it is supposed to work?

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

Channel Setup for Emits ports.

  • Key: CORBA26-39
  • Legacy Issue Number: 3937
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I found 2 (possibly) contradictory statement in 99-10-04 for "emits" ports.

    1) in 62.4.1.2 The Event Interface

    EventConsumerBase obtain_channel (in string supp_name, in EventHeader hdr)
    raises (InvalidName);

    The obtain_channel operation is used by the component to obtain an
    EventConsumerBase which it can use to push events. This operation
    corresponds to an emits declaration in component IDL. The supp_name string
    identifies an Interoperable Naming Service (INS) name which is used to
    identify the SupplierAdmin to be used by CORBA notification. The name is
    associated with the SupplierAdmin thorough container specific configuration
    data. The obtain_channel operation may optionally specify the EventHeader
    required by CORBA notification which will be used for all events pushed to
    this channel. If hdr is present, it is prefixed to all events pushed to this
    channel. If not, it is defaulted as described in Section 66.4, "Event
    Management Integration," on page 66-252. If the supp_name is not recognized,
    the InvalidName exception shall be raised.

    2) in 66.4.2 Transmitting an event

    . channel lookup - for emitted events, this is the channel configured for
    general use at container start-up, for published events, this is the channel
    established by the container for the purpose of pushing this event type.

    Section 62.4.1.2 seems to imply that there can be a different event channels
    for each emit port while 66.4.2 seems to imply that there is only one event
    channel shared by all emits ports.

    What means "general use"?

    What is the truth/intent?.

    Could you make things clear?

    I certainly preffer 1)

  • Reported: CORBA 2.4 — Thu, 5 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

exception raised by Components::Events::subscribe()

  • Key: CORBA26-38
  • Legacy Issue Number: 3930
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The exception raised by Components::Events::subscribe() doesn't include the
    Components::ExceededConnectionLimit exception raised by the
    subscribe_source_name() 2.3 equivalent interface.

    It should be added.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

ExecutablePlacement definition

  • Key: CORBA26-37
  • Legacy Issue Number: 3929
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    In the componentAssembly DTD the executablePlacement is defined as follow:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

    It seems to me that the DTD should not enforce the componentimplref as this
    might depend on the deployment And there is no reason the assembler should
    know where the executable is going to be deployed. For example the
    componentimplref should be different between a Solaris, a Linux or an NT
    placement.

    Therefore I would propose to make componentimplref optional (as it is in
    homePlacement) and change the executablePlacement definition to:

    <!ELEMENT executableplacement
    ( usagename?
    , componentfileref
    , componentimplref?
    , invocation?
    , destination?
    , extension*
    )>
    <!ATTLIST executableplacement
    id ID #REQUIRED
    cardinality CDATA "1" >

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Local push() operation.

  • Key: CORBA26-36
  • Legacy Issue Number: 3928
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    When the component implementor wants to emits an event it has to use the
    push() operation from the local Event interface.

    It is not clear how the container will manage to discriminate the event and
    select the channel this event need to be send to.

    Nothing prevent a component to define several publisher and several emitters
    and nothing force the events to be of different types on all of these
    channels.

    So either the spec is not clear enough on this process or the local push
    method is missing some a parameter (like the emitter/publisher port name) to
    help the container do his job.

  • Reported: CORBA 2.4 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

repository element needed by softpkg DTD

  • Key: CORBA26-47
  • Legacy Issue Number: 3986
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05 the softpkg DTD is missing the "repository" element
    specification. It could be copied from corbacomponent DTD.

    <!ELEMENT repository
    ( ins

    objref
    link
    ) >
    <!ATTLIST repository
    type CDATA #IMPLIED >
  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

description element need to be added to corbacomponent.dtd

  • Key: CORBA26-46
  • Legacy Issue Number: 3985
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    in 99-08-05, the corbacomponent DTD is missing the "description" element
    specification. It should be the same as the other DTDs and can be copied
    from them

    <!ELEMENT description ( #PCDATA ) >

  • Reported: CORBA 2.4 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

equivalent interfaces issue

  • Key: CORBA26-42
  • Legacy Issue Number: 3954
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The equivalent interfaces as described within the document result in type mismatches when code is built to implement the functions generated from the CIDL component specification. That is, you cannot assign a consumer to a subscriber because the interfaces are parallel derivations and not an inheritance compatible derivations. The code prototypes must be changed to overcome this problem. We have tried three different approaches, but the one that seems to work best has the most impact to the IDL revisions.

  • Reported: CORBA 2.4 — Mon, 16 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Resolved by reference/clarification to 3746/ duplicate

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

Exchange rates need to be date based.

  • Key: CURR11-34
  • Legacy Issue Number: 2369
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Fbc: Need the ability to have date based exchange rates and for the
    manager to manage date based exchange rates.

    • Since we need to start accounting for dates for exchange of currencies
      and also for doing multi-currency money calculations, it would be nice to
      add settings on the ExchangeRateManager that is state based that allows for
      client configuration.
  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2RTF

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

Clearer information describing different rounding types is needed

  • Key: CURR11-33
  • Legacy Issue Number: 2368
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: RoundingType.ROUND_DOWN – The textual description needs to be far more
    explicit and/or include examples for both positive and negative numbers.
    Round toward zero? Is the rounding digit truly ignored? e.g. Let the
    internal precision be two.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF

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

Text indicating that vendors shall provide default values

  • Key: CURR11-32
  • Legacy Issue Number: 2367
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: .A Currency implementation should probably provide default values on behalf
    of a given valid stateIdentifier (i.e. MoneyCalculator.roundingType,
    MoneyCalculator.roundingDigit, MoneyCalculator.conversionType,
    MoneyCalculator.internalPrecision, MoneyFormatter.radixSymbol,
    MoneyFormatter.groupingSymbol, MoneyFormatter.negativePrefixSymbol,
    MoneyFormatter.inputMultiplier, MoneyFormatter.outputDivisor, locale,
    etc.). The standard should state that a vendor’s responsibility is to
    provide defaults, but leave the choice of the actual default values to the
    vendor. An interface allowing state to be set back to defaults should be
    considered.

  • Reported: CURR 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolve dis Currency 2 RTF

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

Extend ExceptionType enumerations

  • Key: CURR11-31
  • Legacy Issue Number: 2366
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need to add some additional enumerations to the ExceptionType enumeration.
    Some of the suggestions are the following : INVALID_VALUE,
    INVALID_STATE_IDENTIFIER, INVALID_DATE_RANGE, INVALID_CONVERSION_FACTOR,
    INVALID_STRING (when a provided string is empty or contains only white
    space), UNINITIALIZED_DATA, DATE_RANGE_FRAGMENTATION (when adding an
    exchange rate whose effective window in time would fragment existing
    exchange rates), INVALID_MULTIPLIER, INVALID_DIVISOR, STATE_IDS_EXHAUSTED.
    (Our implementation plan is such that INVALID_ROUNDING_DIGIT,
    INVALID_MULTIPLIER, etc. should really be discarded in favor of using
    INVALID_VALUE. Where an explicit value has already been specified in the
    submission (e.g. INVALID_ROUNDING_DIGIT) we will use it but hope for our
    recommendation to be heeded. For exception types that are necessary but
    were not included in the adopted submission, we will add our own (e.g.
    INVALID_STATE_IDENTIFIER, INVALID_VALUE) and use whenever necessary.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF, closed

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

Propose modification to the init method of CurrencyValue

  • Key: CURR11-36
  • Legacy Issue Number: 2381
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Propose the following interface change(s):
    void init(
    in wstring name,
    in wstring fractionName,
    in wstring mnemonic,
    in short numericCode,
    in wstring symbol,
    in wstring fractionSymbol,
    in short ratioOfFractionToWhole,
    in wstring description,
    in CBO::DTime introductionDate,
    in CBO::DTime expirationDate,
    in boolean isISO,
    in wstring ISOVersion,
    in StringCollection locales)
    raises(FbcException); - Note in this signature that
    scaleFactor, isExternalOutputShowingFractions, and
    isInternalOutputShowingFractions have been deleted.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF, closed

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

vendor implementations can implement only parts and interoperate-Statement

  • Key: CURR11-35
  • Legacy Issue Number: 2379
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification should state very explicitly how the subsystems/entry
    points (i.e. StateIdManager, CurrencyBook, ExchangeRateManager,
    MoneyFormatter, MoneyCalculator) locate each other if multiple vendor
    implementations (e.g. StateIdManager and MoneyFormatter implementation from
    one vendor and the remaining from another) can work with each other. If the
    intention though is to support homogeneous implementations only (i.e. A
    vendor solution supports all subsystems/entry points and only works with
    its one implementation) this needs to be called out in the specification
    instead.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    No action taken, this has always been viewed as a component.

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

More clarification on the semantics of string arguements for CurrencyValue

  • Key: CURR11-39
  • Legacy Issue Number: 2384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can the wstring argument(s) to setMnemonic(), setName(), setFractionName(),
    setSymbol(), setFractionSymbol(), or init() be empty strings or strings
    containing only white space? Acceptable arguments need to be discussed.

  • Reported: CURR 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF, closed

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

Missing details on preconditions on the Currency interface as a whole

  • Key: CURR11-38
  • Legacy Issue Number: 2383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Missing details on preconditions on the Currency
    interface as a whole

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed issue, resolved by Currency 2 RTF

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

Typos in CurrencyValue section

  • Key: CURR11-41
  • Legacy Issue Number: 2386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Typos in the section that describes setRatioOfFractionToWhole(). The second
    sentence should be “The ratio for United States Dollars is one hundred
    pennies to one dollar, which is 100. In cases where there is no minor part
    of a currency (e.g. Yen), this method should return a value of 1.”

  • Reported: CURR 1.0 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved by Currency 2 RTF, close

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

Legal value ranges for numerics in CurrencyValue init should be discussed

  • Key: CURR11-40
  • Legacy Issue Number: 2385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can the short numericCode presented to init() and setNumericCode() be <= 0?
    What are its legal values?
    Can the short ratioOfFractionToWhole provided to init() and
    setRatioOfFractionToWhole() be <= 1? What are acceptable values?
    Can the point in time represented by introductionDate be >= expirationDate
    in init() and setExpirationDate()/setIntroductionDate()?

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    close issue, resolved by Currency 2 RTF

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

missing description on the init method for CurrencyValue

  • Key: CURR11-37
  • Legacy Issue Number: 2382
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The init() method appears in the consolidated IDL Specifications portion of
    the standard, but does not appear and is not documented or discussed in
    section 2.3.6.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    closed issue, resolved by Currency 2 RTF

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

ISL changes to break dependency on Security and SECIOP modules

  • Key: CSIV2-10
  • Legacy Issue Number: 4141
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Section "IDL" Contains dependencies on the IDL of the security
    specification (the SECURITY, SECIOP, and SSLIOP modules)

    Description:

    The IDL for CSIv2 is dependent on the AssociationOptions type of the
    SECURITY module, and proposes some new types to be added to that module.

    The IDL for CSIv2 also proposes some new types to be added to the the
    SECIOP module.

    The IDL for CSIv2 is dependent on the SSL module.

    Proposed Solution:

    1. Move the AssociationOptions type out of the Security Mododule into a
    new base security module. (Issue for the security spec) - Make the
    Security Module dependent on this base security module.

    2. Add new constants to AssociationOptions.

    3. Add to this new base module the new types created for CSIv2 and
    previosly intended to be added to the security module (with the
    exception of the types related to type ScopedName, which will be the
    subject of another issue).

    4. Move the new SECIOP ComponentId and tag structure for TAG_SECIOP
    SEC_TRANS into the CSIIOP module, thus eleiminating the CSIv2 dependence
    on the SECIOP module.

    5. move the SSLIOP module into the CSIv2 spec. Change the SSLIOP modules
    dependency on the security module to a dependency on the new base
    security module.

    6. Change All references to the SECUIRTY module in modules GSSUP,
    SSLIOP. CSI, and CSIIOP to references to the base security module.

    7. Modify the GSSUP, CSI, and CSIIOP modules for idempotent inclusion.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

Multiple Privilege Authorities and Supported Naming Types

  • Key: CSIV2-9
  • Legacy Issue Number: 4118
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Multiple privilege authorities and multiple naming types yield
    combinatorial problems for the client.

    Discussion:

    This issue is sort of in the same regards to Issue 3973 where Ron thinks
    that having multiple target_name(s) in the AS_ContextSec is a bad idea, of
    which I agree.

    The type of the privilege_authorities field in the CSIIOP::SAS_ContextSec
    structure sequence<ServiceConfiguration>. It suffers the same problem,
    especially when combined with multiple supported naming types.

    It is completely hard to determine having multiple privilege authorities
    and the names that must be used to assert the identity for the privileges.
    In fact, the client may get back an AuthorizationToken that he doesn't
    understand, but will need to assert an identity for it's use, quite
    possibly with endorsement. Having multiple naming types supported per
    privilege authority is fine, but combine that with multiple ones, and you
    may get a decision problem for the client.

    It is better to be able to specify a one-to-one correspondence, locking
    down the combinations that a server will accept, and the client doesn't
    have to do any mucking about deciding what will work.

    Proposed Solution:

    Singularize the privilege authorities field.

    Unfortunately IDL has a hard time making a singular field become optional
    without doing something bizzare, such as:
    switch(boolean)

    { true: ServiceConfiguration privilege_authority }

    which requires a new type, etc.

    I have two proposals:

    Proposal 1:

    We signularize the field in name, i.e. "privilege_authority". Keep the
    sequence definition. However, stating in the specification at most one
    must be contained. This can be hinted at as well in IDL.

    struct SAS_ContextSec

    { Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; sequence <ServiceConfiguration,1> privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }

    ;

    Proposal 2:

    We specify a ServiceConfigurationSyntax tag for "none", and specify that
    the sequence of octet associated with it is empty.

    // Corresponding ServiceName for the SCS_None Syntax should be an empty
    // sequence octets.
    const ServiceConfigurationSyntax SCS_None = -1;

    struct SAS_ContextSec

    { Security::AssociationOptions target_supports; Security::AssociationOptions target_requires; ServiceConfiguration privilege_authority; sequence <Security::OID> supported_naming_mechanisms; }

    ;

    For efficiency I'm in favor of the second approach, because I can just
    look a the ServiceConfiguration::syntax field and know what to do. The
    first proposal causes me to look at the length first, index to the first
    element in the array, and then look at the syntax field.

    As an aside, I also wouldn't mind changing the sequence<Security::OID>
    type into a Security::OIDList, but that can be the subject of another
    issue. Also note, to be specific with the document I am pointing to, I
    used the "Security" definitions. Hopefully, we will follow one proposal to
    change the Security::AssociationOptions to CSIIOP::AssociationOptions and
    Security::OID and Security::OIDList to CSI::OID and CSI::OIDList
    respectively.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

inconsistent definition of target_name field

  • Key: CSIV2-6
  • Legacy Issue Number: 3973
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    target_name(s) field of struct AS_ContextSec is defined and described
    inconsistently in various places in the submission.

    Description:

    In section 6.1.4.1 this field is defined as

    sequence <Security::GSS_NT_exportedName> target_names;

    and defined as a list of target names.

    In the IDL in section B.7 this field is defined as

    sequence <Security::GSS_NT_exportedName> target_name;

    There are other places in the document where the singular form of this
    field name is used, including in the examples of the scenarios chapter.

    Proposed Solution:

    The change of this field to a list was not necessary, as it is difficult
    to make a case for requiring multiple target names within a single
    mechanism (as there is a multiple mechanism workaround).

    We should at least fix the inconsitencies in the document. If we keep
    the
    ability to express multiple targets, then we should also say something
    about the semantics of position in the list.

    The prefered solution would be to revert back to the singular form.

    Security::GSS_NT_exportedName target_name;

    and fix all references to this field accordingly.

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Make it singular. Close issue with revised text.

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

Format of GSSUP GSS exported name object undefined

  • Key: CSIV2-5
  • Legacy Issue Number: 3972
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Format of GSSUP GSS mechanism-independent exported name object, a
    special form of "flat" name as described below, is not defined.

    Description:

    >From RFC 2473 section 1.1.5 Naming

    > Different classes of name representations are used in conjunction
    > with different GSS-API parameters:
    >
    > - Internal form (denoted in this document by INTERNAL NAME),
    > opaque to callers and defined by individual GSS-API
    > implementations. GSS-API implementations supporting multiple
    > namespace types must maintain internal tags to disambiguate the
    > interpretation of particular names. A Mechanism Name (MN) is a
    > special case of INTERNAL NAME, guaranteed to contain elements
    > corresponding to one and only one mechanism; calls which are
    > guaranteed to emit MNs or which require MNs as input are so
    > identified within this specification.
    >
    > - Contiguous string ("flat") form (denoted in this document by
    > OCTET STRING); accompanied by OID tags identifying the namespace
    > to which they correspond. Depending on tag value, flat names may
    > or may not be printable strings for direct acceptance from and
    > presentation to users. Tagging of flat names allows GSS-API
    > callers and underlying GSS-API mechanisms to disambiguate name
    > types and to determine whether an associated name's type is one
    > which they are capable of processing, avoiding aliasing problems
    > which could result from misinterpreting a name of one type as a
    > name of another type.
    >
    > - The GSS-API Exported Name Object, a special case of flat name
    > designated by a reserved OID value, carries a canonicalized form
    > of a name suitable for binary comparisons.

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    No Data Available

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

CSIv2 Protocol

  • Key: CSIV2-1
  • Legacy Issue Number: 3906
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

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

    Document: orbos/2000-08-04 CSIv2 Joint Submmission
    Subject: Protocol and IOR incompatabilities for Identity Assertion
    Severity: Critical

    Summary:

    The CSIv2 protocol is too vague on acceptance of identity tokens.
    This yeilds an uneeded and unwarranted complexity in implemenations.
    Vague protocols are not a good idea. It limits interoperability.

    Discussion:

    In the IOR, the CSIv2 protocol states a list of OIDs signifying the
    acceptable forms of an IdentityToken delivered by the client. This list of
    acceptable name forms is stated only to apply to GSS_NT_ExportedName
    types. There are no OIDs signifying that an X.501 DN or X.509 Public Key
    Certificate are acceptable.

    It seems that the specification is written so that both X.501 DNs and
    X.509 Certificate chains are always acceptable. This requirement would
    cause all clients to send only X.501 DNs or X.509 Certificate Chains,
    regardless of the server listing its acceptable name types. Also, there is
    no indication of which of an X.501 DN or X.509 Public Key Certificate
    Chain is desirable. This is vague.

    It is completely unwarranted to tell all CSI mechanisms that they must
    support X.509 DNs or X.509 Certificate chains. These name forms may not be
    relevant to the mechanism at all. The mechanism may not support public key
    technology, have facility for verification of certificates, may not be
    able to parse X.501 DNs or X.509 Certificate Chains, and further more, but
    not least, the security mechanism may not know what to do with it. One
    example, might be an TCPIP CSI mechanism that only wants to accept
    Kerberos principal names, Unix user names, or NT user names. DNs or
    Certificate Chains are irrelevant.

    With that in mind, a client should not be allowed to send the server an
    X.509 certificate chain or an X.501 DN at it. Those name forms are not
    acceptable to the server.

    The easiest way around this problem is to allocated OIDs under the OMG OID
    that signify the acceptance of each of the X.509 DNs and X.509 Public Key
    Certificate chains. Servers that accept X.501 DNs and X.509 Public Key
    Certificate chains for identity assertion shall list the appropriate OIDs
    in the IOR.

  • Reported: CSIv2 1.0b1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Apply revised text and close issue

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

OIDs

  • Key: CSIV2-12
  • Legacy Issue Number: 4143
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    There is a need to define OIDs, at least one for GSSUP. However, an OID is
    represented by a sequence of positive integers, encoded as a octet
    sequence. The encoding has the property that two encodings are equivalent
    if and only if their definitions are equivalent (which is something ASN.1
    DER is not particulary good at).

    We cannot define a costant in IDL for a sequence of octets. However, I've
    seen an number of ASN.1 compilers and it seems that the internal form of
    the definition of an OID is a string of natural numbers in base 10
    separated by dots. This is a parseable representation, and widely used.

    I suggest that we introduce a definition, possibly a type, for and OID
    string representation.

    module CSI

    { // // An OID String Representation. // The OID is represented in dot format. // For example, "2.23.130.1.1.1". // typedef string OIDStringRep; }

    ;

    module GSSUP

    { const OIDStringRep GSSUP_OID_DEF = "2.23.130.1.1.1"; }

    ;

    This will allow ASN.1 compilers to at least map from this internal string
    representation if they don't already do so.

    What do you think? If there is consensus, I'll raise an issue, and we can
    resolve it.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

Module suggestions

  • Key: CSIV2-11
  • Legacy Issue Number: 4142
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    In looking at it, I think CSI would make a good "base" module.

    Since other modules are only related to CSI, such as CSIIOP and GSSUP, I
    see no reason why those two modules cannot depend on CSI.

    Define in CSI:

    AssociationOptions
    GSSToken
    GSS_NT_ExportedName
    X509CertificateChain
    X501DistinguishedName

    As part of another issue, change the use of ScopedName in GSSUP to
    CSI::GSS_NT_ExportedName.

    As yet another issue, is to get rid of the ASN.1 dependance on
    X509CertificateChain and X501DistinguishedName and somehow make it
    consistent with the PKI spec. Or get rid of them all together, and just
    use ExportedName format with proper OIDs.

  • Reported: CSIv2 1.0b1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Same as issue 4141

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

GSSUP Names are inconsistent other security mechanisms.

  • Key: CSIV2-2
  • Legacy Issue Number: 3922
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Joint Submission
    Subject: GSSUP Names are inconsistent other security mechanisms.
    Severity: Medium

    Summary:
    The names supplied in the InitialContextToken for the UserName password
    scheme invents a name type called a Security::ScopedName. This is just yet
    another name type that must be dealt with and is completely inconsistent
    with anything else used for names. The contents of the scope and the name
    are underspecified.

    Discussion:
    The structure should allow for all forms of name types. The easiest
    way to do accomplish consistency is to use a GSS exported Name type.

    struct InitialContextToken

    { Security::GSS_NT_ExportedName username; Security::UTF8String password; }

    ;

    That way a password database can even store names that are DN's,
    X509GeneneralNames, Kerberos Names, NT Usernames, etc.

  • Reported: CSIv2 1.0b1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text

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

INVALID recommended cipher suites

  • Key: CSIV2-8
  • Legacy Issue Number: 3975
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:

    Section "5.2.1" Recommended SSSL/TLS Ciphersuites" incorrectly names 4
    cipher suites.

    Description:

    The first 4 cipher suites in the recommended list do not exist as they
    were named. The invalid appearing in this list are:

    TLS_RSA_EXPORT_WITH_RC4_128_MD5
    SSL_RSA_EXPORT_WITH_RC4_128_MD5
    TLS_DHE_DSS_EXPORT_WITH_DES_CBC_SHA
    SSL_DHE_DSS_EXPORT_WITH_DES_CBC_SHA

    Proposed Solution:

    Replace the invalid names listed above with the following:

    TLS_RSA_WITH_RC4_128_MD5
    SSL_RSA_WITH_RC4_128_MD5
    TLS_DHE_DSS_WITH_DES_CBC_SHA
    SSL_DHE_DSS_WITH_DES_CBC_SHA

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Make the replacements as suggested above.

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

CSIv2 IOR Tagged component Identifier values

  • Key: CSIV2-7
  • Legacy Issue Number: 3974
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: orbos/2000-08-04 CSIv2 Final Submission
    Issue:
    tagged component identifier values must be assigned for
    components TAG_NULL_TAG, TAG_CSI_SEC_MECH_LIST, and
    TAG_SECIOP_SEC_TRANS.

    Description:

    const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = aa;
    const IOP::ComponentId TAG_NULL_TAG = bb;
    const IOP::ComponentId TAG_SECIOP_SEC_TRANS = cc;

    Numerical values must be reserved within the OMG tag list to
    identify these new tagged components. These values will replace the
    temporary values, "aa", "bb", and "cc" appearing in the submission.

    Discussion:

    Proposed Solution:

    const IOP::ComponentId TAG_CSI_SEC_MECH_LIST = 33;
    const IOP::ComponentId TAG_NULL_TAG = 34;
    const IOP::ComponentId TAG_SECIOP_SEC_TRANS = 35;

  • Reported: CSIv2 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    editorial, close issue

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

GSSUP names are incompatible with the Identity Token

  • Key: CSIV2-4
  • Legacy Issue Number: 3948
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The name type used in the GSSUP mechanism for Client Authentication over
    the transport name type is not convertible to anything used by the
    Identity Token. This situation becomes a problem when on the server side
    where you need to quote, (i.e. identity assert) the client's authenticated
    identity to another CSIv2 CORBA outcall on behalf of the client.

  • Reported: CSIv2 1.0b1 — Fri, 13 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue as duplicate of 3922

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

Service ID missing

  • Key: CSIV2-3
  • Legacy Issue Number: 3932
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    CSIV2 service context element, SecurityAttributeService,
    must be assigned a service id.

    Description:

    const ServiceId SecurityAttributeService = xx;

    A numerical value must be reserved within the OMG service
    id space to identify CSIv2 service context elements. The
    value will replace the temporary value ("xx") appearing in the
    submission.

    Discussion:

    Proposed Solution:

    const ServiceId SecurityAttributeService = 15;

  • Reported: CSIv2 1.0b1 — Tue, 3 Oct 2000 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    No action needed from the FTF, purely administrative

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

StateID Exception

  • Key: CURR11-30
  • Legacy Issue Number: 2363
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need exceptions for stateId indicating that one was never created from the
    StateIdManager for all methods that take stateId.

  • Reported: CURR 1.0 — Mon, 11 Jan 1999 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved is Currency 2 RTF, closed

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

Change double to short for internal precision

  • Key: CURR11-29
  • Legacy Issue Number: 2271
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change double to short for internal precision

  • Reported: CURR 1.0 — Fri, 18 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF

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

Add idl and text to describe the getAllExchangeRates method

  • Key: CURR11-28
  • Legacy Issue Number: 2270
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add idl and text to describe the getAllExchangeRates method

  • Reported: CURR 1.0 — Fri, 18 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF

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

Add text for formatter that the format string will be used for parsing

  • Key: CURR11-27
  • Legacy Issue Number: 2269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add text for formatter that the format string will be used for parsing.
    Clarify the formatting string and how it is used.
    This way the parser routine will use: M##,###.00 to help it parse: RUR10,00
    This also means the radix character was set to: "," and the grouping symbol was set to: "."
    Show an example to distinguish between what the pattern gives you and what the actually settings of the characters give you.

  • Reported: CURR 1.0 — Thu, 17 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved in Currency 2 RTF

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

Change text description of behavior of ROUND_FLOOR and ROUND_CEILING

  • Key: CURR11-26
  • Legacy Issue Number: 2268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change text description of behavior of ROUND_FLOOR and ROUND_CEILING. The descriptions are mixed between the two.

  • Reported: CURR 1.0 — Thu, 17 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Change text in spec describing the correct behaviour for the rounding rules

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

Clarify on comparison methods of the calculato

  • Key: CURR11-25
  • Legacy Issue Number: 2267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify on comparison methods of the calculator that no rounding etc. would take place before the
    comparison, it would be the raw numbers in each money instance that is compared.

  • Reported: CURR 1.0 — Thu, 17 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    Already fixed in issue # 2415

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

clarification on how the "#" is used in the money formatter

  • Key: CURR11-24
  • Legacy Issue Number: 2265
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Need more clarification on how the "#" is used in the money formatter -
    i.e. if the digit is zero and doesn"t contribute to the value, 0 will not show.

  • Reported: CURR 1.0 — Thu, 17 Dec 1998 05:00 GMT
  • Disposition: Resolved — CURR 1.1
  • Disposition Summary:

    resolved and closed in Currency 2 RTF

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

CSIv2 TSS state machine lacks states to enforce target policy for

  • Key: CSIV2-21
  • Legacy Issue Number: 4326
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    While in state "Waiting for Request", The TSS state machine will accept
    an unprotected request, without consideration of the target CSIv2
    security policy.

    Also the specification does not describe what is supposed to happen when
    a target's mechanism definitions/policy requires SAS (i.e. client
    authentication) and the CSS does not send an EC.

  • Reported: CSIv2 1.0b1 — Wed, 30 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

The encoding of GSSUP ICT's is not clearly specified

  • Key: CSIV2-20
  • Legacy Issue Number: 4308
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: http://cgi.omg.org/pub/csiv2-ftf/csiv2-031401.pdf

    Isuse: The encoding of GSSUP ICT's is not clearly specified

    Para 48 states:

    [48] The format of a GSSUP initial context token shall be as defined in
    [IETF RFC 2743]
    Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
    GSSToken shall
    contain an ASN.1 tag followed by a token length, an authentication
    mechanism
    identifier, and a CDR encoded sequence of octets corresponding to a
    GSSUP inner
    context token as defined by the type GSSUP::InitialContextToken in
    Section 16.9.2,
    “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
    (and
    repeated below).

    and section
    16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats
    states

    // The following structure defines the inner contents of the username
    // password initial context token. This structure is CDR encoded in a
    // sequence of octets and appended at the end of the username/password
    // GSS (initial context) Token.

    struct InitialContextToken

    { CSI::UTF8String username; CSI::UTF8String password; CSI::GSS_NT_ExportedName target_name; }

    ;

    Proposed Resolution:

    Change para 148 to the following:

    [48] The format of a GSSUP initial context token shall be as defined in
    [IETF RFC 2743]
    Section 3.1, “Mechanism-Independent Token Format,” pp. 81-82. This
    GSSToken shall
    contain an ASN.1 tag followed by a token length, an authentication
    mechanism
    identifier, and an encapsulation octet stream containing a CDR encoded
    GSSUP inner
    context token as defined by the type GSSUP::InitialContextToken in
    Section 16.9.2,
    “Module GSSUP - Username/Password GSSAPI Token Formats,” on page 16-59
    (and
    repeated below).

    change the relevant comment in
    16.9.2 Module GSSUP - Username/Password GSSAPI Token Formats
    to the following

    // The following structure defines the inner contents of the username
    // password initial context token. This structure is CDR encoded in an
    // encapsulation octet stream and appended at the end of the
    username/password
    // GSS (initial context) Token.

  • Reported: CSIv2 1.0b1 — Tue, 15 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

New minor codes for NO_PERMISSION Exception in CSIv2

  • Key: CSIV2-16
  • Legacy Issue Number: 4277
  • Status: closed  
  • Source: International Business Machines ( Dr. Daniel T. Chang)
  • Summary:

    Don,
    >
    > Although the minor codes of the NO_PERMISSION exception have been defined
    > in Table 4-7, Section 4.5, of the 7/21/2000 version of the CSIv2
    > Specification, in order
    > for the server to properly communicate the caused of the NO_PERMISSION
    > exception
    > to the client, we would like to propose the additional minor codes to the
    > NO_PERMISSION
    > exception.
    >
    > ***********************************************************************
    > NO_PERMISSION authentication error minor codes: range 1-100
    > (Note: The following minor codes are defined in the current CSIv2 spec:
    >
    > 1 - Invalid evidence
    > 2 - Invalid mechanism
    > 3 - Conflicting evidence
    > 4- No Context
    > )
    > The new proposed minor codes for NO_PERMISSION exception: The numbering
    > scheme was chosen to group errors into areas of
    > similarity.
    >
    > 5 - user id not defined to security system - the user may select another
    > userid
    > 6 - user id revoked by security system - the user may select
    > another userid
    >
    > 11 - password invalid for this userid - the user may correct the password
    > 12 - password expired - the user may select another userid
    >
    > 20 - credentials expired - the user may select different credentials or
    > renew them(e.g. by reissuing kinit)
    > 22 - credentials invalid - the user may select different
    > credentials, (e.g.
    > by kinit, or specifying a different PKCS certificate handle)
    >
    > 52 - new password doesn't meet installation requirements
    >
    > 60 - general authentication error - the user should resubmit his
    > credentials, but not additional information as to what is in error is
    > provided.
    > ******

  • Reported: CSIv2 1.0b1 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

How to Partition the ServiceConfiguration syntax space to support vendor sp

  • Key: CSIV2-15
  • Legacy Issue Number: 4268
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    We need to define how the namespace of ServiceConfiguration syntax
    identifiers (used in privilege_authorities) is to be partitioned
    so that individual vendors have some identifiers reserved for
    their use (i.e. the definition of vendor specific syntaxes).

  • Reported: CSIv2 1.0b1 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Recommend closure with revised text

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

CSIv2 Issue: SECIOP does not have multiple addresses.

  • Key: CSIV2-19
  • Legacy Issue Number: 4293
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    This issue is the exactly the same issue as issue 4200, which
    is for TLS (SSL) transport addresses. It notes that the
    component for a SECIOP transport needs to support multiple
    addresses.

    The recommended solutioin to this issue is to adopt the analogous
    resolution to the 4200 issue.

  • Reported: CSIv2 1.0b1 — Thu, 3 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

Inability to specify per method target security requirements

  • Key: CSIV2-18
  • Legacy Issue Number: 4282
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The CSIv2 mechanism definition schema, soes not provide a way to
    associate mechanisms with subsets of the methods of an object.

    Discussion

    EJB method-permissions may be associated with subsets of methods, such
    that a class of EJB objects may have some protected and some unprotected
    methods. Where by protection I mean, the caller must be authenticated
    and be in a authorized role, to access the method. Some methods of an
    EJB may be available to unauthenticated callers, while others may limit
    access to only specific authenticated callers.

    Given a mixed protection object, how would one define its IOR such that
    it could be affectively accessed by its clients without

    1. eliminating unauthenticated access to the object

    that is, mark the target as authentication required

    2. causing unnecessary authentications and usurping the
    clients perogative to only authenticate when it is required to or
    chooses to.

    that is, mark the target as authentication supported and tell the
    client to authenticate if it can

    3. causing failed attempts because the client does not know that
    the target requires authentication

    that is, mark the target as authentication supported and let the
    client authenticate if it wants to

    Would it be appropriate to add information to the IOR, that indicates
    that whether the object will check permissions, such that a client
    normally operating in mode 3, would know when it would probably do
    better in mode 2?

    Should a CSIv2 IOR which principally defines (authentication and msg
    protection mechanisms) carry additional information about the
    authorization policy of the object? There is obviously some precedent
    for doing so in the privilege authorities field.

  • Reported: CSIv2 1.0b1 — Tue, 24 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with no change as this does not apply to CSIv2

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

How to Partition the AuthorizationElementType regarding vendor extensions

  • Key: CSIV2-23
  • Legacy Issue Number: 4330
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    We should define how the namespace of AuthorizationElementType
    identifiers (used in authorization tokens) is to be partitioned
    so that individual vendors have some identifiers reserved for
    their use (i.e. the definition of vendor specific type identifiers).

  • Reported: CSIv2 1.0b1 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

clarification of csiv2 stateful conformance requirements

  • Key: CSIV2-22
  • Legacy Issue Number: 4327
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The specification is currently weak on its description of what must
    be done by a TSS with respect to designating a "stateful" value in its
    IOR's, and in defining under what circumstances a TSS may claim stateful
    conformance. In particular, the spec does not currently state whether or
    not a TSS must be stateful for all of its mechanism definitions, at all
    of its target objects in order to claim stateful conformance. The
    following paragraphs should be included to clarify these two issues.

  • Reported: CSIv2 1.0b1 — Wed, 30 May 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text

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

Issue: inconsistent definition of AuthorizationToken

  • Key: CSIV2-14
  • Legacy Issue Number: 4221
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    Document: csiv2-011701

    In section 16.2.3

    The AuthorizationToken type is defined inconsitently with respect to its
    definition in IDL module CSI.

    typedef sequence <X509AuthorizationElement> AuthorizationToken;

    in module CSI

    typedef sequence <AuthorizationElement> AuthorizationToken;

    The definition in 16.2.3 should be chnaged to agree with that in the IDL

  • Reported: CSIv2 1.0b1 — Tue, 13 Mar 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Apply revised text and close issue.

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

Module SSLIOP Does Not Contain Host

  • Key: CSIV2-13
  • Legacy Issue Number: 4200
  • Status: closed  
  • Source: Mansurus LLC ( Donald Flinn)
  • Summary:

    In some situations, e.g. a multi-homed system, there would have to be a profile for each port number supported by SSL. This is inefficient. Adding a String host_name to the struct SSL in the Module SSLIOP would resolve this issue.

  • Reported: CSIv2 1.0b1 — Mon, 12 Feb 2001 05:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    Close issue with revised text.

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

No Tokens in EstablishContext Message

  • Key: CSIV2-17
  • Legacy Issue Number: 4281
  • Status: closed  
  • Source: Oracle ( Ron Monzillo)
  • Summary:

    The spec doesn't say whether or not an EstablishContext with none
    of cleint authentication, identity, or authorization token is
    legitimate.

    I don't think we need the ability to send such mecahnisms (for
    unprotected requests), as we would just send the request without a CSIv2
    service context element. The only down side I can see, to writing this
    empt EstbalishContext out of spec, would be that a client could not use
    it to get feedback from a TSS in the form of CompleteEstablishContext,
    indicating that the TSS supports CSIv2.

    We must indicate that this is either an invalid msg, or state that it
    must be supported (and what it's semantics should be).

  • Reported: CSIv2 1.0b1 — Tue, 24 Apr 2001 04:00 GMT
  • Disposition: Resolved — CSIv2 1.0
  • Disposition Summary:

    close issue with no change

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

Urgent issue: Alignment of LocateReply body

  • Key: CORBA25-53
  • Legacy Issue Number: 4314
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    In CORBA 2.3, a GIOP 1.2 LocateReply message made no requirements as to
    the alignment of the LocateReply body. This meant that the LocateReply
    body needed to be aligned only on a 4-byte boundary. With the resolution
    for issue 2521, published with CORBA 2.4, the spec was changed to require
    alignment of the LocateReply body on an 8-byte boundary.

    The change is incompatible with the CORBA 2.3 definition because the receiver
    must know where to look for the ReplyBody in the the byte stream following
    the message header. (The LocateReply header is 12 bytes long, so changing
    the alignment rules means that the LocateReply body has to start at offset 12
    for CORBA 2.3, but has to start at offset 16 for CORBA 2.4.)

    The change in alignment did not result in a version change of GIOP,
    despite the incompatibility, so it appears that the change is simply illegal.

    There are already deployed products that use the CORBA 2.3 alignment
    rule; therefore, we cannot deploy a CORBA 2.4 compliant product without
    breaking interoperability with already deployed CORBA 2.3 compliant products.

    So, I'd like to request that we back out the change and continue to
    permit a LocateReply body to be aligned on a 4-byte boundary. There was
    never any need to change the alignment of the LocateReply body anyway because
    a LocateReply header has fixed length and, therefore, cannot ever cause
    remarshaling of the body due to a size change in the header. In other
    words, the motivation quoted in the spec for the 8-byte alignment rule
    isn't founded on fact, and the change should never have been made in the first
    place. (See issue 4309 for details.)

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    No Data Available

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

Incorrect table in section 15.4

  • Key: CORBA25-52
  • Legacy Issue Number: 4311
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The table on page 15-31 (Table 15-3 "GIOP Message Types and Originators")
    is in error. For CloseConnection, it shows that only the server can
    send this message but, in GIOP 1.2, either client or server can send
    the message, as detailed in 15.5.1 and 15.4.7.

    Also. in 15.4.7, we have:

    In GIOP version 1.2 both sides of the connection may send
    the CloseConnection message.

    That should be "must", not "may".

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Table 15-2 is missing entry for tk_local_interface

  • Key: CORBA25-48
  • Legacy Issue Number: 4242
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    Add the missing entry with the same information as tk_objref.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    add the missing table entry with the same information as tk_objref

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

GIOP 1.2 AddressingDisposition processing on the client side

  • Key: CORBA25-47
  • Legacy Issue Number: 4213
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    If the server ORB sends back a NEEDS_ADDRESSING_MODE reply to the client indicating the prefered
    addressing disposition, then is the client ORB required to 'cache' the prefered addressing
    disposition per object reference, and use it for further requests to the server ?

  • Reported: CORBA 2.4.2 — Wed, 28 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    to close without revision

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

Fixed point marshalling

  • Key: CORBA25-46
  • Legacy Issue Number: 4198
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    I have a query about the intended marshalling format for Fixed. Is the
    sending ORB always required to transmit the number of digits specified
    in the IDL, or is it permitted to transmit fewer if there are leading
    zeros?

    Consider transmitting 123.45 as fixed<6,2>. Is the ORB permitted to
    transmit

    12 34 5c

    or must it send the leading zero (plus another zero to pad the first
    octet):

    00 12 34 5c

    In both cases, the receiving ORB knows it is expecting a scale of 2,
    and the sign half-octet tells it where the digits end, so it can
    correctly unmarshal the value as 123.45.

    The discussion of issue 3431 suggests that the first option is not
    permitted, and leading zeros must always be sent. However, the 2.4
    GIOP spec makes no mention of how many digits should be sent. The
    specification should be clarified to either explicitly permit or
    explicitly forbid stripping of leading zeros.

  • Reported: CORBA 2.4.2 — Wed, 7 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with clarification revision

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

Null termination of strings

  • Key: CORBA25-45
  • Legacy Issue Number: 4113
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.2.7 of the CORBA 2.3 spec, which describes the CDR encoding
    of strings, includes the following sentence in the first paragraph:

    "Both the string length and contents include a terminating null."

    It is not clear from this whether exactly one terminating null is required,
    or whether more than one null can be included, with the string being terminated
    by the first null.

    Since IDL strings cannot include nulls (see 3.10.3.2: "OMG IDL defines the string
    type string consisting of all possible 8-bit quantities except null"), any
    additional nulls following the first terminating null cannot be part of the
    string, and it therefore seems reasonable to ignore them.

    Proposed Resolution:

    Change the above sentence in section 15.3.2.7 to:

    "Both the string length and contents include at least one terminating null."

    Also make the same change to the corresponding sentence in the third paragraph
    of section 15.3.2.7 describing GIOP 1.1 wide strings.

  • Reported: CORBA 2.4.1 — Fri, 8 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    To close with clarification revision

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

Incorrect text in 15.4.6.2

  • Key: CORBA25-51
  • Legacy Issue Number: 4309
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    15.4.6.2, "LocateReplyBody" says:

    In GIOP version 1.0 and 1.1, Locate reply bodies are marshaled into
    the CDR encapsulation of the containing Message immediately following
    the Reply Header. In GIOP version 1.2, the Reply Body is always
    aligned on an 8-octet boundary. The fact that GIOP specifies the
    maximum alignment for any primitive type is 8 guarantees that
    the ReplyBody will not require remarshaling if the Locate Reply
    Header are modified.

    The final sentence doesn't make sense because the LocateReply header is
    a fixed-length header and therefore can't possibly cause remarshalling.

    I suggest to delete the final sentence of this para.

  • Reported: CORBA 2.4.2 — Wed, 16 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see resolution of Urgent Issue 4314

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

GIOP 1.1 Fragment problem

  • Key: CORBA25-50
  • Legacy Issue Number: 4299
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is nothing in the specification that explicitly states whether the
    data in the body of a GIOP 1.1 Fragment message is marshalled relative
    to the Fragment header or relative to the unfragmented message as a
    whole.

    The restriction in GIOP 1.2 that all fragments but the last must have a
    multiple of 8 bytes, and the careful padding of the GIOP 1.2 Fragment
    header to 16 bytes both strongly suggest that GIOP 1.1 fragments should
    be marshalled only relative to the fragment header.

    Proposed Resolution:

    In section 15.4.9, right after the paragraph that reads:

    "A primitive data type of 8 bytes or smaller should never be broken
    across two
    fragments."

    add the following paragraph:

    In GIOP 1.1, the data in a fragment is marshalled with alignment
    relative to its position in the fragment, not relative to its position
    in the whole unfragmented message.

  • Reported: CORBA 2.4.2 — Fri, 11 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Accept proposal above

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

tk_indirect

  • Key: CORBA25-49
  • Legacy Issue Number: 4294
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    I don't understand why tk_indirect isn't allowed as a top-level typecode.
    This causes servere performance penalties for RMI-IIOP because the Java to IDL
    mapping requires that Java objects of declared type java.lang.Object are
    marshalled as CORBA anys. In the case of a Vector or HashTable with 100
    elements, this means that 100 anys must be marshalled. If all of these are
    of actual type foo, the restriction on tk_indirect means that all 100 of
    these data values must repeat the typeCode for foo, which could be very large.
    This causes very substantial overheads, since the space and time needed to
    marshal the TypeCode for foo can greatly exceed that needed to marshal the
    data for foo.

    I understand why a nested tk_indirect cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, I don't think this
    restriction needs to apply to a top-level TypeCode. We have made this
    change experimentally without any adverse effects and we have discovered that
    using tk_indirect for all the top-level foo TypeCodes after the first one can
    speed up some common scenarios by at least a factor of 5 on end-to-end
    measurements. There seems to be no downside to making this change.

    I would therefore like to propose the following change to the section headed
    "Indirection: Recursive and Repeated TypeCodes" within section 15.3.5.1:

    Change the first bullet from:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
    some other encoded TypeCode.

    by the following words:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode, or from one top-level TypeCode to another. Indirected TypeCodes
    nested within a top-level TypeCode can only reference TypeCodes that are part
    of the same top-level TypeCode, including the top-level TypeCode itself.
    Indirected top-level TypeCodes can reference other top-level TypeCodes but
    cannot reference TypeCodes nested within some other top-level TypeCode.

    If this change finds favour, then we need to work out how it can be brought
    into GIOP without causing problems interoperating with older ORBs that insist
    on the stronger restriction of the current spec. This could perhaps be
    added to the "wish list" for GIOP 1.3.

  • Reported: CORBA 2.4.2 — Fri, 4 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close this issue and add it to the GIOP wish list

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

operation get_implementation() referenced but not declared

  • Key: CORBA26-32
  • Legacy Issue Number: 3785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In chapter 69.9.1.2 Deployment Scenario on page 329 of ptc/99-10-04.pdf the
    operation get_implementation() is refered as if it belongs to the
    ComponentInstallation interface (called only "Installation"), but the
    specification of that interface lacks it.

  • Reported: CPP 1.1 — Thu, 17 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    Duplicate, close

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

Pbl: Improper mapping rule from IDL3 to IDL2 when dealing with events.

  • Key: CORBA26-31
  • Legacy Issue Number: 3746
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Dealing with the following IDL3 definition, a problem arises when
    generating the IDL2 definitions (complete IDL2 mapping is enclosed at
    the end of this mail).

    module example {
    valuetype AnEvent : Components::EventBase

    { public string value; }

    ;

    component Producer

    { publishes AnEvent output; }

    ;

    component Consumer

    { consumes AnEvent input; }

    ;
    };

    According to the chapter 5 of the CCM specification, the publishes
    definition of the Producer component is mapped to the following
    definition (excerpt).

    interface Producer : Components::CCMObject

    { Components::Cookie subscribe_output(in ::example::ProducerEventConsumers::AnEventConsumer consumer) raises (Components::ExceededConnectionLimit); }

    ;

    In the mean time, the consumes definition of the Consumer component is
    mapped to the following definition.

    interface Consumer : Components::CCMObject {

    ::example::ConsumerEventConsumers::AnEventConsumer
    get_consumer_input();

    };

    We can see that two versions of the "AnEventConsumer" interface have
    been defined in two distincts modules. Thus the following Java
    lines are not correct:

    example.Producer p = ...;
    example.Consumer c = ...;

    p.subscribe_output(c.get_consumer_input());

    The Java compiler will refuse to compile the last one, producing an
    error like "BadTypeCoerce". However, in the IDL3 definitions, both
    components have been defined in order to be used together. (sic!)

    Thus, we think that the mapping for a Consumer should not be based on
    the component definitions, but on the event definition itself. It
    would then avoid multiple (incompatible) definitions of the consumers.
    This mapping could be defined in two distinct ways.

  • Reported: CPP 1.1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue on Assemblies and descriptors

  • Key: CORBA26-30
  • Legacy Issue Number: 3726
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    Looking a the <Assembly> interface, a question arises. When providing
    the assembly descriptor location, a logic description of the
    application to deploy is provided. But, how are set the pysical hosts
    to be used for the deployemnt of the logic configuration? No hooks is
    provided to the deployment tool (as there are no interfaces for the
    tool) in order to provide these information, and no operation is
    available on the assembly interface to do so. Is there an extension of
    the <Assembly> interface in order to contain this information?
    Otherwise, how could the application be deployed?

    Thinking about what should be provided, it is necessary to assign a
    logical name contained in the assembly descriptor to a physical host
    name. Maybe an extension to the assembly descriptor filled at
    deployment time is the solution? The second possible choice crossing
    my mind is an IDL structure (in fact sequence of structure) that could
    be provided to the assembly object.

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

What about valuetype factories?

  • Key: CORBA26-33
  • Legacy Issue Number: 3786
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    What about <i>valuetype factories</i>?

    <p>In the context of a component dealing with events, the aspect of
    <i>valuetype</i> factories has not been really mentionned in the spec,
    especially in the deploiement process.
    If I am right, dealing with <i>valuetypes</i> in a program means to
    instantiate and to register a factory for this <i>valuetype</i> to the
    ORB. In the context of the CCM, a component and its home is installed
    into a generic container which may not know the <i>valuetype</i>.
    Thus, the <i>valuetype factory</i> may have to be installed at
    deployment time. </p>
    <p> According
    to the similarity in the <i>home</i> and <i>valuetype factory</i>
    concepts, it may be a good solution to add an entry in the CORBA
    Component Descriptor OSD file to define the <i>valuetype factory</i>
    (which would have to be included in the component package) required by
    the component as well as to define a standard name scheme for their
    entry points. Here is an draft example of what it could look
    like. Relationships / dependencies between components and <i>valuetype
    factories</i> also have to be introduced.</p>

    <!--
    <softpkg>
    ...
    <implementation id="...">
    ... all the environment stuff ...
    <descriptor type="Event Factory">
    <fileinarchive>...</fileinarchive>
    </descriptor>
    <code type="DLL">
    <fileinarchive name="bank.dll" />
    <entrypoint>createEventFactory</entrypoint>
    </code>
    </implementation>
    ...
    </softpkg>
    -->

    <p><tt><softpkg>
    <br>  ...
    <br>  <implementation id="...">
    <br>    ... all the environment stuff ...
    <br>    <descriptor type="Event Factory">
    <br>      <fileinarchive>...</fileinarchive>
    <br>    </descriptor>
    <br>    <code type="DLL">
    <br>      <fileinarchive name="bank.dll" />
    <br>      <entrypoint>createEventFactory</entrypoint>
    <br>    </code>
    <br>  </implementation>
    <br>  ...
    <br></softpkg></tt></p>

    <p>The second solution could be to include the code for <i>valuetype
    factory</i> creation in the <i>home</i> implementation, which mean
    less specification: "The home has to install any valuetype factory
    required by the component." would be enough. However, this second
    approach may not be as much portable as the first one (as long as a
    <i>home</i> may be portable between containers, which IMHO should be
    possible).</p>

  • Reported: CPP 1.1 — Thu, 24 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

simple ELEMENT definition

  • Key: CORBA26-35
  • Legacy Issue Number: 3926
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    I have a question about the property.dtd file provided with the CCM spec.

    in this file "simple" is described as follow:

    <!ELEMENT simple
    ( description?
    , value
    , choices?
    , defaultvalue?
    ) >

    This seems to indicate that a "simple" element has to have a value in the
    file. Therefore it is not clear how usefull is the optional "defaultvalue"
    field. It also means that if the component or assembly provider wants to
    provide the CPF files with the CCD and CAD files it has to put values into
    them instead of just setting the default value. Obviously the best thing to
    do would be to repeat the default value into the value but it seems strange
    to me. The point is that if there is a default value provided the value
    doesn't seem to be mandatory.

    Also, in a way similar to the CAD file, where placement information are
    added at deployment time, we may want to enable the component/assembly
    provider to provide CPF skeleton files together with the CCD files and
    skeleton CAD files. In this case the "simple" element may not contain any
    "value".

    I propose to replace this definition with:

    <!ELEMENT simple
    ( description?
    , value?
    , choices?
    , defaultvalue?
    ) >

    Any thought

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

range description in CPF files.

  • Key: CORBA26-34
  • Legacy Issue Number: 3925
  • Status: closed  
  • Source: Open Networks Engineering ( Jean-Christophe Dubois)
  • Summary:

    The definition for "choices" is as follow in the properties.dtd file:

    <!ELEMENT choice ( #PCDATA ) >
    <!ELEMENT choices ( choice+ )

    knowing that the PCDATA for choice is supposed to hold one possible value
    for the "simple" if I am right

    I believe this is missing a bit of descriptive power. In case you want to
    specify a range of 100 values you will have to give the 100 different values
    each in its own "choice" element. It is very verbose !!!

    We could add a range ELEMENT to the DTD as follow:

    <!ELEMENT range (value, value)>

    We could then change the choices ELEMENT as follow:

    <!ELEMENT choices ( range | choice )+>

    Any thought.

  • Reported: CORBA 2.4 — Mon, 2 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Bridge Interoperability of the Java mapping with the EJB-to-CCM mapping

  • Key: CORBA26-23
  • Legacy Issue Number: 3419
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    he following sub-issues need to be addressed to make sure that CCM/EJB
    bridge implementations are interoperable. In particular, these sub-issues
    have in common that the current definition of the bridge relies on the
    Java-to-IDL mapping, which in certain cases does not match the requirements
    of the EJB-to-CCM mapping.

    Sub-issue: METHOD NAMES IN STANDARD INTERFACES

    The names for some methods defined on standard interfaces, for example
    <home-name>Implicit.find_by_primary_key or <home-name>Implicit.create,
    differ from the names that their EJB counterparts get mapped to under
    Java-to-IDL (in the example these would be
    <home-name>.findByPrimaryKey and create__keytype, respectively). When
    this happens, the translation from one form of the name to the other
    can happen at either the client or the server side of the bridge. FOR
    INTEROPERABILITY, it is necessary to eliminate this ambiguity. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    name forms.

    The actual problem we are getting hit by here is overloaded names. Methods
    like remove and create in EJBHome and user-defined EJB homes can only be
    mapped to remove_XXX and create_XXX under Java-to-IDL, yet the
    definitions of the corresponding methods in <home-name>Implicit are remove
    and create, respectively. I can understand that these implicit home names
    were defined as such because <home-name>Implicit is a standard interface
    (although the fact that its name is prefixed by <home-name> is a bit
    troubling) and, if for no other reason, because the XXX in create_XXX
    cannot be known in general. So, if we stick to the standard names, there is
    a mismatch. Notice however that I said that the mapping is done under
    Java-to-IDL. Perhaps I should not say that but the CCM spec is not clear
    about this and in fact it states that the create methods in an EJB home are
    mapped to factory names under Java-to-IDL. So we may actually be talking
    about two different issues: (1) use different mapping rules for create with
    no primary key, in which case we need to ammend the spec to this effect;
    (2) perform a translation, in which case we have an interoperability issue.

    Sub-issue: HANDLING STANDARD EXCEPTIONS

    Standard exceptions thrown by EJB methods, such as
    DuplicateKeyException, have a mapping specification to IDL (under the
    current Java-to-IDL specification) that does not match the exceptions
    that they map to under the CCM spec (in the example this would be
    DuplicateKeyValue). This requires that the bridge perform a run-time
    translation of exceptions from the Java-to-IDL mapping to the CCM
    mapping at either the client stub or the server skeleton. FOR
    INTEROPERABILITY, it is further necessary that the location of the
    translation be fixed. Early prototype implementation suggests that it
    is more advantageous for the client stub to perform the translation
    since otherwise the server skeleton would need to know what kind of
    client it is talking to: a CCM client or an EJB client. A larger issue
    that this falls under is the reconciliation of the Java-to-IDL mapping
    with the EJB-to-CCM mapping. If and when the larger issue is resolved,
    this issue would largely disappear.

    This also falls under the Java-to-IDL mismatch. Our choices seem to be: (1)
    define the standard exceptions, e.g. Components::DuplicateKeyValue, as if
    they had been mapped from Java under Java-to-IDL, (2) map the exceptions
    from Java under rules different from those on Java-to-IDL; (3) perform a
    translation. Choice (1) may be too intrusive but it could be rationalized
    with a "integration with EJB" argument. Choices (2) and (3) are similar to
    the above.

    Sub-issue: PASSING A PRIMARY KEY PARAMETER

    A number of methods defined by standard interfaces, such as remove
    defined by EJBHome, include in their signature a primary key value and
    define its type to be java.lang.Object, which under RMI-IIOP is mapped
    to CORBA::Any. Since the primary key is actually an object passed by
    value and thus mapped to an IDL value type, a run-time translation
    must be performed from the value type to Any and viceversa whenever a
    method that includes a primary key is called. FOR INTEROPERABILITY, it
    is necessary that the location of this translation be fixed. Choices
    for doing this include requiring the client stub to always do the
    translation or requiring the server skeleton to take into account both
    a value or an Any that could possibly be coming from any given
    client. In additon, if a primary key is returned it may be more
    advantageous for the client to perform this translation, since the
    server skeleton may not know what form the client is expecting.

    Here again the problem is that, under Java-to-IDL, java.lang.Object gets
    mapped to ::java::lang::Object (not CORBA::Any actually, as per the actual
    Java-to-IDL I am looking at) for methods like EJBHome.remove, whereas the
    key is expected to be passed as a value type. So the choices seem to be:
    (1) use rules other than those in Java-to-IDL for the mapping or (2)
    perform a translation.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM issue chapter 69 ptc/99-10-04

  • Key: CORBA26-22
  • Legacy Issue Number: 3412
  • Status: closed  
  • Source: Anonymous
  • Summary:

    What exactly is meant in chapter 69.7.2.3 by component archive file? It is
    not defined anywhere. Is it a software package descriptor or a software
    package? At least it is not a CORBA component descriptor as shown in the
    example in chapter 69.7.1. The text there is like:

    <componentfile id="A">
    <fileinarchive name="ca.ccd"/>
    ...

    Is the sufix ccd right?

  • Reported: CPP 1.1 — Mon, 13 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01

  • Key: CORBA26-21
  • Legacy Issue Number: 3299
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    Document orbos/99-08-13, line 9 and further, contradicts with
    orbos/99-07-01,
    Chapter 4.4. The production rules for typePrefix and typeId contain a
    ";",
    where file orbos/99-08-13 omits them.

    Document orbos/99-08-13, lines 1-6, contradicts with orbos/99-07-01,
    Chapter 4.2. The production rules for import contain a ";",
    where file orbos/99-08-13 omits them.

  • Reported: CPP 1.1 — Mon, 7 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

EJB/CCM mappings for the IR

  • Key: CORBA26-20
  • Legacy Issue Number: 3260
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The mapping between EEJB metadata and the IR is missing in the
    current specification .Resolution: Define the mapping

  • Reported: CPP 1.1 — Thu, 27 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see above, rejected

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

IFR backward compatibility broken

  • Key: CORBA26-19
  • Legacy Issue Number: 3233
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Moving existing interfaces from the CORBA module to a new IR module breaks
    backward compatibility. Hence they should be moved back to the CORBA module. The
    elements that are newly added can go into a new module, and interfaces
    corresponding to the existing ones with the same names can be placed in the new
    module, with these interfaces deriving from the existing corresponding
    interfaces in the CORBA module, thus allowing all CORBA3 IR interfaces to be
    accessed from a single module.

    This also fixes a related problem regarding separation of the TypeCode stuff,
    specifically TypeCode factory. It is broken in the current spec because certain
    types used by the typecode factory were inadvertently moved to the IR module.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Missing Rights Combinator in Security deployment descriptor

  • Key: CORBA26-18
  • Legacy Issue Number: 3232
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In section 69.4.5.45, the "rights" element is mentioned, but the "rights
    combinator" elemnt is not. Given a set of "rights" it is not possible to
    determine how to cobine them without the "rights combinator" as specified in
    CORBAsec. Suggest we add a "rights cobminator" element, consistent with the
    definition of rights combinator in CORBAsec.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Purpose of "name" element

  • Key: CORBA26-13
  • Legacy Issue Number: 3198
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - What is the purpose of the "name" element as used in the
    "dependency" element?

    See section 10.2.2.7, The dependency Element (, page 10-308, 10.2.1 A
    softpkg Descriptor Example, CORBA Components - orbos/99-07-01.) Section
    10.2.2.20, The name Element, describes the name element as an optional
    element of the "author" element, and is meant to identify the author. So
    does the name element identify the author of the dependency, or is it used
    to identify the dependency itself?

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

CCM Issue: CIDL Syntax doesn't allow for modules

  • Key: CORBA26-12
  • Legacy Issue Number: 3065
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    The FTF draft does not allow a CIDL composition to be
    included in a module.

    Discussion: In the FTF Draft, the CIDL BNF (Section 60.3) is not yet
    tied into IDL syntax. As it stands, a composition cannot be embedded
    in a module. The draft recognizes that with the note (Section 60.4):

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Issue On the use of typed home (or CCMHome subtypes)

  • Key: CORBA26-29
  • Legacy Issue Number: 3725
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    When a component type is implemented, it inherits a specialized
    interface for callback functions, for example SessionComponent. In
    this context, why should home implementations be unspecialized? Using
    a specific home type, deployment could be improved when performed in a
    multi-actor context. As the cooperation between containers and homes
    is unspecified, using multi-actors components seems unreachable. One
    particular aspect is how the container <Context> interface si provided
    to the component instance. Using a well defined specialized home
    interface would solve this problem easily. Thus, avoiding the use of
    wrappers for example which are another solution, but far more complex.
    Such an interface should be defined for each component type category.

    As an example the following interface could be a basis for session
    component homes. (there must be other operations to add here, but I
    have not foudn them yet.)

    interface SessionCCMHome : CCMHome

    { // or CCMHomeKeyless void set_session_context ( in SessionContext sc ) ; }

    ;

  • Reported: CPP 1.1 — Mon, 26 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

Where is HomeExecutorBase interface defined?

  • Key: CORBA26-28
  • Legacy Issue Number: 3651
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    7. Where is HomeExecutorBase interface defined? I only saw it used in
    the packaging and deployment model. If it is a standard interface
    which is returned (how could it be non standard), shouldn't it be
    defined somewhere? (Same remark for ExecutorSegmentBase
    interfaces. It may be defined in the last Components.idl, but I did
    not find one more recent than orbos/99-08-13.)

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See the resolution for issue 4574.

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

In example p.615-86

  • Key: CORBA26-27
  • Legacy Issue Number: 3650
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    6. In example p.615-86, shouldn't myToonImpl extends ToonSessionImpl
    (presented in the previous pages) instead of ToonImpl (which is not
    defined)? The same classname is used in pages 96-98, but it seems
    correct in this case.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

p.615-85 ToonTownImpl

  • Key: CORBA26-26
  • Legacy Issue Number: 3649
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    5. Even if it is only an example, p.615-85 ToonTownImpl implements
    ExecutorSegmentBase, shouldn't it be HomeExecutorBase?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Why does not CCMHome include the operation create_component() ?

  • Key: CORBA26-25
  • Legacy Issue Number: 3648
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    4. Why does not CCMHome include the operation create_component() ? I
    understand that a component created by a home with keys should not
    offer this interface, however according to the exemple in the spec
    Container operation install_home() returns a CCMHome, thus how
    could a component be created in this context? Does it imply that
    you know if the home is keyless or not, thus narrowing it before
    use? Don't you find strange to have the remove operation but not a
    default create in the CCMHome interface?

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected

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

operation

  • Key: CORBA26-24
  • Legacy Issue Number: 3647
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    3. Why isn't the operation <string get_implementation(in string iuuid)>
    defined in the interface ComponentInstallation while being used in
    ptc/99-10-04 p.69-329 item 9? (Where Installation should be
    replaced by ComponentInstallation don't you think?) Moreover, this
    operation is required for an Assembly to find the location of a
    component implementation in order to load it in a container.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

PACKAGING AND DEPLOYMENT METAMODEL

  • Key: CORBA26-15
  • Legacy Issue Number: 3208
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) Some concepts from the CORBA metamodel (component, facet, receptacle,
    event publishing/emission/consumption) are also in P/D metamodel but the
    definitions from the CORBA metamodel are not directly reused.

    Recommendation: Analyze where reuse is appropriate and adjust the P/D
    metamodel accordingly.

    2) The P/D metamodel has the notion of files (e.g. configuration property
    files and some other files) where some metadata are stored. The hand-coded
    DTDs treat these files as types in their own right, i.e. they conceptualize
    them as files, and some of the other types point to the file types. This
    is approach is mimicked in the metamodel. However, it might not make sense
    in the metamodel because, in a repository context, you are referencing
    other information in the repository and not necessarily a file. The way
    the metamodel is now, when something references one of these files you lose
    the metadata trail. The file metaclass itself does not have structural
    features pointing to metaclasses that define the contents of the file. You
    have to go elsewhere (i.e. to the property file Package) to get that
    metadata and there is no reference to the property file Package.

    Recommendation: It might make more sense for references to the file
    metaclass to instead reference the top level element of the property file
    Package so that you can "follow the metadata trail." If someone wants to
    break out the properties metadata in a file, then the generated DTD should
    allow that, i.e. the part that needs to go into a properties file should be
    able to be self-contained without external references.

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, See issue 4575.

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

atribute not part of definition

  • Key: CORBA26-14
  • Legacy Issue Number: 3199
  • Status: closed  
  • Source: Ericsson ( John-Luc Bakker)
  • Summary:

    ISSUE - The description of the "implementation" element explains the
    "variation" attribute, but the attribute is not part of the definition.

    >From page 10-32, CORBA Components - orbos/99-07-01: "The variation attribute
    is used to indicate a variation from a normal implementation." But the
    definition of the implementation attribute list only lists the "id"
    attribute. The variation attribute is not part of the definition as given in
    softpkg.dtd either (, page B-419, B.1 softpkg.dtd, CORBA Components -
    orbos/99-08-05.)

  • Reported: CPP 1.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Versioning needed for CORBA Core

  • Key: CORBA26-11
  • Legacy Issue Number: 2227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At present there is no formal mechanism or process for versioning the
    CORBA Core. Indeed, it is somewhat hard to figure out what is part of
    the CORBA Core. In Rev 2.3 we tried to at least bring all the IDL for
    the Core together in pieces at logical places, e.g. ORB interface,
    Object interface, IR Interfaces etc. In addition we also have the
    PortableServer module and the GIOP and related modules, the versions of
    all of which have to match for the resulting system to have any hope of
    working as advertized. I guess the basis of the current state of
    affairs is that - the vendor delivers the core, and therefore one can
    trust the vendor to deliver the right things. This model tends to break
    down in situations where people can download bits and pieces of a Java
    ORB at different times and then try to make the whole thing work
    together.

  • Reported: CORBA 2.2 — Mon, 23 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    rejected, see above

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

Components: readonly_attr_declarator slightly ambiguous

  • Key: CORBA26-17
  • Legacy Issue Number: 3230
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In ptc/99-10-04, the production 104

    <readonly_attr_declarator >::=
    <simple_declarator> [ <raises_expr> ]

    <simple_declarator> { "," <simple_declarator> }*

    is ambiguous, since a sole <simple_declarator> could either denote the
    first alternative (with no <raises_expr>), or the second alternative
    (with the simple-declarator-list omitted). Even though this does not
    constitute a serious problem, it is also easy to fix:

    <readonly_attr_declarator >::=
    <simple_declarator> <raises_expr>
    | <simple_declarator> { "," <simple_declarator> }

    *

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

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

Components: Relationship of CIDL and PSDL unclear

  • Key: CORBA26-16
  • Legacy Issue Number: 3229
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The draft component specification (ptc/99-10-04) explains that CIDL is
    a superset of IDL. This is a derivation from the specification
    voted-on in the PTC (orbos/99-07-01), which specified that CIDL is a
    superset of PSDL.

    Also, declaring CIDL not to be a superset of PSDL means that the
    <catalog_use_dcl>, <abstract_storage_home_binding> etc become
    meaningless, as they refer to entities from PSDL.

    Proposed Resolution: Declare CIDL to be a superset of PSDL.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    See issue 3065.

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

ValueMembersSeq

  • Legacy Issue Number: 5939
  • Status: closed  
  • Source: MetroApp Entertainment ( Keith Allyn Baker)
  • Summary:

    ValueMembersSeq is not defined in the CORE Specification and appears in interface ORB, but I believe it is a typo of ValueMemberSeq:

    TypeCode create_value_tc ( in RepositoryId id, in Identifier name, in ValueModifier type_modifier, in TypeCode concrete_base, in ValueMembersSeq members );

  • Reported: CORBA 3.0.2 — Sun, 11 May 2003 04:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    In CORBA v3.3 Part 1 Interfaces, section section 8.2 change ValueMembersSeq to
    ValueMemberSeq

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

Make a typedef for the POA id new

  • Legacy Issue Number: 7891
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Made a typedef for the POA id new: local interface POA

    { typedef CORBA::OctetSeq POAid; }

    change: local interface POA

    { readonly attribute CORBA::OctetSeq id; }

    to: local interface POA

    { readonly attribute POAid id; }
  • Reported: CORBA 3.0.3 — Mon, 1 Nov 2004 05:00 GMT
  • Disposition: Resolved — CORBA 3.1
  • Disposition Summary:

    No Data Available

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

section 7.1.1 claims to define the "NVList structure", but doesn't

  • Key: CORBA26-10
  • Legacy Issue Number: 4722
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the Corba 2.5 spec,
    section 7.1.1 claims to define the "NVList structure",
    but doesn't. Section 7.5 defines the "NVList interface".
    Is this a typo in 7.1.1, then?

    This is a bit confusing. Is NVList a struct, or an interface?
    Inquiring minds want to know

  • Reported: CORBA 2.5 — Thu, 15 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

Implied IDL for interfaces in modules

  • Key: CORBA26-9
  • Legacy Issue Number: 4719
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The Messaging Programming Model introduces implied interfaces. These
    interfaces have the same name as the original interface, but with an
    AMI_ prefix.

    What happens if the original interface is in a module? Will AMI_ be
    prepended to the unqualified name, or to the absolute name? E.g.

    module Stock {
    interface StockManager

    { ... }

    ;
    };

    In this case, will the absolute name of the ReplyHandler be
    ::AMI_Stock::StockManagerHandler, or ::Stock::AMI_StockManagerHandler ?

    All examples in the spec (formal/2001-09-26) are outside any module.
    Since it never talks about absolute names, but only of names, it might
    indicate that it should be the latter (AMI_ prepended to the unquali-
    fied name).

    However, the precedent for prefixes, the POA, always prepends the POA_
    prefix to the absolute name, and I would find it confusing if the AMI_
    prefix was used differently.

  • Reported: CORBA 2.5 — Fri, 30 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

IDL for ORB::resolve_initial_references

  • Key: CORBA26-8
  • Legacy Issue Number: 4718
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • Summary:

    The IDL for ORB::resolve_initial_references declares that it may throw the standard user exception InvalidName, however the Specification does not specify when, if ever the ORB may do so. Two cases of interest are an unknown name such as a misspelled well-known name and an unimplemented well-known name such as Trading Service.

  • Reported: CORBA 2.5 — Tue, 27 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    close, no change

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

set_length operation of the DynSequence interface

  • Key: CORBA26-7
  • Legacy Issue Number: 4713
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    The set_length operation of the DynSequence interface is defined as:

    void set_length(in unsigned long len) raises(InvalidValue);

    in the IDL but is defined as:

    void set_length(in unsigned long len) raises(TypeMismatch, InvalidValue);

    in the discussion that follows the IDL in section 9.2.8. The TypeMismatch exception appears inconsistently in the definition of the operation.

  • Reported: CORBA 2.5 — Tue, 20 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

the IDL include directive should introduce declarations into the namespace

  • Key: CORBA26-6
  • Legacy Issue Number: 4709
  • Status: closed  
  • Source: Hewlett-Packard ( Michael Matzek)
  • Summary:

    The IDL specification for the include directive follows the ANSI C++ specification. This means that the include statement is replaced by the included file's text. The C++ mapping then calls for the generation of stubs and skeletons for the now inline included interfaces. But if the same IDL file, for example CosTransactions.idl, is included in multiple compilation units, the included interfaces become multiply defined. It's like including C++ class definitions rather than class declarations in a C++ program. The problem arises because IDL language mappings specify implementation. Wrapping include directives in different modules has the undesirable effect of requiring multiple implementations of the same operations that differ only in their qualified names. The IDL specification should provide a specification similar to the Java language import statement. That is, the IDL include directive should introduce declarations into the namespace but not implementation via the language. mappings.

  • Reported: CORBA 2.5 — Fri, 16 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    close, no change

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

DynUnion operations

  • Key: CORBA26-5
  • Legacy Issue Number: 4708
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the section describing DynUnion operations, the restatement of the IDL definition of the get_discriminator() operation includes a raises (InvalidValue) clause. This exception is not discussed in the paragraph describing the operation, nor does it appear in the IDL definintion of this operation anywhere else in the chapter.

  • Reported: CORBA 2.5 — Fri, 16 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see below

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

Problem with IDL Context interface

  • Key: CORBA26-4
  • Legacy Issue Number: 4657
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    a few problems with IDL contexts:

    1) On page 4-32, with have:

    "CORBA::CTX_DELETE_DESCENDENTS deletes the indicated context
    ^^^^^^^^^^^
    object and all of its descendent context objects, as well."
    ^^^^^^^^^^
    The standard system exception BAD_PARAM is raised if there are one
    or more child context objects and the CTX_DELETE_DESCENDENTS
    ^^^^^^^^^^^
    flag was not set."

    That's a bit embarrassing because the correct spelling is "descendants",
    not "descendents".

    2) For the get_values() operation, we have:

    "Scope indicates the context object level at which to initiate the
    search for the specified properties (e.g. "_USER", "_SYSTEM"). If
    the property is not found at the indicated level, the search
    continues up the context object tree until a match is found
    or all context objects in the chain have been exhausted."

    This does not say exactly how this is meant to work. I assume that
    the idea is to start at the current context object, checking whether its
    name matches the start_scope parameter. If it does, start the search here;
    otherwise, go up a level and repeat. Once a context object has been found
    with a matching name, then start looking for the properties and collect
    them together, with lower level settings overriding higher level settings,
    until either all property values have been determined or we run out of
    context objects.

    If this is the intended interpretation, the words in the spec are a long
    way from actually expressing that...

    3) Context objects have names. Those names are used to control the behavior
    of get_values(). However, we have two problems:

    • The top-level context object does not have a defined name, so
      I can't specify its name for get_values().
    • Once I've given a context object a name, I can't get it back out.
      (Yet another case where I am forced to give identity to an object
      only to be denied any opportunity of ever asking what that
      identity is...)

    4) For create_child(), what happens if I:

    • specify a name that doesn't look like an IDL identifier?
    • call create_child() twice with the same name on the same
      parent context?

    5) For delete_values(), what is the behavior if the specified property
    does not exist?

    6) For delete(), what is the minor code of the BAD_PARAM exception
    if I don't set the CTX_DELETE_DSCENDENTS [sic] flag and the context
    has child contexts?

    7) For get_values(), what does it mean to "omit" the scope name? The only
    way to omit it, as far as I can see, is to pass the empty string. If so,
    that should be stated.

    8) For get_values(), what exception is raised if the specified scope name
    is not found?

    9) get_values() and delete() accept a Flags parameter. It is not specified
    how to not set a flag (only what it may be set to). Given that Flags
    is an unsigned long, presumably I have to pass zero to indicate that a
    flag is not set. However, this is not specified.

    10) For get_values(), what is the minor code of the BAD_CONTEXT system
    exception if a property isn't found? Why a BAD_CONTEXT exception? Why
    an exception at all (instead of returning an empty sequence)?

    11) For get_values(), it says:

    The NO_MEMORY exception is raised if dynamic memory allocation fails.

    This sentence is utterly redundant.

    12) For get_values(), we have:

    The values returned may be freed by a call to the list free operation.

    What "list free operation"? There is no such operation on NVList.
    There is CORBA::free, but that is specific to the C mapping.

    13) For get_values(), we have:

    "Scope indicates the context object level at which to initiate the
    search for the specified properties (e.g. "_USER", "_SYSTEM")."

    However, for create_child(), we have:

    "Context object names follow the rules for OMG IDL identifiers."

    "_USER" and "_SYSTEM" are not valid IDL identifiers (at least they were
    not at the time this was written, and you can argue that they still are
    not valid IDL identifiers because the underscore is stripped immediately
    by the IDL compiler).

    14) What happens if I call get_default_context() multiple times? Presumably,
    I will get a reference to the same single context object?

    15) In the first para of page 4-29, it says:

    "... although a specified property may have no value associated
    with it"

    This would appear to be impossible. If the property itself exists,
    it always has a value, namely a string. The closest thing to "no value"
    would appear to be the empty string (or a property doesn't exist at all).

    16) "An operation definition may contain a clause specifying those context
    properties that may be of interest to a particular operation. These
    context properties comprise the minimum set of properties that will
    be propagated to the server's environment..."

    So, what happens if I have

    interface I

    { void op() context("C"); }

    ;

    and no property "C" exists in the context object passed by the client?

    Does this mean that the call will be made, but no property "C" will
    be available to the server? (I don't think so, because that would
    contradict the above words about "minimum set of properties that will
    be propagated")

    Or does it mean that the call will be made, but that the value of "C"
    will be the empty string?

    Or does it mean that the call will be refused because the caller has
    not supplied the required properties? If so, what exception is be
    raised?

    17) "Context property names (which are strings) typically have the
    form of an OMG IDL identifier, or a series of OMG IDL identifiers
    separated by periods."

    This is in conflict with the words about property name syntax elsewhere.

    This is a total mess. One interface with six operations, and about a dozen
    bugs. Impressive!

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Indeed it is hopelessly broken. Fix as suggested below.:

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

Chapter 11, section 11.3.8.19 (WrongPolicy)"

  • Key: CORBA26-3
  • Legacy Issue Number: 4654
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In chapter 11, section 11.3.8.19, the "raises (WrongPolicy)" clause has been omitted from the specification of the create_reference_with_id operation. (This exception clause is included in the IDL definition in section 11.4.)

  • Reported: CORBA 2.5 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    see above

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

Support for is_a for local interfaces

  • Key: CORBA26-2
  • Legacy Issue Number: 4623
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Proposal: Section 3.7.6.1: Change the bullet that says

    • The is_a, get_interface, get_domain_managers, get_policy,
      get_client_policy, set_policy_overrides, get_policy_overrides, and
      validate_connection pseudo-operations, and any DII support
      pseudo-operations,
      may result in a NO_IMPLEMENT system exception with minor code 3 when
      invoked on a reference to a local object.

    to:

    • The get_interface, get_domain_managers, get_policy,
      get_client_policy, set_policy_overrides, get_policy_overrides, and
      validate_connection pseudo-operations, and any DII support
      pseudo-operations,
      may result in a NO_IMPLEMENT system exception with minor code 3 when
      invoked on a reference to a local object.
  • Reported: CORBA 2.5 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    Reflect this fact as follows

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

Section 11.3.8.16 - ambiguity

  • Key: CORBA26-1
  • Legacy Issue Number: 4620
  • Status: closed  
  • Source: Anonymous
  • Summary:

    My issue is the ambiguity surrounding the following statement:

    "If the POA has the SYSTEM_ID policy and it detects that the Object Id value was not generated by the system or for this POA, the activate_object_with_id operation may raise the BAD_PARAM system exception."

    So the spec says the operation may raise the BAD_PARAM exception, but doesn't have to. It would be nice if the spec were to clarify the exact behaviour that should be followed to remove ambiguity, because I'm finding some ORB implementations are throwing a BAD_PARAM exception whereas others are not raising an error condition at all.

  • Reported: CORBA 2.5 — Tue, 16 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.6
  • Disposition Summary:

    No Data Available

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

Nil return from resolve_initial_references()

  • Key: CORBA25-44
  • Legacy Issue Number: 4532
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The spec doesn't say whether or not resolve_initial_references() is allowed
    to return nil. Clearly, it doesn't make sense for it to do that – we
    should say so in the spec.

  • Reported: CORBA 2.4.2 — Thu, 23 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

Interpretation of time field in UtcT?

  • Key: CORBA25-43
  • Legacy Issue Number: 4468
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in the absence of an RTF for the time service, I'm sending this to the
    core RTF. (You could argue that this is a core issue anyway, since
    the core depends on the time service for messaging.)

    What is the interpretation of the time and tdf fields in a UtcT?

    The spec shows:

    struct UtcT

    { TimeT time; // 8 octets unsigned long inacclo; // 4 octets unsigned short inacchi; // 2 octets TdfT tdf; // 2 octets // total 16 octets. }

    ;

    For TimeT, the spec says:

    TimeT represents a single time value, which is 64 bits in size, and
    holds the number of 100 nanoseconds that have passed since the base
    time. For absolute time the base is 15 October 1582 00:00.

    For UtcT, the spec says:

    UtcT defines the structure of the time value that is used
    universally in this service. The basic value of time is of type
    TimeT that is held in the time field. Whether a UtcT structure
    is holding a relative or absolute time is determined by its history.
    [...]
    The tdf field holds time zone information. Implementation must
    place the time displacement factor for the local time zone in this
    field whenever they create a UTO.

  • Reported: CORBA 2.4.2 — Thu, 9 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

There is no mapping for fixed types in the COM/CORBA mapping

  • Key: CORBA25-42
  • Legacy Issue Number: 4441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no mapping for fixed types in the COM/CORBA mapping. Why has this been omitted? Is there a submission underway?

  • Reported: CORBA 2.4.2 — Tue, 31 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close with answers to the qestions raised, as given above under Resolution

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

COBRA problem using pragma prefix for modules

  • Key: CORBA25-41
  • Legacy Issue Number: 4395
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please have a look at the news article below. Basically, the problem is
    that we don't say in the spec what has to happen if I try to give
    conflicting prefixes/IDs/versions to a module (which can happen if a module
    is reopened).

    My feeling is that we should deal with this the same way as for forward
    declarations, that is, force the compiler to emit a diagnostic. I think
    we should also add a note that this can't be enforced by the compiler
    under all circumstances because of separate compilation.
    > Orbacus distribution contains following IDL file.
    >
    > > #pragma prefix "omg.org"
    > >
    > > module CosNaming
    > > {
    > > typedef string Istring;
    > >
    > > struct NameComponent
    > >

    { > > Istring id; > > Istring kind; > > }

    ;
    > > };
    > >
    > > #pragma prefix "ooc.com"
    > >
    > > module CosNaming
    > >

    { > > typedef string Ostring; > > }

    ;
    >
    > And here the error message of IDL to Visual Basic compiler.
    >
    > orbacusnaming.idl:16(8): Attempt to assign a different prefix
    > to a forward-declared identifier
    > orbacusnaming.idl:3(8): Position of the first identifier definition

    The error message is misleading becuase there is no forward-declared
    identifier here. But the compiler has a point – something strange is
    going on there...

    > I look in the CORBA specification and found that modules do have
    > repository ids.

    Absolutely.

    > > Forward-declared constructs (interfaces, value types, structures,
    > > and unions) must have the same prefix in effect wherever
    > > they appear. Attempts to assign conflicting prefixes
    > > to a forward-declared construct result in a compile-time
    > > diagnostic. For example:
    > [...]
    >
    > And what about reopened modules?

    This part of the spec simply doesn't apply because it talks about
    forward-declared things only.

    > Which repository id do they
    > have if someone use different prefix statements? I think
    > they can have only one because the IFR of CORBA allows only
    > one (if the repository version is equal).

    Yes. The spec isn't really clear on this point. Here is your example
    once more, simplified to the bare bones:

    #pragma prefix "X"
    module M

    { typedef string foo; }

    ;

    #pragma prefix "Y"
    module M

    { typedef string var; }

    ;

    The spec simply does not address this problem, so we have a hole. Thinking
    about it, there are two possible interpretations:

    1) Module M gets a prefix "X" initially. Then, when the prefix
    changes to "Y" and the compiler sees M for the second time,
    it could just ignore the prefix for M because M has the prefix
    "X" already.

    2) The compiler could notice that M previously got prefix "X"
    and then complain when it sees M for the second time because
    it would get a conflicting prefix.

    For forward-declared things, the spec applies the philosophy that
    the prefixes must not change. Seeing that a reopened module is somewhat
    similar to a forward declaration (because the same definition can be seen
    more than once), I'd be inclined to amend the spec to say that the prefix
    for a module must not change.

    For cases where the compiler can actually detect this, we can even force
    a diagnostic. However, as for forward-declared things, this is not always
    detectable by the compiler. In particular, if the reopened module is
    reopened in different source files and the two source files are compiled
    separately, there is no way for the compiler to detect that the module
    is getting a different prefix in each source file. If the generated code
    from the two files is linked into the same binary, you should at least
    get a multiple definition error. But if the code for the two files ends
    up in different executables, there is no way to detect the error at all
    and you will get strange things happening at run time.

    As far as the ORBAcus IDL is concerned, I think it needs fixing. The second
    prefix pragma should be inside the module, to avoid the conflict:

    #pragma prefix "omg.org"

    module CosNaming
    {
    typedef string Istring;

    struct NameComponent

    { Istring id; Istring kind; }

    ;
    };

    module CosNaming

    { #pragma prefix "ooc.com" typedef string Ostring; }

    ;

    > Is my IDL2VB compiler again buggy or the Orbacus IDL file
    > or the CORBA specification not clear?

    Well, a little bit of all three I'll raise an issue with the core RTF.

    > I recently solve all founded bugs in IDL2VB and it compiles now
    > all examples of syntax chapter in CORBA spec and find
    > all errors. CORBA is to difficult for humans...

    That's why we use compilers for IDL instead of humans

  • Reported: CORBA 2.4.2 — Sun, 24 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify as described below

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

CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion)

  • Key: CORBA25-40
  • Legacy Issue Number: 4392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.2 (01-02-01.pdf) 4.2.3.4 shutdown (relevant portion): "If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application does this in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock."

    But does this mean that things will be as if the operation has not been called (suggested by the name of the exception raised?), or will they be as if the operation had been called with wait_for_completion FALSE (seems more appropriate)? Or should the implementation decide, and should it just use an appropriate completion code? In this case, is COMPLETION_MAYBE allowed? Letting the implementation decide puts a higher burden on the developer, though, if s/he wants to write portable code, so that developer may decide to just program for the current implementation...

    This question has additional relevance for me because I'm implementing an ORB.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that BAD_INV_ORDER is raised in this case with COMPLETED_NO

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

Local interface is-a Object?

  • Key: CORBA25-39
  • Legacy Issue Number: 4388
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For local interfaces, we seem to have internal inconsistencies in the spec.
    For one, it is not clear whether or not a local interface implicitly inherits
    from Object. There is one sentence in the spec that seems to imply that
    there is implicit inheritance from object, on page 3-23 of the 2.5 draft
    (http://doc.omg.org/ptc/1-6-10):

    Any attempt to marshal a local object, such as via an unconstrained
    base interface, as an Object, or as the contents of an any, or to
    pass a local object to ORB::object_to_string, shall result in a
    MARSHAL system exception with OMG minor code 4.

    This implies that I can at least try to pass local object as CORBA::Object,
    which implies that local interfaces do indeed implicitly inherit from Object.

    But then, a bit further down, it says:

    The is_a, get_interface, get_domain_managers, get_policy,
    get_client_policy, set_policy_overrides, get_policy_overrides, and
    validate_connection pseudo-operations, and any DII support
    pseudo-operations, may result in a NO_IMPLEMENT system exception
    with minor code 3 when invoked on a reference to a local object.

    "May result in a NO_IMPLEMENT system exception"? I would suggest "shall"!

    But, more seriously, I can't call is_a() on a local interface. In turn,
    that seems to imply that I can't narrow a local interface either, but
    narrowing is clearly necessary in the presence of inheritance for local
    interfaces.

    It seems that local interfaces must inherit from Object. After all,
    it would be difficult to see, for example, how resolve_initial_references
    can return a reference to the Root POA if it were otherwise... But then,
    if local interfaces do inherit from Object, It doesn't make sense to
    prohibit calling is_a() on them.

    Related to that then is the question of "What is the repository ID of
    a local interface?" Given that they can be narrowed, it would seem that
    they must have repository IDs. (Although, you could argue that narrowing
    is to be achieved via some mechanism other than repository IDs – that
    would also permit is_a() not to be supported and would make narrowing
    an issue that is specific to each language mapping.)

    But the inheritance issue seems serious – if something doesn't inherit
    from Object, I can't return or pass it as an Object, but we are doing
    just that for local objects.

    I think this will require some careful thought. We don't want to find
    ourselves in yet another maze of twisty little passages, all different,
    as we did with pseudo-objects...

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

Wither pseudo-objects?

  • Key: CORBA25-38
  • Legacy Issue Number: 4387
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the terms "pseudo-object", "pseudo-interface", and "PIDL" appear in many
    places in the spec. However, there does not appear to be a definition
    of what these things actually are anywhere in the spec. Now, for many years
    now, I've been telling people that PIDL objects differ from normal ones
    in the following ways:

    • They don't inherit from Object.
    • They can't be invoked via the DII.
    • They don't have definitions in the IFR.
    • They can't be passed as arguments to remote operations
      (except for TypeCode).
    • They may have special mapping rules.

    I know that, once upon a time, when I first wrote these points into a CORBA
    training course, I didn't just make them up – I found them in the spec.
    However, I'm damned if I can find them now. I looked in the 2.0 spec as
    well as the 2.4.2 spec to no avail. Can someone help me out?

    At any rate, we should add the definition somewhere because, write now,
    we have lots of free-floating terms in the spec.

    On a related note, by searching for "pseudo", I found a few places where
    it is stated that "pseudo-objects do not have object references". That
    seems to be wrong. After all, we pass these things across (local) interfaces
    by reference (instead of by value) and, at the language mapping level,
    pseudo-objects have references that are indistinguishable from any other
    reference. We should correct this.

  • Reported: CORBA 2.4.2 — Fri, 29 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Missing TypeCode identity

  • Key: CORBA25-37
  • Legacy Issue Number: 4386
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Steve's and my book contains a bit of code that pretty-prints a TypeCode.
    (See page 704ff, in particular, 709-711.) No big deal – just write
    a recursive function that does a depth-first traversal of a TypeCode tree
    and prints things out, except for one thing: recursive types.

    For recursive types, the code has to be careful not to get trapped in
    infinite recursion. In essence, this means that the pretty-printer has to
    remember which TypeCodes it has already seen and end the recursion if it gets
    to a TypeCode that was printed previously. This is where we run into
    problems because there is no legal way to do this:

    • I cannot rely on the repository ID in the TypeCode to determine
      TypeCode identity because the repository ID for structs and
      unions is optional prior to GIOP 1.2, but recursion happens
      via structs and unions. (A GIOP 1.2 implementation may interoperate
      with a GIOP 1.0 or 1.1 implementation and still end up sending
      TypeCodes without repository IDs.)
    • The code in the book uses is_equivalent() to determine whether
      it has seen a TypeCode previously. However, doing this is
      completely illegal (even though it happens to work with most
      ORBs) because:
    • is_equivalent() does not provide object identity.
    • TypeCode is a pseudo-object, and pseudo-objects do
      not inherit from CORBA object. This means that TypeCode
      doesn't even have an is_equivalent() operation that I
      could call.

    So, as far as I can see, there is no compliant way to reliably and portably
    determine TypeCode identity and, as a result, I can't ever reliably parse
    a TypeCode...

    I can see several solutions for this problem, all with different drawbacks:

    1) Add an identity() operation of some kind to TypeCode.

    An ORB that receives a TypeCode would have to make sure that
    it generates a unique ID for each TypeCode. But that's not
    all that easy to implement – in particular, if we have an
    older TypeCode where all the optional bits are missing, we
    can't reliably establish object identity for a TypeCode.
    (Only structural comparison is possible.)

    2) Add an identity() operation to TypeCode, but have the TypeCode's
    identity generated at the sending end instead of the receiving
    end.

    Major drawbacks: the identity would have to large because it
    needs to be globally unique (e.g. a UUID) and it would change
    the marshaling of TypeCodes.

    3) Add is_equivalent() and hash() operations to TypeCode.

    This might break existing ORB implementations because a lot
    of ORBs seem to inherit from Object for TypeCode and other PIDL
    objects, even though they shouldn't.

    4) Make PIDL objects implicitly inherit from CORBA::Object.

    Note that making the repository ID mandatory is impossible because we
    can't legislate for existing GIOP 1.0 or 1.1 implementations...

    On a related note, we seem to have further problems with the idea that
    PIDL objects don't inherit from CORBA::Object. For example, in the C++ mapping,
    pseudo-objects such as TypeCode, ORB, etc. can be passed as Object_ptr
    (for example, to CORBA::is_nil()). This really means that the C++ mapping
    (and possible mappings for other languages) are completely in conflict
    with the core spec...

    My feeling is that option 4 is really the least-intrusive one. But I'm
    not sure that I fully understand all the ramifications of making that change.

  • Reported: CORBA 2.4.2 — Thu, 28 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Problem with resolution to 4285 and 4306

  • Key: CORBA25-36
  • Legacy Issue Number: 4385
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Please take a look at the resolution of issues 4285 and 4306 in
    > ptc/2001-06-08 - the RTF report that is up for recommendation to adopt
    > at this upcoming meeting, and see if they do not fix these problems.
    > 4285 fixes the BAD_OPERATION problem most definitely. 4306 seems to fix
    > the OBJ_ADAPTER problem too, although slightly differently from how you
    > suggest. If these fixes address the problem that you raise in your
    > message, could you please ask Juergen to not create an issue?I didn't CC issues, so I don't think Juergen will create an issue (at least,
    that was the intent). My apologies for the duplication. However, looking
    at 4285 once again, I think there may be a problem:

    In order to return something that means "ServantManager returned wrong
    servant type", I think the ORB core has to insert an active check
    at the point where the servant manager returns. If it doesn't, it will
    either get an unmarshaling error or return a BAD_OPERATION exception with
    some other minor code when it detects that the operation isn't in the
    function pointer table for the servant. In the latter case, the ORB won't
    know anymore why the operation is missing (for example, it could also
    be missing because the client used the DII to invoke a non-existent operation.)

    I am also not sure whether BAD_OPERATION is really the correct exception to
    use. To me, BAD_OPERATION tells the client "you invoked an operation that
    doesn't exist". If we give this exception to the client when it invokes
    an operation that's perfectly good, that's highly misleading because the
    actual problem isn't with the client, but with the servant manager.

    So, I think that using OBJ_ADAPTER, as I suggested, would be better.

    For the resolution to 4306, I think we also have something that is suboptimal.
    That's because minor code 2 say "Servant not found" in table 4-3. But
    I don't see how this is possible. Basically, a servant manager isn't allowed
    to return a null servant. If it can't find the servant, it's supposed to
    throw a system exception. So, a servant manager that returns null is simply
    broken and needs to be recoded. 4306 (by using "Servant not found" as
    the explanation of minor code 2) is misleading, because that condition simply
    can't happen.

    So, without trying to create a procedural mess, could we reconsider the
    resolution to these two issues, maybe for the next vote?

  • Reported: CORBA 2.4.2 — Sat, 23 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix inconsistency as described below

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

get_interface() underspecified

  • Key: CORBA25-35
  • Legacy Issue Number: 4335
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the text for get_interface() says:

    An operation on the object reference, get_interface, returns an object
    in the Interface Repository, which provides type information that may
    be useful to a program. See the Interface Repository chapter for a
    definition of operations on the Interface Repository. The
    implementation of this operation may involve contacting the ORB
    that implements the target object.

    This does not say what should happen if I call _get_interface() and

    • the interface repository isn't running,
    • the interface repository is running and can be reached, but
      doesn't contain an entry for the object's interface.

    Looking at the INTF_REPOS exception, we have:

    An ORB raises this exception if it cannot reach the interface
    repository, or some other failure relating to the interface
    repository is detected.

    This would indicate that, if the repository isn't running, the client should
    get INTF_REPOS. However, we have no idea what should happen if the repository
    is in fine shape, but no entry exists for the interface.

    Since an unpopulated interface repository is very much the same thing as
    no interface repository at all, I would like to flag both scenarios as an
    error.

    Proposal: add the following sentence to the end of 4.11.3.22:

    If the interface repository is not available, get_interface() raises
    INTF_REPOS with minor code 1. If the interface repository does not
    contain an entry for the object's (most derived) interface,
    get_interface() raises INTF_REPOS with minor code 2.

    Update the minor code table in 4.11.4 accordingly.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change and the additional change suggested in the archive

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

Typo in UML for POA

  • Key: CORBA25-34
  • Legacy Issue Number: 4333
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The UML diagram on page 11-49 uses "the_manager" in two places. This
    should be "the_POAManager".

    In one place, it uses the attribute "the_servant_manager". No such attribute
    exists.

  • Reported: CORBA 2.4.2 — Mon, 4 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested corrections

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

DII create_request

  • Key: CORBA25-33
  • Legacy Issue Number: 4331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA 2.4.1 final, Section 7.2.1 (create_request), page 7-7, last
    paragraph reads:

    "If the name of an implicit operation that is not invocable through DII
    is passed to create_request with a "_" prepended, create_request shall
    raise a BAD_PARAM standard system exception".

    This does not specifies the minor code for the exception.

  • Reported: CORBA 2.4.2 — Fri, 1 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Ambiguity in non_existent

  • Key: CORBA25-32
  • Legacy Issue Number: 4322
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 4.3.5.1 non_existent last paragraph says:

    Probing for object non-existence may require contacting the ORB that
    implements the
    target object. Such an attempt may fail at either the local or the
    remote end. If non-existent
    cannot make a reliable determination of object existence due to failure,
    it
    raises an exception in the calling application code. This enables the
    application to
    distinguish among the true, false, and indeterminate cases.

    This does not define what exception gets thrown in the indeterminate
    case. I picked TRANSIENT, but COMM_FAILURE or NO_RESPONSE may also be
    valid choices.

    Proposal:

    Change the sentence in last paragraph of section 4.3.5.1:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises an exception in the calling application code.

    to:
    If non-existent cannot make a reliable determination of object existence
    due to failure, it
    raises a TRANSIENT with XX minor code in the calling application code.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    close, no change

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

String literal definition incorrect.

  • Key: CORBA25-31
  • Legacy Issue Number: 4320
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The following from the CORBA 2.4.1 specification.
    3.2.5.2 Character Literals
    A character literal is one or more characters enclosed in single quotes,
    as in ’x.’
    Character literals have type char.
    A character is an 8-bit quantity with a numerical value between 0 and
    255 (decimal).

    3.2.5.4 String Literals
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    The above statements together implies that a string literal may contain
    embedded NULL characters. That is incorrect. The definition of string
    literals must explicitly eliminate NULL.

    Proposal:
    Revised text:

    Section 3.2.5.4 String Literals

    replace this first paragraph
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9) surrounded by double quotes, as in “...”.

    with
    A string literal is a sequence of characters (as defined in Section
    3.2.5.2, “Character
    Literals,” on page 3-9), with the exception of the character with
    numeric value 0, surrounded by double quotes, as in “...”.

  • Reported: CORBA 2.4.2 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

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

Inconsistent minor code for MARSHAL

  • Key: CORBA25-30
  • Legacy Issue Number: 4310
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 3-23 of section 3.7.6.1, first bullet point, we find:

    Local types cannot be marshaled and references to local objects
    cannot be converted to strings. Any attempt to marshal a local
    object, such as via an unconstrained base interface, as an Object,
    or as the contents of an any, or to pass a local object to
    ORB::object_to_string, shall result in a MARSHAL system exception
    with OMG minor code 2.
    ^^^^^^^^^^^^^^^^
    However, the minor code table, page 4-59, section 4.11.4 shows:

    MARSHAL 1 Unable to locate value factory.
    2 ServerRequest::set_result called before
    ServerRequest::ctx when the operation IDL contains a
    context clause.
    3 NVList passed to ServerRequest::arguments does not
    describe all parameters passed by client.
    4 Attempt to marshal Local object.

    This is inconsisent – the text requires minor code 2, but the table
    requires minor code 4.

    I would suggest to update the first bullet of 3.7.6.1 to require minor code 4,
    in line with what is shown in the table.

  • Reported: CORBA 2.4.2 — Thu, 17 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

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

Minor code

  • Key: CORBA25-29
  • Legacy Issue Number: 4306
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "If a ServantManager returns a null Servant (or the equivalent in a language mapping) as the result of an incarnate() or preinvoke() operation, the POA will return the OBJ_ADAPTER system exception with standard minor code 3 as the result of the request."

    Should that be minor code 2 rather than 3? I couldn't find any other reference to OBJ_ADAPTER minor code 2 and the description makes more sense for this condition.

  • Reported: CORBA 2.4.2 — Mon, 14 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Yes the minor code in this case should indeed be 2. Make it so

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

Missing POAManager identity

  • Key: CORBA25-28
  • Legacy Issue Number: 4297
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the current way of dealing with POAManager objects is less than satisfactory.
    Consider:

    interface POA

    { // ... POA create_POA( in string adapter_name, in POAManager a_POAManager, in CORBA::PolicyList policies ) raises(AdapteraAlreadyExists, InvalidPolicy); readonly attribute POAManager the_POAManager; }

    ;

    The problem here is twofold:

    • There is no way to get at the list of all existing POA managers,
      at least not easily; I have to either keep a list myself,
      or I have to traverse the POA tree and build the list as I go.
    • POA managers have no identity. There is no name or other piece
      of state that would allow me to distinguish one POA manager from
      another.

    The second problem is the more serious one because POA managers are used
    to control the behavior of one or more transport endpoints. Most ORBs
    permit configuration control over transports. For example, it is usually
    possible to configure things such as which protocols/transports should
    be associated with a POA manager, how many protocols/transports should
    be associated, at what address/port the transport controlled by a
    POA manager should listen for requests, what timeouts to apply, etc, etc...

    Currently, ORBs have to resort to proprietary means to attach such
    configuration information. For example, in ORBacus, we use a proprietary
    POA manager factory that permits a name to be attached to a POA manager.
    That name then is used as a hook to attach configuration information
    to POA managers, so we can do things like configure port numbers, etc.

    I'd like to improve the spec such that it becomes possible to control
    identity for POA managers through a standard API. The thoughts are:

    • Add a POAManagerFactory interface that allows
    • creation of POA managers
    • listing of existing POA managers
    • searching for POA managers by name
    • Add an id() accessor to POAManager that returns the name

    For creation of POA managers, a CORBA::PolicyList can be passed into
    the call in addition to the POA manager name. That policy list would permit
    configuration of POA managers through a defined API (even though the
    actual policies that apply would still be proprietary).

    These changes would be completely backward-compatible, so no existing
    code breaks.

  • Reported: CORBA 2.4.2 — Wed, 9 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

BAD_OPERATION needs minor code and completion status

  • Key: CORBA25-27
  • Legacy Issue Number: 4285
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    "This indicates that an object reference denotes an existing object,
    but that the object does not support the operation that was invoked."

    This text does not specify a minor code nor a completion status.

    Section 11.3.4.1 (last paragraph) says:

    "If the ServantManager returns the wrong type of Servant, it is
    indeterminate when that error is detected. It is likely to result in a
    BAD_OPERATION with standard minor code 5 or MARSHAL exception at the
    time of method invocation."

    This implies that 4.11.3.13 should specify a '5' for the minor code.

    A specific minor code for this case is necessary since BAD_OPERATION
    may be raised in other contexts (e.g., IDL->Java mapping for union,
    Any, any extraction, ...).

    I am not sure why it says '5' in 4.11.3.13. Is this minor code
    specified somewhere else that I'm missing?

    Assuming that this is underspecified I would suggest:

    1. assigning a minor code for the case discussed in 4.11.3.13,

    2. making sure that 11.3.4.1 is in sync with that assignment,

    3. specifying a completion status of COMPLETED_NO (since there is no
    way anything could be completed since the call never makes it out of
    the skeleton into the servant).

  • Reported: CORBA 2.4.2 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Cross-reference refers to wrong section

  • Key: CORBA25-26
  • Legacy Issue Number: 4276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second paragraph of "3.10.1.7 Any Type" uses a cross-reference to explain the concept of the TypeCode in an Any value. This cross-reference refers to section 3.10, which is useless.

    Suggestion: Change this cross-reference to read as follows: '(see Section 10.7, "Type Codes", on page 10-51)'

  • Reported: CORBA 2.4.2 — Wed, 18 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested

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

Issue: Error in section 4.5.3.2 ORBInitRef

  • Key: CORBA25-25
  • Legacy Issue Number: 4275
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 4.5.3.2 says:
    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    Couple of problems w/ this. Shouldn't the reference be Section 13.6.10
    of this spec. Also, the ObjectURL specifications in chapter 13 include a
    "rir" protocol which obviously makes no sense for ORBInitRef.

    Proposal:

    Replace first sentence of last paragraph of section 4.5.3.2 from:

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Sections 13.6.6 to 13.6.7 CORBA 2.3
    Specification).

    to

    <ObjectURL> can be any of the URL schemes supported by
    CORBA::ORB::string_to_object (Section 13.6.10), with the exception of
    the corbaloc URL scheme with the rir protocol (i.e. corbaloc:rir:...).

  • Reported: CORBA 2.4.2 — Tue, 17 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Fix as suggested above

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

Section 10.5.22.2 what happens when conditions not met

  • Key: CORBA25-24
  • Legacy Issue Number: 4266
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    What happens when someone attempts to set the mode attribute while not
    adhering to the restrictions spelled out?

    We should say what happens if these conditions
    aren't met. Furthermore, a oneway method can't have exceptions.
    I suggest:

    • add a new row to the BAD_PARAM block in Table 10-1 (p.10-10):

    Exception Minor Code Explanation

    BAD_PARAM N Attempt to define a oneway
    operation with non-void result,
    out or inout parameters or
    exceptions

    • Add a similar entry to table 4.3 (p.4-61).
    • Change the last para of 10.5.22.2 to read:

    "The mode attribute can be set to OP_ONEWAY only if the result is
    TC_void, all elements of params have a mode of PARAM_IN, and the
    list of exceptions is empty. If the mode is set to OP_ONEWAY
    when these conditions do not hold, a BAD_PARAM exception is
    raised with minor code N."

    This is perhaps rather large to be a friendly ammendment. I'm
    happy to vote YES to the current resolution, which is still a
    useful change, and raise this for next time. I can't discuss
    further in this round, as I'm on vacation for a week from this
    evening.

  • Reported: CORBA 2.4.2 — Wed, 11 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Restrictions on native types

  • Key: CORBA25-23
  • Legacy Issue Number: 4264
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The new text in 3.10.5 states: "Native type parameters are permitted
    only in operations of local interfaces or valuetypes". However, 11.4
    states that:
    a) Servant is a native type, and
    b) that it is used on the POA::get_servant operation, and
    c) that POA is not a local interface
    (Taking POA as an arbitrary example here; other POA interfaces show
    the same problem). Does that mean that CORBA 2.5 will be inconsistent?

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

Clarification about include files and IDL compiler behavior

  • Key: CORBA25-22
  • Legacy Issue Number: 4262
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think it would be nice to mention something about code generation in
    section 19.5.22.2. People seem to either expect that the compiler will
    generate code for everything, or that it will generate code only for
    things that are not in included files. The following might help to clear
    this up:

    "Note that whether a particular IDL compiler generates code for included
    files is an implementation-specific issue. To support separate
    compilation, IDL compilers may not generate code for included files, or
    do so only if explicitly instructed."

  • Reported: CORBA 2.4.2 — Tue, 10 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Insert the sugested text in section 3.3

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

Definition of NamingContextExt interface in IDL of Appendix A not consisten

  • Key: CORBA25-21
  • Legacy Issue Number: 4246
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The definition of the NamingContextExt interface in the IDL of Appendix A is not consistent with the definition in section 2.5.4.

    Specifically,

    1. The Appendix A version has an extra operation: resolve_context

    2. In Appendix A, there is an extra exception type in the raises clause of the resolve_str operation: AlreadyBound

  • Reported: CORBA 2.4.2 — Thu, 29 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above

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

3.7.4 Forward Declaration (for interfaces) doesn't mention local

  • Key: CORBA25-20
  • Legacy Issue Number: 4241
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 3.7.4 doesn't mention local as a legal prefix for an interface
    forward declaration.

    Proposal 1:

    Change the sentence:

    "The syntax is: optionally the keyword abstract, followed by the keyword
    interface, followed by an <identifier> that names the interface."

    to:

    "The syntax is: optionally either the keyword abstract or the keyword
    local, followed by the keyword interface, followed by an <identifier>
    that names the interface."

    Proposal 2:

    Just strike the sentence entirely, since it is redundant.

  • Reported: CORBA 2.4.2 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the recommended change in Proposal 1

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

What is the semantics of the DataInputStream::read_*_array() operations?

  • Key: CORBA25-19
  • Legacy Issue Number: 4233
  • Status: closed  
  • Source: Floorboard Software ( Yvonne Biggar)
  • Summary:

    The CORBA::DataInputStream abstract valuetype has operations like:

    void read_boolean_array( inout BooleanSeq seq,
    in unsigned long offset,
    in unsigned long length);

    However, the spec says nothing about whether the provided sequence must
    already have sufficient length to satisfy the offset+length or whether
    the operation will extend the sequence to fit.

  • Reported: CORBA 2.4.2 — Fri, 23 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify that the operations are expected to extend the sequence to fit

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

Introduction of identifiers

  • Key: CORBA25-13
  • Legacy Issue Number: 4171
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I cannot seem to come to grips with the introduction of identifiers
    by their use in a nested scope. The example on page 3-54 reads
    (simplified)

    module Inner1

    { typedef string S1; }

    ;

    module Inner2

    { typedef Inner1::S1 S2; // Inner1 introduced typedef string inner1; // Error }

    ;

    The text goes on to explain that the above construct introduces the
    identifier "Inner1", while using the absolute name, "::Inner1::S1"
    in the typedef wouldn't. Therefore, the following code would be
    legal:

    module Inner2

    { typedef ::Inner1::S1 S2; // Inner1 not introduced typedef string inner1; // legal }

    ;

    I fail to see the rationale in this. Also, this is not in sync with
    the Interface Repository, which cannot even detect that the first
    example is illegal, because it never sees relative names.

    My proposed resolution would be to get rid of "introduced names"
    altogether and to declare the above example legal.

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Close no change

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

Type redefinition in derived interface

  • Key: CORBA25-12
  • Legacy Issue Number: 4170
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The discussion for issue 3525 shows that it is legal to redefine a type
    in a derived interface, as in

    interface B

    { typedef string S; }

    ;
    interface D : B

    { typedef long S; }

    ;

    However, I don't think that this legality is obvious from the text. On
    page 3-52, it says that "inheritance causes all identifiers defined in
    base interfaces to be visible in derived interfaces." Then, on page
    3-56, it is said that "once a type has been defined anywhere within
    the scope of a module, interface or valuetype, it may not be redefined
    except within the scope of a nested module or interface."

    Since B::S is not "defined" but only "visible" in D, and D is not a
    nested interface but a derived interface, there seems to be a gray
    area.

    Proposed resolution:

    Edit the first paragraph of 3.15.3 (Special Scoping Rules for Type
    Names) on p 3-56 to read:

    "Once a type has been defined anywhere within the scope of a module,
    interface or valuetype, it may not be redefined except within the
    scope of a nested module, interface or valuetype, or within the
    scope of a derived interface or valuetype."

    Edit the following example to include, after interface A, but before
    the erroneous redefinition of ArgType,

    interface B : A {
    typedef long ArgType; // OK, redefined in derived interface
    struct S

    { // OK, redefined in derived interface ArgType x; // x is a long A::ArgType y; // y is a string }

    ;
    };

  • Reported: CORBA 2.4.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make the suggested change clarifying the inheritance case

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

PortableServer::ObjectId

  • Key: CORBA25-11
  • Legacy Issue Number: 4165
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    I propose that ObjectId be changed from:

    typedef sequence<octet> ObjectId;

    to:

    typedef CORBA::OctetSeq ObjectId;

    This shouldn't cause any existing code to break. However, currently
    PortableInterceptor::ObjectId (needed so that the PI module doesn't
    depend on the PortableServer module) isn't directly assignable to
    PortableServer::ObjectId which means additional copying that doesn't
    seem necessary. It also reduces the code-size of the ORB somewhat
    (since a sequence type can be removed from the core).

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

core issue: unchecked narrow

  • Key: CORBA25-10
  • Legacy Issue Number: 4159
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    CORBA Core should state that language mappings providing a narrowing mechanism
    are also required to provide an 'unchecked narrowing'-mechanism.

    The original CORBA Messaging specification (orbos/98-05-05) specifies an
    unchecked narrow operation that has not been changed by any Messaging RTF.
    'unchecked narrowing' is not an issue of a single language mapping. Therefore,
    it would be good if this was formulated in the CORBA Core as a general
    requirement for any language mapping.

    The originally adopted CORBA Messaging specification, orbos/98-05-05, had an
    explanatory paragraph for this purpose:

    '3.3.7 Note on Asynchrony and Narrowing of Object References
    Many programming languages map IDL interfaces to programming constructs that
    support inheritance. In those language mappings (such as C++ and Java) that
    provide
    a mechanism for narrowing an Object reference of a base interface to a more
    derived
    interface, the act of narrowing may require the full type hierarchy of the
    target. In this case, the implementation of narrow must either contact an
    interface repository or the target itself to determine whether or not it is
    safe to narrow the client’s object reference. This requirement is not
    acceptable when a client is expecting only
    asynchronous communication with the target. Therefore, for the appropriate
    languages
    this specification adds an unchecked narrow operation to the IDL mappings for
    interface. This unchecked narrow always returns a stub of the requested type
    without
    checking that the target really implements that interface. If a client narrows
    the target to an unsupported interface type, invoking the unsupported
    operations will raise the system exception CORBA::BAD_OPERATION.'

    However, the semantics of the above have obviously not made it into CORBA 2.4.

  • Reported: CORBA 2.4.1 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

#include issue

  • Key: CORBA25-18
  • Legacy Issue Number: 4226
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    A minor issue with section 3.3 of the 2.4 specification:

    "... Text in files included with a #include directive is treated as
    if it appeared in the including file. ..."

    That is not true since, as we find out in chapter 10, included files
    behave specially with regard to assigning repository identifiers.

    e.g. in

    // a.idl
    #pragma prefix "foo"
    interface bar {};

    the repository id of bar is IDL:foo/bar:1.0, but in

    // a.idl
    #pragma prefix "foo"
    #include "b.idl"

    // b.idl
    interface bar {};

    it is just IDL:bar:1.0.

  • Reported: CORBA 2.4.2 — Tue, 20 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

DynValueBox::set_boxed_value should also raise InvalidValue

  • Key: CORBA25-17
  • Legacy Issue Number: 4224
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    As with other DynAny operations that accept an Any parameter,
    the set_boxed_value operation should be capable of raising
    InvalidValue.

    Proposal:

    • In sections 9.2 and 9.12, add InvalidValue to the raises clause for
      set_boxed_value
    • In section 9.12, replace the text describing set_boxed_value with the
      following:

    "The set_boxed_value operation replaces the boxed value with the specified
    value. If the type of the passed Any is not equivalent to the boxed type,
    the operation raises TypeMismatch. If the passed Any does not contain a
    legal value, the operation raises InvalidValue. If the DynBoxedValue
    represents a null valuetype, it is converted to a non-null value."

  • Reported: CORBA 2.4.2 — Fri, 16 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Make it so

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

misleading wording in 10.5.22.2 Write Interface

  • Key: CORBA25-16
  • Legacy Issue Number: 4217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The mode attribute can only be set to OP_ONEWAY if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    which might be taken to mean that the mode attribute must be set to
    OP_ONEWAY if the signature is as described. A better wording might be

    The mode attribute can be set to OP_ONEWAY only if the result is TC_void and all
    elements of params have a mode of PARAM_IN.

    This was brought to my attention by an email question I received today, from
    someone who thought he understood CORBA oneway semantics until he
    read that sentence - then he became confused.

  • Reported: CORBA 2.4.2 — Fri, 2 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    make it so

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

Inconsistent text for unknown system exception

  • Key: CORBA25-15
  • Legacy Issue Number: 4189
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    In document 01-01-01, there are the following paragraphs which seem
    contrary to one another regarding the minor code to be used when an
    ORB receives an unrecognized system exception.

    4.11.2
    Vendors may define non-standard system exceptions, but these exceptions are
    discouraged because they are non-portable. A non-standard system exception, when
    passed to an ORB that does not recognize it, shall be presented by that ORB as an
    UNKNOWN standard system exception. The minor code and completion status from
    the unrecognized exception shall be preserved in the UNKNOWN exception.

    15.3.5.5 Exception
    Exceptions are encoded as a string followed by exception members, if any. The string
    contains the RepositoryId for the exception, as defined in the Interface Repository
    chapter. Exception members (if any) are encoded in the same manner as a struct.
    If an ORB receives a non-standard system exception that it does not support, or a user
    exception that is not defined as part of the operation's definition, the exception shall be
    mapped to UNKNOWN, with standard minor code set to 2 for a system exception, or
    set to 1 for a user exception.

  • Reported: CORBA 2.4.2 — Sat, 3 Feb 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate changes and close issue

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

ForwardRequest from normal operations

  • Key: CORBA25-14
  • Legacy Issue Number: 4176
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    interface Foo

    { void op() raises(PortableServer::ForwardRequest); }

    ;

    What happens if a client invokes op() and op() throws ForwardRequest?
    Is this received by the client as a locate forward or does the client
    simply receive the exception?

    The spec doesn't say either way. However, thinking about how all this is
    implemented, I strongly suspect that current implementations will simply
    marshal the exception back to the client instead of sending a locate forward
    reply.

    Personally, I think that's how it should be. If it werent, we'd have to
    insert additional code into the user exception processing path to deal
    with this special exception (which would probably set a bad precedent).

    I'd suggest to amend the spec to state that ForwardRequest has the effect
    of causing a locate forward reply only if thrown from preinvoke() and
    incarnate() and is otherwise just a normal exception.

  • Reported: CORBA 2.4.1 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Incorporate change and close issue

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

POAManager::deactivate should not mandate ORB::shutdown implementation

  • Key: CORBA25-3
  • Legacy Issue Number: 4034
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Section 11.3.2.6 has a paragraph that states:

    If the ORB::shutdown operation is called, it makes a call on deactivate
    with a
    TRUE etherealize_objects parameter for each POA manager known in the
    process;
    the wait_for_completion parameter to deactivate will be the same as the
    similarly
    named parameter of ORB::shutdown.

    Shouldn't this be reworded to not require an explicit call to
    deactivate(but only the effect). Also, since ORB::shutdown already does
    the equivalent of destroy on the POAs shouldn't the order of these
    operations be specified. I also think they should be specified in the
    text for ORB shutdown rather than here.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Right, make it so

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

POAManager::deactivate does not specify behavior for "reject"

  • Key: CORBA25-2
  • Legacy Issue Number: 4033
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    This is the first issue I found w/ POAManager::deactivate definition.

    The spec states in section 11.3.2.6, paragraph 1.

    Entering the inactive state causes the associated POAs to reject
    requests that have not
    begun to be executed as well as any new requests.

    However, there is no definition of what "reject" means. What does the
    client see in this case?

    Proposal:

    Add to the paragraph:
    When a request is rejected, an OBJECT_NOT_EXIST system exception with
    standard minor code XX is returned to the client.

  • Reported: CORBA 2.4.1 — Wed, 8 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    The proposal proved to be too controversial. So suggest close no change

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

Can a valuetype support multiple non-abstract interfaces via inheritance?

  • Key: CORBA25-1
  • Legacy Issue Number: 4003
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.4 specification is not clear about whether a valuetype can
    support multiple non-abstract interfaces via inheritance. Here is an
    example:

    interface I1 {};

    interface I2 {};

    valuetype V1 supports I1 {};

    valuetype V2: V1 supports I2 {};

    Is V2 legal?

    I see three possible resolutions to this issue:

    1. Make V2 illegal. A valuetype may not support a non-abstract
    interface if any of its base valuetypes supports a non-abstract
    interface. This is a pretty simple rule, but I think it is far too
    restrictive, and can get in the way of some cases where supporting
    multiple interfaces could be genuinely useful.

    2. Make V2 legal. Since we have clarified (assuming that the proposed
    resolution of 3589 passes, which it appears it will) that valuetypes
    that support an interface are not synonymous with an object reference
    that uses that valuetype as a servant, I don't see any actual core
    issues that break the object model. Also, my inspection of the language
    mappings does not reveal any problems on that front either.

    3. Make V2 illegal, but make it legal if I2 inherited from I1. The
    rule would be that a valuetype can support a non-abstract interface only
    if that interface is derived (directly or indirectly) from all other
    non-abstract interfaces that are supported by base valuetypes. This
    allows the use of the ladder inheritance pattern, which I think is very
    useful in this case:

    interface I1 {};

    valuetype V1 supports I1 {};

    interface I2 {};

    valuetype V2 supports I2 {};

    interface I3 : I1, I2 {};

    valuetype V3 : V1, V2 supports I3 {};

    Of these three posible resolutions, I prefer #2, since I don't see any
    practical implementation problems, so the restriction in #3 is really
    not necessary.

  • Reported: CORBA 2.4 — Fri, 27 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

CORBA::ORB::object_to_string() raising INV_OBJREF or BAD_PARAM

  • Key: CORBA25-6
  • Legacy Issue Number: 4128
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    There appears to be a contradiction in CORBA 2.4.1 (00-11-07) as to
    whether CORBA::ORB::object_to_string() should raise INV_OBJREF or
    BAD_PARAM when an invalid string is passed.

    Here's where I see a contradiction in the spec:

    CORBA 2.4.1: "4.11.3.6 INV_OBJREF
    This exception indicates that an object reference is internally
    malformed. For example, the repository ID may have incorrect syntax or
    the addressing information may be invalid. This exception is raised by
    ORB::string_to_object if the passed string does not decode correctly."

    This explicitly specifies that INV_OBJREF is thrown if a non-decodable
    stringified IOR is passed to string_to_object().

    On the other hand the table:
    CORBA 2.4.1: "4.11.4 Standard Minor Exception Codes ...
    BAD_PARAM ...
    7 string_to_object conversion failed due to bad scheme name.
    8 string_to_object conversion failed due to bad address.
    9 string_to_object conversion failed due to bad bad schema specific
    part.
    10 string_to_object conversion failed due to non specific reason."

    indicates that BAD_PARAM/10 should be raised for non-specific
    string_to_object failures, contradicting 4.11.3.6 above.

    Is this simply an editing issue in that 4.11.3.6 has not yet been
    updated to take cognizance of 4.11.4? I propose that 4.11.3.6 is updated
    to allow BAD_PARAM to be raised on string_to_object failures where the
    problem lies in the string content.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see above, Close issue, already fixed

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

ServantLocator preinvoke/ postinvoke semantics

  • Key: CORBA25-5
  • Legacy Issue Number: 4117
  • Status: closed  
  • Source: Borland Software Corporation ( Andy Cutright)
  • Summary:

    the 2.4 specification states that 'preinvoke and postinvoke operations
    are always called in paris in response to any ORB activity...' the spec
    details in particular the case of what happens when preinvoke is called
    when processing a GIOP Locate message: postinvoke is called subsequent
    to calling preinvoke.

    if the preinvoke raises an exception, what is the expected behavior?
    should postinvoke be called if preinvoke raises a system exception or
    ForwardRequest? are there any situations in which postinvoke would not
    be called following a call to preinvoke?

  • Reported: CORBA 2.4.1 — Wed, 10 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Clarify the expected behavior if preinvoke raises an exception

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

Minor code 2 description for OBJECT_NOT_EXIST not consistent w/ use

  • Key: CORBA25-4
  • Legacy Issue Number: 4037
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    I was looking at the spec to amend 4033 to not use up a new minor code but
    noticed this text for minor code 2 under OBJECT_NOT_EXIST:

    POAManager::incarnate failed to create POA.

    This is clearly not consistent with its use under the TRANSIENT POA Lifespan
    Policy description (I also found other inconsistent uses, detailed below).

    There are two things that need fixing here. The first one is probably
    straightforward.
    1. The minor code allocated for 4033 must be used in the text for TRANSIENT
    Lifespan Policy in section 11.3.7.2

    2. POAManager::incarnate is not a valid operation at all.
    I found references to OBJECT_NOT_EXIST with minor code 2 in the following
    places:

    A - Section 11.2.6, paragraph 2

    The adapter activator has the opportunity to create the required POA. If it
    does not, the client receives the
    OBJECT_NOT_EXIST exception with standard minor code 2.

    B - Section 11.2.6
    If the POA has the NON_RETAIN policy or has the RETAIN policy but didn't
    find a
    servant in the Active Object Map, the POA takes the following actions:
    Bullet 3

    • If t he USE_OBJECT_MAP_ONLY policy is in effect, the POA raises the
      OBJECT_NOT_EXIST system exception with standard minor code 2.

    C - 11.3.3.2 unknown_adapter
    If the operation returns TRUE, the ORB will
    proceed with processing the request. If the operation returns FALSE, the ORB
    will
    return OBJECT_NOT_EXIST with standard minor code 2 to the client.

    D - 11.3.3.2 unknown_adapter
    If the parent of a nonexistent POA does not have an
    associated adapter activator, the ORB will return the OBJECT_NOT_EXIST
    system
    exception with standard minor code 2.

    E - 11.3.7.6 Request Processing Policy
    USE_ACTIVE_OBJECT_MAP_ONLY - If the Object Id is not found in the
    Active Object Map, an OBJECT_NOT_EXIST system exception with standard
    minor code 2 is returned to the client.

    Cases A, C and D hint that minor code 2 should actually say "Could not
    create or locate POA" or something to that effect. Cases B and E should
    really be using another minor code ("Could not locate object in AOM?").

  • Reported: CORBA 2.4.1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

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

Container::lookup() ordering requirements

  • Key: CORBA25-9
  • Legacy Issue Number: 4152
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    In the Interface Repository, Container::contents() and describe_contents()
    do not seem to have any restrictions on ordering. However, these seem to
    be necessary for interoperability, so that a dynamic bridge that tries to
    find out about a Value by using Container::contents (dk_ValueMember, 0)
    does the right thing.

  • Reported: CORBA 2.4.1 — Tue, 16 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    Add language to require preservation of order of elements in IR as shown below

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

Section 2.1.7 of CORBA 2.3 and 2.4

  • Key: CORBA25-8
  • Legacy Issue Number: 4135
  • Status: closed  
  • Source: Object Management Group ( Dr. Jon M. Siegel)
  • Summary:

    Section 2.1.7 of CORBA 2.3 and 2.4 (and presumably all earlier
    versions) concludes with the sentence

    Object-oriented programming languages, such as C++ and Smalltalk,
    do not require stub interfaces.

    I suspect that this is a relic of some prehistoric age when early
    OMG folk imagined that OO languages would handle some stub stuff
    via language mechanisms. Since this has not turned out to be the
    case, the sentence should be excised.

  • Reported: CORBA 2.4.1 — Wed, 3 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    incorporate change and close issue

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

Legal IDL?

  • Key: CORBA25-7
  • Legacy Issue Number: 4132
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Is the following legal IDL?

    module M
    {
    abstract interface I

    { string s(); }

    ;

    valuetype V supports I

    { private string s; }

    ;
    };

    Our interpretation of the spec is that it is legal but we have been informed
    that some other IDL compilers consider it an error.

  • Reported: CORBA 2.4.1 — Wed, 20 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.5
  • Disposition Summary:

    see below

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

Issues related to CCM's XML descriptors: chapter 69.4.5.4

  • Key: CORBA3-124
  • Legacy Issue Number: 5493
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.4
    "The information obtained by (...) it allows component assembly
    tools to decide WHAT ports
    on a component are capable (...)"
    it seems that the word "which" would be better than "what" in
    this sentence

  • Reported: CCM 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Replace "what" by "which".

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

Creating IORs

  • Key: CORBA3-128
  • Legacy Issue Number: 4478
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    > // ulgy conversion to objectref: we should think about
    > // creating utilities for IOR<->objref conversion

    I meant to raise that second issue (the ugly IOR to ObjRef conversion).
    It is too painful and I think we should address it. I can think of a few
    possible solutions.

    1. have make object just return profiles, so the ORB can do the
    conversion internally.
    2. Add a method on the ORT to provide this functionality
    3. Add a separate CODEC interface to manufacture IORs from Profiles
    (IORFactory, rir etc)

  • Reported: CORBA 2.4.2 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Undo the resolution of issue 4476 and close 4478 no change

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

There is no way to modify a POA's ORT and append to it

  • Key: CORBA3-127
  • Legacy Issue Number: 4476
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    If I wish to register an ORF (ObjectReferenceFactory) as the current
    factory, there is no way for it to append to the current template. In
    other words, an updated factory can only replace the original but not
    say add another profile to the one the given POA would generate w/ the
    adapter template.

    As an inverse, there is no way for a POA to require or even request an
    ORF to include profiles that it deems fit.

    Proposal:

    Add a parameter to make_object

    Object make_object( in string repositoryId, in ObjectId id,
    ObjectReferenceTemplate template);

    Add the following methods to ObjectReferenceTemplate

    abstract valuetype ObjectReferenceTemplate : ObjectReferenceFactory

    { readonly attribute ServerId server_id ; readonly attribute ORBId orb_id ; readonly attribute AdapterName adapter_name; ProfileSeq getProfiles(in string repositoryId, in ObjectId id); ComponentSeq getComponents(in IOP::ProfileId profile_id); }

    ;

    where ProfileSeq is defined as

    module IOP

    { typedef sequence <TaggedProfile> ProfileSeq; typedef sequence <TaggedComponent> ComponentSeq; }

    Add the following sections:

    21.5.3.8 getProfiles

    This returns the set of profiles that the POA would have generated using
    its default template. This can optionally be included in the generated
    IOR.
    [ED: This is independent of make_object, because make_object returns an
    object reference from which profiles would have to be extracted for
    inclusion]

    21.5.3.9 getComponents
    This returns set of components that would have been include in the
    profile with the id profile_id and allows the factory to choose to
    include those in the profiles that it generates.

  • Reported: CORBA 2.4.2 — Sun, 12 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    see above

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

Interoperability of ObjectReferenceTemplate and Factory.

  • Key: CORBA3-126
  • Legacy Issue Number: 4445
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    Nothing in the specs (I think the submission does say this somewhere)
    say that the valuetypes defined in this spec and implemented by the ORB
    vendor are not expected to be transmitted across different ORB
    implementations.

    Proposal:

    Add paragraph to 51.5.3.1:

    Concrete definitions and implementations of ObjectReferenceTemplate and
    ObjectReferenceFactory are ORB implementation specific and are not
    defined as they are not expected to be exchanged between ORB
    implementations.

  • Reported: CORBA 2.4.2 — Thu, 2 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Add a clarification to the specification

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

Object Adapter name problem in ORT

  • Key: CORBA3-125
  • Legacy Issue Number: 4440
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The adopted specification for the Object Reference Template is
    ptc/01-04-03. This specification introduces adapter names for
    object adapters. Adapter names are needed in the definition of the
    ObjectReferenceTemplate abstract valuetype. An AdapterName is
    simply a sequence of strings that is used to identify an
    instance of an object adapter.

    In the case of the POA, the spec defines the AdapterName as follows
    in section 21.5.2.1:

    In the case of the POA, the adapter name shall be the sequence
    of names starting with the root POA that is required to reach
    the POA using the find_POA call. The name of the root POA is
    the empty sequence.

    Also, in section 21.3.14.6:

    The adapter_name attribute defines a name for the object adapter that
    services requestws for the invoked object. In the case of the POA,
    the adapter_name is the sequence of names from the root PAO to the POA
    that services the request. The root POA is not named in this sequence.

    The problem here is that the POA occupies the entire name space of
    possible adapter names, so an ORB that supports other proprietary
    object adapters cannot unambiguously identify instances of other
    object adapter through ServerRequestInfo.adapter_name.

  • Reported: CORBA 2.4.2 — Mon, 30 Jul 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    Update the specification so that the Object Adapter ID of the root POA is

    { "RootPOA" }
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Productions 140, 141, 142 and 143 must be removed

  • Key: CORBA3-116
  • Legacy Issue Number: 5500
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions 140, 141, 142 and 143 must be removed. Catalog has been
    removed
    from the PSS specification.
    Production 145 : <home_executor_body> refers to <stored_on_dcl> which is
    defined in production 151
    as <home_persistence_dcl>. Pick one or the other and changes references
    as required ...
    Productions 149 and 150 are not valid any more. Remove them and add a
    new production :
    <abstract_storage_home_name> ::= <identifier>
    identifier must be the name of an abstract storagehome previously
    declared

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

paragraph 60.2.1 : There is two mistakes in keywords

  • Key: CORBA3-115
  • Legacy Issue Number: 5499
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:
    • Capital letters are not appropriated. Correct "storageHome" with
      "storagehome".
    • The keyword "catalog" must be removed as it was removed from PSDL.
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Update Table 5-13 in the EJB Chapter of formal/02-06-65

  • Key: CORBA3-123
  • Legacy Issue Number: 5588
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In ptc/01-11-03, page 64-410, there is the following note

    Issue This table will be completed after the Interface Repository
    chapter is ready.

    Then Table 5-13 in formal/02-06-65 would be completed.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Editorial issues in formal/02-06-65

  • Key: CORBA3-122
  • Legacy Issue Number: 5585
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains some texts removed by the Components December
    2000 RTF (ptc/01-11-02 and ptc/01-11-03). See at

    formal/02-06-65 ptc/01-11-03

    page 1-24 and 25 page 61-241
    page 1-26 page 61-243
    page 1-28 page 61-245
    page 4-37 page 62-363
    page 6-67 page 69-542
    page 6-72 page 69-548
    page 8-23 page 70-601

    Remove these old texts once again.

    Proposed revised text:

    Following must be applied on formal/02-06-65.

    At pages 1-24 and 1-25, remove

    module <module_name> {
    module <component_name>EventConsumers

    { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { Components::Cookie subscribe_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer) raises (Components::ExceededConnectionLimit); <component_name>EventConsumers:: <event_type>Consumer unsubscribe_<source_name> (in Components::Cookie ck) raises (Components::InvalidConnection); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); };
    };
    };


    At page 1-26, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; }

    ;
    interface <component_name> : Components::CCMObject

    { void connect_ <source_name> ( in <component_name>EventConsumers:: <event_type>Consumer consumer ) raises (Components::AlreadyConnected); <component_name>EventConsumers:: <event_type>Consumer disconnect_ <source_name>() raises (Components::NoConnection); }

    ;
    module <component_name>EventConsumers {
    interface <event_type> Consumer :
    Components::EventConsumerBase

    { void push (in <event_type> evt); };
    };
    };


    At page 1-28, remove


    module <module_name> {
    module <component_name>EventConsumers { interface <event_type>Consumer; };
    interface <component_name> : Components::CCMObject { <component_name>EventConsumers:: <event_type>Consumer get_consumer _<sink_name>(); };
    module <component_name>EventConsumers {
    interface <event_type>Consumer :
    Components::EventConsumerBase { void push (in <event_type> evt); }

    ;
    };
    };

    At page 4-37, remove in Session2Context interface
    the two occurrences of PortableServer::ObjectId.

    At page 6-67, remove

    Note Of the interfaces described below, only
    ComponentInstallation,
    AssemblyFactory, and Assembly are required by this specification;
    the other
    interfaces are included for illustrative purposes and to support an
    end-to-end scenario.

    At page 6-72, remove

    exception InvalidLocation { };

    At page 8-23, remove Figure 8-20.

  • Reported: CORBA 3.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Remove section 4.4.1.4 in formal/02-06-65

  • Key: CORBA3-120
  • Legacy Issue Number: 5583
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Proposed resolution:

    The Adopted CORBA Components Specification (formal/02-06-65)
    always contains the section 4.4.1.4 at page 4-36.

    However, this section was removed in the ptc/01-11-03 document
    by the resolution of the issue 3937 of the Final Report of
    Components December 2000 FTF (ptc/01-11-02).

    Proposed revised text:

    In formal/02-06-65 page 4-36, remove the section 4.4.1.4.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

create operation of AssemblyFactory interface

  • Key: CORBA3-119
  • Legacy Issue Number: 5577
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Dr. Tom Ritter)
  • Summary:

    The name of the create operation in the AssemblyFactory Interface shall
    be renamed to a more specific identifier. Create is often used in other
    interfaces and this may lead to problems e.g. in inheritance relationships.

    suggested change:

    create -> create_assembly

  • Reported: CORBA 3.0 — Tue, 13 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see below

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

CIDL Grammar problems: Productions must be renumbered : 134 -> 1, ...

  • Key: CORBA3-114
  • Legacy Issue Number: 5498
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    Productions must be renumbered : 134 -> 1, ...

    In all productions, replace ...storage_home... by ...storagehome... and
    ...storage_type...
    by storagetype...

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

69.8.2 Property File XML Elements

  • Key: CORBA3-118
  • Legacy Issue Number: 5507
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    1. 69.8.2.1 The properties Root Element, page 69-537
    Properties Element Cardinality. Suggested change is to replace "*" with "
    +".
    Why does it make sense to have an empty properties file, since the
    properties are
    optional references in the Software Package DTD, CORBA Component DTD, and
    Component Assembly DTD?

    Current Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )*
    ) >

    Suggested New Format

    <!ELEMENT properties
    ( description?
    , ( simple

    sequence
    struct
    valuetype
    )+
    ) >
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Typo (??) in chapter 61

  • Key: CORBA3-117
  • Legacy Issue Number: 5506
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the CCM specification document ptc/2001-11-03 page 61-227
    the 'session' word should be removed from the OMG IDL 3.0
    example, i.e.:

    component baz session {

    should be replaced by:

    component baz {

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the typo by removing the 'session' word

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

Corrections in XML DTDs for packaging

  • Key: CORBA3-121
  • Legacy Issue Number: 5584
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the Adopted CORBA Components Specification (formal/02-06-65),
    page 6-4, section 6.3.2.1, the version attribute of the softpkg
    element is tagged as #OPTIONAL and is tagged as #IMPLIED at page 7-5.
    As #OPTIONAL is not valid in XML, then replace it by #IMPLIED.

    In chapter 7, the softpkg XML DTD does not contain the
    ins and objref elements which they are used by the repository
    element described at page 7-4. Add them.

    Proposed revised text:

    In formal/02-06-65:

    At page 6-4, section 6.3.2.1, replace #OPTIONAL
    by #IMPLIED for the version attribute of the softpkg element.

    At page 7-3, add before the humanlanguage element

    <!ELEMENT ins EMPTY >
    <!ATTLIST ins
    name CDATA #REQUIRED >

    At page 7-4, add before the os element

    <!ELEMENT objref EMPTY >
    <!ATTLIST objref
    string CDATA #REQUIRED >

  • Reported: CORBA 3.0 — Wed, 21 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: connectevent element

  • Key: CORBA3-106
  • Legacy Issue Number: 5093
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-521 (ptc/01-11-03), the connectevent
    element of an Assembly Descriptor is defined as

    <!ELEMENT connectevent (consumesport,
    (emitsport |
    publishesport))>

    This does not allow for emits and publishes
    ports to be connected to existing consumer
    interfaces that are registered in the naming
    or trading service. I suggest to change that
    element in the spirit of connectinterface to

    <!ELEMENT connectevent (emitsport |
    publishesport) ,
    (consumesport |
    existinginterface)>

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: registercomponent element

  • Key: CORBA3-105
  • Legacy Issue Number: 5092
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    On page 69-532 (ptc/01-11-03), the
    registercomponent element of an Assembly
    Descriptor is defined to optionally
    contain an emitsidentifier and publishes-
    identifier element, in order to register
    an event source in the Naming or Trading
    Service. There is also a note saying, "In
    the case of events, what gets registered?"

    I suggest to replace the emitsidentifier
    and publishesidentifier elements with the
    consumesidentifier element, and to change
    the first two paragraphs to read:

    "The registercomponent element is to specify
    that a component, a provided interface, or
    an event consumer interface should be regis-
    tered with a naming service or trader.

    If a consumesidentifier or publishesidentifier
    is specified, then that element is registered.
    If none of the above are specified, then it is
    implied that the component itself is to be
    registered."

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

components-ftf: repository id in software package descriptor

  • Key: CORBA3-104
  • Legacy Issue Number: 5091
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    The id attribute of the idl element in a
    Software Package Descriptor currently
    contains the Repository Id of the component.

    I suggest to change this to the Repository
    Id of the home, as the home implies the
    component, but not vice versa. This makes
    it easier for the deployment application to
    find out about the home interface, e.g. for
    the purpose of configuring properties.

  • Reported: CORBA 2.6 — Tue, 26 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The Repository Id of the home should be added as an attribute of the idl element

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

IDL3 keyword "eventtype" conflicts with struct "CosNotification::EventType

  • Key: CORBA3-103
  • Legacy Issue Number: 4986
  • Status: closed  
  • Source: Tech-X ( Nanbor Wang)
  • Summary:

    The "eventtype" keyword defined in Section 3.2.4 of the "CORBA 3.0 New
    Components Chapters" (ptc/2001-11-03) will make the Notification
    Service IDL un-compilable because Notification Service defines a
    struct called "EventType" in Section 3.1 of formal/00-06-20.

    I guess one of the specs will have to change.

  • Reported: CORBA 2.6 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 695.4

  • Key: CORBA3-113
  • Legacy Issue Number: 5497
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 695.4
    the elements aren't in the alphabetical order
    proxyhome must be placed before publishesidentifier

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.7.2.38

  • Key: CORBA3-112
  • Legacy Issue Number: 5496
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.38
    the processcollocation element given in this chapter lacks a
    DESTINATION child element
    right one:
    <!ELEMENT processcollocation
    (usagename?
    , impltype?
    , (homeplacement

    extension
    )+
    ,destination?
    )>
    <!ATTLIST processcollocation
    id ID #IMPLIED
    cardinality CDATA "1">
  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issue regarding language mapping for keyless homes

  • Key: CORBA3-107
  • Legacy Issue Number: 5340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In 01-11-03.pdf page 61-255

    Given a base home definition with a primary key (H, T, K), and a derived home
    definition with no primary key (H', T'), such that H' is derived from H, then the
    definition of H' implicitly includes a primary key specification of type K, becoming
    (H', T', K). The implicit interface for H' shall have the form specified for an
    implicit interface of a home with primary key K and component type T'.

    In same document section 615.3.3.6 Home I see no mention that a keyless
    home that inherits from a keyed home is implicitly a keyed home and thus
    the Home Implicit Executor Interface must be constructed for a keyed home
    using the key type declared for the base keyed home. Everyone agree?

  • Reported: CORBA 3.0 — Fri, 7 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Generic operations for subscribing/unsubscribing at publishing ports

  • Key: CORBA3-102
  • Legacy Issue Number: 4983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    generic operations for subscribing and unsubscribing at publishing ports of components should have the same funtionality as the specific ones. Therefore the generic unsubscribe operation should return the unsubscribed consumer reference like the specific operation does. proposal: change

    void unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

    to

    EventConsumerBase unsubscribe (in FeatureName publisher_name, in Cookie ck) raises (InvalidName, InvalidConnection);

  • Reported: CORBA 2.6 — Fri, 15 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

simple type element of the property file issue

  • Key: CORBA3-108
  • Legacy Issue Number: 5429
  • Status: closed  
  • Source: Computational Physics, Inc. ( J. Scott Evans)
  • Summary:

    In document 01-11-03.pdf section 69.8.2.8 the simple type element
    of the property file descriptor excludes the types:

    long long
    unsigned long long
    long double
    wchar

    Is there any reason why we can't add these types to the simple element?

  • Reported: CORBA 3.0 — Thu, 13 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.7.2.25

  • Key: CORBA3-111
  • Legacy Issue Number: 5495
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.7.2.25
    the given reference to the fileinarchive element is wrong
    (69.3.2.11);
    the right one is 69.3.2.12

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Correct the false cross-reference

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

Issues related to CCM's XML descriptors: chapter 69.4.5.16

  • Key: CORBA3-110
  • Legacy Issue Number: 5494
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.5.16
    this eventpolicy element is said to be child element of
    corbacomponent
    in fact it can be child element of: consumes, emits, publishes
    but it's NOT a child element of corbacomponent

  • Reported: CORBA 3.0 — Tue, 23 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Issues related to CCM's XML descriptors: chapter 69.4.4

  • Key: CORBA3-109
  • Legacy Issue Number: 5492
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    chapter 69.4.4
    the sample componentkind definition given as an entity with
    "process" lifetime seems
    unadapted as described in 69.4.5.49, we can give a best lifetime
    with "container"

  • Reported: CORBA 3.0 — Mon, 15 Jul 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

add a ClientInterceptor then create_POA() in the post_init() method?

  • Key: CORBA3-95
  • Legacy Issue Number: 5764
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Isit possible to add a ClientInterceptor then create_POA() in the
    post_init()
    method? It seems that the ClientInterceptor is not called after that. Do
    you know the
    reason why?

    My Investigation:
    If the post_init method in SampleClientLoader.C creates the new POA
    using create_POA method, the client side PI will not be called. Even if
    an ORB-mediated call is made from within post_init(), ServerInterceptor
    is called beyond the scope of post_init(). Moreover, even if an
    ORB-mediated call is made from within post_init() in VisiBroker for
    Java, ClientInterceptor and ServerInterceptor are called beyond the
    scope of post_init(). However, in Visibroker for C++, the
    ClientInterceptor of VBC is not called. Please see the attachments for
    the difference in results of VBC & VBJ. A testcase is also attached.

    Any comments will be greatly appreciated.

  • Reported: CORBA 3.0.1 — Mon, 18 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

CORBA::WrongTransaction and Interceptors

  • Key: CORBA3-94
  • Legacy Issue Number: 5743
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How can a portable OTS implementation, using only Portable Interceptors,
    achieve the correct semantics for raising CORBA::WrongTransaction from
    Request::get_response or ORB::get_next_response or type specific
    pollers? There doesn't appear to be a way to do this for two reasons:

    1. ClientRequestInterceptors can only change a request result into a
    system exception, but WrongTransaction is a user exception.

    2. 21.4.4.6 says:

    "Interceptors shall assume that each client-side interception point
    logically runs in its own thread, with no context relationship between
    it and any other thread. While an ORB implementation may not actually
    behave in this manner, it is up to the ORB implementation to treat
    PICurrent as if it did."

    I take this to mean that the PICurrent in the receive_* client
    interception points cannot be guaranteed to share the same slot data as
    the client thread that called Request::get_response. This means that
    the interceptor has no way to determine whether or not the transaction
    context of the client thread matches that of the request.

  • Reported: CORBA 3.0 — Thu, 31 Oct 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolved together with 3599. Resolution appears in the resolution for 3599

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

How do Portable Interceptors interact with Messaging callbacks

  • Key: CORBA3-93
  • Legacy Issue Number: 5726
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In the messaging callback model, the response is delivered as a request
    invocation on another object. What is the call-pattern for
    ClientRequestInterceptors in this case?

    My guess is that the receive_other interception point is called for each
    registered ClientRequestInterceptor.

  • Reported: CORBA 3.0 — Fri, 25 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-92
  • Legacy Issue Number: 5691
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Fri, 18 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive.

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

ORBInitInfo::arguments() underspecified

  • Key: CORBA3-91
  • Legacy Issue Number: 5690
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    21.7.2.3 states:

    "This attribute contains the arguments passed to ORB_init. They may or
    may not contain the ORB's arguments."

    First, what good does this do? A portable application can't depend on
    anything useful being returned by this attribute.

    This should be changed to state that ORBInitInfo::arguments() returns
    the original unmodified argv parameter that was passed to ORB_init.


    Second, this attribute really ought to be read-write, so that an
    Interceptor implementation can find and strip out arguments that are
    intended for the Interceptor.

    Alternatively, we should specify a standard prefix for arguments that
    are recognized and processed by interceptors, so that the ORB and client
    code can be explicitly coded to recognize and ignore them.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Exception handling in Interceptor initialization

  • Key: CORBA3-90
  • Legacy Issue Number: 5689
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    It is undocumented what should happen if an exception is thrown while
    the ORB initialization process is calling ORBInitializer::pre_init or
    post_init.

    In section 21.7.3.1 concerning the Java binding, the following statement
    related to calling pre_init and post_init appears:

    "If there are any exceptions, the ORB shall ignore them and proceed."

    Taking this as precedent, it suggests that exceptions raised by pre_init
    and post_init should be ignored. However, I'm not convinced that this
    is a good idea, since a failure in an ORBInitializer is very likely to
    cause the application to fail in mysterious ways later on that would be
    difficult to debug.

    I think it would be better to define explicit behavior for exceptions
    raised from pre_init and post_init to be that the ORB initialization is
    abandoned and the ORB is destroyed. Any ORBInitializer implementation
    that really needs the ORB to ignore any thrown exceptions can simply
    catch and discard them itself.

  • Reported: CORBA 3.0 — Wed, 16 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Derived component supported interface restriction (formal/2002-06-01)

  • Key: CORBA3-89
  • Legacy Issue Number: 5687
  • Status: closed  
  • 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."
    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
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Local types allowed as valuetype state?

  • Key: CORBA3-88
  • Legacy Issue Number: 5674
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    A bullet in 3.8.7 states:

    "o A local type may not appear as a parameter, attribute, return type,
    or exception declaration of an unconstrained interface or as a state
    member of a valuetype."

    while 3.9.1.4 says:

    "A valuetype that has a state member that is local (i.e. non-marshalable
    like a local interface), is itself rendered local. That is, such
    valuetypes behave similar to local interfaces when an attempt is made to
    marshal them."

    I presume the second statement is the correct one.

    Proposed resolution:

    Strike "or as a state member of a valuetype." from the bullet in 3.8.7.

  • Reported: CORBA 3.0 — Sat, 12 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Presumption is correct. Fix as suggested

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

Why does PollableSet::number_left() return unsigned short?

  • Key: CORBA3-87
  • Legacy Issue Number: 5673
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Is there a particular design reason to limit the Pollable count to
    65535?

  • Reported: CORBA 3.0 — Mon, 7 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Incorporate change and close issue

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

Pollable in more than one PollableSet?

  • Key: CORBA3-86
  • Legacy Issue Number: 5672
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The descriptions of Pollable and PollableSet in 7.4 do not indicate if
    it is legal to add a Pollable to more than one PollableSet. If this is
    made illegal, it is easier to implement Pollable and PollableSet to
    cooperate behind the scenes to improve the efficiency of the PollableSet
    implementation.

    Recommended Resolution:

    Make it illegal to add a Pollable to more than one PollableSet, by
    adding the following text to 7.4.3.2:

    "If the supplied Pollable has already been added to another PollableSet,
    this operation raises the standard BAD_PARAM system exception with minor
    code XYZ.

    and add a new minor code for BAD_PARAM to appendix A:

    "XYZ: Attempt to add a Pollable to a second PollableSet."

  • Reported: CORBA 3.0 — Sat, 5 Oct 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Oneway operations should not generate sendc_ and sendp_ variants

  • Key: CORBA3-85
  • Legacy Issue Number: 5669
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Somewhere in the discussion in 22.6, it should specify that oneway
    operations are not mapped with sendc_ and sendp_ variants, because they
    would be useless.

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

DII sendc reply delivery underspecified

  • Key: CORBA3-84
  • Legacy Issue Number: 5668
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    7.2.10 states that sendc delivers the reply by using the supplied
    Messaging::ReplyHandler, but it does not spell out the mechanics of the
    delivery.

    I presume that for an invocation of operation "foo", the "foo" or
    "foo_excep" methods of the ReplyHandler will be invoked to deliver the
    reply

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Yes, indeed. Insert a short description in section 7.10.2 on how the reply is obtained from the Repl

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

Bad example code in 22.11.4.3

  • Key: CORBA3-83
  • Legacy Issue Number: 5667
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The example code in 22.11.4.3 seems to be from a draft version of the
    Messaging specification where the Pollable type was an interface rather
    than a valuetype

  • Reported: CORBA 3.0 — Mon, 30 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Turns out that the examples in both 22.11.4.2 and 22.11.4.3 need fixing. Make changes as described

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

Messaging Poller generation is broken for interfaces with multiple inherite

  • Key: CORBA3-82
  • Legacy Issue Number: 5666
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    22.10.1 states that Type-Specific poller valuetypes inherit from the
    poller valuetype associated with the interface that the original
    interface inherits from. This does not address multiple inheritance,
    and in fact it cannot, since valuetype inheritance is more limited than
    interface inheritance.

    The problem is that the base valuetype for polling, Messaging::Poller,
    is not abstract, and cannot be inherited more than once by a derived
    valuetype. So as it stands now, the AMI polling model is broken for
    multiple inheritance, and needs to be treated as an urgent issue in
    order to produce an immediate fix.

    Proposed resolution:

    1. Make Messaging::Poller an abstract valuetype, and remove the state
    members from it. Change the IDL for Poller in 22.9 and 22.16.1 to:

    module Messaging {
    abstract valuetype Poller : CORBA::Pollable

    { readonly attribute Object operation_target; readonly attribute string operation_name; attribute ReplyHandler associated_handler; readonly attribute boolean is_from_poller; }

    ;
    };

    2. Add back the private target and op_name state members to the
    persistent type-specific poller valuetypes. Modify the example IDL in
    22.10.2 to:

    valuetype AMI_<ifaceName>PersistentPoller : AMI_<ifaceName>Poller

    { private MessageRouting::PersistentRequest outstanding_request; private Object target; private string op_name; }

    ;

    This is necessary so the PersistentPoller can be propagated from one
    process to another with all of its necessary state.

    3. Change the text in 22.10.1 that describes inheritance of
    type-specific pollers to:

    For each interface, the IDL compiler generates a type-specific Poller
    value. A Poller is created by the ORB for each asynchronous invocation
    that uses the polling model operations. The name of the basic
    type-specific Poller is AMI_<ifaceName>Poller, where ifaceName is the
    unqualified name of the interface for which the Poller is being
    generated. If the interface ifaceName derives from one or more IDL
    interfaces, then the Poller is derived from the corresponding
    Poller for each base interface, but if it does not, then it is derived
    from Messaging::Poller. Poller valuetypes are declared abstract. If
    this name conflicts with definitions in the original IDL, additional
    AMI_ prefixes are prepended before <ifaceName> until a unique valuetype
    name is generated (such as "AMI_AMI_FooPoller"for interface Foo).

    4. Change the example IDL in 22.10.3 to make the poller abstract:

    // AMI implied-IDL of type-specific Poller
    // for original example IDL defined in Section 22.5
    abstract valuetype AMI_StockManagerPoller : Messaging::Poller {
    ...

    and add the target and op_name private state members to the persistent
    poller:

    valuetype AMI_StockManagerPersistentPoller : AMI_StockManagerPoller

    { private MessageRouting::PersistentRequest request; private Object target; private string op_name; }

    ;

  • Reported: CORBA 1.1 — Mon, 28 Sep 1992 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Make the changes recommended in the archive

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

name disambiguation for AMI interface & poller names is confusing

  • Key: CORBA3-81
  • Legacy Issue Number: 5665
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The rule for generating a unique AMI_ callback or poller name is to
    stuff additional "AMI_" strings until the name is unique. However,
    consider the following IDL:

    // IDL
    module M {

    interface A {
    };

    interface AMI_A {
    };

    };

    this apparently maps to the implied IDL:

    // implied IDL
    module M {

    interface A {
    };

    interface AMI_AMI_A

    { // callback interface for A }

    ;

    interface AMI_A {
    };

    interface AMI_AMI_AMI_A

    { // callback interface for AMI_A }

    ;
    };

    however, if I switch the order of declaration of A and AMI_A, the names
    of the associated callback interfaces change.

    Not only that, but if I split the IDL into two files:

    // File 1
    module M {

    interface A {
    };
    };

    // File 2
    module M {
    interface AMI_A {
    };

    };

    and try to compile them separately, the generated code will fail.

    I don't think there is any solution to this problem other than to
    declare it an error to use an IDL identifier that begins with "AMI_" if
    it causes a name clash.

    The same problem applies to the AMI poller valuetypes.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Insert the requirement that any IDL that is meant to be used for AMI should not have any

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

potential name clash with Messaging type-specific poller timeout argument

  • Key: CORBA3-80
  • Legacy Issue Number: 5663
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The name generated for the type-specific poller timeout argument is
    "timeout", which could clash with a real IDL argument name.

    The name should be changed to "ami_timout", similar to "ami_return_val".

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    make it so

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

What ORBInitInfo operations are legal during pre_init() and post_init()?

  • Key: CORBA3-101
  • Legacy Issue Number: 5692
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There is no information in chapter 21 that specifies which operations on
    ORBInitInfo can be legally called during pre_init or post_init.

    The intention appears to be that calls to register new interceptors or
    allocate a new slot id should be illegal during post_init.

    Calling resolve_initial_references during pre_init does not appear to be
    wise, but otherwise seems benign.

    Proposed resolution:

    Add the following to 21.7.1.2:

    "During a call to post_init(), invoking the ORBInitInfo methods:
    add_client_request_interceptor, add_server_request_interceptor,
    allocate_slot_id or add_ior_interceptor will raise the BAD_INV_ORDER
    standard system exception with minor code nnn."

  • Reported: CORBA 3.0 — Thu, 17 Oct 2002 04:00 GMT
  • Disposition: Duplicate or Merged — CORBA 3.0.2
  • Disposition Summary:

    duplicate of issue 5691

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

AMI vs abstract & local interfaces

  • Key: CORBA3-100
  • Legacy Issue Number: 5664
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The spec is silent about the interaction of AMI implied IDL and abstract
    interfaces

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that sendc_ and sendp_ operations are not generated for abstract interfaces

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

Sending codeset context more than once?

  • Key: CORBA3-99
  • Legacy Issue Number: 3318
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Question: Is it legal to send the same codeset context more than once
    on the same connection?

    The spec says:

    Codeset negotiation is not performed on a per-request basis,
    but only when a client initially connects to a server.

    These words suggest that the codeset must be sent on the first request,
    but don't say whether it's OK to send it more than once.

    I would like to have clarification, and also a loose interpretation. Here
    is why:

    A multithreaded client starts talking to a new object from
    multiple threads more or less simultaneously. If the codeset
    info must be sent only on the first request and is illegal on
    subsequent requests, we end up with rather complex locking
    logic in the connection management layer of the ORB. In effect,
    each request is no longer a stand-alone and context-free thing;
    instead, how to send a specific request now depends on what
    other threads may have done in the past.

    That's not very nice (even though it can be implemented) because
    it needlessly complicates things.

    So, I would like to change things such that it is legal to send the
    codeset context even if it was sent previously on the same connection.
    When that happens, the server should simply and silently ignore all
    but the first context (even if the subsequent contexts have different
    codeset information from earlier ones). That way, requests remain
    context-free. [ Yet again, we see a sterling demonstration that attaching
    semantics to the duration of a connection was a very bad idea, especially
    in a model that is connectionless ]

    Further, it seems pointless to send codeset info at all unless the client
    actually uses an operation that involves a wchar or wstring parameter.
    So, I think it would make sense to relax things such that the codeset
    need not be sent until the first request is made that requires sending it.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Getting reply svc ctxts from PersistentRequests

  • Key: CORBA3-98
  • Legacy Issue Number: 2629
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It does not appear that reply service contexts are maintained when retrieving
    polled requests from a Router. Although the Router interfaces properly
    propogate the service contexts to the the untyped reply handler representing the
    PersistentRequest, there is no way for the client to retrieve these contexts
    from the PersistentRequest::get_reply. This may make it impossible for the
    client to interpret the reply data (e.g. if the reply contained CodeSet
    contexts).

  • Reported: CPP 1.0 — Tue, 4 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Type code creation

  • Key: CORBA3-97
  • Legacy Issue Number: 5771
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The core spec says in section 4.11.3:

    Typecode creation operations that take name as an argument shall check that
    the name
    is a valid IDL name or is a null string.

    This is oxymoronic: we are talking about IDL here; IDL does not have the
    concept of
    a null string. If anything, we can say "empty string".

    Looking at this bit of spec, it would appear that a call such as

    orb->create_interface_tc(someRepId, 0);

    is legal. But that doesn't make sense because it's illegal to pass null
    pointers
    across IDL interfaces in C++ (or null references as strings in Java).

  • Reported: CORBA 3.0.1 — Sun, 1 Dec 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

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

Unfortunate CDR Encapsulation of ASN.1 Encodings

  • Key: CORBA3-96
  • Legacy Issue Number: 5766
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Document: Chapter 24 Corba, CSIv2

    There is a misinterpretation in the current JDK implementations as to the
    interpretation of the word of "encapsulation" in the CSIv2 specification
    in relation to the encoding of the fields within the CSI Identity Token.

    The issue is that the JDK and already certified implementations have
    performed a CDR encapsulation of the byte arrays within the Identity
    Token. This CDR encapsulation is not needed as the the Identity Token is
    already a CDR encapsulation, so further CDR encapsulating the byte array
    containing the ASN.1 encodings is inefficient.

    We can suggest that current implementations do not generate CDR
    encapsulation for these fields, yet accept them to be compatible with
    misaligned implementations.

    Proposed Fix:

    Remove the word "encapsulation" before "octet stream" from the rows of the
    table 24-2 "Identity Token Types".

    Remove the word "encapsulation" in the paragraph in section 24.2.3
    "Authorization Token Format".

    Remove the word "encapsulated" in the comments in the IDL section for the
    definition of the X509CertifcateChain.

    Remove the sentence "The two-part SEQUENCE is encapsulated in an octet
    stream." in the IDL definition for "const AuthorizationElementType
    X509AttributeCertChain".

    Add paragraph to section 24.2.5 "Identity Token Formats".

    The identity token for ITTPrincipalName, ITTDistinguishedName,
    ITTX509CertChain should contain their respective ASN.1 encodings of the
    name directly. However, the token may contain a CDR encapsulation of the
    octet stream that contains the ASN.1 encoding of the name. The TSS shall
    distinguish the difference by the first octet of the field. The values of
    0x00 or 0x01 shall indicate that the field contains a CDR encapsulation.
    Any other value indicates the field for these identity token types
    contains the ASN.1 encoded value. For instance, the ASN.1 encoding for
    ITTPrincipalName starts with 0x04, and ITTDistinguishedName and
    ITTX509CertChain each start with 0x30. The TSS shall accept both the CDR
    encapsulation form and the direct ASN.1 encoding for these identity token
    types.

  • Reported: CORBA 3.0.1 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Indeed a severe interoperability problem. Fix as suggested.

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

Messaging type-specific poller valuetypes should be abstract

  • Key: CORBA3-79
  • Legacy Issue Number: 5661
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The generated type-specific poller valuetypes generated for an interface
    should be abstract valuetypes and should inherit the corresponding
    type-specific poller valuetypes of the base interfaces.

    Without this, code reuse is prevented in both implementing the
    type-specific poller valuetypes, as well as in using them in client
    code.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The resolution of 5666 fixes this. Close this one no change with that comment

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

Errors in definition of Messaging poller types

  • Key: CORBA3-78
  • Legacy Issue Number: 5660
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definintion of Messaging::Poller in section 22.9 is missing the
    keyword "private" on the target & op_name valuetype attribute
    declarations.

    The persistent poller in 22.10.2 is also missing a "private" on the
    "outstanding_request" attribute, as well as the example in 22.10.3.

  • Reported: CORBA 3.0 — Fri, 27 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolution: Fix as suggested. No problem with versioninhg since the published IDL already contains t

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

Messaging: bad example code for type specific poller

  • Key: CORBA3-77
  • Legacy Issue Number: 5642
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    22.10.3 has bad example code for the type specific poller generated for
    the StockManager interface. The AMI_StockManagerPoller is shown with
    the following:

    valuetype AMI_StockManagerPoller : Messaging::Poller

    { ... attribute AMI_StockManagerHandler associated_handler; ... }

    ;

    This is illegal, since Messaging::Poller also defines an attribute named
    "associated_handler". Since the text does not specify that this
    attribute ought to be generated in a type-specific poller, I suspect
    that this is an editing mistake from a draft version of the Messaging
    RFP response and should be removed.

    The C++ example generated code in 22.11.4.2 also needs to be edited to
    remove the associated_handler attribute as well.

  • Reported: CORBA 3.0 — Wed, 11 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The observation above is correct. Fix it

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

SyncScope for oneway invocations

  • Key: CORBA3-76
  • Legacy Issue Number: 5641
  • Status: closed  
  • Source: Eternal Systems ( Wenbing Zhao)
  • Summary:

    I was reading the CORBA specification (formal/02-06-01) concerning the
    SyncScope for oneway invocations. I found out that there is a mismatch on
    the meaning of SYNC_WITH_TARGET:

    On page 21-23 (Request Interceptors), there is the following paragraph:

    "For SYNC_WITH_SERVER and SYNC_WITH_TARGET, the server does send an empty reply back to the client before the target is invoked."

    That is true for SYNC_WITH_SERVER, but not correct according to the specification of the CORBA Messaging service, given on page 22-7:

    "SYNC_WITH_TARGET - equivalent to a synchronous, non-oneway operation in CORBA. The server-side ORB shall only send the reply message after the target has completed the invoked operation."

    Note that a reply is send back to the client AFTER the target has completed the invoked operation, not BEFORE.

    This error has been around already in eariler versions of the CORBA specification.

  • Reported: CORBA 3.0 — Mon, 9 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The statement about SYNC_WITH_TARGET in 21-23 is indeed wrong. Fix it.

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

Messaging time based policy enforcement?

  • Key: CORBA3-75
  • Legacy Issue Number: 5626
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 22.2.4 provides various time-based policies to bound the
    delivery and lifetime of requests, but has no information about who
    (client, router or target server) is responsible for enforcing those
    policies. Without this information, there will certainly be
    interoperability issues.

  • Reported: CORBA 3.0 — Mon, 2 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix it as suggested in the archive with a few minor changes

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

determining TimeT or UtcT value

  • Key: CORBA3-74
  • Legacy Issue Number: 5623
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Time service states that determining if a TimeT or UtcT value is
    absolute or relative needs to be specified by the context. One presumes
    that the Messaging RequestStartTimePolicy, RequestStopTimePolicy,
    ReplyStartTimePolicy and ReplyEndTimePolicy contain absolute timestamps,
    and that RelativeRequestTimeoutPolicy and RelativeRoundtripTimeoutPolicy
    contain relative timestamps. The specification should make the context
    explicit.

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Is a router allowed to pick any value in the range for a priority?

  • Key: CORBA3-73
  • Legacy Issue Number: 5622
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Does it make sense (and is it legal) for a request to be sent with a
    RequestPriorityPolicy or ReplyPriorityValue in a service context where
    the min and max priorities are not the same? Is a router allowed to
    pick any value in the range for a priority?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Close no change

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

Who is responsible for generating the TIMEOUT exception

  • Key: CORBA3-72
  • Legacy Issue Number: 5620
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    What is the expected behavior of a server or router that receives a
    request with a RequestEndTimePolicy or ReplyEndTimePolicy value that has
    expired? Who is responsible for generating the TIMEOUT exception--the
    client or server or both?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This issue is a subset of issue 5626. Merge it with 5626 and close this issue

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

Object::validate_connection()

  • Key: CORBA3-71
  • Legacy Issue Number: 5619
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    How does Object::validate_connection() interact with RoutingPolicy
    values of ROUTE_FORWARD or ROUTE_STORE_AND_FORWARD? Should
    validate_connection() force the client to open a connection to a message
    router and fail if it cannot?

  • Reported: CORBA 3.0 — Sun, 1 Sep 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Sloppy text in CORBA 3.0, 4.3.8.1 get_policy

  • Key: CORBA3-70
  • Legacy Issue Number: 5614
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    In CORBA 3.0 section 4.3.8.1, the description of the Object::get_policy
    operation says:

    "Invoking non_existent on an object reference prior to get_policy
    ensures the accuracy of the returned effective Policy.Ifget_policy is
    invoked prior to the object reference being bound, the returned
    effective Policy is implementation dependent. In that situation, a
    compliant implementation may do any of the following: raise the standard
    system exception BAD_INV_ORDER, return some value for that PolicyType
    which may be subject to change once a binding is performed, or attempt a
    binding and then return the effective Policy."

    This is silly, since the only portable thing that applications can do is
    to call validate_connection or non_existent before calling get_policy,
    having two other non-portable behaviors just serves to make the standard
    larger and confuse users.

    We should pick one of the two reasonable behaviors--throw BAD_INV_ORDER
    or force a binding before returning a valid policy value--and make that
    the only valid behavior. Either one will be backwards compatible with
    portable code.

  • Reported: CORBA 3.0 — Thu, 29 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Makes sense. Fix it as suggested

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

Object::get_client_policy problem

  • Key: CORBA3-69
  • Legacy Issue Number: 5592
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4.3.7.2 says:

    "Returns the effective overriding Policy for the object reference. The
    effective override is obtained by first checking for an override of the
    given PolicyType at the Object scope, then at the Current scope, and
    finally at the ORB scope. If no override is present for the requested
    PolicyType, the system-dependent default value for that PolicyType is
    used. Portable applications are expected to set the desired defaults
    at the ORB scope since default Policy values are not specified."

    Some policies may not have a sensible default value, such as
    RequestStartTime and in fact, perhaps should not have one to avoid
    putting any value in the INVOCATION_POLICIES service context. In this
    case, it would be better if get_client_policy were allowed to return a
    nil Policy reference.

    Suggested revision:

    Change the sentence that reads:

    "If no override is present for the requested PolicyType, the
    system-dependent default value for that PolicyType is used."

    to:

    "If no override is present for the requested PolicyType, a
    system-dependent default value for that Policy Type may be returned. A
    nil Policy reference may also be returned to indicate that there is no
    default for the policy."

  • Reported: CORBA 3.0 — Sat, 24 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fix as suggested

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

Inconsistent definition of semantics of RebindPolicy?

  • Key: CORBA3-68
  • Legacy Issue Number: 5587
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4.12.3.32 states:

    > REBIND is raised when the current effective RebindPolicy, as described in
    > Section 22.2.1.2, interface RebindPolicy on page 22-5, has a value of
    > NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
    > in a LocateReply message with status OBJECT_FORWARD or a Reply message with
    > status LOCATION_FORWARD. This exception is also raised if the current effective
    > RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
    > The invocation can be retried once the effective RebindPolicy is changed to
    > TRANSPARENT or binding is re-established through an invocation of
    > CORBA::Object::validate_connection.

    but 22.2.1.2 says:

    > If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
    > ORB will raise a REBIND system exception if any rebind handling would cause a
    > client-visible change in policies. This could happen under the following
    > circumstances:
    >
    > o The client receives a LocateReply message with an OBJECT_FORWARD status and a
    > new IOR that has policy requirements incompatible with the effective policies
    > currently in use.
    >
    > o The client receives a Reply message with LOCATION_FORWARD status and a new
    > IOR that has policy requirements incompatible with the effective policies
    > currently in use.

    So the former says that a REBIND exception always occurs a rebind is
    necessary (and NO_REBIND is set), but the latter says that a REBIND
    exception only occurs when any client-visible policies would change.

    Which one is correct?

    Also, it is not clear from the specification whether an invocation on a
    new object reference that has never been bound must fail if RebindMode
    is not TRANSPARENT, forcing the use of validate_connection, or whether
    the first initial binding can proceed without the use of
    validate_connection.

  • Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

pragma prefix syntax

  • Key: CORBA3-63
  • Legacy Issue Number: 5327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    suppose the following [pseudo-]idl:

    #pragma prefix "2abc.def"

    module xyz {
    interface q

    {...}

    ;
    };

    It would generate a Java class 'q' within package 'def.2abc.xyz'.
    The package name '2abc' is not that popular with the java compiler
    since it starts with a digit.

    From what I could see in CORBA 2.6.1, identifiers have to start
    with a character (or at least not a digit). So, I guess that the
    prefix pragma is erroneous here, right ?

    The OpenORB IDL parser 1.2.0 did though generate Java code without any
    complaints, which confuses me ...

  • Reported: CORBA 2.6.1 — Sat, 25 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Avoiding Interceptors for colocated method requests

  • Key: CORBA3-62
  • Legacy Issue Number: 5296
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Could we please discuss the possibility of introducing a performance
    optimization for Interceptors.

    There may be considerable overhead involved in invoking Portable
    Interceptors. While some interceptors need to be invoked when caller
    and target are colocated (the locally optimized path), many do not.
    I think it would be useful to introduce a mechanism to allow this
    unnecessary overhead to be avoided for interceptors that do not need
    to be invoked on the colocated path, for example by adding a
    'run_local' parameter to the add_xxx_request_interceptor methods of
    the ORBInitInfo interface.

    I realise that this issue was touched upon during discussion of interop
    issue 4291 but, at the time, the focus was on getting the interceptor
    mechanism to work correctly in the colocated case; the performance
    aspect of the issue seems to have been lost.

  • Reported: CORBA 2.6.1 — Mon, 13 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Provide means for the optimization as shown below

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

Codeset negotiation and the CODESET_INCOMPATIBLE exception

  • Key: CORBA3-61
  • Legacy Issue Number: 5270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. There's no minor code assigned to the use of CODESET_INCOMPATIBLE
    for a failed codeset negotiation in 13.10.2.6.

    2. There's no indication of what a server should do if the client
    delivers a codeset via a CodeSetContext that the server does not support
    as a transmission codeset). This isn't likely to happen, but we ought
    to close the hole. I propose that we have the server raise
    CODESET_INCOMPATIBLE (with a different minor code from 1) in this case
    too.

    3. Would it be a good idea for us to include recommendations on how to
    change a persistent server's native codeset while remaining backwards
    compatible with existing IORs floating around the world with obsolete
    CodeSetComponent data? Or is it too obvious? (Just make sure the new
    server advertises (or at least continues to support) the old native
    codeset as a transmission codeset.)

  • Reported: CORBA 2.6.1 — Tue, 7 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Replace deprecated anonymous type declarations?

  • Key: CORBA3-60
  • Legacy Issue Number: 5232
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've deprecated defining types anonymously with bounded
    strings, fixed, sequences and arrays, should we take the next step and
    deliberately purge them from the Core IDL?

    Here are the offenders that I've identified and the edits that should
    occur:

    In module CORBA:

    1. the service_detail member of struct ServiceDetail

    Fix: Add 'typedef sequence<octet> ServiceDetailData' and replace
    member type

    2. the service_options & service_details members of struct
    ServiceInformation

    Fix: Add 'typedef sequence<ServiceOption> ServiceOptionSeq' and
    'typedef sequence<ServiceDetail> ServiceDetailSeq' and replace
    member type

    In module GIOP:

    3. the magic member in the various struct MessageHeader_1_X types

    Fix: Add 'typedef char Magic[4]' and replace member types

    4. the reserved member in the struct RequestHeader_1_1 and
    RequestHeader_1_2 types

    Fix: Add 'typedef octet RequestReserved[3]' and replace member
    types

    5. the object_key member in various Header structures

    Fix: replace member types with IOP::ObjectKey

    In module IIOP:

    6. the object_key member in various struct ProfileBody_1_X types

    Fix: replace member types with IOP::ObjectKey

    7. the components member in struct ProfileBody_1_1

    Fix: replace member type with IOP::ComponentSeq

    In module IOP:

    8. the profile_data member in struct TaggedProfile

    Fix: Add 'typedef sequence<octet> ProfileData' and replace member
    type

    9. the profiles member in struct IOR

    Fix: Add 'typedef sequence<TaggedProfile> TaggedProfileSeq' and
    replace
    member type

    10. the component_data member in struct TaggedComponent

    Fix: Add 'typedef sequence<octet> ComponentData' and replace member
    type

    11. the context_data in struct ServiceContext

    Fix: Add 'typedef sequence<octet> ContextData' and replace member
    type

    also to complete fixes for cases 5, 6, and 20:

    Fix: Add 'typedef sequence<octet> ObjectKey' and
    'typedef sequence<TaggedComponent> TaggedComponentList'

    In module MessageRouting:

    12. the body member in struct MessageBody

    Fix: Add 'typedef sequence<octet> BodyData' and replace member type

    13. the object_key member in struct RequestMessage

    Fix: replace member type with 'IOP::ObjectKey'

    14. the reserved member in struct RequestMessage

    Fix: replace member type with 'GIOP::RequestReserved'

    15. the typed_excep_holder_repids in struct ReplyDestination

    Fix: replace member type with 'CORBA::RepositoryIdSeq'

    In module Messaging:

    16. the pvalue member in struct PolicyValue

    Fix: Add 'typedef sequence<octet> PolicyData' and replace member
    type

    17. the marshaled_exception member in valuetype ExceptionHolder

    Fix: Add 'typedef sequence<octet> MarshalledException' and replace
    member
    type

    In module CONV_FRAME:

    18. the conversion_code_sets member in struct CodeSetComponent

    Fix: Add 'typedef sequence<CodeSetId> CodeSetIdSeq' and replace
    member type

    In module DCE_CIOP:

    19. the object_key member in struct InvokeRequestHeader and struct
    LocateRequestHeader

    Fix: replace member type with 'IOP::ObjectKey'

    In module DCE_CIOPSecurity.idl:

    20. the components member in struct DCESecurityMechanismInfo

    Fix: replace member type with 'IOP::TaggedComponentList'

  • Reported: CORBA 2.6 — Tue, 30 Apr 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

reference_to_servant

  • Key: CORBA3-59
  • Legacy Issue Number: 5105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For reference_to_servant(), the spec says:

    > This operation requires the RETAIN policy or the USE_DEFAULT_SERVANT
    policy.
    > If neither policy is present, the WrongPolicy exception is raised.
    >
    > If the POA has the RETAIN policy and the specified object is present in
    the Active
    > Object Map, this operation returns the servant associated with that object
    in the Active
    > Object Map. Otherwise, if the POA has the USE_DEFAULT_SERVANT policy and a
    > default servant has been registered with the POA, this operation returns
    the default
    > servant. Otherwise, the ObjectNotActive exception is raised.

    This says that, if I use USE_DEFAULT_SERVANT, reference_to_servant() always
    and unconditionally returns the default servant.

    This appears to be wrong. In particular, I can have USE_DEFAULT_SERVANT but
    still add other servants explicitly to the AOM. If I do that, I can have,
    for example,
    servant X with object ID 1 as an explicitly activated servant, in addition
    to the default
    servant. In this situation, if I call reference_to_servant() with a
    reference with object ID 1,
    it should return servant X instead of the default servant.

    The exact same reasoning applies to id_to_servant(), which also
    unconditionally returns
    the default servant with USE_DEFAULT_SERVANT().

    I think we need to fix this – it appears that the current words are simply
    wrong.

  • Reported: CORBA 2.6 — Tue, 2 Apr 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

BAD_INV_ORDER minor code 5 and 10 mean the same thing?

  • Key: CORBA3-67
  • Legacy Issue Number: 5448
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    From the descriptions in CORBA 2.6.1 sections 7.2 and 7.2.3, the
    BAD_INV_ORDER minor codes 5 and 10 appear to mean the same thing. We
    should officially deprecate one, or state that either is acceptable

  • Reported: CORBA 3.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Easiest fix is to state either is acceptable

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

Serious backward compatibility issue in the PI

  • Key: CORBA3-66
  • Legacy Issue Number: 5430
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    I have recently realized that there is a serious backward compatibility
    issue in the PI changes introduced by the Object Reference Template.
    The problem is in the IORInterceptor. The original PI specification
    defined only the establish_components method on IORInterceptor.
    ORT added 3 new methods to this interface: components_established,
    adapter_state_changed, and adapter_manager_state_changed.

    The compatibility problem arises with the Java mapping. Prior to
    the CORBA 3.0 IDL to Java mapping, local interfaces were simply
    mapped to interfaces. The mapping for the CORBA 3.0 IORInterceptor
    is then simply:

    public interface IORInterceptorOperations
    extends org.omg.PortableInterceptor.InterceptorOperations

    { void establish_components (org.omg.PortableInterceptor.IORInfo info); void components_established (org.omg.PortableInterceptor.IORInfo info); void adapter_manager_state_changed (int id, short state); void adapter_state_changed ( org.omg.PortableInterceptor.ObjectReferenceTemplate[] templates, short state); }

    public interface IORInterceptor extends IORInterceptorOperations,
    org.omg.PortableInterceptor.Interceptor, org.omg.CORBA.portable.IDLEntity
    {
    }

    Any client of PI that implements IORInterceptor from CORBA 2.6 defines only the
    establish_components method, so that client will fail on a CORBA 3.0 version of PI.

    I propose the following changes to the draft CORBA 3.0 spec to fix this problem:

    In Section 21.5.4, replace the definition of IORInterceptor with:

    local interface IORInterceptor : Interceptor

    { void establish_components( in IORInfo info ) ; }

    ;

    local interface IORInterceptor_3_0 : IORInterceptor

    { void components_established( in IORInfo info ) ; void adapter_manager_state_changed( in AdapterManagerId id, in AdapterState state ) ; void adapter_state_changed( in ObjectReferenceTemplateSeq templates, in AdapterState state ) ; }

    ;

    Replace the first sentence in 21.5.4.2 with:

    After all of the establish_components methods have been called, the
    components_established methods are called on all registered IORInterceptor_3_0
    instances.

    Replace the first sentence in 21.5.4.3 with:

    Any time the state of an adapter manager changes, the adapter_manager_state_changed
    method is invoked on all registered IORInterceptor_3_0 instances.

    Replace the first sentence in 21.5.4.4 with:

    Adapter state changes unrelated to adapter manager state changes are reported by
    invoking the adapter_state_changed method on all registered IORInterceptor_3_0
    instances.

  • Reported: CORBA 3.0 — Fri, 14 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve urgently as suggested

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

OpaqueValue/add_arg never mapped to languages

  • Key: CORBA3-65
  • Legacy Issue Number: 5333
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    As far as I can tell, 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.

    Also, the len parameter of add_arg is underspecified.

  • Reported: CORBA 3.0 — Mon, 3 Jun 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Minor codes in specified NO_IMPLEMENT exceptions incomplete/inconsistent

  • Key: CORBA3-64
  • Legacy Issue Number: 5329
  • Status: closed  
  • Source: Xanalys ( Martin Simmons)
  • Summary:

    The minor codes in the specified NO_IMPLEMENT exceptions are incomplete/inconsistent.

    In particular:

    1) In 3.7.6.1 "Semantics", minor code 3 is mentioned for DII support pseudo-operations, but 3.7.6.2 seems to specify minor code 4 for these (though it uses different wording).

    2) 3.7.6.2 "LocalObject" doesn't specify the minor code for "is_a" etc, though presumably it should be 3 as in 3.7.6.2.

    3) The explanation for minor code 3 is "Unable to use any profile in IOR." but that isn't particular clear for local objects, which probably don't have an IOR at all.

  • Reported: CORBA 2.6.1 — Tue, 28 May 2002 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Valuetypes supporting forward declared interfaces

  • Key: CORBA3-58
  • Legacy Issue Number: 5100
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Interfaces cannot inherit from forward declared interfaces and
    valuetypes cannot inherit from forward declared valuetypes, but there is
    no specific prohibition against a valuetype supporting a forward
    declared interface. There should be.

    Proposed resolution:

    Add the following sentence to section 3.8.4:

    "It is illegal for a value type to support a forward-declared interface
    whose definition has not yet been seen."

  • Reported: CORBA 2.6 — Fri, 29 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Do as suggested

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

Inconsitent exception handling with find_POA & unknown_adapter

  • Key: CORBA3-57
  • Legacy Issue Number: 4982
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I think we totally messed up the resolution to issue 3740. We added the
    following text (circa CORBA 2.5) to 11.3.3.2:

    "If unknown_adapter returns FALSE then find_POA raises
    AdapterNonExistent. If
    unknow_adapter raises any system exception then find_POA passes through
    the
    system exception it gets back from unknown_adapter."

    [ There is also a typo in this text: "unkown_adapter".]

    and this text to 11.3.8.3:

    "If find_POA receives a system exception in response to a call to
    unknown_adapter
    on a POA, find_POA raises OBJ_ADAPTER system exception with standard
    minor
    code 1."

    In the former, system exceptions raised by unknown_adapter are to be
    passed through unchanged by find_POA. In the latter, system exceptions
    raised by unknown_adapter are to be replaced with OBJ_ADAPTER(1).

    I think the former behavior is more correct, since it preserves the
    original exception and doesn't throw away useful debugging information.

  • Reported: CORBA 2.6 — Thu, 14 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The former (i.e. 11.3.3.2) is right. Change the latter to match the former

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

IOR processing performance

  • Key: CORBA3-56
  • Legacy Issue Number: 4945
  • Status: closed  
  • 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 request interceptors are used. IOR access and creation
    performance could be improved by making better use of Java facilities to
    provide access to an IOR's components without the overhead of CDR encoding,
    and by recognising that many of the constituent parts of an IOR are
    identical for all objects within an object adapter.

    I would like to propose that we introduce a Java API for IOR, along the
    following lines:-

    An abstract model of an IOR could be defined as follows:
    an IOR has a type ID string, and contains TaggedProfile instances
    an IIOPProfile is a TaggedProfile
    an IIOPProfile is composed of an IIOPProfileTemplate and an object ID
    an IIOPProfileTemplate has an ObjectKeyTemplate, and contains
    TaggedComponents
    a TaggedComponent has an ID, and can be written to an OuputStream.
    a TaggedComponentFactory reads a TaggedComponent from an InputStream.

    It should be possible to manipulate IOR TaggedProfiles and
    IIOPProfileTemplate TaggedComponents using all of the facilities in the
    Java collections framework.

    Templates can be used to create IIOPProfile and ObjectKey because the basic
    object adapter model for object creation is to establish all properties of
    an IOR (except for type and object ID) 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 runs only when an object adapter is created,
    which is the only time that user code can add tagged components to an IOR.

    TaggedComponent is a framework that may be extended to support application
    defined TaggedComponents. It would be necessary to be able to register
    TaggedComponentFactory instances with an ORB, in which case any IOR
    unmarshalled by that ORB instance would use the registered
    TaggedComponentFactory to unmarshal the TaggedComponent.

    In order to use the IOR API, a method would be needed, probably on ORB,
    to obtain an abstract IOR from an object reference.

  • Reported: CORBA 2.6 — Wed, 6 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    No Data Available

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

Wide string in reply before codeset was negotiated

  • Key: CORBA3-47
  • Legacy Issue Number: 4824
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Martin von Loewis posed the following rather intersting question in
    comp.object.corba:

    > Also notice that you must perform character set negotiation to
    > communicate wstring values, unlike string values. You don't have to do
    > that in the first message, though, but sometime before the first wide
    > string is transmitted (I wonder what happens if the client does not
    > negotiate a character set in its first message but the server wants to
    > sent back a wstring response, e.g. inside an any).

    The current codeset negotiation rules don't address this problem.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

conflict between CORBA specification and C++ mapping (_this method

  • Key: CORBA3-46
  • Legacy Issue Number: 4823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I think that there is conflict between CORBA specification and C++ mapping (_this method). May be it relates both to CORBA specification and C++ mapping.

    The Portable Object Adapter chapter of CORBA 2.6 specification 11.2.7 Implicit Activation (last paragraph - before Note)

    If the POA has the MULTIPLE_ID policy, the servant_to_reference and servant_to_id operations will always perform implicit activation, even if the servant is already associated with an Object Id. The behavior of language mapping operations in the MULTIPLE_ID case is specified by the language mapping. For example, in C++, the _this() servant member function will not implicitly activate a MULTIPLE_ID servant if the invocation of _this() is immediately within the dynamic context of a request invocation directed by the POA to that servant; instead, it returns the object reference used to issue the request.

    If I am right, author thinks that _this operation can be called on servant (related to POA with MULTIPLE_ID policy) multiple times (and it will not raise PortableServer::WrongPolicy exception).

    But C++ mapping provides the following semantics of _this:

    1.36.5 Skeleton Operations 3. ... This requires the POA with which the servant was activated to have been created with the UNIQUE_ID and RETAIN policies. If the POA was created with the MULTIPLE_ID or NON_RETAIN policies, the PortableServer::WrongPolicy exception is thrown.

    Moreover CORBA specification provides the following semantics for servant_to_reference method: 11.3.8.20 servant_to_reference 2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and either the POA has the MULTIPLE_ID policy or the specified servant is not active, the servant is activated using a POA-generated Object Id and the Interface Id associated with the servant, and a corresponding object reference is returned.

    If I am right, _this and servant_to_reference are very close by their semantics (sometimes _this can be implemented using servant_to_reference invocation on appropriate POA). That's why I think that C++ mapping conflicts with CORBA specification.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

Codeset negotiation requires clarification

  • Key: CORBA3-51
  • Legacy Issue Number: 4850
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    We need to analyze this problem in pieces, because our discussions have been all
    over
    the map.

    I have identified some legitimate needs for clarification though this discussion.
    To help
    we should target each discussion to be within one or more of these scenarios:

    Lets look at a few typical scenarios a, b, and c:

    a) server does not support international Strings

    Server cannot support Objects which use WSTRING in their IDL. It does not use
    codeset component in IORs, thus closing off Client’s use of international strings
    on the connection.

    We have a problem as to what to do with an ANY which may have WSRING in it for
    this case (we could mandate the orb to consider this a failed negotiation and go
    to the fallback of UTF-16).

    b) Server supports only Latin 1 for string, and Unicode UCS-2 for Wstring

    Server places a Codeset component in the IOR with TCS-W indicated.

    There may be a need for clarification as to what Native Code Sets should be used
    for Unicode.

    • If we view the GIOP negotiation mechanism as transport oriented, then the Server
      should put in UTF-16 as the Native Code set.in the IOR component
    • If we view it as a presentation mechanism, then the Server might put UCS-2 as
      Native code set, and UTF-16 as Conversion Code Set in the IOR component.

    What can the server legally put in the IOR component for TCS-C in this case. Is
    Null allowed? Should ISO 8859-1 be explicitly called out in the TCS-C portion of
    the codeset component?

    c) Server supports ShiftJISC for string and Unicode UCS-2 for Wstring

    There might be an issue on whether the server may also place UTF-8 in as an
    explicit Conversion code set in the TCS-C portion of the IOR component?

    If the client does not support ShiftJISC, it should assert UTF-8 in the Codeset
    Service context for the TCS-C.

  • Reported: CORBA 2.6 — Thu, 28 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

The whole negotiation thing should be removed, Unicode should be mandated

  • Key: CORBA3-50
  • Legacy Issue Number: 4846
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The whole negotiation thing should be removed from the spec and Unicode should be mandated"

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

discussion on the create_union_tc operation could use some clarifications

  • Key: CORBA3-53
  • Legacy Issue Number: 4852
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The discussion on the create_union_tc operation could use some clarifications to prevent implementation errors.

    Firstly, in the previous paragraph of the spec it states that member names must be unique, but this is not true for unions: only the member (label) values need to be unique, not the member names.

    Secondly, there is a check that each member (label) type matches the discriminator type, but this will not hold for the default label, because according to the typecode spec (section 4.11.1) the default label type of a union will be octet so it will never match the discriminator type.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    There is indeed a defect that should be fixed by replacing a single sentence as shown below

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

IDL inheritance issue

  • Key: CORBA3-52
  • Legacy Issue Number: 4851
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    The IDL specification is unclear about the names that can be used to
    denote a base interface. Section 3.7.2 says

    "Each <scoped_name> in an <interface_inheritance_spec> must denote a
    previously defined interface."

    but the word "denote" is not defined. In particular, is the following
    legal?

    interface I { };
    typedef I J;
    interface K : J { };

    There is real IDL in use in the world that assumes that inheriting
    from a typedef is permitted. I therefore suggest re-wording the part
    of section 3.7.2 to be

    "Each <scoped_name> in an <interface_inheritance_spec> must be the
    name of a previously defined interface or an alias to a previously
    defined interface."

    A similar clarification is required in section 3.8.1.3, regarding
    valuetype inheritance.

  • Reported: CORBA 2.6 — Wed, 20 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good point. Incorporate the clarification

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

interaction of #pragma and typeid, typeprefix

  • Key: CORBA3-49
  • Legacy Issue Number: 4835
  • Status: closed  
  • Source: Memorial University of Newfoundland ( Jeffrey Parsons)
  • Summary:

    The CCM final draft has a section on repository identity
    related declarations (3.15), and the rules for which trumps
    which and what may be reset a second time are clear. Likewise
    for the #pragma prefix, version and ID directives in section
    10.7.5. But I'm still confused about how these two things
    interact – I haven't been able to find anywhere where this is
    addressed.

  • Reported: CORBA 2.6 — Mon, 18 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

IPv6 in corbaloc URLs

  • Key: CORBA3-48
  • Legacy Issue Number: 4825
  • Status: closed  
  • Source: Progress Software ( Markus Heichel)
  • Summary:

    is there any recent specification for IPv6 addresses in corbaloc
    URLs? I could not find any hint.

    Since it is not possible to unambiguously determine the meaning
    of something like:

    corbaloc::10:5::5:6/Hello

    there should be an escape for the colons or a delimiter for
    the IP address.

  • Reported: CORBA 2.6 — Tue, 12 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

GIOP version in replies

  • Key: CORBA3-55
  • Legacy Issue Number: 4899
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    is it allowed to return a reply with a GIOP version number of 1.0 for a
    request with GIOP version number 1.1 or 1.2, as long as the reply can be
    correctly encoded with GIOP 1.0? IMO the spec is not clear about that, i.e.
    it does not explicity state that the version numbers of request and reply
    must match. This should be clarified.

  • Reported: CORBA 2.6 — Fri, 1 Mar 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify that the reply message must have the same GIOP version as the request message

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

definition of the TypeCode interface (4.11.1)

  • Key: CORBA3-54
  • Legacy Issue Number: 4870
  • Status: closed  
  • Source: ADLINK Technology Ltd ( Jason Courage)
  • Summary:

    In the definition of the TypeCode interface (4.11.1) the length operation is defined as:

    // for tk_string, tk_sequence, and tk_array unsigned long length () raises (BadKind);

    The comment for this operation should include tk_wstring.

  • Reported: CORBA 2.6 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed editorially in CORBA 3.0, close no change

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

Issue with chunking

  • Key: CORBA3-43
  • Legacy Issue Number: 4806
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    15.3.4 is silent on the treatment of encapsulations containing chunked valuetypes and in particular chunked valuetypes containing encapsulations containing chunked valuetypes. My understanding of encapsulations leads me to believe that the encapsulation should ignore the current nesting level and chunk length and start from scratch, i.e. chunks within an encapsulation are calculated relative to the start of the encapsulation rather than relative to the stream.

    The reason this needs clarification is because the spec goes to great lengths to make sure chunks are not nested so I think that it would be clearer if this case was specifically discussed. Additionally I don't know whether 15.3.4.6 should include encapsulations in the list of data types that cannot be split across a chunk. In general you would probably have to read the entire encapsulation before you can decode it, so allowing it to be split across chunks might be problematic.

  • Reported: CORBA 2.6 — Tue, 15 Jan 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

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

TypeCode indirections

  • Key: CORBA3-42
  • Legacy Issue Number: 4796
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    This issues was previously raised as issue 4294, and was deferred to the
    GIOP 1.3 wishlist. Now that GIOP 1.3 is about to become a reality, I am
    re-raising the issue because of its importance for efficient RMI-IIOP
    communications. This is an interop issue, but I am also copying the
    Java to IDL list because of its impact on RMI-IIOP performance.

    CDR should allow TypeCode indirections that refer to top-level TypeCodes.
    The current prohibition of this causes servere performance penalties for
    RMI-IIOP because the Java to IDL mapping requires that Java objects of
    declared type java.lang.Object are marshalled as CORBA anys. In the case
    of a Vector or HashTable with 100 elements, this means that 100 anys must
    be marshalled. If all of these are of actual type foo, the restriction
    on TypeCode indirections means that all 100 of these data values must repeat
    the TypeCode for foo, which could be very large. This causes very substantial
    overheads, since the space and time needed to marshal the TypeCode for foo
    can greatly exceed that needed to marshal the data for foo.

    I understand why a nested indirection cannot refer to any TypeCode outside
    the scope of its enclosing top-level TypeCode. However, this restriction
    does not need to apply to a top-level TypeCode. We have made this change
    experimentally without any adverse effects and we have discovered that
    using indirections for all repeated top-level TypeCodes can speed up some
    common scenarios by at least a factor of 5 on end-to-end measurements.
    There appears to be no downside to making this change.

    Proposed Resolution:

    In the section headed "Indirection: Recursive and Repeated TypeCodes" within
    section 15.3.5.1, replace the current first bullet:

    The indirection applies only to TypeCodes nested within some “top-level”
    TypeCode. Indirected TypeCodes are not “freestanding,” but only exist inside
    some other encoded TypeCode.

    by the following two bullets:

    For GIOP 1.2 and below, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode. Indirected TypeCodes are not “freestanding,”
    but only exist inside some other encoded TypeCode.

    For GIOP 1.3 and above, the indirection applies only to TypeCodes nested
    within some “top-level” TypeCode, or from one top-level TypeCode to another.
    Indirected TypeCodes nested within a top-level TypeCode can only reference
    TypeCodes that are part of the same top-level TypeCode, including the
    top-level TypeCode itself. Indirected top-level TypeCodes can reference
    other top-level TypeCodes but cannot reference TypeCodes nested within
    some other top-level TypeCode.

  • Reported: CORBA 2.6 — Fri, 21 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Chapters 13.10.1.9, and 13.10.1.12 -- issue

  • Key: CORBA3-41
  • Legacy Issue Number: 4725
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapters 13.10.1.9, and 13.10.1.12] apparently indicate that both TCS-C
    and TCS-W can be byte-oriented or non-byte-oriented.

    Assume the following configurations for two communicating ORBs.

    CNCS-C = windows-1252, SNCS-C = ISO-8859-1, and CCCS-C = SCCS-C =

    {UTF-16}

    .

    The execution of the OMG code set negotiation algorithm [3, Chapter
    13.10.2.6] in this case will result in the value of the TCS-C as UTF-16!

    An IDL string will then be marshalled as UTF-16 encoded data, which may
    have embedded single-octet NULLs. This point should be mentioned explicitly
    somewhere in [3, Chapter 15.3.1.6], especially when IDL string data types
    are not allowed to contain any embedded NULLs [3, Chapter 3.10.3.2]. [3,
    Chapter 15.3.1.6] states that "Both the string length and contents include
    a terminating null". If TCS-C is selected to be UTF-16, this 'null' should
    be a null of two-octet size. [3, Chapter 15.3.1.6] should be explicit in
    stating that the concrete representation of the 'terminating null' is
    dependent on the TCS-C.

    Similarly, for the following configuration
    CNCS-W = UCS-2, SNCS-W = UCS-4, and CCCS-W = SCCS-W =

    {UTF-8}

    TCS-W will be selected as UTF-8!

    Are these configurations valid? Regardless of the answer to this question,
    [3, Chapters 13.10.1.9, and 13.10.1.12] should clarify the issue of the
    orthogonality of TCS with respect to the byte-oriented and
    non-byte-oriented code sets with appropriate examples.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Alignment for empty sequence?

  • Key: CORBA3-38
  • Legacy Issue Number: 4650
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    struct X

    { long long_1; sequence<double> double_seq; long long_2; }

    ;

    The question is, how should things be padded if double_seq is empty?
    (Assume that we are starting at byte offset 0 for marshaling this structure.)

    Approach taken by ORB 1:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • long_2 is aligned on a four-byte boundary. Because double_seq is
      empty, this means that long_2 immediately follows the length of
      double_seq on the wire, so long_2 begins at offset 8 and the total
      number of bytes for the struct is 12.

    Approach taken by ORB 2:

    • long_1 is aligned on a four-byte boundary (offset 0).
    • The length of double_seq is aligned on a four-byte boundary,
      immediately following long_1 (offset 4).
    • Now four bytes of padding are inserted because the sequence element
      type is double, so the next data item is expected to start on
      an eight-byte boundary.
    • long_2 is aligned on that eight-byte boundary, so long_2 begins at
      offset 12 and the total number of bytes for the struct is 16.

    The spec isn't clear on what should happen:

    Sequences are encoded as an unsigned long value, followed by the
    elements of the sequence. The initial unsigned lon gcontains the
    number of elements in the sequence. The elements of the sequence
    are encoded as specified for their type.

    >From this, I cannot infer unambiguously which interpretation is correct.

    Both approaches seem reasonable. (Personally, I have a slight preference
    toward approach 2 because it's more consistent: after consuming the sequence,
    the next data item will always start on an 8-byte boundary, which is more
    consistent than approach 1, because the padding rules don't depend on the
    length of the sequence at run time.)

    I suspect that the best way to resolve this might be to take a majority vote
    in line with the behavior of current implementations. And, of course,
    the question now is what do we do with the GIOP version? We probably should
    increment it, but I don't see what that would achieve for already existing
    implementations, sigh...

  • Reported: CORBA 2.5 — Tue, 30 Oct 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, no change necessary

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

CORBA 2.5 and Portable Interceptors mismerged

  • Key: CORBA3-37
  • Legacy Issue Number: 4585
  • Status: closed  
  • Source: Vanderbilt University ( Mr. Ossama Othman)
  • Summary:

    The new Portable Interceptor chapter in the CORBA 2.5 specification
    has apparently been mismerged. Section 13.8 "Coder/Decoder
    Interfaces," the Codec related interfaces added to the "IOP" module,
    should supercede those in the deprecated "IOP_N" module that is listed
    in section 21.10 "Portable Interceptor IDL."

    Suggested changes include:

    • Remove the IOP_N module from Section 21.10 "Portable Interceptor
      IDL."
    • Change all instances of "IOP_N" to "IOP." In particular, methods
      listed in sections 21.3.13 (ClientRequestInfo IDL) and 21.10 refer
      to the "IOP_N" module. The following methods in section 21.10 must
      be updated:

    module PortableInterceptor {

    // ...
    local interface ClientRequestInfo

    { // ... IOP_N::TaggedComponent get_effective_component (...) IOP_N::TaggedComponentSeq get_effective_components (...) // ... }

    ;
    // ...

    local interface ORBInitInfo

    { readonly attribute IOP_N::CodecFactory codec_factory; }

    ;

    };

  • Reported: CORBA 2.5 — Mon, 1 Oct 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Fixed in CORBA 3.0 (ptc/02-01-14). Close no change

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

Detecting Recursion in Other Interceptors

  • Key: CORBA3-36
  • Legacy Issue Number: 4554
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Baldwin)
  • Summary:

    We have identified a requirement where the interceptors for one service
    need to be able to detect recursive invocations made by some other
    interceptor during the processing of a request. As far as we have been
    able to determine there is no way to achieve this using the
    Request-scope/Thread-scope Current mechanism described in the spec.

    It is probably easiest to explain this using a specific example. Start
    with some form of "transaction" service that registers client-side
    interceptors so it can detect all new request invocations and add service
    contexts that perform some form of "begin transaction" processing at the
    server. This transaction service must only perform this "begin
    transaction" once per application-level request, so it allocates a
    PICurrent slot and performs the processing described in section 21.4.4.2 to
    ensure that any recursive calls it makes itself will form part of the same
    transaction and not begin a new one.

    However a problem now occurs if we introduce some other service, say a
    "security" service that has its own interceptors registered. The order in
    which these two service's interceptors run can affect what happens, but
    since interceptor ordering is undefined assume that the security
    interceptor runs first.

    An application makes a request on its own thread A. The send_request
    interceptors start to run on thread B and the security interceptor runs
    first, at this point both the RSC and TSC slots for the transaction service
    are empty. The security interceptor makes a recursive request so the
    send_request interceptors run again on a new thread C. The security
    interceptor runs again and this time doesn't recurse so the transaction
    interceptor now runs on thread C. At this point it finds its RSC slot
    empty so does a "begin transaction" and sets its TSC for thread C. We've
    now finished interceptors on thread C and return to thread B and invoke
    send_request for the transaction service. Once again it finds its RSC slot
    empty and will try to "begin transaction" again. Now we have a problem as
    we have issued two "begin transactions" for the same application request.

    In fact it as actually the second of those two "begin transactions" that we
    really want to do, as that represents the true start of the application's
    transaction. The first one (caused by the recursive call in the other
    interceptor) is at best redundant and wasteful and at worst wrong and
    problematic.

    Does anyone have any comments on this problem?

  • Reported: CORBA 2.5 — Tue, 4 Sep 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

X/Open Codeset registry is obsolete needs to be replaced

  • Key: CORBA3-27
  • Legacy Issue Number: 4236
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    13.9.1 refers to the X/Open (nee OSF) Codeset registry. This registry
    is obsolete and no longer maintained. We should replace it with the
    IANA codeset registry instead and grandfather the old values for a
    transition period.

  • Reported: CORBA 2.4.2 — Mon, 26 Mar 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Clarify that each interception point executes in a distinct logical thread

  • Key: CORBA3-26
  • Legacy Issue Number: 4173
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    To me the key word is "EACH" - in other words values set via
    PICurrent.set_slot in send_request are visible to other interceptors in
    that point and go into the RSC of client interceptors serving any
    requests made from within the interceptor(s). However, the TSC for
    receive_reply (etc) would have a clean PICurrent since it runs in its
    own logical thread.

    We should clarify this.

  • Reported: CORBA 2.4.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Clarify as shown below

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

11.3.2.1 Processing States (end of second paragraph and third paragraph

  • Key: CORBA3-45
  • Legacy Issue Number: 4822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Hello, I think I've found inconsistency (or slips of the pen) in CORBA specification.

    ----------------------------------------- 11.3.2.1 Processing States (end of second paragraph and third paragraph):

    For example, if a POA is in active state, it does not change state due to an activate operation. Such operations complete successfully with no special notice.

    The only exception is the inactive state: a deactivate operation raises an exception just the same as every other attempted state change operation.

    Probably incosistent to:

    11.3.2.5 deactivate (first paragraph):

    This operation changes the state of the POA manager to inactive. This operation has no affect on the POA manager's state if it is already in the inactive state. (no more explanation about AdapterInactive exception)

    ------------------------------------------ So, each POAManager state changing operation do nothing if it will not really change the state of the POAManager (activate call on already active POAManager, for example)

    On the other hand:

    Each POAManager state changing operation raises the AdapterInactive exception if issued while the POA manager is in the inactive state.

    CORBA 2.5 specification was the first in which explanation about AdapterInactive exception during deactivate operation was removed (but third paragraph of 11.3.2.1 was not changed respectively).

    Probably, the third paragraph of 11.3.2.1 should be removed.

    Could you please provide some explanation about this problem (even if I am not right).

  • Reported: CORBA 2.6 — Mon, 4 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Potential problem using BiDir GIOP and codeset conversion service context

  • Key: CORBA3-44
  • Legacy Issue Number: 4820
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope.

    Take the following example:

    A opens connection to B

    A issues a request 1 (R1) containing the bidir service context, but not the codeset conversion service context.

    B processes R1, marking the connection as bidirectional.

    B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request.

    A symultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different.

    So we have a problem, which codesets should be used for the connection?

    The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occour for any connection specific state as set up by service contexts.

    Suggested resolution: add to the BiDir part of chapter 15 the following:

    "For any connection level state negotiated by exchange of service contexts, each direction of a bidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction"

  • Reported: CORBA 2.6 — Fri, 1 Feb 2002 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close no change

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

GIOP 1.2 encoding of wstring

  • Key: CORBA3-40
  • Legacy Issue Number: 4724
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 3.10.3.2] defines an IDL wstring data type to be a sequence of
    wchars. But the GIOP 1.2 encoding of wstring is defined differently [3,
    Chapter 15.3.2.7]. A GIOP 1.2 encoded wstring is not a sequence of GIOP 1.2
    encoded wchars.

    Each individually encoded wchar is associated with an octet containing the
    size of the encoded wchar in octets [3, Chapter 15.3.1.6], whereas an
    encoded wstring is associated with an unsigned long containing the length
    of the entire wstring in octets. Probably [3, Chapter 15.3.2.7] should
    clearly mention and explain this point with sample layout diagrams of
    appropriately encoded wchars and wstrings.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

ORBs using BOMs for UTF-16 (closely related to issue 4008)

  • Key: CORBA3-39
  • Legacy Issue Number: 4723
  • Status: closed  
  • Source: International Business Machines ( Richard Sitze)
  • Summary:

    [3, Chapter 15.3.1.6] mentions the use of BOM to indicate (and override the
    OMG byte order indicator flag [3, Chapter 15.2.1]) the endian-ness of the
    UTF-16 encoded wchar or wstring data.

    This is incorrect and goes against the Unicode recommendations [1]?refer to
    the Unicode conformance clause C3 [4, Chapter 3.1], and the discussion
    related to the use of BOM [4, Chapter 2.7].

    [4, Chapter 3.1] unambiguously implies that a BOM is not necessary if a
    higher-level protocol indicates the endian-ness. [4, Chapter 2.7]
    categorically states: "if other signaling methods (the OMG byte order flag
    in this context) are used, signatures (BOM) should not be employed".

    The UTF-16 endian rules of [3, Chapter 15.3.1.6] are clearly influenced by
    [2]. In the MIME world, an initial U+FEFF or U+FFFE is interpreted as BOMs.
    The BOM (or its absence) indicates the endian-ness of UTF-16 encoded data
    in the internet MIME world. But for CORBA messages or CDR encapsulations,
    the OMG byte order flag is already explicitly marking the UTF-16 encoded
    data as UTF-16BE or as UTF-16LE. U+FEFF or U+FFFE should not be used as
    BOMs for UTF-16 encoded data in the CORBA domain.

    Therefore, it is proposed that any U+FEFF or U+FFFE, regardless of their
    positions in the marshalled data, must be interpreted as ZERO WIDTH
    NO-BREAK SPACE characters, and not as BOMs. All the references to BOM in
    [3, Chapter 15.3.1.6] must be removed altogether.

    Adoption of the above Unicode conformant rule will
    – result in more efficient encoding of wchar/wstring data?no need to place
    U+FFFE for little-endian UTF-16/UTF-32 wchars/wstrings,
    – eliminate the ugly situation, where the BOM of an UTF-16/UTF-32 encoded
    wchar/wstring data contained in a message or CDR encapsulation indicate a
    different byte order than that specified by the OMG byte order flag for the
    same message or CDR encapsulation.

  • Reported: CORBA 2.6 — Tue, 4 Dec 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This proposal results in a complete reversal of an earlier adopted resolution, and hence would be in

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

Problem with CSIv2 and GIOP LocateRequest

  • Key: CORBA3-29
  • Legacy Issue Number: 4290
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CSIv2 uses GIOP ServiceContexts to associate a security context with a
    given GIOP message, but the GIOP LocateRequest & LocateReply messages to
    not have a ServiceContext field to carry the CSIv2 security context
    information. Thus, it is impossible to use LocateReuest & LocateReply
    when using CSIv2.

  • Reported: CORBA 2.4.2 — Fri, 20 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

21.8.1 register_initial_reference

  • Key: CORBA3-28
  • Legacy Issue Number: 4284
  • Status: closed  
  • Source: SeeBeyond Technology Corp. ( Tom Urquhart)
  • Summary:

    21.8.1 register_initial_reference

    An operation is available in the ORB interface:
    void register_initial_reference (in ObjectId id, in Object obj) raises
    (InvalidName);
    If this operation is called with an id, Y , and an object, YY, then a
    subsequent call to ORB::resolve_initial_references ( Y ) will return object
    YY.
    InvalidName is raised if:
    " this operation is called with an empty string id;
    or
    " this operation is called with an id that is already registered, including
    the default names defined by OMG.
    What we think this means is that it would be impossible to register (and
    resolve) ORB vendor external implementations of, for example, CORBA
    Services, such as Naming, Trading, Notification, etc. as they are some of
    the "default names".

    Could you please amend the second "or" clause to something like:
    or
    " this operation is called with an id that is already registered, including
    the default LOCALLY CONSTRAINED names defined by OMG, where 'LOCALLY
    CONSTRAINED' would not then apply to any predefined CORBA Service names
    such as NameService, NotificationService, etc.
    Many thanks and apologies if you've already addressed this.

  • Reported: CORBA 2.4.2 — Wed, 25 Apr 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

rep_id() operation on Object?

  • Key: CORBA3-33
  • Legacy Issue Number: 4337
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I'm seeing more and more questions along the lines of:

    "How can I get the repository ID of an object, given its reference?"

    The standard answer is to call get_interface() and to then grope around
    in the IFR. However, that's cumbersome, and the IFR may well not be
    populated or running.

    So, why is it that there is no way to get the repository ID from the target
    object directly? I would think that adding something like the following
    to CORBA::Object would work nicely:

    interface Object

    { // ... string rep_id(); }

    ;

    As far as the implementation is concerned, it would be trivial. We'd have
    another "_rep_id" operation name in IIOP (similar to "_get_interface" and
    "_non_existent"). On the server side, the implementation would simply
    return the repository ID of the servant (the result of _primary_interface()
    in the C++ mapping).

    Yes, I know, we'd have to rev IIOP (which we are due to do some time
    soon anyway, so we might as well add this at the same time).

    Apart from the IIOP issue, I'd be interested in hearing what other people
    think of this idea. Any glitches with it?

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Repository ID in nil references

  • Key: CORBA3-32
  • Legacy Issue Number: 4334
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 13-17, the spec says:

    A Null TypeID is the only mechanism that can be used to represent
    the type CORBA::Object.

    This is in conflict with the information provided on page 15-28:

    When a reference to a base Object is encoded, there are two allowed
    encodings for the Repository ID: either "IDL:omg.org/CORBA/Object:1.0"
    or "" may be used.

    I would suggest to strike the sentence on page 13-17 because that is a
    historical hangover.

    Also, the entire section talks about "type IDs", when what it really means
    are "repository IDs". I would suggest to hunt down all uses of "type ID"
    and to replace them with "repository ID", because that's the correct
    terminology.

  • Reported: CORBA 2.4.2 — Tue, 5 Jun 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above Close no change

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

Note on page 15-43, OBJECT_FORWARD_PERM

  • Key: CORBA3-31
  • Legacy Issue Number: 4324
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 15-43, we have a note:

    Note--Usage of OBJECT_FORWARD_PERM is now deprecated, due to problems it
    causes with the semantics of the Object::hash operation.
    OBJECT_FORWARD_PERM features could be removed from some future GIOP
    versions if solutions to these problems are not provided.

    This seems to be in conflict with the decision to retain permanent forwarding
    for FT ORBs. The note needs to be either deleted or updated to reflect
    the real state of affairs.

  • Reported: CORBA 2.4.2 — Tue, 29 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Good catch. The note is simply wrong and should be removed

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

Interpretation of defined ServiceConfigurationSyntax constants is incomplet

  • Key: CORBA3-30
  • Legacy Issue Number: 4321
  • Status: closed  
  • Source: Adiron, LLC ( Polar Humenn)
  • Summary:

    If the ServiceConfigurationSyntax identifier is a 0, the specification
    says that the contents of the associated ServiceConfiguration is an ANS.1
    Encoded version of a GeneralNames construct.

    It is not specified what a conforming client implementation does when it
    encounters this type of privilege authority. What is the conforming
    behavior of a client?

    If there is no conforming behavior, I believe the definition of
    CSIIOP:SCS_GeneralNames should be removed from the specification, as there
    is nothing "interoperable" about it, and this specification is an
    interoperability specification.

    As a remedy to this situation we should probably use a resolution of the
    VMCID solution sought after in issue 4268, and let that Vendor specify it
    in their specification (i.e. does EJB have a use for this?), when there is
    a specification for it.

    The ServiceConfigurationSyntax identifier of 1 specifies that the
    ServiceConfiguration is a GSSExported name.

    This one has a bit more use than 0, as the contents of a GSS exported name
    construct can imply a lot, such as the protocol, the format of the token,
    and a specification of where to get the authorization token.

    So, the specification should state the specific OIDs that are understood
    by a conforming CSS, and where to find the specification of the conforming
    behavior of each OID.

    Obviously there are no OID specified (yet), but there might be in the
    future. It would be nice to know where to look, or otherwise remove the
    definition of SCS_GSSExportedName from the specification.

  • Reported: CORBA 2.4.2 — Thu, 24 May 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

CORBA components requires new GIOP version?

  • Key: CORBA3-35
  • Legacy Issue Number: 4536
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    Please forgive me if this is old news. I was trying to find a recent
    CORBA Components spec to see what changes it has had on the core spec.

    It looks like several new TypeCode kinds have been added (two from
    CCM?), but doesn't that require a new GIOP version? Even if the specs
    did declare the wire formats in new versions of Chapter 15, how could
    older GIOP 1.2 ORBs handle them?

    Specs:

    CCM FTF drafts of modified CORBA Core chapters
    Adds tk_component and tk_home in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?ptc/99-10-03

    CORBA 2.4.2 complete specification
    Adds tk_local_interface in 10.7.1. No update to 15.
    http://www.omg.org/cgi-bin/doc?formal/01-02-01

  • Reported: CORBA 2.4.2 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change, see above

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

TypeCodes for custom marshaled valuetypes

  • Key: CORBA3-34
  • Legacy Issue Number: 4506
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    It is underspecified what value member information for custom
    marshaled valuetypes an ORB must provide.

    Users of custom marshaled valuetypes must provide their own marshaling
    code, and the ORB has no way of knowing what it does before executing
    it.

    This comes into play for custom marshaled valuetypes inside of Anys,
    as well as the ValueMemberSeq in the FullValueDescription of a custom
    marshaled valuetype.

    In both cases, one can query whether or not the valuetype is custom
    marshaled. With Anys, the TypeCode has a ValueModifier type_modifier
    which is set to VM_CUSTOM. The FullValueDescription includes a
    boolean is_custom.

    I can see two possible solutions:

    1. TypeCodes for custom marshaled valuetypes will encode no value
    member information, so the member_count will be 0. The
    FullValueDescription will have a zero length sequence for the
    ValueMemberSeq members.

    or

    2. Value member information for the TypeCode or FullValueDescription
    for a custom marshaled valuetype is the state defined in the
    valuetype's IDL in the same way as if it were not custom marshaled.

    I propose #1 as the solution. This member information is only useful
    for finding out what is encoded, and solution #2 doesn't provide
    that. Plus, it can be very expensive to create and transmit if many
    repository IDs are involved.

  • Reported: CORBA 2.4.2 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Stateful boolean causes all CSI mechanisms to operate the same way.

  • Key: CORBA3-25
  • Legacy Issue Number: 4167
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    The stateful boolean of the CSIIOP::CompoundSecMech forces all CSI
    mechanisms to behave the same way with respect to state retention. This is
    problematic and makes mechanisms parametric on the POA they are
    supporting. The retention of state is actually a function of an
    established transport, not a POA.

    Discussion:

    In the architecture (OMA) POA's are the 'owners' of object references.
    Therefore, the state retention boolean must be set there, as there is only
    one CompundSecMecList per object reference.

    You may have cases where multiple CSI mechanisms must support one POA.

    These mechanisms may span POA's as they may be defaults for many POA's. If
    state retention is parameterized on the particular mechanism, then
    negotiating the state retention for each mechanism becomes easier to
    handle, as the state retention algorithm is mechanism specific. Therefore,
    that mechanism may operate independently of knowing the POA.

    This makes the TSS mechanisms to be able to work independently of the POA
    policy.

    Also, for another reason, CSI state retention is based on the established
    transport, which has nothing to do with a POA, therefore it is part of the
    CSI mechanism over which the transport it is working.

    I think the purpose for the "stateful" boolean was ill conceived. It was
    thought of by some as a deficiency in your implementation and you needed
    to provide a single boolean so one could RED FLAG a security service
    "inferior" in some sense.

    The fact is that state retention can be inefficient in some cases. State
    retention is actually parameter that is a function of the mechanism over a
    particular transport mechanism. One may want to use mechanisms that retain
    their state where one makes lots of invocations over a single transport
    (long live connections). (State retention is a function of transport).
    Short lived connections need not incur the overhead.

    Proposed Solution:

    Move the stateful field, as follows:

    module CSIIOP {
    // type used in the body of a TAG_CSI_SEC_MECH_LIST component to describe a
    // compound mechanism

    struct CompoundSecMech

    { AssociationOptions target_requires; IOP::TaggedComponent transport_mech; AS_ContextSec as_context_mech; SAS_ContextSec sas_context_mech; boolean stateful; }

    ;

    // type corresponding to the body of a TAG_CSI_SEC_MECH_LIST component

    struct CompoundSecMechList

    { sequence <CompoundSecMech> mechanism_list; }

    ;

    };

  • Reported: CORBA 2.4.1 — Mon, 22 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    CLOSE NO CHANGE

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

Bug in C++ NVList mapping

  • Key: CORBA21-80
  • Legacy Issue Number: 501
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: NVList has an item () operation, which returns a NamedValue reference. The same special memory management rules should apply to item().

  • Reported: CORBA 2.0 — Thu, 20 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

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

OMG C++ Mapping: Implicit Conversion Operators

  • Key: CORBA21-79
  • Legacy Issue Number: 484
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose that public interface of _var types, the similar "smart pointer" types used in struct fields, and "smart pointer" types returned from sequence index operators be extended. (see file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Persistent Any values

  • Key: CORBA21-78
  • Legacy Issue Number: 480
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s currently not possible for a C++ client or server to receive a parameter value of type Any, store that value in filesystem or a database and later reconstruct Any value from persistent represe

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by portability submission

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

DII and DSI are useless with current Any

  • Key: CORBA21-77
  • Legacy Issue Number: 479
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Cannot use DII to invoke an operation that expects or returns a complex user-defined type. Any needs to provide member functions for composing Any"s containing arbitrary user-defined values

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

iterating over Any primitives

  • Key: CORBA21-76
  • Legacy Issue Number: 254
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There hsould be a way to access an unknown type inside an Any by "iterating" over the Any to examine the type in terms of the primitive types that make it up.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

decompose Any into constituent primitives

  • Key: CORBA21-75
  • Legacy Issue Number: 251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is an extremely simple extension to the any type to allow decomposition of values to their constituent parts: <EXAMPLE issue251>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Rethrowing exceptions

  • Key: CORBA21-69
  • Legacy Issue Number: 144
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If all I want to do is rethrow an exception in my C++ client code, there is no convenient and compliant way. It would be useful to add extra members to allow this.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Return value of operator[] for array var

  • Key: CORBA21-72
  • Legacy Issue Number: 220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA2.o Why are we returning a Long * from operator[] rather than an LongArray_slice&?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Taking T out of T_var

  • Key: CORBA21-71
  • Legacy Issue Number: 205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0 p31, Section 3.10.1 para 14: If I have T_var referring to T. How can I take ownership?How to stop it from being deallocated when T_var goes out of scope?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Freeing inaccessible storage for T_var as out parameter

  • Key: CORBA21-70
  • Legacy Issue Number: 187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Standard requires that a conforming implementation must free the inaccessable storage associated with a parameter passed as a managed type(T_var). How to achieve it for out parameters??

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

RTTI vs. _narrow for exceptions

  • Key: CORBA21-74
  • Legacy Issue Number: 244
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since RTTI is not ubiquitous, the _narrow operations for Exceptions should be defined, even when RTTI available. They are trivial to implement using RTTI.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

Implementation of parameter passing for T_var types

  • Key: CORBA21-73
  • Legacy Issue Number: 239
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation of parameter passing using T_var types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    Fixed by Portability submission

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

IDL grammar

  • Key: CORBA21-68
  • Legacy Issue Number: 458
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an inconsistency between the IDL grammar as defined in chapter 3 of CORBA2.0 spec and an IDL example from same chapter(Example p. 3-16..rule 71 and rule 36 specify different

  • Reported: CORBA 1.2 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

8.1 Role of the Basic Object Adapter Para 1 - comment

  • Key: CORBA21-67
  • Legacy Issue Number: 455
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Last sentence: Seems like an odd thing to say. All X/Open specs only guarantee that they are correct if system is configured correctly. Not a big deal

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-66
  • Legacy Issue Number: 454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Unacceptable to say that "calling the ORB_init function multiple times for the same ORB may be required where an ORB is implemented as a shared library."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    defer to portability

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

7.4 ORB Initialization Last Paragraph - objection

  • Key: CORBA21-65
  • Legacy Issue Number: 453
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: X/Open would like to see either the provision for a system default ORB or an interface that application could use to get list of available ORBs from which to choose.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    No change to the specification. The existing spec supports a default ORB

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

7.2.5 Probing for Object Non-Existence Paragraph 2 - comment

  • Key: CORBA21-64
  • Legacy Issue Number: 452
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para describes implementation strategies that ORB implementors might use to ensure ORBS remain synchronized about presence of objects.Info really appropriate for this spec?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change required, close issue

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

7.2.4 Equivalence Checking Operation Paragraph 3 - comment

  • Key: CORBA21-63
  • Legacy Issue Number: 451
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Concept of "type safe narrow" isn"t really described. What"s it"s importance, announcement mechanism, and whether it can be portably relied on by programmers. Where"s more info in spec??

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.2.1 Determining the Object Implementation and Interface

  • Key: CORBA21-62
  • Legacy Issue Number: 450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 1-comment: These interfaces are very important parts of ORB interface. Their semantics are very unclear. What exceptions are they permitted to raise? Expand on this definition.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

7.1 Converting Object References to Strings Para 3 - comment

  • Key: CORBA21-61
  • Legacy Issue Number: 449
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: it"s not clear from this whether the string generated by object_to_string is portable accross ORBs or among clients. Please add text clarifying portability of generated string.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.5.6 Repository Paragraph 4 - editorial

  • Key: CORBA21-60
  • Legacy Issue Number: 436
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mention of the kind attribute should be bold-face

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.5.4 Container Last Paragraph - editorial

  • Key: CORBA21-59
  • Legacy Issue Number: 433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The trailing period is missing.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    changed, close issue

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

6.4.3 Interface Objects Paragraph 2 - editorial

  • Key: CORBA21-58
  • Legacy Issue Number: 419
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "...not by modify..." to "...not by modifying..."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.4.3 Interface Objects Paragrapg 1 - editorial

  • Key: CORBA21-57
  • Legacy Issue Number: 418
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Numbered bullet list following this para is formatted poorly. Text items should be alligned and offset from the numbers in a consistent way

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

6.3.1 Managing Interface Repositories

  • Key: CORBA21-56
  • Legacy Issue Number: 417
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1 - editorial: Change the reference to "get_interface" to the appropriate type-face

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

5.3.2 Registering Dynamic Implementation Routines Para 1- comment

  • Key: CORBA21-55
  • Legacy Issue Number: 411
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph starts off by explaining that previous versions of CORBA weren"t complete. Not necessary to belabor this point. It"s not clear whether or not this lack has been repaired.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    This is fixed by the new DSI text from the Portability FP

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

5.2 Explicit Request State: ServerRequest Pseudo Object

  • Key: CORBA21-54
  • Legacy Issue Number: 410
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 4: editorial Change "..OMG IDL for operation.." to "..OMG IDL for the operation...:.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.6.5 delete_values Paragraph 1 - editorial

  • Key: CORBA21-53
  • Legacy Issue Number: 407
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "value(s) values" to "value(s)

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.3.3 get_response

  • Key: CORBA21-52
  • Legacy Issue Number: 401
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 0 - editorial: Add a line containing ");" to the PIDL for get_response, to match the PIDL given in section 4.2.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.2.3 invoke

  • Key: CORBA21-51
  • Legacy Issue Number: 398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1 - editorial : The leading "c" in create_request is not boldface

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.1.2 Memory usage, Para 1, editorial

  • Key: CORBA21-50
  • Legacy Issue Number: 394
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is an extra space between the table reference "Table 21" and the period

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

4.1 Overview, Paragraph 3, editorial

  • Key: CORBA21-49
  • Legacy Issue Number: 392
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Dynamic Invocation Interface is a proper name, and should be capitalized and italicized

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.15.2 Object Non-Existence, Para 1, editorial

  • Key: CORBA21-48
  • Legacy Issue Number: 391
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "This standard system exception" to "The OBJECT_NOT_EXIST exception", to make explicit which exception is being discussed

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.10.3 Raises Expressions

  • Key: CORBA21-47
  • Legacy Issue Number: 389
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para last, comment: We understand why standard exceptions may not be listed on a raises expression, but it would make IDL definition of interface more complete if permitted.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

3.9 Exception Declaration

  • Key: CORBA21-46
  • Legacy Issue Number: 388
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para 2, editorial: Change "...(as specified by the <member> in its declaration." to "...(as specified by the <member> in its declaration)."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

2.5 Structure of an Object Adapter

  • Key: CORBA21-45
  • Legacy Issue Number: 387
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 2, editorial: Change " registration of implementations" to "Registration of implementations"

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

2.1 Structure of an Object Request Broker

  • Key: CORBA21-44
  • Legacy Issue Number: 386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 1, editorial: Change "....up the "request." to "....up the request."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

1.2.2 Requests Paragraph last - editorial

  • Key: CORBA21-43
  • Legacy Issue Number: 385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Change "Descriptions of the values and exceptions...." to "For descriptions of the values and exceptions..."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

CORBA2.0, 1.2.2 Paragraph 2 - comment

  • Key: CORBA21-42
  • Legacy Issue Number: 384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para points to C Language Binding chapter and the DII for info on dynamic invocation of objects. It implies that DII is only available in C. Text should pobably be more clear

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Scope of standard exceptions

  • Key: CORBA21-41
  • Legacy Issue Number: 132
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 3-35 doesn"t really say that the list of standard exceptions belong to the CORBA module, although 3.12 seems to clarify.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Unions with enum as discriminator type

  • Key: CORBA21-40
  • Legacy Issue Number: 130
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How is it possible in IDL to specify a union with an enum discriminator type?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change necessary, close issue

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

_is_a with CORBA::Object as input parameter

  • Key: CORBA21-39
  • Legacy Issue Number: 127
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should _is_a() return when invoking it with an input parameter designating CORBA::Object?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed with revised text

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

Unqualified names in scopes

  • Key: CORBA21-38
  • Legacy Issue Number: 117
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA says "Once an unqualified name is used in a scope, it cannot be redefined", but my IDL compiler allows it. Is it legal?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    no change to spec., close issue

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

Usage of standard exceptions

  • Key: CORBA21-37
  • Legacy Issue Number: 97
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there a difference between standard/system exception? Can an implementation raise both? Is raising a standard exception the recommended way to handle errors while setting an attribute?

  • Reported: CORBA 1.2 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Ambiguity in DII and DSI

  • Key: CORBA21-36
  • Legacy Issue Number: 90
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For the DII, what value if any can be placed into the Any in the NamedValue corresponding to an OUT parameter? Must it be NULL, or is it legal to include a storage pointer? Also for DSI.

  • Reported: CORBA 1.2 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Request reuse

  • Key: CORBA21-35
  • Legacy Issue Number: 88
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Can a Request pseudo object be invoked multiple times?

  • Reported: CORBA 1.2 — Tue, 20 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Whether unions carry exact discriminant information

  • Key: CORBA21-34
  • Legacy Issue Number: 66
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported.

  • Reported: CORBA 1.2 — Mon, 5 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    resolved, close issue

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

Recusive Type Definitions

  • Key: CORBA21-33
  • Legacy Issue Number: 1
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does "semantically constrained" mean in section 3.8.2 under the discussion of recursive type specifications.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.0
  • Disposition Summary:

    closed issue, resolved

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

Detail lacking in when request interceptors are called

  • Key: CORBA3-11
  • Legacy Issue Number: 3599
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I set out reading ptc/2000-04-05 to answer a question: how could a
    client interceptor for the OTS implement the proper behavior for the DII
    get_response or get_next_response operations that require the
    WrongTransaction to be raised if the current thread is not properly
    associated with the same transaction as the request.

    I wasn't able to answer this question authoritatively, because there is
    nothing in the Portable Interceptors Chapter that indicates the proper
    time sequencing of when the client side request interceptor operations
    are invoked in relation to the use of the DII (or the AMI_ messaging
    interfaces either.)

    By inference, it appears to me that the only way to allow an OTS client
    request interceptor to exhibit the proper semantics is for the ORB to
    not make calls to receive_

    {reply,exception,other}

    when the response is
    received from the protocol stack, but instead to make them when
    get_response or get_next_response is called by the application.

    This paragraph in 21.3.7.2:

    "Asynchronous requests are simply two separate requests. The first
    request receives no reply. The second receives a normal reply. So the
    normal (no exceptions) flow is: first request - send_request followed by
    receive_other; second request - send_request followed by receive_reply."

    is also not particularly useful, since it doesn't give any indication
    how the interceptor can distinguish the "first request" from the "second
    request".

    So, to sum up, the PI chapter needs explicit information showing the
    time sequencing of when the request interceptor operations are invoked
    in relationship to a static call, a DII call, and AMI_ calls.

  • Reported: CPP 1.1 — Tue, 9 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

How correlate requests and replies when using pollable sets?

  • Key: CORBA3-10
  • Legacy Issue Number: 3541
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    When using the pollable sets, pollers are registered with
    PollableSet::add_pollable() and retrieved using
    PollableSet::get_ready_pollable(). As pollers are valuetypes they are passed by
    copy, thus portable applications must assume that get_ready_pollable() returns
    a different poller instance than the one passed to add_pollable(). Thus, with
    non-TII, currently there is no portable way to find out how requests
    (represented by the pollers returned from sendp) and replies (represented by
    the pollers returned from get_ready_pollable ) correlate.

    Consider the following IDL:

    module Stock
    {
    interface Quoter

    { long get_quote(in string stock_name); }

    };

    and a client that does a 1000 invocations in the style

    poller = quoter->sendp_get_quote(portfolio[i].stock_name);
    poll_set->add_pollable(poller);

    Now, the client could retrieve the 1000 replies in the order:

    while(poll_set->number_left() > 0)

    { pollable = poll_set->get_ready_pollable(timeout); ... }

    ;

    But how can the client find out which returned quote belongs to which
    stock_name?

    Possible resolutions:
    ---------------------
    (a) Reconsider the introduction of a correlation id on pollers which can be
    used to compare if two pollers are referring to the same request/reply.

    (b) Based on the fact that pollable set is locality-constrained and that
    valuetypes support sharing semantics (see CORBA 2.3, 5.2.4.2 Sharing
    Semantics), it could be required that PollableSet::get_ready_pollable() returns
    a pointer to the same valuetype instance as the one passed as argument of
    PollableSet::add_pollable().

    (c) Close without action, i.e. has to be solved at the application level, e.g.
    in our example the application would have to solve this by changing get_quote to

    long get_quote(in string stock_name, out string stock_name);

    Discussion:
    -----------
    (c) contradicts with the CORBA Messaging Philosophy that AMI is a mere
    client-side issue and that in principle any existing target can be called
    asynchronously.

    (b) means that we would have two different polling-related correlation
    mechanisms:

    • one for correlating requests and replies in different processes based on the
      PersistentRequest objref
    • one for correlating requests and replies in the same process based on poller
      pointers

    (a) means that a generic correlation mechanism is defined that covers both:
    intra- and inter-process correlation. This was variant (a) of issue 2803 in the
    latest vote. It failed with 5 NO : 4 YES : 3 ABSTAIN.

    I could work out two straw men for (a) and (b) for the next vote, or much
    better, we could try to discuss this before the next vote and just work out a
    straw man for the variant that has better acceptance.

  • Reported: CPP 1.1 — Mon, 10 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

no way to register value factory from ORB initializer

  • Key: CORBA3-18
  • Legacy Issue Number: 3793
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    There is currently no way to register a value factory from an ORB
    initializer.

  • Reported: CPP 1.1 — Mon, 28 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above.

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

ORB accessor on POA?

  • Key: CORBA3-17
  • Legacy Issue Number: 3772
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    looking at the POA IDL, I get the impression that it was written at a time
    where the use of multiple ORBs in a process wasn't anticipated. With
    the advent of messaging, OTS, QoS policies, etc, it is more and more common
    for one application to use several ORBs simultaneously.

    When writing code, it becomes an endless pain dealing with multiple ORBs.
    That's because I have to endlessly pass the ORB around in my program, just
    so I can do things like call object_to_string() or string_to_object(), etc.

    I think it would be really useful to have an ORB() accessor on the POA
    interface:

    interface POA

    { CORBA::ORB ORB(); // ... }

    ;

    The accessor would return the ORB for this POA. Doing this would eliminate
    most of the cases in my code where I have to pass the ORB around. For
    example, in a servant, I can call _default_POA(), and then call ORB() to
    get at the ORB.

    Adding the operation would cause any compatibility problems, I believe.

    Opinions?

  • Reported: CPP 1.1 — Tue, 15 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

RoutingPolicy issue

  • Key: CORBA3-16
  • Legacy Issue Number: 3770
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    This problem comes from the fact that RoutingPolicy is actually a range: min and max. Basically, Messaging defines this range of Routing QoS:

    ROUTE_NONE(0) ---> ROUTE_FORWARD(1) ---> ROUTE_STORE_AND_FORWARD(2)

    You can set your min and max to any of the values, with the caveat that min must be <= max. The issue that concerns us is when the min is ROUTE_NONE(0) and the max is either ROUTE_FORWARD(1) or ROUTE_STORE_AND_FORWARD(2).

    If you look at the Messaging spec (orbos/98-05-06) in section 5.3.5.3, it says:

    "If, for example, the min is ROUTE_NONE and the max is ROUTE_FORWARD, the Routing protocol will normally be used but a direct connection may be used if available."

    Of course, we've left in "usually" just to make sure we could screw up OTS for you

    Reading the text in section 3.3 makes me believe that an issue should really be raised in the Messaging-RTF to clarify this. Here's what I BELIEVE the results would be for all of the combinations.

    min maxresultconfidence ----------- ---------- -------------------- ROUTE_NONEROUTE_NONEDirect Call100% ROUTE_NONEROUTE_FORWARDTII if possible50% direct if not ROUTE_NONEROUTE_STORE_AND_FORWARDTII if possible50% direct if not ROUTE_FORWARDROUTE_FORWARDTII Only100% ROUTE_FORWARDROUTE_STORE_AND_FORWARDTII Only100% ROUTE_STORE_AND_FORWARDROUTE_STORE_AND_FORWARDTII Only100%

    Obviously, the problem is with cases #2 and #3.

    How should an ORB determine which to use: what priority is given to each of the RoutingType values?

  • Reported: CPP 1.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

ORB::shutdown vs. ORB::destroy

  • Key: CORBA3-24
  • Legacy Issue Number: 4164
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    The CORBA 2.3 spec says under ORB shutdown:

    Once an ORB has shutdown, only object reference management
    operations(duplicate, release and is_nil) may be invoked on the ORB or
    any object reference obtained from it. An application may also invoke
    the destroy operation on the ORB itself. Invoking any other operation
    will raise the BAD_INV_ORDER system exception with the OMG minor code 4.

    This implies that calling ORB::shutdown also terminates the client
    side processing. I think that this wrong. I believe that ORB::shutdown
    should terminate server side processing. ORB::destroy should terminate
    the client side processing.

  • Reported: CORBA 2.4.1 — Sat, 20 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Encodings of Sequences of Certificates are not standard.

  • Key: CORBA3-23
  • Legacy Issue Number: 4156
  • Status: closed  
  • Source: Syracuse University ( Polar Humenn)
  • Summary:

    Explicit ASN.1 definitions of a sequence of certificates make a single
    ASN.1 object out of the certificates. This approach is not what most
    systems use today.

    Discussion:

    The CSI::ITTX509CertChain and the CSI::X509AttributeCertChain both
    stipulate that the encodings of these "chains" be a single ASN.1 encoded
    object. Sequences of certificates usually come in the form of a byte
    stream of either ASN.1 DER encoded objects, or PEM encoded objects, (i.e.
    Base64 encodings wrapped with "---BEGIN CERTIFICATE--", "---END
    CERTIFICATE---" lines). It would be ideal to be able to handle both of
    kinds these sequences, since many toolkits work this way already.

    Tool kits that are provided in OpenSSL and Java, namely,
    java.security.cert.CertificateFactory will not be able to handle the
    encoding brought forth by the CSIv2 specification. However, the toolkits
    will be able to handle a stream sequence of ASN.1 or even PEM encoded
    objects, i.e. without the ASN.1 SEQUENCE wrapper.

    Proposed Solution:

    Eliminate the ASN.1 definitions in the specification, namely para 50 that
    defines ASN.1 syntax for a certificate chain (i.e. "CertificateChain"),
    and para 33 thru 34 for the corresponding one that fits the
    AttributeCertificate(i.e. AttributeCertChain and VerifyingChain).

    Furthermore, I believe, that the definition of CSI:ITTX509CertChain be
    eliminated in favor of a single OID that forms a GSS_NT_ExportedName type,
    in which it's name component is simply a non-empty sequence of
    certificates (in any form), as well as creating an OID that stipulates a
    supported name type is a DN, ASN.1 encoded or string form.

  • Reported: CORBA 2.4.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    The proposed change is backward incompatible. Close no change

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

Portable interceptors and invocation timeouts

  • Key: CORBA3-20
  • Legacy Issue Number: 3947
  • Status: closed  
  • Source: Progress Software ( Eoghan Glynn)
  • Summary:

    I'd like to raise an issue and garner feedback on the interaction of the
    Messaging timeout QoS policies (or indeed any proprietary invocation
    timeout mechanism) and portable interceptors.

    Where a bound is being imposed on request and/or reply delivery, and
    portable interceptors are present in the client- and/or server-side
    binding, these interceptors surely must be made aware of the relevant
    timeout(s) so that they may bound any potentially blocking activities
    they engage in. Assuming that it would be unacceptable to dictate that
    potentially blocking activity (such as making a subsidiary invocation)
    may not be undertaken in interception point operations, it appears some
    addition to the PortableInterceptor::RequestInfo interface is required
    to facilitate the Messaging timeout policies at least. For instance, the
    absolute request and reply expiry times could be passed as additional
    attributes:

    module PortableInterceptor
    {
    interface RequestInfo

    { // ... readonly attribute TimeBase::UtcT request_end_time; readonly attribute TimeBase::UtcT reply_end_time; }

    ;
    };

    the former bounding the send_request, send_poll,
    receive_request_service_contexts and receive_request interception points
    and the latter bounding the send_reply, send_exception, send_other,
    receive_reply, receive_exception and receive_other interception points.
    Of course this all relies on the discipline of the portable interceptor
    implementor, i.e. that they do not ignore the constraints imposed by the
    timeouts.

  • Reported: CORBA 2.4 — Thu, 12 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Missing minor codes in Messaging Chapter

  • Key: CORBA3-19
  • Legacy Issue Number: 3914
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Minor codes specifications are missing in all the places where the
    specifications states that a system exception is to be raised. The minor
    codes need to be specifiedto complete the specification of exceptional
    beahivior.

  • Reported: CPP 1.1 — Thu, 14 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

wchar endianness

  • Key: CORBA3-22
  • Legacy Issue Number: 4008
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    In a similar vein to Vishy's question about alignment, what should the
    endianness of a word-oriented wchar be? This applies both to single
    wchars, and the separate code points in a wstring. With the 2.3 spec,
    it seemed quite obvious to me that word-oriented wide characters
    should have the same endianness as the rest of the stream. After all,
    they are no different from any other word-oriented type.

    However, with the new 2.4 spec, there is now a bizarre section saying
    that if, and only if, the TCS-W is UTF-16, all wchar values are
    marshalled big-endian unless there is a byte-order-mark telling you
    otherwise. I don't understand the point of this. Section 2.7 of the
    Unicode Standard, version 3.0 says [emphasis mine]:

    "Data streams that begin with U+FEFF byte order mark are likely to
    contain Unicode values. It is recommended that applications sending
    or receiving untyped data streams of coded characters use this
    signature. _If other signaling methods are used, signatures should
    not be employed._"

    It seems quite clear to me that a GIOP stream is a typed data stream
    which uses its own signalling methods. The Unicode standard therefore
    says that a BOM should not be used.

    I guess it's too late to clean up the UTF-16 encoding, but what about
    other word-oriented code sets? What if the end-points have negotiated
    the use of UCS-4? Should that be big-endian unless there's a BOM?
    The spec doesn't say. Even worse, what if the negotiated encoding is
    something like Big5? That doesn't have byte order marks. Big5
    doesn't have a one-to-one Unicode mapping, so it's not sensible to
    always translate to UTF-16.

    GIOP already has a perfectly good mechanism for sorting out this kind
    of issue. Please can wchar be considered on equal footing with all
    other types, and use the stream's endianness?

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

No portable way to turn IOR components into object-reference policies

  • Key: CORBA3-21
  • Legacy Issue Number: 3989
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    For instance, OTS has a policy called OTSPolicy. This policy is
    encoded in an IOR component with component id TAG_OTS_POLICY. This
    policy governs how transactions are handled when invocations are made
    on the object reference.

    Problem:

    As an end user I would like to be able to interrogate the value of this
    policy. I would expect to be able to call CORBA::Object::_get_policy
    with the OTS PolicyType identifier to retrieve the OTSPolicy and
    subsequently determine the value. However, at present there is no
    portable way to turn this IOR component into a policy.

  • Reported: CORBA 2.4 — Tue, 24 Oct 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This is in essence the same as issue 3615. Merge with 3615 and close this issue

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

Portable Interceptors / register_initial_reference()

  • Key: CORBA3-15
  • Legacy Issue Number: 3672
  • Status: closed  
  • Source: International Business Machines ( Mr. Phil Adams)
  • Summary:

    I am in the process of implementing Portable Interceptors within a C++
    ORB,
    and I would like to raise an issue for resolution regarding the semantics
    of the
    "register_initial_reference()" function, particularly with respect to the
    memory
    management of the object being registered.

    The interface for this function is as follows:

    void register_initial_reference (
    ObjectId id,
    Object_ptr obj
    );

    Within the Portable Interceptors specification, there is really no
    information about
    how the memory for the object should be managed. For example, does the
    caller of
    "register_initial_reference()" pass ownership of the object to the ORB, or
    not?
    Also, does the caller of "resolve_initial_references()" gain ownership of
    the object
    which is returned, or not?

    Here is my proposed resolution:

    The fact that the "obj" parameter is a CORBA::Object implies that it is a
    reference-counted
    object. Therefore, it would make sense that when
    "register_initial_reference()" is called, the
    ORB performs a "_duplicate()" on the object to increment its reference
    count (the ORB would
    then hold its own reference count). The caller of
    "register_initial_reference()" can decide
    whether to call "release()" or retain its own reference count.

    Later, when "resolve_initial_references()" is called, the ORB would call
    "_duplicate()" on the
    object prior to returning it to the caller, thereby giving the caller its
    own reference count.
    The caller would then need to call "release()" when it is finished with
    the object.

    When the ORB is deleted, it must clean up the lookup table of registered
    objects. To do this,
    it simply calls "release()" on each one, and if no one else holds a
    reference count, then
    the object is simply deleted.

    I would like the hear other people's thoughts on this, particularly those
    who have done or are
    working on a C++ implementation of PI.

  • Reported: CPP 1.1 — Tue, 6 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

Policy Management in Portable Interceptors

  • Key: CORBA3-14
  • Legacy Issue Number: 3615
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

    (All document refs to ptc/00-04-05)

    Sec. 4.3.7.1 (Object::get_policy) talks about "the Policy as specified in
    the IOR". Policies get translated to IOR components, but AFAIK there's no
    general way that a component can be unscrambled to give a Policy. This
    suggests that we need another interception point, effectively the inverse of
    the existing IORInterceptor (sec. 21.5), that allows an IOR component to be
    converted into a Policy on the client side.

    I suggest something like:

    local interface ReceiveIORInterceptor : Interceptor

    { void establish_policies (in ReceiveIORInfo info); }

    ;

    local interface ReceiveIORInfo

    { CORBA::Policy set_policy (in CORBA::Policy policy); IOP::TaggedComponent get_ior_component (); IOP::TaggedComponent get_ior_component_from_profile ( in IOP::ProfileId profile_id); }

    ;

    and an extra operation add_receive_ior_interceptor in ORBInitInfo.

    ReceiveIORInterceptor::establish_policies provides the opportunity for an
    interceptor to turn IOR components back into Policies, using the
    interceptor's Policy Factories directly or indirectly via
    ORB::create_policy.

    The ORB will call this method on all registered ReceiveIORInterceptor
    objects during or before the first call of Object::get_policy (we needn't be
    more specific - this would allow eager calls on unmarshalling or lazy calls
    within Object::get_policy).

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

ORBInitInfo needs the ORB

  • Key: CORBA3-9
  • Legacy Issue Number: 3429
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. The presumed
    place to put the ORB would be on ORBInitInfo since at least one
    implementation needs the ORB at initialization time. Is that sufficient?
    Or is it also needed in RequestInfo and IORInfo? My guess is that having
    ORB only on ORBInitInfo is sufficient. All interceptors begin here. If
    the ORB is needed at other points, the implementations can assure that it
    is available where it's needed.

    Since ORB is PIDL and we don't want to pollute the interceptor interfaces
    with PIDL, we have to create IDL access to the ORB, but that's another
    issue.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    This issue is a restatement of issue 3403. Merge with issue 3403 and close this issue

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

PI needs the ORB to be available in IDL

  • Key: CORBA3-8
  • Legacy Issue Number: 3403
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Portable interceptor implementations need access to the ORB. In order to
    accomplish this, the ORB must be defined in IDL There are four
    possibilities that have been opined:

    1. Define the ORB as "native ORB;"

    This puts the ORB into the IDL namespace. However, the ORB is still
    described in PIDL. This doesn't really help us to remove PIDL, some folks
    feel this is a misuse of native, but it would be sufficient for the
    requirements of PI.

    2. Define an IDL wrapper for the ORB, call it proxyORB for now.

    proxyORB would contain exactly the same items that the PIDL ORB does, only
    defined in pure IDL. Advantages: this is a migration step toward getting
    rid of ORB PIDL if we encourage folks to use proxyORB rather than ORB.
    Disadvantages: dual maintenance; lots of work - too much for this FTF?; I
    don't think we know all the ramifications; where do you get a proxyORB?
    from the ORB?

    3. Make the leap and redefine ORB in IDL now.

    This option is similar to option 2, but the IDL is not a wrapper, it's the
    real ORB. Advantages: no dual maintenance; we get rid of ORB PIDL right
    now. Disadvantages: BIG step - too big for this FTF?; lots of work; I
    don't think we know all the ramifications.

    4. Make the ORB a primitive type like TypeCode.

    This seems to be generally undesired. It requires all compilers to change.
    Unless someone really likes this approach, I don't think we should even
    consider it.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve this issue simultaneously with 3772 and close it as soon as 3772 is resolved and closed

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

Question about routing policies

  • Key: CORBA3-7
  • Legacy Issue Number: 3355
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    How are the routing policies e.g.ImmediateSuspend, LimitedPing, UnlimitedPing,
    etc. created. It is not clear that these can be created using the standard
    create_policy operation since these policies are valuetypes that support the
    CORBA::Policy interface.

    Also what are the Policy Type tag values for these policies?

  • Reported: CPP 1.1 — Tue, 22 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Portable Interceptors: object_to_string, string_to_object

  • Key: CORBA3-6
  • Legacy Issue Number: 3322
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    object_to_string and string_to_object are missing on ORBInitInfo.

  • Reported: CPP 1.1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Resolve in conjunction with 3772 and close this issue when 3772 is resolved

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

Implementing proper handling of CloseConnection

  • Key: CORBA3-5
  • Legacy Issue Number: 3076
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • Summary:

    The CORBA 2.3 spec says in chapter 15.7.1:

    "After receiving a CloseConnection message, an ORB must close the TCP/IP
    connection. After sending a CloseConnection, an ORB may close the TCP/IP
    connection immediately, or may delay closing the connection until it
    receives an
    indication that the other side has closed the connection. For maximum
    interoperability with ORBs using TCP implementations which do not
    properly implement orderly shutdown, an ORB may wish to only shutdown
    the sending side of the connection, and then read any incoming data
    until it receives an indication that the other side has also shutdown,
    at which point the TCP connection can be closed completely."

    Most (or all?) Unix TCP/IP implementations suffer from the problem
    described above, i.e., with most Unix TCP/IP implementations the last
    message sent is discarded if the connection is closed. The workaround,
    to shut down the sending side only, and then to read data until EOF is
    received, works fine for C++ ORBs.

    However, there is no equivalent to shutdown() in Java, so I don't see
    any way to reliably transmit the CloseConnection message from a Java ORB
    running on Unix.

    Questions:

    • Is there perhaps some other way to reliably transmit the last message
      before closing the connection, using Java running on Unix?
    • If not, doesn't this mean that IIOP's connection closure strategy is
      unimplementable in Java under most Unixes?
  • Reported: CORBA 2.3.1 — Fri, 3 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above, close, no change

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

Overriding POA policies

  • Key: CORBA3-13
  • Legacy Issue Number: 3609
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    it appears to be impossible to portably attach OTS policies
    to POAs with the machinery that is currently in place. We need a fix for
    that, otherwise OTS ends up getting hamstrung...

  • Reported: CPP 1.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.3
  • Disposition Summary:

    close no change

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

Portable Interceptors: 9.2.3 text describing `Arguments'

  • Key: CORBA3-12
  • Legacy Issue Number: 3601
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The text in section 9.2.3 / page 9-71 describing the
    arguments attribute to ORBInitInfo could use some
    more precise wording. It reads:

    "This attribute contains the arguments passed to ORB_init.
    They may or may not contain the ORB's arguments."

    I take this to mean that any ORB_init arguments that
    applied to the ORB instance being created may not be
    present. All other strings passed to ORB_init will be
    present so initialisation strings can be passed to
    the interceptors through ORB_init.

    With the current text it is possible to think that
    you may not get any of the arguments to ORB_init.

  • Reported: CPP 1.1 — Wed, 3 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

No way to detect that ORB has outstanding deferred synchronous requests

  • Key: CORBA3-2
  • Legacy Issue Number: 2299
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: There is currently no way to detect that an ORB has outstanding
    deferred synchronous requests. In the DII, this was possible via
    the blocking ORB::get_next_response operation. A mechanism is needed so
    that applications can (for example) shutdown gracefully
    only after all outstanding deferred synchronous operations have
    returned results.

  • Reported: CORBA 2.2 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

constant decls broken

  • Key: CORBA3-1
  • Legacy Issue Number: 1139
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    Summary: When the extended IDL types were added to CORBA, the semantics of IDL
    constant declarations seems to have been broken. In CORBA 2.0 (July
    1995) the third paragraph of section 3.7.2 page 3-18 states:

    "An integer constant expression is evaluated as unsigned long unless
    it contains a negated integer literal or the name of an integer
    constant with a negative value. In the latter case, the constant
    expression is evaluated as signed long. The computed value is coerced
    back to the target type in constant initializers. It is an error if
    the computed value exceeds the precision of the target type. It is an
    error if any intermediate value exceeds the range of the evaluated-as
    type (long or unsigned long)."

    The paragraph following the one quoted above explains the same for
    floating-point constants.

    Unfortunately, CORBA 2.2 has broken this. Section 3.7.2, page 3-20,
    of formal/98-02-01 tells us what to do if types are long, unsigned
    long, long long, unsigned long long, double, and long double, but the
    old text stating how general integer constants and floating point
    constants were evaluated has been completely removed! How should the
    following be evaluated?

    const short S = 1 + 2;

  • Reported: CORBA 2.2 — Wed, 15 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    see above

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

scheme name for IORs

  • Key: CORBA3-4
  • Legacy Issue Number: 2785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax for stringified IORs in section 13.6.6 shows:

    <prefix> = "IOR:"

    The problem is that URL scheme names are supposed to be case insensitive.
    So, "Ior:" or "ioR:" should be allowed to.

    I would suggest to add a footnote to state that case for the scheme name
    is ignored.

  • Reported: CORBA 2.3 — Thu, 1 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    Already fixed in CORBA 3.0, close no change

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

issue with ForwardRequest exception in POA

  • Key: CORBA3-3
  • Legacy Issue Number: 2431
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ForwardRequest exception in the POA specification doesn"t allow the
    servant manager to specify whether the status of the GIOP reply is
    LOCATION_FORWARD or LOCATION_FORWARD_PERM. If an application is designed
    to use ForwardRequest exceptions, then it should be able to state whether
    the new object reference is transient or permanent.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 3.0.2
  • Disposition Summary:

    close no change

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

Page 13C-36: Editorials

  • Key: CORBA21-31
  • Legacy Issue Number: 711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The typpedef enum at top of page should be called CORBA_CompletionStatus, not CORBA_ExceptionType. Second line 4th paragraph, text should refer to table 13-5, not 3-5

  • Reported: CORBA 2.0 — Thu, 21 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.1
  • Disposition Summary:

    closed with issue 901-2 revision text

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

More wrong references in chapetr 11

  • Key: CORBAE-17
  • Legacy Issue Number: 11416
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Section 11 starts with the note that 8.3.4.12 is not required for CORBA/e micro (which should be 11.3.4.12). But the consolidated IDL for corba/e micro does mention this method, probably it needs to removed from there. Maybe also add a note about this to 11.3.4.12

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Upon further discussion, use cases that demonstrated the need for either
    create_reference or create_reference_with_id in either profile are
    lacking. (create_reference and create_reference_with_id were
    developed for use with Servant Managers, mainly). Therefore, both of these operations
    are removed from the Compact and from the Micro profile.

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

Wrong references in chapter 11

  • Key: CORBAE-16
  • Legacy Issue Number: 11415
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Chapter 11 starts with the text below, see that it references chapter 8, that should be 11: Conformant implementations of the CORBA/e Compact Profile must comply with clauses 8.1, 8.2, 8.3 and 8.4.1 of this chapter. Conformant implementations of the CORBA/e Micro Profile must support a single root POA and must comply with clauses 8.1, 8.2, 8.3 (except 8.3.4.1, 8.3.4.2, 8.3.4.4, 8.3.4.9, and 8.3.4.12) and 8.4.2 of this chapter.

  • Reported: CORBAe 1.0b1 — Mon, 17 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

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

CORBA/e and get_interface

  • Key: CORBAE-13
  • Legacy Issue Number: 11324
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, when I look at the CORBA/e compact info it says: no DII, DSI,
    Interface Repository, or Component support.

    But, when looking at the spec, CORBA::Object does deliver get_interface,
    which is documented as below. Why does CORBA/e state that we don't support
    the interface repository, but we do deliver an operation for it?

  • Reported: CORBAe 1.0b1 — Fri, 31 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    close

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

Section: 9.2.1.1

  • Key: CORBAE-12
  • Legacy Issue Number: 11306
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, when I look at the CORBA/e compact info it says: no DII, DSI, Interface Repository, or Component support. But, when looking at the spec, CORBA::Object does deliver get_interface, which is documented as below. Why does CORBA/e state that we don’t support the interface repository, but we do deliver an operation for it? Shouldn't get_interface be removed from CORBA/e? >From the spec: get_interface, returns an object in the Interface Repository that describes the most derived type of the object addressed by the reference. See the Interface Repository chapter for a definition of operations on the Interface Repository. The implementation of this operation may involve contacting the ORB that implements the target object. If the interface repository is not available, get_interface raises INTF_REPOS with standard minor code 1. If the interface repository does not contain an entry for the object's (most derived) interface, get_interface raises INTF_REPOS with standard minor code 2.

  • Reported: CORBAe 1.0b1 — Sat, 25 Aug 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    get_interface should be excluded from both profiles for the stated reasons.
    get_interface was not included in the Minimum CORBA specification.

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

Section: 8.2

  • Key: CORBAE-18
  • Legacy Issue Number: 12211
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    At the end of section 8.2, there are several sentences that are incomplete and missing cross references

  • Reported: CORBAe 1.0b1 — Tue, 5 Feb 2008 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Add the description of register_initial_reference from section 21.8.1 in
    CORBA 3.0.3 to the specification. (It is somewhat misplaced in the CORBA 3.0.3
    specification).
    Add correct cross references to the last three sentences before section 8.2.1.

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

Section: 11.4.1

  • Key: CORBAE-15
  • Legacy Issue Number: 11334
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On this page we have: #if ! defined (CORBA_E_MICRO) // POA attributes readonly attribute string the_name; readonly attribute POA the_parent; readonly attribute POAManager the_POAManager; But there is not endif associated with the !defined

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Since 11.4.1 is confined to the Compact profile and section 11.4.2 separately
    shows the interface supported by the Micro profile, the #if statements are
    redundant and should be removed.

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

Section: 18.2.2

  • Key: CORBAE-14
  • Legacy Issue Number: 11331
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 18.2.2 the get_implementation method is mentioned, but this is not mentioned anywhere else in this spec, should the get_implementation be part of CORBA/e, to my idea not

  • Reported: CORBAe 1.0b1 — Fri, 7 Sep 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    The contents of the Interoperability sections were not touched, only reorganized.
    However, get_implementation was deprecated in CORBA 2.2, and should be
    removed from this document and from the “full” CORBA specification.
    Issue opened with CORBA RTF to reconcile.

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

Section: 6.2.12

  • Key: CORBAE-11
  • Legacy Issue Number: 11113
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    for localobject the interfaces are listed that raise a no_implement, but some methods are listed that are not part of corba/e, like get_component, I think these methods should be removed

  • Reported: CORBAe 1.0b1 — Tue, 26 Jun 2007 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested.

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

The removal of static any from micro

  • Key: CORBAE-10
  • Legacy Issue Number: 10599
  • Status: closed  
  • Source: Raytheon ( Jerry Bickle)
  • Summary:

    Problem: The use of static any may be needed in a micro profile. For example, SDR Deployment and Configuration which can be done for embedded constrained environments for signal processing environments such as DSP and RTL devices need this capability.

    Suggested Change

    Make the static any as an optional compliance point that is not mandatory but is part of the profile.

  • Reported: CORBAe 1.0b1 — Fri, 19 Jan 2007 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

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

Servant_to_id clarification

  • Key: CORBAE-9
  • Legacy Issue Number: 10522
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the OMG spec the servant_to_id is described as below. If the RETAIN,
    NO_IMPLICIT_ACTIVATION an UNIQUE has been set then the pre condition is
    valid so we don't get wrong policy. Then we follow the steps, 1 is not
    possible, 2 is also not possible, 3 is not possible, so 4 is triggered but
    that looks very strange. I think there should be another step says if RETAIN
    and UNIQUE and NO_IMPLICIT_ACTIVATION and not active then we get
    WrongPolicy. Ok, the servant is not active, but it is more that the policies
    are wrong.

    This appeared when testing for CORBA/e compact. There RETAIN,
    NO_IMPLICIT_ACTIVATION and UNIQUE are the default and without a special
    check for CORBA/e we got a ServantNotActive exception instead of the wrong
    policy. We could add a check for CORBA/e compact but it looks that the real
    issue is in the core spec already.

    Johnny

    This operation requires the USE_DEFAULT_SERVANT policy or a combination of
    the
    RETAIN policy and either the UNIQUE_ID or IMPLICIT_ACTIVATION policies if
    invoked outside the context of an operation dispatched by this POA. If this
    operation is
    not invoked in the context of executing a request on the specified servant
    and the policies
    specified previously are not present, the WrongPolicy exception is raised.
    This operation has four possible behaviors.
    1. If the POA has both the RETAIN and the UNIQUE_ID policy and the specified
    servant is active, the Object Id associated with that servant is returned.
    March 2004 CORBA, v3.0.3: Interfaces 11-43
    11
    2. If the POA has both the RETAIN and the IMPLICIT_ACTIVATION policy and
    either the POA has the MULTIPLE_ID policy or the specified servant is not
    active,
    the servant is activated using a POA-generated Object Id and the Interface
    Id
    associated with the servant, and that Object Id is returned.
    3. If the POA has the USE_DEFAULT_SERVANT policy, the servant specified is
    the
    default servant, and the operation is being invoked in the context of
    executing a
    request on the default servant, then the ObjectId associated with the
    current
    invocation is returned.
    4. Otherwise, the ServantNotActive exception is raised.

  • Reported: CORBAe 1.0b1 — Tue, 12 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    No Data Available

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

Section: 11.2.3

  • Key: CORBAE-8
  • Legacy Issue Number: 10507
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    What is the exact implicit activation policy the root poa should support for CORBA/e compact and micro. The page 175 says IMPLICIT_ACTIVATION but section 11.3.3.2 and 11.3.3.1 say NO_IMPLICIT_ACTIVATION

  • Reported: CORBAe 1.0b1 — Thu, 7 Dec 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    NO_IMPLICIT_ACTIVATION was the intent

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

document style and use of headings

  • Key: CORBAE-7
  • Legacy Issue Number: 9926
  • Status: closed  
  • Source: Objective Interface Systems ( Dr. Ben A. Calloni)
  • Summary:

    In each of 2.4.1 thru 2.4.4 the document titles have paragraphs below them and if necessary then sub headings. In 2.4.5 there is the title and then a sub heading.

    I'd recommend deleting the heading of 2.4.5.1 and make 2.4.5 the Quality of Service Abstract Model (or Quality of Service Model to match 2.4.1 - 2.4.4 and put the rest of the text under it

    As reads:

    2.4.5Quality of Service

    2.4.5.1 QoS Abstract Model The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA.

    To read:

    2.4.5Quality of Service (Abstract) Model
    The abstract model describes the Quality of Service (QoS) components and their relationships. The specification defines a framework within which current QoS levels are queried and overridden. This framework is intended to be of use for CORBAServices specifiers, as well as for future revisions of CORBA.

  • Reported: CORBAe 1.0b1 — Tue, 18 Jul 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Change as suggested

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

Section: 6.2

  • Key: CORBAE-6
  • Legacy Issue Number: 9809
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The InvalidPolicies exception uses an anonymous sequence as member. Instead of exception InvalidPolicies

    { sequence <unsigned short> indices; }

    ; It should be exception InvalidPolicies

    { UShortSeq indices; }

    ;

  • Reported: CORBAe 1.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Accepted as suggested.
    Issue opened with CORBA RTF to reconcile.

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

Add table that captures the features that are in/out of CORBA/e

  • Key: CORBAE-5
  • Legacy Issue Number: 9756
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The whole spec is apparently a subset (with rationale) with compliance points of the original CORBA spec. There should be a table that captures the features that are in/out of CORBA/e so that readers can determine quickly what is in the CORBA/e spec (or out), and how it differs.

    Same would apply to CORBA/i when it becomes available.

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Accept as suggested: developed and added comparison table as Annex B.

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

state machine diagram

  • Key: CORBAE-4
  • Legacy Issue Number: 9755
  • Status: closed  
  • Source: Object Management Group ( Stephen Mellor)
  • Summary:

    The "state machine diagram" on pg 8-13 of the 473 page spec isn't UML. (See the dotted state.)

  • Reported: CORBAe 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — CORBAe 1.0
  • Disposition Summary:

    Correct diagram (now 11-5) to “proper syntax”.

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

Section: 1.2.x (CorbaToWsdl)

  • Key: C2WSDL12-8
  • Legacy Issue Number: 9602
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    In Corba to WSDL/SOAP Interworking Spec:
    In section 1.2.x there are several typographical errors in the
    XML schema productions for the examples. Several schema productions
    could not validate as written.

    Proposed Resolution: correct the typographical errors to allow the xml schema productions to validate.
    Revised Text:
    Change G1: to make specification text consistent with the validated machine readable example files, in
    http://www.omg.org/cgi-bin/doc?ptc/04-10-12
    ---------------------------------
    In 1.2.1.1 change the namespace prefixes:
    "wsdl" to "w" and "SOAP-ENC" to "soapenc"

    Throughout the document, wherever soap encoding array is used:
    Change:
    "
    SOAP-ENC
    "
    To:
    "
    soapenc
    "
    And:
    Change:
    "
    wsdl:
    "
    To:
    "
    w:
    "
    And
    Change:
    "[]"
    To:
    ""
    --------------------------------end change G1

    In 1.2.6.1, apply change G1
    And:
    Change:
    "
    </xsd.complexType>
    "
    To:
    "
    </xsd:complexType>
    "

    In 1.2.7.1 Change:
    "<simpleType" to "<xsd:simpleType" and "</simpleType" to "</xsd:simpleType"

    In 1.2.7.3 Change:
    Example.Number>
    to:
    Example.Number">
    And change:
    Example.OtherNumber>
    To:
    Example.OtherNumber">
    And Change:
    "
    xsd:sequence>
    xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1" />
    /xsd:sequence>
    "
    To:
    "
    <xsd:sequence>
    <xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1"/>
    </xsd:sequence>
    "
    And change:
    "
    xsd:complexContent>
    xsd:restriction base="tns:S">
    xsd:sequence>
    xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1" />
    "
    To:
    "
    <xsd:complexContent>
    <xsd:restriction base="tns:S">
    <xsd:sequence>
    <xsd:element name="dummy" type="xsd:int" maxOccurs="1" minOccurs="1"/>
    "

    In 1.2.7.5 apply change G1:

    In 1.2.7.6
    apply change G1 to arrayLong example:
    apply change G1 to struct S example
    apply change G1 to matrix example

    In 1.2.7.10 change: <complexType to: <xsd:complexType
    And change: <xsd:attribute> to: <xsd:attribute

  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    correct the typographical errors to allow the xml schema productions to validate

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

Section: 1.2.11 (CorbaToWsdl)

  • Key: C2WSDL12-7
  • Legacy Issue Number: 9601
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    In Corba to WSDL/SOAP Interworking Spec:
    In section 1.2.11, the CORBA namespace file is missing the production for _VALREF.

    Proposed Resolution: Add the production for _VALREF to the corba.wsdl file
    Revised Text:
    Add the following production, from 1.2.7.10, to the corba.wsdl file in 1.2.11:
    "
    <xsd:complexType name="_VALREF">
    <xsd:attribute name="ref" type="xsd:IDREF" use="optional" />
    <!-- empty attribute used for null semantics, i.e., value graph end nodes -->
    </xsd:complexType>
    "

  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    Add the production for _VALREF to the corba.wsdl file.

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

Section: 1.2.7.5 and 1.2.7.6 (CorbaToWsdl)

  • Key: C2WSDL12-6
  • Legacy Issue Number: 9600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In Corba to WSDL/SOAP Interworking Spec:
    In section 1.2.7.5 and 1.2.7.6, the examples of soap encoded array
    types have the SE prefix after the module identifier. The "_SE"
    prefix is supposed to be at the beginning of the mapped type name.

    Proposed Resolution: fix the examples to change "Example.SE" to "_SE_Example."
    Revised Text:
    In 1.2.7.5 three occurances:
    <xsd:complexType name="Example._SE_longSeq">

    <xsd:complexType name="Example._SE_strSeq">

    <xsd.complexType name="Example._SE_structSeq">

    In 1.2.7.6 one occurance:

    <xsd:complexType name="Example._SE_arrayLong" >

    Change:
    "
    "Example.SE"
    To
    "_SE_Example."

  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    Change the mapping definition text to agree with the examples.

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

Section: 1.2.6.1 (CorbaToWsdl)

  • Legacy Issue Number: 9611
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    In Corba to WSDL/SOAP Interworking Spec:
    In section 1.2.6.1 a soap encoded form for the sequence is used, however the type identifier does not have the SE suffix.

    Proposed Resolution: fix the example to be a WS-I BP compliant sequence mapping only.
    Revised Text:
    In 1.2.6.1, change:
    "
    which maps to:
    "
    To:
    "
    which maps to (only the WS-I BP compliant version is shown for simplicity):
    "
    And, remove the following explicit lines (where … denotes intervening lines to be retained):
    "
    <xsd:complexContent>
    <xsd:restriction base="SOAP-ENC:Array">
    …
    <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:string[]"/>
    </xsd:restriction>
    </xsd:complexContent>
    "

  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    fix the example to be a WS-I BP compliant sequence mapping only

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

Section: 1.2.7.6 (CorbaToWsdl)

  • Key: C2WSDL12-9
  • Legacy Issue Number: 9604
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    : In Corba to WSDL/SOAP Interworking Spec:
    In section 1.2.7.6, the IDL identifier "S" at top level has already been used for another example.

    Also have to make editorial corrections to allow schema to validate.

    Proposed Resolution: change second use of "S" To "T", and apply resolution to issue 8991
    Revised Text:
    In 1.2.7.6 change the following explicitly listed lines: (where "…" implies one or more intervening lines)
    "
    struct S {
    …
    <xsd:complexType name="_SE_S.field_ArrayOfint">
    …
    <xsd:complexType name="_SE_S">
    …
    <xsd:element name="field" type="S._SE_field_ArrayOfint" nillable="true" maxOccurs="1" minOccurs="1"/>
    …
    <xsd:complexType name="S.field_ArrayOfint">
    …
    <xsd:complexType name="S">

    <xsd:element name="field" type="S.field_ArrayOfint" nillable="true" maxOccurs="1" minOccurs="1"/>
    …
    "
    To: (this change also incorporates resolution to Issue 8991)
    "
    struct T {
    …
    <xsd:complexType name="_SE_T.field_ArrayOfint">
    …
    <xsd:complexType name="_SE_T">
    …
    <xsd:element name="field" type="_SE_T.field_ArrayOfint" nillable="true" maxOccurs="1" minOccurs="1"/>
    …
    <xsd:complexType name="T.field_ArrayOfint">
    …
    <xsd:complexType name="T">
    …
    <xsd:element name="field" type="T.field_ArrayOfint" nillable="true" maxOccurs="1" minOccurs="1"/>
    …
    "

  • Reported: C2WSDL 1.1 — Thu, 27 Apr 2006 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    change second use of "S" To "T", and apply resolution to issue 8991

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

Section: 1.2.7.6 Multi-dimensional arrays in IDL

  • Key: C2WSDL12-5
  • Legacy Issue Number: 8995
  • Status: closed  
  • Source: Borland ( Naveed Shaikh)
  • Summary:

    Multi-dimensional arrays in IDL are required to be mapped to intermediate types for each of the sub-arrays. The naming scheme used by the specification can lead to name collision. Referring to section 1.2.7.6 page 1-14, an IDL with the following declaration typedef long matrix [5][3]; maps to complex types as below: <xsd:complexType name="_SE_ArrayOfint"> ... </xsd:complexType> <xsd:complexType name="_SE_matrix"> ... </xsd:complexType> <xsd:complexType name="ArrayOfint"> ... </xsd:complexType> <xsd:complexType name="matrix"> ... </xsd:complexType> However, if you have another type in the above IDL typedef long anotherMatrix[5][3]; This will also map to complex types with names _SE_ArrayOfint, _SE_anotherMatrix, ArrayOfint, anotherMatrix leading to name collision between XML schema types. Same goes for more than two-dimensional arrays. Proposed resolution: To have name collision-free types, an approach can be to include the name and size of that particular array. For example, the above IDL will produce the following schema types. <xsd:complexType name="_SE_ArrayOfint_matrix_3"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" maxOccurs="3"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:int[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="_SE_matrix"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="_SE_matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="_SE_matrix_3[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="ArrayOfint_matrix_3"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" maxOccurs="3"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="matrix"> <xsd:sequence> <xsd:element name="item" type="matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> </xsd:complexType>

  • Reported: C2WSDL 1.1 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    append "_<n>" suffix to the nth arising collision with the collided ArrayOf<type> identifier

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

Section: 1.2.7.6 page 1-14

  • Key: C2WSDL12-4
  • Legacy Issue Number: 8994
  • Status: closed  
  • Source: Borland ( Naveed Shaikh)
  • Summary:

    The specification in section 1.2.7.6 page 1-14 gives the following IDL as example for multi-dimensional arrays typedef long matrix[5][3] What the above array is mapped to is semantically equivalent to matrix[3][5]. Proposed resolution: What we think should be the correct order for the expanded multi-dimenstional array is shown in the following XSD schema: <xsd:complexType name="_SE_ArrayOfint_matrix_3"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" maxOccurs="3"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:int[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="_SE_matrix"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="_SE_matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="_SE_matrix_3[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="ArrayOfint_matrix_3"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" maxOccurs="3"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="matrix"> <xsd:sequence> <xsd:element name="item" type="matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> </xsd:complexType>

  • Reported: C2WSDL 1.1 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    Close as Duplicate to issue 8992

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

Section: 1.2.7.6

  • Key: C2WSDL12-3
  • Legacy Issue Number: 8992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The specification in section 1.2.7.6 page 1-14 gives the following IDL as example for multi-dimensional arrays typedef long matrix[5][3] What the above array is mapped to is semantically equivalent to matrix[3][5]. Proposed resolution: What we think should be the correct order for the expanded multi-dimenstional array is shown in the following XSD schema: <xsd:complexType name="_SE_ArrayOfint_matrix_3"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" axOccurs="3"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:int[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="_SE_matrix"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="_SE_matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="_SE_matrix_3[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="ArrayOfint_matrix_3"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="3" maxOccurs="3"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="matrix"> <xsd:sequence> <xsd:element name="item" type="matrix_3" minOccurs="5" maxOccurs="5"/> </xsd:sequence> </xsd:complexType>

  • Reported: C2WSDL 1.1 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    see above

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

Section: 1.2.7.6

  • Key: C2WSDL12-2
  • Legacy Issue Number: 8991
  • Status: closed  
  • Source: Borland ( Naveed Shaikh)
  • Summary:

    In section 1.2.7.6 page 1-13, the implicit IDL declaration of the following struct S

    { long field[10]; }

    ; generates a complex type _SE_S.field_ArrayOfint for the soap-encoded ::S::field. The complex type _SE_S (corresponding to soap-encoded struct S) refers to field with type S._SE_field_ArrayOfint. There is no schema type _S._SE_field_ArrayOfint. Resolution: The soap-encoded name of S.field should be _S._SE_field_ArrayOfint as shown in the following excerpt. <xsd:complexType name="S._SE_field_ArrayOfint"> <xsd:complexContent> <xsd:restriction base="SOAP-ENC:Array"> <xsd:sequence> <xsd:element name="item" type="xsd:int" minOccurs="10" maxOccurs="10"/> </xsd:sequence> <xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="xsd:int[]"/> </xsd:restriction> </xsd:complexContents> </xsd:complexType> <xsd:complexType name="_SE_S"> <xsd:sequence> <xsd:element name="field" type="S._SE_field_ArrayOfint" minOccurs="1" maxOccurs="1" </xsd:sequence> </xsd:complexType>

  • Reported: C2WSDL 1.1 — Thu, 22 Sep 2005 04:00 GMT
  • Disposition: Resolved — C2WSDL 1.2
  • Disposition Summary:

    see above

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

Validity of object references

  • Legacy Issue Number: 3307
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.4.5, page 15-39:

    LocateRequest messages may be sent from a client to a server to
    determine the following regarding a specified object reference:

    • whether the object reference is valid

    In the absence of a definition for how to judge a reference "valid", this
    is a meaningless statement.

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

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

An ORB should not accept an IOR with no usable profiles

  • Legacy Issue Number: 3303
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    ORBs should be required to reject IORs that do not contain any profile that the ORB can use

  • Reported: CPP 1.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    accomodated by proposed change from Issue 3234.

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

Should an ORB be allowed to drop non-standard profiles

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

    Part 2: Should an ORB be allowed to drop non-standard profiles (as it is allowed
    to, indeed almost encouraged to do in GIOP/IIOP 1.2) even though it is not faced
    with any resource contraints. Moreover, when it is faced with resource
    contraints should it be required to follow a specific sequence in determining
    what profiles to drop.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The proposed resolution defines two possible IOR conformance classes for every ORB interoperability

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

selected_profile_index origin

  • Legacy Issue Number: 3622
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    Since the index numbering of sequences is a language mapping specific issue, the origin of the selected_profile_index within the IORAddressingInfo must be specified. I assume a zero origin is meant.

    Proposed Resolution:
    Add the following sentence to the description of IORAddressingInfo (in section 15.4.2.1 of the 25 March CORBA 2.4 preliminary draft): "The first profile has an index of zero."

  • Reported: CPP 1.1 — Thu, 18 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Accept proposed solution.

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

Absence of Wide Character Code Set

  • Legacy Issue Number: 3576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CORBA is inconsistent on how to deal with the lack wide character code set
    information in an IOR and the codes set service context.

    When a server receives a service context without a wide character code set
    specified, then it is supposed to raise BAD_PARAM when it receives wide
    characters data from the client.

    However a client is supposed to raise INV_OBJREF if the IOR is missing
    from the server's native wchar code set . In CORBA 2.3, section13.7.2.6,
    "Code Set Negotiation", it says, "... a server that supports interfaces
    that
    use wide character data is required to specify its native wchar code set;
    if
    one is not specified, then the client-side ORB raises exception
    INV_OBJREF."

    This requires a client to know whether a server supports interfaces that
    use
    wide character data at the time the client receives an IOR. To determine
    this when the first IOR is received is a burdensome task. The client orb
    would be forced to apply an exhaustive examination, such scanning all of
    the
    server's IDL bindings or the contents of the IFR looking for wchar types.
    Additionally the client may need to determine if some Any might flow
    containing wchar data.

    I propose that the client's behavior be changed to match the server's. If
    any wide character data is encountered and the server's IOR was missing
    the native wchar code set, (which would cause the wide character
    transmission
    code set to not be negotiated), the client should raise BAD_PARAM.

    This will allow common marshal and demarshal code to be independent of
    whether it is running as a client or server. It also allows users to not
    configure
    wide character code sets if they know they aren't using them.

  • Reported: CPP 1.1 — Fri, 21 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    The check should be able to be done at invoke time by the client orb

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

ORB throwing exception if it finds unknown service context

  • Legacy Issue Number: 3565
  • Status: closed  
  • Source: UBS ( Urs Kuenzler)
  • Summary:

    Why does it make sense at all to allow an ORB to throw an exception if it finds
    a service context it does not "understand"? This is not very helpful for
    interoperability. Would a sending ORB have to handle this exception and resend
    the same request without context to allow to interoperate with an ORB throwing
    BAD_PARAM in this case? If an unknown service context is sent with a reply, the
    receiving ORB would throw BAD_PARAM at the caller (even if it got a valid
    reply). The originator of the service context wouldn't even know.

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    To close with Issue 3561 resolution to eliminate option of throwing exception

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

Wrong minor code specified in Chapter 13

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

    In document ptc/00-03-02 on page 13-30 in the last bullet on that page it says: "If a system
    exception is raised , it shall be BAD_PARAM with an OMG standard minor code of 1".

    This cannot be right because the OMG standard minor code of 1 for BAD_PARAM is assigned to "failure
    to register, unregister or lookup value factory."

    I recommend that we change this minor code to a new one that is properly allocated with the
    associated text that reads something like: "Service context not understood". I am still wondering
    though why BAD_PARAM is the correct exception to raise. Wouldn't BAD_CONTEXT be more appropriate?

    In any case we have to change the minor code, even if we cannot make up our minds about which
    exception.

  • Reported: CPP 1.1 — Fri, 14 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved and closed

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

Table 13-1 needs update for valuetypes & abstract interfaces

  • Legacy Issue Number: 3128
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Table 13-1 is missing a row:

    Feature Version 1.0 Version 1.1 Version 1.2
    -----------------------------------------------------------
    Valuetypes and yes
    Abstract
    Interfaces

  • Reported: CORBA 2.3.1 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    add table row as suggested.

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

marshalling of null values unclear

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

    Description: Instruction for marshalling of null values is missing (in

    ptc/99-03-07). Issues include:

    • The null_tag token is included in the grammar, but it's purpose is
      described nowhere. If this is the intended encoding of any null value,
      how are the typing semantics of values to be maintained? For example,
      which type-specific factory is to be used to create the null value to
      be
      passed to the servant? How are the truncation semantics to be
      preserved?
    • There is a statement in 15.3.4.5 that "[t]he tag value 0 is reserved
      for future use". Does this refer to null_tag? (Note that there seems to
      be
      inconsistent use of "tag" within the text.) If so, how are null values
      to be marshalled? The grammar doesn't seem to allow for zero length
      value_data.
  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

CDR Encapsulation Issue

  • Legacy Issue Number: 3096
  • Status: closed  
  • Source: Camros Corporation ( Jeffrey Marshall)
  • Summary:

    In the current 2.3 spec section 15.3.3 on Encapsulation
    states in the last paragraph:
    "Note that this gaurantees a four-octet alignment of the
    start of all encapsulated data within GIOP messages and
    nested encapsulations(2)"

    There's a foot note on the bottom of the page stating:
    (2) "Accordingly, in cases where encapsulated data holds
    data with natural alignment of greater than four
    octets, some processors may need to copy the octet
    data before removing it from the encapsulation. The
    GIOP protocol itself does not require encapsulation
    of such data"

    Here's the problem, the latest revisions have added support
    for a "[unsigned] long long" being the discriminator type
    within a union and therefore the encapsulated information
    for a tk_union TypeCode could have alignment needs of eight,
    not four.

    The footnote needs to be revised to indicate that copying
    could be necessary for some type code indirections or at
    least the sentence stating that "GIOP problem itself..."
    should be removed/revised. Of course we could try to
    remove support for "long long" discriminators....

    Some of the interoperability testing we've been doing
    indicates that all but one vendor who supports long long
    discriminator types are not doing things correctly...

  • Reported: CORBA 2.3.1 — Tue, 7 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

Preserving unencapsulated information

  • Legacy Issue Number: 3327
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 15-50 of 2.3.1:

    ORBs that suport only version 1.1. or 1.2 IIOP profiles must
    ignore, but preserve, any data in the profile that occurs
    after the components member.

    A 1.2 ORB is obliged to ignore, but preserve, any information that follows
    the components member in 1_1 profile body. I think the cost of implementing
    this is quite high. What follows after the components member is not in
    a separate encapsulation. So, an ORB that receives an IOR that indeed has
    data after the components member doesn't understand anything about that data
    and therefore must treat it as a blob of bits.

    However, the IOR might be little-endian and the receiving ORB might be
    big-endian. When the receiving ORB wants to send the IOR back out, it
    can't send it as a big-endian IOR because it can't know how to byte-swap
    the data that follows the components member. That means that a big-endian
    ORB is obliged to remarshal the IOR back as a little-endian IOR.
    That's inconvenient, to say the least.

    I don't think it makes sense to require an ORB to preserve something that
    is not encapsulated, simply because the cost of doing this is high.
    (The ORB has to keep a copy of the marshaled profile around because of
    the trailing bit it doesn't understand.)

  • Reported: CPP 1.1 — Thu, 17 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision

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

Indirection for value types

  • Legacy Issue Number: 3315
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 15.3.4, page 15-18:

    The encoding used for indirection is the same as that used for
    recursive TypeCodes (i.e., a 0xffffffff indirection marker
    followed by a long offset (in units of octets) from the beginning
    of the long offset).

    [...]

    Indirections may refer to any preceding location in the GIOP
    message, including previous fragments if fragmentation is used.
    This includes any previously marshaled parameters.

    The beginning of the section ("is the same as that used for recursive
    TypeCodes") is in conflict with what appears at the end ("refer to any
    preceding location in the GIOP message [...]. This includes any previously
    marshaled parameters.")

    This is incorrect because the indirection for type codes does not permit
    indirections that span type code boundaries (page 15-27):

    The indirection applies only to TypeCodes nested within
    some "top-level" TypeCode. Indirected TypeCodes are not
    "freestanding," but only exist inside some other encoded TypeCode.

    I would suggest to rephrase the first part of what is on page 15-18
    to avoid saying that the indirection is the same as for type codes
    because that's simply not the case.

  • Reported: CPP 1.1 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close with revision

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

chunked value encoding:

  • Legacy Issue Number: 3231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    a chunk can be followed by:

    1. a new chunk (starting with its size tag)
    (1 <= chunk_size_tag < 0x7fffff00
    2. a new value (value_tag | 0 | value_ref)
    (0x7fffff00 <= value_tag <= 0x7fffffff)
    (valueref = 0xffffffff)
    3. an end tag
    (0x80000000 <= end_tag <= 0xffffffff)

    A value indirection and a "top-level" end tag, both have the same tag (0xffffffff).
    Consequently, the 0xffffffff tag marks the end of the current value but it is not clear whether or not a new value (indirection) has started.

    An example where this situation occurs is a ring buffer that is chunked encoded.

  • Reported: CPP 1.1 — Tue, 18 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

CORBA 2.3.1 missing text describing the response_expected field

  • Legacy Issue Number: 3195
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    When the response_flags text was added for GIOP 1.2 Request processing,
    the old text for the GIOP 1.0 and 1.1 response_expected field was
    removed. Thus, the current documentation no longer completely describes
    the GIOP 1.0 and 1.1 protocols.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revision

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

Supporting TAG_MULTIPLE_COMPONENTS

  • Legacy Issue Number: 3176
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on how can ORB vendor support profile with ID
    TAG_MULTIPLE_COMPONENTS? The spec 2.3/13.6.2 says single profile holds
    enough information to drive a complete invocation. Let us say we have an
    IOR with one profile and the ID is TAG_MULTIPLE_COMPONENTS. As per
    13.6.2.2, the profile body in this case contains a
    MultipleComponentProfile. Let us again assume that there is only one
    TaggedComponent with component id of TAG_CODE_SETS and its component
    data.

    What we have here is a legal profile with no end point information. What
    can a ORB do with such a profile? Is there any thing broken here or did
    I just misinterpret the spec completely?

  • Reported: CPP 1.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no revision

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

GIOP version and CloseConnection

  • Legacy Issue Number: 3438
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I believe that, at some point, we decided that it is legal to send
    request for different GIOP versions over the same connection. Could someone
    please confirm or deny? (My memory is a bit hazy on the details.)

    At any rate, careful scrutiny of the spec does not reveal any words that would
    either state that separate connections must be used for different GIOP versions
    or that they can share a single connection. A definite statement is required
    either way.

    Assuming that different GIOP versions can indeed coexist on the same
    connection, we get an interesting problem: for GIOP 1.0 and 1.1, the spec
    disallows a client to send a CloseConnection message; for GIOP 1.2, it
    requires the client to send a CloseConnection message. This begs the question:
    if different GIOP versions can coexist on the same connection, it becomes
    impossible to achieve orderly connection shutdown. Sending a CloseConnection
    message is illegal for GIOP 1.0 and 1.1, whereas it is required for
    GIOP 1.2... So, what's the client to do if multiple GIOP versions are used
    over the same connection?

  • Reported: CPP 1.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    To close with revision

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

Valuetype in anys. Unmarshaling problem?

  • Legacy Issue Number: 3434
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    There seems to be a problem with valuetypes contained in anys.

    Consider the following:
    valuetype A

    { A a; }

    ;

    valuetype B : A

    { private long long x; }

    ;

    If an instance w/ the following structure:

    A { a = {B { x = {<value>}}}}

    is inserted into an any and the any is received by an event service. Given that
    the event service has no type information of the B encoded inside of A, the
    event service has no way of knowing how big A.a (an instance of B) is and how
    many bytes it needs to read (unless it contacts an IR)

    Am I missing something here?

  • Reported: CPP 1.1 — Mon, 20 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue and place it into the GIOP wish list for future enhancements to GIOP.

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

Transferring Java exception reason string across the wire

  • Legacy Issue Number: 3405
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Although this is a Java-specific issue, I suspect it will have to be
    decided in interop, therefore I'd like this to be an interop issue. I've
    cc'ed java-rtf since I'm sure they'll be interested.

    System exceptions only have: minor code, completion status. Java
    exceptions all have a reason string as well. This is a potentially
    significant bit of info that is not getting transferred across the wire in
    Java ORB implementations. Our rmi over iiop customers expect this
    information.

    Our suggested solution is to create another service context for a system
    exception reason string. When a system exception occurs, on a Java server,
    the ORB places the reason string into this service context on the reply
    message. On a Java client, the ORB checks for and extracts this string and
    uses it when creating the system exception instance which is propagated to
    the application code. If the service context doesn't exist, the Java ORB
    just does what it does today. Any other client bindings may ignore this
    service context.

    Java bindings do not need to change for this proposal.

    To be more precise (sorta), we need three things:
    1. A new service context ID

    const ServiceId SystemExceptionReason = TBD;

    2. The context data associated with this ID is a CDR encapsulation of a
    string.
    3. Some verbage somewhere describing this.

  • Reported: CPP 1.1 — Tue, 21 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed/resolved

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

Nesting depth in valuetype end tags

  • Legacy Issue Number: 3526
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 15.3.4.5 contains an inconsistency in the description of how end tags
    for valuetypes are written. Consider the case where an unchunked value (V)
    contains a chunked value (CV1). Should the end tag for CV1 contain a nesting
    depth of -2 or -1?

    The following sentence in the spec seems to imply that the correct value is -2:

    > The end tag is a negative long whose value is the negation of the absolute
    > nesting depth of the value type ending at this point in the CDR stream.

    However the spec also says:

    > The outermost value type will always be terminated by an end tag with a
    > value of -1.

    which is not true if the end tag for CV1 is written as -2, since no end tag
    with a -1 value will be written.

    Proposed resolution:

    Delete the second above sentence from the spec.

  • Reported: CPP 1.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with revision using alternative A above.

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

Valuetype encoding grammar in 15.3.4.7 is wrong

  • Legacy Issue Number: 3512
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The valuetype encoding "grammar" in 15.3.4.7 is wrong. The rule for
    <state> should be:

    <state> ::= <octets> |<value_data>* [ <end_tag> ]

    to allow for valuetypes with no state and therefore no value chunks.

    -

  • Reported: CPP 1.1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    to close with revised text

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

Marshaling fixed-point decimal types

  • Legacy Issue Number: 3431
  • Status: closed  
  • Source: Oracle ( Stefan Bauer)
  • Summary:

    Looking at formal/99-10-07, 15.3.2.8 which describes marshaling of fixed
    types I ran into a question. The section doesn't mention how to indicate
    the scale of the written decimal.

    My understanding is that the TypeCode of kind fixed, which gets written
    before the value, indicates the maximum number of digits and the maximum
    scale, not what is currently contained in the number. To describe the
    current scale I would expect that a decimal point gets written to the
    stream, just like the decimals into the half-octets as described in
    15.3.2.8.

  • Reported: CPP 1.1 — Thu, 16 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close with no Interop Revision

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

IIOP 1.2 Early Reply message in presence of fragmented Request

  • Legacy Issue Number: 3409
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It is unclear in the spec when reply messages are allowed when a fragmented
    send message is sent.

    It is possible to know that a system exception will occour before the last
    fragment in a message is recieved, for example the request can be
    demultiplexed to discover the object does not exist, or the appropriate
    service contexts are not present.

    It should be legal to send a reply containing anything but a NO_EXCEPTION or
    USER_EXCEPTION before the last fragment is recieved.

  • Reported: CPP 1.1 — Wed, 8 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close without revision

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

Minor code allocation inconsistency

  • Legacy Issue Number: 3040
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    CORBA 2.3, section 15.4.3.2 - Reply Body - states:

    "A vendor (or group of vendors) wishing to define a specific set of system
    exception minor codes should obtain a unique VMCID from the OMG, and then
    define up to 4096 minor codes for each system exception."

    Section 3.17 - Standard Exceptions - states:

    "Within a vendor assigned space, the assignment of values to minor codes is
    left to the vendor."

    The first dictates that minor code numbers are in the space of each
    Standard Exception. Ie, the true # of minor codes is (4096 times
    #-of-Standard-Exceptions). But the second implies that vendors can
    allocate their minor codes however they wish.

    So which is it? The first mandate (if you read it as a mandate) or the
    second freedom?

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Take proposed resolution from Core RTF discussion in issue Archive

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

.Passing the interface repository ID of the method in IIOP

  • Legacy Issue Number: 2031
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If we had a repository ID on the wire with every request, such errors could
    > be caught. In addition, it would make it substantially easier to build
    > tools such as IIOP packet tracers – right now, it is next to impossible
    > to dump the parameter values of IIOP requests because the packet tracer
    > has no way of figuring out what the type of the target object is.

    This could be added to IIOP in a reasonably non-invasive way, too. We
    could add a service context to the request which would carry the
    repository ID of the interface in which the method was defined

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Chunked GIOP marshalling for variable-length types

  • Legacy Issue Number: 1677
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Following the discussion of valuetype chunking in the OBV group, I"ve
    been thinking that the arguments advanced for it really apply to all
    the other variable-length types in CORBA (sequences and strings) as
    well as to OBV value types, and wonder if we might try a small change
    to the marshalling rules.

    Currently, we marshal a string (say) by sending the length of the
    string followed by the bytes of the string. If we don"t know the
    string"s length in advance, say because we are reading it from stdin
    or a subprocess, we need to buffer it in memory and send it as one big
    thing. That"s inefficient.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

TAG_ENDPOINT_ID_POSITION and TAG_LOCATION_POLICY

  • Legacy Issue Number: 1303
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there any particular reason that we shouldn"t allow these two
    ComponentIds in IIOP IORs? They certainly can be useful using IIOP for
    optimization of client/server interactions, and can be safely ignored by
    clients that don"t implement/understand them.

    So could we add text to the spec that states that these components are
    allowed in IIOP IORs, but the clients are free to ignore them?

  • Reported: CORBA 2.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Optimization of LOCATION_FORWARD replies

  • Legacy Issue Number: 1133
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As of GIOP/IIOP 1.1, if a server wants to have a client
    use some locally hashed down object_key in future requests
    for an object, it must require one of the following:
    a) the client use a LocateRequest in order for the server
    to reply with a forwarded object reference that has
    a hashed down object key.
    b) respond with an OBJECT_FORWARD reply to the request,
    forcing the client to remarshal the request with the
    new target (the forwarded object reference"s key).
    With some already recommended changes to GIOP 1.1,
    such a reply will only require remarshaling the
    message header, but an extra roundtrip is still required.

    This could be avoided by addind a new service context
    to the reply that contains the forward IOR, or a new
    Reply type such as NO_EXCEPTION_AND_FORWARD that
    indicates the first request has succeeded and that
    subsequent requests can use the supplied forward IOR.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP Requests by hashing down operation names

  • Legacy Issue Number: 1132
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to
    be invoked as a string. If this can be compacting to
    an integral value, savings would be possible on all
    subsequent requests. A simple solution would involve
    a service context containing "operation name to index"
    mappings.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" st

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

GIOP encoding of nil Abstract Interface is unspecified

  • Legacy Issue Number: 2333
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 15.3.7 of 98-12-04 discusses the encoding of abstract
    interfaces, but neglects to mention how to encode an abstract
    interface whose value is nil.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    see above

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

Compacting GIOP Messages by using templates

  • Legacy Issue Number: 1131
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A common server pattern is that of "factory". As a result
    of a request, a Factory returns an object reference.
    Frequently, these object references differ only by a
    small fraction of their full size. For example, object
    references may be exactly the same except for the object_key
    member of a GIOP profile and maybe the repository_id field
    of the IOR. Allowing the factory to return a more compact
    representation of the object reference would yield great
    savings in message size.
    If the server or client can establish a template for filling
    out object references (or possibly any type of data), a
    more compact on-the-wire form can be used for such object
    references once the template is established.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this previously deferred issue as too much for RTF. Add to GIOP future version "wish list" do

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

Compacting GIOP messages by using indirections

  • Legacy Issue Number: 1130
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Repeated strings within an encapsulation can account
    for a large percentage of the size of the encapsulation.
    Indirections are already used in the marshaling of TypeCodes
    to allow compacting of messages. This can be extended
    to also allow indirection for strings. The current
    encoding of a string is the unsigned long number of characters
    in the string, followed by the null-terminated characters
    comprising the string. If we resolve the maximum value
    for unsigned long "0xffffffff" for indirections, the
    next byte can refer to a previously marshaled string.

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close previously deferred issue as too much for RTF. Add to GIOP future version "wish list".

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

Use of the type ComponentHome

  • Legacy Issue Number: 3645
  • Status: closed  
  • Source: Laboratoire d`Informatique Fondamentale de Lille ( Raphael Marvie)
  • Summary:

    1. In the document OMG ptc/99-10-04 p.69-329 there is in item 5 a use
    of the type ComponentHome, shouldn't it be CCMHome? If I do recall
    correctly, ComponentHome was used in the first versions of the
    specification proposal.

  • Reported: CPP 1.1 — Tue, 23 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    You are correct. ComponentHome should be CCMHome

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

USING Components::Enumeration

  • Legacy Issue Number: 3418
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    It is probably not a good idea to mandate an implementation for
    Enumeration, since there may be different options for implementing.
    For example, it may be desirable for
    performance reasons to implement a form of lazy Enumeration that does
    not carry with it every element that it can contain, but requiring
    this kind of implementation can be overkill for some
    applications. Given this, Enumeration is defined as an abstract
    valuetype and at least one concrete specialization of it is
    required. In addition, FOR INTEROPERABILITY, at least one STANDARD
    implementation must also be provided so that client stubs and server
    skeletons know how to marshal and unmarshal Enumeration values.

  • Reported: CPP 1.1 — Tue, 14 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolution see above

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

destroy() for local objects

  • Legacy Issue Number: 3236
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    every ORB I know of implements the various destroy() operations on
    local objects (such as policies or DynAny) as a no-op and destroys the local
    object on the final call to release() instead. Yet, the spec still requires
    programmers to call destroy(). The problem with this is that programmers
    can easily end up writing non-portable code without any visible problem.
    Then, when code is moved to another ORB, it is conceivable that it will
    leak objects.

    This isn't very pretty. I think we should get rid of the destroy() calls
    on local objects (possibly with the exception of the ORB object, although
    the entire shutdown issue for that is quite a mess anyway). It doesn't
    make sense to require the programmer to make a destroy() call for something
    that naturally can be reference counted.

  • Reported: CPP 1.1 — Wed, 19 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    When the interfaces identified in section 11.1.5 are updated to be local interfaces, any destroy() o

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

New IDL keywords

  • Legacy Issue Number: 3216
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    Problem: The new IDL keywords use mixed case, rather than the lower case style used by current keywords. Should the new keywords be changed to comply with the existing style?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Yes, new IDL keywords should be changed to conform to existing style guide.

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

Implementation of get_component

  • Legacy Issue Number: 3213
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    2. Implementation of get_component with separate ORB and component vendors
    Problem: A design goal of the components specification was to permit the component container to be provided by a different vendor than the ORB vendor. When this is true, how does the implementation of get_component work?

  • Reported: CPP 1.1 — Wed, 12 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    closed issue, resolved

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

CORBA IR METAMODEL

  • Legacy Issue Number: 3207
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    1) The isBasic Attribute needs to be removed from HomeDef to synchronize
    with the regular CORBA IR.

  • Reported: CPP 1.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

Is the ccm_home method shown in Table 8-1 a typo?

  • Legacy Issue Number: 3191
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Table 8-1 shows a mapping for CCMObject::get_home. It looks like it should
    say CCMObject::get_ccm_home

    Proposal:

    Change "CCMObject::get_home" to "CCMObject::get_ccm_home" in Table 8-1.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

How is CCMHome::get_home_def mapped to EJB operations?

  • Legacy Issue Number: 3190
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 omits to mention how the CCMHome::get_home_def call is mapped by
    the bridge at runtime to an EJB operation.

    Issue:
    The very similar call CCMHome::get_component_def is shown as mapped to the
    EJBHome.getEJBMetaData operation, but there is no mapping shown for
    CCMHome::get_home_def. It appears that get_home_def could be also be
    implemented using the EJBHome.getEJBMetaData operation, and if necessary,
    with the help of Java introspection.

    Proposal:
    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to
    EJBHome.getEJBMetaData.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Add a line in Table 8-1 to show CCMHome::get_home_def mapped at runtime to EJBHome.getEJBMetaData

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

What's the return type of CCM mappings of EJB finder and creator methods?

  • Legacy Issue Number: 3189
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Summary:

    8.2.1.2 of the CCM specification says that EJB finder and creator methods
    which return an RMI object reference are mapped to methods which return a
    Components::CCMObject reference. It is unclear whether the actual base
    class CCMObject is intended or whether the specific component subclass
    (e.g., Widget) is intended. The specific subclass seems more sensible,
    and is consistent with the equivalent IDL mappings shown in section 5.8.4.

    Proposal:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget)
    is the return type.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change 8.2.1.2 to make it clear that the specific subclass (e.g., Widget) is the return type

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

Do EJB-mapped attributes go to the ComponentDefault interface?

  • Legacy Issue Number: 3187
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    When mapping EJB set/get methods to a CCM view, it is not clear whether the
    resulting IDL attributes belong on the ComponentDefault interface or on the
    component definition itself

    Issue:
    Set/get method pairs on the EJB remote interface map to IDL attributes, but
    do these attributes end up in the XXXDefault interface or in the XXX
    component definition? Section 8.2.1.2 of the specification seems to imply
    they belong in the XXXDefault interface, but section 5.3.2 says the
    component definition for a basic CCM "shall only contain zero or more
    attribute declarations", which suggests that attributes of a CORBA
    Component belong in the component definition. Also, the mapping in the
    other direction (EJB view of a CCM), described in 8.3.1, suggests that CCM
    attributes are always found in the component definition itself. It appears
    that both versions will work, but this point is worth clarifying.

    Proposal:
    Change 8.2.1.2 to say that all EJB set/get method pairs are mapped to IDL
    attributes on the component definition itself.

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

CCM Issue: Is CCMObject::remove intended to be available to the CCM client?

  • Legacy Issue Number: 3183
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Section 5.12.1 of the spec can be interpreted to mean that the
    CCMObject::remove call is not intended for use by CCM clients; but this is
    inconsistent with the EJB/CCM mapping given in chapter 8.

    Issue:
    The explanation given for the CCMObject::remove call in section 5.12.1 is:
    "This operation is called when a component is about to be destroyed.
    The component
    can perform any cleanup processing required (e.g. releasing resources)
    prior to its
    destruction."
    This explanation can be interpreted to mean that the call is a private call
    from a CCM container to one of its components; if it has this internal
    purpose then it might not be
    intended for use by CCM clients wanting delete the component. However,
    table 8-1 shows that the CCM view of an EJB maps this call to the
    EJBObject.remove()
    method. This implies that the method is intended for client use as the
    EJBObject.remove() is. If so, then it also makes more sense to implement
    the
    CCMHome::remove() method in terms of the EJBObject.remove() method, rather
    than the current mapping which requires an EJB Handle.

    Proposal: (a) Change the text for remove() in 5.12.1 to say: "This
    operation is used to delete a component".
    (b) Change the mapping in table 8-1 for CCMHome::remove to use
    EJBObject.remove

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Change the text for remove() in 5.12.1 to say: "This operation is used to delete a component".

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

Small optimization for the GIOP header

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

    I think I found a possible (very minor) optimization for the
    GIOP 1.3 spec, but maybe I'm missing something in GIOP 1.2

    The new <target> field on the RequestHeader_1_2 structure is
    always aligned to a 4 byte boundary, the reserved[3] field ensures
    that. Consequently the discriminant for the TargetAddress union
    does not end on a 4 byte boundary, but will require 2 bytes of padding
    following it, since all the union values in this case start on 4 byte
    boundaries.

    IMHO, using just 1 byte for the reserved[] field, would have
    resulted in more natural alignments. Did I get something wrong here?
    Is this something likely to be fixed in GIOP 1.3?

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close this issue as too much of a change for this RTF, and add it to the GIOP wish list for future p

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

interop issue: CodeSets service context in GIOP 1.0 request

  • Legacy Issue Number: 3681
  • Status: closed  
  • Source: Xerox ( Bill Janssen)
  • Summary:

    Well, a new Java release is upon us, and with it comes a new CORBA
    implementation. I'm trying Java 2 SE 1.3 CORBA clients against an ILU
    2.0beta1 CosNaming server, and we find that the Java ORB cannot
    reliably connect to the server. Why not? First, we must analyze the
    IOR provided by the ILU service:

    IOR:000000000000002849444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578743A312E300000000002000000000000002F0001000000000016776174736F6E2E706172632E7865726F782E636F6D00270F0000000B4E616D6553657276696365000000000100000024000100000000000100000001000000140001001800010001000000000001010000000000

    If we look at this (those who've received it un-truncated) we find that it advertises the following:

    _IIOP_ParseCDR: byte order BigEndian, repository id <IDL:omg.org/CosNaming/NamingContext:1.0>, 2 profiles
    _IIOP_ParseCDR: profile 1 is 47 bytes, tag 0 (INTERNET), BigEndian byte order
    _IIOP_ParseCDR: profile 2 is 36 bytes, tag 1 (MULTIPLE COMPONENT), BigEndian byte order
    (iiop.c:parse_IIOP_Profile): bo=BigEndian, version=1.0, hostname=watson.parc.xerox.com, port=9999, object_key=<NameService>
    (iiop.c:parse_IIOP_Profile): encoded object key is <NameService>
    (iiop.c:parse_IIOP_Profile): non-native cinfo is <iiop_1_0_1_NameService@tcp_watson.parc.xerox.com_9999>
    (iiop.c:parse_MultiComponent_Profile): profile contains 1 component
    (iiop.c:parse_MultiComponent_Profile): component 1 of type 1, 20 bytes
    (iiop.c:parse_MultiComponent_Profile): native codeset for SHORT CHARACTER is 00010001, with 0 converters
    (iiop.c:parse_MultiComponent_Profile): native codeset for CHARACTER is 00010100, with 0 converters

    That is, there's a vanilla Internet profile (bo=BigEndian,
    version=1.0, hostname=watson.parc.xerox.com, port=9999,
    object_key=<NameService>), plus a Multicomponent profile, noting that
    the ILU ORB's native codesets are Latin-1 and UCS-2.

    OK, great. Now we get the first message from the Java ORB:

    0000 47 49 4f 50 01 00 00 00 00 00 01 00 GIOP........
    0000 00 00 00 02 00 00 00 01 00 00 00 0c 00 00 00 00 ................
    0010 00 01 00 20 00 01 01 00 00 00 00 06 00 00 00 90 ... ............
    0020 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    0030 6f 72 67 2f 53 65 6e 64 69 6e 67 43 6f 6e 74 65 org/SendingConte
    0040 78 74 2f 43 6f 64 65 42 61 73 65 3a 31 2e 30 00 xt/CodeBase:1.0.
    0050 00 00 00 01 00 00 00 00 00 00 00 54 00 01 01 00 ...........T....
    0060 00 00 00 0c 31 33 2e 31 2e 31 30 33 2e 36 38 00 ....13.1.103.68.
    0070 0e e9 00 00 00 00 00 18 af ab ca fe 00 00 00 02 ................
    0080 67 d5 93 95 00 00 00 08 00 00 00 00 00 00 00 00 g...............
    0090 00 00 00 01 00 00 00 01 00 00 00 14 00 00 00 00 ................
    00a0 00 01 00 20 00 00 00 00 00 01 01 00 00 00 00 00 ... ............
    00b0 00 00 00 05 01 00 00 00 00 00 00 07 53 79 6e 65 ............Syne
    00c0 72 67 79 00 00 00 00 06 5f 69 73 5f 61 00 00 00 rgy....._is_a...
    00d0 00 00 00 00 00 00 00 28 49 44 4c 3a 6f 6d 67 2e .......(IDL:omg.
    00e0 6f 72 67 2f 43 6f 73 4e 61 6d 69 6e 67 2f 4e 61 org/CosNaming/Na
    00f0 6d 69 6e 67 43 6f 6e 74 65 78 74 3a 31 2e 30 00 mingContext:1.0.

    Note that we are seeing a CodeSets service context, even though the
    request is GIOP 1.0. The service context specifies a TCS-C of ASCII,
    and a TCS-W of UCS-2.

    The question is, what should the server do with it?

    First of all, there seems to be no way in which the algorithm in
    section 13.2.7.6 can result in the TCS-C specified in the service
    context. So perhaps this bug should be detected and signalled back to
    the sending ORB. How? Using CODESET_INCOMPATIBLE might make sense,
    but that really doesn't flag the bug in the client-side implementation
    of the codesets determination algorithm. Perhaps a straight
    COMM_FAILURE would be better. Opinions?

    Secondly, since this is GIOP 1.0, the client could reasonably ignore
    the service context, and go ahead with using its default codeset
    (Latin-1). However, to do so risks comm failure down the line, as
    ASCII (the TCS-C assumed by the client) does not permit many Latin-1
    characters. It seems better to flag this situation up front.

  • Reported: CPP 1.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    close with revision. See below

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

Version and byte order changes when fragmenting messages (interop)

  • Legacy Issue Number: 3680
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    It's occoured to me that according to the spec it's allowable for
    a message to be fragmented and have second and subsequent
    fragments change the version fields.

    Having the version change while in the middle of reading a
    wstring could cause problems, the CDR encoding of version 1.1
    strings is always two bytes longer than the corresponding 1.2
    encoding, if the version changed while in the middle of reading
    the wstring the length field would be out by two.

    Secondly if request IDs are per-protocol rather than
    per-connection (as aired in issue 3438) then the request ids of
    the fragments could interfere.

    I think an extra phrase should be added to the spec with regards
    to fragmentation, similar to the one regarding byte order:

    The version of fragments must match the version of the initial message that
    the fragment extends.

  • Reported: CPP 1.1 — Fri, 16 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision since the spec was already clarified to state this.

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

Issue 2 -- resulting from UK comment UK-5:

  • Legacy Issue Number: 3624
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The UK believes the footnote to section 13.6.2, page 13-16, of CORBA
    2.3.1 (this is clause 5.6.2 with the footnote appearing on page 13 of
    DIS 19500-2) does not make sense, especially the phrase "... except
    ones that make such profiles...". The meaning of this footnote needs
    to be clarified with revised text.

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close without revision.

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

Issue 1 -- resulting from Japanese comment JPN-009E:

  • Legacy Issue Number: 3623
  • Status: closed  
  • Source: Object Management Group ( Henry Lowe)
  • Summary:

    The Japanese would like to clarify the first sentence of the first
    paragraph of section 15.5.2, page 15-46, of CORBA 2.3.1 (this
    is clause 6.4.2 of DIS 19500-2, page 70) by adding the phrase
    "if Bi-Directional GIOP is not used" to the end of the sentence.
    The resulting sentence would read "Only the client (connection
    originator) may send Request, LocateRequest, and CancelRequest
    messages if Bi-Directional GIOP is not used."

    Is there any reason not to add this phrase now that Bi-Directional
    is in the OMG specification?

  • Reported: CPP 1.1 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree that this was an editorial oversight in corba 2.3.

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

wchar alignment in GIOP 1.2

  • Legacy Issue Number: 4007
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    I have a question on the octet alignment requirement for wchar as
    mentioned in Table 15-1 of CORBA 2.3. In 15.3.1.6 the spec states that

    "For GIOP version 1.2, wchar is encoded as an unsigned binary octet
    value followed by the octet sequence representing the encoded value of
    the wchar. The initial octet contains a count of the number of elements
    in the sequence and the elements of the sequence of octets represent the
    wchar, using the negotiated wide character encoding"

    If this is a variable length octet sequence anyway, specifying an octet
    alignment for this does not make sense. Our assumption is that alignment
    is specified only for GIOP 1.1 style wchars and is irrelevant for
    GIOP 1.2 style wchars. I am looking for confirmation of that assumption.

    If that is a valid assumption, shall we change the table 15.1 third row
    first column entry to state "wchar (in GIOP 1.1)" instead of "wchar"?

    If that is not a valid assumption, what are we aligning here? The length
    byte? The elements of octet sequence? What is the benefit of any
    aligning in this case?

  • Reported: CORBA 2.4 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Close with revision

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

Is padding necessary for empty Reply body?

  • Legacy Issue Number: 3792
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The Interop RTF added text that explicitly states that padding for a
    Request body in GIOP 1.2 is not necessary if the body is empty. No
    equivalent text was added for empty GIOP 1.2 Reply bodies.

  • Reported: CPP 1.1 — Fri, 25 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Agree to add equivalent text for reply bodies.

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

GIOP _get_domain_managers ambiguous

  • Legacy Issue Number: 3787
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In GIOP, the _get_domain_managers operation name is used to indicate
    an invocation of the get_domain_managers pseudo operation. OTOH, it is
    also used if an attribute domain_managers is accessed, as it would
    appear in

    interface I

    { readonly attribute long domain_managers; }

    ;

  • Reported: CPP 1.1 — Fri, 18 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Changing the object reference operation on the wire to _domain_managers fixes the problem stated.

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

CCM Issue: How are standard EJB exceptions mapped into the CCM View

  • Legacy Issue Number: 3182
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Chapter 8 of the spec specifies mappings between EJB operations and their
    equivalents in the CCM view, but it leaves the mappings of standard EJB
    exceptions unclear.

    Issue:
    Create methods on an EJB home interface all throw the standard
    javax.ejb.CreateException; finder methods on the EJB home interface all
    throw the javax.ejb.FinderException; and remove methods on both home and
    remote interfaces all throw the javax.ejb.RemoveException. In a few cases
    chapter 8 gives an implied mapping: for example, the FinderException on the
    findByPrimaryKey method seems to map to either the
    Components.UnknownKeyValue exception or to the Components.InvalidKey
    exception on the equivalent find_by_primary_key CCM method. Even in these
    cases the names are sometimes inappropriate. In the majority of cases,
    however, there is simply no CCM equivalent to the EJB exception, and bridge
    implementors are left to wonder whether they should attempt a non-standard
    mapping.

    Proposal:
    (a) Add the new CCM standard exceptions Components.CreationFailure,
    Components.NotFound, and Components.RemovalFailure
    (b) Add Components.CreationFailure to the raises clause of all create
    methods on implicit and explicit home interfaces
    (c) Add Components.NotFound to the raises clause of
    find_by_primary_key on implicit home interfaces, and to the raises clause
    of all finder methods on explicit home interfaces
    (d) Add Components.RemovalFailure to the raises clause on the remove
    operation on implicit home interfaces, to the CCMObject.remove operation,
    and to the CCMHome.remove_component operation
    (e) Specify in chapter 8 that the EJB Finder exception is always
    mapped to Components.CreationFailure; that the EJB CreateException is
    always mapped to Components.CreationFailure; and that the EJB
    RemoveException is always mapped to Components.RemovalFailure.
    (f) Make explicit in chapter 8 the already implied mapping bewteen the
    EJB DuplicateKeyException and the Components.DuplicateKeyValue exception

  • Reported: CPP 1.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    No Data Available

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

Should Components::Enumeration be an IDL interface or an IDL abstract value

  • Legacy Issue Number: 3099
  • Status: closed  
  • Source: International Business Machines ( Mr. Ignacio Silva-Lepe)
  • Summary:

    Summary: Section 8.2.1.2 of the spec defines Components::Enumeration as an
    IDL interface, with the implication
    that it is intended as a remote type.

    Issue: It has been noted that java.util.Enumeration is usually implemented
    as a java.io.Serializable and that making
    Components::Enumeration an IDL interface would prevent this from happening
    for collections of primary keys returned
    from EJB Homes that are mapped to CCM Homes.

    Proposal: Define Components::Enumeration as an IDL abstract valuetype.

  • Reported: CORBA 2.3.1 — Wed, 8 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Define Components::Enumeration as an IDL abstract valuetype

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

CCM Issue: Is a home needed?

  • Legacy Issue Number: 3066
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    Summary: The CCM FTF IDL chapter does not state whether a home must be
    declared for a component. A home must have a component, but must a
    component have a home?

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    A component must have a home

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

Components Issues - Interface Repository ptc/99-10-03

  • Legacy Issue Number: 3063
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the interface repository chapter 10 need to be fixed.

    1. In IDL for interface HomeDef on Page 52 and Page 88:
    Remove the line: readonly attribute boolean is_basic;
    2. In IDL for struct HomeDescription on Page 52 and Page 88:
    Remove the line: boolean is_basic;
    3. In section 10.5.38.1 on page 53: Remove the paragraph that begins with:
    "The is_basic attribute is TRUE if this is a basic home......."

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Since there is no basic and extended distinction for homes as there is for components, change text a

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

Components Issues - Chapter 61 ptc/99-10-04

  • Legacy Issue Number: 3060
  • Status: closed  
  • Source: Oracle ( Ed Cobb)
  • Summary:

    The following errors in the component model chapter 61 need to be fixed as
    follows to align the IDL in the text with the final IDL published in
    Appendix A (orbos/99-08-08).
    1. In IDL on page 46, section 61.6.3 add a “;” after expected_event_type.
    2. In IDL on page 43, section 61.5.3 replace
    ConnectionList get_connections (in FeatureName name)
    raises (InvalidName);
    with
    ConnectedDescriptions get_connections (in FeatureName name)
    raises (InvalidName);
    3. In IDL on page 68, section 61.10.1.2 replace
    valuetype ConfigValue

    { FeatureName name; any value; }

    ;
    with
    valuetype ConfigValue

    { public FeatureName name; public any value; }

    ;

  • Reported: CORBA 2.3.1 — Mon, 22 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    resolved

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

implementing import for C++

  • Legacy Issue Number: 2973
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    I'm concerned that for C++, implementing "import" as currently specified in
    the Components spec will be extremely difficult.

    Imagine how you might implement this: your IDL compiler generates a C++
    header file for all imported name scopes and creates #include directives
    for these files in the C++ code generated for the main IDL file. The main
    problem is that importable name scopes are modules, interfaces, valuetypes,
    structures, unions, and exceptions. To import an exception, for example,
    the import mechanism would have to keep a dependency graph for that
    exception type and make sure that all dependencies are generated into the
    header file so the C++ compilation won't fail. This seems way too complex,
    and I don't see the value of being able to import individual structs and such.

  • Reported: CORBA 2.3.1 — Fri, 29 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4.2
  • Disposition Summary:

    Remove structure, union and exception from the list of name scopes (and repository ids) that can be

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

Policies not locality-constrained?

  • Legacy Issue Number: 2611
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the current spec doesn"t list policy objects as locality constrained.
    This seems rather strange. In particular, at the time I create policy objects,
    there is no POA that could be responsible for them, and I have no way
    to associate a policy object with a particular POA.
    Of course, this raises the question of whether references to policy objects
    are persistent or transient, whether I can pass them to another address
    space, whether requests on them are single-threaded or not, etc, etc.

  • Reported: CPP 1.0 — Fri, 16 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close, no change (for 2.4).

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

Locality-constrained objects

  • Legacy Issue Number: 2301
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: something about locality-constrained objects... The spec says that LC objects
    are local, so I cannot pass reference to another process or use
    object_to_string with them. There are no other restrictions so, by
    implication, LC objects can do everything a normal object can do. In paricular,
    I can invoke operations on LC objects via the DII, I get preinvoke and
    postinvoke calls from a servant locator, and the reference for an LC object
    and its servant have independent life cycles.

    This seems rather strange.

  • Reported: CORBA 2.2 — Sun, 10 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    close, no change

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

Locality constrained objects + externalization

  • Legacy Issue Number: 2204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here"s an interesting question. How do you prevent the externalization of
    an l-c object? The user can create a reference to the l-c object before
    the l-c object has been bound to the POA itself. This means that the
    reference can be externalized, and calls could presumably come into
    the POA for this l-c object. What should the result of this call be?
    OBJECT_NOT_EXIST?

  • Reported: CORBA 2.2 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    issue closed, no change

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

Nested Recursive Structs Legal in 2.3.x?

  • Legacy Issue Number: 3764
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    Given the IDL below, is the third case (labeled "Nested Recursive
    Case") legal in CORBA 2.3.x? (I understand that the answers to my questions
    may change in 2.4: I am interested in possible flaws in 2.3 at the moment).
    If it is legal, I have some concerns listed after the IDL:

    //IDL
    module recurse
    {
    //Recursive Struct: This is legal
    struct TestStruct1

    { sequence<TestStruct1> list; }

    ;
    // Nested Struct: This is legal
    struct TestStruct2 {
    struct TestStruct3

    { long threeMember; }

    twoMember;
    };
    // Nested Recursive Case: IS THIS LEGAL?
    struct One {
    struct Two

    { sequence<One> twoMember; }

    oneMember;
    };
    };

    1) If this IDL is loaded into an IFR, and the type() method of the StructDef
    for ::recurse::One::Two is called, what should happen? I can think of at
    least three interpretations of the spec (in particular, section 10.5) :

    a) type() should fail since the TypeCode for Two is not valid
    outside of the definition of One. If this is the case, what should it
    throw? (the natural result of many implementations would be MARSHAL, but
    that seems wrong)

    b) type() should succeed and should include a complete, valid
    TypeCode of the form:

    //BEGIN TYPECODE//
    Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Struct_tc(One)
    MemberList
    StructMember
    oneMember,
    TypeCode: Recursive_tc("IDL:recurse/One/Two:1.0")
    //END TYPECODE//

    c) type() should succeed and should include a complete, valid
    TypeCode of the form:

    //BEGIN TYPECODE//
    Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Struct_tc(One)
    MemberList
    StructMember
    oneMember,
    TypeCode: Struct_tc(Two)
    MemberList
    StructMember
    twoMember,
    TypeCode: Recursive_tc("IDL:recurse/One:1.0")
    //END TYPECODE//

    2) Similarly, what should the behavior be when the type() method on the
    generated structs (or their Helper classes in Java) are called? In
    particular, at what point is the ORB responsible for "embedding" the
    recursive TypeCode in its enclosing TypeCode as specified by section 10.7.3
    "Creating TypeCodes"?

    For example, given the following code (in Java, but applied to other
    languages):

    TypeCode recursiveTC = orb.create_recursive_tc("IDL:recurse/One:1.0");

    org.omg.CORBA.StructMember[] members = new
    org.omg.CORBA.StructMember[1];
    members[0] = new org.omg.CORBA.StructMember("twoMember",
    _orb().create_sequence_tc(0, recursiveTC), null);
    /1/ TypeCode twoType = _orb().create_struct_tc(id(), "Two", members);

    members = new org.omg.CORBA.StructMember[1];
    members[0] = new org.omg.CORBA.StructMember("oneMember", twoType,
    null);
    /2/ TypeCode oneType = _orb().create_struct_tc(id(), "One", members);

    If 1 attempted to resolve the recursive TC, it would fail.
    If 2 attempted to resolve the recursive TC, it would succeed, but would
    have to traverse all of twoType's members to see if there was a recursive TC
    in there.

    Any other thoughts on this issue would be appreciated.

  • Reported: CORBA 2.3.1 — Tue, 25 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

incomplete rules for forward declaration of structs/unions

  • Legacy Issue Number: 3751
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • Summary:

    1. The phrase "the only recursion permitted for constructed types with the exception of value types" is confusing: a) valuetypes are not constructed types b) the definition of a valuetype may indeed be recursive, but then so can interfaces - why are these not mentioned? Are you trying to say something specific with regard to valuetypes?

    2. The cross reference in the first example should be 3.10.7 not 3.10.3.

    3. Why does the second paragraph on page 3-38 insist that a forward declared definition must follow "in the same source file"? While this is sensible I do not see the point in enforcing it (there is a separate rule about repository IDs which has a bearing). I couldn't find a statement requiring completion of forward interface and valuetype declarations to compare with - I have always assumed these must be satisfied too.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

read_fixed() and write_fixed() methods missing

  • Legacy Issue Number: 3799
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    The org.omg.CORBA.DataInputStream and
    org.omg.CORBA.DataOutputStream do not define read_fixed() and
    write_fixed() methods. To enable custom marshalling/unmarshalling
    of the fixed data types, these methods should be added to the
    above classes.

  • Reported: CORBA 2.3.1 — Thu, 31 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Initializers and user exceptions

  • Legacy Issue Number: 3781
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    The IDL grammar does not allow valuetype initializers to be declared
    as raising user exceptions, which seems like a potentially useful thing
    to do. Was this possibility considered and rejected for some reason?

  • Reported: CORBA 2.3.1 — Wed, 9 Aug 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No won for B above so this issue is closed no change.

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

IDL: Clashes with inherited identifiers

  • Legacy Issue Number: 3768
  • Status: closed  
  • Source: AT&T ( Duncan Grisby)
  • Summary:

    Is the following IDL legal?

    interface A

    { void B(); }

    ;
    interface B : A {};

    Interface B has an inherited operation named B. Whether it is legal or
    not depends on whether the inherited operation is considered "defined"
    within interface B.

    This issue is subtly different from the discussions in issue 3525.
    Operations and attributes are more strongly "introduced" into the
    inherited interface than type declarations are, since inherited type
    declarations can be overridden, but operations and attributes cannot.

    I think the IDL specification should be clarified to state whether the
    above IDL is legal or not.

  • Reported: CORBA 2.3.1 — Mon, 31 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

Should POA spec examples use string_to_ObjectId?

  • Legacy Issue Number: 3918
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    As I understand things, string_to_ObjectId is an artifact of the
    C++ POA mapping. It certainly isn't defined in the core POA spec.
    However, some of the example code in the POA spec uses this routine.
    Is this kosher? Shouldn't the relevant examples at least have a
    cross-reference to the C++ mapping?

  • Reported: CORBA 2.3.1 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change

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

Values for CORBA::ARG_IN,... not defined

  • Legacy Issue Number: 3905
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    This is a core issue.

    formal/99-10-07 (and orbrev/00-09-01) section 7.1.1 claims
    arg_modes is a bit mask with CORBA::ARG_IN, ... as possible values.
    The values are not defined in that document.

    The values defined in ptc/00-01-08 (IDL to Java mapping)
    section 1.19.4 do not look like bit masks:

    typedef unsigned long Flags;
    const Flags ARG_IN = 1;
    const Flags ARG_OUT = 2;
    const Flags ARG_INOUT = 3;
    const Flags CTX_RESTRICT_SCOPE = 15;

    This needs clarification (e.g., how wide is the bit mask, what
    are the values, or, if not a bit mask, a better definition).

  • Reported: CORBA 2.3.1 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

module IOP_N needs a real name

  • Legacy Issue Number: 3877
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The interceptors specification, ptc/00-08-06, defines:

    IOP_N

    Issue: "_N" needs to be replaced with the correct version such that
    this module has a real name.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

"omg.org" prefix missing from interceptor specification and its reference

  • Legacy Issue Number: 3862
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The specification, ptc/00-08-06, defines the following modules:

    Dynamic
    IOP_N
    PortableInterceptor

    These modules reference the following modules:

    CORBA
    IOP
    Messaging

    The CORBA 2.4 specification, orbrev/00-09-01, only explicitly specifies:

    #pragma prefix "omg.org"

    for:

    DynamicAny (page 196)
    CORBA, the Interface Repository Case, (p 280)
    PortableServer (page 338)

    and the Messaging specification, orbos/98-05-05, specifies the prefix
    for messaging.

    ----------

    Proposed solution:

    Either explicitly add

    #pragma prefix "omg.org"

    before Dynamic, IOP_N, PortableInterceptor, CORBA (in general), and IOP

    OR

    Change, the second paragraph of 10.6.7 RepositoryIDs for OMG-Specified Types
    (page 270)

    from:

    "All official OMG IDL files shall contain the following pragma prefix
    directive:

    #pragma prefix "omg.org"

    unless said file already contains a pragma prefix identifying the
    original source of the file (e.g., "w3c.org")."

    to:

    "All official OMG IDL modules shall contain the following pragma prefix
    directive:

    #pragma prefix "omg.org"

    unless said file already contains a pragma prefix identifying the
    original source of the module (e.g., "w3c.org")."

    ----------

    Discussion:

    Perhaps we can interpret 10.6.7 above to mean already mean the all
    official OMG modules have the "omg.org" prefix. In that case, there
    is no issue.

  • Reported: CORBA 2.3.1 — Tue, 19 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The last sentence of the summary states the way things are, so there really is no issue here

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

ORB ID accessor

  • Legacy Issue Number: 3817
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    ORB_init allows me to specify an ORB ID, but there is no way to get that
    ORB ID back from an ORB. It seems wrong to force people to specify an
    object identity during object creation but to not allow access to that
    identity later.

    I would suggest to add an accessor to the ORB interface:

    interface ORB

    { ORBid id(); // ... }

    ;

  • Reported: CORBA 2.3.1 — Fri, 8 Sep 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the proposed accessor to ORB.

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

ValueMemberDef section omitted from CORBA 2.3.1 spec

  • Key: CORBA24-85
  • Legacy Issue Number: 3560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the CORBA 2.3.1 99-10-07.pdf spec, where "The Interface Repository
    chapter has been updated based on CORE changes from
    ptc/98-09-04 and the Object by Value documents (orbos/98-01-18 and
    ptc/98-07-06).", ValueMemberDef is not fully documented.

    ValueMemberDef should have it's own section in the Interface Repository
    chapter but it does not. This would contain it's IDL and at least two
    subsections, one for the read interface and one for the write interface.

  • Reported: CORBA 2.3.1 — Thu, 13 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Missing section should be filled in

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

Inheritance description incorrect

  • Key: CORBA24-84
  • Legacy Issue Number: 3525
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 3-46, CORBA 2.3, we have some old words that got forgotten during
    the scope resolution rule cleanup we did some time ago:

    Inheritance produces shadow copies of the inherited identifiers;
    that is, it introduces names into the derived interface, but these
    names are considered to be semantically the same as the original
    definition. Two shadow copies of the same original (as results
    from the diamond shape in Figure 3-1 on page 3-21) introduce a
    single name into the derived interface and don't conflict with
    each other.

    That's wrong because it confuses visibility of an identifier with introduction
    of an identifier (which are different things). I would suggest to reword
    as follows:

    Inheritance produces shadow copies of the inherited identifiers;
    that is, inherited identifiers are visible in derived interfaces.
    Such identifiers are considered to be semantically the same as
    the original definition. Two shadow copies of the same original (as
    results from the diamond shape in Figure 3-1 on page 3-21) do
    not conflict with each other.

    This simply gets rid of the word "introduces", which has the wrong meaning.

    Note that these words have been wrong all along, even before we changed
    the name lookup rules. That's because, if inherited identifiers were
    indeed introduced into the derived interface, the following would be illegal
    (but has in fact never been illegal):

    interface B

    { typedef string S; }

    ;

    interface D : B

    { typedef long S; }

    ;

  • Reported: CORBA 2.3.1 — Fri, 31 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as suggested below

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

ORB mediation for servant managers, references for servant managers?

  • Key: CORBA24-83
  • Legacy Issue Number: 3460
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Two questions:

    1) Are calls to operations on servant managers mediated by the ORB?

    2) Is it legal to export the object reference for a servant manager
    to another process?

    For question 1, the answer would appear to be no. Here is why:

    Page 11-17:

    Inactive state

    When a POA manager is in the inactive state, the associated POAs
    will reject new requests. [...] If the client is co-resident in
    the same process, the ORB could raise the OBJ_ADAPTER system
    exception, with standard minor code 1, to indicate that the
    object implementation is unavailable. [...]

    If the transition into the inactive state is a result of calling
    deactivate with an etherealize_objects parameter of

    • TRUE - the associated POAs will call etherealize for
      each active object associated with the POA once all
      currently executing requests have completed processing
      (if the POAs have the RETAIN and USE_SERVANT_MANAGER
      policies). If a servant manager has been registered for
      the POA, the POA will get rid of the object. If there
      are any queued requests that have not yet started
      executing, they will be treated as if they were new
      requests and rejected.

    If calls to servant managers were to be ORB-mediated, the calls to
    etherealize() cannot possibly be dispatched because the corresponding
    servant manager is already in the inactive state. The only logical conclusion
    I can see is that calls to servant managers are not mediated by the ORB.

    I think the spec should be updated to state this.

    For question 2, the answer would also appear to be no:

    Exporting a reference to a servant manager outside my own address space
    makes no sense whatsoever. Here a servant manager offers either
    incarnate() and etherealize(), or it offers preinvoke() and postinvoke().
    These are the only operations that are possible (apart from operations
    on Object). If it were possible to export a reference to a servant
    manager to another address space, there is nothing the receiver of
    the reference could do with it (other than call operations on Object).
    That's because incarnate(), etherialize(), and preinvoke use a native
    type (servant). postinvoke() doesn't use a native type, but
    accepts a parameter of type POA, so postinvoke cannot be invoked
    remotely either (because POA is locality constrained and its
    reference cannot be marshaled).

    So, it appears clear that export of servant manager references should be
    illegal and flagged the same way as an attempt to export a POA manager
    reference.

    The spec currently says this about servant managers:

    A ServantManager object must be local to the process containing
    the POA objects it is registered with.

    Contrast this with POA managers, for which the spec says:

    A POAManager object must not be exported to other processes,
    or externalized with ORB::object_to_string. If any attempt is
    made to do so, the offending operation will raise a MARSHAL
    system exception. An attempt to use a POAManager object with
    the DII may raise the NO_IMPLEMENT exception.

    To me, it looks like we should say the same thing for servant managers as
    for POA managers.

    And, by the same reasoning, I think it also must be said for the
    AdapterActivator interface: it doesn't make sense to marshal a reference
    for an adapter activator because the only operation (unknown_adapter) has
    an in parameter of type POA, which cannot come from a remote location.

  • Reported: CORBA 2.3.1 — Tue, 28 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Merge into Issue 4264 and close this with the resolution of 4264.

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

Policy Management in the ORB core

  • Key: CORBA24-92
  • Legacy Issue Number: 3614
  • Status: closed  
  • Source: foxfield-sw.demon.co.uk ( Nick Sharman)
  • Summary:

    (All document refs to ptc/00-03-02, but I think the relvant sections are the
    same in ptc/00-04-05)

    (a) Sec. 4.3.7.1 (Object::get_policy) says that the "effective Policy is the
    intersection of the values allowed by the effective override and the
    IOR-specified Policy." What does this mean? For example, the example
    MyPolicy given in 4.8.5 appears to define some range or interval, so the
    intersection of two MyPolicy objects has some meaning - but I doubt if it's
    reasonable to expect the ORB to deduce that.

    I suggest that the effective policy is:

    • any override of that type if there is one, else
    • any IOR-specified policy of that type if there is one, else
    • the system default of that type if there is one, else
    • the null Policy reference (or a system exception? which?).

    This is feasible and consistent with normal meaning of "override" as
    "replace", not "modify".

    (b) Sec. 4.3.7.2 (Object::get_client_policy) suggests that the ORB searches
    the object's overrides, then PolicyCurrent's overrides, then PolicyManager's
    overrides. If it can't find any in those, then it can return the system
    default. I suggest the system default be left out of this search - it's not
    an override, it's a final default - and that we define what happens if no
    policy of the right type can be found, either null or a system exception.

    (c) Sec. 4.3.8.1 (Object::set_policy_overrides) and sec. 4.9.3.1
    (PolicyManager::set_policy_overrides) both allow the existing set of
    overrides either to be replaced or to be extended.

    If the set is to be extended, and the new overrides contain a Policy of a
    type for which there is already an override, should the supplied Policy
    (1) replace the existing Policy silently, or
    (2) be ignored silently, or
    (3) cause a system exception (and which)?

    Whatever the value of 'set_add', if the supplied Policy list contains two
    Policies of the same type, which one prevails, if any? I suggest
    "implementation defined", but we could mandate a system exception.

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

Some problems

  • Key: CORBA24-91
  • Legacy Issue Number: 3612
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I thought there are some error in Grammer which number are (24) and (27).
    The grammer which number is 24 in specification is
    <init_param_decls> ::= <init_param_decl>

    { "," <init_param_decl> }

    I thought it may be <init_param_decls> ::= <init_param_decl> { "," <init_param_decl> }

    *
    Can you see asterisk?

    And grammer number 27 is miss-printing.

    It is all of my question in grammer and next problem is in Preprocessing.
    User can use #include for source inclusion.
    But in case of C++, there are two kind of source inclusion. One is standard library inclusion using angle brackets.
    Another is using quotation mark.
    Is the rule adapted in IDL preprocessor?
    Could you send me a document about Preprocessing rule?

    Another question is #ifdef, #ifndef.
    Is this option able to be duplicated?

    Last question is about position of inclusion command.
    In some example in specification 2.3, I find this example.

    module M

    { #include <E.idl> }

    ;

    • from CORBA V2.3, June 1999, 10-43

    The source inclusion command - #incude - is in module block.
    How that source will be compiled and mapped?
    I thought that source is wrong....

  • Reported: CORBA 2.3.1 — Mon, 15 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change with explanation as above.

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

ORB shutdown vs destroy

  • Key: CORBA24-90
  • Legacy Issue Number: 3608
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    CORBA2.3.1 section 4.11.5 destroy() has following information.

    Once an ORB is destroyed, another call to ORB_init with same ORBid will
    return a reference to a newly constructed ORB.

    My assumption here is if I call shutdown() on an ORB followed by
    ORB_init() with the same ORBid as of the shutdown ORB, I get the same
    ORB back. Essentially, we can not get rid of that ORB until destroy() is
    called. Is this a valid assumption? If so, can we add a sentence to that
    effect to shutdown() section?

  • Reported: CORBA 2.3.1 — Fri, 12 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

With reference to forward declarations of structs and unions.

  • Legacy Issue Number: 3749
  • Status: closed  
  • Source: ICL ( Trevor Nash)
  • Summary:

    Clause 48 <constr_type_spec> in the syntax has been modified to include a choice <constr_forward_decl>. This does not in fact allow things like struct a; though that is the obvious intention. But it does allow bizarre stuff such as typedef struct a, array_of_a[100]; which IMHO should not be legal (I am not that keen on typedef struct a b

    I think this choice should be deleted from clause 48 and inserted in clause 42 <type_dcl> instead.

  • Reported: CORBA 2.3.1 — Sat, 8 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

There is inconsistency in the POA.IDL and description in section 11.3.8.19

  • Legacy Issue Number: 3743
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    There is inconsistency in the POA.IDL and description in section 11.3.8.19
    in formal/99-10-07.pdf.

    According to poa.idl the signature for create_reference_with_id is:

    Object create_reference_with_id ( in ObjectId oid,
    in CORBA::RepositoryId intf )
    raises (WrongPolicy);

    whereas, section 11.3.8.19 completely omits this exception in the
    signature and does not even describe under what condition it is raised.

  • Reported: CORBA 2.3.1 — Fri, 14 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The POA IDL should be fixed by removing the raises(WrongPolicy) clause

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

description of unknown_adapter

  • Legacy Issue Number: 3740
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    2. According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.3.2
    description of unknown_adapter, indicates that:
    " The implementation of this operation should either create the specified
    POA and return TRUE, or it should return FALSE. If the operation returns TRUE,
    the ORB will proceed with processing the request. If the operation returns
    FALSE,
    the ORB will return OBJECT_NOT_EXIST to the client."

    In Section 11.3.8.3, find_POA specifies the following:

    "If a child POA with the specified name does not exist and the value of
    the activate_it parameter is TRUE, the target POA's AdapterActivator,
    if one exists, is invoked, and, if it successfully activates the child POA,
    that child POA is returned. Otherwise, the AdapterNonExistent exception is
    raised."

    Since find_POA itself invokes the unknown_adapter() method on the
    AdapterActivator.
    If the unknow_adapter() returns false, the find_poa() should throw an
    OBJECT_NOT_EXIST exception. This is not very clear from explanation in
    section 11.3.8.3.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clearly the current text potentially leads readers astray, so clarify it as shown below:

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

reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy

  • Key: CORBA24-99
  • Legacy Issue Number: 3739
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    1. According to CORBA V2.3 spec, 99-10-07.pdf, section 11.3.8.22,
    reference_to_servant raises ObjectNotActive, WrongAdapter, and WrongPolicy
    exceptions.

    This is inconsistent with the method signature specified in the poa.idl (section
    11.4). According to the idl the reference_to_servant raises only
    ObjectNotActive and WrongPolicy exceptions.

    It is requested that the signature of reference_to_servant in poa.idl be changed
    to match the description in section 11.3.8.22.

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix the editorial error

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

Missing exception for activation

  • Key: CORBA24-98
  • Legacy Issue Number: 3738
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For explicit activation, the spec says:

    11.3.8.15 activate_object

    ObjectId activate_object(in Servant p_servant)
    raises (ServantAlreadyActive, WrongPolicy);

    This operation requires the SYSTEM_ID and RETAIN policy; if not
    present, the WrongPolicy exception is raised.

    And:

    11.3.8.16 activate_object_with_id

    void activate_object_with_id(
    in ObjectId oid,
    in Servant p_servant)
    raises (ObjectAlreadyActive, ServantAlreadyActive, WrongPolicy);

    This operation requires the RETAIN policy; if not present, the
    WrongPolicy exception is raised.

    Neither section says that IMPLICT_ACTIVATION would be required.

    The intent for IMPLICIT_ACTIVATION was that it permits implicit activation
    as well as explicit activation. However, I can infer this only by reading
    between the lines. In particular, in section 11.2.7, the intent is never
    made clear.

    I would suggest to change the the text in section 11.2.7 from:

    When a POA supports implicit activation, an inactive servant may
    be implicitly activated in that POA by certain operations that
    logically require an Object Id to be assigned to that servant.
    Implicit activation of...

    to read:

    When a POA supports implicit activation, an inactive servant may
    be implicitly activated in that POA by certain operations that
    logically require an Object Id to be assigned to that servant.
    (IMPLICIT_ACTIVATION does not disallow explicit activation; instead,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    it enables both implicit and explicit activation.)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Implicit activation of...

  • Reported: CORBA 2.3.1 — Wed, 5 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The proposed clarification is in order.

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

AbstractBase not declared.

  • Key: CORBA24-97
  • Legacy Issue Number: 3737
  • Status: closed  
  • Source: Département Informatique & Réseaux ( Thomas Quinot)
  • Summary:

    The standard IDL files included in the corba/ subdirectory
    of the IDL text files archive, formal/00-04-01, should be compilable
    with any compliant IDL parser. Most notably, these files comprise
    a "corba/orb.idl" source file, whose inclusion in application
    IDL files is necessary whenever an application has to manipulate
    type CORBA::TypeCode (as mandated by section "3.14 CORBA module"
    of the CORBA specification v. 2.3).

    It is thus expected that the file corba/orb.idl be a legal
    IDL specification.

    This is not the case, because the corba/orb.idl files #includes
    a CORBA_Stream.idl file, which contains the following declaration:

    abstract valuetype DataOutputStream

    { [...] void write_Abstract (in AbstractBase value); [...] }

    In this declaration, the syntax of the language imposes that
    the name AbstractBase be interpreted as a <scoped_name>.
    This <scoped_name> is not defined in corba/orb.idl or any of
    the files it #includes.
    The declaration is therefore illegal.

    According to the CORBA 2.3 specification, section
    "4.2 The ORB operations", module CORBA contains a declaration
    "native AbstractBase".

    The following resolution is therefore proposed for this issue:

    In file corba/orb.idl, include the followinf declaration:

    native AbstractBase; // Chapter 4

  • Reported: CORBA 2.3.1 — Tue, 4 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Declaration of native AbstractBase needs to be added to orb.idl as stated above.

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

POA deactivate_object description is ambiguous

  • Key: CORBA24-82
  • Legacy Issue Number: 3449
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    CORBA 2.3.1 section 11.2.8.17 states that "An ObjectId which has been
    deactivated continues to process requests until there are no active
    requests for that ObjectId"

    In the short window where deactivate_object is called but object is not

    yet deactivated, the above sentence is open to interpretation. The 2
    interpretation are:

    1. Active requests are those requests that came before
    deactivate_object was called. In this case, POA continues to service
    those requests and throws OBJECT_NOT_EXIST for future requests if the
    object is not activable.

    2. Active requests are any requests. In this case, POA will continue
    to service requests that come even after deactivate_object was called
    as long as deactivation is not complete.

    So what is the intended interpretation? I suspect it is 1. If so, can we

    make this section clearly state that?

  • Reported: CORBA 2.3.1 — Thu, 23 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

how are valid ORBids determined

  • Key: CORBA24-81
  • Legacy Issue Number: 3443
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Section 4.5.1 of the CORBA core document explains the ORBid argument to
    ORBinit. However, it is sufficiently vague to present implementation and
    usage problems.

    It says:

    "All ORBid strings other than the empty string are allocated
    by ORB administrators and are not managed by the OMG."

    It fails to define ORB administrator. This administrator could be the
    developer of the application calling the ORB, or it could be the
    administrator of the machine on which the ORB will run, or it could be the
    developer of the ORB itself. Each answer to this question may result in a
    different mechanism for determining if a supplied ORBid is valid.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate change and close issue

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

POA namespace and ORB ID

  • Key: CORBA24-80
  • Legacy Issue Number: 3441
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    Section 4.6 of CORBA 2.3.1 addresses the meaning of the ORBid argument. It is clear
    that ORB_init can be called multiple times in the same address space resulting in
    different ORBs. I think the CORBA spec should make it clear that all of these ORBs
    have different POA namespaces. This should probably be indicated in section 11.2.3
    by stating something like:

    If an application makes use of multiple ORBs in the same address space, each
    ORB defines its own separate POA namespace. In particular, each ORB returns a
    distinct root POA in response to a resolve_initial_references( "RootPOA" )
    call.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarifying sentence is justified.

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

servant_to_id versus servant_to_reference

  • Key: CORBA24-94
  • Legacy Issue Number: 3636
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    This operation requires the USE_DEFAULT_SERVANT policy or a
    combination of the RETAIN policy and either the UNIQUE_ID or
    IMPLICIT_ACTIVATION policies; if not present, the WrongPolicy
    exception is raised.

    Note that there is nothing conditional here. If these policies are not
    present, the operation raises an exception.

    Compare this with servant_to_reference:

    This operation requires the RETAIN policy and either the
    UNIQUE_ID or IMPLICIT_ACTIVATION policies if invoked outside
    the context of an operation dispatched by this POA.

    Note that, in this case, we have a qualification:

    "... if invoked outside the context of an operation..."

    Why the difference between the two? They almost do the same thing, namely,
    map from a servant to an object ID. It's just that servant_to_reference,
    after it has the object ID, also embeds that object ID in a reference.

    So, shouldn't the two operations behave the same way? In particular,
    why should servant_to_id raise an exception if I call it from within the
    context of an executing operation on the specified servant?

    In other words, it seems that the behavior specified for servant_to_reference
    is correct and should apply equally to servant_to_id. In effect, calling
    the operation from withing an executing operation on the specified servant
    should do the same thing as calling get_object_id on the POA Current and
    use the resulting id.

    Am I missing something?

  • Reported: CORBA 2.3.1 — Mon, 22 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

ORB::shutdown underspecified

  • Key: CORBA24-93
  • Legacy Issue Number: 3618
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    If I call ORB::shutdown(), it implicitly calls POA::destroy() on the
    Root POA.

    I assume that the value of the wait_for_completion parameter to
    ORB::shutdown() should be passed through to POA::destroy()? The spec isn't
    entirely clear on this point.

    Further, what is the effect of calling ORB::shutdown() on the value
    of the etherealize_objects parameter for POA::destroy()? Since ORB::shutdown()
    doesn't have an etherealize_objects parameter itself, the value passed
    through to POA::destroy must be implicit, but the spec doesn't say what
    it is.

    Similarly, ORB::destroy() implicitly calls ORB::shutdown(). From the
    second-last para on page 4-35, it would appear that this implicit call
    is made as ORB::shutdown(true) rather than ORB::shutdown(false). It
    might be nice to make this explicit so I don't have to read between the
    lines to figure it out.

  • Reported: CORBA 2.3.1 — Wed, 17 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Incorrect use of negative fixed scale

  • Key: CORBA24-87
  • Legacy Issue Number: 3581
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    In section 3.9.2 (of ptc/99-12-07) on semantics of constants,
    an example is given showing 3000.00D being of type fixed<1,-3>.
    This is inconsistent with statements elsewhere that fixed scale is a
    non-negative quantity.

    Also, the preceding explanation states: "... leading and trailing zeros are
    factored out, INCLUDING NON-SIGNIFICANT ZEROS BEFORE THE DECIMAL POINT."
    This rule of course leads to negative scale factors, so it must also be
    incorrect.

    Suggested Revision:

    Change the following text:

    "A fixed-point literal has the apparent number of total and fractional
    digits, except leading and trailing zeros are factored out, including
    non-significant zeros before the decimal point. For example, 0123.450d is
    considered to be fixed<5,2> and 3000.00d is fixed<3,-1>."

    to:

    "A fixed-point literal has the apparent number of total and fractional
    digits, except leading zeros before the decimal point and trailing zeros
    after the decimal point are factored out. For example, 0123.450d is
    considered to be fixed<5,2> and 3000.00d is fixed<4,0>."

  • Reported: CORBA 2.3.1 — Tue, 25 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the specification for stripping leading and trailing zeros, and fix the examples accordingly

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

is_equivalent and policies

  • Key: CORBA24-86
  • Legacy Issue Number: 3566
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    How should is_equivalent() behave if I compare two references that denote
    the same object at the same location, using the same profiles, etc, but
    differ in the policies? Do differences in the policies affect the outcome?

    My gut feeling is that is_equivalent() should return false in this case
    because it uses reference identity, not object identity. However, we
    are rapidly approaching the point where is_equivalent() might as well
    unconditionally return false because we are adding more and more flavours
    of additional information into IORs as time goes by. Invocation policies,
    transaction policies, codesets, multiple profiles, optional components,
    etc, etc.

    Does is_equivalent() require a more precise definition in order to remain
    useful?

  • Reported: CORBA 2.3.1 — Sat, 15 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

POA servant_to_id inconsistent with servant_to_reference

  • Key: CORBA24-89
  • Legacy Issue Number: 3607
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In CORBA 2.3, servant_to_id does not work if the POA has the RETAIN,
    MULTIPLE_ID, and NO_IMPLICIT_ACTIVATION policies, even if
    servant_to_id is invoked in the context of the specified servant.
    According to 11.3.8.20, such a call raises WrongPolicy.

    Inconsistent with that specification, it is apparently still possible
    to obtain the ID for that servant, using

    id = poa.reference_to_id(poa.servant_to_reference(self))

    This works since 11.3.8.21/3 supports all cases of currently-active
    servant, not only USE_DEFAULT_SERVANT

  • Reported: CORBA 2.3.1 — Wed, 10 May 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Same as Issue 3636, and is fixed by the fix for 3636.

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

Valuetypes with multiple interfaces

  • Key: CORBA24-88
  • Legacy Issue Number: 3589
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    consider the following, which as valid IDL as best as I can figure out:

    interface I1 {};
    abstract valuetype V1 supports I1 {};

    interface I2 {};
    abstract valuetype V2 supports I2 {};

    interface I3 {};
    valuetype V3 : V1, V2 supports I3 {};

    The above raises some very interesting issues. For one, this can't be
    mapped into C++ for a number of reasons (largely having to do with
    ambiguous multiple inheritance). However, there much deeper issues here
    relating to the object model. Some questions:

    • What is the type of the a V3 instance?
    • What is the repository ID of that instance?
    • What is the return value of a call to _this()?
    • What is the result of invoking

    is_a("IDL:I1");
    is_a("IDL:I2");
    is_a("IDL:I3");

    on an I3 reference?

    • What are the results of I1::narrow(), I2::narrow(), and I3::narrow()
      on an I3 reference?
    • What is returned by a call to get_interface()?
    • What are the results of traversing the above in an IFR?

    There are probably more questions along these lines. They all aim at
    the fact that the above construct effectively creates an object that has
    multiple unrelated interfaces. This flies in the face of the CORBA
    type system, which fundamentally requires every object to have exactly
    one most-derived type.

    I think we need to put the axe through constructs such as the one above
    in a hurry!

  • Reported: CORBA 2.3.1 — Fri, 28 Apr 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve no change with explanation as above.

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

Pragma version 2.3

  • Key: CORBA24-96
  • Legacy Issue Number: 3694
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Bill Beckwith)
  • Summary:

    Since pragma version only applies to the name given in the
    pragma and not to anything in the scope of the name this
    means that the rep id of things like Bounds and BadKind are
    still "...:1.0":

    interface TypeCode { // PIDL

    1. pragma version TypeCode 2.3
      exception Bounds {};
      exception BadKind {};

    This is just one example of many things inside version 2.3
    pragma'ed scopes that are defaulting to 1.0.

  • Reported: CORBA 2.3.1 — Fri, 9 Jun 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Non-escaped keywords in published IDL

  • Key: CORBA24-95
  • Legacy Issue Number: 3685
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I know that this is probably not the best RTF to send this to, but the
    issue spans RTFs and we don't have RTFs for the collection or the life cycle
    service, so I'm sending this to the Core RTF for want of a better task force...

    In the CosLifeCycle IDL (formal/98-10-01.idl), we have:

    module CosLifeCycle{

    typedef CosNaming::Name Key;
    typedef Object Factory;
    typedef sequence <Factory> Factories;

    The two occurences of "Factory" are illegal. According to the comment
    at the beginning of the module, this should read:

    module CosLifeCycle{

    typedef CosNaming::Name Key;
    #ifdef NO_ESCAPED_IDENTIFIERS
    typedef Object Factory;
    typedef sequence <Factory> Factories;
    #else
    typedef Object _Factory;
    typedef sequence <_Factory> Factories;
    #endif

    The same problem also appears in formal/98-10-15.idl.

    Also in formal/98-10-01.idl:

    // C o l l e c t i o n F a c t o r i e s
    interface CollectionFactories : CollectionFactory {
    boolean add_factory (
    in Istring collection_interface,
    in Istring impl_category,
    in Istring impl_interface,
    in CollectionFactory factory);

    // ...

    // R A C o l l e c t i o n F a c t o r i e s
    interface RACollectionFactories : RACollectionFactory {
    boolean add_factory (
    in Istring collection_interface,
    in Istring impl_category,
    in Istring impl_interface,
    in RACollectionFactory factory);

    Both operation definitions need the same #ifdef to map away from the
    "factory" keyword that is used as a parameter name.

    That same problem also appears in formal/98-10-03.idl.

    I guess the IDL in the formal CORBAservices documents should be fixed too.

  • Reported: CORBA 2.3.1 — Thu, 6 Jul 2000 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix IDL as suggested

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

return type of TypeCode::fixed_scale()

  • Key: CORBA24-79
  • Legacy Issue Number: 3439
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    in 10.7.1 the fixed_scale() operation is defined to return a short but
    the 'scale' value of a fixed type is defined to be a positive integer
    (in 3.4 (96)) and also in the C++ mapping.
    It seems to me there is some inconsistency here.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

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

POA status during destruction is unclear

  • Key: CORBA24-78
  • Legacy Issue Number: 3436
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The description of POA destroy in section 11.3.8.4 is unclear.
    There are several ways to implement this, which may result in problems
    porting application code between orbs.

    Some of the ambiguities are:

    1) It may or may not be legal for an application to create new child POAs
    while the existing children are being destroyed. This could happen
    explicitly or via AdapterActivators. Such behavior could prevent destruction
    from ever completing.

    2) If the POA's POAManager is in the holding state at the time of
    destruction (or if its state is changed to holding during the destruction
    process), it isn't clear what happens to the held requests.

    3) If the POA's POAManager is active, what happens to requests that arrive
    after the call to destroy but before the destruction becomes apparent? If
    they are to be serviced, a sufficiently rapid arrival rate may prevent the
    destruction from ever completing.

  • Reported: CORBA 2.3.1 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify POA behavior during destruction as described below

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

Problem with valuetype parameter copying

  • Key: CORBA24-77
  • Legacy Issue Number: 3364
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Corba 2.3.1 section 5.2.4.3 states that valuetypes passed as parameters
    are copied when passed into the receiving context. Is this also true
    for valuetypes that are embedded in a contructed IDL type passed as a
    parameter?

    Example:

    // IDL

    valuetype V { };

    struct S

    { V a_v; }

    ;

    interface I

    { S op(in S s1, inout S s2, out S s3); }

    ;

    When I::op is called are the valuetypes embedded in s1, s2, s3 and the
    return value supposed to be copied when making a collocated call?

    Example 2:

    // IDL

    interface J

    { any op(in any a1, inout any a2, out any a3); }

    ;

    If one of the any parameters to J::op contains a valuetype, must it be
    copied before/after a collocated call? What if the any contains a
    struct S instead?

    It seems to me we need to revisit the valuetype copying issue. We have
    three choices:

    1. Valuetypes are not copied for collocated calls.
    2. Only valuetypes as explicit parameters are copied for collocated
    calls.
    3. All valuetypes are copied no matter how deeply they are nested in
    parameters.

    Currently the specification is ambiguous as to whether the semantics are
    supposed to be case 2 or 3. Case 3 is the only one that provides
    guaranteed location transparency, but the cost to implement case 3 for
    collocated calls far too high. It would effectively require the same
    overhead as marshalling/unmarshalling for any operation that has a
    valuetype embedded in a complex IDL type or any.

    So, given that transparency for collocated calls cannot be maintained
    without high overhead, should we completely remove the copying
    requirement because transparency cannot be maintained, or should we just
    document that case 2 is the accepted semantic?

  • Reported: CORBA 2.3.1 — Fri, 25 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see below

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

Ordering issues in the DII

  • Key: CORBA24-64
  • Legacy Issue Number: 3194
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The following are currently undefined in the spec:

    • What happens if poll_response or get_response is called
      before send_deferred?
    • What happens if get_response is called after invoke?
    • What if get_response is called more than once?

    [ Interestingly, the resolution to issue 2341 resolved something,
    but it wasn't issue 2341 That's because the resolution
    doesn't say that calling get_response twise is illegal. ]

    • Is it legal to call poll_response more than once?

    I think that, for the first three, we should raise BAD_INV_ORDER. We
    also need minor codes for those.

    For case four, I'd suggest that calling poll_response multiple times is OK,
    but that calling it once get_response was called should raise BAD_INV_ORDER.

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Fix as described above.

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

Efficient construction of Any types w/o DynamicAny

  • Key: CORBA24-63
  • Legacy Issue Number: 3185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The current C++ mapping does not offer efficient insertion or
    extraction of data from CORBA::Any if static type information
    (IDL-generated insertion and extraction operators) are not
    available.

    I'm thinking of a dynamic DII gateway that needs to shovel large
    amounts of data, such as a sequence<octet>. Presently, the gateway
    must employ the DynAny type, and loop over the number of elements,
    calling insert_octet() or get_octet() repeatedly. This is inefficient,
    especially for large sequences/arrays of basic types.

    I think that a more efficient mechanism might be useful for some
    applications.

  • Reported: CORBA 2.3.1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

Does a value in a valuebox make sense?

  • Key: CORBA24-68
  • Legacy Issue Number: 3220
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Although legal in the CORBA 2.3 IDL grammar, creating a valuebox of
    another valuebox or valuetype is of dubious use. I can't see why having
    an extra level of indirection here would ever be useful. None of the
    language mappings that have defined mappings for valuebox (C++, Java,
    Ada) address this issue either.

    Does it make sense to disallow valueboxing valueboxes or valuetypes?

  • Reported: CORBA 2.3.1 — Sat, 15 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

Semantics for DynAny::equal underspecified

  • Key: CORBA24-67
  • Legacy Issue Number: 3205
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3.1, 9.2.3.5 says: "Two DynAny values are equal if their
    TypeCodes are equivalent and, recursively, all component DynAnys have
    equal values."

    We already added text in the Y2K RTF to clarify equal for object
    references & typecodes, but this leaves an exercise for the reader to
    figure out what equal means for some IDL types, particularly fixed,
    sequences & valuetypes. I believe that an experienced person thinking
    about it can come up with the correct rules, but why leave it up to
    mistaken interpretation.

  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Resolve as suggested

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

Definition of COMPLETED_NO needs to be clarified

  • Key: CORBA24-73
  • Legacy Issue Number: 3302
  • Status: closed  
  • Source: BROKAT Informationssysteme ( Blake Biesecker)
  • Summary:

    In order to resolve the OTS RTF issue 1819, we need
    to have clearer wording regarding what COMPLETED_NO.

    Since we now have the POA, the following phrase from
    section 3.17 is not clear enough:

    COMPLETED_NO The object implementation was never initiated prior to the exception being raised

    In order to get proper rollback logic for transactions
    that get system exceptions and, I'd imagine, to get
    proper fault tolerant behavior, it needs to be made
    clear that COMPLETED_NO means that absolutely no execution
    on the server took place prior to the exception being
    raised. Without such a clarification, it is not possible
    to guarantee data integrity for fault tolerance and it
    forces the OTS to insist on a strict rollback policy when
    a system exception is raised.

    In particular, with the advent of the POA, "object implementation"
    is not as clear as it once was. Does this include servant
    locators, for example.

    As a place to start, I'd like to suggest this instead:

    COMPLETED_NO No execution was initiated in the server prior to the exception being raised

    (The archive for issue 1819 contains a lot more
    discussion on this topic as it relates to the
    OTS.)

  • Reported: CORBA 2.3.1 — Tue, 8 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Close no change

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

Minor glitch about forward declared things

  • Key: CORBA24-72
  • Legacy Issue Number: 3270
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    When value types added forward declarations, and when we added forward
    declarations for structs and unions, we forgot to update the version pragma
    text. Currently, it says (page 10-45):

    Attempts to assign a prefix to a forward-declared interface
    and a different prefix to that interface later result in
    a compile-time diagnostic:

    Proposal:

    Change that sentence to read:

    Forward-declared constructs (interfaces, value types, structures,
    and unions) must have the same prefix in effect wherever they appear.
    Attempts to assign conflicting prefixes to a forward-declared
    construct result in a compile-time diagnostic. For example:

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add the following clarification:

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

Editorial mistake in IDL chapter

  • Key: CORBA24-70
  • Legacy Issue Number: 3268
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 10-46 of the latest draft, at the end of section 10.6.5.2,
    there are three paragraphs that talk about a SoftCo printer. It looks
    like these are somewhere else in previous version and accidentally
    got moved or left behind during the edition for the chapter.
    (If that's a wrong guess, I'd like to know what they are doing there
    because they most certainly don't contribute to the content of this
    section

  • Reported: CORBA 2.3.1 — Wed, 2 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Move the text in question to a more appropriate place as suggested below

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

Can native be used in constructed IDL types?

  • Key: CORBA24-69
  • Legacy Issue Number: 3258
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3.1, section 3.10.5 says:

    "A native type may be used to define operation parameters and results.
    However, there is no requirement that values of the type be permitted in
    remote invocations, either directly or as a component of a constructed
    type."

    This is ambiguous as to whether a native type may be used in a
    constructed IDL type that is intended to be used only locally:

    // IDL

    native MyNative;

    struct MyStruct

    { MyNative a_native; }

    ;

    So, should the first sentence in 3.10.5 be read to mean that native may
    ONLY be used in parameters & results? If so, we ought to put the word
    "only" in there.

  • Reported: CORBA 2.3.1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

response_flags in interop draft

  • Key: CORBA24-76
  • Legacy Issue Number: 3338
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    n the interop draft (ptc/00-02-04) the response_flags are defined now in terms
    of SyncScope. However, SyncScope does only apply to oneway, DII with
    INV_NO_RESPONSE, and sendc-stubs with no reply handler. The Messaging
    submission explicitly defines that it is ignored in the other cases.

    from CORBA Messaging:

    interface SyncScopePolicy

    This interface is a local object derived from CORBA::Policy. It is applied to
    oneway
    operations to indicate the synchronization scope with respect to the target of
    that
    operation request. It is ignored when any non-oneway operation is invoked. This
    policy is also applied when the DII is used with a flag of INV_NO_RESPONSE since
    the implementation of the DII is not required to consult an interface
    definition to
    determine if an operation is declared oneway. The default value of this Policy
    is not
    defined. Applications must explicitly set an ORB-level SyncScopePolicy to ensure
    portability across ORB implementations. When instances of SyncScopePolicy are
    created, a value of type Messaging::SyncScope is passed to
    CORBA::ORB::create_policy. This policy is only applicable as a client-side
    override. The client’s SyncScopePolicy is propagated within a request in the
    RequestHeader’s response_flags as described in GIOP Request Header.

  • Reported: CORBA 2.3.1 — Mon, 21 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

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

symbolic constants for minor exception codes

  • Key: CORBA24-75
  • Legacy Issue Number: 3319
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    in section 3.17.2, we show all the minor codes for exceptions. Unfortuantely,
    these are all magic numbers rather than symbolic constants. In turn,
    these means that I can't write portable code unless I use the magic numbers
    directly.

    It would be nice to have constant definitions for these instead, so I
    can refer to minor numbers in the code without having to resort to
    hard-wired magic numbers.

  • Reported: CORBA 2.3.1 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close no change.

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

Inheritence table 3-10 wrong?

  • Key: CORBA24-66
  • Legacy Issue Number: 3203
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There appears to be a minor glitch in table 3-10. It states that
    stateful valuetypes can only support one non-abstract interface, but it
    is not clear what is correct for abstract valuetypes or abstract
    interfaces, since it uses the words "supports", not "supports single" or
    "multiple" which are used elsewhere. It certainly does not appear
    reasonable for abstract valuetypes to be able to inherit from more than
    one non-abstract interface when stateful valuetypes cannot.

    This brings up a question: Can abstract valuetypes support non-abstract
    interfaces? It's not clear to me what the answer to this ought to be.

    Anyway, it appears to me that part of the table should look like this
    instead:

    May inherit from: | Interface | Abstract Interface
    ---------------------------------------------------------------------------
    Abstract | *no or supports single| multiple
    Value |
    ---------------------------------------------------------------------------
    Stateful | supports single | multiple
    Value | |
    ---------------------------------------------------------------------------

    • depending on the answer to the question above
  • Reported: CORBA 2.3.1 — Mon, 10 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The table needs to be changed to clarify as shown below

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

poll_response()

  • Key: CORBA24-65
  • Legacy Issue Number: 3196
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    there really is a different issue here. On page 7-5:

    boolean poll_response();

    On page 7-9:

    boolean poll_response ( in Request req);

  • Reported: CORBA 2.3.1 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Already fixed editorially in draft.

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

#pragma rules are too restrictive

  • Key: CORBA24-71
  • Legacy Issue Number: 3269
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I think the current rules for #pragma are too tight and we need to relax
    them. In particular, for the ID pragma (page 10-43):

    If an attempt is made to assign a repository ID to the same
    IDL construct a second time, a compile-time diagnostic shall
    be emitted, regardless of whether the second ID is in conflict or not:

    interface A {};
    #pragma ID A "IDL:A:1.1"
    #pragma ID A "IDL:X:1.1" // Compile-time error

    interface B {};
    #pragma ID B "IDL:BB:1.1"
    #pragma ID B "IDL:BB:1.1" // Compile-time error

    This causes problems with separate compilation. For example:

    // x.idl
    namespace Foo

    { // ... };
    #pragma ID Foo "IDL:blah:1.0"

    // y.idl
    namespace Foo { // ... }

    ;
    #pragma ID Foo "IDL:blah:1.0"

    // z.idl
    #include "x.idl"
    #include "y.idl"

    The same problem arises with the version pragma, because I may want to
    change the version in two different source files.

  • Reported: CORBA 2.3.1 — Fri, 4 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify as suggested

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

valuetype factory inheritence?

  • Key: CORBA24-74
  • Legacy Issue Number: 3305
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3.1 Core specification is silent on the issue of whether
    factories defined for a valuetype are "inherited" into derived
    valuetypes. I assume that there is no such inheritence.

    Proposal:

    Add to the end of the first paragraph in 3.8.1.5:

    "Initializers defined in a valuetype are not inherited by derived
    valuetypes."

  • Reported: CORBA 2.3.1 — Wed, 9 Feb 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Add clarifying text as shown below:

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

special-casing TypeCode is unnecessary

  • Key: CORBA24-62
  • Legacy Issue Number: 3181
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The resolution to issue 3048 special-cases TypeCode in a manner that
    essentially makes it a keyword. First of all, given that TypeCode lives in
    the CORBA module, and thus is properly named CORBA::TypeCode, this is
    highly irregular because it means we have a scoped keyword. Second, this
    change also significantly breaks working products – it adopts
    implementation details of certain compilers and rules out already-working
    implementation approaches of other existing compilers. The OMG is not
    supposed to dictate implementation. Finally, the rationale for the changes
    made for 3048 centered around unquantifiable performance issues that IMO
    affect only a very small minority of applications.

  • Reported: CORBA 2.3.1 — Thu, 6 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue.

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

CDR encoding for fixed

  • Legacy Issue Number: 1653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CDR encoding rules for fixed-point types are incomplete.

    In particular, it is not stated which value encodes what digit in each
    nibble of an octet. It seems sensible to use 0x0 -> "0", 0x1 -> "1", ...,
    0x9 -> "9". However, this isn"t stated (but should be).

    The same comment applies to page 7-10 for DynFixed. I would suggest that
    rather than repeat the same explanations in the CDR section and the DynFixed
    section, the spec should use a cross-reference in the DynFixed section that
    points at the CDR rules.

  • Reported: CORBA 2.2 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Interop RTF has recommended adoption of this resolution.

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

LocateRequest and LocateReply messages

  • Legacy Issue Number: 2494
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: GIOP 1.1 only allows Request and Reply headers to be fragmented. But
    GIOP 1.2 increases the size of LocateRequest messages, and large
    LocateReply messages are also likely. I see no reason why GIOP 1.2
    should not allow LocateRequest and LocateReply messages to be
    fragmented. If noone objects, I"d like to see the following put to a
    vote in the next ORB 2.4 Interoperability RTF for inclusion in CORBA
    2.3:

  • Reported: CORBA 2.2 — Fri, 26 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    see above

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

profile ids & component ids

  • Legacy Issue Number: 2904
  • Status: closed  
  • Source: Real-Time Innovations ( Mr. Dave Stringer)
  • Summary:

    Section 15.7.3 includes TAG_INTERNET_IOP and TAG_MULTIPLE_COMPONENTS
    in the list of tagged component ids when they are tagged profile ids.

  • Reported: CORBA 2.3 — Tue, 28 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    editorial change to CORBA 3.0 resolved

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

Need clarification on GIOP::TargetAddress

  • Legacy Issue Number: 2940
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    Something seems unclear to me about how to interpret a RequestHeader_1_2
    when the AddressingDisposition of the TargetAddress is ReferenceAddr:

    In the case the request contains a full IOR, which may have several
    profiles. Since each profile has its own object_key, and there is no
    requirement that they all be the same, the key for the operation may
    depend on which profile chosen.

    The client had to choose some profile in order to send the request, but
    that information is not included in the request. So apparently the
    server must decide on its own which profile it would like to use. This
    may not be the same one the client chose.

    What if any requirements are there on how this is done?

  • Reported: CORBA 2.3 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3.1
  • Disposition Summary:

    withdrawn by submitter...issue closed

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

Errors in published IDL for CORBA module

  • Key: CORBA24-51
  • Legacy Issue Number: 3105
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    I found a lot of errors in the CORBA IDL text file that's on the server
    for download:
    In general, the layout of the file is a mess. Inconsistent, meaningless
    indentation, whitespace before semicolons on occasion, comments indented
    poorly, etc, etc. Wouldn't hurt to clean this up – it's quite embarrassing
    as it is now.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Non-standard system exceptions

  • Key: CORBA24-50
  • Legacy Issue Number: 3104
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Section 3.17.1 says that "ORB implementations may raise non-standard system
    exceptions." This raises a number of questions:

    1. How are non-standard system exceptions defined? Are they defined using
    IDL, or are they PIDL? If they are IDL, how are they identified as
    system exceptions by the language mappings?

    2. The definitions in section 3.17.1 for standard system exceptions appear
    to be IDL, but I believe the intention is that they are PIDL. This
    should be stated clearly.

    3. Should non-standard system exceptions be defined in the CORBA module like
    the standard system exceptions? There are three choices:
    a. They must be in the CORBA module.
    b. They must not be in the CORBA nmodule.
    c. They can either be in the CORBA nodule or in other modules.

    4. Point 3 raises the more general question of whether it is legal for ORB
    vendors to add non-standard definitions to the CORBA module. Section 3.14
    says that "Names defined by the CORBA specification are in a module named
    CORBA," but it does not say whether these are the only names that may appear
    in the module named CORBA. This should be clarified.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    See text below for resolution

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

Use of Principal in GIOP Module erroneous

  • Key: CORBA24-49
  • Legacy Issue Number: 3095
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    In spite of objections based on misunderstandings from certain quarters
    I would like to propose that Principal in the IDL describing GIOP as
    excerpted below be replaced by "sequence <octet>". For whatever it might
    be worth, doing so would make the IDL in the GIOP module actually
    compilable for the first time in its entire existence!

    module GIOP { // IDL extended for version 1.1 and 1.2
    // GIOP 1.0
    struct RequestHeader_1_0

    { // Renamed from RequestHeader IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; sequence <octet> object_key; string operation; Principal requesting_principal; ^^^^^^^^^ }

    ;

    // GIOP 1.1
    struct RequestHeader_1_1

    { IOP::ServiceContextList service_context; unsigned long request_id; boolean response_expected; octet reserved[3]; // Added in GIOP 1.1 sequence <octet> object_key; string operation; Principal requesting_principal; ^^^^^^^^^ }

    ;

    ...
    };

    Firstly, ever since the GIOP standard was adopted, the use of Principal
    in that struct has been erroneous, since it is undefined in GIOP module,
    unless adorned with a CORBA:: prefix. Secondly, in effect all that it is
    trying to say
    is that the Principal is represented as a sequence<octet> in the header
    field
    requesting_principal, not a Principal pseudo-interface, which is
    undefined in that context anyway. Thirdly, even if you could find a
    definition for an unadorned Principal somewhere, what is the meaning of
    that type when CDR encoded? It really is
    nothing but sequence<octet>.

    I think this issue should go to the Interop RTF.

  • Reported: CORBA 2.3.1 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

valuebox and DynAny

  • Key: CORBA24-56
  • Legacy Issue Number: 3135
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The DynAny chapter says absolutely nothing about value boxes. Do they
    fulfill only the base DynAny interface, or the DynValue interface, or do we
    need a new DynValueBox interface? If the DynValue interface is supposed to
    be used, do you treat the boxed value as a single member? If so, what is
    its name?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Following text changes address the outage raised in this issue as well as the one from issue 3250

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

OMG wchar <-> COM WCHAR in CORBA 2.3

  • Key: CORBA24-55
  • Legacy Issue Number: 3134
  • Status: closed  
  • Source: IONA ( Thomas Moriarty)
  • Summary:

    The CORBA 2.3 spec states in table 18-2 that OMG IDL wstring maps to LPWSTR
    in COM.

    This was presumably added with the introduction of CORBA support for
    wstrings. I don't see any mapping defined for OMG wchar. This would
    naturally map to COM WCHAR.

    Is this an error/omission in the 2.3 spec?

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    OMG IDL wchar should indeed map to COM WCHAR. Add it to table 18-1

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

local interfaces and the DII

  • Key: CORBA24-61
  • Legacy Issue Number: 3177
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The current spec for local interfaces disallows making calls to a local
    interface via the DII. It turns out that this is rather inconvenient
    for implementors of scripting languages. That's because, for a scripting
    language, everything is a DII request. Local interfaces, therefore, force
    the implementor to wrap all pseudo-objects and local interfaces in
    special wrapper objects.

    For pseudo-objects, there is nothing we can do. However, for local
    interfaces, we could require DII calls to be supported.

  • Reported: CORBA 2.3.1 — Wed, 5 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved, see above

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

servant_to_id

  • Key: CORBA24-60
  • Legacy Issue Number: 3174
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the following text in the spec could be made a bit clearer:

    2. If the POA has the IMPLICIT_ACTIVATION policy and either the
    POA has the MULTIPLE_ID policy or the specified servant is not
    active, the servant is activated using a POA-generated Object Id
    and the Interface Id associated with the servant, and that Object
    Id is returned.

    Although it is stated elsewhere that IMPLICIT_ACTIVATION requires SYSTEM_ID,
    it wouldn't hurt to reflect this here too:

    2. If the POA has the IMPLICIT_ACTIVATION policy and either the
    POA has the MULTIPLE_ID policy or the specified servant is not
    active and the POA has the SYSTEM_ID policy, the servant is
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    activated using a POA-generated Object Id
    and the Interface Id associated with the servant, and that Object
    Id is returned.

    Another question:

    What should be returned if the USER_ID policy is present?

    The spec doesn't say. Given that we can't add a new user exception,
    OBJ_ADAPTER seems appropriate.

  • Reported: CORBA 2.3.1 — Tue, 4 Jan 2000 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.4
  • Disposition Summary:

    Close with no change, since a POA cannot have IMPLICIT_ACTIVATION and USER_ID.

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

What is the TypeCode for ValueBase?

  • Key: CORBA24-54
  • Legacy Issue Number: 3132
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    I know this is late, but I think it is quite urgent, and we ought to
    add it to the last Core 2000 vote.]

    The spec is silent about the existence and properties of a TypeCode
    constant for ValueBase, even though it is necessary to define one so
    that the DII, DSI and IFR can operate properly.

    There also is no explicit information about what values operation calls
    on the TC_Object typecode constant return.

    Proposal:

    1. Add to the list of TypeCode constants in 10.7.2:

    TC_ValueBase = tk_value

    { ValueBase }

    2. Add at the end of section 10.7.2:

    For the TC_Object TypeCode constant, calling id returns
    "IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object". For
    the TC_ValueBase TypeCode constant, calling id returns
    "IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase",
    calling member_count returns 0, calling type_modifier returns
    CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.

  • Reported: CORBA 2.3.1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via t

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

Do valueboxes have factories?

  • Key: CORBA24-53
  • Legacy Issue Number: 3115
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Nowhere in the CORBA 2.3 specification is it made clear whether or not
    valueboxes have or need a valuefactory.

    Since valueboxes are clearly completely concrete types, with no
    operations, and with no factory initializers, there is no need for a
    factory for valueboxes.

    Proposal:

    Add the following to secion 5.2.8.1:

    "Value box types do not need or use factories."

  • Reported: CORBA 2.3.1 — Tue, 14 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

DynAny & abstract interfaces don't mix!

  • Key: CORBA24-52
  • Legacy Issue Number: 3109
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 9.2.2 states:

    "The operation raises InconsistentTypeCode if value has a TypeCode with
    a TCKind of tk_Principal, tk_native, or tk_abstract_interface."

    This is totally broken for abstract interfaces. What happens if I do
    this:

    // IDL
    abstract interface I {
    };

    struct S

    { I an_i; }

    ;

    // C++
    S mys;
    CORBA::Any a;

    a <<= s;

    DynamicAny::DynAnyFactory_var daf = ...;
    DynamicAny::DynAny_var da = daf->create_dyn_any(a);
    DynamicAny::DynAny_var component = da->current_component();

    Obviously the value of component must be meaningful, otherwise there is
    no way to examine or construct a value of type S.

  • Reported: CORBA 2.3.1 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

create_POA and inactive state?

  • Key: CORBA24-48
  • Legacy Issue Number: 3073
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    what should happen if I call create_POA() on a POA whose POA manager is
    in the inactive state (that is, a POA on which, previously, deactivate()
    was called?

    The spec says nothing about this. Seeing that creating a new POA on a "dead"
    POA doesn't make sense, I would suggest to raise BAD_INV_ORDER, possibly
    with a new minor code.

  • Reported: CORBA 2.3.1 — Thu, 2 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

value type substitutability

  • Key: CORBA24-47
  • Legacy Issue Number: 3072
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Chapter 5.2.5: Value type semantics should not define that an instance of a
    value type can be passed (directly) as a parameter that is declared as an
    interface type. The reason is that this is not true in some of the language
    mappings (e.g. C++) because it contradicts the kind and nature of value types.

    A value type instance IS NOT an object reference even if it is registered with
    the ORB. Therefore, if a construct conceptually is not a subtype of another
    construct, it should not be possible that it substitutes the other. Also, it
    should not be required that there are any shortcuts which automatically convert
    a registered valuetype to it's associated object reference.

  • Reported: CORBA 2.3.1 — Tue, 30 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify the ambiguity that leads to the possible inappropriate interpretation

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

OMG IDL Syntax and Semantics issue

  • Key: CORBA24-46
  • Legacy Issue Number: 3069
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The following thing is unnoticed in CORBA V2.3, June 1999, OMG document
    99-07-07.pdf, Chapter 3, "OMG IDL Syntax and Semantics", pages 3-37..3-39,
    definition of "sequence" type:

    There is no explicit definition what length sequence may have at run
    time. Things are perfectly defined for sequence bounds (i.e. maximum
    size at compile time) which is explicitly declared to be a positive
    integer. However, nothing is said whether length of sequence at run
    time can be: (a) positive; or (b) non-negative; or even (c) negative.

  • Reported: CORBA 2.3.1 — Mon, 29 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

TypeCode issue

  • Key: CORBA24-45
  • Legacy Issue Number: 3048
  • Status: closed  
  • Source: ZeroC ( Marc Laukien)
  • Summary:

    At present, the following IDL code is illegal:

    interface I

    { CORBA::TypeCode get_type(); }

    ;

    To make it legal, "orb.idl" must be included. From the spec:

    "The file orb.idl contains the IDL definitions for the CORBA module. The
    file orb.idl must be included in IDL files that use names defined in the
    CORBA module."

    I don't think that this is a good idea, because of the following
    reasons:

    • TypeCode is PIDL, not IDL. So orb.idl can only be used as a "switch"
      to enable TypeCode, but it cannot contain a "real" IDL definition for
      TypeCode.
    • Having to include orb.idl for every little program that requires
      TypeCode means a huge overhead, as orb.idl includes everything from
      the CORBA module (including the IFR!).

    I don't see any reason why TypeCode should only be available if orb.idl
    is included. To me, TypeCode is "built-in", even if it doesn't have a
    keyword. So it appears rather strange to me that I have to artificially
    disable TypeCode in our IDL parser if orb.idl is not included, just to
    be compliant with the spec.

    I would therefore propose to allow CORBA::TypeCode in IDL even if
    orb.idl is not included.

  • Reported: CORBA 2.3.1 — Tue, 23 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

IDL scoping rules

  • Key: CORBA24-59
  • Legacy Issue Number: 3173
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 3-48, we have:

    On the other hand, if module Inner2 were:

    module Inner2

    { typedef Inner1::S1 S2; // Inner1 introduced typedef string inner1; // Error typedef string S1; // OK }

    ;

    The definition of inner1 is now an error because the identifier
    Inner1 referring to the module Inner1 has been introduced in the
    scope of module Inner2 in the first line of the module declaration.
    Also, the declaration of S1 in the last line is OK since the
    identifier S1 was not introduced into the scope by the use of
    Inner1::S1 in the first line.

    This is fine, but it doesn't make it clear that, if the name is qualified,
    it is not introduced into the scope.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Additional clarifying words are needed as shown below.

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

null & void TCs and DynAny

  • Key: CORBA24-57
  • Legacy Issue Number: 3159
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The DynAny chapter says nothing about whether
    DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly
    handle a TypeCode argument that has a TCKind of either tk_null or tk_void.

    I assume these are valid argument TypeCodes that do not result in an
    InconsistentTypeCode exception, and the returned DynAny is simply one that
    fulfills the basic DynAny interface and has no components. However, it
    would be nice to explicitly document the cases for these two TypeCodes,
    though, given that they're a little different from other TypeCodes in that
    they can't have any associated values.

  • Reported: CORBA 2.3.1 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Clarify with additional text as shown below

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

Bug in 11.3.7.6

  • Key: CORBA24-58
  • Legacy Issue Number: 3172
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    on page 11-30, we have:

    RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY

    This combination represents the situation where the POA does no
    automatic object activation (that is, the POA searches only the
    Active Object Map). The server must activate all objects served
    by the POA explicitly, using either the activate_object or
    activate_object_with_id operation.

    The final sentence is wrong. Implicit activation is controlled by the
    ImplicitActivation policy.

  • Reported: CORBA 2.3.1 — Sun, 2 Jan 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Remove the incorrect sentence

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

Problem with the "Special scoping" rules in 3.15.3

  • Key: CORBA24-37
  • Legacy Issue Number: 2980
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The special scoping rules make it clear that they apply only to
    identifiers that name a type, however the second IDL example claims that
    the import of a constant definition (in this case the identifier I) into
    an interface scope behaves the same way.

    So which one is it? Do the rules only apply to type identifiers or to
    all identifiers?

  • Reported: CORBA 2.3.1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    The changes below provide clarification.

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

Meaningless sentence on page 3-11?

  • Key: CORBA24-36
  • Legacy Issue Number: 2978
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 3-11 says about string literals:

    The size of a string literal is the number of character literals
    enclosed by the quotes, after concatenation. The size of the
    literal is associated with the literal.

    The final sentence appears to be meaningless. Suggest to delete it.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Type Code Section issue

  • Key: CORBA24-32
  • Legacy Issue Number: 2963
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the TypCodes definition section is in Chapter 10, Interface
    Repository. Type Codes are used by lots of other things that have very little to
    do with Interface Repository. Wouldn't it be better to move the TypeCode section
    to Chapter 4.

  • Reported: CORBA 2.3.1 — Wed, 27 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Minor codes for Standard System Exceptions in Chapter 8 missing

  • Key: CORBA24-31
  • Legacy Issue Number: 2960
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 8 (formal/99-07-12) is missing specification of minor codes for all the
    standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Minor codes for Standard System Exceptions in Chapter 5 missing

  • Key: CORBA24-30
  • Legacy Issue Number: 2959
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    Chapter 5 (formal/99-07-09) is missing specification of minor codes for all the
    standard system exceptions that are specified to be raised under various
    circumstances.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

IDL and C++ relationship

  • Key: CORBA24-34
  • Legacy Issue Number: 2976
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    page 3-2 of the spec says (Section 3.1, para 3 and para 5):

    OMG IDL obeys the same lexical rules as C++.

    [ ... ]

    The OMG IDL grammar is a subset of the proposed ANSI C++ standard...

    Both paragraphs are simply wrong. IDL doesn't obey the same lexical rules
    and it isn't a subset of C++. In addition, we now have the final ISO/IEC
    C++ standard, so talking about the proposed or draft standard is out of date.

    I would suggest to systematically replace references to ANSI C++, the
    "proposed" standard, or the "draft" standard with the proper ISO/IEC
    reference.

    The verbage about IDL being a subset of C++ and obeying the same lexical
    rules should be removed. It simply isn't true.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

PIDL vs Local

  • Key: CORBA24-33
  • Legacy Issue Number: 2974
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    Regarding using a version in a repository ID:

    If old PIDL were to be recast to local, each time the
    interface def would be enhanced (by adding new local
    operations), the IDL module would have to be appropriately
    versioned.

    I also point out that using a version for corba::object's repository
    id seems inappropriate, since there are multiple version of
    corba::object which the omg never bothered to version, since they
    did not have to.

    Thus, in summary, putting version 1.0 to correspond to a pidl interface
    implies stability in that inteface (i.e., it will not change without
    changing
    the version number), which the OMG has never enforced for PIDL.

  • Reported: CORBA 2.3.1 — Mon, 25 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

Missing "abstract" in forward declaration

  • Key: CORBA24-40
  • Legacy Issue Number: 3018
  • Status: closed  
  • Source: Perot Systems ( Bill Binko)
  • Summary:

    In the new Core 2.3.1 (http://www.omg.org/cgi-bin/doc?formal/99-10-07),
    section 3.7.4 is incorrect in that it does not mention the optional
    "abstract" keyword.

    A forward declaration declares the name of an interface without defining it.
    This
    permits the definition of interfaces that refer to each other. The syntax
    consists simply

    of the keyword interface followed by an <identifier> that names the
    interface. The
    actual definition must follow later in the specification.

    The paragraph is not in sync with the idl grammar in section 3.4

    (6) <forward_dcl> ::= [ "abstract" ] "interface" <identifier>

  • Reported: CORBA 2.3.1 — Wed, 10 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

The algorithm for TypeCode::equivalent in 10.7.1 was not updated

  • Key: CORBA24-39
  • Legacy Issue Number: 3001
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The algorithm for TypeCode::equivalent in 10.7.1 was not updated to
    reflect the new TypeCode::member_visibility, TypeCode::type_modifier,
    and TypeCode::concrete_base_type operations.

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Editorial glitch in DynAny::destroy, section 9.2.3.6

  • Key: CORBA24-44
  • Legacy Issue Number: 3041
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The first paragraph of 9.2.3.6 refers to "creation operations on the ORB
    interface". This needs to be changed to "creation operations on the
    DynAnyFactory interface".

  • Reported: CORBA 2.3.1 — Tue, 16 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

What is the NO_RESPONSE exception good for?

  • Key: CORBA24-43
  • Legacy Issue Number: 3022
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 3.17.1.15 states:

    "NO_RESPONSE

    This exception is raised if a client attempts to retrieve the result of
    a deferred synchronous call, but the response for the request is not yet
    available."

    Meanwhile, section 7.3.4 states:

    "get_response returns the result of a request. If get_response is called
    before the request has completed, it blocks until the request has
    completed."

    So if get_response blocks, how and when will and ORB ever raise
    NO_RESPONSE?

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

General Exception Question

  • Key: CORBA24-29
  • Legacy Issue Number: 2955
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Could someone explain to me the justification for all the restrictions on
    > exceptions? Why CAN'T we: pass exceptions as parameters, use them as
    > elements in container types? I know the IDL language doesn't allow it, I
    > just want to know why it was designed that way. Other languages certainly
    > allow it.

  • Reported: CORBA 2.3.1 — Tue, 26 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Exception section issue

  • Key: CORBA24-28
  • Legacy Issue Number: 2954
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the Standard Exception definitions are in Chapter 3 IDL
    Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces? I would like to get a feel for how the RTF membership feels about moving the
    entire section 3.21 from Chapter 3 to Chapter 4.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Section 7.6: IDL context housecleaning

  • Key: CORBA24-42
  • Legacy Issue Number: 3021
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Now that we've bitten the bullet and moved the Exception section from
    chapter 3 to chapter 4, shouldn't we do the same thing with section 7.6,
    since IDL contexts actually have little to do with the DII?

    I propose that we move section 7.6 to chapter 4 as well.

  • Reported: CORBA 2.3.1 — Fri, 12 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Question about IDL \uxxxx escape format

  • Key: CORBA24-41
  • Legacy Issue Number: 3020
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Why was the \uxxxx escape from C++ added to wide string & char literals
    in IDL, but the equivalent \Uxxxxxxxx escape was not?

  • Reported: CORBA 2.3.1 — Thu, 11 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Duplicate

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

Preprocessing of IDL

  • Key: CORBA24-35
  • Legacy Issue Number: 2977
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Page 3-12:

    OMG IDL preprocessing, which is based on ANSI C++ preprocessing, ..
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    The highlighted phrase is meaningless and should be deleted.

    In addition, the last para of 3.3 says that

    A complete description of the preprocessing facilities may be found
    in the The Annotated C++ Reference Manual.

    For one, the ARM is badly out of date. Second, the para implies, but doesn't
    actually say, that IDL preprocessing is exactly like C++ preprocessing.

    I would suggest to replace the last para with a definitive statement to
    say that IDL is preprocessed as described for C++ in the ISO/IEC C++ standard.
    In addition, that statement should probably be used as the lead-in to
    section 3.3.

  • Reported: CORBA 2.3.1 — Wed, 3 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Codeset conversions and unions

  • Key: CORBA24-38
  • Legacy Issue Number: 3000
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Recently, we decided not to permit wchar as the discrinator type for
    unions because of the impossibility of dealing with different codesets.

    Well, it looks like we have exactly the same problem for char

  • Reported: CORBA 2.3.1 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Use of incomplete recursive TypeCodes underspecified

  • Key: CORBA24-17
  • Legacy Issue Number: 2903
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Section 10.7.3 of the CORBA 2.3 spec says that operations on recursive
    TypeCodes and recursive sequence TypeCodes before they have been embedded
    give undefined results.

    However, it is not clear whether this applies to other uses of these
    TypeCodes ... or other incomplete TypeCodes or Anys that contain them. For
    example, can an incomplete TypeCode be used:

    • as a parameter to create_dyn_any_from_type_code,
    • as a parameter to a DII or DSI operation; e.g. the arg_type parameter
      of CORBA::Request::add_arg(), or
    • as a (CORBA IDL) parameter or result of a regular operation invocation?
  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Semantics of DynAny with alias TypeCodes

  • Key: CORBA24-16
  • Legacy Issue Number: 2901
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The CORBA 2.3 spec for DynAny makes no mention whatsoever of how it should
    handle Any values corresponding to TypeCodes whose kind is tk_alias.

    The implementation of (CORBA 2.2) DynAny in a popular free ORB strips off
    typecode aliases when it creates a DynAny. While this seems to be contrary to
    the overall intent of the DynAny spec, I can find nothing in the 2.2 or 2.3
    spec that definitively precludes this (IMO bogus) behaviour.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

URLs interact poorly with code set selection

  • Key: CORBA24-15
  • Legacy Issue Number: 2900
  • Status: closed  
  • Source: Cisco Systems ( Paul Kyzivat)
  • Summary:

    The corbaname & corbaloc url formats provide a situation where an IOR
    designating a server is created and used by a client without input by
    that server.

    One (optional) element of an IOR is a CodeSetComponent specifying the
    code sets that the server is willing/able to utilize. Normally these are
    examined by a client and used to select a pair of code sets (narrow and
    wide) to be used for communication between client and server.

    Chapter 13 of the Corba spec states: "If the code set component is not
    present in a multi-component profile structure, then the deault char
    code set is ISO 8859-1 for backward compatibility. However, there is no
    default wchar code set. If a server supports interfaces that use wide
    character data but does not specify the wchar code sets that it
    supports, client-side ORBs will raise exception INV_OBJREF."

    This seems to imply one of the following:
    1) URLs may not be used to reference interfaces that employ wide
    characters;
    2) URLs must generate IORs with a code set component supporting
    wchar data;
    3) The CORE must be changed to relax the above restrictio

  • Reported: CORBA 2.3.1 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

DataInputStream specification is inefficient for Java

  • Key: CORBA24-12
  • Legacy Issue Number: 2892
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue is for the Core RTF. Although it shows up in the context of Java,
    fixing it requires a change to an API defined in the CORBA core.

    The CORBA::DataInputStream type (part of the CORBA core) is specified in
    a way that makes it extremely inefficient to implement in Java. A small
    change to this IDL definition would reduce the number of Java classes needed
    to implement it from 27 to 1. (Really!)

  • Reported: CORBA 2.3 — Fri, 17 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

POA exception minor codes

  • Key: CORBA24-11
  • Legacy Issue Number: 2861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are several cases in the POA specification where the POA is required to
    raise system exceptions. We should assign OMG minor exception codes to
    each of these cases so that applications can diagnose these conditions
    better.

    Examples:

    1. POA has the USE_DEFAULT_SERVANT policy but no servant is assigned, the
    POA raises OBJ_ADAPTER.

    2. If no adapter activator is available (or the available one refuses to
    create a POA), the OBJECT_NOT_EXIST exception is raised.

  • Reported: CORBA 2.3 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Wchar as discriminator in union

  • Key: CORBA24-10
  • Legacy Issue Number: 2859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Just got a question from our IDL compiler folks - I think they"ve
    found a bug in the 2.3 IDL chapter..... (actually the bug has been there
    for a while)..

    Looking at the new CORBA2.3 book,

    The syntax for discriminated unions are described on two pages (3-16 and
    3-36).
    On both pages the <wchar_type> isn"t included in the grammar for
    <switch_type_spec>. Therefore my conclusion was that it shouldn"t be
    allowed. The problem is that further down on page 3-36 there is a table
    for "case label matching" and in that table wchar is listed as a
    discriminator type.

    So, was the wchar type forgotten from the grammar for switch type spec,
    or
    was wchar mistakenly added to the table?

  • Reported: CORBA 2.3 — Thu, 26 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Problem with text of POAManager::deactivate()

  • Key: CORBA24-23
  • Legacy Issue Number: 2911
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The first paragraph of 11.3.2.6 says:

    This operation changes the state of the POA manager to inactive. If
    issued while the POA manager is in the inactive state, the
    AdapterInactive exception is raised. Entering the inactive state causes
    the associated POAs to reject requests that have not begun to be
    executed as well as any new requests.

    But the last paragraph says:

    If deactivate is called multiple times before destruction is complete
    (because there are active requests), the etherealize_objects parameter
    applies only to the first call of deactivate; subsequent calls with
    conflicting etherealize_objects settings will use the value of the
    etherealize_objects from the first call. The wait_for_completion
    parameter will be handled as defined above for each individual call
    (some callers may choose to block, while others may not).

    So which is right? Is does a subsequent call to deactivate() raise
    AdapterInactive, or does it succeed, perhaps blocking until completion?

  • Reported: CORBA 2.3.1 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    Incorporate changes and close issue

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

CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B

  • Key: CORBA24-22
  • Legacy Issue Number: 2910
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I notice that the CORBA 2.3 spec hasn't been updated with one of the corrections in
    part B of the COM-CORBA Interworking spec (orbos/97-09-06).

    page 13C-130 of the Part B spec, CORBA::Char mapping to UI1 has not been updated
    in the corresponding section in the CORBA 2.3 spec (19.3.1, page 19-10).

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

creation of arguments to TypeCode creation ops

  • Key: CORBA24-19
  • Legacy Issue Number: 2907
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It is not clear from section 10.7.3 of CORBA 2.3 how much param checking
    the ORB operations for TypeCode creation should do. It is also unclear
    whether only the BAD_PARAM exception should be raised, or whether some
    others are legitimate; e.g. BAD_TYPECODE.

    Here are some detailed questions on TypeCode creation argument checking:

    1) should the operations that take a "name" argument check that it
    is a valid IDL name? A non null string?

    2) should the operations that take a "RepositoryId" argument check
    that it has a recognisable format?

    3) should the operations that take content and member types as
    parameters check that they are legitimate; i.e. that they
    don't have kinds tk_null, tk_void or tk_exception.

    4) should the operations that take members check that the member
    names are valid IDL names and that they are unique within the
    member list?

    5) should create_union_tc check that there are no duplicate label
    values? Should it check that the labels' TypeCodes are equal to
    discriminator TypeCode? Or equivalent?

    6) should create_union_tc check that the supplied discriminator
    type is legitimate?

    There are probably more cases as well.

  • Reported: CORBA 2.3.1 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

DynFixed editorial issue

  • Key: CORBA24-18
  • Legacy Issue Number: 2906
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    In the CORBA 2.3 spec for DynFixed::set_value (page 9-14) it says, "If val
    contains a value whose scale exceeds that of the DynFixed or is not
    initialized, the operation raises InvalidValue."

    Later in the same paragraph it says, "If val has more fractional digits
    than can be represented in the DynFixed, fractional digits are truncated
    and the return value is false."

    Given that the term "scale" is used with the fixed-point type to describe
    the number of fractional digits, these two quoted sentences are confusing
    and appear to contradict one another.

    I propose changing the first quoted sentence to: "If val contains a value
    whose number of digits exceeds the maximum number of digits specified by
    the TypeCode of the DynFixed, or if val is not initialized, the operation
    raises InvalidValue."

  • Reported: CORBA 2.3 — Wed, 29 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

CORBA 2.3 Editorial issue for TypeCodes & abstract_interface

  • Key: CORBA24-27
  • Legacy Issue Number: 2945
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The comments in the definition of TypeCode in 10.7.1 shows that id() and
    name()
    are valid for TypeCodes of kind tk_abstract_interface, but the text
    descriptions of the id() and name() operations do not list abstract
    interface TypeCodes as supporting these operations.

  • Reported: CORBA 2.3.1 — Thu, 21 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Editorial issue for CORBA 2.3, 1.3.8.20

  • Key: CORBA24-26
  • Legacy Issue Number: 2944
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Section 11.3.8.20 (servant_to_id) was not updated in the same fashion as
    section 11.3.8.21.

    There are two problems:

    1. The RETAIN policy in the first paragraph needs bold face.

    2. Behaviors 1 & 2 should both require the RETAIN policy, just like the
    text in section 11.3.8.21.

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

CORBA 2.3: minor editorial issue

  • Key: CORBA24-9
  • Legacy Issue Number: 2849
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 4-5 of CORBA 2.3 the deprecated create_recursive_sequence_tc
    operation is missing its open parenthesis for its parameter list.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

chapter 3 and recursion

  • Key: CORBA24-8
  • Legacy Issue Number: 2848
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3, chapter 3, section 3.10.2, page 3-35 says: "Although the IDL
    syntax allows the generation of recursive constructed type specifications,
    the only recursion permitted for constructed types is through the use of
    the sequence template type." With the introduction of valuetypes, this is
    no longer true. A valuetype is allowed to have a member of its own type,
    either directly or indirectly.

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Component ids in 13.6.2.2

  • Key: CORBA24-25
  • Legacy Issue Number: 2913
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Also, 13.6.2.2 claims "ORB services are assigned component identifiers
    in a namespace that is distinct from the the profile identifiers".
    What is the significance of this statement?

  • Reported: CORBA 2.3 — Tue, 28 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

(CORBA Core) Data streams missing arrays of long double

  • Key: CORBA24-24
  • Legacy Issue Number: 2912
  • Status: closed  
  • Source: Oracle ( Dan Frantz)
  • Summary:

    DataInputStream and DataOutputStream (CORBA 2.3, Section 5.5.2) has
    definitions for reading and writing individual items and arrays of
    primitive data types except long double. This seems to be an
    oversight.

  • Reported: CORBA 2.3 — Wed, 22 Sep 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Why are Standard Exceptions defined in IDL chapter?

  • Key: CORBA24-14
  • Legacy Issue Number: 2898
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    I was wondering why the Standard Exception definitions are in Chapter 3 IDL
    Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces?
    I would like to get a feel for how the RTF membership feels about moving the
    entire section 3.21 from Chapter 3 to Chapter 4.

  • Reported: CORBA 2.3.1 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

What is the RepId of Object?

  • Key: CORBA24-13
  • Legacy Issue Number: 2896
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    "Can someone please clue me in as to what the
    > repository ID of Object is? Is it "IDL:omg.org/CORBA/Object:1.0"? Or is
    > it "IDL:omg.org/Object:1.0"?"

  • Reported: CORBA 2.3.1 — Wed, 20 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

formal/99-08-01.txt missing pragmas

  • Key: CORBA24-21
  • Legacy Issue Number: 2909
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The ORB Core IDL extracted in formal/99-08-01.txt is missing the various
    '#pragma' definitions for the IFR interfaces.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

CORBA::ORB::RequestSeq definition obsolete

  • Key: CORBA24-20
  • Legacy Issue Number: 2908
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    CORBA 2.3 added the CORBA::RequestSeq definition to orb.idl. The C++
    mapping defines CORBA::ORB::RequestSeq, which is now redundant and
    should be removed.

  • Reported: CORBA 2.3.1 — Tue, 12 Oct 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

Incorrect IDL is section 5.5.3

  • Key: CORBA23-84
  • Legacy Issue Number: 2539
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL in section 5.5.3 is incorrect. It refers to
    CORBA::FullValueDescription
    but the correct name for this type according to chapter 10 is
    CORBA::ValueDef::FullValueDescription

    Proposed Resolution:

    Change chapter 5 to match up with chapter 10.

  • Reported: CORBA 2.2 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    make it so.

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

RMI style repository ID hash code

  • Key: CORBA23-83
  • Legacy Issue Number: 2529
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with the currently defined algorithm for computing
    the hash code component of the RMI Hashed Format repository ID as
    defined in section 10.6.2. Because it is based only on the structural
    information in the most derived Java class and does not take into
    acoount any superclass information, it can give a "false positive"
    result when the state of a superclass changes but the state of the
    most derived class does not.

    This is a core RTF issue since the affected text is in chapter 10.

  • Reported: CORBA 2.2 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Replace the currently defined algorithm with one that fixes the problem as described below

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

forward declaration in ptc/98-10-04

  • Key: CORBA23-82
  • Legacy Issue Number: 2522
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Pages 3-18 and 3-19 of the CORBA 2.3a spec state that a forward declaration consists of the following:
    [abstract] "interface" <identifier>
    I believe that this should be:
    [abstract] "interface" <scoped_name>

    Otherwise, the following would be illegal:
    module A
    {
    interface B::d; //forward decl of d
    interface c

    { B::d f(); }

    ;
    };
    module B
    {
    interface d

    { A::c f(); }

    ;
    };

  • Reported: CORBA 2.2 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

${issue.summary}

  • Key: CORBA24-4
  • Legacy Issue Number: 2828
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: CORBA 2.3 — Mon, 2 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    resolved in interop RTF

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

mixing giop versions

  • Key: CORBA24-3
  • Legacy Issue Number: 2822
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is currently unclear on when and how messages with different
    giop versions may share a single connection.

    This has already been discussed, with different RTF members holding
    positions running the range from: "all messages on a connection must
    have the same giop version" to "messages with differing giop versions
    must be permitted on the same connection". So clearly there is an issue.

    The resolution of this issue should address at least the following
    unclear points:

    1) suppose a client orb supporting giop 1.2 initiates an invocation on
    an IOR with iiop version 1.1. As a result, it establishes a new
    connection and sends the request using giop 1.1. Later, the same client
    obtains another IOR referencing the same transport address, but
    specifying iiop version 1.0.

    • may the same connection be used to send a request to the new IOR?
    • if so, what giop version should be used to send the request?

    2) Later, the same client obtains another IOR referencing the same
    transport address, but specifying iiop version 1.2.

    • may the same connection be used to send a request to the new IOR?
    • if so, what giop version should be used to send the request
    • if so, what giop version should be used to send subsequent requests
      to the IORs mentioned in (1).

    3) Imagine a day in the not too distant future, when giop 1.3 has been
    approved and implemented. A client that supports giop 1.3 obtains an IOR
    with iiop version 1.2, establishes a new connection, and then sends a
    request using giop 1.2. A service context offering bidirectional giop is
    sent with this request, and accepted by the server. The client provides
    the server (that supports giop 1.3) with a callback IOR that has iiop
    version 1.3, and the server attempts to call back on it.

    • may the callback use the incoming connection?
    • if so, what giop version should the request use?
    • if so using v1.2, what if the callback request requires a feature
      only available in giop 1.3?
  • Reported: CORBA 2.3 — Mon, 26 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

UNIQUE_ID and ServantActivator issue

  • Key: CORBA23-92
  • Legacy Issue Number: 2576
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should happen if the servant returned from a
    ServantActivator::incarnate call is already registered for another
    object id, and the POA has the UNIQUE_ID policy?

    Since this is clearly an error, I suggest raising the OBJ_ADAPTER
    exception (which will be returned to the client whose request prompted
    the call to incarnate). I also suggest requiring the POA to call
    ServantActivator::etherealize for that object id. The latter is
    necessary to allow the application to dispose of any resources
    associated with that object, and to ensure that an application will
    never recieve two calls to ServantActivator::incarnate for a particular
    object id without an intervening call to ServantActivator::etherealize.

  • Reported: CORBA 2.2 — Fri, 2 Apr 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change and close issue

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

Clarification on IdUniquenessPolicy

  • Key: CORBA23-91
  • Legacy Issue Number: 2574
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of IdUniquenessPolicy in section 11.3.7.3 fails to
    mention how this policy interacts with the ServantRetentionPolicy.

    My interpretation is that the IdUniquenessPolicy is irrelevant when the
    ServantRetentionPolicy is NON_RETAIN. If this is the case it should be
    explicitly stated. Alternatively, one specific value might be required
    when NON_RETAIN is in effect. (If so, it ought to be MULTIPLE_ID.)

    Without some statement clarifying this there could be portability
    problems with some orbs allowing either value while others require a
    particular value.

  • Reported: CORBA 2.2 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

New "opaque" data type

  • Key: CORBA23-95
  • Legacy Issue Number: 2674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I propose the addition of the new basic data type "opaque."

    Many applications require the sending or retrieving of opaque data,
    like graphical data or file contents. Currently, such data is packaged
    as sequence<octet>.
    In the past, the performance of passing sequence<octet> parameters
    was not satisfactory because of the generic mapping of sequences. In
    the recent C++ mapping, the dubious get_buffer() is introduced for
    the mapping of sequences.
    I feel that this matter is best resolved by adding a new data type
    which can then be mapped efficiently into target languages without
    the side effect of complicating the mapping of other sequences.
    After all, a "string," too, is nothing but a sequence of char.

  • Reported: CORBA 2.2 — Sun, 30 May 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

DynAny::equal operator issue

  • Key: CORBA23-94
  • Legacy Issue Number: 2616
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The DynAny::equal operator does not mention how to compare object
    references or TypeCodes. It should be specified to require is_equivalent()
    to be called for object reference comparison and equivalent() to be called
    for TypeCode comparison.

  • Reported: CORBA 2.2 — Tue, 20 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

sharing valuetypes across Anys

  • Key: CORBA23-93
  • Legacy Issue Number: 2577
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should valuetype identity be preserved across arguments when those
    valuetypes reside within Anys?

  • Reported: CORBA 2.2 — Mon, 5 Apr 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

DynAny.insert_valuetype shoud be insert_val

  • Key: CORBA23-86
  • Legacy Issue Number: 2547
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL in section 9.2 of ptc/98-12-04 is incorrect. The OBV RTF adopted
    method names insert_val and get_val instead of the original insert_value
    and get_value which conflicted with the get_value method in the DynFixed
    subclass. The IDL incorectly shows these methods as insert_valuetype
    and get_valuetype.

    Proposed Resolution:

    Change insert_valuetype to insert_val and get_valuetype to get_val.

  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    fix the names in section 9.2

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

confusing rules for operations on Object

  • Key: CORBA23-85
  • Legacy Issue Number: 2543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.3 of ptc/98-10-05 documents Object Reference Operations. These
    are described as "not operations in the normal sense, in that they are
    implemented directly by the ORB, not passed on to the object
    implementation".

    This includes a variety of operations, requiring varying contexts to be
    used successfully:

    • Some require remote communication to the orb of the server
      or (contrary to the quote above) may actually be passed on
      to the object implementation, or something similar like a
      servant manager (e.g. is_a, non_existent)
    • some may require remote communication to an interface repository
      (e.g. get_interface)
    • some require the local orb to be operational
      (e.g. create_request)
    • some can function even without a local orb
      (e.g. is_nil, duplicate, release)
  • Reported: CORBA 2.2 — Tue, 16 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

ambiguity in wstrings having a Unicode escape sequence

  • Key: CORBA24-7
  • Legacy Issue Number: 2847
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to the spec, a wide string may contain one or
    more Unicode escape sequences of the form \uxxxx, where
    the x"s are hex digits. It also says that such an
    escape sequence may not have the value 0, and that
    leading 0s are optional in the hex digits.
    Taking all this into account, how does a parser
    tell the difference between (imaginary parentheses
    inserted to show the writer"s intent)

  • Reported: CORBA 2.3 — Fri, 13 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

POA: false placement of paragraph

  • Key: CORBA24-6
  • Legacy Issue Number: 2846
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA 2.3, chapter 11.3.8.11 (docs/formal/99-07-15.pdf, p. 11-35):
    seems to me as if the paragraph that was added to the description of
    get_servant_manager() is really intended for set_servant_manager().

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

OBV interface support inconsistencies

  • Key: CORBA24-5
  • Legacy Issue Number: 2844
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3 chapter 3.8.5 (docs/formal/99-07-07.pdf, p. 3-27) claims that
    a stateful value can only support a single interface.

    CORBA 2.3 chapter 5.2 (docs/formal/99-07-09.pdf, p. 5-2) claims that
    a concrete (stateful) value can support multiple interfaces.

    The latter is obviously wrong.

  • Reported: CORBA 2.3 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    No Data Available

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

activate_object_with_id and exceptions

  • Key: CORBA23-88
  • Legacy Issue Number: 2549
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If I use activate_object_with_id and the object ID is already in the AOM,
    the operation raises ObjectAlreadyActive.

    If I use activate_object_with_id and the servant is already in the AOM, and
    the POA has UNIQUE_ID, the operation raises ServantAlreadyActive.

    What happens if I have UNIQUE_ID, and I run the following code?

    poa->activate_object_with_id(my_id, my_servant);
    poa->activate_object_with_id(my_id, my_servant); // ???

    Which exception is raised on the second call, ObjectAlreadyActive or
    ServantAlreadyActive?

  • Reported: CORBA 2.2 — Thu, 18 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Repository ID for Object

  • Key: CORBA23-87
  • Legacy Issue Number: 2548
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Latest 2.3, draft (98-10-10), page 13-17:

    "A Null TypeID is the only mechanism that can be used to represent
    the type CORBA::Object."

    I am aware of more than one ORB that uses "IDL:omg.org/CORBA/Object:1.0".

    I don"t understand why:

    • a null ID should mean Object
    • why a perfectly good repository ID for Object should be disallowed

    Related to this is the fact that we made repository IDs mandatory in
    reference TypeCodes with the 2.3 revision. Unless an implementation is
    very careful, this could mean that, if it gets a reference that doesn"t
    have the repository ID, it could present an illegal TypeCode (with an
    empty ID) for that reference to the application.

  • Reported: CORBA 2.2 — Wed, 17 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

interop issue: what system exceptions may be raised on GIOP 1.0?

  • Key: CORBA24-2
  • Legacy Issue Number: 2819
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An issue we"ve run across is enumerating the set of system exceptions
    that are valid to be passed via GIOP 1.0 (and similarly for 1.1, and
    1.2). This is important for implementations of GIOP, which are, for
    instance, attempting to map wire exceptions to C++ exceptions, and is
    also important for packet-sniffing implementations.

    Since many conforming GIOP 1.0 implementations were built (and bought)
    and incorporated into products before various CORBA system exceptions
    were added to the Core, it seems that servers should not raise `newer"
    exceptions back to older clients – that is, clients speaking GIOP 1.0.
    Instead, they should map those `newer" exceptions to UNKNOWN, I"d guess.

  • Reported: CORBA 2.3 — Wed, 21 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

The syntax for stringified IORs in section 13.6.6

  • Key: CORBA24-1
  • Legacy Issue Number: 2796
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The syntax for stringified IORs in section 13.6.6 shows: =
    "IOR:" The problem is that URL scheme names are supposed to be case
    insensitive. So, "Ior:"
    or "ioR:" should be allowed to. I would suggest to add a footnote to
    state that case for the scheme name is ignored.

  • Reported: CORBA 2.3 — Fri, 9 Jul 1999 04:00 GMT
  • Disposition: Resolved — CORBA 2.4
  • Disposition Summary:

    closed in interop/2000-01-01

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

deactivate_object asymmetry

  • Key: CORBA23-90
  • Legacy Issue Number: 2559
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the POA, we have

    ObjectId activate_object(in Servant s) raises(...);
    void activate_object_with_id(in ObjectId id, in Servant s) raises(...);

    However, for deactivation, we have only one function:

    void deactivate_object(in ObjectId id) raises(...);

    This lacks symmetry. If I can use implicit activation of a servant,
    why can"t I use implicit deactivation? For symmetry, I would have expected:

    void deactivate_object() raises(...);
    void deactivate_object_with_id(in ObjectId id) raises(...);

  • Reported: CORBA 2.2 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

ORB::shutdown again

  • Key: CORBA23-89
  • Legacy Issue Number: 2553
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m sorry to reopen this can of worms, but I believe that the shutdown()
    issue we voted on (1665) still only offers a partial solution. The problem
    appears to be that terminating the event loop and ORB destruction must be
    separate steps.

    Consider a very simple application that uses RETAIN, NO_IMPLICIT_ACTIVATION,
    and USER_ID. No servant manager is used.

  • Reported: CORBA 2.2 — Tue, 23 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue should be closed no change.

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

Inconsistent spellings of "policy" related identifiers:

  • Key: CORBA23-70
  • Legacy Issue Number: 2454
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have found inconsistent spellings of "policy" related identifiers:

    "DomainManagersList" is used on pages 4-4 and 4-8

    "DomainManagerList" is used on pages 4-17,20-87,20-88,20-110

    Also, the operation identifer

    "set_policy_override" is used on pages 20-87, 20-88, 20-110

    However, this same operation identifier is consistently spelled as

    "set_policy_overrides" on pages 15-52,15-61,15-65,15-66,15-103,
    15-104,15-105,15-106,15-108,15-109,15-111,15-199,15-218,
    and 15-219

    in 98-12-03.pdf (Security Service Specification - Security Service
    v1.5 15 December 1998 [FINAL]

    So what is the "correct" spelling of these identifiers?

  • Reported: CORBA 2.2 — Wed, 17 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

IR Changes in 2.3

  • Key: CORBA23-69
  • Legacy Issue Number: 2450
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Jishnu has pointed out (very pointedly i might add that a whole slew of
    upwardly incompatible changes have been made to the IR.

    E.g. old structs that have been modified (e.g. full interface description),
    new structs have been added, operations added to container, changed
    tckind, etc., etc.

    The question before us is how, if at all, to reflect this change.

    We came up with several options (listed in no particular order and
    with no particular recommendation.)

    1. Do nothing. This is the traditional approach but probably becoming
    less and less appropriate as we mature

    2. Add a #pragma version name_of versioned_thingy major.minor
    for every definition. (Jishnu thinks that in
    principle all the #pragma version statements could go in one place,
    say at the end of the CORBA module. [We leave it as exercise to the
    reader to work out why they have to go at the end] )

    3. Change the name of the enclosing module. say CORBA -> CORBA_2_3, gulp!!

  • Reported: CORBA 2.2 — Fri, 12 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate changes in 2.4 and close issue.

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

Interceptors broken

  • Key: CORBA23-63
  • Legacy Issue Number: 2435
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be general consensus that the interceptor spec is
    unimplementable fantasy material. Given this, it would seem advisable to
    remove interceptors from the core.

    Also, there is some doubt as to whether P&P rules were followed when
    interceptors were added. My understanding is that an RTF cannot add
    new features to a spec, yet interceptors definitely seem to fall into
    that category.

    Given that no RFP was ever issues and that the feature is obviously broken,
    I suggest to remove the interceptor section until the outcome of the
    Portable Interceptors RFP can be added.

  • Reported: CORBA 2.2 — Thu, 4 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close in 2.4 with no change.

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

clarification and bug in InterfaceDef::FullInterfaceDescription

  • Key: CORBA23-62
  • Legacy Issue Number: 2432
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text in the interface repository specification that describes FullInterfaceDescription is ambiguous. CORBA v2.3a draft, section 10.5.23.1, page 10-22 reads:

    The describe_interface operation returns a FullInterfaceDescription
    describing the interface, including its operations and attributes. The
    inherited describe operation for an InterfaceDef returns an
    InterfaceDescription.

    It does not specify whether the elements of the FullInterfaceDescription should describe only items (e.g., operations, attributes) that where defined in the interface being described, or whether they should describe items inherited from base interfaces as well. My naive, assumed rationale is that the full description is intended to improve efficiency. It should allow a dynamic client to obtain all of the information it needs to invoke any operation supported by the interface in a single request, avoiding the need to traverse the graph of base interfaces. If this is the case, then the full description should include inherited items as well, and the spec should say so. I checked our implementation (VisiBroker) and this is what it does.

    My suggested remedy is to add the following words to the paragraph cited above:

    "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 bug (I think) is that the FullInterfaceDescription description doesn"t include the boolean is_abstract member. The abbreviated InterfaceDescription struct has been extended with this member, and the FullInterfaceDescription should be a superset of the InterfaceDescription.

    The suggested fix is to add the the following member to the InterfaceDef::FullInterfaceDescription struct:

    boolean is_abstract;

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

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

Try to define obligatory and optional parts of the CORBA specification.

  • Key: CORBA23-61
  • Legacy Issue Number: 2378
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule.
    6) In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional.
    In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close in 2.4 with no change.

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

Application Interface issue

  • Key: CORBA23-60
  • Legacy Issue Number: 2377
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: During study of the ORBIX software, I analyzed structure of internal stubs generated by IDL compiler on the both client and server side of the CORBA connection. I appreciated, that for creation of the both sides are used the same constructions like Request object, not different objects Request on the client side and ServerRequest on the server side. Naturally, there was also possibility to use CORBA compliant ServerRequest object when requested, but generated stubs used "old" IONA logic. May be, there are some sophisticated reasons why OMG specification use various objects on both client and server sides which I do not know, but in general, I prefer more simple approach of IONA. Please, let application interface as simple as possible.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is adequately dealt with in the POA specification.

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

Use UNICODE Character set

  • Key: CORBA23-59
  • Legacy Issue Number: 2372
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I am member of the nation using another set of accented Latin letters than is LATIN-1 standard (ISO 8859.1), namely LATIN-2. For this reason, I must comment your preference of one particular character set as an unfortunate case. I would understand, that if you would limit character set to basic Latin characters of the basic ASCII code, but preference of one national enhancements of this code brings my doubts.
    In fact, the problem is not so hot, as it may seem on the first view. I know at present no classical compiler allowing use of the national character set e.g. for the language identifiers, and the limitation of the character sets to pure Latin characters is considered by Czech (and other nation"s) programmers as no significant limitation, with exception of the comments. The same concerns CORBA identifiers used in the OMG IDL language.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close issue in 2.4 with no change.

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

LocateReply body alignment issue

  • Key: CORBA23-81
  • Legacy Issue Number: 2521
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Hi folks, I know this is a bit late but I was going through some GIOP
    1.2 issues with Bob and I only just noticed another required
    clarification for LocateReply messages. Bascially the text added under
    Request/Reply which states "In GIOP 1.2, the Request[/Reply] Body is
    always aligned on an 8 octet boundary" was not also added to the
    description for LocateReply"s (15.4.2.2). I presume the requirement
    was intended for the body data of all message types. If so, perhaps it
    would make sense to move this text to the start of 15.4 and reworded
    to indicate the requirement for all message body data in general.

    If the LocateReply body alignment issue will not be clarified in the
    GIOP 1.2 specification then I wish to submit this as a new interop
    issue.

  • Reported: CORBA 2.2 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

POA issue, section 11.3.8.10

  • Key: CORBA23-80
  • Legacy Issue Number: 2513
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 11.3.8.10 of the Core draft 2.3a says that the application is
    free to assign its own servant manager to the root POA, but the next
    section says that the
    set_servant_manager() operation requires that the POA in question must
    support the request processing policy of USE_SERVANT_MANAGER. But as
    the root
    POA has a req. proc. policy of USE_ACTIVE_OBJECT_MAP_ONLY, surely the
    user CANNOT assign a servant manager to the root POA.

    The text is a mistake, isn"t it? The application cannot "assign its own
    servant manager to the root POA". Unless there is some subtlety to the
    meaning of the word "assign" which make it different from "set". I
    thought the root POA was something the user could not tamper with in any
    way.

  • Reported: CORBA 2.2 — Fri, 5 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

POA that has IdAssignmentPolicy=SYSTEM--portability problem

  • Key: CORBA23-79
  • Legacy Issue Number: 2511
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For a POA that has IdAssignmentPolicy=SYSTEM, there is a portability
    problem in the combination of the POA generation of an ObjectId and
    the language functions that convert between ObjectId and string.

    The C++ functions PortableServer::ObjectId_to_string (and wstring)
    state that

    If conversion of an ObjectId to a string would
    result in illegal characters in the string (such
    as a NUL), the [...] functions throw the
    CORBA::BAD_PARAM exception.

    This apparently assumes that the conversion does nothing but take the
    sequence of octet and recast it as a char*. Thus, an embedded null
    would cause the string to be interpreted as shorter than the sequence,
    so it"s an error.

  • Reported: CORBA 2.2 — Thu, 4 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

Scope of SendingContextRunTime service context

  • Key: CORBA23-76
  • Legacy Issue Number: 2507
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear what is the scope of the SendingContextRunTime service
    context defined in section 13.6.7.

    Since the content of this service context will remain constant through
    the lifetime of a connection, it needs to be sent only once per
    connection. This is much more efficient than requiring it to be sent
    on a per-request basis.

    This seems to parallel the current usage of the CodeSets service context.
    Section 13.7.2.6 says:
    Code set 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.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

Need to specify exception for abstract interface error

  • Key: CORBA23-75
  • Legacy Issue Number: 2502
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An abstract interface type in an operation signature indicates that
    at runtime the value passed will either be an object reference or a
    valuetype. However, it is possible for user code invoking this
    operation to supply (incorrectly) a runtime programming language object
    that is neither of these. For example, an IDL abstract interface type
    maps into a Java interface, and the object passed at runtime could be
    any Java type that implements this interface.

    The spec does not currently define an exception to be used in this
    error case. The Java to IDL mapping needs a defined exception so that
    it can detect this error and return a NotSerializableException to the
    application.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add a new minor code to the BAD_PARAM system exception:

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

Error in IRObject definition in 98-12-04

  • Key: CORBA23-74
  • Legacy Issue Number: 2492
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of IRObject in 10.5.2 somehow got an additional attribute
    that makes no sense: "readonly attribute InterfaceName type_name".
    This is probably an editorial mistake.

  • Reported: CORBA 2.2 — Fri, 26 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    They have been fixed in ptc/98-12-04.

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

What use is CORBA::exception_type?

  • Key: CORBA23-73
  • Legacy Issue Number: 2490
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This enumeration type is defined in 3.17.1, but used no where else. Why
    is it even there?

  • Reported: CORBA 2.2 — Thu, 25 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate changes in 2.4 and close issue.

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

Inconsistent Definition of Flags type

  • Key: CORBA23-72
  • Legacy Issue Number: 2487
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 4.3 of V2.3a specification, the typedef of Flags is "long". In
    Section 7.1.1, it is "unsigned long".

  • Reported: CORBA 2.2 — Wed, 24 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Make it uniformly unsigned long

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

CORBA::Object::ping ?

  • Key: CORBA23-71
  • Legacy Issue Number: 2456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"d like to float the idea of adding a ping operation to CORBA::Object:

    module CORBA {
    interface Object

    { void ping(); // ... }

    ;
    // ...
    };

    The reason for suggesting this is that developers have a frequent need
    for this functionality. (How to determine object reachability (as opposed
    to object existence) is a FAQ).

  • Reported: CORBA 2.2 — Thu, 18 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Can an any with a tk_null or tk_void TypeCode be encoded with CDR?

  • Key: CORBA23-78
  • Legacy Issue Number: 2509
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is silent about whether an any with a TypeCode of tk_null or
    tk_void can be marshalled and unmarshalled with CDR.

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed in interop/2000-01-01

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

omg.org prefix not well specified

  • Key: CORBA23-77
  • Legacy Issue Number: 2508
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The core spec says in section 10.6.7 that:

    Unless pragma directives establishing RepositoryIds for all definitions
    are present in an IDL definition officially published by the OMG, the
    following directive is implicitly present at file scope preceding all
    such definitions:
    #pragma prefix “omg.org”

    What does an IDL compiler need to do to be compliant with this? How
    is it supposed to recognize IDL definitions officially published by the
    OMG so that it can insert the required implicit pragma?

  • Reported: CORBA 2.2 — Wed, 3 Mar 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

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

What value type does ValueDef"s base_value() return?

  • Key: CORBA23-68
  • Legacy Issue Number: 2447
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: full_desc: What does a ValueDef"s base_value() operation
    return for a value type that does not inherit from
    any concrete value?

    I see two possible resolutions: (1) make base_value()
    return ValueDef::_nil() in this case, or (2) add a
    pk_ValueBase primitive type to PrimitiveDef and
    return that.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

Inheritance of value types

  • Key: CORBA23-67
  • Legacy Issue Number: 2446
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for clarification regarding inheritance
    for value types. Must a value type that inherits from
    abstract bases always inherit from a "concrete"
    value? This seems to be enforced by the IDL
    grammar and the introduction of the ValueBase
    primitive type (as a concrete base in case no
    other concrete base is inherited).

    This seems somewhat ambiguous.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    close this issue with the note that it is resolved as part of 2490 in 2.4

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

Problems in Chapter 5 IDL

  • Key: CORBA23-66
  • Legacy Issue Number: 2444
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-12-04 Chapter 5, page 5-14, a DataInputStream operation
    has the signature "long long long read_long()". It should be
    "long long read_longlong()"

    Also, the spelling of W[Cc]harSeq is inconsistent between its
    declaration and its usage on pages 5-12 to 5-14.

  • Reported: CORBA 2.2 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Closed; No Change — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

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

POA Construction Policy.

  • Key: CORBA23-65
  • Legacy Issue Number: 2442
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: >From what I understand of the POA document is that
    the POA or POAs are process resident, and that the servants they register
    are within their own process space, i.e. the Server.

  • Reported: CORBA 2.2 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

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

another problem with IDL specification section 3.9.2

  • Key: CORBA23-64
  • Legacy Issue Number: 2436
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec doesn"t say how octal and hex integral constants are treated.
    For instance, is the following line legal IDL or not:

    const short s = 0xFFFF; // Valid???

    If the interpretation of "0xFFFF" in this context is "65535", then
    this is illegal, since the value is out of range. If the interpretation
    is "-32768", then this assignment is valid. The wording in this section specifies that
    each operand is converted immediately to the size of the eventual
    storage location, but fails to specify how that conversion is to be
    performed for hexadecimal and octal literals.

  • Reported: CORBA 2.2 — Thu, 4 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    closed issue

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

Issue - no PIDL, just language bindings

  • Key: CORBA23-58
  • Legacy Issue Number: 2371
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 7.3.2 of CORBA 2.3a (ptc/98-10-07 pg 7-9) the description of
    send_multiple_requests gives the C, C++, and SmallTalk bindings for the
    operation but does not describe it in PIDL. This is inconsistent with
    the description style for other operations. It is unnecessarily biased
    towards these particular languages, and complicates the process of
    maintaining the specifications of the individual language bindings.

    The same comment applies to section 7.3.4 regarding get_next_response.
    In this case the language binding is in fact inconsistent with that
    published in the C++ language binding.

  • Reported: CORBA 2.2 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue and raise new issue in C++ RTF

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

Grammar section 3.9.2 missing "float" rules, and other problems

  • Key: CORBA23-57
  • Legacy Issue Number: 2343
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.9.2 has the following problems:

    No rules for combining floats are given, although double and long double types are mentioned.

    The rules for sizing intermediate forms of constant expressions that must result in an octet type
    are unspecified.

    The size a positive integer constant is required to have is not specified; I imagine it should be
    restricted to (at most) an "unsigned long" size, as larger sizes would not make valid array indices
    in several languages.

  • Reported: CORBA 2.2 — Mon, 25 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Sumsume this issue in 1139, and close this issue with that annotation in 2.4.

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

No description for NativeDef

  • Key: CORBA23-45
  • Legacy Issue Number: 2322
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.5.26, NativeDef, has no description of its read and write
    interfaces. This is inconsistent with other sections.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Provide description

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

Errors in figure 10-2

  • Key: CORBA23-44
  • Legacy Issue Number: 2321
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-8, the section of figure 10-2 describing the module object
    has become wrongly ordered when the green text was inserted. It says:

    InterfaceDef
    ValueDef
    ValueBoxDef
    ModuleDef

    It should say:

    ModuleDef
    ValueBoxDef
    InterfaceDef

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    fix the order and indentation

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

Signature of unmarshal method is wrong

  • Key: CORBA23-43
  • Legacy Issue Number: 2320
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 5-11, section 5.5.1, the signature of the unmarshal method is
    wrong. It should return void, not ValueBase.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

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

Value base and the IFR

  • Key: CORBA23-54
  • Legacy Issue Number: 2334
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following IDL:

    // IDL
    interface I

    { void op(in ValueBase vb); }

    ;

    How is this represented in the IFR? What is the IDLType of the vb
    parameter?

    I think it should be a PrimitiveDef, just as it would be the case if I
    would pass "Object" instead of "ValueBase". However, there is no
    pk_ValueBase defined. Shouldn"t this be added?

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add value base to primitive defs.

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

Clarifications needed in section 5.2.2

  • Key: CORBA23-53
  • Legacy Issue Number: 2332
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.2.2 it states in the second paragraph that instances of
    valuetypes passed into valuetype methods are passed by reference (in a
    programming language sense). That"s fine, but:

    1. This paragraph should also state that returned results are passed
    by reference. This is necessary to ensure consistent IDL
    valuetype semantics across different implementation languages.

    2. The last sentence of the following paragraph is confusing because
    it appears to contradict the statement in the second paragraph
    about reference semantics. It says that "normal semantics for the
    programming language in question apply". So if I have a language
    that only does pass-by-value, pass-by-value semantics would apply
    (so this says). This cannot be correct, since it would prevent
    valuetypes from having well-defined semantics at the IDL level.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it.

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

Clarify meaning of no IDL initializers

  • Key: CORBA23-42
  • Legacy Issue Number: 2319
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.8.1.5 on page 24 does not make it clear what it means to
    have no initializers for an IDL valuetype. The decision of the OBV
    designers, which is reflected in the C++ and Java language mappings,
    was that this means there is no portable way to create an instance
    of the value type. This should be clearly stated in the definition of
    IDL semantics for valuetypes, not deduced from the language mappings.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading text in section 3.2.5.2

  • Key: CORBA23-41
  • Legacy Issue Number: 2318
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The second last paragraph in section 3.2.5.2 is confusing. The
    second last sentence says (modulo typos) that since a string is a
    sequence of character literals, a sequence of \u literals can be
    used to define a wide string literal.

    This seems to me to be a non sequitur. The conclusion does not
    follow from the premise. I think this sentence was supposed to say
    that since a wide string is a sequence of wide character literals,
    a sequence of \u literals can be used to define a wide string literal.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Calling get_response twice?

  • Key: CORBA23-56
  • Legacy Issue Number: 2341
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What if I call get_response on a request a second time, after I"ve already
    retrieved the response previously? It seems that an exception should
    be raised but the spec doesn"t say which one.

    Also, the spec could be interpreted right now to say that it"s OK to
    call get_response twice for the same request (because the spec says nothing
    about that). However, to me, permitting this would be silly because it would
    oblige the ORB to keep the reply around until the request object is destroyed
    or is used to initiate another request.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Forward-Declared Interfaces

  • Key: CORBA23-55
  • Legacy Issue Number: 2340
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: there just has been raging discussion on the OB list about forward-declared
    interfaces. The words we have right now are inadequate. You could argue that the
    interface is defined in the same "specification" here. However,
    current IDL compilers (if they implmement the check at all) require
    the interface to be defined in the same compilation unit as the
    forward declaration.

    Now, we could allow a forward-declared interface to not be defined in
    the same compilation unit, but then, I think, we would have to very
    carefully specify what sort of things I can do with the forward-declared
    interface. (If we don"t do that, we"ll make separate compilation impossible
    because the compiler doesn"t know the size of a forward-declared interface
    nor its base interfaces.)

    What"s the general feeling here? I think we could simple change "specification"
    to "IDL source file" and be done with it. That"s the simple way out.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No description for ValueBoxDef

  • Key: CORBA23-47
  • Legacy Issue Number: 2325
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.5.25, ValueBoxDef, has no description of its read and write
    interfaces. This is inconsistent with other sections.

    Proposed resolution:

    Add copies of sections 10.5.13.1 and 10.5.13.2 here.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Provide description

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is_a description is wrong

  • Key: CORBA23-46
  • Legacy Issue Number: 2323
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-36, the "is_a" description is wrong. "interface_id" should
    be "value_id" for consistency with the IDL.

    Actually, it would be more correct to name this "value_or_interface_id"
    or just "id" since both values and interfaces can be passed to the is_a
    method of ValueDef. This requires changing the IDL on pages 10-34 and
    10-65.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RMI Repository ID missing from section 10.6

  • Key: CORBA23-50
  • Legacy Issue Number: 2329
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 10.6 needs to be updated to reflect the addition of RMI
    Hashed Format RepositoryIds.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    change introductory sentence to fix this problem in section 10.6

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text was inserted in wrong place

  • Key: CORBA23-49
  • Legacy Issue Number: 2328
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-9, the recently added second paragraph should be moved to the
    bottom of the section. The parapgraph preceding it and the two paragraphs
    following it refer back to numbered points 1, 2 and 3 at the bottom of
    page 10-8, so this block of text should not be broken up.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Make it so

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify text in section 15.3.7

  • Key: CORBA23-52
  • Legacy Issue Number: 2331
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 15-26, last sentence of section 15.3.7, the phrase "The abstract
    encoding of value type" is not very clear. This refers to abstract
    interfaces, but a reader might think it refers to abstract valuetypes.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in text describing TypeCode interface

  • Key: CORBA23-51
  • Legacy Issue Number: 2330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL on page 10-47 describing the TypeCode interface says that
    the member_count, member_name, and member_type operations apply to
    tk_except TypeCodes. However, the text on page 10-49 says that
    these do not apply to exception TypeCodes.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix it.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in ValueDef IDL

  • Key: CORBA23-48
  • Legacy Issue Number: 2327
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 10-35, the first line should be "RepositoryId supported_interface;".

    Also, on page 10-65, the eleventh member of FullValueDescription should be
    "RepositoryId supported_interface;" (same change).

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    The resolution of this is tied to the resolution of issue 2314. So this issue is attached to and sub

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Core uses both "standard" and "system" exception terminology

  • Key: CORBA23-28
  • Legacy Issue Number: 2221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The core chapters (chapter 3, for example) uses both "standard" and
    "system" to describe the same class of exceptions. Most of the core
    seems to prefer "standard", however the C++ language mapping uses
    SystemException.

    The core should be cleaned up to use "standard" as the normal term, and
    then state that "system" is used in some language mappings as a synonym.

  • Reported: CORBA 2.2 — Thu, 19 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create_policy specification needs to be completed

  • Key: CORBA23-27
  • Legacy Issue Number: 2214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification of the create_policy operation in Chapter 4 section
    4.9.2 (ptc-98-10-05, 5 November 98) is missing the following important
    elements:

    1. There is no specification of what is expected of someone who is
    defining a new policy type, in order to use this operation as the
    factory for policy objects of that type.

    2. Policy objects of wich of the PolicyTypes can be created using this
    operation in release 2.3 is not specified. Consequently, the types that
    are valid as input through the "val" parameter are unspecified also.

  • Reported: CORBA 2.2 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need namespace for Policy Type

  • Key: CORBA23-26
  • Legacy Issue Number: 2206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: To allow vendors to define their own value added Policies, the
    PolicyType should be partitioned into spaced that can be assigned to
    vendors. Since the PolicyType is a CORBA long, just like the system
    exception minor code, we can just reuse the VMCID for this purpose.

  • Reported: CORBA 2.2 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Codebases with multiple URLs

  • Key: CORBA23-40
  • Legacy Issue Number: 2316
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: To support JDK 1.2 correctly, the codebase support for Objects By Value
    needs to support multiple URLs rather than a single URL as at present.

    This affects page 5-16 in the core 2.3a chapters. Either the signatures
    of the implementation and implementations methods need to change to:
    URLSeq implementation(in CORBA::RepositoryId x);
    URLSeqSeq implementations(in CORBA::RepositoryIdSeq x);

    or we need to say that the URL string can be a blank-separated
    sequence of URLs. This also affects the OBV grammar on page 15-19.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting multiple abstract interfaces

  • Key: CORBA23-39
  • Legacy Issue Number: 2314
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Valuetypes should be able to support multiple abstract interfaces but
    only a single regular interface. See also comments number 28 and 31
    in the list of core 2.3a errata I just sent out.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names of Data*Stream methods

  • Key: CORBA23-38
  • Legacy Issue Number: 2312
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The method names in DataInputStream and DataOutputStream have been
    chosen to match the method names in the Java portability streams.
    There is a proposal before the Java RTF to change some of the latter
    names. If this is accepted, we should change the corresponding names
    in Data*Stream as well.

    This affects page 5-12 in the core 2.3a chapters. write_Value should
    change to write_value and write_Abstract to write_abstract_interface.
    The corresponding read_* methods on page 5-14 should also be changed.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scoping resolution for member names

  • Key: CORBA23-25
  • Legacy Issue Number: 2202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The wording of the current 2.3 spec says nothing to suggest that member names in structs are in (or
    out) of the scope of the struct. That is, whether

    struct s {
    struct t

    {...}

    t;
    };

    is legal or illegal.

  • Reported: CORBA 2.2 — Tue, 10 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close this issue in 2.4 noting that the resolution of issue 1893 subsumes this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in POA

  • Key: CORBA23-24
  • Legacy Issue Number: 2200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On P. 11-52 I see:

    ...Assuming the POA has the USE_SERVANT_MANAGER policy and no servant
    manager is associated with a POA, any request received by the POA for
    an Object Id value not present in the Active Object Map will result
    in an OBJECT_NOT_EXIST exception.

    However on P. 11-9:

    If the POA has the USE_SERVANT_MANAGER policy, a servant manager
    has been associated with the POA so the POA will invoke incarnate or
    preinvoke on it to find a servant that may handle the request. (The
    choice of method depends on the NON_RETAIN or RETAIN policy of the
    POA.) If no servant manager has been associated with the POA, the POA
    raises the OBJ_ADAPTER system exception.

  • Reported: CORBA 2.2 — Mon, 9 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

void * in DII Chapter

  • Key: CORBA23-23
  • Legacy Issue Number: 2162
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Now that we have the native type, it is time to replace those void *s in
    the DII specification PIDL and restate them in terms of native types.

  • Reported: CORBA 2.2 — Tue, 3 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in text and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

is_a underspecified

  • Key: CORBA23-30
  • Legacy Issue Number: 2230
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the description of is_a suffers from the same problem that we fixed for
    non_existent in 2.3: it is not clear what the operation should do if
    it could not make a determination due to a hard error. This means that
    the application does not know whether failure to make a determination
    returns false, or whether that will raise an exception (and false is
    returned only if the object doesn"t have the expected type).

  • Reported: CORBA 2.2 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    clarify

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Local operations on CORBA::Object

  • Key: CORBA23-29
  • Legacy Issue Number: 2223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Basically, people get confused about which operations on CORBA::Object
    can go remote. It"s clear from the GIOP spec that only non_existent(),
    is_a(), get_interface(), and get_domain_managers() can go on the wire.
    It follows that things like nil(), hash(), and is_equivalent() must be
    local. However, as Owen Rees pointed out, this only applies to GIOP, not
    the core, but a compliant ORB need not provide GIOP.

    It seems that it would be a good idea to add some clarification to the core
    to state which operations on CORBA::Object must be local and which ones
    may (but need not) go remote.

  • Reported: CORBA 2.2 — Thu, 19 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

uses of recursive_tc

  • Key: CORBA23-31
  • Legacy Issue Number: 2235
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53,
    "Once the recursive TypeCode has been properly embedded in the
    enclosing TypeCode which corresponds to the specified repository
    id, it will function as a normal TypeCode."

    Given the following idl:

    valuetype v

    { public v m0; }

    ;

    And the following C++ code to generate the typecode for v:

    CORBA::ORB_ptr orb = ...;
    CORBA::TypeCode_ptr tcRecursive =
    orb->create_recursive_tc("IDL:v:1.0");
    CORBA::ValueMemberSeq v_seq;
    v_seq.length(1);
    v_seq[0].type = tcRecursive;
    ...
    CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v",
    VM_NONE, CORBA::TypeCode::_nil(),
    v_seq);

    After tcRecursive has been properly embedded, what does "tcRecursive
    functioning
    like a normal TypeCode" mean? Does it mean that one can call on
    tcRecursive the same
    methods that are available on tcV? For example, will

    CORBA::Visibility vis = tcRecursive->member_visibility(0);

    work?

  • Reported: CORBA 2.2 — Thu, 3 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom Marshaling clarification

  • Key: CORBA23-37
  • Legacy Issue Number: 2311
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the core 2.3a chapters, page 5-11, section 5.5.1, last paragraph needs
    to be clarified or deleted. This paragraph originally referred to the
    "streaming policy" registration APIs that used to be specified here but
    have since been deleted.

    Do we still intend to allow language mappings to provide alternative
    mechanisms for custom marshaling as well as the standard mechanism of
    having the valuetype implementation provide the CustomMarshal methods
    marshal and unmarshal? If not, this paragraph should be deleted. If so,
    the last part of the paragraph should be reworded, for example "... to
    support other ways for value types to implement custom marshaling".

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing minor code

  • Key: CORBA23-36
  • Legacy Issue Number: 2310
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the 2.3a core chapters, there is a minor code missing from page 3-58,
    table 3-13. BAD_PARAM minor code 1 should also be raised for errors
    trying to lookup and unregister a value factory. Alternatively we could
    add new minor codes for these.

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Let minor code one be used for all value factory related exceptions.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom marshalling & AbstractBase

  • Key: CORBA23-33
  • Legacy Issue Number: 2296
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The 2.3a draft defines DataOutputStream as having the following
    operation (see p. 5-12):

    void write_Abstract(in AbstractBase value);

    Yet there is no definition of the type `AbstractBase" anywhere
    in the document.

  • Reported: CORBA 2.2 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Add AbstractBase as a native type in the CORBA module, together with explanation in Chapter 6.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequences of recursive structs/unions

  • Key: CORBA23-32
  • Legacy Issue Number: 2275
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If I have a recursive struct or union type and want to pass a sequence
    of that type to an operation, I am completely stuck if I want to do
    this with C++. I"m not sure about other mappings, but I expect that
    Java, Ada, etc. will all suffer from the same problem.

  • Reported: CORBA 2.2 — Mon, 21 Dec 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA SINGLE_THREAD_MODEL description ambiguous

  • Key: CORBA23-35
  • Legacy Issue Number: 2308
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description for the SINGLE_THREAD_MODEL policy only states that the
    POA makes all upcalls in a manner that is safe for code that is
    multi-thread-unaware. This statement could be read to disallow
    recursive upcalls from one object implementation to another mediated by
    the same POA on a single thread.

    Proposed resolution:

    Add the following sentence to both sections 9.2.8 and 9.3.7, where the
    text defines the Single Threaded Model:

    A single-threaded POA will still allow recursive upcalls, where an
    object"s implementation invokes an operation on an object implemented
    using the same POA.

  • Reported: CORBA 2.2 — Mon, 18 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA threading policies

  • Key: CORBA23-34
  • Legacy Issue Number: 2303
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The POA offers the SINGLE_THREAD_MODEL policy. It guarantees that, for
    a POA with this policy, all invocations are serialized. (The only other
    threading policy, ORB_CTRL_MODEL, allows to ORB to thread invocations as
    it sees fit.)

    There is a pragmatic problem here: SINGLE_THREAD_MODEL guarantees
    serialization for only a particular POA. This means that if I have a server
    that uses three POAs, all of which use SINGLE_THREAD_MODEL, invocations on
    any one of these POAs are serialized but invocations on different POAs
    can be dispatched in parallel.

  • Reported: CORBA 2.2 — Sun, 10 Jan 1999 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception for abstract interface inheritance

  • Key: CORBA23-22
  • Legacy Issue Number: 2156
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Abstract interfaces can only inherit from other abstract interfaces,
    yet the Interface Repository chapter (98-10-08) does not define the
    behavior of an InterfaceDef object when an attempt is made to violate
    this rule.

    Text should be added to section 10.5.23.2 defining the behavior of
    the mutators is_abstract and base_interfaces.

    Since none of the BAD_PARAM minor codes really apply, it appears
    that a new one is needed.

  • Reported: CORBA 2.2 — Mon, 2 Nov 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

long double problem?

  • Key: CORBA23-21
  • Legacy Issue Number: 2119
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: (2.2 3-24) and (2.2 13-8)
    I"m no floating point expert, but it seems to me that these two
    definitions are inconsistent. The first implies 1 + 15 + 64 = 80
    bits of information, while the second implies 1 + 15 + 112 = 128 bits
    of information.

  • Reported: CORBA 2.2 — Fri, 23 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No inconsistency exists as explained in the archive.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Lifetime of ORB and validity of ORB pointe

  • Key: CORBA23-6
  • Legacy Issue Number: 1665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA 2.2 added the ORB::shutdown operation. What operations are
    valid during the potentially lengthy shutdown process while ongoing
    operations complete? What is the validity of the ORB reference after the
    shutdown? Is the ORB destroyed? Can a new ORB be reconstituted by
    ORB_init?

    This issue came up during the port-rtf discussion for CORBA 2.3. It goes
    beyond considerations for the POA so it should be addressed by
    orb_revision.
    r

  • Reported: CORBA 2.2 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Fix the problem as described below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of system exception completion_status

  • Key: CORBA23-5
  • Legacy Issue Number: 1315
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA 2.2 spec says the following about completion_status:

    Each standard exception also includes a completion_status code which
    takes one of the values

    {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}

    .
    These have the following meanings:

    COMPLETED_YES The object implementation has completed processing prior
    to the
    exception being raised.
    COMPLETED_NO The object implementation was never initiated prior to the
    exception
    being raised.
    COMPLETED_MAYBE The status of implementation completion is
    indeterminate.

    These definitions do not cover the case where the standard exception was
    raised by the object implementation itself.

  • Reported: CORBA 2.2 — Mon, 11 May 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What does interface substitutability mean in CORBA?

  • Key: CORBA23-17
  • Legacy Issue Number: 1997
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA
    revision work that is going on in ORMSC about what the ORB vendors think
    "substitutability" means.

  • Reported: CORBA 2.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Which OBV initialiser to run is under-specified

  • Key: CORBA23-16
  • Legacy Issue Number: 1981
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Detail: The 2.3 draft says:

    There may be any number of init declarations, as long as the signatures
    of all the initializers declared within the same scope are unique.

    To me, this implies that initialiser selection is done by matching the actual call parameter types against the formal parameter types in all the initialisers, and choosing the one that applies. However (a) this isn"t said explicitly and (b) if it is the intention, it"s fairly easy to construct a case where no one initialiser is more applicable than any other. Assuming initialiser parameters are allowed to be interface types (it doesn"t say they aren"t), consider a declaration of two initialisers in the same scope with parameter interfaces A and B, then calling the initialiser with a parameter of C, an interface that inherits from both A and B. It is impossible to say that one initialiser is more or less applicable than the other. The specification should make clear what choice a compliant ORB should make.

  • Reported: CORBA 2.2 — Sun, 20 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Handling of minor codes for standard exceptions underspecified

  • Key: CORBA23-12
  • Legacy Issue Number: 1969
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly
    underspecified. The text in 3.17.2 doesn"t actually mention the OMG
    space explicitly; it should. Also, the definition of the partitioning
    of the minor code, at the beginning of 3.17, is hopelessly vague – what
    ``high order bits"" are used, what ``low order bits""? What"s the
    policy for obtaining a new vendor registration?

  • Reported: CORBA 2.2 — Wed, 23 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c

  • Updated: Fri, 6 Mar 2015 20:58 GMT

page 3-47: Identifiers

  • Key: CORBA23-11
  • Legacy Issue Number: 1893
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 3-47:

    "Identifiers for the following kinds of definitions are scoped:

    • types
    • constants
    • enumeration values
    • exceptions
    • interfaces
    • attributes
    • operations"

    I"m not sure I understand the purpose of this list. In particular, what
    is meant by "are scoped"? Scoped by what? I think the intent was to state
    that if any of these identifiers appears within a nested scope, it needs
    to be unique only within that nested scope?

  • Reported: CORBA 2.2 — Thu, 27 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changes in 2.4 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing equality for DynAny

  • Key: CORBA23-14
  • Legacy Issue Number: 1972
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Type DynAny has no equality operator. This makes it impossible
    to determine whether or not two DynAnys contain the same value, unless
    I am prepared to recursively iterate over all of a DynAny"s components
    to determine whether they are equal. This is rather inconvenient.

    I would suggest to add a new operation to DynAny:

    boolean equal(in DynAny da);

  • Reported: CORBA 2.2 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    added comparison operator

  • Updated: Fri, 6 Mar 2015 20:58 GMT

set_servant_manager

  • Key: CORBA23-13
  • Legacy Issue Number: 1970
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What exception should POA::set_servant_manager raise if the wrong servant
    manager type is passed? For example, if a POA has RETAIN and I try to
    register a ServantLocator, should set_servant_manager raise WrongPolicy, or
    some system exception? With respect to set_servant_manager, the spec says

    "This method requires the USE_SERVANT_MANAGER policy; if not present, the
    WrongPolicy exception is raised."

    Because WrongPolicy is used to denote whether set_servant_manager can be
    called correctly or not, it seems like the wrong exception to also use for
    the case of passing the wrong servant manager type. May I suggest that
    BAD_PARAM be raised in that case instead?

  • Reported: CORBA 2.2 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate change in 2.4 and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Nested scopes

  • Key: CORBA23-10
  • Legacy Issue Number: 1892
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The name of an interface or a module may not be redefined within
    the immediate scope of the interface or the module. For example:

    module M {
    typedef short M; // Error: M is the name of the module
    in the scope of which the typedef is.
    interface I

    { void i (in short j); // Error: i clashes with the interface name I }

    ;
    };

  • Reported: CORBA 2.2 — Thu, 27 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Incorporate changed text and close issue in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple paths to a recursive sequence typecode

  • Key: CORBA23-9
  • Legacy Issue Number: 1802
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What exactly is the story for how the TypeCodes are created? Is there
    one call to create_recursive_sequence_tc per recursive sequence template in the
    source, or one per cycle in the type graph? I think this is worth clarifying
    in section 8.7.3, which doesn"t seem to conceive of the possibility of multiple
    type graph cycles through the same recursive sequence type.

  • Reported: CORBA 2.2 — Wed, 12 Aug 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This was fixed in the process of resolving issue 1928 in Core Revision 2.3a. See resolution of 1928.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change to IDL for anonymous types

  • Key: CORBA23-8
  • Legacy Issue Number: 1729
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Secondly, anonymous types are generally a pain to deal with
    for a language mapping. I know that anonymous sequences are
    a necessary evil because they are needed to define recursive
    structs and recursive unions. For example:

    struct node

    { long data; sequence<node> children; }

    ;

    However, IDL allows anonymous sequences and arrays to be used
    in other ways for which they are not essential.

  • Reported: CORBA 2.2 — Thu, 23 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynStruct::get_members needs exception

  • Key: CORBA23-7
  • Legacy Issue Number: 1679
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If get_members is called on a DynStruct whose members have not been
    initialized, what should it do? It can"t return any values, because there
    are none.

    I suggest allowing it to raise DynAny::Invalid in this case. If there are
    objections to adding a raises clause, I suggest having it raise BAD_INV_ORDER.

  • Reported: CORBA 2.2 — Tue, 14 Jul 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorproate changes and close issue in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive exceptions?

  • Key: CORBA23-20
  • Legacy Issue Number: 2084
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is the following IDL legal?

    exception e

    { sequence<e> e_seq; }

    ;

    The grammar permits it, so from that, I would have to conclude it"s legal.
    However, not all ORBs I"ve tried can handle this – some accept it and it
    works, others accept it but generate bad code, and yet others won"t compile
    the IDL.

  • Reported: CORBA 2.2 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

InconsistentTypeCode exception in CORBA 2.3

  • Key: CORBA23-19
  • Legacy Issue Number: 2070
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current CORBA 2.3 ORB interface chapter (ptc/98-08-08) does not
    match the resolution which was voted on for the InconsistentTypeCode
    exception (issue 1089).

    The proposed resolution from ptc/98-05-01 was to place the exception
    in the ORB interface with InvalidName, not in the CORBA module.
    Jishnu, could we correct this mistake by moving InconsistentTypeCode
    from the CORBA module into the ORB interface?

  • Reported: CORBA 2.2 — Sat, 10 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Already fixed in 2.3a Draft

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive IDL types

  • Key: CORBA23-18
  • Legacy Issue Number: 2034
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current spec is not terribly clear on how recursive IDL types are
    supposed to work.A minor problem here is that the terminating semicolon is missing following
    the closing curly brace.

    But more seriously, it leaves it open whether, for example, the following
    is legal:

    struct foo {
    union u switch (long)

    { case 0: sequence<foo> foo_mem; case 1: char c_mem; }

    u_mem;

    long l_mem;
    };

  • Reported: CORBA 2.2 — Mon, 5 Oct 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DynUnion::member()

  • Key: CORBA23-15
  • Legacy Issue Number: 1974
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does DynUnion::member() return if a union does not have a default
    case label and has no active member? A nil reference? A DynAny
    with TCKind tk_null?

    It"s not specified, but should be.

  • Reported: CORBA 2.2 — Thu, 17 Sep 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    incorporate change and close in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolve_initial_references under-specified

  • Key: CORBA23-4
  • Legacy Issue Number: 1156
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: resolve_initial_references can raise an InvalidName exception. However,
    the text in section 4.5 does not attach any semantics to that exception
    (in fact, it does not mention the exception at all).

    The spec needs to state explicitly when InvalidName should be raised.
    Presumably, the intent was that it would be raised for unknown ObjectIds,
    such as "XXXX".

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Needs no further action in Core RTF. Close this issue no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain Manager related specification shortcoming (02)-ConstructionPolicy

  • Key: CORBA23-3
  • Legacy Issue Number: 1154
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) The associated ConstructionPolicy object does not provide any
    facility for allocating an object reference to any domain manager other
    than the domain manager to which the creator (if an object) belongs or a
    completely new domain manager.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is included in the mandatory requirements of the Security Domain Membership management R

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Domain manager related specification shortcoming(s) (01)

  • Key: CORBA23-2
  • Legacy Issue Number: 1153
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The specification lacks any operations for moving an object reference
    from one domain manager to another, thus making the domain manager
    abstraction less useful as a means for managing allocation of policies
    to groups of object references, the memberships of which change over a
    period of time.

  • Reported: CORBA 2.2 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    This issue is included in the mandatory requirements of the Security Domain Membership Management R

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation to add to CORBA::ORB pseudo-object

  • Key: CORBA23-1
  • Legacy Issue Number: 991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following operations should be added to the CORBA::ORB
    pseudo-object:

    module CORBA {
    interface ORB

    { ... typedef sequence<octet> SerializedData; typedef unsigned long SerializedEncoding; const SerializedEncoding CDR_ENCODING = 0; SerializedData serialize(in Any data, in SerializedEncoding how); Any unserialize(in SerializedData data, in SerializedEncoding how); ... }

    ;
    };

  • Reported: CORBA 2.2 — Wed, 4 Mar 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.3
  • Disposition Summary:

    Close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

marshalling service context

  • Legacy Issue Number: 905
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The question is: What is the exact marshalling for an encapsulation
    of a zero length sequence? (Service context is an encapsulation of a
    sequence. CORBA 2.1, Section 10.6.7, page 10-22.)
    While it may or may not be an ambiguity,
    it does appear that ORB vendors differ in their interpretations, so
    it might be important to clarify it.

  • Reported: CORBA 2.1 — Wed, 14 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment and offsets in the presence of fragmentation

  • Legacy Issue Number: 904
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Its not clear to me how octet indices used for alignment and for
    TypeCode indirection offsets are calculated in the presence of
    fragmentation. Different interpretations will prevent successful
    interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changes to and strategy for 1.2

  • Legacy Issue Number: 886
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are 2 changes:
    1. add the request id to message fragments so that fragmentation is usable.
    2. change the alignment rules so that message headers may be changed
    without having to remarshal the body.
    [ as an aside we"d really like to remove all the alignment rules so that
    any"s no longer have to be double marshaled, but we don"t think its
    possible to deal with all the details quickly ]
    3. Add some more addressing information to request, locate_request,etc.

  • Reported: CORBA 2.1 — Thu, 8 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type ids in OBJECT_FORWARD return message

  • Legacy Issue Number: 74
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of dynamic ports

  • Legacy Issue Number: 382
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Object::non_existent

  • Legacy Issue Number: 126
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct IIOP marshalling of union TypeCodes

  • Legacy Issue Number: 89
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.

  • Reported: CPP 1.0b1 — Thu, 22 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

LOCATION_FORWARD byte alignment

  • Legacy Issue Number: 77
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision from issue 901, 902

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2 XML file appears to contain EA proprietary elements

  • Key: CTS2F2-82
  • Legacy Issue Number: 16347
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Looking at 11-06-20.xml, I see elements such as <thecustomprofile:interface base_Class="EAID_F37A3B0D_CFE6_448a_A95F_26FDC113F2A2"/>, which are EA-specific representations. This needs to be fixed to be properly XMI compliant.

  • Reported: CTS2 1.0b1 — Thu, 23 Jun 2011 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM: N/A
    The UML 2.x Specification insists that Stereotypes be bound to a
    profile.
    But in EA, users can freely type-in any name in the "Stereotype" field (
    in the "Properties" dialog of a construct ).
    Such freely typed-in stereotypes do not belong to any profile.

    When exporting to XMI 2.x, we cannot export a stereotype unless we
    specify its profile.
    So, we create a dummy profile called "thecustomprofile" in the namespace
    http://www.sparxsystems.com/profiles/thecustomprofile/1.0 and bind all
    the freely typed-in stereotypes to this profile.

    For example, refer to the attached Snapshot.png - Class1's stereotype is
    "opt" ( I typed-in this in the "Stereotype" field in the "Properties"
    dialog of the class ) & Activity1 is a BPMN 2.0 activity.
    When exported to XMI 2.x, the stereotype "opt" is linked to
    "thecustomprofile" as underlined in green.

    NOTE :
    XML Namespace is just a method to avoid name conflicts & using the
    namespace http://www.sparxsystems.com/profiles/thecustomprofile/1.0
    doesn't means that our XMI is OMG in-compliant.
    If you want, you can manually change the namespace of the
    "thecustomprofile" ( or any other profile used in the XMI file ) from
    http://www.sparxsystems.com/profiles/thecustomprofile/1.0 to the desired
    namespace ( at the location boxed in brown ).

    Revised Text:
    PIM: N/A
    PSM: N/A
    N\A - No Change Necessary

    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in PIDL to C++ mappings

  • Legacy Issue Number: 804
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
    A number of the PIDL classes include a member function _duplicate.
    It should be declared as a static member function
    with an argument; i.e. the pointer to be "duplicated".

  • Reported: CORBA 2.1 — Thu, 4 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in C++ mapping

  • Legacy Issue Number: 732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

  • Reported: CORBA 2.1 — Thu, 25 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C mapping for list_initial_services is incorrect

  • Legacy Issue Number: 621
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.29: The C mapping for list_initial_services is incorrect and should return a pointer to a sequence (example in corresponding archive file)

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defintion of Any

  • Legacy Issue Number: 147
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of Any in C.3 is missing the no_copy flag in the class Any::from_string.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any extractor signature problem

  • Legacy Issue Number: 146
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the Any extractor signature be (Any_ptr &) instead of (Any &)?

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Any inserter

  • Legacy Issue Number: 145
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following inserter is missing in the C++ spec: void operation <<=(Any &, Any *); // non-copying

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP object pointer resetting

  • Legacy Issue Number: 55
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.

  • Reported: CPP 1.0b1 — Tue, 16 Jul 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional enumeration to the ReplyStatusType

  • Legacy Issue Number: 807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add an additional enumeration to the ReplyStatusType (and
    LocationStatusType) called LOCATION_FORWARD_PERM (and
    OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
    OBJECT_FORWARD), but can be used as a hint by the client that it should
    permanently discard the original IOR and replace it with the new IOR.

  • Reported: CORBA 2.1 — Wed, 10 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Additional Requirement for GIOP 1.2

  • Legacy Issue Number: 798
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement
    that an eight byte alignment occur before the body of any message.
    This allows for numerous optimizations that currently cannot be performed
    because the alignment of the beginning of the bodies is not consistent.

  • Reported: CORBA 2.1 — Mon, 22 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification on IIOP2.1 12.3.2 fixed point type representation needed

  • Legacy Issue Number: 782
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close with no change: The scale information is in the IDL definition of the fixed-point type

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 12.7.2 type IIOP::ProfileBody_1_0 not compatible

  • Legacy Issue Number: 885
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is
    supposed to be compatible with the type ProfileBody of earlier
    versions of CORBA. Unfortunately, it has a different repository
    ID, leading to incompatibilities.
    Proposed change: Add two pragmas to section 12.7.2, inside
    the module IIOP

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP marshalling of empty strings

  • Legacy Issue Number: 817
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add a rule to CDR that allows an empty string to be marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.
    For a structure with five simple data members, this reduces the size of the
    TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

  • Reported: CORBA 2.1 — Mon, 1 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with GIOP CancelRequest when fragments are used

  • Legacy Issue Number: 488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)

  • Reported: CPP 1.0b1 — Thu, 30 Jan 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transport Level Bridge

  • Legacy Issue Number: 465
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol

  • Reported: CPP 1.0b1 — Wed, 4 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by "NeedAddressingInfo" change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL Type Extensions: wstring CDR encoding issue

  • Legacy Issue Number: 586
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1.2 p. 20 : Implementation needs to know whether it is byte-oriented or not, since CDR representation is different in each case. ORB expected to maintain table mapping of all codesets?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL Type Extensions: wchar and wstring CDR encoding

  • Legacy Issue Number: 585
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 4.1 GIOP CDR Transfer Syntax: The spec should cover cases where TCS-W is byte-oriented or non-byte oriented

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    duplicate to closed issue 1096

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.0 backward compat (2)

  • Legacy Issue Number: 592
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Assuming a 1.1 server we must Reply using 1.o to Request sent from 1.o client. If we get request with junk revision (eg 2.2) we wil automatically send (1.1) MessageError, but connection is close

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, accomodated by clarification of version semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1.0 backward compat (1)

  • Legacy Issue Number: 591
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If 1.1 client sends request to 1.0 server and tis causes 1.0 MessageError msf from serverthen 1.1 client must recognize MessageErrors from 1.o servers

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    accomodated by clarification of version semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IORs and identifying Object Keys

  • Legacy Issue Number: 460
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion

  • Reported: CPP 1.0b1 — Thu, 5 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Callbacks in IIOP

  • Legacy Issue Number: 383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.

  • Reported: CPP 1.0b1 — Mon, 2 Dec 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fragment improvements (2)

  • Legacy Issue Number: 590
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fragment improvements (1)

  • Legacy Issue Number: 589
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    fixed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type extensions char code set negotiation

  • Legacy Issue Number: 574
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This negotiation adds 16 bytes to both request and reply messages. It"s overburdening an already obese message header scheme.

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed, no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type Extensions and code set negotiation

  • Legacy Issue Number: 573
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 26 of ptc/97-01-01: replace "Code set negotiation is not....." with"Code set negotiation is performed on a per-request basis."

  • Reported: CORBA 2.0 — Wed, 14 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with no revision required

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with service context

  • Legacy Issue Number: 651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What should an ORB do when it gets a message with an unknown service context ID value?

  • Reported: CORBA 2.0 — Mon, 4 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revision

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CloseConnection messages

  • Legacy Issue Number: 593
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1.1 client may get 1.0 CloseConnection prior to first attemptto send Requests which it needs to recognize. Spec should clarify this.

  • Reported: CORBA 2.0 — Tue, 17 Jun 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed with revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union typecode (02)

  • Key: CORBA22-96
  • Legacy Issue Number: 812
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. I cannot locate where the definition of typecodes for unions with
    members with multiple labels. The natural semantics with respect to
    the member accessor operations on that typecode and the CDR
    marshalling of that typecode would seem to be that the union
    declaration is treated as if the member definition in question were
    replicated once for each label.

  • Reported: CORBA 2.1 — Tue, 23 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

locally constrained

  • Key: CORBA22-95
  • Legacy Issue Number: 797
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the consensus for the notation to use for interfaces to objects
    that are in the orb but not outside. We use to call them psuedo objects.
    During the last talk I got the feel that there are three options:

    1. //PIDL
    2. "psuedo" keyword placed before "interface"
    3. //locally constrained

  • Reported: CORBA 2.1 — Tue, 9 Dec 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL types are ambiguous with inheritance

  • Key: CORBA22-94
  • Legacy Issue Number: 783
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the return type of parent(), short or long? The spec does not say whether the inherited ::y::y::z takes precedence, or whether it is ::x::z. The scope resolution rules don"t mention how to resolve such an ambiguity. The spec should be updated to state that ::x::z takes precedence (IDL example in corresponding archive "issue783")

  • Reported: CORBA 2.1 — Tue, 25 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close noting that this has been explained in Revised Chapter 3.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about typecode creation

  • Legacy Issue Number: 911
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Consider the following operation in the ORB pseudointerface:

    TypeCode create_union_tc (
    in RepositoryId id,
    in Identifier name,
    in TypeCode discriminator_type,
    in UnionMemberSeq members)

    Suppose that in some mapping this is invoked with the given arguments,
    i.e. an id, a name, a discriminator_type, and members..
    For concreteness, suppose that the id argument has the value
    "IDL:foo/bar:1.0".

    There are three main cases:<<Go to issue archive>>

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i

  • Updated: Fri, 6 Mar 2015 20:58 GMT

#pragma processing

  • Key: CORBA22-99
  • Legacy Issue Number: 910
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 7-32, the 2.1 spec says about #pragma processing:
    An IDL compiler must either interpret these annotations
    as specified, or ignore them completely.
    I don"t think this makes sense.
    If the prefix pragma isn"t honored in one ORB, but used by another ORB,
    the repository IDs will disagree for types generated from the same
    IDL definition, but with different IDL compilers. This in turn means
    that interoperability is destroyed.

  • Reported: CORBA 2.1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of 999 , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Contained::describe() underspecified

  • Legacy Issue Number: 918
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The describe() operation of the CORBA::Contained interface of the
    Interface Repository is under-specified in CORBA 2.1. (section 7.5.3
    on page 7-12). The text should add that the "kind" field of the returned
    Description struct should give the DefinitionKind for the "most derived"
    type of the object. Without this, the spec can be read as allowing
    describe() to return a kind of dk_Typedef, or even dk_all!

  • Reported: CORBA 2.1 — Sun, 25 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate the proposed clarification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity in non_existent() specification

  • Key: CORBA22-98
  • Legacy Issue Number: 903
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a minor ambiguity here. Consider the case where the ORB cannot
    make a reliable determination because the client-side run-time cannot
    reach the implementation repository or the server. In that case, most
    ORBs will raise a TRANSIENT or COMM_FAILURE exception. I can read the
    above words in the spec to mean that a compliant implementation of
    non_existent is allowed to hide the exception from me and return false
    instead.
    I suggest to amend the wording such that non_existent is obliged to propagate
    any exception other than OBJECT_NOT_EXIST back to the caller.

  • Reported: CORBA 2.1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Sugested text below , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Appendix B lists incorrect CORBA Components IDs

  • Key: CORBA22-97
  • Legacy Issue Number: 884
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. Appendix B lists the CORBA Component IDs. This listing is
    incorrect: Proposed resolution: Change Appendix B to correspond to the
    main text.

  • Reported: CORBA 2.1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution: Change Appendix B to correspond to the

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Trader constraint language and international characters

  • Legacy Issue Number: 915
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the trader constraint language (page 16-98, 2.1 spec) defines a
    character class "<other>". This class is used in the definition of
    what characters may appear inside a string literal (on page 16-97).
    The problem is that the definition limits the legal character values
    that may appear in a string literal. Only character positions 0x1
    to 0x7f are legal, anything else is illegal.

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Replace section B.2.3 with corresponding text from the ISO Trader standard

  • Updated: Fri, 6 Mar 2015 20:58 GMT

defined_in member of ModuleDescription for top-level module

  • Legacy Issue Number: 913
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the value member of what is returned by
    CORBA::Contained::describe when invoked on a CORBA::ModuleDef object
    corresponding to a top-level IDL module?

  • Reported: CORBA 2.1 — Wed, 21 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of Exceptions

  • Legacy Issue Number: 912
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is a request to add an optional extension to IDL which would
    permit an exception declaration to include a specification of the
    superexception or superexceptions for a given exception, exactly the
    same way superinterfaces may be specified when defining an interface.The advantage of this extension is that it (optionally) permits
    interface designers to organize exceptions into categories, which can
    help clarify the design of the exceptions.

  • Reported: CORBA 2.1 — Thu, 22 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RIDs

  • Key: CORBA22-93
  • Legacy Issue Number: 780
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of IDL Repository IDs the example in the IFR chapter 7.6.6 indicates that prefixes when not set are not separated. Definition says that "typically" it is the prefix and scoped name separated with "/".

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed with sepcific example in section 10.6.5.2 in Rev 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Containers

  • Key: CORBA22-92
  • Legacy Issue Number: 779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On the issue of making StructDef, UnionDef, and ExceptionDef inherit from container, would it be possible to introduce the depreciation of including anything other than members in these three types?

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect definition of "object type"

  • Legacy Issue Number: 917
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The definition of interface and object type in the Object Model
    are imprecise, if not incorrect. [See section 1.2.5 of the Corba 2.1
    spec (Aug 1997)]

  • Reported: CORBA 2.1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify as follows

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Resetting #pragma prefix?

  • Legacy Issue Number: 916
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the spec doesn"t say how I can reset a repository ID prefix back to nothing
    after I have set it. Consider

    #pragma prefix "dstc.edu.au"
    interface foo {};
    #pragam prefix "" // Attempt to reset prefix
    interface bar {};

    This doesn"t work with at least one ORB I have tried.

  • Reported: CORBA 2.1 — Mon, 26 Jan 1998 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of issue 999 , close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Proposed IFR exceptions

  • Key: CORBA22-91
  • Legacy Issue Number: 778
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {};

  • Reported: CORBA 2.1 — Fri, 7 Nov 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate changes in 2.3a and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypedefDef issue

  • Key: CORBA22-90
  • Legacy Issue Number: 777
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it legal for a TypedefDef to contain another TypedefDef that is NOT mentioned in it"s "members" attribute? If not, should the IR spec explicitly forbid this?

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.1 IR Structdef typo

  • Key: CORBA22-89
  • Legacy Issue Number: 776
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Read Interface" section of 7.5.10: The second sentence is a typo. The StructDef as a whole can "contain" structs, unions, and enums. However, the members attribute is a CORBA IDL data type not a subtype of Container, and hence cannot "contain" anything in the sense used elsewhere in the IR spec. The sentence should be deleted

  • Reported: CORBA 2.1 — Thu, 30 Oct 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove the second sentence in section 8.5.10 of Rev 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with ObjectId_to_string and string_to_ObjectId

  • Key: CORBA22-85
  • Legacy Issue Number: 749
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 18.4 "illegal characters": It should be clarified what corresponds to the concept of "illegal characters". On the othe hand, do we want to specify that ObjectIds generated by the POA should not include those "illegal characters?

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bug in the 2.1.spec for IDL unions

  • Key: CORBA22-84
  • Legacy Issue Number: 727
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Table 3-11 on page 3-26 shows wchar as al legal switch type for unions. The grammar on page 3-26 doesn"t have wchar as a legal switchtype. The same is true for grammar on page 3-13. Is wchar legal for union discriminator? Spec will need to be fixed

  • Reported: CORBA 2.1 — Fri, 17 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 2-2 in CORBA 2.0 and CORBA 2.1

  • Key: CORBA22-83
  • Legacy Issue Number: 726
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the figure all the interfaces/skeletons/adaptors/stubs have either an Up-call or a Normal-call arrow or both with the exception of the Dynamic Skeleton which has neither

  • Reported: CORBA 2.1 — Thu, 18 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add an Up-Call Arrow to the Dynamic skeleton box.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Octet and enum constants

  • Key: CORBA22-82
  • Legacy Issue Number: 725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL should permit enum and octet constants.

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The following changes add enum and octet constants to IDL:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non ASCII alphabetics in IDL identifiers

  • Key: CORBA22-81
  • Legacy Issue Number: 724
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL identifiers can contain non-ASCII alphabetic characters. None of the language maappings deals with this. To fix this restrict IDL identifiers to ASCII characters, digits and underscore

  • Reported: CORBA 2.1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Native types with respect to typecodes, DII, DSI,Interface Reposit.

  • Key: CORBA22-80
  • Legacy Issue Number: 666
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details)

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Proposed resolution is to add representation of native type in the IR. Details below as proposed by

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode equality

  • Key: CORBA22-79
  • Legacy Issue Number: 665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: TypeCode equality is not very well-specified or portable.

  • Reported: CORBA 2.0 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate more complete specification as shown below:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor bug in 2.1 spec

  • Key: CORBA22-88
  • Legacy Issue Number: 754
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer

  • Reported: CORBA 2.1 — Tue, 21 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    incorporate changes in 2.3 and close this issue and 1066.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheriting exceptions in IDL

  • Key: CORBA22-87
  • Legacy Issue Number: 753
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When writing IDL, why is it not possible to have an exception declaration inherit from another exception? It"s possible to have an interface inherit another interface, so it seems logical to derive an exception class from an already declared exception area

  • Reported: CORBA 2.1 — Thu, 23 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with no change with the above explanation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inclusion of standard exception

  • Key: CORBA22-86
  • Legacy Issue Number: 751
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The proposal is to define a new standard exception, called
    EXTERNAL_ACCESS (the name is not important) that carries
    an any value. Another alternative may be to re-define
    the exception COMM_FAILURE so that it may carry an any in
    addition to the existing minor and completed fields.

  • Reported: CORBA 2.1 — Mon, 6 Oct 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Syntax for basic types must be updated

  • Key: CORBA22-75
  • Legacy Issue Number: 611
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.8.1: The syntax for basic types must be updated to include the adopted IDL type extensions.

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

create_exception() is declared outside any interface scope

  • Key: CORBA22-74
  • Legacy Issue Number: 610
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.8: The create_exception() methos is declared outside any interface scope. It seems logical to move it to Container Interface along with other create_XXX() methods

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TCKind enum should be updated

  • Key: CORBA22-73
  • Legacy Issue Number: 609
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.8: TCKind enum should be updated to include adopted IDL type extensions as follows: tk_longlong, tk_longdouble, tk_wstring, tk_wchar. Update DefinitionKind and PrimitiveKind enum

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do identifiers and keywords clash if they differ in case?

  • Key: CORBA22-78
  • Legacy Issue Number: 641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.2.3 and 3.2.4: It"s not said explicitly that an identifier may not differ from a keyword only in case since it differs only in case from a keyword

  • Reported: CORBA 2.0 — Wed, 30 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2+, Close

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.7.2: take new IDL type extensions into account

  • Key: CORBA22-77
  • Legacy Issue Number: 624
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The section states that the <<and>> operands must be in the range 0 to 32. Should be changed to 0 to 64 to take new IDL type extensions into account

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.8: editorial

  • Key: CORBA22-76
  • Legacy Issue Number: 623
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.8: ; is missing from definition of attribute policy_type

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close, Fixed in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sec 17.7.1: IDL for interface request doesn"t match C++ mapping

  • Key: CORBA22-70
  • Legacy Issue Number: 598
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for interface Request does not match the C++ mapping. There are a series od add_arg methods in the mapping that should be added to the IDL.

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Language mappings are allowed to have custom mappings for pseudo-interfaces.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence parameter specified is ignored

  • Key: CORBA22-69
  • Legacy Issue Number: 597
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why does mapping ignore the sequence parameter specified in the IDL for the initialization service and split this single parameter into 2 separate ones in the mapping?

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping

  • Updated: Fri, 6 Mar 2015 20:58 GMT

request() should be added to IDL (section 17.13.2)

  • Key: CORBA22-68
  • Legacy Issue Number: 596
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Object C++ mapping has an _request() method that is not in the IDL. This method should be added to the IDL

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.7: only C++ mapping defines string_free and string_dup

  • Key: CORBA22-67
  • Legacy Issue Number: 595
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only the C++ mapping defines string_free and string_dup. Why are these methods not present in other language mappings? If they are generally applicable they should be added to the IDL

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    They are C++ language specific helper functions, that is why they are in the C++ mapping section. T

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No defined value for OBJECT_NIL

  • Key: CORBA22-72
  • Legacy Issue Number: 607
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.2.3: reference is made to OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.2: get_implementation function

  • Key: CORBA22-71
  • Legacy Issue Number: 604
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Why does Object have a get_implementation function instead of a readonly implementation attribute? (likewise for get_interface)

  • Reported: CORBA 2.0 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Closed; No Change — CORBA 2.2
  • Disposition Summary:

    closed issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"service"~~operation or interface?

  • Key: CORBA22-64
  • Legacy Issue Number: 570
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does a service consist of single operation, or a collection of related operations, exceptions, types, and constants?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Cleaning up the use of the word service throughout the document does not seem to be an achievable g

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What exactly is a request

  • Key: CORBA22-63
  • Legacy Issue Number: 569
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: One may expect it to be a reply or response.Reading chapters 1,4,5 makes clear that it is the entirety of an invocation of an operation, including request and response. Change possible soon?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarify the sense in which the term Request is used in section 1.2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Scope and use of prefix pragma in IDL-style repository IDs

  • Key: CORBA22-61
  • Legacy Issue Number: 567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is confusion about effect of "prefix" pragma evident in the Interface Repository chapter. Whole notion of prefix should be explained more fully in section 6.6.1

  • Reported: CORBA 2.0 — Mon, 12 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Terminology consistency

  • Key: CORBA22-60
  • Legacy Issue Number: 565
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships?

  • Reported: CORBA 2.0 — Tue, 20 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved closed issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.6.4 Pragma Directives for RepositoryId Para 1 - objection

  • Key: CORBA22-52
  • Legacy Issue Number: 444
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Conforming compilers should ignore pragmas that are not defined. in this spec, and that they do not explicitly support. Portable applications should only use pragmas defined in this spec.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.6.1 OMG IDL Format Paragraph 5 - comment

  • Key: CORBA22-51
  • Legacy Issue Number: 443
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of minor version number changes should be a requirement on conforming applications (objects).

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    That"s what the sections appears to say. close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.2 TypeCode Constants Last Paragraph - comment

  • Key: CORBA22-56
  • Legacy Issue Number: 448
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that form of TypeCode constants might be implementation specific.Does that mean the contents of the TypeCode implementation as opposed to signature of programmer?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Offending language has been removed in Revision 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.1 The Type Code Interface Paragraph 4 - comment

  • Key: CORBA22-55
  • Legacy Issue Number: 447
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Last sentence: It"s not clear under which conditions this is permitted. It"s permitted when a structure,union,enumeration or alias typecode wasn"t obtained from Interface Repository.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2 close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Enums and enumerators

  • Key: CORBA22-59
  • Legacy Issue Number: 545
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

  • Reported: CORBA 2.0 — Thu, 10 Apr 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Internationalization

  • Key: CORBA22-58
  • Legacy Issue Number: 499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: New Idl types have been introduced to cover non-ISO code sets.Sec 5.4.1 indicates that where "generic strings" are required in a spec "wstring"should be used. Place holder in naming spec: Istring

  • Reported: CORBA 2.0 — Wed, 12 Feb 1997 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    not interpretable, closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7.1 The TypeCode Interface All Paragraphs - objection

  • Key: CORBA22-54
  • Legacy Issue Number: 446
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: PIDL for this interface describes the exceptions that might be raised, but the text doesn"t define the conditions when all of those exceptions might occur. This must be addressed.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Fixed in 2.2 close no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.7 TypeCodes Paragraph 3 - objection

  • Key: CORBA22-53
  • Legacy Issue Number: 445
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s better to say "However, TypeCode "literals" shall have a representation such that they can be placed in C include files."

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Offending sentence removed in the resolution of issue 73. This is the same as issue 73

  • Updated: Fri, 6 Mar 2015 20:58 GMT

limited-length strings

  • Key: CORBA22-66
  • Legacy Issue Number: 588
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section?

  • Reported: CORBA 2.0 — Thu, 29 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3a and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Question about IDL grammar

  • Key: CORBA22-65
  • Legacy Issue Number: 571
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

  • Reported: CORBA 2.0 — Tue, 6 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    subsumed by issue 725

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORE spec reference

  • Key: CORBA22-57
  • Legacy Issue Number: 459
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORE contains specific language binding information which should be in a language binding chapter or in a new appendix

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Such information now exists only in the way of examples of what a particular piece of pseudo-IDL me

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inherit vs. include

  • Key: CORBA22-62
  • Legacy Issue Number: 568
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Ther is sense in which an interface "includes" operations it inherits from its base interface.Does it also "include" types, constants, and exceptions?

  • Reported: CORBA 2.0 — Wed, 21 May 1997 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue with annotation fixed in Rev 2.2+

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.22 InterfaceDef Paragraphs 7 and 8 - comment

  • Key: CORBA22-50
  • Legacy Issue Number: 442
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: These paras indicate that an error is returned if the ID already exists in the repository. What is the error and what happens of the IR supports versioning?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.22 InterfaceDef Paragraph 6 - comment

  • Key: CORBA22-49
  • Legacy Issue Number: 441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This Para indicates that the base_interface attribute can return an error if there are name conflicts. What error is returned?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Subsumed by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.20 AttributeDef Paragraph 2 - comment

  • Key: CORBA22-48
  • Legacy Issue Number: 440
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What does the describe operation return for this interface?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Add the sentence "The describe operation for an AttributeDef object returns an AttributeDescription

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 6 - editorial

  • Key: CORBA22-38
  • Legacy Issue Number: 427
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para starts the description of the arguments for the lookup_name operation. It should stand out more instead of being intended in such a way that it looks like part of previous item"s description.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    changed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 5 - comment

  • Key: CORBA22-37
  • Legacy Issue Number: 426
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para descibes exclude_inherited argumentto the content operation. Format is poor, it"s not clear what the default setting for this argument might be (if any).

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change required, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 2 - objection

  • Key: CORBA22-36
  • Legacy Issue Number: 425
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It"s not clear what lookup operation returns when it is successful. We can tell from the IDL, but it should be explicitly defined. We think it returns object reference to scoped name.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change required, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained Paragraph 10 - comment

  • Key: CORBA22-35
  • Legacy Issue Number: 424
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that name attribute is changed to new_name, and version attribute is changed to new_version. If name already exists and IR doesn"t support versioning=error. What error?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Subsumed by 778 . Closed with that annotation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 15 - comment

  • Key: CORBA22-43
  • Legacy Issue Number: 432
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para describes create_<type> operations. It indicates that there are errors returned under differing circumstances. Possible errors should be defined.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 12 - comment

  • Key: CORBA22-42
  • Legacy Issue Number: 431
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para refers to the describe operation. This operation is part of the parent interface from which container interface is inherited.There should be a pointer to the parent interface

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.10 StructDef Last paragraph - comment

  • Key: CORBA22-46
  • Legacy Issue Number: 438
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove the phrase "is ignored" from the last sentence of section 8.5.9 rev 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.8 ConstantDef Interface Paragraph 2 - comment

  • Key: CORBA22-45
  • Legacy Issue Number: 437
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There should be a pointer to the list of simple types.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Replace the phrase "simple type( ..... )" by the phrase "primitive types allowed in a constant decl

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 10 - comment

  • Key: CORBA22-40
  • Legacy Issue Number: 429
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This para and para 4 both describe a limiy_type argument. These should be described in the same way since they appear to have the same semantics

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 8 - comment

  • Key: CORBA22-39
  • Legacy Issue Number: 428
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What other values of levels_to_search are legal? What happens if values other than those described are used?Is an exception raised? If so, what exception?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.6 Repository Paragraph 4 - comment

  • Key: CORBA22-44
  • Legacy Issue Number: 435
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This Para refers to a PrimitiveDef. There should be a pointer to where this is defined.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    In section 8.5.6 second para under Read Interface, add a cross reference to section 8.5.13 where Pr

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.11 UnionDef Last Paragraph - comment

  • Key: CORBA22-47
  • Legacy Issue Number: 439
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.4 Container Paragraph 11 - comment

  • Key: CORBA22-41
  • Legacy Issue Number: 430
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Same as issue # 429 with respect to 6.5.4 Container Paragraph 5.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate resolution and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained - Paragraph 7 - comment

  • Key: CORBA22-34
  • Legacy Issue Number: 423
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This initial Para of the Write Interface section indicates that an error is returned if an object with specified ID attribute already exists. Error should be specified.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close with annotation as above.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.3 Contained Paragraph 2 - comment

  • Key: CORBA22-33
  • Legacy Issue Number: 422
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Para indicates that IRs are not required to support simultaneous containment of multiple versions of the same named object. Required that IRs are able to handle multiple versions of objects

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.5.2 IRObject Paragraph 3 - objection

  • Key: CORBA22-32
  • Legacy Issue Number: 421
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Write Interface description indicates that it is error to invoke destroy on a Repository or PrimitiveDef. Should state that behavior is undefined.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6 Context Object Operations, Para 2 - objection

  • Key: CORBA22-22
  • Legacy Issue Number: 399
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Spec reads " Property names are stored preserving their case, however names cannot differ simply by their case." This sentence should be deleted.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose to apply resolution as above and close issue in 2.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.2.2 add_arg Paragraph 5-comment

  • Key: CORBA22-21
  • Legacy Issue Number: 397
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: X/Open believes there is no need to use different wording. They don"t believe that it is useful to indicate that mixing of methods might be allowed someday

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    In Section 5.2.2 Para 5 Rev 2.2 remove the word "currently" from the last sentence

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.2 set_on_value Paragraph 2 - objection

  • Key: CORBA22-24
  • Legacy Issue Number: 402
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Text reads:"Currently, only string values are supported by the context object." Sentence should be deleted, since PIDL requires that a string be the value provided

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose apply resolution to rev 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.3.1 sen3 - comment 23 - comment

  • Key: CORBA22-23
  • Legacy Issue Number: 400
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: X/Open recommends that this para is being reworded to require that applications call get_response after a send. Spec could also be modified to detect errors if response is not required

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 5 - objection

  • Key: CORBA22-28
  • Legacy Issue Number: 406
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Text reads " If the specified scope name is not found, an exception is returned." Error to be indicated must be specified. See objection for Paragraph 2.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    See resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 4 - objection

  • Key: CORBA22-27
  • Legacy Issue Number: 405
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Text indicates that "Value scope names are implementation-specific." Items not necessary for portable development of applications are unspecified,undefined.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Remove paragraph 4. Does not add any value to the spec.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.4 get_values Paragraph 2 - objection

  • Key: CORBA22-26
  • Legacy Issue Number: 404
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The error to be returned must be specified.. Since a status is not required to be returned, it"s incorrect to say that error is returned. Exception is raised.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    add text to sections 5.6.4, 5.6.5 and 5.6.7 stating what exceptions are raised under what condition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.3 set_values

  • Key: CORBA22-25
  • Legacy Issue Number: 403
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: See comment on set_value in issue # 402

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Propose apply resolution to rev 2.3 and close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1.1 Common Data Structures, Paragraph 6, comment

  • Key: CORBA22-18
  • Legacy Issue Number: 393
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The usage of len could easily lead to a situation where it was inconsistent with TypeCode through erronous usage. WOuld be great if standard System exception was available for this case.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Close no change in 2.3a

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface for managing interceptors is missing

  • Key: CORBA22-17
  • Legacy Issue Number: 380
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: List of interceptors to be called during request and order in which interceptor will be called: Needs to be resolved by Alec Thomas but shouls also be moved to ORB RFT

  • Reported: CORBA 1.2 — Mon, 18 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

6.4.3 Interface Objects Paragraph 3 - comment

  • Key: CORBA22-31
  • Legacy Issue Number: 420
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Final Para describes the types of support interfaces that might be available in some implementations. These are not interesting for portable application develpoment.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    no change necessary, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.7 delete Paragraph 4 - objection

  • Key: CORBA22-30
  • Legacy Issue Number: 409
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The exception to be returned is not specified. See objection for 4.6.4 get_values Paragraph 2.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    see resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.2.1 create_request Paragraph 8 - comment

  • Key: CORBA22-20
  • Legacy Issue Number: 396
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This paragraph should be deleted, since it is not useful for an application programmer.

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.1.3 Return Status and Exceptions

  • Key: CORBA22-19
  • Legacy Issue Number: 395
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: X/Open recommends that the specification is being modified to require DII functions to return a Status as an unsigned long. Implementations without return value return value:non-conforming

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4.6.5 delete_values Paragraph 3 - objection

  • Key: CORBA22-29
  • Legacy Issue Number: 408
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This paragraph indicates that an exception is returned. See objection for 4.6.4 get_values Paragraph 2

  • Reported: CORBA 1.2 — Tue, 26 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    see resolution of 404

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do typecodes need literal constant representations in all mappings?

  • Key: CORBA22-4
  • Legacy Issue Number: 73
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.7 of the CORBA 2 spec constrains the representation of typecodes such that typecode "literals" can be placed in C include files. Is this meant?

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing info about the semantics of ORB_init and OA_init

  • Key: CORBA22-3
  • Legacy Issue Number: 68
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text associated with ORB_init and OA_init does not specify what is done with the argv parameter that requires it to be inout.

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Incorporate change in 2.3a and close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Similar structure to IR::Identifier

  • Key: CORBA22-14
  • Legacy Issue Number: 283
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no such type as IR::Identifier? It should really say CORBA::Identifier. Are ServiceTypeNames limited to characters allowed in IDL Identifier and also case sensitive?

  • Reported: CORBA 1.2 — Sat, 19 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved in 2.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pseudo-IDL identifiers differ by case only

  • Key: CORBA22-13
  • Legacy Issue Number: 233
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL identifiers in chapter 4 differ by case only [Ch 17 CORBA2.0] Some of the identifiers used in the IDL in Ch 4 differ only by case, which is not legal in IDL.

  • Reported: CORBA 1.2 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typecodes for recursive sequences

  • Key: CORBA22-8
  • Legacy Issue Number: 116
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the interface for the create_recursive_sequence_tc ORB method, is this just a matter of creating a TypeCode with these two fields, or is there a parameter missing?

  • Reported: CORBA 1.2 — Fri, 13 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    No parameter is missing. you just create a TypeCode with TCKind set to tk_sequence and content type

  • Updated: Fri, 6 Mar 2015 20:58 GMT

lookup() questions

  • Key: CORBA22-7
  • Legacy Issue Number: 86
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does the lookup() function also lookup in the base interfaces if used on an InterfaceDef? If so, what if it is is more than one interface? Can the search_name argument be a scoped name?

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DSI and oneway operations

  • Key: CORBA22-10
  • Legacy Issue Number: 129
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: After calling a Dynamic Invocation Routine, how can the ORB know whether to send a response back to the client (i.e., whether the operation was "oneway")?

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    The ORB uses protocol information (i.e. from GIOP response_expected) to make this decision.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServerRequest::op_def()

  • Key: CORBA22-9
  • Legacy Issue Number: 128
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What is the purpose of the ServerRequest::op_def method? It is not described in the Chap. 5 discussion of ServerRequest or in 18.4.1.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface Repository Error Handling

  • Key: CORBA22-6
  • Legacy Issue Number: 85
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IR specification specifies what operations are an error, but does not specify how this error is returned. The specification does not define any exceptions.

  • Reported: CORBA 1.2 — Thu, 15 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    Superceded by Issue 778

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::InterfaceDef name collision

  • Key: CORBA22-5
  • Legacy Issue Number: 76
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA::InterfaceDef defines an operation "is_a", although there is already an "is_a" operation defined in CORBA::Object. Section 3.6 on page 3-17 says this is not allowed.

  • Reported: CORBA 1.2 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Apparent error in CORBA 2.0 Interoperability

  • Key: CORBA22-12
  • Legacy Issue Number: 156
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: in 13.5.6 "The DCE ESIOP", "Location Policy Component" there is for module IOP a list of 4 "const octet statements.. The BNF appears to suggest that this is invalid.

  • Reported: CORBA 1.2 — Tue, 8 Oct 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    issue closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Repository IDs

  • Key: CORBA22-11
  • Legacy Issue Number: 133
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would expect a lookup on IDL:/CORBA/Object:1.0 to return an InterfaceDef. It would seem more logical if Object was represented by a "default" InterfaceDef in the repository.

  • Reported: CORBA 1.2 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Portability and the #include directive

  • Key: CORBA22-16
  • Legacy Issue Number: 306
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: #include has same definition that C and C++ programmers are used to.HP treats #include at global scope as merely introducing declarations. This idea needs closer examination

  • Reported: CORBA 1.2 — Sat, 23 Nov 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close no change in 2.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Recursive sequence TypeCodes

  • Key: CORBA22-15
  • Legacy Issue Number: 300
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are they a new TypeCode kind (tk_kind) or are they of the tk_sequence TypeCode kind/

  • Reported: CORBA 1.2 — Tue, 29 Oct 1996 05:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    subsumed by issue 116, close issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IFR: union elements associated with case labels

  • Key: CORBA22-2
  • Legacy Issue Number: 14
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A union element associated with N case labels manifests in the IFR as N distinct UnionMembers. Is this intended?

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inheritance of describe_contents()

  • Key: CORBA22-1
  • Legacy Issue Number: 2
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Where does the OperationDef interface inherit the describe_contents() operation from.

  • Reported: CORBA 1.2 — Thu, 16 May 1996 04:00 GMT
  • Disposition: Resolved — CORBA 2.2
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT


CTS2: Change cardinality of defaultLanguage from [0..1] to [0..*]

  • Key: CTS2F2-72
  • Legacy Issue Number: 17332
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    11-09-02 CTS2 Code System and Code System Version Catalog Services

    On page 16 the attribute of the CodeSystemCatalogVersionEntry the defaultLanguage is defined as the default spoken or written language used in this version. If we look at the cardinality we see it is [0..1]. We believe this should be [0..*]. HL7 CTS2 specifies " The different languages (supportedLanguages) supported by the Code System in this version". For certain official terminology providers the same version can be multilingual. For example the file supplied by ISO ISO-639-2_utf-8.txt is both in English and in French. STS implements the attribute supportedLanguages as a list of languages, which we believe is much more fitted than a defaultLanguage attribute (with only one language). Proposition: Change cardinality.

    Logged: https://github.com/cts2/cts2-specification/issues/71

  • Reported: CTS2 1.0b1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Updated Diagram (Figure 3.1: Code System Version, Page 19.)
    PSM:
    Change Location: CodeSystemVersion.xsd
    Added a 'supportedLanguage' element to "CodeSystemVersionCatalogEntry."
    <xs:element name="supportedLanguage" type="core:LanguageReference" minOccurs="0" maxOccurs="unbounded">
    <xs:annotation>
    <xs:documentation>all languages recognized by this particular code system version</i></xs:documentation>
    </xs:annotation>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduction section about conventions and notation needs to be in all modules

  • Key: CTS2F2-74
  • Legacy Issue Number: 17351
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The introductory section about conventions and the like needs to be included in all of the modules. Currently it is just in the Core

    Logged: https://github.com/cts2/cts2-specification/issues/93

  • Reported: CTS2 1.0b2 — Fri, 4 May 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception listed twice in EntityDescriptionQueryService


EntityDescriptionQueryService knownCodeSystem type is incorrect

  • Key: CTS2F2-75
  • Legacy Issue Number: 17352
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The type of knownCodeSystem should be CodeSystemReference instead of CodeSystemVersionReference. This needs to be corrected in both the PIM and the Service schema

    Logged: https://github.com/cts2/cts2-specification/issues/94

  • Reported: CTS2 1.0b2 — Fri, 4 May 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update Diagram (Figure 3.2: Entity Description Query Service)

    PSM: In the 'EntityDescriptionReadService' and 'EntityDescriptionQueryService' types, change:
    <xs:element name="knownCodeSystem" type="core:CodeSystemVersionReference" minOccurs="0" maxOccurs="unbounded"/>
    to
    <xs:element name="knownCodeSystem" type="core:CodeSystemReference" minOccurs="0" maxOccurs="unbounded"/>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Delta stereotype is opposite of isQuery

  • Key: CTS2F2-77
  • Legacy Issue Number: 17434
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The stereotype indicates that the operation may change the service state, which is the opposite of the UML isQuery tag. You need to set the isQuery tag to true on all non-delta operations and then include documentation on each operation to repeat what it means because everyone will ignore it otherwise.

    Logged: https://github.com/cts2/cts2-specification/issues/111

  • Reported: CTS2 1.0b2 — Wed, 20 Jun 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MatchValueFormatException missing from documentation

  • Key: CTS2F2-81
  • Legacy Issue Number: 17438
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    MatchValueFormatException was incorrectly typed as "exeption" instead of "exception", which means that it isn't included in the formal PDF documents or Exceptions.xsd. Need to add it to the documentation and the schema.

    Logged: https://github.com/cts2/cts2-specification/issues/117

  • Reported: CTS2 1.0b2 — Wed, 20 Jun 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text

    PSM: Change the MatchValueFormatException type to 'exception.'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Boolean is a UML data type and shouldn't be part of the model

  • Key: CTS2F2-80
  • Legacy Issue Number: 17437
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    This is related to the string issue pointed out by Manfred. Boolean cannot be defined as a data type, as it is already part of the UML core.

    Logged: https://github.com/cts2/cts2-specification/issues/116

  • Reported: CTS2 1.0b2 — Wed, 20 Jun 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT


String is a UML dataType and cannot be included as part of the model data types


CTS2: Additional options needed for Entity Read Query

  • Key: CTS211-12
  • Legacy Issue Number: 18479
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The entity and entitybyuri queries currently return an EntityReference that contains zero or more knownEntityDescriptions. They do this even if there is just one knownEntityDescription. This behavior is not what most clients desire

    Would recommend the following:
    (a) (re-)add the tag that was present in the LexGrid model that could be used to identify one of the coding systems as the "primary"
    (b) State that the default behavior of entity and entitybyuri is to redirect to the only or (when present) tagged entry in the specific codesystem version. The id is that //entity/12345 will redirect to //codesystem/

    {c}

    /version/

    {v}

    /entity/12345 if it is the only describing code system version or its code system (version?) is listed as the primary
    (c) add an additional parameter (fwd?) that, when false, says that redirection should not occur.

    Logged: https://github.com/cts2/cts2-specification/issues/129

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Format and language resolution precedence not described for REST

  • Key: CTS211-11
  • Legacy Issue Number: 18478
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Both the format and language can be supplied as a url parameter or as part of the http header. The current specification doesn't address what to do if both are present.

    Recommendation is that the command line takes precedence over Accept and Accept-Language in the header.

    Logged: https://github.com/cts2/cts2-specification/issues/130

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Include the signature for the CLONE operation in Change Set

  • Key: CTS211-8
  • Legacy Issue Number: 18475
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The change set includes a CLONE type, but we haven't specified a method for asking that a CLONE be performed.

    We would anticipate that the method signature would include:
    nameOrURI of the the versionable resource to be Cloned
    the new version identifier (optional - could be assigned by service or error if it doesn't)
    the new version URI (optional)
    the change set URI

    (we need to check the documentation to see whether there is anything else)

    Logged: https://github.com/cts2/cts2-specification/issues/135

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Extensible Directories - Allow directories to be extended

  • Key: CTS211-7
  • Legacy Issue Number: 18474
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The CTS2 specification describes the minimum (and, at the moment, only) content that can be in directories of various types. Implementers are discovering that they need to add information to this to meet special use cases (e.g. ChangeSetURI and ChangeSetNotes for a special value set authoring environment). We need a way to allow directories to be extended for service specific implementations.

    Logged: https://github.com/cts2/cts2-specification/issues/137

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Rest signatures missing for ValueSetDefinitionResolution "resolveAsCompleteSet" function

  • Key: CTS211-15
  • Legacy Issue Number: 18483
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The resolveAsCompleteSet function allows the client to ask for a ResolvedValueSet (vs. IterableResolvedValueSet). There is currently no way to do this in the REST functions.

    Would propose that we add a parameter to queryControl or update the possible values for maxToReturn so a client can indicate that they don't want an iterator, they want the whole thing. We will have to supply a new error message as well - something to the effect of "too much to return all at once"

    Logged: https://github.com/cts2/cts2-specification/issues/125

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: REST language signature "referencelanguage" needs to be more REST compliant

  • Key: CTS211-14
  • Legacy Issue Number: 18481
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The current tag, "referencelanguage" is a bit unwieldy from the REST perspective. Would recommend adding a synonym, "lang" to address this issue.

    Logged: https://github.com/cts2/cts2-specification/issues/127

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: CodeSystemCatalogEntry xml schema missing "hasOntologyLanguage" and "includes" elements

  • Key: CTS211-19
  • Legacy Issue Number: 18487
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    CodeSystemCatalogEntry.xsd is missing "hasOntologyLanguage" and "includes" elements. These were added to cts2/spec/submission/OMGServerMap/codesystem/CodeSystem.xsd in revision 7641

    Logged: https://github.com/cts2/cts2-specification/issues/121

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Map Entry "MapFrom" and "MapTo" need optional description element

  • Key: CTS211-18
  • Legacy Issue Number: 18486
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The mapFrom and mapTo elements in Map Entry are currently of type URIAndEntityName, which doesn't allow an explanatory designation to be provided, meaning that it may be necessary to resolve the returned types against a code system. This type should be changed to EntitySynopsis. Changes have been submitted to CTS2 svn repository as change 7853

    Logged: https://github.com/cts2/cts2-specification/issues/122

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    Disposition: See issue 18532 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: No ROA link to value set resolution of current value set

  • Key: CTS211-9
  • Legacy Issue Number: 18476
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    While it is possible to construct a URL that requests the resolution of the CURRENT version of a value set, there is no href in the ValueSet schema that allows this query to be performed without knowing URL construction rules. There should be another optional link called "resolution" or something similar where a service can provide an href that allows direct access to the value set resolution.

    Logged: https://github.com/cts2/cts2-specification/issues/134

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: ValueSetDefinition REST signatures need to include shortcuts for tags

  • Key: CTS211-17
  • Legacy Issue Number: 18485
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Currently there is no way to resolve a value set definition directly without knowing a specific version - it is first necessary to find the definition via query statements. The REST signatures should include:
    //valueset/resolution[?tag=

    {tag}

    ], which will resolve CURRENT or tag directly. This has already been implemented in the SVS mat implementation.

    Logged: https://github.com/cts2/cts2-specification/issues/123

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Documentation for value set resolution needs to be corrected.


CTS2: "versiontag" has wrong type in MapVersion schema

  • Key: CTS211-10
  • Legacy Issue Number: 18477
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Line 60 in MapVersion.xsd has the wrong type for versiontag. Change:

    <xs:element name="versionTag" type="core:MapVersionReference" minOccurs="0" maxOccurs="unbounded">

    to

    <xs:element name="versionTag" type="core:VersionTagName" minOccurs="0" maxOccurs="unbounded">

    Change submitted to svn - cts2/spec/submission/OMGServerMap/mapversion/MapVersion.xsd - revision 7877

    Logged: https://github.com/cts2/cts2-specification/issues/133

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Redirect behavior isn't clear for uri reads

  • Key: CTS211-13
  • Legacy Issue Number: 18480
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The REST specification doesn't specify what the service behavior should be on "byuri" type queries. Some implementations use a 303 to get to the base resource while others leave the URI as entered.

    Would propose that the specification say that it should always redirect.

    Logged: https://github.com/cts2/cts2-specification/issues/128

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Create/Update in WADL use the wrong HTTP methods

  • Key: CTS2F2-65
  • Legacy Issue Number: 17323
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In the WADL (REST PSM), a Create is done with an HTTP 'PUT' and an update is done with an HTTP 'POST'. This is problematic because a client must have knowledge of the URL structure before doing a create. It will limit implementation as-is because clients cannot be expected to know the URL structure of a resource before it is created. In the case of an update, a 'PUT' is more appropriate because we assume that at that point the client does know the URL of the resource.

    Logged: https://github.com/cts2/cts2-specification/issues/84

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Change all creates to an HTTP 'POST' and all updates to an HTTP 'PUT'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: StructuralProfile - Statement and/or MapEntry

  • Key: CTS2F2-64
  • Legacy Issue Number: 17322
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In the StructuralProfile enum, should there be 'SP_STATEMENT' and/or 'SP_MAP_ENTRY' ?

    It could be that Statement is intended to be included in the 'Association' profile and MapEntry in the 'MapVersion' profile. If that is the case this issue would be a no-op, or at most a documentation note.

    Logged: https://github.com/cts2/cts2-specification/issues/86

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Added two new enum values: 'SP_MAP_ENTRY" and "SP_STATEMENT" to the StructuralProfile enum.
    <xs:enumeration value="SP_MAP_ENTRY">
    <xs:annotation>
    <xs:documentation>The <b>Map_Entry</b> profile represents
    individual entries in a
    <b>Map_Version</b></xs:documentation>
    </xs:annotation>
    </xs:enumeration>
    <xs:enumeration value="SP_STATEMENT">
    <xs:annotation>
    <xs:documentation>The <b>Statement</b> profile provides a
    bridge between the CTS2 model structure and the
    underlying RDF/XML/etc.</xs:documentation>
    </xs:annotation>
    </xs:enumeration>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: currentVersion not typed in MapCatalogEntry

  • Key: CTS2F2-61
  • Legacy Issue Number: 17319
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Map.xsd MapCatalogEntry currentVersion does not have an XSD type. Should be MapVersionReference...

    Logged: https://github.com/cts2/cts2-specification/issues/89

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Changed the type of 'currentVersion' to 'MapVersionReference.'
    Original:
    <xs:element name="currentVersion" minOccurs="0">
    Updated:
    <xs:element name="currentVersion" type="core:MapVersionReference" minOccurs="0">

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: ScopedEntityName.name type is too strong

  • Key: CTS2F2-60
  • Legacy Issue Number: 17317
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    ScopedEntityName.name is set to LocalIdentifier in the XML Schema. The UML specification shows it as "String" and its current setting is preventing us from using SNOMED CT fully specified names and other useful sources.

    Logged: https://github.com/cts2/cts2-specification/issues/91

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Changed the 'name' element from 'LocalIdentifier' to 'String.'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Message Header Documentation Missing

  • Key: CTS2F2-63
  • Legacy Issue Number: 17321
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The documentation got stripped in the RestResource type in Core.xsd. We propose it read as:

    xs:annotation

    xs:documentationThe relative URI of the resource with respect to the resourceRoot. As an example,

    if the resource URI was "http://informatics.mayo.edu/cts2/rest/codesystems", the resourceURI would

    be "codesystems". Fragment and query identifiers should also be included./xs:documentation

    xs:appinfoPSM/xs:appinfo

    /xs:annotation

    /xs:element

    xs:annotation

    xs:documentationThe paramaters that were used in executing the query. This carries all of the parameters that

    are needed to reconstruct the complete query in either a RESTful or procedural environment. The service provider

    may or may not include non-CTS2 related parameters such as security tokens, routing requests, etc./xs:documentation

    xs:appinfoPSM/xs:appinfo

    /xs:annotation

    /xs:element

    xs:annotation

    xs:documentationThe date and time that the resource was accessed./xs:documentation

    xs:appinfoPSM/xs:appinfo

    /xs:annotation

    /xs:element

    Logged: https://github.com/cts2/cts2-specification/issues/87

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Added in documentation to the 'RestResource' type as described in the updated xml below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Inconsistent element/complexType declarations

  • Key: CTS2F2-62
  • Legacy Issue Number: 17320
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The current xml schemas in the rest/schema directory present an inconsistent combination of the "Venetian Blind" and "Garden of Eden" schema patterns (http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html), where all elements except the elemMsg, elemList and elemDirectory have both complexType and element declarations. The approaches to these two patterns can be quite different in a schema compiler such as pyxb. We propose that all element declarations follow the general pattern:

    ...

    /xs:complexType

    For resources that can be document level elements and complex (or simple) for the rest)

    Logged: https://github.com/cts2/cts2-specification/issues/88

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Changed any XSD Element in the form of:
    <xs:element name='x'>
    <xs:complexType>
    ...
    </xs:complexType>
    </xs:element>
    to:
    <xs:element name='x' type = 'x'/>
    <xs:complexType name='x'>
    ...
    </xs:complexType>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: AssociationQueryServices WSDL corrections

  • Key: CTS2F2-68
  • Legacy Issue Number: 17326
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

    Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

    In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression

    In method 'count' add parameter 'timeout'.

    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, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
    • Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
    • In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression
    • In method 'count' add parameter 'timeout'.
    • In method 'restrict' change the type of param 'directory' to DirectoryURI
    • In method 'restrictToTargetLiteral' change the type of param 'target' to String

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: ConceptDomainBindingReadService QueryControl parameters

  • Key: CTS2F2-67
  • Legacy Issue Number: 17325
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The QueryControl parameter was omitted from the read and readByURI operations in ConceptDomainBindingService.

    Logged: https://github.com/cts2/cts2-specification/issues/81

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    In the ConceptDomainBindingService - methods 'read' and 'readByUri', add a parameter 'queryControl of type 'AssociationDirectoryURI.'
    Updated Diagram (Figure 4.1: Concept Domain Binding Read. Concept Domain Binding, Page 20.)

    PSM:
    Add in the following element to types 'read' and 'readByURI':

    <xs:element minOccurs="0" name="queryControl" type="coreService:QueryControl" />

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: AssociationQueryService 'getAllSourceAndTargetEntities' wrong input parameter

  • Key: CTS2F2-66
  • Legacy Issue Number: 17324
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In the AssociationQueryService, the method 'getAllSourceAndTargetEntities' accepts an 'EntityDirectoryURI' as an input. I believe that it should accept an 'AssociationDirectoryURI' (as 'getSourceEntities', 'getTargetEntities', and 'getPredicates' do).

    Logged: https://github.com/cts2/cts2-specification/issues/83

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    In the AssociationQueryService - method 'getAllSourceAndTargetEntities', change the parameter 'directory' to type 'AssociationDirectoryURI.'

    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Concept Domain Catalog Query Service missing description

  • Key: CTS2F2-70
  • Legacy Issue Number: 17330
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    11-09-03 CTS2 Concept Domain and Concept Domain Binding Services

    In section 2.2 Concept Domain Catalog Query Service the section goes onto describing Concept Domain Catalog History. Is is possible that the Query service description (resolve and resolveAsList) were missed due to a cut and paste error?

    Logged: https://github.com/cts2/cts2-specification/issues/75

  • Reported: CTS2 1.0b1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM: N/A
    After review, the existing text is correct, and the change should not be applied to the PIM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Service map catalog typo

  • Key: CTS2F2-69
  • Legacy Issue Number: 17327
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    11-09-08 Value Set services - The ValueSetCatalogReadService provides direct access to the service map catalog. Typo - Value Set Catalog instead of service map catalog.

    Logged: https://github.com/cts2/cts2-specification/issues/78

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: section 1.1.2.1 Class CodeSystemCatalogEntryDirectory typo

  • Key: CTS2F2-71
  • Legacy Issue Number: 17331
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In the pdf2 in section 1.1.2.1 Class CodeSystemCatalogEntryDirectory we think this is a typo and it should be CodeSystemDirectory.

    Logged: https://github.com/cts2/cts2-specification/issues/69

  • Reported: CTS2 1.0b1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM: N/A
    After review, the existing text is correct, and the change should not be applied to the PIM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Evaluation only conformance profile

  • Key: CDSS-10
  • Legacy Issue Number: 15641
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    There have been many requests to support a minimal conformance profile that requires only select operation(s) of the Evaluation interface. Such a conformance profile should therefore be added.

  • Reported: CDSS 1.0b1 — Fri, 24 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    A minimal conformance profile that only requires the “evaluate” operation within
    the “Evaluation” interface has been defined. Also, the conformance profiles have
    been simplified to include only this “evaluation only” conformance profile and a
    full conformance profile supporting all defined operations. The previous
    intermediate profile (the “Core” profile) was removed because it was
    functionally very close to the Complete profile, (ii) additional profiles could be
    specified outside of the scope of this specification by DSS providers if desired,
    and (iii) the two remaining profiles appear to be the ones to which implementers
    are gravitating.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EvaluationRequest and IterativeEvaluationRequest content ordering

  • Key: CDSS-9
  • Legacy Issue Number: 15634
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    For the EvaluationRequest and IterativeEvaluationRequest, KMEvaluationRequest and IterativeKMEvaluationRequest should precede dataRequirementItemData, so that the knowledge module being used is apparent before potentially very lengthy payload data are provided. This may make it possible for a CDSS to ignore data not needed for a requested rule, thereby improving performance.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    This issue has been resolved in the PSM by correcting the relative order of
    elements as recommended

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Consider RESTful service specification

  • Key: CDSS-8
  • Legacy Issue Number: 15633
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Consider providing RESTful PSM or noting that a RESTful PSM is under consideration for future specification.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    It is now noted that a RESTful Web service PSM is under consideration for future
    specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Security Issues

  • Key: CDSS-7
  • Legacy Issue Number: 15632
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Consider further clarifying approach to security in SOAP Web service PSM. For example, consider explicitly noting that an implementer may extend the provided WSDLs to incorporate WS-Security conformance and still be considered compliant with the specification.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    Further clarified approach to security in SOAP Web service PSM. In particular,
    select security considerations included in the RFP response but not included in
    the beta 1 specification have been re-introduced. Also, it is now explicitly noted
    that an implementer may extend the provided WSDLs to incorporate WS-Security
    conformance and still be considered compliant with the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DSS: single targetNamespace "urn:dss.hssp.org"

  • Key: CDSS-1
  • Legacy Issue Number: 14856
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    A single targetNamespace "urn:dss.hssp.org" is used in all of the following
    machine readable files for the DSS submission:

    wsdl file dss_minimum_functional_profile.wsdl (subset of full set of operations)
    wsdl file dss_core_functional_profile.wsdl (subset of full set of operations)
    wsdl file dss.wsdl (full set of operations)

    xsd file HsspDssSchema.xsd (xs:include in wsdl:types element of each wsdl file)

    The common wsdl:message definitions are repeated in each of the three wsdl files. This will cause a maintenance headache. These should be pulled out into a separate wsdl file which can be referenced by a wsdl:import into each of the three wsdl files above.

    Is it necessary to keep the same namespace for both the schema and wsdl? It might be easier for ongoing maintenance to give the schema a different target namespace from the wsdl descriptions. This is a design decision that the FTF should consider.

    Of greater significance, the targetNamespace used is not an OMG rooted namespace.

    Solution proposed by originator:

    The FTF should use OMG rooted namespaces, as opposed to continuing to use
    hssp.org rooted namespaces?

    Rather than using urn values for namespaces, the OMG has recommended strongly, the
    use of URLs which resolve to a RDDL file which has pointers to the
    wsdl and/or schema files which define that namespace?

  • Reported: CDSS 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    The recommended changes have been made. Specifically:

    • The common WSDL definitions have been pulled into a new WSDL
      (dssBaseComponents.wsdl). This WSDL is then referenced through a
      wsdl:import into each of the WSDLs that correspond to the
      conformance profiles.
    • The namespaces for the schemas and WSDLs have been separated.
    • The targetNamespace has been changed to be an OMG rooted
      namespace.
    • For the namespaces, URLs that resolve to a RDDL which has pointers
      to the relevant WSDLs and XSDs are now provided, as described in
      the document authored by Tom Rutt on this topic, obtained form
      http://xml.coverpages.org/OMG-Rutt-NamespaceProposal-
      20090917.pdf
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Too many defined elements within one package name

  • Key: CDSS-4
  • Legacy Issue Number: 15629
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Use of a single package name limits logical packaging of elements and causes problems for auto-generated classes.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    The contents of OmgDssSchema.xsd have been grouped and alphabetized in a
    manner derived from the package structure used in the PIM. Auto-generated
    classes could be logically packaged in accordance with the suggested package
    structure if desired.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Non UTF-8 character in schema comments

  • Key: CDSS-3
  • Legacy Issue Number: 15628
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Schema HsspDssSchema.xsd has a non-processable, non UTF-8 character (right-handed single quote) in comments in a number of locations. This causes failure of some code generators and compilers.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    Non UTF-8 characters, which consisted of special apostrophes, were removed
    from the schema annotations by rewording the comments appropriately in all PIM
    and PSM models. Also, the encodings of all XSDs and WSDLs developed in this
    specification were set to UTF-8.
    Also, along with this typo correction, a number of additional miscellaneous
    corrections were made, as detailed below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of xs:any data type for payload

  • Key: CDSS-5
  • Legacy Issue Number: 15630
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Standard approach for this type of content in similar healthcare interoperability specifications (eg, IHE specifications) usually specify contained payloads as a Base64 encoded string. The current approach with xs:any results in creation of a DOM object for payload, which results in unnecessary processing overhead.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    The use of xs:any has been replaced by the use of xs:base64Binary in the SOAP
    XML Web Services PSM.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

All Defined Operations

  • Key: CDSS-2
  • Legacy Issue Number: 15624
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Need an interaction identifier and timestamp for all defined operations to avoid issues with logging under multi-threaded situations

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    An InteractionIdentifier class with the recommended information has been added
    to all operations as an input

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of "Exception" as a class name in the model

  • Key: CDSS-6
  • Legacy Issue Number: 15631
  • Status: closed  
  • Source: swpartners.com ( David Shields)
  • Summary:

    Use of the name "Exception" as a class name in the model causes problems with Java code generators, due to confusions with the java Exception class.

  • Reported: CDSS 1.0b1 — Thu, 23 Sep 2010 04:00 GMT
  • Disposition: Resolved — CDSS 1.0
  • Disposition Summary:

    The Exception base class has been renamed DSSException.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The XML document dtc-13-11-05.xsd is NOT valid (1 errors)

  • Key: CMMN-19
  • Legacy Issue Number: 19137
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Line 381: content types of base type 'tCmmnElementWithMixedContent' and derived type 'tExpression' must both be mixed or element-only.

    Presumably tExpression should be declared to be mixed: this is not implicit through inheritance

  • Reported: CMMN 1.0b1 — Thu, 12 Dec 2013 05:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify CMMN XML-Schema file CMMN10CaseModel.xsd
    Old specification of type "tExpression":
    <xsd:complexType name="tExpression">
    <xsd:complexContent>
    <xsd:extension base="tCmmnElementWithMixedContent">
    <xsd:sequence>
    <xsd:element name="body" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="language" type="xsd:anyURI" use="optional"
    default="http://www.w3.org/1999/XPath"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

    New specification of type "tExpression":
    <xsd:complexType name="tExpression" mixed="true">
    <xsd:complexContent>
    <xsd:extension base="tCmmnElementWithMixedContent">
    <xsd:sequence>
    <xsd:element name="body" type="xsd:string" minOccurs="0" maxOccurs="1"/>
    </xsd:sequence>
    <xsd:attribute name="language" type="xsd:anyURI" use="optional"
    default="http://www.w3.org/1999/XPath"/>
    </xsd:extension>
    </xsd:complexContent>
    </xsd:complexType>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 11

  • Key: CMMN-18
  • Legacy Issue Number: 19128
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    The composite end of the association between ParameterMapping and Expression, as shown in Figure 11, has multiplicity 0..*, which is technically wrong. It should have multiplicity 0..1.

  • Reported: CMMN 1.0b1 — Thu, 28 Nov 2013 05:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Change the multiplicity of the composite end of the association between ParameterMapping and Expression to 0..1.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Parents URI needed in EntityDescription

  • Key: CTS211-26
  • Legacy Issue Number: 18494
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    EntityDescription provides URI's for children, descendants and ancestors, but it only provides parents directly. While this is useful, it means that applications that are traversing graphs have to have two different mechanisms - one for the first three categories and a second for parents. We should add one more attribute, "parents" which allows parents to be accessed by URI as well.

    Logged: https://github.com/cts2/cts2-specification/issues/136

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: CodeSystemCatalogQueryService (resolve and resolveAsList) parameter 'directory' type incorrect

  • Key: CTS211-25
  • Legacy Issue Number: 18493
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI'

    Section 2.2.1.2 (Operation resolveAsList), input parameter 'directory' is specified as type CodeSystemCatalogURI. Type should be 'CodeSystemCatalogEntryDirectoryURI'

    Logged: https://github.com/cts2/cts2-specification/issues/96

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    This issue does not exist in the "CTS2 - Code System and Code System Version Catalog Services, v1.0" document.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Complete binding operation missing from specification

  • Key: CTS211-31
  • Legacy Issue Number: 18534
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    There is no method with a signature: f(conceptDomain, context[0..*], codeSystemVersion[0..*], tag[0..1]) --> ResolvedValueSet

    (In that there is no way to say "Give me the resolved value set for this concept domain in this context")

    https://github.com/cts2/cts2-specification/issues/149

  • Reported: CTS2 1.0 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: URIAndEntityName references should all be changed to EntitySynopsis, allowing an optional description


CTS2: IteratableResolvedValueSet and ResolvedValueSet have inconsistent element names

  • Key: CTS211-29
  • Legacy Issue Number: 18531
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    ResolvedValueSet has 'member' elements while IteratableResolvedValueSet has 'entry' elements.

    Recommend moving all elements to 'entry' as that is the pattern for everything else.

    Logged: https://github.com/cts2/cts2-specification/issues/147

  • Reported: CTS2 1.0 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: CTS2Exception doesn't match documentation

  • Key: CTS211-28
  • Legacy Issue Number: 18530
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    CTS2Exception in the PIM consists of message and severity. The XML schema has an extra element that makes no sense - ExceptionType. This appears to be an artifact that was accidentally left in the UML model, but is never used in the spec itself.

    This should be removed from both places - the UML and the exception schema

    Logged: https://github.com/cts2/cts2-specification/issues/148

  • Reported: CTS2 1.0 — Thu, 7 Mar 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need an optional attribute to carry the OID in addition to the URI

  • Key: CTS211-27
  • Legacy Issue Number: 18517
  • Status: closed  
  • Source: Phast ( Ana Estelrich)
  • Summary:

    In the description of the Code System Catalog Entry the identification is done via the Code System name: “codeSystemName - the local identifier that uniquely identifies the code system within the context of the implementing service. Note that the about URI is the globally unique identifier”.

    The HL7 culture is used to manage messages and documents via OIDs which. An optional attribute: CodeSystemOID is needed. The issue here is not turning an OID into a URI but having the possibility to have SIMULTANEOUSLY the URI and OID present (an additional attribute aside from about). In all IHE domains we use OIDs to identify objects. There is no strong consensus and a mechanism of sharing URI so that complete interoperability can be achieved. In this transition context we need a means to assure this transition while assuring interoperability. https://github.com/cts2/cts2-specification/issues/144

  • Reported: CTS2 1.0 — Fri, 1 Mar 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationDirectory needs "associationID"

  • Key: CTS211-22
  • Legacy Issue Number: 18490
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    In cases where the associationID is supplied, it is the ID that gets you from the directory contents to the actual association.

    This change has been added to revision 7733 in cts2/spec/submission/OMGServerMap/association/Association.xsd on 10/4/2012

    Logged: https://github.com/cts2/cts2-specification/issues/118

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Make "associationID" optional

  • Key: CTS211-21
  • Legacy Issue Number: 18489
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Generating associationID's when none exist just produces noise. The associationID parameter should made optional in the PIM where the service doesn't support AssociationRead. This needs to be changed in the schema AND the spec.

    Schema has been updated in revision 7752 in cts2/spec/submission/OMGServerMap/association/Association.xsd

    Logged: https://github.com/cts2/cts2-specification/issues/119

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Filter PropertyReference documentation needs clarification

  • Key: CTS211-32
  • Legacy Issue Number: 18541
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The PropertyReference class in Filter, and corresponding elements in the query signatures doesn't specify exactly how one should create a referenceTarget for references of type Attribute. As an example, how would one go about specifying the uri attribute in the source component of a sourceAndRole element? The behavior is underspecified if the reference not to a leaf (e.g. "sourceAndRole") Recommend it should specify match anything except href.

    If it is going to require URIAndEntityName (vs. 'or'), we need to clearly state what URI is used in the CTS2 spec. Otherwise we need to change the signature to allow just a name (preferred).

    Logged: https://github.com/cts2/cts2-specification/issues/151

  • Reported: CTS2 1.0 — Tue, 12 Mar 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Include a depth indicator for AssociationGraph

  • Key: CTS211-20
  • Legacy Issue Number: 18488
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The association graph structure is considerably easier to use if has a dept indicator. While this could be computed, it is much easier to traverse if explicitly present.

    This change has been added to Association.xsd in cts2/spec/submission/OMGServerMap/association

    Still needs to be documented and added to the spec itself

    Logged: https://github.com/cts2/cts2-specification/issues/120

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: ConceptDomainCatalogQueryService (resolve) parameter "directory" type incorrect

  • Key: CTS211-24
  • Legacy Issue Number: 18492
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Section 2.2.1.1 (Operation resolve), input parameter 'directory' is specified as type ConceptDomainDirectoryURI. Type should be 'ConceptDomainCatalogEntryDirectoryURI'

    Logged: https://github.com/cts2/cts2-specification/issues/97

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    This issue does not exist in the "CTS2 - Concept Domain and Concept Domain Binding Services, v1.0" document.
    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: URIAndEntityName XSD representation does not match UML

  • Key: CTS211-23
  • Legacy Issue Number: 18491
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    URIAndEntityName does not represent what is in the UML. The UML says that the only thing that is required is the uri – the name and href are optional. The Schema says that the namespace and name is required.

    Logged: https://github.com/cts2/cts2-specification/issues/98

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationMaintenanceServices WSDL corrections

  • Key: CTS2F2-50
  • Legacy Issue Number: 17185
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'putChangeSet' add param 'errorResponse'

    In method 'validateChangeSet' add param 'validationLevel'

    In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'

    In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'

    Removed methods 'createAssociationsFromExpression' and 'createAssociationFromExpression'

    Added method 'addAssociation

    Added params 'subject', 'predicate', 'target', 'ecternalStatementId' to method 'updateAssociation;

    Logged: https://github.com/cts2/cts2-specification/issues/54

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'putChangeSet' add param 'errorResponse'
    • In method 'validateChangeSet' add param 'validationLevel'
    • In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'
    • In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'
    • Removed methods 'createAssociationsFromExpression' and 'createAssociationFromExpression'
    • Added method 'addAssociation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationHistoryServices WSDL corrections

  • Key: CTS2F2-49
  • Legacy Issue Number: 17184
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'count' add parameter 'timeout'

    For methods 'getLatestChangeFor', 'getChangeHistoryFor', and 'getEarliestChangeFor' change param 'assocation' type to URI

    Add methods 'getEarliestServiceChange', 'getLatestServiceChange', and 'getLatestServiceChange'

    Logged: https://github.com/cts2/cts2-specification/issues/53

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'count' add parameter 'timeout'
    • For methods 'getLatestChangeFor', 'getChangeHistoryFor', and 'getEarliestChangeFor' change param 'assocation' type to URI
    • Added methods 'getEarliestServiceChange', 'getLatestServiceChange', and 'getServiceHistoryFor'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationReadServices WSDL corrections

  • Key: CTS2F2-48
  • Legacy Issue Number: 17183
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'readByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.

    In method 'existsByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.

    In method 'read' change type of 'associationId' param to URI

    In method 'exists' change type of 'associationId' param to URI

    Logged: https://github.com/cts2/cts2-specification/issues/52

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'readByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.
    • In method 'existsByExternalStatementId' remove param 'assertingCodeSystemVersion' and replace with 'scopingNamespace'.
    • In method 'read' change type of 'associationId' param to URI
    • In method 'exists' change type of 'associationId' param to URI

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AdvancedAssociationQueryServices WSDL corrections

  • Key: CTS2F2-47
  • Legacy Issue Number: 17182
  • Status: closed  
  • 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/51

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
    • Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
    • In method 'restrictToTargetExpression' change the type of param 'target' to EntityExpression
    • In method 'count' add parameter 'timeout'.
    • In method 'restrict' change the type of param 'directory' to DirectoryURI
    • In method 'restrictToTargetLiteral' change the type of param 'target' to String

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityDescriptionMaintenanceServices WSDL changes

  • Key: CTS2F2-59
  • Legacy Issue Number: 17194
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'readChangeSet' add param 'queryControl;

    In method 'updateChangeSetMetadata added param 'officialEfectiveDate;

    In method putChangeSet change return type to ProcessStatus

    Logged: https://github.com/cts2/cts2-specification/issues/63

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'readChangeSet' add param 'queryControl'
    • In method 'updateChangeSetMetadata added param 'officialEffectiveDate'
    • In method putChangeSet change return type to ProcessStatus'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityDescriptionQueryServices WSDL corrections

  • Key: CTS2F2-58
  • Legacy Issue Number: 17193
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In 'count' method added 'timeout' param.

    Renamed method 'restrictToCodeSystemVersions' to 'restrictToCodeSystemVersion'

    Added method 'restrictToEntities', 'isEntityInSet', and 'intersectEntityList'

    Renamed method 'restrictToCodeSystems' to 'restrictToCodeSystem'

    Logged: https://github.com/cts2/cts2-specification/issues/62

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In 'count' method added 'timeout' param.
    • Renamed method 'restrictToCodeSystemVersions' to 'restrictToCodeSystemVersion'
    • Added method 'restrictToEntities', 'isEntityInSet', and 'intersectEntityList'
    • Renamed method 'restrictToCodeSystems' to 'restrictToCodeSystem'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityDescriptionReadServices WSDL corrections

  • Key: CTS2F2-46
  • Legacy Issue Number: 17180
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.

    Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.

    Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'.

    Logged: https://github.com/cts2/cts2-specification/issues/49

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • Rename method 'getKnownCodeSystems' to 'getKnownCodeSystem'.
    • Rename method 'getKnownCodeSystemVersions' to 'getKnownCodeSystemVersion'.
    • Rename method 'getSupportedVersionTags' to 'getSupportedVersionTag'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemVersionCatalogHistoryServices WSDL corrections

  • Key: CTS2F2-45
  • Legacy Issue Number: 17179
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'count' add param 'timeout'.

    Rename 'getLatestChange' to 'getLastChange'.

    In method 'getChangeHistoryFor' rename param 'codeSystem' to 'codeSystemVersion'

    In method 'getEarliestChangeFor' rename param 'codeSystem' to 'codeSystemVersion'

    Logged: https://github.com/cts2/cts2-specification/issues/48

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In 'count' method added 'timeout' param.
    • Rename 'getLatestChange' to 'getLastChange'.
    • In method 'getChangeHistoryFor' rename param 'codeSystem' to 'codeSystemVersion'
    • In method 'getEarliestChangeFor' rename param 'codeSystem' to 'codeSystemVersion'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConceptDomainBindingMaintenanceServices WSDL corrections

  • Key: CTS2F2-54
  • Legacy Issue Number: 17189
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'putChangeSet' added param 'errorResponse'

    In method 'updateChangeSetMetadata' added param 'officialEffectiveDate'

    In method 'readChangeSet' added param 'queryControl'

    In method 'updateConceptDomainBinding' renamed param 'conceptDomain' to conceptDomainBinding'

    In method 'validateChangeSet' added param 'validationLevel'

    In method 'updateChangeableMetadata' removed 'target' and 'owner' params and added 'entryID' param.

    In method 'newProperty' removed param 'entity' and added param 'predicate'

    Logged: https://github.com/cts2/cts2-specification/issues/58

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'putChangeSet' add param 'errorResponse'
    • In method 'validateChangeSet' add param 'validationLevel'
    • In method 'updateChangeSetMetadata' add param 'officialEffectiveDate'
    • In method 'readChangeSet' added param 'queryControl'
    • In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'
    • In method 'updateConceptDomainBinding' renamed param 'conceptDomain' to conceptDomainBinding'
    • In method 'newProperty' removed param 'entity' and added param 'predicate'

  • Updated: Fri, 6 Mar 2015 20:58 GMT


BaseImport/ExportServices WSDL correction


EntityDescriptionTransformService WSDL corrections

  • Key: CTS2F2-57
  • Legacy Issue Number: 17192
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Renamed method 'getKnownCodeSystems' to 'getKnownCodeSystemVersion'

    Removed method 'getSupportedVersionTags'

    Logged: https://github.com/cts2/cts2-specification/issues/61

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM: Renamed method 'getKnownCodeSystems' to 'getKnownCodeSystemVersion'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConceptDomainCatalogHistoryServices WSDL corrections

  • Key: CTS2F2-56
  • Legacy Issue Number: 17191
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'count' added a 'timeout' param

    In method 'readChangeSet' renamed param 'URI' to 'changeSetURI'

    Logged: https://github.com/cts2/cts2-specification/issues/60

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In 'count' method added 'timeout' param.
    • In method 'readChangeSet' renamed param 'URI' to 'changeSetURI'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationTransformServices WSDL corrections

  • Key: CTS2F2-51
  • Legacy Issue Number: 17186
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Removed method 'getSupportedVersionTags' and 'fromEntityDirectory'

    In method 'toAssociationFormat' changed type of param 'codeSystemVersion' to 'CodeSystemVersionReference'

    Logged: https://github.com/cts2/cts2-specification/issues/55

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Removed method 'getSupportedVersionTags' and 'fromEntityDirectory'
    • Reason: Refactored into BaseService

    In method 'toAssociationFormat' changed type of param 'codeSystemVersion' to 'CodeSystemVersionReference'
    • Reason: Typo

  • Updated: Fri, 6 Mar 2015 20:58 GMT


CTS2: Possible issue with CTS2 URI

  • Key: CTS211-1
  • Legacy Issue Number: 17318
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Appendix 10 of the OMG "Hitchhiker's Guide" (http://www.omg.org/cgi-bin/doc?hh) specifies a directory structure for organizing submission documents. While older specifications were organized as "spec.omg.org/...", the current direction is that the documents should be organized in "www.omg.org/spec//, where version would be "Beta2", "1.0" for the base spec and "yyyymmmm" for accompanying files.

    The OMG AB believes that this set of requirements would imply that the CTS2 URIs should change from "http://spec.omg.org/cts2/1.0/" to "http://www.omg.org/spec/cts2/1.0/".

    Logged: https://github.com/cts2/cts2-specification/issues/90

  • Reported: CTS2 1.0b1 — Fri, 20 Apr 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    Resolution (PIM)
    N/A

    Resolution (PSM)

    In each of the following files, all references to: "http://schema.omg.org/spec/CTS2/1.0"
    are being changed to: "http://www.omg.org/spec/CTS2/1.1".

    Change Location

    AdvancedAssociationQueryService.wsdl
    AssociationHistoryService.wsdl
    AssociationMaintenanceService.wsdl
    AssociationQueryService.wsdl
    AssociationReadService.wsdl
    AssociationTransformService.wsdl
    BaseExportService.wsdl
    BaseImportService.wsdl
    CodeSystemCatalogHistoryService.wsdl
    CodeSystemCatalogMaintenanceService.wsdl
    CodeSystemCatalogQueryService.wsdl
    CodeSystemCatalogReadService.wsdl
    CodeSystemVersionCatalogHistoryService.wsdl
    CodeSystemVersionCatalogMaintenanceService.wsdl
    CodeSystemVersionCatalogQueryService.wsdl
    CodeSystemVersionCatalogReadService.wsdl
    ConceptDomainBindingMaintenanceService.wsdl
    ConceptDomainBindingQueryService.wsdl
    ConceptDomainBindingReadService.wsdl
    ConceptDomainCatalogHistoryService.wsdl
    ConceptDomainCatalogMaintenanceService.wsdl
    ConceptDomainCatalogQueryService.wsdl
    ConceptDomainCatalogReadService.wsdl
    EntityDescriptionHistoryService.wsdl
    EntityDescriptionMaintenanceService.wsdl
    EntityDescriptionQueryService.wsdl
    EntityDescriptionReadService.wsdl
    EntityDescriptionTransformService.wsdl
    MapCatalogHistoryService.wsdl
    MapCatalogMaintenanceService.wsdl
    MapCatalogQueryService.wsdl
    MapCatalogReadService.wsdl
    MapEntryHistoryService.wsdl
    MapEntryMaintenanceService.wsdl
    MapEntryQueryService.wsdl
    MapEntryReadService.wsdl
    MapResolutionService.wsdl
    MapVersionHistoryService.wsdl
    MapVersionMaintenanceService.wsdl
    MapVersionQueryService.wsdl
    MapVersionReadService.wsdl
    ReasoningService.wsdl
    ResolvedValueSetLoader.wsdl
    ResolvedValueSetQueryService.wsdl
    ResolvedValueSetResolution.wsdl
    StatementHistoryService.wsdl
    StatementQueryService.wsdl
    StatementReadService.wsdl
    UpdateService.wsdl
    ValueSetCatalogHistoryService.wsdl
    ValueSetCatalogMaintenanceService.wsdl
    ValueSetCatalogQueryService.wsdl
    ValueSetCatalogReadService.wsdl
    ValueSetDefinitionHistoryService.wsdl
    ValueSetDefinitionMaintenanceService.wsdl
    ValueSetDefinitionQueryService.wsdl
    ValueSetDefinitionReadService.wsdl
    ValueSetDefinitionResolution.wsdl

    Change Description

    Changes to machine readable files are easily identified by Git using the color red to indicate “deletion” and green to indicate “addition.” Furthermore, the ‘-‘ minus sign is also displayed to indicate a deletion, and a “+” plus sign is displayed to indicate an addition.

    View Changes: https://github.com/cts2/cts2-specification/commit/890558063ee42dd3a21419f942abe16f0a634677

    Due to number of changes, please review the PDF.
    http://informatics.mayo.edu/svn/trunk/cts2/spec/submission/RTF_1.1/RTF_Issues/CTS2_RTF_1.1_17318.pdf

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: "documentURI" attribute description in ResourceVersionDescription is incorrect

  • Key: CTS211-5
  • Legacy Issue Number: 18472
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    On page 39 of Core the description of the documentURI attribute in ResourceVersionDescription stops in mid sentence with a "100".

    Logged: https://github.com/cts2/cts2-specification/issues/139

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    Resolution (PIM)
    Location 1
    Document "CTS2 - Core Model Elements, v1.0"
    Section 2.7.1.5
    Page 39
    Change Description 1
    Change made to Attributes section.
    Old Text:
    documentURI - a URI that identifies the specific version, language, and notation of the about resource. This URI needs to be constructed in such a way that, if necessary, it will be possible to differentiate resource versions that were loaded from different document syntaxes. As an example, if an image of the wine ontology was loaded from a resource that was in Manchester Syntax, it should be given a different URI than the image loaded from the RDF/XML syntax. The reasoning behind this is, even in cases where different syntaxes are 100.
    New Text:
    documentURI - a URI that identifies the specific version, language and notation of the about resource. This URI needs to be constructed in such a way that, if necessary, it will be possible to differentiate resource versions that were loaded from different document syntaxes. As an example, if an image of a the wine ontology was loaded from a resource that was in Manchester Syntax, it should be given a different URI than the image loaded from the RDF/XML syntax. The reasoning behind this is, even in cases where different syntaxes are 100% compatible the transformation into the CTS2 model may not be identical.
    Resolution (PSM)
    Change Location
    Core.xsd
    Change Description
    Changes to machine readable files are easily identified by Git using the color red to indicate “deletion” and green to indicate “addition.” Furthermore, the ‘-‘ minus sign is also displayed to indicate a deletion, and a “+” plus sign is displayed to indicate an addition.
    View changes: https://github.com/cts2/cts2-specification/commit/138ee6180cb52fa1176ac0f3bbfd93b54de34205

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: "entityType" description text incorrect - needs to be updated

  • Key: CTS211-2
  • Legacy Issue Number: 18469
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The current description of entityType in section 2.1.1.1 of the Entity Description Services (page 6) reads:
    entityType - the set of type(s) which the entityReference is an instance of. Because this is a terminology service, entityType must include one of owl:class, owl:individual, rdf:predicate, or skos:concept, although it may carry many other types as well.

    This is incorrect - it should read:
    "... must include one of owl:Class, owl:Individual, rdf:Property or skos:Concept"

    Note that this may potentially effect some implementations that have either transcribed the information literally or have used "rdf:predicate" instead of "ref:Property"

    Logged: https://github.com/cts2/cts2-specification/issues/142

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: "SourceAndNotation" should be made optional in resource version

  • Key: CTS211-4
  • Legacy Issue Number: 18471
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    At the moment, SourceAndNotation is a required field. In many situations there is nothing of value that can be supplied here - it should be made optional.

    Logged: https://github.com/cts2/cts2-specification/issues/140

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    see pages 35 - 37 of prc/2013-06-02 for details

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: referencedEntity in Value Set Definitions should include an optional description

  • Key: CTS211-3
  • Legacy Issue Number: 18470
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    AssociatedEntitiesReference.referencedEntity and SpecificEntityList.referencedEntity are currently of type URIAndEntityName. This does not provide any place to include a designation or description of the entity. The type should be changed to EntitySynopsis

    Logged: https://github.com/cts2/cts2-specification/issues/141

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    See issue 18532 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: DocumentURI shouldn't be mandatory in ResourceVersionDescription

  • Key: CTS211-6
  • Legacy Issue Number: 18473
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The DocumentURI was intended to differentiate situations where there were potentially multiple sources of the same version of a resource (e.g. SNOMED CT 20120731 from RF1, RF2, RRF or Owl). This is the exception, rather than the rule, and the DocumentURI field should be made optional for clarity.

    Logged: https://github.com/cts2/cts2-specification/issues/138

  • Reported: CTS2 1.0 — Fri, 22 Feb 2013 05:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    Resolution (PIM)
    Change Location 1
    Document "CTS2 - Core Model Elements, v1.0"
    Section 2.7.2
    Page 40
    Figure 2.17
    Change Description 1
    Updated diagram in Figure 2.17
    Old Diagram:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS 2: SortCriteria contains PropertyReference

  • Key: CTS2F2-4
  • Legacy Issue Number: 16940
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    SortCriteria contains PropertyReference, which implies that the user needs to know the EntityName AND URI of the Property to sort. We want all user input to be Name OR URI. There needs to be a flavor of SortCriteria that doesn't require the user to know the Name AND URI of the Property to sort.

    Logged: https://github.com/cts2/cts2-specification/issues/5

  • Reported: CTS2 1.0b1 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    In the type 'SortCriterion', the element 'sortElement' was changed from:
    type="core:PropertyReference"
    to
    type="PropertyNameOrURI"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS 2: Change 'applicableContext' cardinality in ConceptDomainBinding (XSD) to 0..1

  • Key: CTS2F2-3
  • Legacy Issue Number: 16939
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    'applicableContext' cardinality in ConceptDomainBinding (XSD) needs to change to 0..1 to align with the PIM.

    Logged: https://github.com/cts2/cts2-specification/issues/4

  • Reported: CTS2 1.0b1 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Changed the 'applicableContext' attribute of ConceptDomainBinding from:
    minOccurs="0" maxOccurs="unbounded"
    to:
    minOccurs="0" maxOccurs="1"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Move 'bindingQualifier' in ConceptDomainBinding (XSD) to an Element

  • Key: CTS2F2-2
  • Legacy Issue Number: 16938
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    'bindingQualifier' in ConceptDomainBinding (XSD) should be moved to an Element of type BindingQualifierReference and be 0..1.

    Logged: https://github.com/cts2/cts2-specification/issues/3

  • Reported: CTS2 1.0b1 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • Attribute 'bindingQualifier' in ConceptDomainBinding (XSD) was removed.
    • Element of type BindingQualifierReference with cardinality 0..1 was added.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS 2: Change 'boundValueSet' cardinality in ConceptDomainBindingDirectoryEntry (XSD) to 1..1

  • Key: CTS2F2-1
  • Legacy Issue Number: 16937
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    'boundValueSet' cardinality in ConceptDomainBindingDirectoryEntry (XSD) needs to change from 0..* to to 1..1

    Logged: https://github.com/cts2/cts2-specification/issues/2

  • Reported: CTS2 1.0b1 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Change cardinality of ConceptDomainBindingDirectoryEntry from:
    minOccurs="0" maxOccurs="unbounded"
    to the XML default, which is:
    minOccurs="1" maxOccurs="1"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BaseMaintenanceService.updateChangeableMetadata parameters

  • Key: CTS2F2-10
  • Legacy Issue Number: 17074
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Add effectiveDate, changeNotes, changeSource parameters, all optional. Used to update ChangeDescription if supported by the service

    Logged: https://github.com/cts2/cts2-specification/issues/11

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Updated Diagram (Figure 3.7: Maintenace Service. Core, Page 56.)
    PSM:
    Add in the following elements to the type 'UpdateChangeableMetadataRequest':

    <xs:element name="updatedEffectiveDate" minOccurs="0">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="effectiveDate"
    type="core:DateAndTime" minOccurs="0"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    <xs:element name="updatedChangeNotes" minOccurs="0">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="changeNotes" type="core:OpaqueData"
    minOccurs="0"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    <xs:element name="updatedChangeSource" minOccurs="0">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="changeSource"
    type="core:SourceReference" minOccurs="0"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changeable/ChangeDescription typo

  • Key: CTS2F2-9
  • Legacy Issue Number: 17073
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Changeable/ChangeDescription typo

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS 2: FilterComponent is a PropertyReference and contains a MatchAlgorithm reference

  • Key: CTS2F2-5
  • Legacy Issue Number: 16941
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    FilterComponent is a PropertyReference and contains a MatchAlgorithm reference, which implies that the user needs to know the Name AND URI of both of these. We want all user input to be Name OR URI. There needs to be a flavor of FilterComponent that doesn't require the user to know the Name AND URI of these.

    Logged: https://github.com/cts2/cts2-specification/issues/6

  • Reported: CTS2 1.0b1 — Fri, 30 Dec 2011 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    A new FilterComponent type was introduced to extend from "PropertyNameOrURI" instead of "PropertyReference". This type is to be used for all client interaction into the interfaces on the PSM level.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AnonymousStatement target cardinality

  • Key: CTS2F2-6
  • Legacy Issue Number: 17070
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Target cardinalityTarget should be 1..* to allow things like unionof(a,b,c...). Need to change spec and schema

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 1.1: Statement Model. Statement, Page 2.)
    PSM:
    Change the 'target' element in the type 'AnonymousStatement' from
    <xs:element name="target" type="StatementTarget" minOccurs="1" maxOccurs="1">
    to
    <xs:element name="target" type="StatementTarget" minOccurs="1" maxOccurs="unbounded">

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ChangeDescription stereotypes

  • Key: CTS2F2-8
  • Legacy Issue Number: 17072
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    ChangeType, committed, containingChangeSet, prevChangeSet, changeDate and clonedResource should be ReadOnly

    Logged: https://github.com/cts2/cts2-specification/issues/9

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 2.12: CTS2 Change Model. Core, Page 30.)
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AnonymousStatement typo


CTS2: Resource content filtering for Query

  • Key: CTS211-37
  • Legacy Issue Number: 18610
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    In each Query Service, it would be helpful for the user to be able to select certain attributes of the resource to be included (or excluded). For instance, a user may only be interested in the Definitions, or a given named property. Right now, for the Query Service, the user is limited to either 1) the directory entry, or 2) the list representation, which is the entire resource. It would be helpful to have the option of something in between.

    Logged: https://github.com/cts2/cts2-specification/issues/155

  • Reported: CTS2 1.0 — Mon, 1 Apr 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    See OMG Issue 18474 (#137) for disposition.

    Disposition: See issue 18474 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: WADL Graph URLs need to change to better reflect AssociationDirectory as input

  • Key: CTS211-36
  • Legacy Issue Number: 18564
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    Currently, to get an association graph in REST, the graph is retrieved by:

    /codesystem/cs/version/1.0/graph

    It would be more correct to be like:

    /codesystem/cs/version/1.0/associations/graph

    to take into account the 'graph' taking in the association directory as an input. Right now, the 'graph' resource is used in place of the 'associations' resource, but this makes it very hard to do queries such as:

    /codesystem/cs/version/1.0/entity/C12345/children/graph

    Logged: https://github.com/cts2/cts2-specification/issues/152

  • Reported: CTS2 1.0 — Thu, 14 Mar 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: MapTargetList and MapTargetListList need a 'Message' wrapper for REST calls


CTS2: Cardinality of includesResolvedValueSet wrong on ResolvedValueSetHeader


CTS2: ValueSetDefinitionResolution 'resolve' method has incorrect return type

  • Key: CTS211-41
  • Legacy Issue Number: 18689
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    ValueSetDefinitionResolution 'resolve' method has incorrect return type. It should be IterableResolvedValueSet.

    6.1.1.1 Operation: resolve

    Resolve the value set definition against the supplied code system versions and/or version tags.

    ....

    Return Type: ResolvedValueSetDirectory

    should be:

    6.1.1.1 Operation: resolve

    Resolve the value set definition against the supplied code system versions and/or version tags.

    ....

    Return Type: IterableResolvedValueSet

    Logged: https://github.com/cts2/cts2-specification/issues/159

  • Reported: CTS2 1.0 — Fri, 26 Apr 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: Association derivation should be optional and not have a default

  • Key: CTS211-39
  • Legacy Issue Number: 18624
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The specification states that derivation can be ASSERTED, INFERRED or omitted, meaning that the derivation is unknown. The UML diagram shows it as required, which is wrong. The XML Schema shows it with a default of ASSERTED, which also needs to be removed.

    Logged: https://github.com/cts2/cts2-specification/issues/157

  • Reported: CTS2 1.0 — Tue, 9 Apr 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    see pages 258 - 260 of ptc/2013-06-02 for details

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: MapEntry Read and Resolution need WADL 'byURI' REST signatures

  • Key: CTS211-35
  • Legacy Issue Number: 18563
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    In the WADL, two MapEntry URLS were omitted:
    map/

    {map}/version/{version}/entrybyuri?uri=...
    map/{map}

    /version/

    {version}

    /entrybyuri/resolution?uri=.

    Logged: https://github.com/cts2/cts2-specification/issues/153

  • Reported: CTS2 1.0 — Thu, 14 Mar 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CTS2: AssociationDirectory needs the derivation

  • Key: CTS211-38
  • Legacy Issue Number: 18622
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Cory Endle)
  • Summary:

    The derivation attribute (INFERRED/ASSERTED) needs to be visible in an association directory, as it helps consumers understand the abstract structure.

    Logged: https://github.com/cts2/cts2-specification/issues/156

  • Reported: CTS2 1.0 — Mon, 8 Apr 2013 04:00 GMT
  • Disposition: Resolved — CTS2 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Type of maxtoreturn is string in the WADL definitions. It should be NaturalNumber (or equiv)


SpecificEntityList incorrectly supertyped

  • Key: CTS2F2-21
  • Legacy Issue Number: 17085
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    in ValuseSetDefinition.xsd, SpecificEntityList is defined as an extension of ValueSetDefinitionEntry. This is not correct - it should be a stand alone type.

    Logged: https://github.com/cts2/cts2-specification/issues/24

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Remove the 'ValueSetDefinitionEntry' extension from the complex type 'SpecificEntityList'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Designation and Note have inconsistent pattern in schema

  • Key: CTS2F2-20
  • Legacy Issue Number: 17084
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Core.xsd defines Note with both assertingInCodeSystemVersion and externalId as attributes, making the type of assertingCodeSystemVersion "CodeSystemVersionName". Entity.xsd defines Designation them both as elements, with the type of assertingCodeSystemVersion set to "CodeSystemVersionReference".

    Recommend that the Note pattern be used in Designation as well

    Logged: https://github.com/cts2/cts2-specification/issues/23

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Apply the element/attribute convention of the type 'Note' to the type 'Designation'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NamedEntityDescription and AnonymousEntityDescription incorrectly defined in schema

  • Key: CTS2F2-22
  • Legacy Issue Number: 17086
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The XML Schema uses xsd:restriction to constrain the type of URI that can be used in EntityDescription. It accidentally factored out the name and description attributes, however. This change has been submitted to version control

    Logged: https://github.com/cts2/cts2-specification/issues/25

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    A sequence was inserted include the name and description attributes (addtion shown below):
    <xs:sequence>
    <xs:element name="name" type="ScopedEntityName" minOccurs="0">
    <xs:annotation>
    <xs:documentation>the namespace and name by which this
    entity is known within the context of the service
    implementation</xs:documentation>
    </xs:annotation>
    </xs:element>
    <xs:element name="knownEntityDescription"
    type="DescriptionInCodeSystem" minOccurs="0"
    maxOccurs="unbounded">
    <xs:annotation>
    <xs:documentation>a reference to a version of a code
    system that makes one or more assertions about the
    referenced entity. Note that only one version of a
    given code system is allowed in the
    <i>describingCodeSystem</i> list. Unless specified
    otherwise in a specific call, the code system version
    with the tag "CURRENT" must be
    used.</xs:documentation>
    </xs:annotation>
    </xs:element>
    </xs:sequence>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UpdateCodesystemCatalogEntry.usedOntologyEngineeringTool optionality

  • Key: CTS2F2-12
  • Legacy Issue Number: 17076
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 2.4 :Code System Catalog Maintenance. Code System Catalog, Page 15.)

    PSM:
    Update the ''UpdateCodeSystemCatalogEntry' type with a new element to allow for updates of 'usedOntologyEngineeringTool'.

    Add in an element to 'UpdateCodeSystemCatalogEntry' to allow for updates of 'usedOntologyEngineeringTool'

    <xs:element name="updatedUsedOntologyEngineeringTools"
    minOccurs="0">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="usedOntologyEngineeringTool"
    type="core:OntologyEngineeringToolReference"
    minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Core spec typos


Documentation issue on ProfileElement

  • Key: CTS2F2-24
  • Legacy Issue Number: 17088
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The documentation for ProfileElement in CoreService.xsd is not correct. Need to chase this back to its source and fix it.

    Logged: https://github.com/cts2/cts2-specification/issues/27

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    N/A

    PSM:
    Add the following documentation to the 'ProfileElement' type:

    ProfileElement appears in service implementations, once per structural profile that is supported by the implementation instance. Each occurrence records the set of functional profiles that are supported for the specific structural profile

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ImplementationProfiles.ProfileElement not RESTful

  • Key: CTS2F2-23
  • Legacy Issue Number: 17087
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    There is currently no way to get to each of the service implementations from the main page of the service. The XML Schema for Profile Element needs to support (require?) a href for each of the profile element functions. As an example, if a service supports SP_CODE_SYSTEM FP_READ, there should be a URL that links to the service implementation of CodeSystemCatalogEntryReadService

    Logged: https://github.com/cts2/cts2-specification/issues/26

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    N/A

    PSM:
    Create a new type 'FunctionalProfileEntry' and associated it to 'ProfileElement' as shown below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodesystemCatalogEntry.usedOntologyEngineeringTool

  • Key: CTS2F2-13
  • Legacy Issue Number: 17077
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Type should be OntologyEngineeringToolReference...

    Check omv for "used" vs. "uses"

    Logged: https://github.com/cts2/cts2-specification/issues/16

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 1.1: Code System Catalog Entry. Code System, Page 3.)

    PSM:
    Add in a 'usedOntologyEngineeringTool' element to the type 'CodeSystemCatalogEntry'.
    <xs:element name="usedOntologyEngineeringTool"
    type="core:OntologyEngineeringToolReference" minOccurs="0"
    maxOccurs="unbounded">
    <xs:annotation>
    <xs:documentation>information about a tool used to create
    the ontology</xs:documentation>
    </xs:annotation>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UpdateEntityDescription is missing elements and does not support "optparam" semantics

  • Key: CTS2F2-19
  • Legacy Issue Number: 17083
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Need to add all parameters to UpdateEntityDescription and add the optparam pattern:

    xs:complexType

    xs:sequence

    /xs:sequence

    /xs:complexType

    /xs:element

    Logged: https://github.com/cts2/cts2-specification/issues/22

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Wrapper all mutable elements in the pattern show above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityDescriptionQueryService lacking supportedVersionTag

  • Key: CTS2F2-18
  • Legacy Issue Number: 17082
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    EntityDescriptionServices.xsd doesn't have suppportedVersionTag in the query service

    Logged: https://github.com/cts2/cts2-specification/issues/21

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Add a new Element to the complexType "EntityDescriptionQueryService."
    <xs:element name="supportedVersionTag" type="core:VersionTagReference"
    minOccurs="1" maxOccurs="unbounded"/>

  • Updated: Fri, 6 Mar 2015 20:58 GMT



EntityDescriptionReadService lacking local variables

  • Key: CTS2F2-17
  • Legacy Issue Number: 17081
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    EntityDescriptionServices.xsd doesn't have knownCodeSystem, knownCodeSystemVersion or supportedVersionTag in the schema.

    Logged: https://github.com/cts2/cts2-specification/issues/20

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    Added the following elements to the complexType "EntityDescriptionReadService"

    <xs:element name="knownCodeSystem" type="core:CodeSystemVersionReference" minOccurs="0" maxOccurs="unbounded"/>

    <xs:element name="knownCodeSystemVersion" type="core:CodeSystemVersionReference" minOccurs="0" maxOccurs="unbounded"/>

    <xs:element name="supportedVersionTag" type="core:VersionTagReference" minOccurs="1" maxOccurs="unbounded"/>

  • Updated: Fri, 6 Mar 2015 20:58 GMT


Refactor inline XSD types from WSDLs (SOAP PSM)

  • Key: CTS2F2-38
  • Legacy Issue Number: 17119
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    All CTS2 WSDLs contain inline XSD type definitions. We would like to refactor those out into separate XSD files in order to make code generation easier for tooling (mainly, Castor).

    Logged: https://github.com/cts2/cts2-specification/issues/41

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    XSD declarations inside of WSDL files were making it difficult for tooling to process and generate code from the WSDL files. To work around this, and to make a clean separation between WSDL 'types' and WSDL 'functionality', all types that were previously inlined into the wsdl via the wsdl:types tag have been refactored into an XSD file.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ResolvedValueSetReadService and QueryService omitted from spec

  • Key: CTS2F2-37
  • Legacy Issue Number: 17118
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    ResolvedValueSet needs two additional service entries - a read service that carries:

    read (by RVS URI)

    resolveAsEntityDirectory

    resolveAsCompleteSet

    (Same methods as the ValueSetResolutionService except that the argument is a single ResolvedValueSetURI)

    and a simple query service that carries:

    contains(resolvedSet, EntityNameOrURIList (move from loader)

    resolvedSetsFor(EntityNameOrURI, ...) -> tells which resolved sets carry the entity

    Logged: https://github.com/cts2/cts2-specification/issues/40

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    1. Introduce a new type - 'IterableResolvedValueSet' - and change the 'ResolvedValueSetDirectoryEntry' to be a subtype of 'ResolvedValueSetSummary.'
    2. Added a new service, 'ResolvedValueSetResolution' Service, which follows the same general resolution patterns as 'ValueSetDefinitionResolution' service. The 'contains' method is moved from 'ResolvedValueSetLoader' to this new 'ResolvedValueSetResolution' service.

    3. Add a new type of DirectoryURI, "ResolvedValueSetDirectoryURI.
    4. In order to query for 'ResolvedValueSets', a new service - 'ResolvedValueSetQuery' Service was added
    PSM:
    Added an 'IterableResolvedValueSet' type.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ResolvedValueSetDirectory misnamed and mistyped

  • Key: CTS2F2-36
  • Legacy Issue Number: 17117
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    ResolvedValueSetDirectory is the return type of the "resolve" function for ValueSetDefinitionResolution, which should return a ResolvedValueSetHeader as part of the directory and an iteratable EntitySynopsis list. Both the name and model of this particular return type need to be fixed. This change applies to the UML and spec, the XML Schema and the WSDL/WADL

    Logged: https://github.com/cts2/cts2-specification/issues/39

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Updated Diagram (Figure 3.4: Resolved ValueSet. ValueSetDefinition, Page 27.)
    PSM: Add the type 'IteratableResolvedValueSet' to allow for iterable access of a 'ResolvedValueSet'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AdvancedAssociationQuerySerivce not in WADL (REST PSM)

  • Key: CTS2F2-35
  • Legacy Issue Number: 17116
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The AdvancedAssociationQuerySerivce is not fully specified in the WADL (REST PSM). The actual AdvancedAssociationQuerySerivce url (/service/advancedassociationqueryservice) is specified, but not the implementation.

    Logged: https://github.com/cts2/cts2-specification/issues/38

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    The AdvancedAssociationQuerySerivce resources were added to the cts2.wadl. A resource 'graph' was added with all parameters outlined below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Information Model derivation and derivationReasoningAlgorithm

  • Key: CTS2F2-34
  • Legacy Issue Number: 17115
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Derivation and derivationReasoningAlgorithm shouldn't be marked as

    {readOnly}

    , as it is not part of the identity of Association. These two fields need to be added as optparams in UpdateAssociationRequest (Needs to be changed in the WADL and Schema as well.

    Logged: https://github.com/cts2/cts2-specification/issues/37

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 4.1: Association Model. Association, Page 43.)
    Updated Diagram (Figure 5.4: Association Maintenance. Association, Page 67.)

    PSM:
    Add the following elements to the 'UpdateAssociationRequest' type:
    <xs:element minOccurs="0" name="updatedDerivation">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="derivation" type="association:AssociationDerivation" minOccurs="1" maxOccurs="1"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    and
    <xs:element minOccurs="0" name="updatedDerivationReasoningAlgorithm">
    <xs:complexType>
    <xs:sequence>
    <xs:element name="derivationReasoningAlgorithm" type="core:ReasoningAlgorithmReference" minOccurs="1" maxOccurs="1"/>
    </xs:sequence>
    </xs:complexType>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT



Statement needs an identifier

  • Key: CTS2F2-31
  • Legacy Issue Number: 17112
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Need to add an identifier to the statement model:

    statementURI : ExternalURI

    {readOnly}



    and add an invariant that entryID = statementURI



    This is the identity.



    subject, predicate, assertedBy, assertedIn all need to be set to {readOnly}

    to indicate that they are part of the statement identity.

    Logged: https://github.com/cts2/cts2-specification/issues/34

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 1.1: Statement Model. Statement, Page 2.)

    PSM:
    Added a 'StatementURI' element to the type 'Statement'

    <xs:element name="statementURI" type="core:URI"
    minOccurs="1" maxOccurs="1">
    <xs:annotation>
    <xs:documentation>The unique statement identifier. Must be globally unique if information is to be exchanged and updated on the statement leve.</xs:documentation>
    </xs:annotation>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemVersionCatalogReadServices WSDL corrections

  • Key: CTS2F2-42
  • Legacy Issue Number: 17176
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Renamed method 'getCodeSystemVersionByExternalId' to 'getCodeSystemByVersionId'.

    Renamed method 'existsExternalId' to 'existsVersionId'.

    Logged: https://github.com/cts2/cts2-specification/issues/45

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • Renamed method 'getCodeSystemVersionByExternalId' to 'getCodeSystemByVersionId'.
    • Renamed method 'existsExternalId' to 'existsVersionId'.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemCatalogQueryServices WSDL corrections


CodeSystemCatalogHistoryServices WSDL corrections

  • Key: CTS2F2-40
  • Legacy Issue Number: 17174
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Added 'timeout' parameter to 'count' method

    Changed 'getLatestChangeFor' method name to 'getLastChangeFor' to match the PIM

    Logged: https://github.com/cts2/cts2-specification/issues/43

  • Reported: CTS2 1.0b1 — Tue, 1 May 2012 04:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In 'count' method added 'timeout' param.
    • Changed 'getLatestChangeFor' method name to 'getLastChangeFor' to match the PIM

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemCatalogMaintenanceServices WSDL corrections

  • Key: CTS2F2-39
  • Legacy Issue Number: 17173
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'updateChangeableMetadata', removed params 'target' and 'owner' and addded 'entryID' to match the spec.

    In method 'validateChangeSet', added param 'validationLevel'.

    In method 'readChangeSet', added param 'queryControl'.

    In method 'putChangeSet', added parameter 'errorResponse'.

    Logged: https://github.com/cts2/cts2-specification/issues/42

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'putChangeSet' add param 'errorResponse'
    • In method 'validateChangeSet' add param 'validationLevel'
    • In method 'readChangeSet' add param 'queryControl'
    • In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ConceptDomainbinding needs an identifier

  • Key: CTS2F2-30
  • Legacy Issue Number: 17111
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Need to add an id attribute to ConceptDomainBinding:

    bindingURI: DocumentURI

    {readOnly}

    Need to add an assertion that bindingURI = entryID

    Logged: https://github.com/cts2/cts2-specification/issues/33

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 3.1: Concept Domain Binding Model. Concept Domain, Page 17.)

    PSM:
    Added a 'bindingURI' element to the type ''ConceptDomainBinding'

    <xs:element name="bindingURI" type="core:DocumentURI"
    minOccurs="1" maxOccurs="1">
    <xs:annotation>
    <xs:documentation>The unique identifier of this particular
    binding instance.</xs:documentation>
    </xs:annotation>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BaseQueryService filter property needs to be individualized

  • Key: CTS2F2-29
  • Legacy Issue Number: 17110
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The filter property (type Filter) on BaseQueryService does not work as an input parameter. It needs to be replaced, instead, with:

    matchAlgorithm: NameOrURI

    matchValue: String OPT

    refType: TargetReferenceType

    referenceTarget: EntityNameOrURI

    Logged: https://github.com/cts2/cts2-specification/issues/32

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Change the signature of restrict to the following: (Diagram below)
    PSM:
    Added the following elements to the 'Query' element:
    <xs:element name="matchAlgorithm" type="NameOrURI" minOccurs="0">
    <xs:annotation>
    <xs:documentation> The match algorithm of the filter to be
    applied. If a 'setOperation' is specified, the filter
    will apply to the resulting aggregate.
    </xs:documentation>
    </xs:annotation>
    </xs:element>
    <xs:element name="matchValue" type="core:String" minOccurs="0">
    <xs:annotation>
    <xs:documentation> The match value of the filter to be
    applied. If a 'setOperation' is specified, the filter
    will apply to the resulting aggregate.
    </xs:documentation>
    </xs:annotation>
    </xs:element>
    <xs:element name="filterComponent" type="NameOrURIList"
    minOccurs="0">
    <xs:annotation>
    <xs:documentation> The target components of the filter to
    be applied. If a 'setOperation' is specified, the
    filter will apply to the resulting aggregate.
    </xs:documentation>
    </xs:annotation>
    </xs:element>

    while removing the following element:
    <xs:element name="filter" type="core:Filter" minOccurs="0">
    <xs:annotation>
    <xs:documentation> The filter to be applied. If a
    'setOperation' is specified, the filter will apply to
    the resulting aggregate. </xs:documentation>
    </xs:annotation>
    </xs:element>

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Schema for BaseService has wrong type for supported Profile

  • Key: CTS2F2-25
  • Legacy Issue Number: 17089
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    The type of SupportedProfile should be ProfileElement, not StructuralProfile

    Logged: https://github.com/cts2/cts2-specification/issues/28

  • Reported: CTS2 1.0b1 — Mon, 30 Jan 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    In the type 'BaseService', change 'SupportedProfile' from:
    <xs:element name="supportedProfile" type="StructuralProfile" minOccurs="1" maxOccurs="unbounded">
    to:
    <xs:element name="supportedProfile" type="ProfileElement" minOccurs="1" maxOccurs="unbounded">

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemVersionCatalogMaintenanceServices WSDL corrections

  • Key: CTS2F2-44
  • Legacy Issue Number: 17178
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'updateChangeSetMetadata', add param 'officialEffectiveDate/

    In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'.

    In method 'deleteChangeable' remove param 'target' and add param 'changeableResource'.

    In method 'validateChangeSet' add param 'validationLevel'.

    In method 'readChangeSet' add param 'queryControl'.

    In method 'putChangeSet' add param 'errorResponse'.

    Logged: https://github.com/cts2/cts2-specification/issues/47

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In method 'putChangeSet' add param 'errorResponse'
    • In method 'validateChangeSet' add param 'validationLevel'
    • In method 'readChangeSet' add param 'queryControl'
    • In method 'updateChangeableMetadata' remove params 'target' and 'owner' and add param 'entryID'
    • In method 'deleteChangeable' remove param 'target' and add param 'changeableResource'.
    • In method 'updateChangeSetMetadata', add param 'officialEffectiveDate'

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CodeSystemVersionCatalogQueryServices WSDL corrections

  • Key: CTS2F2-43
  • Legacy Issue Number: 17177
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    In method 'resolveAsList', rename param 'control' to 'queryControl' to match spec.

    In method 'count', add a 'timeout' param.

    Logged: https://github.com/cts2/cts2-specification/issues/46

  • Reported: CTS2 1.0b1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: N/A
    PSM:
    • In 'count' method added 'timeout' param.
    • In method 'resolveAsList', rename param 'control' to 'queryControl' to match spec.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Changeable changeDescription cardinality constraint

  • Key: CTS2F2-28
  • Legacy Issue Number: 17109
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Need to add an invariant to Changeable indicating that the changeDescription cardinality must be 1..1 if the profile supports HISTORY or MAINTENANCE

    Logged: https://github.com/cts2/cts2-specification/issues/31

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM: Update PIM text
    PSM: N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityReferences - URIAndEntityNameList


Remove CONCEPT_DOMAIN_BINDING from ReferenceType

  • Key: CTS2F2-26
  • Legacy Issue Number: 17107
  • Status: closed  
  • Source: Mayo Clinic ( Mr. Craig Stancl)
  • Summary:

    Concept Domain Bindings are not referenced anywhere in the specification and the entry needs to be removed from the ReferenceType model

    Logged: https://github.com/cts2/cts2-specification/issues/29

  • Reported: CTS2 1.0b1 — Thu, 9 Feb 2012 05:00 GMT
  • Disposition: Resolved — CTS2 1.0
  • Disposition Summary:

    PIM:
    Updated Diagram (Figure 2.4: Reference Types. Core, Page 10.)

    PSM:
    N/A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

COAS operations that return ObservationData

  • Key: COAS-35
  • Legacy Issue Number: 3042
  • Status: closed  
  • Source: 2AB ( Tim Brinson)
  • Summary:

    The COAS operations that return ObservationData are locked into using a
    structuring mechanism that is defined as a stop gap solution due to the
    lack of extensive support for the ValueTypes by ORBs today. This
    proposal addresses that problem by suggesting a simple change that
    allows the same COAS operational interfaces to be used in the future
    with ValueTypes (or additional types that may be created for IDL in the
    future).

    I propose that the current ObservationData type be renamed to
    ObservationDataStruct. Any data types that reference ObservationData
    would then reference ObservationDataStruct (with the exception of
    ObservationDataSeq). A typedef for ObservationData being of the type
    "any" would be created as such:

    typedef any ObservationData;

    In this way observations are passed by value via the "any" type
    (actually a typedef to the "any" type) in the operations which frees up
    the possibility of using ValueType (and other type) definitions for
    observations in the future or by local agreement in specialized
    environments.

    In addition a new Conformance class (e.g. "Structured COAS") should be
    created that indicates a server uses the ObservationDataStruct as the
    explicit type returned/passed in via the ObservationData in operations.
    This allows future standardization using value types in which additional
    conformance points can be made for other structuring used by servers.
    Note these conformance classes are independent of the conformance
    classes specifying which interfaces a server implements.

  • Reported: COAS 1.0b1 — Wed, 17 Nov 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 193 Under section - D.3 Secure Interoperability Concerns

  • Key: COAS-32
  • Legacy Issue Number: 3011
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 193 Under section - D.3 Secure Interoperability Concerns
    Text in question:
    "Each CSI level is parameterized by mechanisms that can support the level of security functionality, such as SPKM for CSI Level 0, GSS Kerberos for CIS Level 0 or CIS Level 1, and CSI_ECMA for CSI Level 2. Future developments in security functionality and mechanism are not restricted, and mechanisms can be added to each level."

    Misspelling.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 208 Under section - 12.7 AbbreviatedCorba.idl

  • Key: COAS-31
  • Legacy Issue Number: 3010
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 208 Under section - 12.7 AbbreviatedCorba.idl
    Suggest remove & just document that COAS only uses TCKind & RepositoryId.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservatio

  • Key: COAS-34
  • Legacy Issue Number: 3013
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 71, 157 Under section - 3.3.2.1 Abbreviated Includes & B.1 DSObservationAccess ObservationType
    Imported enums are dangerous. This has to do with TCKind and get_observation_type.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram

  • Key: COAS-33
  • Legacy Issue Number: 3012
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 9 Under section - 3.2.2.1 Clinical Observations Model - Class Diagram
    Ensure that the semantics of the aggregate relationship and the cardinality is what is meant.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 145-152 Under section - 3.8.1-3.8.17

  • Key: COAS-29
  • Legacy Issue Number: 3008
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 145-152 Under section - 3.8.1-3.8.17
    A multitude of const were typedefed yet in the const declaration the primitive type was used.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 141 Under section - 3.7.1 General

  • Key: COAS-28
  • Legacy Issue Number: 3007
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 141 Under section - 3.7.1 General
    Text in question:
    • replace "/" with "_".
    • replace space with nothing, capitalizing next word.
    • Omit apostrophe, periods, parenthesis, and other punctuation.

    Needs to be indented.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 129 Under section - 3.5.4 Sequence Types

  • Key: COAS-26
  • Legacy Issue Number: 3005
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 129 Under section - 3.5.4 Sequence Types
    Text in question:
    case OtherSeqDataType : any the_any;

    Is the any required to be a sequence? Or can it be just any old any?

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 120 Under section - 3.4.2 Supporting Types

  • Key: COAS-25
  • Legacy Issue Number: 2999
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 120 Under section - 3.4.2 Supporting Types
    Text in question:
    typedef DsObservationAccess::AbstractManagedObjectAbstractManagedObject;

    Missing a space.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 81 Under section - 3.3.2.5 Constants

  • Key: COAS-24
  • Legacy Issue Number: 2998
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 81 Under section - 3.3.2.5 Constants
    Text in question:
    const QualifiedCodeStr PARTIAL_RESULT
    const QualifiedCodeStr COMPLETING_RESULT
    const QualifiedCodeStr ASYNC_OBSERVATION_COUNT
    const QualifiedCodeStr EVENT_SOURCE_DOMAIN
    const QualifiedCodeStr EVENT_SOURCE_SERVER_NAME
    const QualifiedCodeStr EVENT_NAME
    const QualifiedCodeStr TEST_EVENT
    const QualifiedCodeStr TRADER_1_0_CONSTRAINT_LANGUAGE
    const QualifiedCodeStr OCL_1_1_CONSTRAINT_LANGUAGE
    const QualifiedCodeStr COAS_OBSERVATION_ID

    Complete the const spec here are simply state names of constants & refer to IDL.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typedefs for TimeStamp and TimeSpan that are never used

  • Key: COAS-36
  • Legacy Issue Number: 3136
  • Status: closed  
  • Source: Cognition Group, Inc. ( David Forslund)
  • Summary:

    DsObservationValues.idl has typedefs for TimeStamp and TimeSpan that are
    never used. Why not delete them since they create problems in the IDL2Java
    mapping by creating *Helper classes than cause name collisions?
    DsObservationQualifers.idl has a typedef for TimeStamp that also is not used.

    Can we remove these references? They can have no impact on any
    application that uses these interfaces.

  • Reported: COAS 1.0b1 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 133 Under section - 3.6.1 Genera

  • Key: COAS-27
  • Legacy Issue Number: 3006
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 133 Under section - 3.6.1 General
    Text in question:
    • replace "/" with "_".
    • replace space with nothing, capitalizing next word.
    • Omit apostrophe, periods, parenthesis, and other punctuation.

    Needs to be indented.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 153 Under section - 3.9 Conformance Classes

  • Key: COAS-30
  • Legacy Issue Number: 3009
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 153 Under section - 3.9 Conformance Classes
    Doesn't say what one needs to do to claim conformance to this spec I guess the requirement is conformance to at least one?

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interfaces are presented in alphabetical order and not in logical order

  • Key: COAS-17
  • Legacy Issue Number: 2991
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It took me a LONG time to realize that the interfaces are presented in alphabetical order and not in any logical order. A sentence to explain this would have been useful. While that organization may be useful from a reference perspective it is very confusing when you try to read the specification and understand the functionality and how it is partitioned between the interfaces. This significantly increased the time it took me to review the submission.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 108 Under section - 3.3.3.13 FederatedAccess

  • Key: COAS-16
  • Legacy Issue Number: 2990
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 108 Under section - 3.3.3.13 FederatedAccess
    The name of this interface was confusing to me. In the CORBA world I think of federation as a way to connect multiple services, not just a way to get data feeds to a single service from other services. I'm not saying this isn't important, just that I think the interface name is confusing.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 70 Under section -3.3.2.1 Include Files

  • Key: COAS-20
  • Legacy Issue Number: 2994
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 70 Under section -3.3.2.1 Include Files
    This abbreviated include must not be part of the standard - it is a deployment convenience. 5.2.1 dealing with abbreviated includes should not be normative.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 5 Under section - 3.1.5 BOCA & CDL

  • Key: COAS-19
  • Legacy Issue Number: 2993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Text in question:
    "Although the Business Object Component Architecture (BOCA) was not adopted as an OMG specification, a portion of the work defining Common Business Objects was adopted.

    There is interest in defining COAS such that it will build on top of the appropriate Common Business Objects, and that in the future if a BOCA specification is adopted, the COAS can be used as a stand-alone service and also as a business object compatible with the BOCA. Since this is new ground, it will take some experimentation to determine the way to accomplish this."

    Statement of pious intentions regarding unpredictable future events.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 79 Under section - 3.3.2.4.9 TimeStamp


Pg. 75 Under section - 3.3.2.4.3 ObservationData

  • Key: COAS-22
  • Legacy Issue Number: 2996
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue:
    Pg. 75 Under section - 3.3.2.4.3 ObservationData
    This is strange use of IDL. I would have used a union for composite and value.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 95 Under section - 3.3.3.5 AsynchCallBack

  • Key: COAS-15
  • Legacy Issue Number: 2989
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 95 Under section - 3.3.3.5 AsynchCallBack
    put_observations() The text states that the as_iterator is a sequence. It is not. It is an objref. Also there is no mention of what it means if the are_iterators_supported is FALSE

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 92 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-14
  • Legacy Issue Number: 2988
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 92 Under section - 3.3.3.3 AccessComponent
    get_observation_type() I'm unclear the purpose of this parameter and also the description of where it is applicable is unclear. "will be returned" from what operations? What if it isn't? I'm just not sure what the purpose of this actually is.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 90 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-12
  • Legacy Issue Number: 2986
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 90 Under section - 3.3.3.3 AccessComponent
    It is not stated whether each interface is required to return the same response to one of these operations being called.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10

  • Key: COAS-11
  • Legacy Issue Number: 2985
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 88 Under section - Asynchronous Access Viewpoint 5.1.10
    Your definition of a clinical observation specifically states a human being as the subject (which I thought was a bit restrictive), but in this section you admit it might be an animal

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 5 Under section - 3.1.4 Objects By Value (OBV)

  • Key: COAS-18
  • Legacy Issue Number: 2992
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 5 Under section - 3.1.4 Objects By Value (OBV)
    Text in question:
    "Also, typical usage patterns of OBV, appropriate to healthcare, have not been identified. During the implementation phase of the COAS specification, it is expected that these patterns will be identified, and changes may be recommended through normal OMG revision processes."

    May be beyond the scope of what an FTF or RTF is allowed to do.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 71 Under section - 3.3.2.1 Include Files

  • Key: COAS-21
  • Legacy Issue Number: 2995
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 71 Under section - 3.3.2.1 Include Files
    Text in question:
    "Another abbreviated file, AbbreviatedCorba.idl, includes two definitions from the fundamental CORBA 2.2 definitions. This file is provided as part of the normative section for convenience. The full CORBA 2.2 IDL specification for ORB vendors, in plain IDL, is lengthy and may not be easily available in IDL text format."

    It must not be normative.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 86 Under section - 3.3.2.8 Exceptions

  • Key: COAS-10
  • Legacy Issue Number: 2984
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 86 Under section - 3.3.2.8 Exceptions
    The description of these exceptions is not sufficient for an implementation to know what the actual meaning of the results should be. For example, the "Duplicate*" exceptions; is it required that the service parse all inputs and return all duplicates or may it return only the first duplicate found? The same question for Invalid* exceptions

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 91 Under section - 3.3.3.3 AccessComponent

  • Key: COAS-13
  • Legacy Issue Number: 2987
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 91 Under section - 3.3.3.3 AccessComponent
    get_supported_codes() It wasn't clear to me what a "query code" is. This should be clarified.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

alternative verbs for Federated access and put_obsevations

  • Key: COAS-7
  • Legacy Issue Number: 2936
  • Status: closed  
  • Source: Level Seven Visualizations ( Jon Farmer)
  • Summary:

    here are our desired positions in dimensions of connotation:

    • multiple instance vs. one instance vs. one atribute of an instance - we
      want to connote multiple instances
    • does a the requestor get any info back - no.

    ======== options, their thesaurus equivalents, and assessment for
    suitability ===================
    place - connotes location to explicitly

    put or put-in (insert, place, store, publish) - reasonable but can we do
    better?

    write (communicate, mark, record) - implies recording on a persistence
    medium - too underlying technology-connotative

    load - has precedent in pids; implies multiple, and already understood in IS
    as "batch" and one-way-transfer with no significant return info. I also lke
    the "ammo" connotation. We are "charging" a sevice with useful info or
    potential energy - ready to be put to useful work.

    add - in o-o circles, this connotes adding an (singleton) entry to a
    dictionary or to a container.

    set - connotes setting a property or a primitive value. no batch semantics
    permitted.

    ======================= my recommendation

    interface: ObservationLoader (a utility with a manifest puprose)

    operation: load_observations

  • Reported: COAS 1.0b1 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pg. 81 Under section - 3.3.2.5 Constants

  • Key: COAS-9
  • Legacy Issue Number: 2983
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Pg. 81 Under section - 3.3.2.5 Constants
    Many of the constants do not have the values specified in this section although they are in the IDL.

  • Reported: COAS 1.0b1 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

how to use HL7 data types

  • Key: COAS-8
  • Legacy Issue Number: 2981
  • Status: closed  
  • Source: 2AB ( Tim Brinson)
  • Summary:

    This is an issue for both the PIDS2 RTF and the COAS FTF.

    The PIDS and COAS specifications both indicate how to use HL7 data types
    with those services but neither have specified a way for an
    implementation to claim conformance to using them. A conformance point
    should be added to both specifications. This will enhance the
    expectations of interoperability for using those services since a user
    and of the servcie and the servcie have to be compatible on the
    information type specification as well as the service specification.

  • Reported: COAS 1.0b1 — Mon, 8 Nov 1999 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    resolved in COAS FTF

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GCPR issue: Exceptions

  • Key: COAS-37
  • Legacy Issue Number: 4019
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the current specification we find that exceptions are limited. For example, when invoking get_observations_by_time, the patient specified may not exist on the server. We can return empty ObservationData in this case, but a more descriptive exception such as "patient not found" would be useful here. Other exceptions that give information for "no results found" or "unable to get access" or "system down" etc. would give the client more flexibility to notify the user of the status of the call and how to handle any repeated tries. In other words, more application level information should be allowed to be sent back. These types of enhancements will require input from programmers and developers to make sure we capture relevant and meaningful exceptions.

  • Reported: COAS 1.0b1 — Mon, 6 Nov 2000 05:00 GMT
  • Disposition: Resolved — COAS 1.0
  • Disposition Summary:

    see above, issue rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA sequence IDL type in COBOL

  • Key: COBOL-5
  • Legacy Issue Number: 626
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Under the current standard, the sequence accessor functions have no way of knowing how big each element in a sequence is.Add another element to the sequence type describing length of elements

  • Reported: COBOL 1.0b1 — Wed, 16 Jul 1997 04:00 GMT
  • Disposition: Resolved — COBOL 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

COBOL Typedefs NOT universally available

  • Key: COBOL-4
  • Legacy Issue Number: 603
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: COBOL typedefs have not been standardized or are universally available. An easy-to-use alternative to proposed alternative of using COBOL COPY books needs to be found

  • Reported: COBOL 1.0b1 — Fri, 11 Jul 1997 04:00 GMT
  • Disposition: Resolved — COBOL 1.0
  • Disposition Summary:

    resolved, close dissue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing statement on compliance

  • Key: CMMN-13
  • Legacy Issue Number: 19002
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Compliance section should explicitly demand compliance with total spec.

    Most likely a section has to be added for this purpose.

    Note that this was a remark from the AB, back in December 2012, from the meeting in which the spec was adopted.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify section 2 of the spec

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in XML-Schema for CMMN (CMMN-1,2,3)

  • Key: CMMN-15
  • Legacy Issue Number: 19004
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    Description: The XML-Schema for CMMN has the following issues:
    1. CaseFileItemTransition restriction missing attribute 'base="xsd:string"'
    2. Attribute "id" of complex type "tDefinitions" MUST be of type "xsd:ID" (and not "xsd:IDREF")
    3. Complex Types "tTask" and "tEvent" MUST NOT be abstract

    Attached are the new XML-Schema files that fixes above issues.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify CMMN XML-Schema files CMMN10.xsd and CMMN10CaseModel.xsd

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add CMMN logo to front page of the spec

  • Key: CMMN-14
  • Legacy Issue Number: 19003
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    It is desirable to add a CMMN logo to the front page of the spec.

    ((The team had reached agreement on that already, based on a graphical proposal from Denis Gagne))

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, add CMMN logo designed by Denis to front page

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong Expression containment mutiplicity

  • Key: CMMN-12
  • Legacy Issue Number: 19001
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    As figure 12 shows, Expression is contained in three classes, all three with multiplicity 1. This is wrong, and should be 0..1.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify PlanItemControl metamodel in Figure 12, section 5.4.11

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong multiplicity of the two containments of process parameter in process

  • Key: CMMN-11
  • Legacy Issue Number: 19000
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Figure 11 shows how Process Parameter is contained twice in Process, both with mutiplicity 1. This is wrong. It should be 0..1

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify metamodel for Task in section 5.4.10

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sentries SHOULD be allowed for DiscretionaryItem's (CMMN-8)

  • Key: CMMN-16
  • Legacy Issue Number: 19005
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    It has turned out that many of our potential users of CMMN 1.0 naturally model
    discretionary items with Sentries associated to PlanItem's in the Stage and there are multiple
    use cases that would benefit from allowing Sentries on Discretionary Items.

    So we'd propose to allow Sentries on DiscretionaryItem's in a Planning Table with the restriction
    that those Sentries MUST refer PlanItem elements of the Planning Table Stage.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify PlanningTable metamodel (Figure 10) in section 5.4.9 and associated text in section 5.4.9.2 (DiscretionaryItem class)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 72 (Example CMMN model) is wrong in spec

  • Key: CMMN-17
  • Legacy Issue Number: 19006
  • Status: closed  
  • Source: Oracle ( Ralf Mueller)
  • Summary:

    The example case model in Figure 72 shows several Discretionary Plan Items with a Sentry on the boundary. Per specification, those items MUST NOT have sentries.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, provide new example

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Improve Motivation for introducing an EventListener

  • Key: CMMN-5
  • Legacy Issue Number: 18887
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    The following statement is used for motivating the introduction of the class EventListener:
    "However, elapse of time cannot be captured via these 'standard events', and it will often lead to very indirect modeling, when any user event..."
    Suggestion: To improve readability, change the text to:
    "However, elapse of time cannot be captured via these 'standard events'. Also, it will often lead to very indirect modeling..."
    When reading the current sentence, the reader might (at least initially) assume that the indirect modeling refers to elapse of time.

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify text in section 5.4.2

  • Updated: Fri, 6 Mar 2015 20:58 GMT

More intuitive symbols for entry and exit criterion

  • Key: CMMN-4
  • Legacy Issue Number: 18886
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    n the visual notation, a shallow and a solid diamond symbol are used for depicting entry and exit criterion.
    Both symbols are not intuitively understandable. Someone who learns the CMMN notation must explicitly learn the difference between shallow and solid symbol. It is likely that inexperienced modelers will mistake one symbol for the other.

    Suggestion: Use an incoming arrow symbol (similar to the UNICODE symbol 21E8) for a Sentry serving as entry criterion and analogously an outgoing arrow symbol for a Sentry serving as exit criterion. This notation will be understood intuitively.

    Note: I am aware of the fact that the currently suggested symbols are already used in the scientific works on the GSM approach. However, the CMMN standard is aimed to be used by a large number of people, including business people who do not have too much time to learn the notation (see the description of target users in section 4.3.). It would be simple for the few scholars who read the work on GSM to learn the new symbols. For inexperienced modelers, easy-to-lern symbols are a great help for adapting the language.

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Reject issue.
    Revised Text:

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Contradicting Definitions of Sentry

  • Key: CMMN-2
  • Legacy Issue Number: 18884
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    While on page 32 it is stated that a Sentry does not have to have an On-part, the text on page 33 says that a Sentry may consist of one or more OnParts.
    This can be read as a contradiction; the meaning of "may" is not clear enough.

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agree with problematic statement, text in section 5.4.6 has been modified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Expand TimeEventListener

  • Key: CMMN-1
  • Legacy Issue Number: 18883
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    For timeExpression, a string conforming to the ISO-8601 format is allowed.
    While this format would allow time events occurring at a given point of time, it is impossible to specify time events that occur after a given period of time that starts with a state change of an instance.
    For example, it would be impossible to specify that a time event occurs five days after an incoming invoice arrived.
    Suggestion: TimerEventListener should contain another attribute that allows to specify a point of time when the duration given in timerExpression starts. This point of time should correspond to a state change of an instance.

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Modify TimerEventListener Metamodel (Figure 6, section 5.4.2) to include references to PlanItem and CaseFileItem lifecycle state changes that triggers the start of a TimerEventListener

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Process and Case Task are inconsistent with BPMN call activity notation (CMMN-6)

  • Key: CMMN-8
  • Legacy Issue Number: 18997
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Nature: Revision
    Severity: Significant
    Chapter/Section: 6.7.2 (Case task) and 6.7.3 (Process Task)
    Page Number(s): 59 - 80

    Description: Process and Case Tasks are semantically similar to BPMN call activity, but do not have thick border lines. In addition, this proposal suggest that some markers should be optional markers for tool sets that combine both CMMN and BPMN.

  • Reported: CMMN 1.0b1 — Thu, 10 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, added sub-sections 6.7.2.1 and 6.7.3.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent AutomaticActivation and Repetition Decorators between CMMN and BPMN (CMMN-5)

  • Key: CMMN-7
  • Legacy Issue Number: 18996
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Chapter/Section: Chapter 6.12.2 (AutomaticActivation Decorator) and 6.12.4 (Repetition Decorator)
    Page Number(s): 68

    Description: There are inconsistencies in AutomaticActivation and Repetition decorators between CMMN and BPMN that makes it difficult for implementors to use both CMMN and BPMN in the same tool set. A goal of CMMN was consistency with BPMN, and so, we are proposing changes to CMMN to solve the decorator inconsistencies.

  • Reported: CMMN 1.0b1 — Thu, 10 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify section 5.4.11 on PlanItemControl and modify decorators in section 6.12.2 and 6.12.4

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMMN FTF Issue: Wrong multiplicity of containment of case file item in case file

  • Key: CMMN-10
  • Legacy Issue Number: 18999
  • Status: closed  
  • Source: VDMbee ( Mr. Henk de Man)
  • Summary:

    Case file item is contained in both itself (0..1) and case file (1).
    The containment in case file cannot be mandatory therefore, and hence has to be 0..1 as well.

    This also requires change of figure 4.

  • Reported: CMMN 1.0b1 — Fri, 11 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify CaseFile metamodel in Figure 4, section 5.3

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Required/Optional and Discretionary Tasks notation is inconsistent with BPMN (CMMN-7)

  • Key: CMMN-9
  • Legacy Issue Number: 18998
  • Status: closed  
  • Source: International Business Machines ( Mr. Mike Marin)
  • Summary:

    Nature: Revision
    Severity: Significant
    Chapter/Section: 6.12.3 (Required Decorator) and 6.7 (Tasks), 6.6 (Plan Fragments)
    Page Number(s): 57 - 60; 68 - 69

    Description: The required/optional decorator introduces an inconsistency between CMMN and BPMN. In addition, discretionary tasks can be confused with event sub-processes. The concepts of optional and discretionary have some similitude, and so, they should have similar icons.

  • Reported: CMMN 1.0b1 — Thu, 10 Oct 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Reject issue
    Revised Text:

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Error in description of Active state for a Stage or Task

  • Key: CMMN-3
  • Legacy Issue Number: 18885
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    In Table 50, the description of the "Active" state contains two cases, separated by "and/or".
    It is obvious that "and" cannot happen, therefore "and/or" should be replaced by "or".

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agree with problematic statement, text in section 7.3.2 has been modified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reference from Section 5.4.10.5

  • Key: CMMN-6
  • Legacy Issue Number: 18888
  • Status: closed  
  • Source: University of Applied Sciences of Zwickau ( Ralf Laue)
  • Summary:

    The reference from Section 5.4.10.5 in the first sentence should be "see 5.4.10.5.1"

  • Reported: CMMN 1.0b1 — Thu, 5 Sep 2013 04:00 GMT
  • Disposition: Resolved — CMMN 1.0
  • Disposition Summary:

    Agreed on the issue, modify reference in section 5.4.10.5

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadConnection, CadSystem: Avaliable_models() enhancement

  • Key: CAD12-5
  • Legacy Issue Number: 7140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Disposition: ?
    OMG Issue No: ?
    Title: CadConnection, CadSystem: Avaliable_models() enhancement
    Source:
    Markus Helmke, Produktionstechnisches Zentrum (PTZ)
    Technische Universität Berlin
    Email: markus.helmke@ipk.fhg.de

    Summary:

    The method "available_models()" provides access to models available to the active CAD System and returns all available models in a list. Up to now the method does not take into account how the models are structured on the server side. When a user selects a model it would be helpful to navigate through the tree structure of the servers file system. A similar problem is the specification of a users file name in that moment when he wants to use "save_model_as()" or "create_model()".
    The proposed methods, data structures and definitions aim to improve navigation capabilities for both systems and users when accessing models. For various reasons a native CAD-system normally is able to access different directories which are presented also to the user. This is to let him structure his work but also in order to offer templates that ease the design process, because in most cases designer aren't starting from scratch, but they are provided with templates that cover predefined parameters or a special design philosophy.
    Assuming a user wants to store, create, or open a model on the (maybe remote) machine running the Cad-Services he expects something like a "FileChooser"-dialog. The method "available_models()" was not designed to support such functionality and therefore needs to be extended.
    The proposed methods allow for implementing the intended functionality because they represent an essential subset of methods needed to do the following:

    • Navigation (get_root_directories(), get_models_and_folders(), get_parent_directory())
    • Create new subfolder (create_new_folder())
    • Providing information to choose a file or folder on the client side (get_models_and_folders())
      The concept provides the possibility not to expose the whole file system to the user by using "root_directories". Every directory can serve as root directory and thus only its subdirectories are exposed to the user. The user starts navigation in the one of the roots.
      The methods were taken from JAVA's abstract class "javax.swing.filechooser.FileSystemView" which serves as "JFileChooser's gateway to the file system" and as such promise to be sufficient. Additionally IWF has implemented against the proposed CAD-Services enhancement with success.

    Resolution:
    ?

    Revised Text:
    The following typedefs, struct and operations are added to the CadConnection module respectively to the CadSystem interface:

    module CadConnection
    {

    struct Path

    { boolean is_dir; // Indicates whether Path represents a file or a directory string path; // Canonical, absolute, and unique path representing a file or // a directory }

    ;

    typedef sequence<string> RootsList;
    typedef sequence<Path> PathList;

    interface CadSystem

    { // Creates a new folder in a given directory. // param parent_dir: The (canonical, absolute, and unique) path of the // directory, in which the folder will be created. This must be either // one of the root directories (see get_root_directories()) or a // directory that exists in one of the root directory's subdirectories // param folder_name: The name of the folder to be created. It must be a // valid and a not already existing name. // raises CadUtility::CadError: If there was an error in creating the // folder. void create_new_folder(in string parent_dir, in string folder_name) raises (CadUtility::CadError); // Returns a list of (canonical, absolute, and unique) pathnames repre- // senting the root directories. In a root directory or in any other // subdirectory, model files can be found. // return: List of pathnames representing root directories. RootsList get_root_directories(); // Returns a list of subdirectories and model files of a given directory. // param directory: (canonical, absolute, and unique) path of the // directory from which to get the list of subdirectories and model // files. This must be either one of the root directories or a subdirectory. // return: A list representing subdirectories and/or model files // of the given directory. // raises CadUtility::CadError If there was an error retrieving the list. PathList get_models_and_folders(in string directory) raises (CadUtility::CadError); // Returns the parent directory of a given directory. // param directory: (canonical, absolute, and unique) path of the // directory from which to get its parent directory. The given directory // should be a subdirectory of one of the root directories. // return: The path of the parent directory. // raises CadUtility::CadError If there was an error retrieving the // parent directory. string get_parent_directory(in string directory) raises (CadUtility::CadError); }

    ;
    };

    Disposition: ?
    Disposition Parameter: ?

  • Reported: CAD 1.1 — Wed, 10 Mar 2004 05:00 GMT
  • Disposition: Resolved — CAD 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Suggest altering the input parameter CadFeature::ParameterSeq model_params

  • Key: CAD12-2
  • Legacy Issue Number: 5845
  • Status: closed  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    Suggest altering the input parameter CadFeature::ParameterSeq model_params on CadConnection::CadSystem to a CosPropertyService::Properties

  • Reported: CAD 1.1 — Wed, 22 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.2
  • Disposition Summary:

    This issue was previously (v 1.1) resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

altering the use of EntitySeqs to LongSeqs

  • Key: CAD12-1
  • Legacy Issue Number: 5844
  • Status: closed  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    I suggest altering the use of EntitySeqs to LongSeqs - essentially to use Unique IDs as identifiers. [In places like: Model::delete_entity(), EntityGroup::add_entities(), EntityGroup::remove_entities()] I see there 2 main problems: 1. I don't see that it is really neccesssary to use the (in this case Entity objects) CORBA objects to identify an object. unique_id's could always be used. -> Less traffic and a lot easier to map. Besides: how much sense does the UidUnsupported exception make? unique ids can always be created. 2. The required mapping especially on the server side is somewhat tricky and not the fastest. You would have to map the CORBA objects to the implementation objects. Nasty thing to do.

  • Reported: CAD 1.1 — Wed, 22 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadMain::ModelInstance::component()' collides

  • Key: CAD12-4
  • Legacy Issue Number: 6693
  • Status: closed  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    'CadMain::ModelInstance::component()' collides with the new 'component' keyword for IDL from CCM.

    I suggest ro rename it to 'CadMain::ModelInstance::component_model()'.

  • Reported: CAD 1.1 — Thu, 11 Dec 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadGeometry::Curve::tessellate()

  • Key: CAD12-3
  • Legacy Issue Number: 5846
  • Status: closed  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    is there any reason, why the double parameter (tolerance) of CadGeometry::Curve::tessellate() is declared as an in parameter and not inout? In other places like CadGeometry::Surface::nurbs_representation() the tolerance parameter is declared inout.

  • Reported: CAD 1.1 — Wed, 22 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Model Instances vs. Top-Level Entities

  • Key: CAD11-19
  • Legacy Issue Number: 5747
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    The distinction between model instances and top-level entities was unclear to me, especially so given my task of trying to write a general purpose tool to "import" arbitrary CAD models into CFD-GEOM via the CAD Services interface. A Model can contain zero or more ModelInstances, and this provides support for assemblies. At the same time, certain entities in a Model are designated as top-level entities, which also brings to mind the concept of a composition or assembly.

  • Reported: CAD 1.0 — Wed, 6 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    Additional text is needed in the documentation

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add some operations to CadFoundation module's interfaces

  • Key: CAD11-18
  • Legacy Issue Number: 5729
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    It's necessary to add some operations to CadFoundation module's interfaces:

    CadFoundation::Entity::SetColor(CadUtility::ColorStruct color) raises (CadUtility::CadError);
    CadFoundation::Layer::SetColor(CadUtility::ColorStruct color) raises (CadUtility::CadError);

  • Reported: CAD 1.0 — Tue, 29 Oct 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    The recommended changes are made as suggested in the summary

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Euclidean Dimension

  • Key: CAD11-21
  • Legacy Issue Number: 5749
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    The Entity::euclidean_dimension() operation is described as returning the "Euclidean dimension of the entity" (with type long). What is this referring to? My guess is that it returns 2 for two-dimensional entities or 3 for three-dimensional entities, but this is unclear

  • Reported: CAD 1.0 — Wed, 6 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    Additional documentation is needed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EntityFactory and ModelInstanceFactory

  • Key: CAD11-20
  • Legacy Issue Number: 5748
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    I was already familiar with the Factory design pattern and so the purpose of the EntityFactory and ModelInstanceFactory interfaces was immediately obvious to me. I'm not sure how familiar other users of the CAD Services will be with this pattern, depending on their software development background.

  • Reported: CAD 1.0 — Wed, 6 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    The documentation shall clarify the intent of these "Factory" interfaces

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interface Parameter

  • Key: CAD11-34
  • Legacy Issue Number: 5935
  • Status: closed  
  • Source: Technical University Berlin ( Markus Helmke)
  • Summary:

    The interface Parameter provides four functions · string get_expression() raises (CadUtility::CadError); · void set_expression(in string e_value) raises (CadUtility::CadError); // operations to allow an expression that may drive geometry

    · CadUtility::EntityAttrib get_value() raises (CadUtility::CadError); · void set_value (in CadUtility::EntityAttrib value) raises (CadUtility::CadError); // operations providing access to parameter value Actually “Parameter” is an easy interface. But since we have seen different implementation approaches and since it was not clear for us in every case too what should be handed over to the set-methods and what could be retrieved by the get-methods I write down our assumptions and hope that it will be corrected if that was not the approach you have had in mind: A parameter covers expressions like “a=6” or “a=b+c”, where “a” is the “name” of the expression. getValue() therefore will return the recursive computed value in the case of “b+c” or an error when there is a problem with the computation. In case of “6” getValue() will just return the value “6”. setValue() allows to set a value if the value of “is_read_only” has the value “false”. The type of the handed over value must match the type of CadUtility::EntityAttrib stored by parameter. In the case of “a=6” “is_independent” keeps the value true. In the case “a=b+c” “is_independent” turns to the value “false”. It is a question whether handing over a value like “8” should be allowed at all when the parameter carries an non numeric expression. getExpression() is similar to getValue() with the difference that the return type is a string. setExpression() allows to set expressions like “d+e” or “8”. The values of “is_independent” and “is_read_only” have to be set accordingly. Expression like “a=d+e” and “a=8” should be possible but internally the expression is parsed and “a=” is ignored. Expression like “b=d+k” should be forbidden because they provide a back door to define completely new parameter when name is set to “b”. If this also has been intended this should be made clear. But I guess this would require extra methods that allow to define parameter. Summing up it is actually no problem to omit the value-methods The “expression”-methods can take over the task to handle values because these also can be represented by expressions like “8”.

  • Reported: CAD 1.0 — Wed, 7 May 2003 04:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Cadsystem" interface issue

  • Key: CAD11-25
  • Legacy Issue Number: 5753
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The interface "Cadsystem" provides access on a "CadUserInterface" by the
    method

    boolean is_interactive(out CadUserInterface gui);

    Normally loading a model in the CAD engine and showing it with the editor
    are two different tasks.
    "create_model" and "open_model" obvioulsy are related to CAD-Engine
    activity. GUI activities like showing, hiding etc. are not mandatory
    implicated. If methods like "create_model" and "open_model" are intended not
    to include GUI operation then functionality to control the
    "CadUserInterface" is missing.
    Therefore the following function would be very helpful (They assume that a
    model is already loaded by the CAD engine):

    createWindow(model) // Creates a window and put it in the foreground
    hideWindow(model) // hides an existing window but doesn't
    delete it
    foregroundWindow(model) // put an existing (even if hided) window in the
    foreground
    deleteWindow(model) // delete the window and the corresponding window
    data structure but NOT the model within the CAD engine

    Every model should throw a "ModelNotLoadedException" if the model is not
    loaded.

    Summing up this should allow for a separated control of activities within
    the CAD-engine and the editor.

  • Reported: CAD 1.0 — Fri, 8 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"Entity-Types"

  • Key: CAD11-24
  • Legacy Issue Number: 5752
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In some methods (mainly Model-Interface) "Entity-Types" are demanded as an
    selection mechanism to select appropriate entities. Example:

    CadFoundation::EntitySeq top_level_entities (
    in CadUtility::TypeCodeSeq entity_types)

    But the CAD-Services provide no opportunity to implement a method that
    allows to ask for these entity types that are supported by the respective
    CAD-System. But in our mind it is up to the CAD-System and thus to the
    CAD-Services to provide such information

  • Reported: CAD 1.0 — Fri, 8 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above, issue rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Curve Parameters

  • Key: CAD11-23
  • Legacy Issue Number: 5751
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    The Edge::start_parameter() and Edge::end_parameter() operations return the "curve parameter corresponding to the start (end) vertex". I suppose this is referring to the parametric distance along the underlying curve, but it's unclear because of the sort-of generic use of the word "parameter".

  • Reported: CAD 1.0 — Wed, 6 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tessellation Types

  • Key: CAD11-22
  • Legacy Issue Number: 5750
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    For example, consider the requirements for calling Body::tessellate():
    ConnectedFaceTessellationStruct
    tessellate(in TessType t_type,
    inout TessParametersStruct params,
    out boolean flag);

    The first argument (the tessellation type) can be one of two enumerated values, WIREFRAME or VISUALIZATION. Nowhere in the specification is any hint given as to the difference between these two settings. One might guess that the VISUALIZATION tessellation type produces a larger number of triangles, but to what degree? Is it implementation-dependent?

  • Reported: CAD 1.0 — Wed, 6 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

remove CadGeometryExtens interface

  • Key: CAD11-27
  • Legacy Issue Number: 5775
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    I propose to remove CadGeometryExtens interface:
    module CadGeometryExtens{

    interface Point : CadFoundation :: Entity

    { CadUtility::PointStruct coords() raises (CadUtility::CadError); }

    ;

    struct PointOnSurfaceStruct

    { CadGeometry::Surface basis_surface; CadUtility::UvStruct the_point; }

    ;

    interface PointOnSurface : Point

    { PointOnSurfaceStruct pos_info() raises (CadUtility::CadError); }

    ;

    struct PointOnCurveStruct

    { CadGeometry::Curve basis; double crv_param; }

    ;

    interface PointOnCurve : Point

    { PointOnCurveStruct poc_info() raises (CadUtility::CadError); }

    ;

    It seems to be quite unuseful

  • Reported: CAD 1.0 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interface Model : CadFoundation:: Attributable replaced

  • Key: CAD11-26
  • Legacy Issue Number: 5774
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    interface Model : CadFoundation:: Attributable

    was replaced by

    interface Model : CadFoundation:: Entity

    This is an issue I've posted many times ago. This really simplify the
    life with implementation and classification of entities.

  • Reported: CAD 1.0 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    The inheritance for Model is changed as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

struct PolyLineStruct is defined but not used anywhere

  • Key: CAD11-33
  • Legacy Issue Number: 5849
  • Status: closed  
  • Source: CAxOPEN GmbH ( Bernd Swienczek)
  • Summary:

    struct PolyLineStruct is defined but not used anywhere. Either the according interface PolyLine is missing or the struct is obsolete

  • Reported: CAD 1.0 — Fri, 24 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    PolyLineStruct is obsolete and should be removed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadFoundation.idl: In the CadFoundation::EntityPropsStruct

  • Key: CAD11-32
  • Legacy Issue Number: 5848
  • Status: closed  
  • Source: CAxOPEN GmbH ( Andreas Korn)
  • Summary:

    CadFoundation.idl: In the CadFoundation::EntityPropsStruct the variable global_position is never mentioned in the pdf file. Besides: The corresponding method to global_position in CadFoundation::Entity is named global_location. Shouldn't that be either both position or both location?

  • Reported: CAD 1.0 — Fri, 24 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

bounding_box" behavior

  • Key: CAD11-31
  • Legacy Issue Number: 5842
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    An empty TypeCodeSeq in Model::bounding_box() and Model::top_level_entities() will be handled differently according to the comments in the IDL-files. In bounding_box it means all entities and in top_level_entities it should generate a BadParam exception. Would it not be better, to give it in both methods a similar meaning?

    Recommend "bounding_box" behavior.

  • Reported: CAD 1.0 — Fri, 17 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add operations to CadMain::Model

  • Key: CAD11-30
  • Legacy Issue Number: 5841
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    void add_child(in Model child_model) raises (CadUtility::CadError);
    void remove_child(in Model child_model) raises (CadUtility::CadError);
    It is suggested that Model be changed to ModelInstance to allow for assemblies

  • Reported: CAD 1.0 — Fri, 17 Jan 2003 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Operation to identify opened Models

  • Key: CAD11-29
  • Legacy Issue Number: 5777
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    The existing interfaces on the CadSystem interface do not indicate CadMain::Model references that may be opened and available for immediate use

  • Reported: CAD 1.0 — Tue, 26 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Set color on Layer interface

  • Key: CAD11-28
  • Legacy Issue Number: 5776
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    The Layer interface needs a set_color() operation

  • Reported: CAD 1.0 — Tue, 19 Nov 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.1
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What are units for 'angle' field in TessParametersStruct

  • Key: CAD-15
  • Legacy Issue Number: 4538
  • Status: closed  
  • Source: Westinghouse Electric ( Jim Jones)
  • Summary:

    adGeometry IDL comment documents the 'angle' field in CadGeometry.TessParametersStruct
    as "deviation between normals of facets".

    Neither the IDL nor the CAD Services spec. indicate what angular units should be used.

  • Reported: CAD 1.0b1 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    This oversight was corrected by indicating the required use of degrees for angle units.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TessellationStruct normals field should be VectorStructSeq

  • Key: CAD-14
  • Legacy Issue Number: 4537
  • Status: closed  
  • Source: Westinghouse Electric ( Jim Jones)
  • Summary:

    The type of the 'normals' field in TessellationStruct should be VectorStructSeq
    instead of PointStructSeq.

  • Reported: CAD 1.0b1 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed. IDL modified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should there be a get_parameter_set function at the Model interface level?

  • Key: CAD-13
  • Legacy Issue Number: 4528
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Should there be a get_parameter_set function at the Model interface level?

  • Reported: CAD 1.0b1 — Mon, 20 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadBrep Edge.nearest_points function needs clarification

  • Key: CAD-12
  • Legacy Issue Number: 4493
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CadBrep Edge.nearest_points function needs clarification for
    'nearest_points' argument.

    How are the nearest_points defined? It is declared as a PointStructSeq,
    but no further details are provided. Will there always be 2? Is the
    first point of the sequence a point on the given edge and the second
    point a point on the edge corresponding to the input argument? What is
    the expected behavior if there are multiple locations that the 2 edges
    have an identical minimum distance?

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadBrep Edge.nearest_points function incorrect

  • Key: CAD-11
  • Legacy Issue Number: 4492
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CadBrep Edge.nearest_points function incorrectly defines the
    'nearest_points' argument as 'in'.

    CAD Services spec documents Edge.nearest as 'Determines the minimum
    distance, and corresponding closest points, between this Edge and the input
    Edge. The returned value is the minimum distance'. The 'nearest_points'
    argument should be declared as 'out'.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Resolved through removing the nearest_points operation. See issue 4493.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAD Services IDL issue (02)

  • Key: CAD-10
  • Legacy Issue Number: 4491
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CadBrep Edge IDL defines a 'start_vertex()' function, but not
    an 'end_vertex()' function.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed. An operation was added to the Edge interface.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAD Services IDL issue

  • Key: CAD-9
  • Legacy Issue Number: 4490
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CadBrep Oriented Edge IDL defines an 'end_vertex()' function,
    but not a 'start_vertex()' function.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed. An operation was added to the OrientedEdge interface

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Binding for Face.nurbs_representation needs major design overhaul/removal

  • Key: CAD-8
  • Legacy Issue Number: 4489
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Binding for Face.nurbs_representation needs major design overhaul or
    removal.

    IDL indicates the function returns a CadUtility.NurbsSurfaceStruct. A
    simple NURBS surface structure cannot represent arbitrary faces w/
    irregular boundaries, both outer and inner.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAD Services needs to clarify 'exact' for nurbs_representation functions

  • Key: CAD-7
  • Legacy Issue Number: 4488
  • Status: closed  
  • Source: Anonymous
  • Summary:

    CAD Services specification needs to clarify 'exact' for
    nurbs_representation functions.

    nurbs_representation indicates that if the NURBS is exact, then tolerance
    is returned as negative value. Is that exact geometrically or exact
    geometrically AND parametrically?

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Edge.nurbs_representation should h. 'tolerance' argument declared as inout

  • Key: CAD-6
  • Legacy Issue Number: 4487
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Edge.nurbs_representation should h. 'tolerance' argument declared as
    'inout' instead of 'in'.

    CAD Services specification indicates that 'If the representation is exact -
    tolerance will be returned as a negative value.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed. This corrections involved a minor modification of the IDL.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Surface.nurbs_approximation should 'tolerance' argument declared as inout

  • Key: CAD-5
  • Legacy Issue Number: 4486
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Surface.nurbs_approximation should have 'tolerance' argument declared as
    'inout' instead of 'in'.

    CAD Services specification indicates that 'If nurbs representation is
    exact, tolerance will be returned as a negative'. By the way, the 'NURBS'
    acronym should be capitalized in the spec and IDL when used in this
    context.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Surface.nurbs_approximation should be renamed nurbs_representation

  • Key: CAD-4
  • Legacy Issue Number: 4485
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Surface.nurbs_approximation should be renamed nurbs_representation to be
    consistent w/ Curve.nurbs_representation.

  • Reported: CAD 1.0b1 — Mon, 6 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agree. Representation is a better description

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need to add a "ColorStruct color;" to the PresentationStruct

  • Key: CAD-3
  • Legacy Issue Number: 4433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I was building a Java3d display for CadServices data and I realized that
    > we do not return the object color in the PresentationStruct. We return
    > the color of the highlight (specular_color), and various parameter about
    > reflectance - but we do not include the base color of the object.
    >
    > I think we need to add a "ColorStruct color;" to the PresentationStruct.

  • Reported: CAD 1.0b1 — Fri, 27 Jul 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL extracts in document are inconsistent about showing module declarations

  • Key: CAD-2
  • Legacy Issue Number: 4415
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:
    • IDL extracts in the document are inconsistent about showing module
      declarations.
  • Reported: CAD 1.0b1 — Sat, 14 Jul 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Module declarations added to the document

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CAD FTF issue regarding UML which looks kind of like CORBA profile

  • Key: CAD-1
  • Legacy Issue Number: 4414
  • Status: closed  
  • Source: Distributed Models Pty Ltd ( Keith Duddy)
  • Summary:

    UML looks like Corba profile, but is not quite. In particular the
    <<Interface>> stereotype should be <<CORBAInterface>>. There may also
    be some "in" tags in the wrong place.

  • Reported: CAD 1.0b1 — Sat, 14 Jul 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    CORBA UML diagrams throughout the document were updated to an appropriate format

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incompletely specified operations - issue

  • Key: CAD-43
  • Legacy Issue Number: 4985
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Mikhail Kazakov mentioned that some of the Cad Services interfaces may be under-specified. Here is a list of operations needing additional documentation:
    1. CadMain:: open_model( …) - the question involves whether this operation loads the specified model into memory or are all the available models in memory and the open_model() operation merely returns an object reference to the model.

    Recommendation: the documentation should include the following: The open_model() operation loads the specified model into memory and can be unloaded by invoking close_model() on the Model object reference.

    2. CadMain:: top_level_entities (in CadUtility::TypeCodeSeq entity_types) - what happens when an empty TypeCodeSeq is passed? One could respond with all top level entities or none.
    Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

    3. unsigned long unique_entities_count (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); - what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none.
    Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

    4. CadFoundation::EntitySeq unique_entities (in CadUtility::TypeCodeSeq entity_types) raises (NotValidCadType, CadUtility::CadError); – what happens when an empty TypeCodeSeq is passed? One could respond with all entites or none.
    Recommendation: Documentation shall state that an empty TypeCodesSeq will result in a system exception (BAD_PARAM).

  • Reported: CAD 1.0b1 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    The identified recommendations were agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Several properties in the CadBrep::PropertyStruct need clarification.

  • Key: CAD-42
  • Legacy Issue Number: 4653
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    double inertial_moment_spherical;
    double gyration_radius_spherical;
    CadUtility::VectorStruct first_moments_centroidal;
    CadUtility::VectorStruct inertial_moments_centroidal;
    CadUtility::VectorStruct inertial_products_centroidal;
    CadUtility::VectorStruct principle_moments_centroidal;
    CadUtility::VectorStruct gyration_radii_centroidal;

    are unclear.

    Jim Stevens identified the following:

    The "centroidal" moments are the various mass properties with respect to the center of mass for the body. This is the more "typical" case for mass properties. They correspond to similar mass property calculations in the structure that are with respect to a specific coordinate system.
    Principle moments are moments inertia along the principle axes through the center of gravity of an object.
    When defining a moment of inertia around an arbitrary axis thru the center of mass you end up with product terms. There is
    one axis definition for which the product terms are zero, which is called the principle axis and the moments of inertia when
    using that axis definition are the principle moments.
    Radius of gyration is related to the moments of inertia and the mass along each axis.
    I am not sure about the meaning of first moments. I am pretty sure that inertial_moment_spherical and
    gyration_radius_spherical have to do with representing the model with a single sphere that would have
    the same overall inertial characteristics as the analyzed body.
    Jim Stephens

    Based on Jim's comments I am not certain that we need the first moments or the spherical inertial moment and gyration radius.

  • Reported: CAD 1.0b1 — Wed, 31 Oct 2001 05:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

problems in the EntityCreation interface.

  • Key: CAD-41
  • Legacy Issue Number: 4632
  • Status: closed  
  • Source: TranscenData ( Jim Jones)
  • Summary:

    Here is a quick itemization of necessary changes (most from Sergey and
    a few additional). Following the list is a modified section of the IDL
    that can be used to replace the corresponding lines in the existing
    CadMain.idl file. *** NOTE: Also need to add 'typedef sequence<LongSeq> LongSeqSeq;'
    to CadUtility.idl.

    index_faces:
    Needs 'SeqSeq' of oriented_eloops instead of 'Seq'
    For consistency, arg should probably be 'oriented_edge_loops' instead of 'oriented_eloops'
    Does not need eloops, edges.
    index_edge_loops:
    Needs 'SeqSeq' oriented_edges instead of 'Seq'
    index_shells:
    Needs 'SeqSeq' oriented_faces instead of 'Seq'
    index_bodies:
    Needs 'SeqSeq' oriented_shells instead of 'Seq'
    index_vertex_loops:
    Ok (just included in IDL below for easier replacement of old IDL section)
    index_oriented_edges
    Need 'BooleanSeq senses'
    index_oriented_faces
    Need 'BooleanSeq senses'
    No vertices or vLoops needed
    index_oriented_edge_loops
    For consistency, should probably be 'index_oriented_edge_loops' not 'index_oriented_edgeloops'
    Need 'Seq edge_loops' not 'Seq edges'
    Need 'BooleanSeq senses'
    index_oriented_shells:
    Need 'Seq shells' not 'Seq ofaces'
    Need 'BooleanSeq senses'
    No vloops needed

    CadUtility::LongSeq index_faces(in CadUtility::LongSeqSeq oriented_edge_loops,
    in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeqSeq oriented_edges)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_shells (in CadUtility::LongSeqSeq oriented_faces)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_bodies (in CadUtility::LongSeqSeq oriented_shells)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_vertex_loops (in CadUtility::LongSeq vertices)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_oriented_edges(in CadUtility::LongSeq edges,
    in CadUtility::BooleanSeq senses)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
    in CadUtility::BooleanSeq senses)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_oriented_edge_loops(in CadUtility::LongSeq edge_loops,
    in CadUtility::BooleanSeq senses)
    raises (IncorrectIndex, CadUtility::CadError);
    CadUtility::LongSeq index_oriented_shells(in CadUtility::LongSeq shells,
    in CadUtility::BooleanSeq senses)
    raises (IncorrectIndex, CadUtility::CadError);

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity Factory issue (Function 5)

  • Key: CAD-40
  • Legacy Issue Number: 4631
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    5. Function
    CadUtility::LongSeq index_oriented_faces(in CadUtility::LongSeq faces,
    in CadUtility::LongSeq vertices,
    in CadUtility::LongSeq vloops)

    Maybe instead of this, the description should be something like this:

    index_oriented_faces(in CadUtility::LongSeq faces,
    in CadUtility::BooleanSeq senses)?

    For what reason should you put the vertices and vloops in parameters?

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Please see resolution in issue 4632.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity Factory issue (Function 4)

  • Key: CAD-39
  • Legacy Issue Number: 4630
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    4. Function
    CadUtility::LongSeq index_oriented_xxxxxxxx

    For functions which create oriented entities, boolean flags "sense" should be present in parameters, i.e. like BooleanSeq senses.

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Please see resolution in issue 4632.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity Factory issue (Function 3)

  • Key: CAD-38
  • Legacy Issue Number: 4629
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    3. Function
    CadUtility::LongSeq index_shells (in CadUtility::LongSeq oriented_faces)
    raises (IncorrectIndex, CadUtility::CadError);

    The same situation. "In" parameter orieneted_faces should be CadUtility::LongSeqSeq, because shell is a set of faces.

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Please see resolution in issue 4632.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity Factory issue (Function 2)

  • Key: CAD-37
  • Legacy Issue Number: 4628
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    2. Function
    CadUtility::LongSeq index_edge_loops(in CadUtility::LongSeq oriented_edges)

    Edge loop is described by list of edges, because of this, the "in" parameter oriented_edges should be CadUtility::LongSeqSeq.

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Please see resolution in issue 4632.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity Factory issue (Function)

  • Key: CAD-36
  • Legacy Issue Number: 4627
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Function
    CadUtility::LongSeq index_faces(in CadUtility::LongSeq oriented_eloops,
    in CadUtility::LongSeq eloops, in CadUtility::LongSeq edges,
    in CadUtility::LongSeq vertex_loops, in CadUtility::LongSeq surfaces)

    Could you describe, please, the reason of presence of "eloops" and "edges" in the parameters?

  • Reported: CAD 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Please see resolution in issue 4632

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interface for STEP open shel

  • Key: CAD-35
  • Legacy Issue Number: 4595
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Suggest interface for STEP open shell, ie a collection of faces that do not enclose a volume.

  • Reported: CAD 1.0b1 — Fri, 5 Oct 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    This functionality is available in the current CadGeometry::Shell interface.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deletion of CadFourndation::Entity descendants

  • Key: CAD-34
  • Legacy Issue Number: 4573
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    Possible resolution:

    Add methods:

    interface CadSystem

    { void delete_model(in string modelname) raises (InvalidModel, PermissionDenied, CadUtility::CadError); // Removes model from CadSystem void delete_model(in CadMain::Model model) raises (InvalidModel, PermissionDenied, CadUtility::CadError); // Removes model from CadSystem }

    interface Model

    { exception EntityOutOfModel; void delete_entity(in long uid) raises (EntityOutOfModel, NotIndependent, UidUnsupported, PermissionDenied, CadUtility::CadError); // Removes ModelInstance, BrepEntity, Curve or Surface from the model void delete_entity(in CadFoundation::Entity entity) raises (EntityOutOfModel, NotIndependent, PermissionDenied, CadUtility::CadError); // Removes ModelInstance, BrepEntity, Curve or Surface from the model }
  • Reported: CAD 1.0b1 — Thu, 20 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    This is essentially the same issue as involved with 4571.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Entity.Position() returns PointStructure instead of TransformationStructure

  • Key: CAD-33
  • Legacy Issue Number: 4572
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    Replace
    CadUtility::PointStruct position () raises (CadUtility::CadError);
    // Returns a struct of the coordinates of a single, reference location on
    // the entity that should be unique relative to neighboring entities.
    method by
    CadUtility::TransformationStruct location () raises (CadUtility::CadError);
    // Returns a struct of the applied transformation, which represents
    // the location (position, turn, scale) of the entity according the global coordinates

    In that case, we will be able to refer the entity according any other entities.
    This method doesn't return the "last applied transformation", but "the superposition
    of all applied transformations". In that case, location of the entity in 3D space will be returned.

  • Reported: CAD 1.0b1 — Thu, 20 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There is no way to delete any CadFoundation::Entity interface child.

  • Key: CAD-32
  • Legacy Issue Number: 4571
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    There is no way to delete any CadFoundation::Entity interface child.
    We shall add the possibility to delete:

    Model
    ModelInstance
    BrepEntity
    Curve
    Surface

  • Reported: CAD 1.0b1 — Thu, 20 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadFoundation::Entity interface

  • Key: CAD-31
  • Legacy Issue Number: 4570
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    There is no "3D Location" function in Entity interface.
    There is only Entity.Position(), which returns PointStructure,
    but it is not enough to describe a 3D transformation.
    It's necessary to return TransofmrationStruct from such a function.
    It's necessary also to mention, that Entity interface has a method for
    transformation.

    However, if Position() has another goal, than 3D location of Entity, it
    shall be described in the document.

  • Reported: CAD 1.0b1 — Thu, 20 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Surface.intersect_ray argument error

  • Key: CAD-30
  • Legacy Issue Number: 4566
  • Status: closed  
  • Source: Westinghouse Electric ( Jim Jones)
  • Summary:

    The 'intersection_parameters' argument in Surface.intersect_ray() must be type 'CadUtility::UvStructSeq' instead of 'CadUtility::DoubleSeq'.

  • Reported: CAD 1.0b1 — Thu, 13 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CadSystem Properties issue

  • Key: CAD-29
  • Legacy Issue Number: 4564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the CadServer interface we have the ability to inquire launch
    properties for the CadSystem, and then pass in a set of properties
    when we call connect() or connect_with_password().

    Once the CadSystem is running we do not have a way to query or
    change the properties.

    As an example - UG has a property for the search path for files.
    You can set this property when you initially start up the CadSystem.
    If it needs to be changed during a session the only choice is to
    shut down the CadSystem with disconnect() then call connect()
    again.

    Also, if you connect to an already running CadSystem you
    cannot determine what properties were used during the original
    connect().

    I think I would propose adding something like "get_properties"
    and "set_properties" for the CadSystem interface. These calls
    would basically allow a query and update of the properties
    provided to the CadServer via the connect() calls.

    CosPropertyService::Properties get_properties();
    void set_properties( in CosPropertyService::Properties props );

  • Reported: CAD 1.0b1 — Thu, 6 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    The proposed operations were added to the CadSystem interface.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

I haven't found any way to create ModelInstance

  • Key: CAD-28
  • Legacy Issue Number: 4563
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    7. Creation of ModelInstances. I haven't found any way to create ModelInstance. And it's not explained in the specification.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace #include "CadFeature.idl with #include "CadFoundation.idl"

  • Key: CAD-27
  • Legacy Issue Number: 4562
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    6. #include list of CadGeometry module contain:
    #include "CadFeature.idl"
    that has to be replaced by #include "CadFoundation.idl".
    CAD Geometry never use features explicitly.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    This is a good observation. The #include was modified.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Method names in topological entities are not everywhere unified

  • Key: CAD-26
  • Legacy Issue Number: 4561
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    5. Method names in topological entities are not everywhere unified. To return a single entity we use normally prefix get_entity.
    To return a sequence we use no prefix normally: for example

    Shell get_shell () raises (CadUtility::CadError);
    OrientedFaceSeq oriented_faces () raises (CadUtility::CadError);

    Not all method names in CadBrep module satisfy this rule.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    All operations that did not follow the standard naming procedure were changed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

how to add new topological entities to existing model with sharing of exist

  • Key: CAD-25
  • Legacy Issue Number: 4560
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    3. It is not clearly described in the specification document, how to add new topological entities to existing model with sharing of existing entities.
    Let's say we have 2 vertexes already created and we would like to add an edge.
    While implementing EntityFactory interface, a developer have to care about this sharing. Otherwise vertexes won't be shared.
    And from my point of view we have to speak about that in the document.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

method of CadMain::EdgeLoop has to be renamed

  • Key: CAD-24
  • Legacy Issue Number: 4559
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    OrientedEdgeLoopSeq edge_loop() raises (CadUtility::CadError); method of CadMain::EdgeLoop has to be renamed to
    OrientedEdgeLoopSeq oriented_edge_loop() raises (CadUtility::CadError);
    for unification.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    The operation is renamed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

we have to generalize is_manifold() methods in all BRep entities

  • Key: CAD-23
  • Legacy Issue Number: 4558
  • Status: closed  
  • Source: Open Cascade ( Mikhail Kazakov)
  • Summary:

    1. Perhaps we have to generalize is_manifold() methods in all BRep entities. I propose to have is_manifold() only in BrepEntity interface, but not in each interface. The only restriction is vertex, which can return anytime TRUE.

  • Reported: CAD 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

adding an attribute to the entity group

  • Key: CAD-22
  • Legacy Issue Number: 4551
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Our entity groups in Cad Services don't have any form of an
    identifier or name that can be retrieved through the interface.
    The only returned data is either a list of entities in the group or
    the count. It makes it difficult to present this information to a
    user.

    We might consider adding an attribute to the entity group,
    however that means it gets inherited to the layer.

    readonly attribute string native_label;

  • Reported: CAD 1.0b1 — Thu, 30 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    A readonly attribute was added to the EntityGroup interface.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.4, Editorial

  • Key: CAD-21
  • Legacy Issue Number: 4548
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    Section 3.4, Editorial: Although the description of interaction with
    PDM Enablers is fairly clear, a sequence diagram (or several, for
    the several cases) would increase the likelihood of
    interoperability.

  • Reported: CAD 1.0b1 — Mon, 20 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Appropriate sequence diagrams were added to the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sections 1.8, 2.8, 3.1, 3.2, Editorial

  • Key: CAD-20
  • Legacy Issue Number: 4547
  • Status: closed  
  • Source: NIST ( Mr. David Flater)
  • Summary:

    Sections 1.8, 2.8, 3.1, 3.2, Editorial: Compliance points / levels
    and optional interfaces are spread around the document in a way that
    would hamper formal claims of conformance.

  • Reported: CAD 1.0b1 — Mon, 20 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Support for STEP input / output?

  • Key: CAD-19
  • Legacy Issue Number: 4544
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Support for STEP input / output?

  • Reported: CAD 1.0b1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Body.property_info, several values are calculated. What is the return accur

  • Key: CAD-18
  • Legacy Issue Number: 4543
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Body.property_info, several values are calculated. What is the return accuracy? Should a separate accuracy for each separate property be returned? Should accuracy be returned at all?

  • Reported: CAD 1.0b1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

BodyTessellationStruct issue

  • Key: CAD-17
  • Legacy Issue Number: 4542
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Should Shell.tessellation return a similar structure to Body.tessellation? Currently shell tessellation returns a FaceTessellationStructSeq while body tessellation returns a BodyTessellationStruct. Shell tessellation results are the only tessellation results that do not have an object reference to underlying topology. Rename BodyTessellationStruct to something like ConnectedFaceTessellationStruct?

  • Reported: CAD 1.0b1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Model level parameters for geometry creation issue

  • Key: CAD-16
  • Legacy Issue Number: 4541
  • Status: closed  
  • Source: NASA ( Russ Claus)
  • Summary:

    Model level parameters for geometry creation. Should the model creation operation support new parameters?

  • Reported: CAD 1.0b1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CAD 1.0
  • Disposition Summary:

    Agreed. A Model creation operation was modified in the CadSystem interface.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::Bounds and CORBA::TypeCode::Bounds

  • Key: CPP11-228
  • Legacy Issue Number: 902
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping uses a Bounds exception in the PIDL for NVList (page 17-6). This is the first time that the Bounds exception is mentioned (as far as I can see). There is no exception declaration for Bounds in the PIDL. This raises the questions:
    1) Does Bounds have data members or not?
    2) At what scope should Bounds be defined?
    Given that the Bounds exception is also used by the
    Request interface, I suspect what is meant is CORBA::Bounds.
    The TypeCode interface also uses a Bounds exception. It is explicitly
    declared in the scope of the TypeCode interface (page 17-15):
    It would be nice to only have one of these, probably CORBA::Bounds, and
    to add the missing declaration.

  • Reported: CPP 1.0b1 — Tue, 13 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Read-only restrictions on parameters

  • Key: CPP11-227
  • Legacy Issue Number: 863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A variable-length in parameter is read-only in the
    server, and a variable-length out parameter or return value is read-only
    in the client. I believe the restriction is too harsh to be useful, and the optimization
    permitted by the restriction is not worth it.

  • Reported: CPP 1.0b1 — Mon, 5 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarifying text added, fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping: missing from_wchar and to_wchar

  • Key: CPP11-226
  • Legacy Issue Number: 803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping states that "wchar" is not required map onto a
    unique C++ type. Yet in 18.17.4, the mapping fails to define the
    from_wchar and to_wchar struct types and associated <<= and >>=
    operators for inserting and extract wide chars into anys. This
    also needs to be fixed in appendix A.6 of section 18.

  • Reported: CPP 1.0b1 — Tue, 2 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for IN object references

  • Key: CPP11-225
  • Legacy Issue Number: 781
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to C++ mapping spec in the POA document (table 2, section 16.18.1) the signature for an object reference in argument should be "objref_ptr", not the more likely "const objref_ptr". this is an conflict with the convention for all other in args except numeric, and is in contrast with the table 3, that specifies "const objref_var&".

  • Reported: CPP 1.0b1 — Wed, 19 Nov 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 188 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL generated C++ types and stream operators

  • Key: CPP11-224
  • Legacy Issue Number: 731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Most ORBs provide overloaded operators to inject String_var values into ostream, istream, on ifstream. Problem: C++ does not make these operators mandatory, so every time I use one of them, I am writing non-portable and proprietary code. Nail those operators down and make them mandatory in the spec

  • Reported: CPP 1.0b1 — Wed, 24 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed, requirements added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wide string allocation (2)

  • Key: CPP11-223
  • Legacy Issue Number: 723
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no statement about the terminating zero value. Is room allocated for it or not?For symmetrie with string_alloc() I suggest that wstring_alloc() also should allocate more room.

  • Reported: CPP 1.0b1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed with issue 722

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Why does get_principal() take an Environment parameter

  • Key: CPP11-218
  • Legacy Issue Number: 617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When this IDL is mapped into C++ for a non-EH target compiler, won"t this method end up having 2 environment parameters?. This is only IDL in current spec that takes environment parameter

  • Reported: CPP 1.0b1 — Mon, 14 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 191 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

POA_*_tie classes in 18.1.4 can"t be supported

  • Key: CPP11-217
  • Legacy Issue Number: 615
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If C++ compiler doesn"t support namespaces or templates defined inside classes, POA_*_tie classes in 18.1.4 cannot be supported within specified scopes.

  • Reported: CPP 1.0b1 — Fri, 11 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Boolean type left undefined by C++ mapping

  • Key: CPP11-214
  • Legacy Issue Number: 594
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA::Boolean can be mapped to totally non-sensical things such as structs, class, type double, type long etc. There are no guarantees about size of underlying type given to implementor

  • Reported: CPP 1.0b1 — Wed, 18 Jun 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defect with anonymus types in union mapping

  • Key: CPP11-213
  • Legacy Issue Number: 482
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are some serious inconsistencies in the union mapping. Spec. (page 16-18, para4 and page 16-19, para 1) The 2 paragraphs appear to be in conflict with each other.

  • Reported: CPP 1.0b1 — Sat, 25 Jan 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed as suggested by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 18.1.2: _this() and IMPLICIT_ACTIVATION need clarification

  • Key: CPP11-220
  • Legacy Issue Number: 637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section states that _this() can implicitly activate servant if IMPLICIT_ACTIVATION applies. _this() does not have a way to specify which POA is to be used for the activation

  • Reported: CPP 1.0b1 — Wed, 30 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PortableServer:ObjectId_tow_wstring() and string_to_ObjectId()

  • Key: CPP11-219
  • Legacy Issue Number: 627
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: PortableServer::ObjectId_to_wstring() and string_to_ObjectId() are written (*in section 18.4) using the "wchar_t" type. Shouldn"t they use the CORBA::wchar type instead?

  • Reported: CPP 1.0b1 — Wed, 16 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 8.2: set_exception() supported by BOA?

  • Key: CPP11-216
  • Legacy Issue Number: 605
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The BOA interface defined a method called set_exception(). This is not present in the IDL in section 17.17. Does the BOA support this method or not?

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 17..13.1 release()method should be added to mappping

  • Key: CPP11-215
  • Legacy Issue Number: 601
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Object IDL contains a release() mmethod that is not mapped in the C++ mapping. This method should be added in the mapping

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wide string allocation (1)

  • Key: CPP11-222
  • Legacy Issue Number: 722
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no wstring_dup(). For symmetrie with string_dup(), I would suggest to create wstring_dup() as well

  • Reported: CPP 1.0b1 — Wed, 17 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed issue, fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bounded strings

  • Key: CPP11-221
  • Legacy Issue Number: 721
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping basically ignores bounded strings and maps them to char* What should happen if I assign a string that is too long to a bounded string? No statement is made

  • Reported: CPP 1.0b1 — Thu, 18 Sep 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interpretation of _narrow semantics

  • Key: CPP11-212
  • Legacy Issue Number: 456
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"?

  • Reported: CPP 1.0b1 — Sat, 16 Nov 1996 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Distinction between _var and _ptr types

  • Key: CPP11-183
  • Legacy Issue Number: 189
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A_var may be identical to A_ptr, so a conforming program cannot overload operations using these types solely. This may clash with statement of different behaviour between the two.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Return value of maximum() for unbounded sequences

  • Key: CPP11-182
  • Legacy Issue Number: 185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Return value of maximum() for unbounded sequences must be specified.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence buffer types

  • Key: CPP11-195
  • Legacy Issue Number: 214
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 p. 39, Sec. 3.13 para 15 Why are you passing string buffers as char ** and object references as T_ptr*. There already is a type used for overloading assignment.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Addressed by resolution to issue 75

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence lacks common features

  • Key: CPP11-194
  • Legacy Issue Number: 213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 p.38,sec 3.13 para 13 There is no auto extend, no inset,append, delete. It doesn"t seem like a sequence. Seems more like a resizable array. Could call it so.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Beyond scope of RTF - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_principal () needs an environment parameter

  • Key: CPP11-185
  • Legacy Issue Number: 191
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: get principal() needs an Environment parameter, but object implementations using C++ EH do not have them. Spec should clarify this.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Names of anonymous types

  • Key: CPP11-184
  • Legacy Issue Number: 190
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec does not define how anonymous types defined within constructed types should be named (as the C mapping does)

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 52

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Bounded sequence problem (Section 16.11 p. 16-23)

  • Key: CPP11-181
  • Legacy Issue Number: 178
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: "Default constructor for a bounded sequence always allocates a contents vector.."-> Bad effect for sequences such as CORBA::ReferenceDatawhich allocates 1024 octets of storage

  • Reported: CPP 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problem with Any::to_object memory management

  • Key: CPP11-180
  • Legacy Issue Number: 154
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.14.5-implies that a CORBA::Object reference extracted from Any must share memory with actual interface stored in Any.Better: results of Any::to_object require explicit release()

  • Reported: CPP 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping complexity

  • Key: CPP11-189
  • Legacy Issue Number: 207
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p. 32, Sec. 3.11 A comment nothing can be done about at thisstage. This section is way too complex. Goal is not to be natural C++ programmers !!!!

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Beyond scope of RTF - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

string and objrev members of constructed types

  • Key: CPP11-188
  • Legacy Issue Number: 204
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Type of string & object reference members of struct, union, sequence

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

State of release flag for sequence

  • Key: CPP11-191
  • Legacy Issue Number: 210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-22 CORBA2.0 If release is FALSE under these circumstances, old storage will not be freed before reallocation is performed. After realloc release TRUE or FALSE?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Addressed by resolution to issue 75

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence implementation

  • Key: CPP11-190
  • Legacy Issue Number: 209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: {sec 16.11 Pg 16-22 CORBA2.0 p.38, Sec 3.13 para 7: Must an implementation REALLY implement a sequence as a contigous chunk of memory?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Addressed by resolution to issue 75

  • Updated: Fri, 6 Mar 2015 20:58 GMT

References returned from sequence operator[] after realloc

  • Key: CPP11-193
  • Legacy Issue Number: 212
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 What happens to refs returned by operator[] when a realloc occurs? Are these invalid?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence maximum() call

  • Key: CPP11-192
  • Legacy Issue Number: 211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-22 CORBA2.0 p.38 Section 3.13 para11: It"s not clear how maximum()call is supposed to be used.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 185 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

fixed- vs. variable-length types

  • Key: CPP11-187
  • Legacy Issue Number: 200
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.8 Pg 16-22 CORBA2.0, p. 28, Section 3.10, para 2: Devastating to programmers. Simple change to IDL an IDL file will require a complete rewrite of application code

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue123

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation dependency for _var and _ptr

  • Key: CPP11-186
  • Legacy Issue Number: 194
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation scheme for Interface _var & _ptr types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue189

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any string extractor

  • Key: CPP11-179
  • Legacy Issue Number: 150
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does the Any string extractor (>>=) return a pointer that is still managed by the Any or a copy? The spec appears to be silent about this.

  • Reported: CPP 1.0b1 — Wed, 2 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarifying text added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adding T_copy function

  • Key: CPP11-178
  • Legacy Issue Number: 148
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be useful if the C++ mapping for IDL arrays also generated a T_copy() function to go along with T_alloc(), T_dup(), and T_free().

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed as suggested by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unknown parts of an IOR and interoperability

  • Key: CPP11-136
  • Legacy Issue Number: 2457
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is currently a heated discussion in comp.object.corba about
    interoperability (Subject: Naming Service Interoperability).

    In a nutshell, the argument is about whether, if I send an object reference
    created by ORB A as a parameter to ORB B, whether or not ORB B is

    a) obliged to accept that reference as a valid parameter

    b) obliged to return me the same reference I sent (in the sense
    that the reference is functionally equivalent) when it returns
    that reference as a parameter to me

    c) obliged to preserve the contents of the reference if it goes
    though a cycle of object_to_string/string_to_object in ORB B.

    Now, my argument in this thread is that if an ORB doesn"t behave in line
    with the above three points, interoperability is completely lost because
    I could never be guaranteed that I can, for example, expect to be able
    to store an IOR in a Naming Service and have that work.

  • Reported: CORBA 2.2 — Fri, 19 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    issue split into issues 3234 and 3235

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Potential interop. problem in CORBA 2.3: pseudo-operation marshalling

  • Key: CPP11-135
  • Legacy Issue Number: 2338
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Existing CORBA 2.2 compatible CORBA clients will fail when invoking
    the non_existent pseudo-operation with a compliant CORBA 2.3 server.
    We have observed this problem in practice with at least one other
    commercial Java ORB, who changed from the Corba 2.2 marshalling to the
    Corba 2.3 marshalling when they changed the version of their product,
    thereby breaking our existing customer"s code.

    Section 15.4.1.2 (p. 15-31) of ptc/98-12-04 CORBA 2.3a defines the CDR
    marshalling for pseudo-operation non_existent in Object
    pseudo-interface to be _non_existent. The spec is worded in such a way
    that it implies that this marshalling applies for all GIOP clients,
    not just GIOP 1.2 client

    However, p. 13-23 of the CORBA 2.2 specification defines the mapping
    of the same pseudo-operation as _not_existent.

  • Reported: CORBA 2.2 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification of OBV GIOP encoding rules

  • Key: CPP11-134
  • Legacy Issue Number: 2326
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last sentence of section 15.3.7 "The abstract encoding of value type
    always includes RepositoryId information." needs to appear somewhere in
    section 15.3.4.1.

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping for wide strings

  • Key: CPP11-141
  • Legacy Issue Number: 1384
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the spec doesn"t say what the type CORBA::WChar should map to. Presumably,
    it should be wchar_t? If so, I think this should be stated.

    It is important to nail this down because of overloading ambiguities. For
    example, if CORBA::WChar * is allowed to be the same as char *, then
    we cannot use the overloaded <<= operator to insert unbounded wide strings
    into an Any.

  • Reported: CPP 1.0b1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fix the mapping to specify what WChar maps to.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Old References in C++ mapping

  • Key: CPP11-140
  • Legacy Issue Number: 1095
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-01-11 contains some stale references. For example, on page 20-18:

    ...
    private:
    // hidden assignment operators for var types to
    // fulfill the fules specified in
    // Section 19.3.2
    };

    The definition for the A_out type is the same as the one shown
    in Section 19.3.6.

    These should now refer to Section 20.

  • Reported: CPP 1.0b1 — Mon, 23 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close without change. Already fixed.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of >>= operator in C++ mapping

  • Key: CPP11-139
  • Legacy Issue Number: 932
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: According to the IIOP protocol specification, it is possible to receive
    an any with a TypeCode which doesn"t include names, member names and
    repository ids.
    However, it is not clear what the behaviour of the >>= operator is in the C++
    mapping for these cases. What happens if I receive an any value from
    a remote ORB which didn"t encode names, member names and repository ids ? Is
    it posible to extract its value using the so-called "type-safe" operator >>= ?

  • Reported: CPP 1.0b1 — Wed, 28 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Errors in example code for boxed struct

  • Key: CPP11-153
  • Legacy Issue Number: 2226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 82 in 98-09-03 (Nov 6 1998), the sample code for a boxed
    struct is using the type "BoxedS" where "S" should be used.
    Specifically, the _value() and _boxed_XXX() functions.

  • Reported: CPP 1.0b1 — Fri, 20 Nov 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Modify the sample code as indicated.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object reference members, _var, and widening

  • Key: CPP11-152
  • Legacy Issue Number: 2215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I recently encountered an issue regarding the assignment of
    Object_vars (shorthand for any object reference _var) to object
    reference members. While the spec explicitly forbids implicit widening
    when assigning Object_vars, it does not explicitly forbid it when
    assigning object reference members.

  • Reported: CPP 1.0b1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

98-09-03, exception inconsistency

  • Key: CPP11-151
  • Legacy Issue Number: 2097
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In 98-09-03, SystemException has a pure virtual _raise() member
    (Section 20.18). That member is not shown in Section 20.40.8.

    Also, I think UserException also should have the pure virtual _raise()
    member, but neither the text in Section 20.18 nor the summary in
    Section 20.40.9 shows it.

  • Reported: CPP 1.0b1 — Mon, 19 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close as duplicate of 1923.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Is SystemException supposed to be concrete?

  • Key: CPP11-150
  • Legacy Issue Number: 1923
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA 2.2 C++ binding has the SystemException class defined as a
    concrete class, because it redefines _raise() as a non-pure virtual.

    This seems to be a bad idea to me. It would be better to leave _raise()
    as a pure virtual so that SystemException cannot be instantiated. This
    prevents accidental programming errors in catching SystemExceptions by
    value, which slices off the real exception type.

  • Reported: CPP 1.0b1 — Wed, 2 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Add pure virtual _raise functions to CORBA::SystemException and CORBA::UserException.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DSI C++ issue

  • Key: CPP11-149
  • Legacy Issue Number: 1777
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.36.1, page 20-118 of orbos/98-07-12 says:

    "Similarly, data allocated by the DIR and handed to the ORB (the NVList
    parameters, the result value, and exception values) are freed by the ORB
    rather
    than by the DIR."

    However, the signatures for the set_result() and set_exception() functions of
    ServerRequest take arguments of type const Any&. How can the ORB adopt the
    result and exception data from a const Any? Unless I am missing something,
    either these signatures have to be changed to Any&, or the quoted sentence has
    to change to remove the text "the result value, and exception values".

  • Reported: CPP 1.0b1 — Wed, 5 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Change the text as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolve_initial_references missing from Orb interface

  • Key: CPP11-145
  • Legacy Issue Number: 1686
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are you looking at CORBA 2.2, document orbos/98-02-01?

    Section 20.31.4 covers ORB_init and friends. The POA is an ordinary IDL
    interface that just follows the ordinary C++ mapping rules, so it needs no
    special mention. The C++ server side is explained in 20.33 through 20.38.

    You are correct that resolve_initial_references is missing from the ORB
    interface. This was because it used to be covered in another section, and
    it appears to have been inadvertantly dropped by the editors at the OMG.
    Juergen, this should be logged as a cxx_revision issue. However,
    resolve_initial_references just follows the regular C++ mapping rules, so
    there"s really no harm in it being missing.

  • Reported: CPP 1.0b1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Add the missing text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 7.3.5 ValueBase editorial changes

  • Key: CPP11-144
  • Legacy Issue Number: 1657
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping for ValueBase is missing return
    values on _add_ref and _remove_ref.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fix the code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for strings

  • Key: CPP11-143
  • Legacy Issue Number: 1617
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping requires that strings are to be mapped to char *.

    Unfortunately, with ANSI C++ compilers, this creates problems if
    string literals are involved.

  • Reported: CPP 1.0b1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any and WChar issue

  • Key: CPP11-142
  • Legacy Issue Number: 1386
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping requires that attempt to insert a Boolean, Octet, or
    Char value into an any must generate a compile-time error:

    CORBA::Any a;
    CORBA::Char c = "x";
    a <<= c; // Compile-time error

    The spec says nothing about WChar and WChar *. This implies that no such
    guarantee exists. However, I don"t think it would hurt to spell this out:

    CORBA::Any a;
    CORBA::WChar wc = L"x";
    a <<= wc; // Undefined behavior

  • Reported: CPP 1.0b1 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed, fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New C++ issue about T_out classes

  • Key: CPP11-148
  • Legacy Issue Number: 1776
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    In 20.9.2, the T_out class has a copy constructor and assignment
    operator that take non-const references to a T_out argument. These
    should be changed to const references instead because the T_out class
    still works correctly with the change, and many compilers issue errors
    or warnings about non-const references arguments bound to temporary
    values.

  • Reported: CPP 1.0b1 — Wed, 5 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

from_string issue

  • Key: CPP11-147
  • Legacy Issue Number: 1747
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The latest C++ mapping (document orbos/98-05-08) defines the
    Any::from_string type as

    struct from_string {
    from_string(char* s, ULong b, Boolean nocopy = FALSE) : val(s),
    bound(b) {}
    ...
    };

    In ANSI C++, this disallows the following code:

    any <<= Any::from_string("string literal");

    This is because string literals in ANSI C++ are const char[], not char[].
    Therefore, from_string should have an additional constructor to allow
    insertion of a const char* as well.

  • Reported: CPP 1.0b1 — Tue, 28 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close as duplicate of 2453.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

void * functions for Any

  • Key: CPP11-146
  • Legacy Issue Number: 1700
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping for Any currently requires:

    Any(TypeCode_ptr tc, void *value, Boolean release = FALSE);
    void replace(TypeCode_ptr tc, void *value, Boolean release = FALSE);
    const void *value() const;

    The meaning of the void * parameters is never defined (and cannot ever
    be defined because it would have to mandate a particular binary layout).

    This means these three functions have completely undefined semantics. Even
    for basic types, such as CORBA::Long, I cannot assume that the void *
    will point directly at the long value, because the mapping implementation
    is free to make the pointer point at some other value internal to an Any.

    Proposal: Remove these three functions from the mapping. If vendors want
    to retain them for backward compatibility reasons, they can.
    However, functions with completely undefined semantics that are
    inherently non-portable have no place in a standard mapping.

  • Reported: CPP 1.0b1 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Leave the original text in place. Add a sentence saying that DynAny should be used instead.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alias type codes in any values

  • Key: CPP11-138
  • Legacy Issue Number: 801
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe the spec should be updated to explicitly require the following
    to be safe: a1.replace(a1.type(), a1.value(), false);
    In other words, an Any should be obliged to detect assignment to self
    for the passed void *. Reason: The above is the only way I can see
    to get a tk_alias type code into an any, so the receiver can tell the
    difference between a date and an address.

  • Reported: CPP 1.0b1 — Fri, 12 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close issue with no change – already resolved in section 20.16.8.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Mappings for Object

  • Key: CPP11-137
  • Legacy Issue Number: 800
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping currently lack mappings for is_a(), is_equivalent(),
    hash(), and non_existent(). These need to be added. The question is, which of these operations can validly be invoked on
    a nil reference, because that affects the mapping. My thinking is that
    all of these should be allowed for nil references.

  • Reported: CPP 1.0b1 — Fri, 5 Dec 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Signature of _narrow in exceptions

  • Key: CPP11-246
  • Legacy Issue Number: 1937
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The mapping shows the signature for the _narrow static member
    functions in exceptions as

    static SystemException * _narrow(Exception *);

    I think we should change this to

    static SystemException * _narrow(const Exception *);

    Otherwise, I cannot catch an exception as const and then narrow it
    without a cast.

  • Reported: CPP 1.0b1 — Mon, 7 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ issue to coordinate with proposed resolution of issue 752

  • Key: CPP11-245
  • Legacy Issue Number: 1626
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In coordination with the proposed resolution to the ORB Portability RTF
    Issue #752, add the following operations to PortableServer::ServantBase
    in section 20.34.1:

    class ServantBase

    { ... public: ... virtual InterfaceDef_ptr _get_interface() throw(SystemException); virtual Boolean _is_a(const char * logical_type_id) throw(SystemException); virtual Boolean _non_existent() throw(SystemException); ... }

    ;

    and change the last paragraph of section 20.34.1 to:

    The default implementation of the _default_POA() function provided by
    ServantBase returns an object reference to the root POA of the default
    ORB in this process — the same as the return value of an invocation of
    ORB::resolve_initial_references("RootPOA") on the default ORB. Classes
    derived from ServantBase can override this definition to return the POA
    of their choice, if desired.

    and add the following text at the end of section 20.34.1:

    ServantBase provides default implementations of the _get_interface(),
    _is_a(), and _non_existent() standard object reference operations that
    can be overridden by the object implementation if the default behavior
    is not adequate. These functions are called just like normal skeleton
    operations by the POA, so the programmer can use _this() and and the
    PortableServer::Current interface in the function bodies.

    The default implementation of the _get_interface() and _is_a() functions
    provided by ServantBase uses the interface associated with the skeleton
    class if it is static to determine its return value. If the skeleton is
    dynamic (see 20.36) it uses the _primary_interface() function to
    determine its return value.

    The default implementation of the _non_existent() function simply
    returns false.

  • Reported: CPP 1.0b1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    :ServantBase

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing text describing fixed point constant mapping

  • Key: CPP11-244
  • Legacy Issue Number: 1538
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no text in the C++ language mapping that describes how to map a
    fixed point constant declaration.

  • Reported: CPP 1.0b1 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing constructor for Fixed

  • Key: CPP11-234
  • Legacy Issue Number: 1073
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Type Fixed has constructors for LongDouble and int. This causes
    a few initialization problems. For example:

    Fixed<8,2> x = 6.75;
    Fixed<8,2> y = 10L;
    Fixed<8,2> z = 10U;

    None of these will compile because of the ambiguity as to whether to use
    the int or the LongDouble constructor.

    I think Fixed will need additional constructors to allow initialization
    from float, double, long and unsigned values.

  • Reported: CPP 1.0b1 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

fixed_digits and fixed_scale member functions

  • Key: CPP11-233
  • Legacy Issue Number: 1072
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20-34 of CORBA 2.2 shows member functions of the Fixed template:

    CORBA::UShort fixed_digits() const;
    CORBA::Short fixed_scale() const;

    There are no semantics specified for these. I assume they return the
    number of the respective digits passed to the template? For example, given

    Fixed<5,2> x;

    assert(x.fixed_digits() == 5);
    assert(x.fixed_scale() == 2);

    Is this the correct interpretation? If so, the spec should say so (otherwise,
    I might, for example, expect that fixed_digits returns 3 and fixed_scale
    return 2).

  • Reported: CPP 1.0b1 — Thu, 19 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ Any mapping proposed change

  • Key: CPP11-243
  • Legacy Issue Number: 1319
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add the following operation to CORBA::Any:

    class Any

    { ... void type(TypeCode_ptr); ... }

    ;

    This will replace the internal typecode in the any with the specified
    typecode. If the new typecode is not equivalent to the old typecode (as
    defined by TypeCode::equivalent), then implementation will raise the
    BAD_TYPECODE system exception.

  • Reported: CPP 1.0b1 — Tue, 12 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to put a generic CORBA exception into an Any

  • Key: CPP11-242
  • Legacy Issue Number: 1289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There doesn"t appear to be any way to place an arbitrary exception into
    an Any with the current C++ mapping. This is necessary to make the DSI
    usefulThe spec needs to be extended to provide an inserter function to insert
    a CORBA::Exception into an Any. I know that this has potential issue
    for the inserter function to determine the correct typecode for the
    exception, but I can"t think of any other way to get an exception into
    the Any when all I"ve got is a CORBA::Exception * without having to
    enumerate each possible exception by calling _narrow.

  • Reported: CPP 1.0b1 — Wed, 29 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

macros for fixed arithmetic results

  • Key: CPP11-232
  • Legacy Issue Number: 1070
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The fixed mapping says on page 20-35 of orbos/98-01-11:

    One way to do this is to declare the result types with a macro
    that evaluates to the approate values, based on the digits and
    scale of the operands:

    // Example of Fixed result type declaraction
    // Fixed<_FIXED_ADD_TYPE(d1,s1,d2,s2)> -> Fixed<dr,sr>

    I think the name of the macro for each rule needs to be nailed down.

  • Reported: CPP 1.0b1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos on p 20-34 of orbos/98-01-11

  • Key: CPP11-231
  • Legacy Issue Number: 1069
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: page 20-34 of orbos/98-01-11 contains a few typos:

    1)
    template<CORBA::UShort d, Short s>

    should be

    template<CORBA::UShort d, CORBA::Short s>

    2)
    operator LongDouble() const;

    should be

    operator CORBA::LongDouble() const;

    3)

    template<unsigned short d1, short s1, unsigned short d2, short s2)

    should use CORBA types and use a closing ">" instead of ")":

    template<
    CORBA::UShort d1,
    CORBA::Short s1,
    CORBA::UShort d2,
    CORBA::Short s2
    > // Note closing ">"

  • Reported: CPP 1.0b1 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed types in orbos/98-01-11

  • Key: CPP11-230
  • Legacy Issue Number: 1056
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 20-36, near the top, the mapping says:

    A T_out type for a Fixed type is defined as typedef to a
    reference to the Fixed type, with the digits and scale added to
    the name to disambiguate it. For example, the name of the T_out
    type for the type Fixed<5,2> is Fixed_5_2_out:

    // C++
    typedef Fixed<5, 2>& Fixed_5_2_out;

    This doesn"t appear to work for fixed types with negative scale. For example:

  • Reported: CPP 1.0b1 — Tue, 17 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA::ORB::InvalidName ambigious in C++ mapping

  • Key: CPP11-229
  • Legacy Issue Number: 933
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 5.6:

    // PIDL
    module CORBA {
    interface ORB {
    exception InvalidName {};
    };
    };

    In section A.24:

    // C++
    class ORB {
    public:
    class InvalidName

    {...}

    ;
    };

    The C++ mapping should be clarified to show that this is indeed a user
    exception.

  • Reported: CPP 1.0b1 — Fri, 30 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ Fixed Type (03)

  • Key: CPP11-238
  • Legacy Issue Number: 1126
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) Page 20-35: the +=, -=, *=, and /= operators are required by the
    C++ language to be member functions, not global functions. They
    should be moved into the Fixed class and should return a reference to
    *this, not a value.

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed type (02)

  • Key: CPP11-237
  • Legacy Issue Number: 1125
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) Page 20-35: the semantics of the istream extraction and ostream
    insertion functions are totally unspecified – what formats are used
    to read and write Fixed types?

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_out parameter typo

  • Key: CPP11-241
  • Legacy Issue Number: 1149
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-01-11 contains a typo on page 20-20.

    The last line of Table 19-1 shows CORBA::Octet in the "C++ Out Type"
    column. This should be CORBA::Octet_out instead.

  • Reported: CPP 1.0b1 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in orbos/98-01-11

  • Key: CPP11-240
  • Legacy Issue Number: 1148
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 20-74, para 1:

    ... original specified except the first oneA caller is ...

    Should be

    ... original specified except the first one. A caller is ...

  • Reported: CPP 1.0b1 — Fri, 17 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ Fixed type issue (01)

  • Key: CPP11-236
  • Legacy Issue Number: 1124
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) Page 20-34: the unary + and - operators in the Fixed class should
    return by value, not by reference.

  • Reported: CPP 1.0b1 — Tue, 31 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for fixed is broken (01)

  • Key: CPP11-235
  • Legacy Issue Number: 1092
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. If the C++ target environment does not support namespaces and/or
    nested template class definitions, then it is impossible to implement
    the Fixed template type as part of the CORBA module.

  • Reported: CPP 1.0b1 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String member initialization

  • Key: CPP11-239
  • Legacy Issue Number: 1128
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: orbos/98-01-11 doesn"t initialize string members if they are inside
    a sequence or array.

    For consistency, it would be better to adopt the following:

    • A plain String_var is default-constructed to contain a
      null pointer (like all other _var types).
    • If a structure, exception, sequence, or array contains
      a string, that string is initialized to the empty string
      when default-constructed. In case of a sequence of strings,
      this means that strings are default-constructed to the
      empty string when the sequence is extended.
  • Reported: CPP 1.0b1 — Wed, 1 Apr 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Access to sequence elements

  • Key: CPP11-202
  • Legacy Issue Number: 246
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: At present sequence elements can only be accessed through operator[]. Public accessors be provided to allow a sequence to simultaneously be viewed as alinked list.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 75 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any and IN_COPY_VALUE

  • Key: CPP11-201
  • Legacy Issue Number: 240
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Binding spec states that implementation af Any must not store its value as reference or pointer to value passed into insertion operator <<= Any return pointer must not be NULL pointer...

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarifying text added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operator>>= on strings and object references

  • Key: CPP11-200
  • Legacy Issue Number: 236
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12.2 Pg 16-27 CORBA2.0 Sun wants to add para.: Extraction operator>>= doesn"t free old storage, doesn"t pass old string to string_free, doesn"t invoke release on old object reference.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarifying text added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

A_ptr and A_var should be distinct types

  • Key: CPP11-199
  • Legacy Issue Number: 235
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.2.1 Pg 16-4 CORBA2.0 A_ptr and A_var need not be distinct. Since these types have distinct semantics, they need to be distinct (Section 3.5.1 para 4)

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 189 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Default constructor for String_var

  • Key: CPP11-211
  • Legacy Issue Number: 269
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping currently specifies that the default constructor for CORBA::String_var initializes the string to NULL Pointer. This is very inconvenient, in particular for structures

  • Reported: CPP 1.0b1 — Thu, 17 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed as suggested by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

explicit copy/adopt for String_var

  • Key: CPP11-210
  • Legacy Issue Number: 265
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Copying + adopting performed by String_var::operator= are very error-prone.Better to have explicit functions to copy, adopt,reference.(e.g void String_var::copy(const char*);

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    handled by Portability submission - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode interpreter

  • Key: CPP11-209
  • Legacy Issue Number: 262
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 4.10 describes mapping for TypeCode. Sun proposes the following typecode interpreter interface: (available in /archives/issues/issue261)

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed with issue 251

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any release flag and operator<<=

  • Key: CPP11-208
  • Legacy Issue Number: 257
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Any should take over the inserted value(Sun) Avoids unnecessary copy for structured types listed in table 2

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    requested functionality added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

to/from string for Any type safety

  • Key: CPP11-205
  • Legacy Issue Number: 249
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We sure could use any_to/from_string<nnn> classes so that the type safe any api could be used for all IDL types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Requested functionality added

  • Updated: Fri, 6 Mar 2015 20:58 GMT

nested ptr and var types

  • Key: CPP11-204
  • Legacy Issue Number: 248
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ptr and var types for objrefs should be nested inside interface class, e.g A::ptr and A::var. Would make writing templates using these types easier.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in table 3?

  • Key: CPP11-197
  • Legacy Issue Number: 229
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Pg 16-46 table 24 CORBA2.0 Shouldn"t arrays be by & for inout? This looks like a typo.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequence creation

  • Key: CPP11-196
  • Legacy Issue Number: 216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 How do I know how sequence was created. Must my code carry arround an extra piece of information saying how sequence was created?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessors for release flag of sequence

  • Key: CPP11-207
  • Legacy Issue Number: 256
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.describes mapping for sequence.Accessor functions should be provided for release flag.Add following member functions: void release(Boolean), Boolean release() --pure accessors

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 75 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

T_copy for string and array

  • Key: CPP11-206
  • Legacy Issue Number: 252
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Duplicate of issue 148 - closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_var types for fixed-length types

  • Key: CPP11-198
  • Legacy Issue Number: 230
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As a convenience for managing this pointer, the mapping also provides another class of each variable-length type. It also provides one for fixed-length types. You should say so

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode mapping update for CORBA 2.)

  • Key: CPP11-203
  • Legacy Issue Number: 247
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It seems that the TypeCode mapping needs to be updated to reflect the TypeCode definition in Interface Repository Spec (p 64)

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    TypeCode interface updated

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface issue

  • Key: CPP11-165
  • Legacy Issue Number: 2376
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The interface between application programmer and CORBA components (BOA, stubs, skeletons etc.) should be as simple as possible (but, naturally, not more simple). I am afraid, that introduction of the new classes to C++ mapping like A_out is not the best way to simplify their life to the creators of the final applications - the application programmers. It is naturally, when creator of the CORBA implementation use very advanced and sophisticated constructions of the programming language, but let he/she left application creators their invention to study application problems, not those advanced features of the programming environment. How many application programmers understand well such construction like "reference to pointer"?
    Naturally, if the new constructions would bring some new principal features to the problem, they may be accepted, but I am afraid, that the only reason of the A_out class is to ensure freeing of memory occupied by the old data of the corresponding variables. But the same service may be done by the first statement of the (generated) stub.

  • Reported: CPP 1.0b1 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Transfer of C++ codes

  • Key: CPP11-164
  • Legacy Issue Number: 2375
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: During my study of the specification CORBA 2.2, I tried to transfer C++ codes on pages 20-12, 20-13 and 20-11 to the C++ source, add some dummy declarations and definitions of such classes as Object and tried to compile it. I obtained error message from the definition of the constructor A_out::A_out(A_var& p) : ptr_(p.ptr_) ... due to unauthorized access to protected member A_var::ptr_. This was no conceptual problem to introduce access function A_var::ptr() in similar manner like has been introduces function A_out::ptr() and correct the problem, another way is definition of some classes as friend ... . But my reliance to document containing such mistakes was lost. Please, can you pay more attention to testing and preparing of the concluding documents?

  • Reported: CPP 1.0b1 — Tue, 2 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Closed without change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB mapping re Policy

  • Key: CPP11-163
  • Legacy Issue Number: 2355
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. ORB pidl on 20-130 of ptc/98-09-03 is missing the create_policy
    pseudo-operation.

    2. Sometimes I think the traditional style of PIDL mapping used for the Java,
    C++, and draft Lisp mappings, wherein each PIDL pseudo-operation is
    explicitly listed in each mapping, is risky - insofar as version
    mismatches between the Core Pseudo-IDL and the pseudo-IDL used in the
    mapping document can and frequently do arise.

  • Reported: CPP 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Add the missing operation.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Access to sequence buffers

  • Key: CPP11-169
  • Legacy Issue Number: 75
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We would like to see an enhancement which allows access to sequence buffers once they have been constructed.

  • Reported: CPP 1.0b1 — Tue, 13 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Omission in union C++ mapping

  • Key: CPP11-168
  • Legacy Issue Number: 52
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Several problems exist with the definition of union constructors.

  • Reported: CPP 1.0b1 — Thu, 11 Jul 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed by adding clarifying text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any inserters for strings need to use const pointers

  • Key: CPP11-167
  • Legacy Issue Number: 2453
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The inserter helper functions for string and wstring on type Any should
    have const pointers as the constructor parameter, otherwise I can"t
    insert string literals with an ANSI C++ compiler.

  • Reported: CPP 1.0b1 — Tue, 16 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Make the suggested fixes.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ keyword mapping ambiguous

  • Key: CPP11-166
  • Legacy Issue Number: 2443
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last para of section 20.1.2 says:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx". For example, an IDL interface named
    "try" would be named "_cxx_try" when its name is mapped into C++.

    This is ambiguous because it doesn"t make it clear what the names of types
    derived from that interface shold be.

  • Reported: CPP 1.0b1 — Mon, 8 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extraction from Any by pointer

  • Key: CPP11-158
  • Legacy Issue Number: 2335
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the mapping currently specifies that for char * and WChar *, the following
    extraction operators must be defined on type Any:

    class Any

    { Boolean operator>>=(const Any &, char * &); Boolean operator>>=(const Any &, WChar * &); // ... }

    ;

    For user-defined complex types and other variable-length types, the mapping
    requires:

    class Any

    { Boolean operator>>=(const Any &, T * &); // ... }

    ;

    This means that a conforming ORB need not compile the following:

    CORBA::Any a = ...;
    const char * p;
    a >>= p; // No matching operator

    This is a Bad Thing (TM), in my opinion. The reason is that when I extract
    something by pointer, first, the Any retains ownership and, second,
    I must treat the pointed-to memory as read-only.

  • Reported: CPP 1.0b1 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ spec uses reserved names in global namespace

  • Key: CPP11-157
  • Legacy Issue Number: 2288
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ language mapping generates typecode names for global IDL type
    definitions that start with an underscore. The C++ standard reserves
    global symbols that start with an underscore for the compiler
    implementation. We need to resolve this conflict.

  • Reported: CPP 1.0b1 — Tue, 29 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

string allocation functions -- description ambiguous

  • Key: CPP11-156
  • Legacy Issue Number: 2286
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the text for string_alloc et al. says:

    The string_alloc function dynamically allocates a string,
    or returns a null pointer if it cannot perform the allocation.

    [ ... ]

    The string_alloc, string_dup, and string_free functions may not
    throw CORBA exceptions.

    I think the second sentence is a little misleading. What is meant is that
    these functions cannot throw any exceptions at, not that they won"t throw
    CORBA excecptions but are allowed to throw others, such as bad_alloc.

    I suggest to change the second sentence to read:

    The string_alloc, string_dup, and string_free functions may not
    throw exceptions.

  • Reported: CPP 1.0b1 — Thu, 24 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String sequence and allocbuff

  • Key: CPP11-155
  • Legacy Issue Number: 2234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The allocbuf function allocates a vector of T elements that can be
    passed to the T
    *data constructor and to the replace() member function. The length of
    the vector
    is given by the nelems function argument. The allocbuf function
    initializes each
    element using its default constructor, except for strings and wide
    strings, which are
    initialized to null pointers, and object references, which are
    initialized to suitably-typed
    nil object references. A null pointer is returned if allocbuf for some
    reason
    cannot allocate the requested vector.

    Since in the latest mapping the elements of string sequences are now
    initialized as empty strings, wouldn"t it be more logical if allocbuf
    would also initialize the elements of the returned string vector with
    empty strings instead of null pointers?

  • Reported: CPP 1.0b1 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_raise() should be const

  • Key: CPP11-154
  • Legacy Issue Number: 2231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CORBA::Exception::_raise() virtual member function should have the
    const qualifier. Since it effectively throws a copy of the exception,
    there isn"t any reason why you shouldn"t be able to call it on a const
    Exception.

  • Reported: CPP 1.0b1 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Make _raise a const member function.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

boxed types for floating point values

  • Key: CPP11-160
  • Legacy Issue Number: 2350
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In ptc/98-08-03 p.20-80:

    For all the integer types, boolean, octet, char, wchar and
    enumerated types, value box classes provide.

    1. The phrase "integer types" should presumably read "integer types except for
    fixed" in view of the separate mapping for fixed type on p. 20-85. It
    is true that "integer type" can mean signed_int or unsigned_int, in
    contexts such as Corba 2.3a grammar, but the phrase here seems
    potentially ambigous.

    2. The phrase should be extended to include floating point types
    (including float, double, and long double).

  • Reported: CPP 1.0b1 — Thu, 28 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify the text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any inserters and extractors

  • Key: CPP11-159
  • Legacy Issue Number: 2346
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the 1.4 version of the C++ mapping has an internal inconsistency. In
    sections 20.16.2 and 20.16.3, the inserters and extractors for built-in
    types that don"t require a from_* or to_* helper class are shown
    as non-member functions of type Any.

    However, section 20.39.5 shows the the inserters and extractors as
    member functions of type Any.

    Section 20.39.5 is wrong and needs be updated to reflect the signatures
    in 20.16.

  • Reported: CPP 1.0b1 — Wed, 27 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CustomMarshal mapping type

  • Key: CPP11-162
  • Legacy Issue Number: 2354
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ptc/98-09-03, p. 20-96: In "The C++ mappings for the IDL
    CORBA::CustomerMarshal..." change Customer to Custom.

  • Reported: CPP 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Fix the typo.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA2.3 C++ mapping for the TypeCode class (section 20.31.2)

  • Key: CPP11-161
  • Legacy Issue Number: 2351
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: The CORBA2.3 C++ mapping for the TypeCode class
    (section 20.31.2) has not been updated.

    Suggested Resolution: Add get_compact_typecode() and valuetype/
    valuebox operations. Also, remove the param_count and parameter
    methods which were deprecated in CORBA2.2 and eliminated in
    CORBA2.3.

  • Reported: CPP 1.0b1 — Thu, 28 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    This issue has already been resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ classes for modules

  • Key: CPP11-172
  • Legacy Issue Number: 96
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does the standard require an implementation to use C++ classes for modules if there is no namespace support? Or is it simply a suggestion?

  • Reported: CPP 1.0b1 — Tue, 3 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Defining an operator for struct/union/sequence _var types

  • Key: CPP11-171
  • Legacy Issue Number: 94
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If no operator *() is defined for struct, union, or sequence _var types, some pieces of code will break.

  • Reported: CPP 1.0b1 — Thu, 29 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 20:58 GMT

T__alloc in C mapping

  • Key: CPP11-170
  • Legacy Issue Number: 92
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is it intended that use of T__alloc functions are the only conformant way to allocate values of (variable length) type T? Or can a conformant app also declare them on the stack?

  • Reported: CPP 1.0b1 — Tue, 27 Aug 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Memory Management Clarification

  • Key: CPP11-175
  • Legacy Issue Number: 101
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should fields of a struct persist across a deep copy?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Union discriminators in C++

  • Key: CPP11-174
  • Legacy Issue Number: 100
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is a modifier function required under the C++ mapping of unions, and if it is, can it be used to set the discriminator to an illegal value?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

In String Argument Passing Question

  • Key: CPP11-173
  • Legacy Issue Number: 98
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: To be compliant, does a client have to pass a string_alloc"ed string to a CORBA operation that takes an in string parameter? If so, why should the ORB care how the client created storage?

  • Reported: CPP 1.0b1 — Fri, 6 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    clarified

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inserter and extractor functions for exceptions

  • Key: CPP11-177
  • Legacy Issue Number: 142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec is silent about whether to generate Any inserter and extractor (<<= and >>=) functions for exceptions, although they appear necessary for properly storing and manipulating exceptions.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    added clarifying texed, fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Union problem

  • Key: CPP11-176
  • Legacy Issue Number: 134
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Is this legal: union X switch(boolean)

    {case TRUE: short a; case FALSE: long b;default: double c;}

    ;? If no, why? If yes, what does _d() return if the union was set with the c() access function?

  • Reported: CPP 1.0b1 — Tue, 24 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    fixed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

GIOP fragment alignment issue for CORBA 2.3

  • Key: CPP11-129
  • Legacy Issue Number: 1982
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The following issue should be fixed prior to publishing CORBA 2.3.

    Section 15.4.8 Fragment Message, page 15-40, of ptc/98-08-03, says:

    > A primitive data type of 8 bytes or smaller should never be broken across two
    > fragments.

    This text has been in the specification since GIOP 1.1.

    Section 15.4.1 GIOP Message Header, page 15-29, of ptc/98-08-03,
    contains new text under the "message size" bullet:

    > For GIOP version 1.2, if the second least significant bit of flags is 1, the
    > message_size value must be evenly divisible by 8.

  • Reported: CORBA 2.2 — Sun, 20 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

COMM_FAILURE and completion_status

  • Key: CPP11-128
  • Legacy Issue Number: 1978
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 15-43 of 98-08-13:
    As Bob Kukura pointed out, COMPLETED_MAYBE could well be wrong. In particular,
    if the connection goes down in the middle of a series of fragments that
    make up the reply, or in between reads by the client of parts of the
    message from a socket, the client can actually conclude reliably
    that the status should be COMPLETED_YES.

    I would suggest to strike the last clause of this para. This would also
    bring things in line with the additions made to the exception section in
    the IDL chapter.

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    agree to remove the last sentence of 15.5.1.1

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo in page 15-44

  • Key: CPP11-127
  • Legacy Issue Number: 1975
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 15-44, second para after bullet list, the word LOCATION_FORWARD
    appears in the wrong font (in two places).

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    duplicate of issue # 2045

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CloseConnection

  • Key: CPP11-126
  • Legacy Issue Number: 1968
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are quite a few words about CloseConnection in the GIOP 1.2 draft.
    The major change is that either end of a connection can send the message
    for a bi-directional connection.

    However, the spec doesn"t say that a client must send a CloseConnection
    message to the server before closing down. It just says that it may.

    Similarly, CloseConnection is only partially defined for the server side,
    as far as I can see.

  • Reported: CORBA 2.2 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

How to handle unexpected exceptions?

  • Key: CPP11-125
  • Legacy Issue Number: 1129
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If I invoke an operation and the result is an exception that is not
    defined as part of the operation"s definition, what should happen? It
    seems obvious that a different exception needs to be raised but which
    one? MARSHAL?

  • Reported: CORBA 2.2 — Thu, 2 Apr 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    Clarify to Be consistent with behaviour for system exceptions. Raise UNKNOWN exception

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IIOP server-initiated connection closure problem

  • Key: CPP11-124
  • Legacy Issue Number: 543
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On several operating systems the client"s writing of Request message after CloseConnection message can cause the unread CloseConnection message to be discarded from buffer

  • Reported: CORBA 2.0 — Wed, 16 Apr 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move recently added text to correct place

  • Key: CPP11-133
  • Legacy Issue Number: 2324
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The recently addded fourth bullet on page 15-18 "For value types that have
    an RMI: rep id, ORBs must include at least the most derived rep id, in the
    value type encoding." should be moved back to be a paragraph on page 15-15,
    preceding the paragraph that starts "If the receiving context ...".

    Its current placement is incorrect because this section (15.3.4.4)
    describes chunking, and this bullet has nothing to do with chunking but
    concerns how much type information needs to be specified in the encoding
    (the subject of section 15.3.4.1).

  • Reported: CORBA 2.2 — Thu, 21 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    To accept proposed change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OBV GIOP clarification needed

  • Key: CPP11-132
  • Legacy Issue Number: 2315
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On page 15-15 of the 2.3a core chapters, I am having trouble
    understanding the wording in the first two bullets. The definition
    of what the different bit values mean is clear enough, but the
    rationale for when they are used is not.

    Specifically, I don"t understand the subtle difference between
    "the actual parameter is the same type as the formal argument"
    (first bullet) and "the actual value"s most derived type is the
    same as the static type of the position currently being marshaled"
    (second bullet). Are these different cases? If so, what is the
    difference?

  • Reported: CORBA 2.2 — Wed, 20 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tagged Component interactions

  • Key: CPP11-131
  • Legacy Issue Number: 2068
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Tagged Components TAG_SSL_SEC_TRANS and TAG_IIOP_ALTERNATE_ADDRESS
    both allow an IIOP profile to have an extra port in the IOR. The
    words around SSL_SEC_TRANS say something like "to be used instead
    of the one in the profile proper". Whereas the words around
    ALTERNATE_ADDRESS are deliberately vague.

    So what should a client-side ORB do with one of these? It could
    view the IOR as broken, it could treat the ALTERNATE_ADDRESS
    component as invalid or it could treat the port in the ALTERNATE_
    ADDRESS component as either for TCP connection requests >or< for
    SSL connection requests. It could even look for a second
    SSL_SEC_TRANS component.

  • Reported: CORBA 2.2 — Fri, 9 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved, see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Obsolete text in ptc/98-08-13.pdf

  • Key: CPP11-130
  • Legacy Issue Number: 2045
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 15.7, the second two paragraphs:

    "IIOP 1.0 is based on GIOP 1.0.

    IIOP 1.1 can be based on either GIOP 1.0 or GIOP 1.1. An IIOP 1.1 client
    can either support both GIP 1.0 and 1.1, or GIOP 1.1 only. An IIOP 1.1
    server must support both GIOP 1.0 and GIOP 1.1. An IIOP 1.1 server must
    be able to receive both GIOP 1.0 and GIOP 1.1 requests and reply using
    the same GIOP revision as invoked."

    only refer to GIOP 1.0 and 1.1, not 1.2. In light of the note in
    section 15.7.2, these two paragraphs are obsolete and could be removed,
    since the note covers the same information in a more generic way.

  • Reported: CORBA 2.2 — Tue, 6 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.0
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed(const char *) constructor problem

  • Key: CPP11-109
  • Legacy Issue Number: 2949
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 C++ spec says (1.11):

    "The Fixed(char*) constructor converts a string representation of a
    fixed-point literal into a real fixed-point value, with the trailing 'd'
    or 'D' optional."

    However, the CORBA 2.3 spec for a fixed point literal says (3.2.5.5):

    "A fixed-point decimal literal consists of an integer part, a decimal
    point, a fraction part and a d or D. The integer and fraction parts both
    consist of a sequence of decimal (base 10) digits. Either the integer
    part or the fraction part (but not both) may be missing; the decimal
    point (but not the letter d (or D)) may be missing."

    This means that the following call is illegal:

    CORBA::Fixed f("-1.0");

    Even though this can be rewritten (legally) as:

    CORBA::Fixed f(-CORBA::Fixed("1.0"));

    I think it would be a good idea change the definition of the constructor
    to also allow an optional sign (+ or -).

  • Reported: CPP 1.0 — Fri, 24 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial typo in Section 1.36.3 of C++ mapping

  • Key: CPP11-108
  • Legacy Issue Number: 2948
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The code example has a "ServantBaseBase_var".

  • Reported: CPP 1.0 — Wed, 13 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed, editorial fix

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Two obvious typos in the C++ mapping for OBV (docs/formal/99-07-41.pdf)

  • Key: CPP11-98
  • Legacy Issue Number: 2841
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - The factories" names in the example IDL on page 1-88 are incomplete

    • Page 1-90: should be CORBA::CustomMarshal rather than
      CORBA::CustomerMarshal. Nice freudian slip. Might it be that the OBV
      mapping was done by marketeers rather than technicians?
  • Reported: CPP 1.0 — Sun, 15 Aug 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as duplicate of 2354.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Object _out class copy constructor & assignment op wrong

  • Key: CPP11-107
  • Legacy Issue Number: 2947
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Issue 1776 was supposed to change all T_out classes so that their copy
    constructor and assignment operators took a "const T_out &". The _out
    class in 1.3.6 didn't get updated with this change.

  • Reported: CPP 1.0 — Mon, 18 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CORBA 2.3 Editorial problem in TypeCode

  • Key: CPP11-106
  • Legacy Issue Number: 2946
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Sections 1.32.2 and 1.41.20 have TypeCode::type_modifier() returning a
    ValuetypeModifier. It should be ValueModifier instead.

  • Reported: CPP 1.0 — Thu, 21 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    editorial fix...isssue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Contents of string members (02)

  • Key: CPP11-101
  • Legacy Issue Number: 2888
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. Should it be legal to assign a null pointer to a string member of a
    struct, sequence, array or exception?

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Contents of string members (01)

  • Key: CPP11-100
  • Legacy Issue Number: 2887
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. What is the contents of a string member of a struct, sequence, array
    or exception after out() or _retn() has been called? Is it a null
    pointer, or an empty string?

    I think that for best consistency, it should be an empty string, which
    is the same state after default construction.

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String extractor semantics undefined?

  • Key: CPP11-102
  • Legacy Issue Number: 2890
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA 2.3 added the requirement (1.7 & 1.8) that string extractor
    operators be defined for String_var & string member classes, for
    example:

    std::istream& operator >>(std::istream &, CORBA::String_var &);

    However, the semantics of the extractor operations is undefined. Does
    the extractor operator extract characters until the first whitespace?
    until a newline? until the default width of the stream? until eof?

    The same applies to wide strings.

  • Reported: CPP 1.0 — Tue, 14 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception constructors should be protected

  • Key: CPP11-104
  • Legacy Issue Number: 2897
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The constructors for CORBA::Exception, CORBA::SystemException and
    CORBA::UserException should be protected, not public, since there is no
    reason for a direct instance of these classes ever to be instantiated.

  • Reported: CPP 1.0 — Fri, 15 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Base exception classes are abstract, so this change is not necessary.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception::_raise() should be const?

  • Key: CPP11-103
  • Legacy Issue Number: 2895
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no reason that the _raise() function for CORBA::Exception
    should not be const. We should change it"s signature to:

    class Exception

    { public: ... void _raise() const = 0; ... }

    ;

  • Reported: CPP 1.0 — Mon, 20 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Union string member mapping defect?

  • Key: CPP11-99
  • Legacy Issue Number: 2880
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The mapping for string members has modifier functions for "char *",
    "const char *", and "String_var". Shouldn"t there also be a modifier
    function that takes the unnamed struct string member and array string
    member types?

  • Reported: CPP 1.0 — Sat, 4 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unary operators for Fixed class have wrong return types

  • Key: CPP11-105
  • Legacy Issue Number: 2902
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Some of the unary operators for the Fixed class have the wrong return
    type:

  • Reported: CPP 1.0 — Mon, 20 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

1 of 4 issues with Abstract interfaces

  • Key: CPP11-114
  • Legacy Issue Number: 3078
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    1. The resolution that we seemed to be converging on for issue 674
    allows programmers to inherit servant implementations like this:

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    class MyA : public virtual POA_A {
    };

    class MyB : public virtual POA_B, public virtual MyA {
    };

    However, this paradigm breaks when using abstract interfaces:

    // IDL
    abstract interface A {
    };

    interface B : A {
    };

    since the spec does not require a POA skeleton be generated for A.

    I think we should change the spec to state that POA skeletons for
    abstract interfaces are generated, but that these skeletons do not
    inherit from ServantBase, and do not contain a _this() member function.
    This will allow inheritence of implementations, even for abstract
    interfaces.

    I considered just having POA_B just inherit directly from the abstract
    class A, but that would allow POA_B skeletons to be widened implicitly
    to an abstract interface pointer (for implementations which define A_ptr
    as A *), and that seems to be too trouble prone. If someone can think
    of a way to do this and prevent implicit widening, then this would be
    better, since it would even allow sharing of implementation between a
    servant and a valutype that both inherit from the same abstract
    interface.

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

NamedValue not only an NVList element

  • Key: CPP11-113
  • Legacy Issue Number: 2967
  • Status: closed  
  • Source: Hewlett-Packard ( Owen Rees)
  • Summary:

    In formal/99-07-41 section 1.28 "NamedValue" it says "NamedValue is used
    only as an element of NVList, especially in the DII." but this is not
    correct. Note the remark in section 1.33.3 "Differences from C-PIDL" which
    describes other uses: "Added create_named_value, which is required for
    creating NamedValue objects to be used as return value parameters for the
    Object::create_request operation."

  • Reported: CPP 1.0 — Mon, 27 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    editorial fix, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

4 of 4 issues with Abstract interfaces

  • Key: CPP11-117
  • Legacy Issue Number: 3081
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    4. Is there any merit in adding narrow operations to AbstractBase that
    would allow the programmer to narrow to ValueBase or Object_ptr?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

don't understand the last paragraph of 1.18.2:

  • Key: CPP11-116
  • Legacy Issue Number: 3080
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    "Both interfaces that are derived from one or more abstract interfaces,
    and valuetypes that support one or more abstract interfaces support
    implicit widening to the _ptr type for each abstract interface base
    class. Specifically, the T* for valuetype T and the T_ptr type for
    interface type T support implicit widening to the Base_ptr type for
    abstract interface type Base. The only exception to this rule is for
    valuetypes that directly or indirectly support one or more regular
    interface types (see Section 1.17.9, Valuetype Inheritance, on page
    1-83). In these cases, it is the object reference for the valuetype, not
    the pointer to the valuetype, that supports widening to the abstract
    interface base."

    This seems to prohibit widening from a valuetype pointer to an abstract
    interface _ptr if the valuetype happens to support a normal interface.
    I don't understand the restriction. This seems to prohibit the
    programmer making a choice of using value or reference semantics in the
    case of diamond inheritence of an abstract interface:

    // IDL
    abstract interface A {
    };

    interface I : A {
    };

    valuetype V1 : supports A {
    };

    valuetype V2 : supports I {
    };

    This means that I must always pass V2 valuetypes by reference to
    operations expecting an A, and cannot choose to pass V2 valuetypes by
    value instead. Why was this restriction added and what would be the
    problem with relaxing it in this case?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Extraction operator for system exceptions?

  • Key: CPP11-119
  • Legacy Issue Number: 3103
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    currently it is not possible to pull an exception out of an Any generically,
    that is, I cannot write:

    const CORBA::SystemException * sep;
    CORBA::Any a;

    // assume a contains a system exception...

    a >>= sep;

    Normally, I won't need this. However, it's come up as part of portable
    interceptors. For example, I might want to write an interceptor that
    logs things, including system exceptions. Now, if I have a system exception
    in an Any, the only way to get it out is to successively try to extract
    every possible system exception until I find one that works.

    That's rather tedious. It would be nicer if I could extract a base
    pointer to the actual exception, so I can print the minor number and
    completion status.

    I would like to suggest adding the following extraction operator:

    Boolean operator>>=(const SystemException * &);

  • Reported: CPP 1.0 — Fri, 10 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need Any::to_value operation?

  • Key: CPP11-118
  • Legacy Issue Number: 3092
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    Given that we have Any::to_object and Any::to_abstract_base, shouldn't
    there be an Any::to_value_base as well?

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

2 of4 issues with Abstract interfaces

  • Key: CPP11-115
  • Legacy Issue Number: 3079
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    2. I do not understand this bullet in section 1.18.2:

    "o Inserting an abstract interface reference into a CORBA::Any operates
    polymorphically; either the object reference or valuetype to which the
    abstract interface reference refers is what actually gets inserted into
    the Any. Because abstract interfaces cannot actually be inserted into an
    Any, there is no need for abstract interface extraction operators,
    either. The CORBA::Any::to_abstract_base type allows the contents of an
    Any to be extracted as an AbstractBase if the entity stored in the Any
    is an object reference type or a valuetype directly or indirectly
    derived from the AbstractBase base class. See Section 1.16.6, Widening
    to Abstract Interface, on page 1-62 for details."

    This seems to make no sense. It seems to state that the actual
    reference or valuetype is inserted into the Any, which means that the
    TCKind associated with the any will be tk_objref or tk_value, not
    tk_abstract_interface. This seems to have particularly bad implications
    with the DII & DSI. How does the DII know to encode an abstract
    interface correctly in CDR if the Any it receives doesn't have a
    tk_abstract_interface TypeCode? It also means that an application which
    only knows the abstract interface type must handle the case where the
    Any has a tk_objref or tk_value instead, use Any::to_abstract_interface
    and then a narrow call to get the abstract interface pointer it needs.

    This seems needlessly complex and unnecessary. This bullet should be
    replaced with one that just states that abstract interfaces have
    inserters and extractors generated for them just like normal interfaces.

  • Reported: CPP 1.0 — Sat, 4 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Supporting typedefs for _var types?

  • Key: CPP11-122
  • Legacy Issue Number: 3563
  • Status: closed  
  • 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.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Duplicate or Merged — CPP 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any::to_abstract_base needs statement about memory management

  • Key: CPP11-121
  • Legacy Issue Number: 3113
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The description of Any::to_abstract_base does not have any information
    about its memory managment implications. It should have the equivalent
    semantics to Any::to_object, and require the resulting reference to be
    released by the caller.

  • Reported: CPP 1.0 — Sun, 12 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Standard object operations & DynamicImplementation

  • Key: CPP11-112
  • Legacy Issue Number: 2966
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The CORBA 2.3 spec needs to make it clear that for dynamic
    implementations, invocations of the standard object operations
    (get_interface, is_a, non_existent) call the virtual functions defined
    in PortableServer::ServantBase, and do not call
    PortableServer::DynamicImplementation::invoke().

  • Reported: CPP 1.0 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in 1.7 and 1.9 of mapping

  • Key: CPP11-111
  • Legacy Issue Number: 2951
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Minor editorial issue:

    In Section 1.9.2, "T_out Types":

    class T_out {
    public:
    //...
    T_out(const T_out& p) : ptr_(p.ptr_) {}
    T_out& operator=(const T_out& p)

    { ... }
    };

    In Section 1.7, "Mapping for String Types":

    class String_out {
    public:
    // ...
    String_out(String_out& s) : ptr_(s.ptr_) {}
    String_out& operator=(String_out& s) { ... }

    };

    Note the missing "const" in 1.7. I suspect String_out should do the
    same as T_out and pass const references.

  • Reported: CPP 1.0 — Mon, 11 Oct 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typographical problems

  • Key: CPP11-123
  • Legacy Issue Number: 5450
  • Status: closed  
  • Source: Boeing Australia ( Bruce McIntosh)
  • Summary:

    Name: Bruce McIntosh
    Company: Boeing Australia
    mailFrom: bruce.mcintosh@boeing.com
    Notification: Yes
    Specification: C++ Language Mapping
    Section: 1.36.2
    FormalNumber: ptc/01-06-07
    Version: Proposed Available Revision
    RevisionDate: 01/26/2002
    Page: 1-136
    The example given has a couple of small typographical problems: (1) the function signature specifies a void return type, but returns a Foo* (2) the function returns "foo_servant->this;" which I think should be "return foo_servant->_this();"

    Perhaps the example should read:

    Foo* some_function (/.../)

    { Servant_var<Foo_impl> foo_servant = new Foo_impl; foo_servant->do_something(); // might throw... some_poa->activate_object_with_id(...); return foo_servant->_this(); }
  • Reported: CPP 1.0 — Sun, 30 Jun 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Updated the example code as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocbuf() for bounded sequences?

  • Key: CPP11-120
  • Legacy Issue Number: 3110
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    What should allocbuf() for a bounded sequence return if I ask for more
    elements than the sequence bound? The spec doesn't say. I think it should
    return null in this case.

    Also, what should allocbuf() return if I ask for zero elements?

  • Reported: CPP 1.0 — Sat, 11 Dec 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed::round and truncate issue

  • Key: CPP11-110
  • Legacy Issue Number: 2950
  • Status: closed  
  • Source: Progress Software ( Steve Vinoski)
  • Summary:

    The Fixed::round() and Fixed::truncate() functions do not mention what to
    do if their scale argument is larger than the current scale. I figure they
    shouldn't do anything – for example, "truncating" by making something have
    more digits doesn't seem to make sense. I propose adding the sentence below
    after the sentence reading "The round and truncate functions convert a
    fixed value to a new value with the specified scale." (page 23-32 of
    ptc/99-03-04):

    If the new scale is equal to or larger than the new scale, no rounding or
    truncation is performed and the result is equal to the target object.

  • Reported: CPP 1.0 — Wed, 29 Sep 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ORB interface destroy() operation issue

  • Key: CPP13-72
  • Legacy Issue Number: 4567
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The ORB interface destroy() operation defined in the core CORBA 2.3 spec seems to be missing from the associated C++ language mapping.

  • Reported: CPP 1.1 — Fri, 14 Sep 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the destroy operation to the ORB definition in 4.35.1 and 4.45.21

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_ptr_type and _var_type typedefs

  • Key: CPP13-71
  • Legacy Issue Number: 1794
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We recently added _ptr_type and _var_type typedefs into interface classes
    to make writing templates for interface types easier. We should add the
    same typedefs for valuetype classes.

  • Reported: CPP 1.0b1 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the missing typedefs

  • Updated: Fri, 6 Mar 2015 20:58 GMT

make it possible to write more generic C++ code

  • Key: CPP13-76
  • Legacy Issue Number: 14169
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec defines: // C++ class Seq_var; class Seq

    { public: typedef Seq_var _var_type; // ... }

    ; We propose to extend this to the following to make it possible to write more generic C++ code. // C++ class Seq_var; class Seq_out; class Seq

    { public: typedef Seq_var _var_type; typedef Seq_out _out_type: typedef ::CORBA::ULong _size_type; // ... }

    ;

  • Reported: CPP 1.2 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    In section 4.11 add to the example at the end Seq_out and a _out_type typedef
    as in the revised text below.
    The _size_type typedef will make it possible in the user code to differentiate
    between the index of a sequence type and a user defined ULong value. To
    section 4.15 add the sentence
    To facilitate template-based programming, a nested public typedef _size_type is delivered as the type
    representing the length of the sequence.
    And to the sequence class examples in section 4.15 the following
    typedef ULong _size_type;

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Servant_var + spec typo?

  • Key: CPP13-75
  • Legacy Issue Number: 12913
  • Status: closed  
  • Source: lmco.com ( Abdullah Sowayan)
  • Summary:

    I was looking at the OMG IDL to C++ mapping specification, specifically
    page 123 and came across the below. It looks to me that their
    implementation in the spec is NOT correct. Shouldn't the swap function
    take the "tmp" Servant_var?

    Servant_var& operator=(Servant* p)
    {
    if (_ptr != p)

    { Servant_var<Servant> tmp = p; swap(_ptr, p); }

    return *this;
    }

    Servant_var&
    operator=(const Servant_var& b)
    {
    if (_ptr != b._ptr)

    { Servant_var<Servant> tmp = b; swap(_ptr, b._ptr); }

    return *this;
    }

  • Reported: CPP 1.2 — Mon, 6 Oct 2008 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Update assignment operator as proposed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

valuetype classes should add _out_type typedef

  • Key: CPP13-79
  • Legacy Issue Number: 16356
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    To really support template meta programming the valuetype classes should deliver a typedef _out_type besides the _ptr_type and _var_type which are proposed to be added as part of issue 1794

  • Reported: CPP 1.2 — Thu, 7 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add a _out_type typedef to the valuetype class

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface should add _out_type typedef

  • Key: CPP13-78
  • Legacy Issue Number: 16355
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    To really support template meta programming the inteface should deliver a typedef _out_type besides the already defined _ptr_type and _var_type

  • Reported: CPP 1.2 — Thu, 7 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add a _out_type typedef to the interface class

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ keywords should be updated

  • Key: CPP13-77
  • Legacy Issue Number: 16283
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The C++ keywords in section 4.47 should be updated and extended with the addition of C++0x

  • Reported: CPP 1.2 — Fri, 27 May 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Add the following keywords to the table on page 154 as part of section 4.47

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 4.5.4: parameter to _narrow

  • Key: CPP13-74
  • Legacy Issue Number: 12856
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In section 4.5.4 it says: Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be widened to the requested interface’s type, then _narrow will return a valid object reference; it should say (widened to narrowed) Unlike _duplicate, the parameter to _narrow is a reference of an object of any interface type (Object_ptr). If the actual (runtime) type of the parameter object can be narrowed to the requested interface’s type, then _narrow will return a valid object reference;

  • Reported: CPP 1.2 — Thu, 18 Sep 2008 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    In section 4.5.4 change widened to narrowed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Context PIDL mapping bug

  • Key: CPP13-73
  • Legacy Issue Number: 4743
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Section 1.31.3 says:

    • In the C mapping, set_one_value used strings, while
      others used NamedValues containg any. Even though implementations
      need only support strings as values, the signatures now uniformly
      allow alternatives.

    I would suggest to delete the entire bullet point. In particular, the notion
    of allowing alternative data types as propery values for contexts doesn't
    work because the receiver expects a sequence of strings with an even number
    of elements; if anything but a string sequence is sent, the receiver
    has no chance of unmarshaling it.

  • Reported: CPP 1.1 — Tue, 11 Dec 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Remove bullet as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_policy should return Policy, not Policy_ptr

  • Key: CPP13-80
  • Legacy Issue Number: 16358
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The Object::get_policy returns a Policy in IDL, not a Policy_ptr, that is the C++ return value

  • Reported: CPP 1.2 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — CPP 1.3
  • Disposition Summary:

    Replace in 4.36.1 the text Policy_ptr to Policy

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operator>> for String_var

  • Key: CPP11-97
  • Legacy Issue Number: 2619
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping says:

    A compliant mapping implementation shall provide overloaded operator<<
    (insertion) and operator>> (extraction) operators for using String_var
    and
    String_out directly with C++ iostreams.

    >From this definition it"s no clear whether operator>> allocates memory
    or not. That is, is the following code correct?

    CORBA::String_var str;
    cin >> str;

  • Reported: CPP 1.0 — Wed, 21 Apr 1999 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes and _out classes in C++ mapping

  • Key: CPP11-96
  • Legacy Issue Number: 2564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I"m trying to work out how valuetypes interact with My question is what should the two reference counts be, and why?
    >From my understanding, myVal"s reference count should be 1, and myPtr"s
    reference count should be 0.

    Is this correct? Perhaps an example _out type for valuetypes should be
    included in the spec to clear this up for future reference.

  • Reported: CPP 1.0 — Wed, 31 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

generate concrete classes and factories for valuetypes without initializer

  • Key: CPP11-89
  • Legacy Issue Number: 2496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggestion: generate concrete classes and factories
    for valuetypes that do not have any initializers. If a
    value type does not have any initializers, it should
    be safe to use the default constructor for all members.

    This would reduce the size of the code that needs
    to be written by the application programmer.

    Similarly, concrete factories could be generated for
    value boxes

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

add a _var type for each servant type

  • Key: CPP11-88
  • Legacy Issue Number: 2445
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: full_desc: The C++ mapping for CORBA 2.3 introduces reference
    counting on servants and provides the
    PortableServer::ServantBase_var class for automated
    reference counting. However, this class can not be
    used if a more specific type of the servant is needed.
    Proposal: add a _var type for each servant type, for
    example POA_FooBar_var.

  • Reported: CPP 1.0b1 — Tue, 9 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

tie doesn"t do ref counting

  • Key: CPP11-87
  • Legacy Issue Number: 2441
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: After all the recently past work getting servant reference counting, it
    just occurred to me that this doesn"t work with TIE. Or am I missing
    something?

    As things stand, to make it work it is necessary to derive a new class
    from both the instantiated tie template and RefCountServantBase. This
    then requires all the constructors to be redefined - ugh!

  • Reported: CPP 1.0b1 — Fri, 5 Feb 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    See resolution for issue 4114, which addresses this issue as well.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Misleading text for DSI invoke() and _primary_interface()

  • Key: CPP11-86
  • Legacy Issue Number: 2357
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.38.3 of the CORBA 2.3 draft states:
    I believe that the intent of this paragraph is to forbid the user from
    calling invoke() and _primary_interface() directly, not to forbid the
    POA from calling _primary_interface() in circumstances other than
    processing a request.

    The paragraph should be reworded to say:

    "The invoke() and _primary_interface() methods will be called by the
    POA, and should never be explicitly called by the application."

  • Reported: CPP 1.0b1 — Fri, 29 Jan 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetypes and arbitrary graphs

  • Key: CPP11-95
  • Legacy Issue Number: 2561
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Valuetypes can be used to form arbitrary, potentially circular graphs.
    This means that reference counts may never drop to zero and that more
    advanced garbage collection is required, which does not come natural to
    C++.

    An ORB may keep track of circularity by traversing a graph and can detect
    if the last outside reference is lost. However, the overhead is significant,
    and the solution would be incomplete, as users need not use "proper" refe-
    rence counting on graph nodes by ignoring both OBV_* classes and default
    reference counting.

    Possible solution: restrict CORBA::DefaultValueRefCountBase to
    non-circular graphs. Users can decide much better when a graph is safe
    to be cleaned up.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as duplicate of 2309.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Factories for StringValue and WStringValue

  • Key: CPP11-94
  • Legacy Issue Number: 2560
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for Objects by Value requires factories for marshalling
    valuetypes. Therefore, it needs to specify default factories for the
    standard StringValue and WStringValue types.

  • Reported: CPP 1.0 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Valueboxes do not have factories.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_primary_interface

  • Key: CPP11-84
  • Legacy Issue Number: 2029
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: From the C++ spec (CORBA2_3-c++.pdf) pg: 20-132

    For static skeletons, the default implementation of the _get_interface
    and _is_a functions provided by ServantBase use the interface associated
    with the skeleton class to determine their respective return values. For
    dynamic skeletons (see Section 20.37), these functions use the
    _primary_interface function to determine their return values.

    Does this mean that a dynamic implementation needs the IFR?
    If not, then how can _is_a be implemented for sub-types?

    I note that the java mapping includes the method _all_interfaces in Servant
    for precisely this reason...

  • Reported: CPP 1.0b1 — Fri, 2 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The C++ mapping for valuetype _narrow should not _add_ref

  • Key: CPP11-83
  • Legacy Issue Number: 2002
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C++ mapping for valuetype includes a typesafe _narrow generated
    for all values. The specification states that the caller
    of _narrow must invoke _remove_ref once on the returned value
    from _narrow (just like object reference _narrow).
    f

  • Reported: CPP 1.0b1 — Sun, 27 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Valuetype argument passing

  • Key: CPP11-92
  • Legacy Issue Number: 2523
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The passing of valuetypes as parameter to operations needs more
    consideration. Section 20.22 of ptc/98-09-03 (98/11/06) specifies
    that the callee should receive a deep-copy of each valuetype to
    preserve location transparently.

    Now, does this apply only to operations of interfaces, or also to
    valuetype operations? With the current phrasing, this applies just
    the same (meaning that valuetype operations also receive a deep-
    copy). And then there are abstract interfaces, which may incarnate
    a remote interface or a local valuetype.

  • Reported: CPP 1.0 — Tue, 9 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The specification is already clear about valuetype argument passing semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add AbstractBase base type to IDL language?

  • Key: CPP11-91
  • Legacy Issue Number: 2499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Does it make sense to add the AbstractBase base
    type to the IDL language, so that operations could
    receive an AbstractBase parameter?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

narrow abstract interface class to concrete object?

  • Key: CPP11-90
  • Legacy Issue Number: 2498
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should it be possible to narrow an abstract interface
    class to a concrete Object, or to downcast it to a
    Valuetype?

  • Reported: CPP 1.0b1 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Sequences and get_buffer()

  • Key: CPP11-93
  • Legacy Issue Number: 2530
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This is a new issue for the C++ RTF.

    The mapping for sequences mandates a get_buffer() accessor for read/write
    access to the members of the sequence. It is mentioned that an implemen-
    tation is not required to store sequence elements in continuous memory
    for efficiency reasons, but may choose to do so only when get_buffer()
    is called.

    However, this introduces coherency problems if sequence elements are
    accessed and modified using both get_buffer() and operator[].

    get_buffer() is not possible for recursive sequences anyway.

  • Reported: CPP 1.0 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misread the specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sequence allocbuf parameter != 0

  • Key: CPP11-82
  • Legacy Issue Number: 1946
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sequence allocbuf functions should be specified such that passing zero for
    their arguments is illegal. Allocating a sequence buffer of zero elements
    is rather pointless because nothing useful can be done with such a buffer.
    The result of passing zero to allocbuf should be implementation-defined,
    since throwing an exception is not a good way to handle programming logic
    errors (similar to how indexing past the end of a sequence is a logic error
    for which an exception is pretty useless).

  • Reported: CPP 1.0b1 — Sun, 13 Sep 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Discussion of this issue determined that a zero parameter to allocbuf is legal and

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Any missing LongLong operators, etc?

  • Key: CPP11-85
  • Legacy Issue Number: 2118
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the latest spec (98-09-03) the Any class appears to be missing
    insertion extraction operators for LongLong, ULongLong, etc.

  • Reported: CPP 1.0b1 — Thu, 22 Oct 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Exception id for each exception type

  • Key: CPP11-43
  • Legacy Issue Number: 260
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping should make available the exception id for each exception type.. Sun would like to revise sec. 3.17 to add following function: static const char * _exception_id();

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessor for exception id

  • Key: CPP11-42
  • Legacy Issue Number: 259
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The base exception class should include an accessor to get the exception id of an exception.It"s obtained from environment.Ability to get exception id is desirable in C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

operator<< for ostreams and Exceptions

  • Key: CPP11-47
  • Legacy Issue Number: 266
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Exceptions could be formatted onto ostreams using operator<<..Examples available on /archives/issues/issue266

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ semantics vs. IDL semantics

  • Key: CPP11-49
  • Legacy Issue Number: 268
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Isn"t it the mappings responsibility to decide how to project the semantics to the underlying "wire rep". You don"t need to put NULL on the wire. Sec 16.18 Pg 16-46 para 11 CORBA2.0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ANy release flag and operator

  • Key: CPP11-48
  • Legacy Issue Number: 267
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.16.2 para 11 describes lifetime of inserted value. Since lifetime of the value is independent of value passed to operator<<=, Any must contain a copy of value.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Legal IDL cannot map to C++

  • Key: CPP11-53
  • Legacy Issue Number: 497
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Generated C++ (example) ends up with redefinition errors. This is not addressed in current C++ mapping. Options are to amend IDL or to simply state that such IDL cannot be translated.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Double underscore identifier mapping

  • Key: CPP11-52
  • Legacy Issue Number: 496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: identifiers containing a double underscore[..] are reserved for use by C++ implementations and standard libraries and shall be avoided by users. IDL could be amended to prohibit double undersc.

  • Reported: CPP 1.0b1 — Wed, 5 Feb 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

make String_var reference but not adopt

  • Key: CPP11-46
  • Legacy Issue Number: 264
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: String_var could refer to memory without assuming memory management responsibilities for it, like void String_var::value(const char*, Boolean release = 0

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

buffer classes for sequences

  • Key: CPP11-45
  • Legacy Issue Number: 263
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: p41,sec 3.13.3,para 24: These functions should return buffers, not T* If you wanted a T* provide a conversion on returned buffer. No need to lock down implementation in this manner

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

u++ binding for ServerRequest pseudo object

  • Key: CPP11-50
  • Legacy Issue Number: 290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Class defined for ServerRequest shows op_def() operation. Seems not to be in IDL for ServerRequest and there is no description in the rest of the section (CORBA 2 spec, Sect. 18.4.1)

  • Reported: CPP 1.0b1 — Thu, 24 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

[q] intf name == op name

  • Key: CPP11-51
  • Legacy Issue Number: 481
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sentence in IDL spec "An identifier can only be defined once in a scope.However,identifiers can be redifined in nested scopes" seems to allow interface Foo

    { void Foo(in long 1); }

    ;

  • Reported: CPP 1.0b1 — Wed, 22 Jan 1997 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode for each basic and IDL defined types

  • Key: CPP11-44
  • Legacy Issue Number: 261
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 4.10 para 2: pseudo object reference of form tc<type> made available for basic and IDL defined types. Sun wants replacements with global function of form TypeCode_ptr tc<type>

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Accessors for the Any release flag

  • Key: CPP11-41
  • Legacy Issue Number: 258
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sun would like to add the following accessors to Any: Boolean release(); void release(Boolean);

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Constructor taking discriminant as argument

  • Key: CPP11-40
  • Legacy Issue Number: 255
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.12 para1 describes union constructors.Sun would like to add new constructor that takes as its sole argument a discriminant value.It initializes union according to specified discr. value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Name field for SystemExceptions

  • Key: CPP11-39
  • Legacy Issue Number: 253
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException class should contain a string name field for easy printing of error messages,or operator<< should be overloaded for each system exception

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union accessors

  • Key: CPP11-31
  • Legacy Issue Number: 231
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Accessors that return a reference to a non-const object can be used for read-write access. They are provided only for following types: struct, union, sequence, any.Provede for all types..

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

callee-allocated storage modification

  • Key: CPP11-30
  • Legacy Issue Number: 228
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Sec 16.18 Pg 16-45 para 9 The caller has sufficient knowledge to release, but not sufficient knowledge to know if contiguous. ("to allow..we adopt the policy....")

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

accessor members for structs

  • Key: CPP11-37
  • Legacy Issue Number: 245
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Struct Mapping: IONA that accessor functions be provided for struct members. Direct access to member variables still available. Enhancement affords the user a consistent interface.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Closed with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

allocbuf and initialization of elements

  • Key: CPP11-36
  • Legacy Issue Number: 241
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 3.13.2 para 25describes allocbuf. Sun prefers that allocated sequence elements be initialized as if vector were allocated by sequence constructor

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allocated storage for out and return strings

  • Key: CPP11-34
  • Legacy Issue Number: 237
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.6 Pg 16-11 CORBA2.0: Sec D.12 states that client stub allocates buffer of specified size for bounded strings.This may result in unnecessary memory consumption.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

accessor function on SystemException

  • Key: CPP11-33
  • Legacy Issue Number: 234
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: SystemException has accessor functions minor() and completed() rather than public data members like exceptions normally do. Normal mapping is to make exception data into public data members

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

void* from Any for constructed types

  • Key: CPP11-28
  • Legacy Issue Number: 226
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: tables not present in CORBA2.0 What about structs, unions, exceptions, and arrays?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

handling void* from Any

  • Key: CPP11-27
  • Legacy Issue Number: 225
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.14.6 Pg 16-38 para 44 CORBA2.0 How are you supposed to delete/duplicate this void* value if you don"t know the type? Do we have to emulate a C++ compiler

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping for IDL context

  • Key: CPP11-32
  • Legacy Issue Number: 232
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If operation in an IDL spec. has a context spec, then a Context_ptr input parameter follows all operation specific arguments (OMGD 3.19) It should map to const Context_ptr

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Object references are always passed as a plain _ptr parameter and never as a c

  • Updated: Fri, 6 Mar 2015 20:58 GMT

union accessors require temporaries

  • Key: CPP11-38
  • Legacy Issue Number: 250
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For structs and exceptions: Unions" access functions return primitives by value, not by refs.I need to use temporaries.Change them to refs

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

anonymus types

  • Key: CPP11-29
  • Legacy Issue Number: 227
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Tables not present in CORBA2.0 Aren"t anonymus sequences still allowed in structs, union, and exception?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ namespaces

  • Key: CPP11-35
  • Legacy Issue Number: 238
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Namespaces available/not available

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple inheritance of C++ Servants is ill-defined

  • Key: CPP11-63
  • Legacy Issue Number: 674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Please find example/discussion in corresponding archive file

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed and resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Blocking semantics of get_next_response not well specified

  • Key: CPP11-59
  • Legacy Issue Number: 646
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of get_next_response sec 4.3.4 are not well-defined with respect to blocking behavior. There is no explicit description of the behavior of the C++ routines

  • Reported: CPP 1.0b1 — Thu, 31 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 16.2, Section 16.6: editorial

  • Key: CPP11-58
  • Legacy Issue Number: 622
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 16.2: "A shown" should be "As shown". Section 16.6: The title is incorrect "TMapping" remove the "T"

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. A search through the current draft does not locate either of the two typos mentioned

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No conversion defined from a B_var to an A_ptr

  • Key: CPP11-67
  • Legacy Issue Number: 956
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I was writing some C++ code and noticed that the following doesn"t work:

    // IDL

    interface A {
    };

    interface B : A {
    };

    // C++

    B_var bv = get_b_from_somewhere();
    A_var av = A::_duplicate(bv);

    because there is no conversion defined from a B_var to an A_ptr. Is
    there a way that this could be added to the language binding without
    ambiguity problems?

  • Reported: CPP 1.0b1 — Wed, 11 Feb 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ServantBase mappings

  • Key: CPP11-66
  • Legacy Issue Number: 920
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the C++ mapping for ServantBase also have _duplicate,
    _var mappings ? For example if get_servant is called on POA, what
    are the ownership rules for the returned Servant. It seems providing
    a _duplicate, _release operations on ServantBase might be useful. These
    operations could be used to ensure that the Servant is not released
    while the caller has a reference to it.

  • Reported: CPP 1.0b1 — Tue, 27 Jan 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed in ptc/1998-09-03

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping of servants may result in ambigous run-time behavior

  • Key: CPP11-62
  • Legacy Issue Number: 673
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If the same servant and ObjectId are registered with two POAs, _this() can"t know which object to return outside of a method invokation

  • Reported: CPP 1.0b1 — Mon, 11 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation problem with policy objects using root POA

  • Key: CPP11-61
  • Legacy Issue Number: 663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears to be impossible to implement the policy objects using the root POA due to race conditions on the Polilicy::destroy() operation. There appears to be no safe time to delete servant

  • Reported: CPP 1.0b1 — Sat, 9 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface definition must be standardized

  • Key: CPP11-56
  • Legacy Issue Number: 608
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL for Object Interface differs from that provided by core specification in section 7.2 page 7.2

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The relevant functions are shown in the latest C++ mapping.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

String_var and Any_var are missing the T_ptr definition

  • Key: CPP11-55
  • Legacy Issue Number: 600
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Appendix E page E-2 and E-3: String_var and Any_var classes are missing T_ptr definition that occurs in the template for var types. These should be added for completness.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. Only object reference types have _ptr type. They do not apply to strings or ty

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C and C++ Mapping question

  • Key: CPP11-65
  • Legacy Issue Number: 705
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL spec states that identifiers can have characters that are things like an A with accent aigu, or a german script B. Can IDL identifiers have these characters? How are they mapped ontoC/C++?

  • Reported: CPP 1.0b1 — Sat, 23 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as non-issue. IDL no longer permits non-ASCII letters in identifiers.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

inout strings modifiable?

  • Key: CPP11-64
  • Legacy Issue Number: 678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping spec should be clearer about the rules for inout strings.There are currently two possible interpretations of what server can do with an inout string (details in archive)

  • Reported: CPP 1.0b1 — Mon, 18 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolverd and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

sec. 18.1.2: explicit information on _this() is missing

  • Key: CPP11-60
  • Legacy Issue Number: 653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The discussion of how _this() operates is missing explicit information about what to do if there is no request context. Should _this() return nil reference, or should exception be thrown

  • Reported: CPP 1.0b1 — Tue, 5 Aug 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL from Ennvironment has invalid attribute

  • Key: CPP11-57
  • Legacy Issue Number: 618
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IDL from Environment has an attribute called "exception" which is invalid. This member should be renammed to "ex"or some other name which is a legal identifier

  • Reported: CPP 1.0b1 — Mon, 14 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Environment is defined as PIDL, so this is legal.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

const method qualification should be removed

  • Key: CPP11-54
  • Legacy Issue Number: 599
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C++ mapping for pseudo request class contains const member functions mapped from readonly attributes. IDL does not define C++ mapping for readonly attribs to const member functions.

  • Reported: CPP 1.0b1 — Wed, 9 Jul 1997 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Storage ownership issue

  • Key: CPP11-25
  • Legacy Issue Number: 223
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA2.0 Care must be taken to avoid using T_var types with these extraction operators. They will try to assume responsibility for deleting storage owned by Any. Problem in mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. That's how the mapping was designed to work.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Global functions vs. T_var namespace

  • Key: CPP11-24
  • Legacy Issue Number: 222
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-28 CORBA2.0 p. 44, sec 3.14 para 8: Why are these global functions rather than static methods of T_var?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Array slice example

  • Key: CPP11-22
  • Legacy Issue Number: 219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.12 Pg 16-27 CORBA 2.0 Why is a Long Array_slice declared to be a typedef Long[]? Why are these locked down rather than allowing a slice to be a class?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved/closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of sequence length() operation

  • Key: CPP11-21
  • Legacy Issue Number: 218
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11 Pg 16-23 CORBA2.0 What is the semantics of the length() member? When can I do reallocation? Can it truncate? Can it realloc if length== current size?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implementation description

  • Key: CPP11-17
  • Legacy Issue Number: 206
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.9 Pg 16-15 CORBA2.0 p.32, Section 3.11 para 4: Seems to describe an implementation. Why is it specified. Is this how Sec. 3.10.1 para 14 issue is supposed to be addressed?

  • Reported: CPP 1.0b1 — Fri, 11 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Detection of initialization of T_var

  • Key: CPP11-16
  • Legacy Issue Number: 203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.8.1 Pg 16-14 CORBA2.0] p.31, Section 3.10.1 para 12: How do I know if the T_var I"ve been passed (in C++) has been initialized?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

example incorrect?

  • Key: CPP11-14
  • Legacy Issue Number: 201
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.8 Pg 16-13 CORBA2.0 p. 29, Section 3.10 example para 4. : This example looks incorrect. Example shown in 3.10.1 is inconsistent with the code in paragraph 4.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Levels of portability conformance requested

  • Key: CPP11-13
  • Legacy Issue Number: 199
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 15.1.1 Pg 15-1 CORBA2.0 "Conforming client or server program is portable across all conforming implementations" We object the word "portable"being used in this context.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Copying of out parameters

  • Key: CPP11-20
  • Legacy Issue Number: 217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-25 CORBA2.0 p.41, section 3.13.2 para 21 Do I have to make an application level full copy? This doesn"t meet the performance goal outlined in the beginning

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C vs. C++ coding style

  • Key: CPP11-19
  • Legacy Issue Number: 215
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec 16.11.2 Pg 16-24 CORBA2.0 p. 40 Section 3.13.2, para 17 Looks like C, not C++

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Autoextension of sequences

  • Key: CPP11-18
  • Legacy Issue Number: 208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Sec 16.11 Pg 16-21 CORBA2.0 Since autoextension is not apparently supported, you should change "may" to "must"

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pointers vs. values

  • Key: CPP11-26
  • Legacy Issue Number: 224
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sec. 16.14.3 Pg 16-34 para 30 CORBA2.0 p.48, sec 3.16.3, para 26 Why is this specified. Why are pointers treated differently from Values. Primitives are not set to NULL

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. It is no longer possible to identify the document to which the question refers

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Assignment to T_var

  • Key: CPP11-15
  • Legacy Issue Number: 202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What happens if i assign a container of data I hold Does aliasing allow in more than simple temporary. Is there a restriction that there can be NO overlapping?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. We do not have enough context to determine what the issue is.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Array_forany

  • Key: CPP11-23
  • Legacy Issue Number: 221
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Do you anticipate end user"s instantiating the Array_forany class? Isn"t this a implementation detail? The name conflicts with IDL specifiable. Section should be removed.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Problems with deactivate_object()

  • Key: CPP11-76
  • Legacy Issue Number: 1627
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The POA does not properly define the behavior of POA operations
    for requests that are currently executing in an object that
    has been deactivated.

  • Reported: CPP 1.0b1 — Thu, 2 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do POA servant classes need to use virtual inheritance?

  • Key: CPP11-75
  • Legacy Issue Number: 1535
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec is silent on whether POA servant classes need to use
    virtual inheritence when an IDL class inherits from the same base
    interface more than once:

    // IDL
    interface A

    { void op(); }

    ;
    interface B : A { };
    interface C : A { };
    value D : supports B, C { };

    Must POA_B & POA_C inherit virtually from POA_A or can defined
    independently with all of interface A"s operations? This makes a big
    difference for values that support interfaces, since, for example, value
    D is defined by the C++ language mapping to inherit from both POA_B and
    POA_C. So, does value D inherit one or two versions of A::op()?

  • Reported: CPP 1.0b1 — Thu, 18 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spec does not mention the existance of an Any_out class

  • Key: CPP11-73
  • Legacy Issue Number: 1520
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The spec does not explicitly mention the existence of an Any_out
    class. I believe that this class is necessary, following the same
    pattern as the normal T_out class for variable length structured types.

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_var & _out types problems (01)

  • Key: CPP11-72
  • Legacy Issue Number: 1519
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1. The spec insection 20.9.2 does not specifically address the form of
    T_out types for fixed length structured types. So, should the T_out
    type be:

    typedef T &T_out;

    or should it follow the form of the T_out type for variable length
    structured types and define as a "class T_out"? In this case, of course
    the copy contructor operator from T_var would not delete the pointer
    held by the T_var.

    Since the "class T_out" solution for fixed length types does not appear
    to have any advantages over the typedef, I recommend that the spec be
    modified to state that T_out types for fixed length structured types
    simply be a typedef of "T&".

  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Spec is too verse in defining the T_var types for fixed length

  • Key: CPP11-74
  • Legacy Issue Number: 1521
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. The spec is too terse in defining the T_var types for fixed length
    structured types as having "the same semantics as T_var types for
    variable-length types." This is not quite true, since the signatures
    for out and return values of these types are different, thus changing
    the semantics of the implicit and explicit (out() and _retn())
    conversion operations. The spec should show the definition of the out()
    and _retn() operations for fixed length types as:

    T &T_var::out()

    { return ptr_; }

    T &T_var::_retn()
    { return ptr_; }
  • Reported: CPP 1.0b1 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing Fixed to operations

  • Key: CPP11-81
  • Legacy Issue Number: 1785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: // IDL
    typedef fixed<4,2> F;

    interface foo

    { void op(in F param); }

    ;

    What should happen if at run time, I do the following?

    F myf = "12345.678D";

    foo_var fv = ...;
    fv->op(myf); // ???

    I think the operation should raise BAD_PARAM, because silent truncation
    is too dangerous. Note that the operation cannot send a fixed<8,3> because
    the operation expects a fixed<4,2> and will get a marshalling error if
    what arrives over the wire does not match the IDL definition.

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Comparison operators for Fixed

  • Key: CPP11-80
  • Legacy Issue Number: 1783
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The fixed mapping in 98-07-12 shows:

    Fixed operator > (const Fixed &val1, const Fixed& val2);
    Fixed operator < (const Fixed &val1, const Fixed& val2);
    Fixed operator >= (const Fixed &val1, const Fixed& val2);
    Fixed operator <= (const Fixed &val1, const Fixed& val2);
    Fixed operator != (const Fixed &val1, const Fixed& val2);
    Fixed operator == (const Fixed &val1, const Fixed& val2);

    I"m surprised at the return type – shouldn"t that be bool for ANSI
    compilers and int for non-ANSI compilers?

  • Reported: CPP 1.0b1 — Fri, 7 Aug 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ Sequence mapping Question

  • Key: CPP11-70
  • Legacy Issue Number: 1134
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 20.13 states:

    "For each different named OMG IDL sequence type, a compliant
    implementation provides a separate C++ sequence type."

    This certainly means that each declared sequence with a different bound
    and component type maps to a unique C++ class. But how about this:

    // IDL
    typedef sequence<long> LongSeq1;
    typedef sequence<long> LongSeq2;

    Are LongSeq1 & LongSeq2 mapped to the same or different C++ classes?

  • Reported: CPP 1.0b1 — Tue, 7 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode_ptr base_typecode(TypeCode_ptr tc)

  • Key: CPP11-69
  • Legacy Issue Number: 1115
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Look at this code and tell me what is wrong with it (CORBA:: left off
    for simplicity):
    So, now the question is: Inside the
    TypeCode_var::operator=(TypeCode_ptr tc)
    assignment operator, when tc == this, what should happen?

    Should this call release(this) to satisfy the requirements of code frag
    #3? Or should it be a noop to satisfy the requirements of code frag #4?

  • Reported: CPP 1.0b1 — Mon, 6 Apr 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. The submitter of the issue misunderstood _var reference counting semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parameter passing rules for ValueFactory

  • Key: CPP11-79
  • Legacy Issue Number: 1658
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Since it is a native, the parameter passing rules for ValueFactory
    must be specified so the register/unregister/lookup operations
    can be mapped.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ language mapping minor editorial revision

  • Key: CPP11-78
  • Legacy Issue Number: 1656
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are a few minor editorial mistakes in the C++ language
    mapping examples. These are included in this single issue for
    brevity.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for fixed is broken (02)

  • Key: CPP11-68
  • Legacy Issue Number: 1093
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. The mapping for the "_out" type for Fixed is broken. It is
    specified as a typedef, for example "Fixed<3,1>" maps to:

    typedef Fixed<3,1> &Fixed_3_1_out;

    but the IDL grammar allows fixed types to be declared as attribute
    types, operation parameters and return values. This causes problems
    because it is no longer obvious where to declare the _out type for an
    out parameter.

  • Reported: CPP 1.0b1 — Sat, 21 Mar 1998 05:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close as fixed. The new Fixed mapping takes care of this.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing operators in orbos/98-01-11

  • Key: CPP11-71
  • Legacy Issue Number: 1383
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the Any class shown on page 20-115 of 98-01-11 appears to be missing
    support for some of the new IDL types. In particular, no operators
    are shown for (unsigned and signed) long long and long double.

    Also, there is no operator to insert an unbounded wide string.

  • Reported: CPP 1.0b1 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.3.6.3 Value Factories

  • Key: CPP11-77
  • Legacy Issue Number: 1655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The last paragraph of section 5.3.6.3 says the standard language mapping
    rules are followed when determining these operation signatures. Since
    one of the arguments/return values is a Native, this isn"t quite
    possible.

  • Reported: CPP 1.0b1 — Thu, 9 Jul 1998 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Already resolved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fixed structs

  • Key: CPP11-2
  • Legacy Issue Number: 123
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the ORB hide the difference between fixed and variable length structs from the application developer?

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent interfaces for the operation pairs *duplicate* and

  • Key: CPP11-5
  • Legacy Issue Number: 186
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The operations duplicate and release work together to provide memory mgmt. functionallity. It"s desirable to use both via similar interface/syntax. nil/is_nil similar problem

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    close with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Testing exceptions

  • Key: CPP11-4
  • Legacy Issue Number: 143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the DII, testing what variety of exception is stored in the Request Pseudo-object requires a sequence of dynamic_cast<> or (_narrow) calls. It would be useful to have a single call.

  • Reported: CPP 1.0b1 — Tue, 1 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    closed/resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Pseudo objects for DSI

  • Key: CPP11-8
  • Legacy Issue Number: 193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [Ch 17 CORBA2.0] Sun would like section 4 to include the interface for the dynamic server invocation

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This issue is already addressed in the CORBA 2.3 specification.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Identifier conflicts resulting from the language mapping

  • Key: CPP11-7
  • Legacy Issue Number: 192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.1 para 4 specifies the rule for resolving identifier conflicts with C++ keywords. A similar rule is required to resolve name conflicts resulting from the mapping.

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close 192 with no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TypeCode/Value mismatch in ANY

  • Key: CPP11-11
  • Legacy Issue Number: 197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: What happens if the typecode & value for the unsafe Any operations do not match?

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

illegal union access when discriminator is wrong

  • Key: CPP11-10
  • Legacy Issue Number: 196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: illegal access of union member accessor functions when the discriminator has the wrong value

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Passing of object reference in pointers

  • Key: CPP11-3
  • Legacy Issue Number: 125
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Suggest changing the mapping so that object references for an interface "T" are passed as "const T_ptr&" instead of just "T_ptr" for "in" parameters.

  • Reported: CPP 1.0b1 — Mon, 23 Sep 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of void* returned from ANY

  • Key: CPP11-12
  • Legacy Issue Number: 198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: Implementation representation of the void * pointer returned by Any::value() for unknown types

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close with no change. The latest draft has already deprecated the void * member functions for type A

  • Updated: Fri, 6 Mar 2015 20:58 GMT

interface mapping

  • Key: CPP11-6
  • Legacy Issue Number: 188
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Mapping for Interface [16.3 CORBA2.0] Mapping example in 3.5.6 implements the ptr type as full pointer. A pointer could be implemented as a class

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. This change is too intrusive and would break too much existing code.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

_ptr member accessors for string and objref

  • Key: CPP11-9
  • Legacy Issue Number: 195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Implementation dependent: _ptr member accessors for strings & object references

  • Reported: CPP 1.0b1 — Mon, 14 Oct 1996 04:00 GMT
  • Disposition: Resolved — CPP 1.1
  • Disposition Summary:

    Close no change. Issue withdrawn by submitter.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Escaped keyword mapping?

  • Key: CPP12-9
  • Legacy Issue Number: 4498
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    the mapping says in section 1.1.2:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var" and "cxx_try_ptr,"
    ^^^^^^^^^^^
    that is, the IDL compiler behaves as if the interface were
    names "cxx_try" and then applies the normal mapping rules.
    ^ ^^^^^^^

    Four issues here:

    1) I think we have a typo at the first place I highlighed. I
    believe it should be "_cxx_try_ptr". (The leading underscore
    is missing in the text as it stands now.)

    2) Typo: It should be '...were named "cxx_try"', not
    '... were names "cxx_try"'

    3) To state that the compiler behaves is if the interface were
    named "cxx_try" doesn't explain where the additional leading
    underscore comes from because we get cxx, not cxx_
    for the mapped identifiers.

    Unfortunately, changing this sentence to state that the compiler
    behaves as if the interface were named "_cxx_try" won't fix
    it, because the leading underscore would be dropped by the
    IDL keyword escape mechanism.

    4) The explanations are insufficient:

    interface try {};

    This will result in "_cxx_try" as the interface name. But what
    about the generated tc type code constant? It could be:

    a) _cxx_tc_try

    This mapping would be consistent with the statement that
    the "cxx" is a prefix.

    b) cxx_tc_try

    Same as above but, given that, normally, the tc type code
    constants already start with an underscore, the escaped
    mapping results in a double underscore.

    c) _tc_cxx_try

    This mapping would be consistent with the directive to map
    as if the type were named "cxx_try".

    d) tc_cxx_try

    Same as above but preserves the underscore for both the
    "tc" and the "cxx", resulting in a double underscore.

    To me, interpretation (d) seems the most natural and intuitive because
    it preserves the leading "tc" for all type code constants (including ones
    for identifiers that are C++ keywords). Also, if the mapping of the type
    is to "_cxx_try", then it makes sense to have the double underscore because
    that is consistent and doesn't make an exception to the rule of "use
    "tc" for type code constants and "cxx" for IDL identifiers that are
    C++ keywords."

    Proposal:

    Rewrite the above para to read:

    To avoid C++ compilation problems, every use in OMG IDL of a
    C++ keyword as an identifier is mapped into the same name preceded
    by the prefix "cxx." For example, an IDL interface named "try"
    would be named "_cxx_try" when its name is mapped into C++.
    For consistency, this rule also applies to identifiers that
    are derived from IDL identifiers. For example, an IDL interface
    "try" generates the names "_cxx_try_var," "_cxx_try_ptr,"
    and "tc_cxx_try".

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    accept the suggested proposal

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Local interfaces issue 1

  • Key: CPP12-8
  • Legacy Issue Number: 4496
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    The current specification of the local mapping requires the
    implementation to enforce the "localness" of the object. This was very
    similar to the (old) java mapping. The inheritance heirarchy is as
    follows

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::Object

    MyLocalObjectImpl : MyLocalObject, CORBA::LocalObject

    The problem here is that there is no way for the ORB or the code
    generators to enforce the last inheritance. And I am not even sure how
    an ORB can detect the following case

    MyLocalObjectImpl : MyLocalObject

    which I suspect would be a very common error.

    Proposal:

    Fix the mapping to have the following heirarchy.

    CORBA::LocalObject : CORBA::Object

    abstract MyLocalObject : CORBA::LocalObject <===== Difference is here

    MyLocalObjectImpl : MyLocalObject <== and here

    Now an _is_a("IDL:omg.org/CORBA/LocalObject:1.0") is guaranteed to give
    a correct answer and it is enforced by the IDL compilers.

    This is also backward source compatible.

  • Reported: CPP 1.1 — Tue, 14 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see issue #4160 (the proposed resolution rejects this suggestion)

  • Updated: Fri, 6 Mar 2015 20:57 GMT

implementing local interfaces in C++

  • Key: CPP12-16
  • Legacy Issue Number: 5579
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    There seems to be only two choices:

    1. Accept that changing interfaces to local breaks old code that implemented
    POA interfaces using servants. Not wonderful, but I can live with it, since
    the source code changes are evident and fixed in a straightforward fashion.

    2. Try to come up with a scheme where local objects can be implemented either
    by using LocalObject or by the traditional servant route. This is more
    specification work, but cleaner, and I an live with it too.

    While we are at it, we should make sure that any other CORBA 3.0 changes are
    properly reflected in the C++ mapping as well.

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Initialized T_var?

  • Key: CPP12-15
  • Legacy Issue Number: 5578
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    a discussion in comp.object.corba pointed out the difficulty
    of testing whether a T_var has been initialized. There is
    no _is_null() member function or some such. As a result,
    calling operator->() appears to be the only way to test
    whether a T_var is initialized:

    if (T_var.operator->())
    // It's initialized...

    Not exactly elegant, but workable. However, the following
    words in the spec get in the way:

    "The overloaded operator-> returns the T* held by the T_var,
    but retains ownership of it. Compliant applications may not
    call this function unless the T_var has been initialized with a
    valid non-null T* or T_var."

    These words forbid me to call operator->() until after the
    T_var has been initialized, meaning that there is no portable
    and compliant way to test whether a T_var is nil. I think
    what was meant here is that

    "Compliant applications may not *dereference the return value
    of this function* unless the T_var has been initialized with a
    valid non-null T* or T_var."

    BTW – using operator->() to test for null is a bit obscure.
    We could add a _is_null() member to T_var for this. But,
    given the versioning confustion we'd cause and the fact
    that adding the member provides only marginal benefit,
    I think it may be better to leave things as they are. (But
    we should fix the description of operator->(), of course.)

  • Reported: CPP 1.1 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Missin operations in Object interface, ptc/01-06-07

  • Key: CPP12-14
  • Legacy Issue Number: 4871
  • Status: closed  
  • Source: seimet.de ( Uwe Seimet)
  • Summary:

    in ptc/01-06-07, 1.34.1, several operations seem to be missing in the Object
    interface, e. g.

    get_client_policy()
    get_policy_overrides()
    validate_connection()

    These are also missing in the Object C++ class, 1.34.2. create_request2() is
    also missing here.

  • Reported: CPP 1.1 — Wed, 27 Feb 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

String_var and C++ implicit conversions

  • Key: CPP12-19
  • Legacy Issue Number: 5807
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This e-mail addresses three CORBA C++ Revision Task Force issues:
    3796
    3797
    4530
    It also addresses section 6.10.2 of your book, "Advanced CORBA
    Programming with C++" ((C) 1999).

    Starting with 6.10.2 of your book, p. 164, you show an example where a
    CORBA::String_var is implicitly converted to 'const char *' in a
    function call, with the conversion operators as defined on p. 157 (sect.
    6.10).

    However, the C++ language won't choose the 'const char *() const'
    operator as you (and I) would think. Instead, since the String_var
    isn't const in the call's scope, the 'char *()' (i.e., non-const)
    operator is chosen.

    Aparently, the conversion path
    String_var -> char * -> const char *
    Is considered "better" than the conversion path we'd expect, namely
    String_var -> const String_var -> const char *

    Further, updating String_var with the resolutions of Issues 3796 and
    3797 (as found in http://cgi.omg.org/issues/cxx_revision.html), namely
    removing 'operator char *()' and adding 'operator char *&()' now leads
    to the conversion path
    String_var -> char *& -> const char *
    The 'const char *' operator is still bypassed, and with 'operator char
    *&()' in the picture, it seems trouble is more likely.

    For reference, take a look at the USENET newsgroup comp.std.c++, the
    thread of "Subject: Implicit conversion of g++", starting 2000/03/02 (I
    know that long URL's don't e-mail well, but...
    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=p6qr
    9dsxi04.fsf%40informatik.hu-berlin.de&rnum=1&prev=/groups%3Fhl%3Den%26lr
    %3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dp6qr9dsxi04.fsf%2540informatik.hu
    -berlin.de)

    For reference, I've attached a little source-code. Imagine that the
    class is String_var. This program produces identical results under two
    compilers:

    • Microsoft's Visual C++ 6.0 (SP3)
    • CygWin's gcc v3.2

    Though the String_var implementations I've seen aren't adversely
    affected, I wanted to bring this compiler behavior to your attention. I
    think the CORBA & C++ folks should eventually know, too, since CORBA and
    C++ seem to miss each other here.

  • Reported: CPP 1.1 — Fri, 10 Jan 2003 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

need mapping for get_orb and get_component on CORBA::Object

  • Key: CPP12-18
  • Legacy Issue Number: 5784
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    The Core issue that adds get_orb to CORBA::Object has passed. It would
    be good if you were to initiate an issue in the C++ RTF to make the
    necessary changes in the C++ pseudo-object mapping section for Object to
    incorporate this new operation. While you are at it you might also wish
    to throw in the get_component operation, which was added by the
    Components specification, and is yet to get into the C++ mapping chapter
    (I think).

    These might be way easier tor esolve than some of the weightier issues
    that you have been struggling with, since these have very
    straightforward and non-controversial resolutions

  • Reported: CPP 1.1 — Tue, 10 Dec 2002 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4871

  • Updated: Fri, 6 Mar 2015 20:57 GMT

No Mapping for Local interface in C++

  • Key: CPP12-17
  • Legacy Issue Number: 5580
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The bit that defines the mapping of local
    interfaces to C++ seems to be missing from the specification (ptc/99-10-09 has a change
    > based on the CCM specification, which does not appear in
    > ptc/01-06-07. )

  • Reported: CPP 1.1 — Fri, 9 Aug 2002 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bug on _var references

  • Key: CPP12-11
  • Legacy Issue Number: 4530
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    he spec shows on page 1-13:

    class A_var {
    public:
    // ...
    operator const A_ptr&() const

    { return ptr_; }
    operator A_ptr&() { return ptr_; }

    // ...
    };

    The conversion operator is overloaded for const and non-const.

    Now, two issues here:

    1) It seems that "const A_ptr &" as the return type for the
    first operator is wrong because it really means
    "A * const", not "const A *". So, if anything, I think it
    would have to be written as

    operator const A * &() const

    { return ptr_; }

    2) But why provide a const version of the conversion operator
    at all? Object references are never passed with a const
    qualifier, so why provide this conversion operator? I think
    it could simply be deleted without affecting anything.

    Proposal: Delete the const version of the conversion operator.

    Opinions?

  • Reported: CPP 1.1 — Wed, 22 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Dangling reference

  • Key: CPP12-10
  • Legacy Issue Number: 4499
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    On page 1-3 of the mapping, it says:

    For more information about CORBA compliance, refer to the
    Preface, "Definition of CORBA Compliance" on page viii.

    That preface hasn't existed for a long time now.

    Proposal:

    Strike this sentence.

  • Reported: CPP 1.1 — Thu, 16 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Strike this sentence

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Structure member ordering

  • Key: CPP12-7
  • Legacy Issue Number: 4340
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The C++ mapping says in section 1.10:

    An OMG IDL struct maps to C++ struct, with each OMG IDL struct
    member mapped to a corresponding member of the C++ struct.

    This doesn't say that the order of the struct members in C++ must be the
    same as in the IDL. Without that guarantee, code that compares pointers to
    members is non-portable. We need a requirement to preserve the order here.

  • Reported: CPP 1.1 — Wed, 6 Jun 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:57 GMT

semantics of valuetype _downcast operation unclear

  • Key: CPP12-6
  • Legacy Issue Number: 4270
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The definition of the _downcast operation generated for valuetypes is
    unclear about whether it increments the reference count of the valuetype
    before returning the downcasted pointer. I assume by the fact that it
    is called _downcast rather than _narrow that it should not increment the
    reference count.

    Proposal:

    Add the following text to the end of the last paragraph in 1.17.3:

    "The _downcast function does not increment the reference count of the
    valuetype."

  • Reported: CPP 1.1 — Fri, 13 Apr 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Add the proposed text

  • Updated: Fri, 6 Mar 2015 20:57 GMT

ValueRefCountBase::_add_ref

  • Key: CPP12-13
  • Legacy Issue Number: 4610
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    PortableServer::ValueRefCountBase derives from both CORBA::ValueBase and
    PortableServer::ServantBase. This create a problem because ValueBase
    contains

    virtual ValueBase * _add_ref() = 0;

    but ServantBase contains

    virtual void _add_ref();

    The easy fix would appear to be to change the ValueBase version to return void.

    Anyone see a problem with this? (I don't understand why the ValueBase version
    currently returns a ValueBase * anyway. Any subtle reason for this that I
    am not aware of?)

  • Reported: CPP 1.1 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    Change _add_ref() on ValueBase to return void.

  • Updated: Fri, 6 Mar 2015 20:57 GMT

C++ mapping for CORBA::LocalObject

  • Key: CPP12-12
  • Legacy Issue Number: 4545
  • Status: closed  
  • Source: Dell Technologies ( Ted Burghart)
  • Summary:

    In the latest C++ mapping including RTF report changes (ptc/01-06-07) I see no mention of a mapping for CORBA::LocalObject. CORBA 2.4.x 3.7.6.2 states that this is to be specified in each language mapping.

    How does it get mapped and, in particular, what are it's memory management semantics and relevant methods?

  • Reported: CPP 1.1 — Wed, 29 Aug 2001 04:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as proposed resolution for issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

LocalObject

  • Key: CPP12-3
  • Legacy Issue Number: 4172
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    From orbos/99-07-01 (is there a more up-to-date version with the C++
    mapping?)

    namespace CORBA
    {
    class LocalObject
    : public virtual Object

    { protected: LocalObject(); ~LocalObject(); public: virtual void _add_ref(); virtual void _remove_ref(); // pseudo operations not shown... }

    ;
    };

    Member functions and any data members needed to implement the Object
    pseudo-operations and any other ORB support functions must also be
    supplied but are not shown.

    _add_ref

    The _add_ref member function is called when the reference is duplicated.
    A default implementation is provided that does nothing. A derived
    implementation may use this operation to maintain a reference count.

    _remove_ref

    The _remove_ref member function is called when the reference is
    released. A default implementation is provided that does nothing. A
    derived implementation may use this operation to maintain a reference
    count, and delete the object when the count becomes zero.

    This implies that by default a LocalObject will not be reference
    counted. That seems counter-intuitive. What was the intention here? It
    seems that every application I can think of will want reference counted
    local objects – however, to get this at present the application developer
    either has to implement the reference counting themselves or inherit
    off some proprietary interface.

  • Reported: CPP 1.1 — Tue, 23 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

mapping of local interfaces

  • Key: CPP12-2
  • Legacy Issue Number: 4160
  • Status: closed  
  • Source: AdNovum Informatik ( Stefan Wengi)
  • Summary:

    I took a closer look at orbos/99-07-01 to see how I'd have to implement
    local objects.
    Several questions came to my mind:

    1)
    what happens if you invoke CORBA::Object::_duplicate on a LocalObject?

    • does it call _add_ref on the local object (as the spec seems to say in
      4.1.2)?
    • is it allowed to return a copy of the object?

    2)
    how is memory handling done on existing interfaces?

    4.1.5 defines a list of interfaces that are changed to local interfaces
    e.g. CORBA::Current. How are they supposed to support proper memory
    handling when the default implementations of _add_ref/_remove_ref do
    nothing?

    3)
    local interfaces can be implemented by the application programmer, e.g.
    PortableInterceptors.

    • what happens if my _duplicate operation on CORBA::Object creates a
      copy (which is legal) and my implemenation of the local interface
      contains some state?

    This mapping creates more problems than it solves.
    It breaks at least one of the basic rules of OO design: base classes
    must not know about subclasses.
    Also disabling some methods that are valid on CORBA::Object (e.g. is_a)
    is a hint for bad design.
    Why not take the same interface 'inheritance' approach as with value
    types?

  • Reported: CPP 1.1 — Thu, 18 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to create a local object reference?

  • Key: CPP12-5
  • Legacy Issue Number: 4245
  • Status: closed  
  • Source: Floorboard Software ( Jonathan Biggar)
  • Summary:

    The text added by the CCM spec that describes LocalObject has no
    information on how to portably create a local object reference. Since
    we have ORB services, like the Security or Transaction service which
    must create local object references, and since we have a goal that these
    services should be portable as source code between ORBs, we need a
    portable way to create a local object reference.

    Proposal:

    Add a static _create_reference() member function to local object
    interface classes:

    // IDL
    local interface I

    { ... }

    ;

    // C++

    ... I_ptr;

    class I : ...

    { public: I_ptr _create_reference(I *); }

    ;

    A programmer can then create a new local object reference portably:

    class MyI : public I, public CORBA::LocalObject

    { ... }

    ;

    I_var new_i = I::_create_reference(new MyI());

  • Reported: CPP 1.1 — Fri, 30 Mar 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA::Object & LocalObject

  • Key: CPP12-4
  • Legacy Issue Number: 4186
  • Status: closed  
  • Source: IONA ( Matthew Newhook)
  • Summary:

    Is the definition of CORBA::Object given the C++ specificaton intended
    to be normative? If so then the C++ mapping given in the components
    spec won't work since it's clear that LocalObject is supposed to
    override the various methods provided on CORBA::Object.

  • Reported: CPP 1.1 — Wed, 24 Jan 2001 05:00 GMT
  • Disposition: Resolved — CPP 1.2
  • Disposition Summary:

    same as issue #4160

  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to allocate storage for a basic type you wish to place in an any?

  • Key: C11-82
  • Legacy Issue Number: 2533
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Under the C mapping how do you allocate storage for a basic type
    you wish to place in an any.

    Consider inserting a long into an Any.

    Do you do this: solution 1

    any->_type = TC_long;
    any->_value = CORBA_alloc(sizeof(CORBA_long));

    or this: solution 2

    any->_type = TC_long;
    any->value = CORBA_long_alloc();

    One vendor argues that the text below supports solution 2. However
    as a long is not a constructed type solution 1 seems more natural.

    >From "17.8 Mapping Considerations for Constructed Types" of CORBA 2.1
    specification:

    "For types whose parameter passing modes require heap allocation,
    an ORB implementation will provide allocation functions. These types
    include variable-length struct, variable-length union, sequence, any,
    string, wstring and array of a variable-length type. The return value
    of these allocation functions must be freed using CORBA_free(). For
    one of these listed types T, the ORB implementation will provide
    the following type-specific allocation function:

    T *T__alloc(); /* C */"

  • Reported: C 1.0b1 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    urgent resolution, issue resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use of "objref_ptr"

  • Key: C11-81
  • Legacy Issue Number: 332
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Nothing defines what an "objref_ptr" is. This was presumably pasted in from C++ mapping which has a T_ptr concept. Stop using this term in the C mapping or define it

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Correct arguments to send multiple requests

  • Key: C11-83
  • Legacy Issue Number: 2534
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Additional Commentary:

    In tset/c/hdr/DII/ORB/send_multiple_requests.c,
    VSOrb 1.1.0 test examines our orb on the assumption that
    send_multiple_requests() is defined like the following.

    CORBA_Status CORBA_send_multiple_requests(
    CORBA_ORB orb,
    CORBA_Request reqs[],
    CORBA_long count,
    CORBA_Flags invoke_flags,
    CORBA_Environment *env
    );

    But, according to section 4.3.2 of CORBA 2.1 specification,
    send_multiple_requests() is defined like the following.

    /* C */
    CORBA_Status CORBA_send_multiple_requests(
    CORBA_Request reqs[],
    CORBA_Environment *env,
    CORBA_long count,
    CORBA_Flags invoke_flags
    );

    Section C - Interpretation Responses

    The Open Group Initial Response:
    An interpretation from OMG is required to determine whether Section
    4.3.2 or Section 17.17 of CORBA 2.1 is definitive.

    Consultants Initial Response:
    We believe Section 4.3.2 is incorrect according to the general
    C mapping rules (as are many of the other examples). We are
    following rules defined in Section 17.17 which states that every
    function signature takes the object as the first parameter and an
    Environment object as the last parameter.

    Interpretations Subgroup Responses:

  • Reported: C 1.0b1 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    urgent resolution....issue closed

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Out of bound value behaviour for _maximum and _length in sequences

  • Key: C11-73
  • Legacy Issue Number: 161
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.11. Para 6 indicates error to set _length or _maximum member larger than specified bound. Say "If the _length and _maximum members are set to a value larger than specified...."

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    replace sentence

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Type declaration

  • Key: C11-72
  • Legacy Issue Number: 160
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.5. ISO C permits declaration of anonymous structures when type is being defined. From a coding style perspective it"s better to require use of defined type names

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    close

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Order of parameters in the C mapping

  • Key: C11-76
  • Legacy Issue Number: 164
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.15: Bullet 2 indicates that last parameter to each operation is an output parameter..Inconsistent with lead sentence, CORBA 1.2, and not reflectedin rest of doc.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Editorial

  • Key: C11-75
  • Legacy Issue Number: 163
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.13: Para 6 Change "For an array T..." to "An array T..."

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA_string_alloc

  • Key: C11-80
  • Legacy Issue Number: 330
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Editorial issue: The definition on page 14-15 is given as char* CORBA_string_alloc(CORBA_unsigned_long_len); The return type should be "CORBA_char*".

  • Reported: C 1.0b1 — Thu, 31 Oct 1996 05:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Argument order inconsistent (Section 14.25.2)

  • Key: C11-79
  • Legacy Issue Number: 173
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: C signature for example4_op5 as well as CORBA_BOA_set_exception have the environment parameter in the wrong place

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed by Portability Submission

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Portably getting the value of the bounds of a sequence

  • Key: C11-74
  • Legacy Issue Number: 162
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.11: It"s not clear how a portable application could know value of bound of sequence. It"s specified in PIDL but is not represented in generated C header

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    add sentence

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reference to undefined term DIR (Section 14.24.1)

  • Key: C11-78
  • Legacy Issue Number: 170
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph refers to "DIR". This term has not been recently defined in the specification.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed in CORBA 2.2 editing process

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Order of arguments in C Language mapped operation

  • Key: C11-71
  • Legacy Issue Number: 159
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Order of arguments to C Language mapped operations seems to have changed from CORBA 1.2. Order must remain the same. Order must be used consistently throughout this specification .

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong order of parameters

  • Key: C11-77
  • Legacy Issue Number: 168
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Example CORBA_ORB_object_to_string function shows CORBA 1.2 function argument ordering. This is inconsistent with text in sect. 14.15. Spec must be internally consistent.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics of CORBA_exception_id()"s return type

  • Key: C11-64
  • Legacy Issue Number: 112
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: CORBA_exception_id() returns a pointer to the character string indentifying the exception. It would be nice to explicitly say that this is the same string defined in 14.14.

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Replace sentence to clarify

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Suggested optimization for string duplication

  • Key: C11-63
  • Legacy Issue Number: 110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be useful if CORBA_string_alloc() took an "optional" second argument which would be the string value to initialize the new string to, since ANSI C does not have strdup().

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Unions represented with either union or struct

  • Key: C11-59
  • Legacy Issue Number: 106
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 14-10 of the C mapping, it says that an ORB can use a struct to hold a union. Doesn"t this cause portability problems?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

All interfaces must be defined at global scope?

  • Key: C11-58
  • Legacy Issue Number: 105
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.3 of the C mapping says that interface definitions may not occur within the scope of module declarations. Doesn"t it mean "within the scope of another interface definition"?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Confusion about ORB handling call to pseudo objects via DII

  • Key: C11-70
  • Legacy Issue Number: 158
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Par. 14.1.8 indicates that ORB may handle calls to pseudo-objects via DII specially. This spec. should indicate that DII can"t be portably used for pseudo-object references.

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    close – paragraph is deleted

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Entire section 14.1 should not be there (CORBA 14)

  • Key: C11-69
  • Legacy Issue Number: 157
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Entire section should not be here.It"s relevant to all potential language mappings. It should be moved to an appendix, since it is not a normative part of the specification

  • Reported: C 1.0b1 — Thu, 10 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    delete section

  • Updated: Fri, 6 Mar 2015 20:57 GMT

CORBA_BOA_set_exception() parameter issues

  • Key: C11-67
  • Legacy Issue Number: 115
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Who owns the parameters "exceptname" and "param" to CORBA_BOA_set_exception? Shouldn"t that routine take a second CORBA_Environment parameter to signal errors in its operation?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    POA update eliminated conditions - close

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Specification type on CORBA_ORB_object_to_string example

  • Key: C11-66
  • Legacy Issue Number: 114
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On p. 14-24, the example of CORBA_ORB_object_to_string seems to have the CORBA_environment parameter in an unexpected position. Is this intentional? And what about the example on 14-28?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Fixed by Portability submission

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Sequence release flag implementation

  • Key: C11-60
  • Legacy Issue Number: 107
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.11 of the C mapping introduces a release flag hidden inside the C struct; however, that struct is completely specified and leaves no bit for that flag. How does this work?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Support for efficient DII invocation (Section 17.7.1 CORBA 2.))

  • Key: C11-68
  • Legacy Issue Number: 155
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sun wants to ensure that DII interface permits implementations that support invocations without consulting the interface repository as intended by CORBA.

  • Reported: C 1.0b1 — Mon, 7 Oct 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    close

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Contents of string literal exception identifier

  • Key: C11-65
  • Legacy Issue Number: 113
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 14.14 calls for a string literal which "uniquely identifies this exception type", but does not specify any rules for generating such identifiers.

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Malloc problems with sequence types

  • Key: C11-62
  • Legacy Issue Number: 109
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C mapping allocation procedures (T__alloc()) don"t allow for malloc"ing space for both the header struct and the values in one call.

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Confusing sequence example

  • Key: C11-61
  • Legacy Issue Number: 108
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The fact that a sequence of longs is to be mapped into a struct is very confusing.

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    Close with no change

  • Updated: Fri, 6 Mar 2015 20:57 GMT

C keywords

  • Key: C11-56
  • Legacy Issue Number: 53
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be no provision for the possibility of C keywords appearing in IDL.

  • Reported: C 1.0b1 — Thu, 11 Jul 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with underscores

  • Key: C11-57
  • Legacy Issue Number: 104
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The C mapping advises avoiding the indiscriminate use of underscores in identifiers. To whom is this addressed? Should it be a more general restriction?

  • Reported: C 1.0b1 — Wed, 11 Sep 1996 04:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 20:57 GMT

Content of an Any is a pointer to the type -- Issue

  • Key: C11-84
  • Legacy Issue Number: 2563
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In PIN4O.00001 OMG have ruled that the content of an any is a
    pointer to the type. So a long in an Any looks like this;

    any ----> long

    But what about strings? As this type includes a pointer part
    itself the above rules would make the following appear to be the
    conformant case;

    any----> ptr to string -----> string : option 1

    Having a pointer to a pointer is a bit unwieldy but appears to follow
    the rules. Collapsing this to simply a pointer to the str thus;

    any----> string : option 2

    is more natural for programmers but ambiguous within the spec.

    We would like to know which of these two options is correct.

    Section C - Interpretation Responses

    The Open Group Initial Response:
    This request is being sent for review by OMG. We request that OMG
    rule which of the two options is correct or whether both are equally
    so.

    Consultants Initial Response:
    We recommend this request be sent to OMG for a binding interpretation.

    We recommend a PIN be granted to clarify the requirements for branding
    irrespective of which of the two options OMG selects.

  • Reported: C 1.0b1 — Tue, 30 Mar 1999 05:00 GMT
  • Disposition: Resolved — C 1.1
  • Disposition Summary:

    urgent resolution, issue closed

  • Updated: Fri, 6 Mar 2015 20:57 GMT