Issue 1258:  describe_value() operation issue (obv-rtf)
Source:  (, )
Nature:  Revision
Severity: 
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? 
 

Resolution: 
Revised Text: 
Actions taken:
April 28, 1998: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Issue 1258 (Leo Uzcategui)
-------------------------
I don't understand why TypeCode constants,
e.g. TC_CORBA_InterfaceDescription and
TC_CORBA_FullInterfaceDescription, are not mentioned or defined in the
OBV spec.
The CORBA spec defines a set of predefined TypeCode constants for 
InterfaceDescription, OperationDescription, AttributeDescription,
etc., named 
TC_CORBA_InterfaceDescription, ... (see section 8.7 TypeCodes in CORBA
2.2)
It seems that new ones should be defined to be consistent, but then it
may be my
misunderstanding.



Return-Path: <kukura@iona.com>
Date: Mon, 20 Jul 1998 14:58:53 -0400
From: Bob Kukura <kukura@iona.com>
Organization: IONA Technologies
To: jis@fpk.hp.com
CC: orb_revision@omg.org
Subject: orb_revision vote 4 votes and friendly ammendments

IONA/Martin votes YES on 913, 999, 1088, 1541, and 1688.

On 665, we vote YES provided that two minor friendly amendments are
incorporated:

1) Comparison of the discriminator_type() for unions should be handled
in step g) rather than step e), since it requires use of equivalent().

2) The get_canonical_typecode() text needs to specify what happens if
a
RepositoryId is not found.  I'd recommend adding the words in
brackets:
"If the top level TypeCode does not contain a RepositoryId, such as
array and sequence TypeCodes, or TypeCodes from older ORBs, [or if it
contains a RepositoryId that is not found in the target Repository,]
then a new TypeCode is constructed by recursively calling
get_canonical_typecode on each member TypeCode of the original
TypeCode".

On 1258, we vote YES with one very minor friendly amendment
incorporated:  Change "If FOO is an IDL type declaration, the IDL
compiler with produce a declaration of a TypeCode constant" to "For
each
IDL type declaration, the IDL compiler will produce a declaration of a
TypeCode constant".  Nothing else seems to refer to "FOO".

-Bob



Return-Path: <jon@floorboard.com>
Sender: jon@floorboard.com
Date: Mon, 20 Jul 1998 12:58:46 -0700
From: Jonathan Biggar <jon@floorboard.com>
To: Bob Kukura <kukura@iona.com>
CC: jis@fpk.hp.com, orb_revision@omg.org
Subject: Re: orb_revision vote 4 votes and friendly ammendments
References: <35B3936D.ABCAE5EA@iona.com>

Bob Kukura wrote:
> 
> IONA/Martin votes YES on 913, 999, 1088, 1541, and 1688.
> 
> On 665, we vote YES provided that two minor friendly amendments are
> incorporated:
> 
> 1) Comparison of the discriminator_type() for unions should be
> handled
> in step g) rather than step e), since it requires use of
> equivalent().

Right.  Somehow I got it into my head that the discriminator_type()
returned a TCKind instead of a TypeCode.  I have no problem with this
change.

> 2) The get_canonical_typecode() text needs to specify what happens
if a
> RepositoryId is not found.  I'd recommend adding the words in
brackets:
> "If the top level TypeCode does not contain a RepositoryId, such as
> array and sequence TypeCodes, or TypeCodes from older ORBs, [or if
it
> contains a RepositoryId that is not found in the target Repository,]
> then a new TypeCode is constructed by recursively calling
> get_canonical_typecode on each member TypeCode of the original
> TypeCode".

This is also a good change.

> On 1258, we vote YES with one very minor friendly amendment
> incorporated:  Change "If FOO is an IDL type declaration, the IDL
> compiler with produce a declaration of a TypeCode constant" to "For
> each
> IDL type declaration, the IDL compiler will produce a declaration of
> a
> TypeCode constant".  Nothing else seems to refer to "FOO".

No problem with this one either.  I never liked the FOO in the first
place. :-)

-- 
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org