Issue 1292: CDR encoding of TypeCodes (interop) Source: (, ) Nature: Uncategorized Issue Severity: 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. Resolution: Revised Text: Actions taken: March 30, 1998: received issue June 23, 1998: moved from orb_revision to interop June 25, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Sun, 29 Mar 1998 20:43:56 -0800 From: Jonathan Biggar To: orb_revision@omg.org Subject: More on Typecode equality 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. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Thu, 30 Apr 1998 11:43:26 -0400 From: Bob Kukura Organization: IONA Technologies To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: More on Typecode equality References: <351F230C.4720A746@floorboard.com> Jonathan Biggar wrote: > > 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. CORBA 2.2, section 8.7.1, page 8-37 states: "The equal operation can be invoked on any TypeCode. Equal TypeCodes are interchangeable, and give identical results when TypeCode operations are applied to them." This definition of TypeCode::equal() is pretty clear to me - it has to compare the optional parts of the TypeCode as well as the structural information and RepositoryIds. I don't think we should mess with this definition. It can certainly be argued that other forms of TypeCode comparison are needed inside an ORB, and maybe should be available to applications via standard TypeCode operations. But I don't see any reason to change the current completely unambiguous specification of TypeCode::equal(). Various proposals have been circulated over the years about alternative forms of TypeCode comparison. So far, there has been no consensus on a single comparison function that serves all purposes, particularly given that some of the information in the TypeCode is optional. It would be nice if some small set of TypeCode comparison functions could be defined and and used to specify things like the rules for extracting values from Anys. CORBA doesn't really have a rigorous model of type substitutability - these things are left to the individual language mapping. If one new comparison operation could be added to TypeCode, I'd argue for one (TypeCode::equivalent()?) that: * ignored aliases - i.e. "long" is equivalent to "typedef long" * compared structure * compared RepositoryIds * ignored struct, union, and exception member names The problem is that the RepositoryIds are optional in struct, union, exception, and enum TypeCodes as seen in the same section of CORBA I quoted above: "The id operation can be invoked on object reference, structure, union, enumeration, alias, and exception TypeCodes. It returns the RepositoryId globally identifying the type. Object reference and exception TypeCodes always have a RepositoryId. Structure, union, enumeration, and alias TypeCodes obtained from the Interface Repository or the ORB::create_operation_list operation also always have a RepositoryId. Otherwise, the id operation can return an empty string." This means that two TypeCodes generated by different ORBs from the same IDL structure definition might: * both have the RepositoryId - equivalent() returns TRUE * only one have a RepositoryId - equivalent() returns FALSE? * neither have a RepositoryId - equivalent() returns TRUE The second case is a false negative, and the third could easily be a false positive if the types really did have different RepositoryIds. An improvement might be to raise an exception when one or both RepositoryIds are missing. But I don't think such a comparison function for TypeCodes would really be all that useful unless all RepositoryIds in CDR TypeCodes and the TypeCode API were made manditory. In my opinion, if RepositoryIds are made manditory, member names could still remain optional. -Bob > > Of course, this still leaves the issue of what to do about aliases > up in > the air. > > -- > Jon Biggar > Floorboard Software > jon@floorboard.com > jon@biggar.org Issue 1292: CDR encoding of TypeCodes (orb_revision) STATUS: Issue 1136 is left open regarding type code equivalence. However Issue 1292 on encoding is closed with the following agreed change for PTC vote: Under the section 13.3.4 sub heading "Encoded Identifiers and Names" describing CDR marshalling of type codes, the end of the first para should be changed from: " RepositoryId values are required for tk_objref and tk_except TypeCodes; for other TypeCodes they are optional, and are encoded as empty strings if omitted " to: " RepositoryId values are required for tk_objref and tk_except TypeCodes; for tk_struct, tk_union, tk_enum, and tk_alias TypeCodes they are required if the TypeCodes has one, and are encoded as empty strings if omitted. "