Issues for Object by Value RTF Discussion Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1055: Can value type inherit from Value Box type
Issue 1064: Section 5.5 Interface repository (01)
Issue 1065: Section 5.5 Interface repository (02)
Issue 1140: Which TypeCode operations apply to Value and ValueBox?
Issue 1250: "Syntax" for grammar rule [value_inheritance_spec] ::= ":" [ safe_token ]
Issue 1251: "Safe" keyword identifier issue
Issue 1252: Can Value type inherit from Value Box type?
Issue 1253: New lexical type - Keyword Identifie
Issue 1254: Grammar rule issue
Issue 1255: Section 5.3.3: can value inherit from a boxed value?
Issue 1256: p.6.68 boxed values of complex types map to same type
Issue 1257: Value type ansd Value Box"s single data member name
Issue 1258: describe_value() operation issue
Issue 1260: Missing member_kind and member_tc
Issue 1261: Type code issue
Issue 1262: Clarify the hash code algorithm
Issue 1263: Section 5.6.2 Repository Id
Issue 1264: Repository Id (02)
Issue 1265: Repository Id (03)
Issue 1266: Section 5.6.3 Hashing Algorythm
Issue 1267: Semantics of computing the hash code..
Issue 1268: Concrete value class
Issue 1269: Section 7.3.5 ValueBase and Reference Counting
Issue 1270: Section 7.3.6 Reference Counting Mix-in Classes
Issue 1271: Section 7 C++ Language mapping
Issue 1272: Java mapping example and C++ mapping example
Issue 1273: Section 7.3.10 Value Factories
Issue 1274: Why is ValueBase a value and not a native type?
Issue 1275: Can an instance of C be passed by value to an operation that expects an A?
Issue 1277: Editorial page 8-107
Issue 1279: p 5-24, first paragraph of 5.3.1.3
Issue 1280: Suggested changes (to section 5.4.1 of orbos/98-01-18) are
Issue 1281: Which exceptions should be raised?
Issue 1282: Editorial: p 5-50
Issue 1283: p 5-50 2nd paragraph of 5.6.2.1
Issue 1284: Can public modifier be applied to value operations?
Issue 1285: Clarify semantics
Issue 1286: Reconcile RMI/IIOP upcall and helper class
Issue 1310: Keyword identifiers (01)
Issue 1311: Keyword identifiers (02)
Issue 1312: Keyword Identifiers(03)
Issue 1313: Keyword identifiers (04)
Issue 1321: public static org.omg.CORBA.ValueDef get_value_def();
Issue 1352: No portable way to obtain list of type safe repository IDs
Issue 1353: Marshaling engine issue
Issue 1380: Sections 5.3.1.2 vs. 6.3.1: Mapping of non-public state to java private
Issue 1382: Narrowing from abstract interfaces
Issue 1419: "in". "out", and "inout" modifiers on value operation parameters
Issue 1420: Typo on page 8-107 of OBV specification
Issue 1421: Can "public" mofifier be applied to value operations?
Issue 1522: OBV "chunking"
Issue 1523: CDR Streams
Issue 1526: Problem with C++ language mapping for OBV
Issue 1527: TypeCodes defined in section 5.8.2
Issue 1528: ValueMemberSeq: What is to be done with the RepositoryID parameter?
Issue 1529: DynAny::get_value collision
Issue 1539: OBV C++ problem with "supports"
Issue 1614: OBV spec inefficient for dending large number of small objects
Issue 1615: Some explicit semantics seem to be missing in section5.8.6
Issue 1624: Forward declaration of value boxes
Issue 1625: TypeCodes for values
Issue 1650: Boxed values need extension to write_Value call
Issue 1654: Default constructor for Java values
Issue 1673: Custom marshalling support for IDL fixed type
Issue 1674: C++ boxed value member clashes
Issue 1676: OBV TypeCode parameters wrong
Issue 1685: OBV TypeCode problems
Issue 1697: P 5-44: use of base type
Issue 1699: Abstract Interface issue (write_Abstract/read_Abstract)(01)
Issue 1719: No typecodes for abstract interfaces
Issue 1720: Abstract Interface issue (02)
Issue 1726: TypeCode complexity for value types
Issue 1727: Module separator within repository IDs
Issue 1748: Memory Management for Value Factories Unspecified
Issue 1771: CodeBase interface uses undefined type
Issue 1782: New OBV "supports" keyword conflicts with CosLifeCycle
Issue 1816: OBV init
Issue 1817: Status of hashed repository IDs
Issue 1932: "Tool" issue for IDL compilers too complex
Issue 1934: ValueHelper Interface issue

Issue 1055: Can value type inherit from Value Box type (obv-rtf)

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?
 

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

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"
 

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.
 

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 { ... }).
 

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.
 

Summary: Can a Value type inherit from a Value Box type (the Value Box is described
 as been syntactic sugar for a Value type)?
 

 received issue

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.

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:
 

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.
 

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).
 
 

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?
 

 received issue

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? 
 

Summary: Missing member_kind and member_tc
 

Summary: TypeCodes:
 
    - It is not clear whether the IDL compiler has to generate
      a TypeCode object for each Value type. 
 

Summary: Clarify the hash code algorithm
 

 closed issue

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

 received issue

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.
 

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

 received issue

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]
 

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

 received issue

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

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"
 
 

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)
 

 delete "must be concrete". Accepted into CORBA 2.3

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:
 

 no action, changed suggested would make c++ mapping consistent

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.
 

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.
 

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?
 
 

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?
 

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

 received issue

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
 

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> ].
 

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
 

Summary: typo p 5-50, first paragraph of 5.6.2.1: *s*IDL compilerS keep on spitting...
 

 closed issue

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.
 

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

 closed issue

Summary: 

Summary: Reconcile RMI/IIOP upcall and helper class
 

 closed issue

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.

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.
 
 

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.
 
 

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.
 

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());
 }
 
 

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. 
 

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. 
 

 received issue

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.
 

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.
 

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.
 

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

 received issue

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.
 

  No. public/private does not apply to operations. See revised language mapping chapters for correct

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?
 

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.
 

 see revised chapter

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
 

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.
 

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 ?
 

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).
 

 rename methods to get_val. Accepted for CORBA 2.3

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
 

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.
 

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.
 
 
 
 
 
 

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?
 

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.
 
 

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.
 

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).
 
 

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);
   };
 

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().
 

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.
 
 

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.
 
 

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.
 

 closed issue

Summary: 1. There are no write_Abstract and read_Abstract methods on 
    DataInputCtream and DataInputStream.  This looks like an oversight
    to me.
 

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.
 

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."
 

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.
 
 

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.
 

 see revised chapters

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.
 

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();
 
 

:Repository get_ir();

Summary: The new OBV keyword "supports" collides with the operation "supports"
 defined in CosLifeCycle::GenericFactory.
 
 

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.
 

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 
 

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.
 

Summary: 5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.
 

 received issue