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)

Deferred

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

Summary: (D)IForeignComplexType,(D)ICORBAStruct,(D)ICORBAUnion,(D)IForeignException,(D)ICORBAUserException should have standard UUIDs and UUID identifiers

Deferred

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

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?

Deferred Automatically

This proposal was generated automatically.

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?

Deferred Automatically

This proposal was generated automatically.

Summary: Section 4.1.12: DICORBAtypeCode::kind has one parameter of type TCKind. It should be of type CORBATCKind

Deferred

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

Summary: There should be a standard ProgramId for the class which exposes D(I)CORBAAny

Deferred

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

Summary: The enum should be named CORBA_CompletionStatus instead of CORBA_ExceptionType

Deferred

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

Summary: The VB cannt handle array out-parameters. Must use in-outs.

Deferred

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

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.

Deferred

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

Summary: The return value type should be DICORBATypeCode*, not IDispatch. The return value of member_label should be a DICORBAAny* rather than VARIANT

Deferred

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

Summary: I suggest that the automation chapter be changed to align with the architecture chapter

Deferred

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

Summary: The uuid for DForeignException has an extra 0. It should be E977F907-3B75-11cf-BBFC-444553540000

Deferred

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

Summary: This property should be removed because the INSTANCE_repositoryId property in IForeignComplexType provides this functionality

Deferred

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

Summary: When translating a BSTR to a CORBA bounded string, boundary violations should cause the View to propagate DISP_E_OVERFLOW

Deferred

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

Summary: Second to last paragraph of the section contains the term "CORBA proxy" which should be changed to Automation View Interface.

Deferred

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

Summary: The "retval" attribute should be removed from the second argument in both methods. MIDL does not have a retval attribute

Deferred

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

Summary: INSTANCE_Clone does not need an in-parameter to specify the instance to be cloned.

Deferred

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

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

Deferred

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

Summary: There should be a standard name for the Automation View interface.

Deferred

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

Summary: Page 2-30, top of page, end of section 2.7.1: There is a label "Examples:" but no example follows

Deferred

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

Summary: "..maximum value of an Automation short" should read "..maximum value of a CORBA::UShort

Deferred

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

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>

*

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.

Deferred

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

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.

Deferred

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

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"

Deferred

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

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

Deferred

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

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?

Deferred

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

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

Deferred

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

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

Deferred

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

Summary: There should be straight dispatch versions of DCORBAObject and DORBObject

Deferred

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

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?

Deferred

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

Summary: Missing member_kind and member_tc

Deferred

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

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

Deferred

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

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.

Deferred

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

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.

Deferred

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

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?

Deferred

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

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

Deferred

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

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

Deferred

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

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]

Deferred

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

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.

Deferred

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

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

Deferred

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

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

Deferred

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

Summary: TypeCodes:

• It is not clear whether the IDL compiler has to generate
  a TypeCode object for each Value type.

Deferred

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

Summary: Clarify the hash code algorithm

Deferred

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

Summary: Semantic of register_value_factory is not clear
What do applications should expect if a factory is already
registered for a given repositoryId?