Issue 719: CDR encoding of TypeCode names inconsistent with equal operation (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name() Resolution: Duplicate of issue 665 Revised Text: Actions taken: September 10, 1997: received issue September 12, 1997: closed issue Discussion: End of Annotations:===== Return-Path: To: orb_revision@omg.org Cc: Juergen Boldt Reply-To: leou@austin.ibm.com Subject: CDR encoding of TypeCode names inconsistent with equal operation Date: Wed, 10 Sep 97 17:09:12 -0500 From: Leo Uzcategui Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name(). Juergen - Here's an issue for the ORB RTF. Thanks, Leo ---------------------------------------------------------------------- Leo Uzcategui, IBM Corp. leou@austin.ibm.com 11400 Burnet Rd, Austin, TX 78758 (512) 823-9573 fax:(512) 838-1032 ---------------------------------------------------------------------- ------- Forwarded Message Date: Tue, 09 Sep 97 09:13:01 -0500 From: Mark Coats To: leou@austin.ibm.com Subject: typecode equivalence Hi Leo, Here is an issue that I'd like brought to OMG's attention: Thanks, Mark Coats There is an inconsistency in the CORBA specification of the typecode equal operation and the Common Data Representation (CDR) description for encoded identifiers and names of typecodes. The TypeCode portion of the spec (p. 6-36) says that typecode equality means two typecodes "give identical results when TypeCode operations are invoked on them." This implies that all fields must be compared. The name operation must return the same value or the two typecodes are not equal. Therefore the names must be equal. But in the section of the spec that deals with CDR (p. 12-12) it says: "The name parameters in tk_objref, tk_struct, tk_union, tk_enum, tk_alias, and tk_except TypeCodes an 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 simple, unscoped names supplied in the OMG IDL definition text. If omitted, they are encoded as empty strings." This clearly says these names are not required. Which implies that the "name" and "member_name" fields of typecodes should not be compared. If one implements typecode equality in it's strictest definition, there is an interoperation exposure when communicating with ORBs that don't include these names in the marshalled typecodes. Date: Tue, 09 Sep 97 09:13:01 -0500 From: Mark Coats To: leou@austin.ibm.comSubject : typecode equivalence ------- End of Forwarded Message Return-Path: X-Sender: vinoski@karloff.boston.iona.ie Date: Thu, 11 Sep 1997 19:59:33 -0400 To: Juergen Boldt From: Steve Vinoski Subject: Re: issue719 Cc: issues@omg.org, orb_revision@omg.org At 01:25 PM 9/11/97 -0400, Juergen Boldt wrote: >This is issue # 719 > >CDR encoding of TypeCode names inconsistent with equal operation > >Should the TypeCode equal operation compare the results of name() > to determine TypeCode equality? Same question for member_name() This is a duplicate of issue 665 (Portability RTF). --steve