Issues for CORBA Core Revision Task Force discussion list

To comment on any of these issues, send email to orb_revision@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

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

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

Issue 1: Recusive Type Definitions (orb_revision)

Click here for this issue's archive.
Nature: uncategorized
Severity:
Summary:

Summary: What does "semantically constrained" mean in section 3.8.2 under the discussion of recursive type specifications.

Resolution: closed issue, resolved
Revised Text: Replace the 2 sentences "Although it is.."template type." with "although the IDL syntax allows the generation of recursive constructed type specificationsthe only recursion permitted for constructed types is through the use of the sequence template type.
Actions taken:
May 16, 1996: Issue received
March 25, 1997: closed issue

Discussion:

Issue 2: Inheritance of describe_contents() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Where does the OperationDef interface inherit the describe_contents() operation from.

Resolution: close issue, resolved
Revised Text:
Actions taken:
May 16, 1996: Issue received
February 26, 1998: closed issue

Discussion:

Issue 14: IFR: union elements associated with case labels (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: A union element associated with N case labels manifests in the IFR as N distinct UnionMembers. Is this intended?

Resolution: resolved, close issue
Revised Text:
Actions taken:
May 16, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 66: Whether unions carry exact discriminant information (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported.

Resolution: resolved, close issue
Revised Text: Value of aunion type includes the exact value of the discriminator. Move this requirement to Chapter 1, since it is a requirement on the type model, not on IDL
Actions taken:
August 5, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 68: Missing info about the semantics of ORB_init and OA_init (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The text associated with ORB_init and OA_init does not specify what is done with the argv parameter that requires it to be inout.

Resolution: Incorporate change in 2.3a and close issue.
Revised Text: Add the following paragraph immediately following the next to last paragraph
Actions taken:
August 13, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 73: Do typecodes need literal constant representations in all mappings? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.7 of the CORBA 2 spec constrains the representation of typecodes such that typecode "literals" can be placed in C include files. Is this meant?

Resolution: The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi
Revised Text: Remove para 3 of section 10.7 Close in 2.3a after incorporating change.
Actions taken:
August 13, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 76: CORBA::InterfaceDef name collision (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORBA::InterfaceDef defines an operation "is_a", although there is already an "is_a" operation defined in CORBA::Object. Section 3.6 on page 3-17 says this is not allowed.

Resolution: close issue, resolved
Revised Text:
Actions taken:
August 13, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 85: Interface Repository Error Handling (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The IR specification specifies what operations are an error, but does not specify how this error is returned. The specification does not define any exceptions.

Resolution: Superceded by Issue 778
Revised Text: Close issue with annotation that it is now being handled in 778
Actions taken:
August 15, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 86: lookup() questions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Does the lookup() function also lookup in the base interfaces if used on an InterfaceDef? If so, what if it is is more than one interface? Can the search_name argument be a scoped name?

Resolution: resolved, close issue
Revised Text:
Actions taken:
August 15, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 87: Exception as explicit parameter (orb_revision)

Click here for this issue's archive.
Nature: Interpretation
Severity: Serious
Summary:

Summary: Is it permissible to declare an exception as an explicit parameter?

Resolution: resolved, close issue
Revised Text: An exception declaration is not a type declaration, according to the grammar, so it cannot be a parameter type.This has already been entered as a C++ issue. Issue closed.
Actions taken:
August 18, 1996: Received issue
December 12, 1996: closed issue

Discussion:

Issue 88: Request reuse (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Can a Request pseudo object be invoked multiple times?

Resolution: resolved, close issue
Revised Text: Add following sentence to 4.2.3:"The behavior is undefined if the Request pseudo-object has already been used with a previous call to invoke(), send(), or send_multiple_requests." There is no way for portable application to reuse a Request Pseudo-Object
Actions taken:
August 20, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 90: Ambiguity in DII and DSI (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: For the DII, what value if any can be placed into the Any in the NamedValue corresponding to an OUT parameter? Must it be NULL, or is it legal to include a storage pointer? Also for DSI.

Resolution: resolved, close issue
Revised Text: Add a new para after fourth para in 4.1.1, as follows, with the word "argument" and the word "namedValue" in bold:"For out parameters, applications can set the argument member of the NamedValue structure to a value that includes either a NULL or a non-NU
Actions taken:
August 22, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 97: Usage of standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Is there a difference between standard/system exception? Can an implementation raise both? Is raising a standard exception the recommended way to handle errors while setting an attribute?

Resolution: resolved, close issue
Revised Text: A new sentence was added to the end of the first paragraph in 3.1.15 and also to the unnumbered section "Exception" in 12.3.4. Find additional sentences in the corresponding archive file.
Actions taken:
September 6, 1996: Received issue
June 20, 1997: closed issue

Discussion:

Issue 116: Typecodes for recursive sequences (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the interface for the create_recursive_sequence_tc ORB method, is this just a matter of creating a TypeCode with these two fields, or is there a parameter missing?

Resolution: No parameter is missing. you just create a TypeCode with TCKind set to tk_sequence and content type
Revised Text: Replace the text in section 8.7.3 that says:
Actions taken:
September 13, 1996: Received issue
February 23, 1999: closed issue

Discussion:

Issue 117: Unqualified names in scopes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORBA says "Once an unqualified name is used in a scope, it cannot be redefined", but my IDL compiler allows it. Is it legal?

Resolution: no change to spec., close issue
Revised Text: No change to spec. It"s not legal for a conforming IDL compiler to permit redefinition of unqualified name after it has been used in the same scope
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 127: _is_a with CORBA::Object as input parameter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What should _is_a() return when invoking it with an input parameter designating CORBA::Object?

Resolution: closed with revised text
Revised Text: Section 7.2.4, 2nd paragraph: The is_a() shall always return TRUE when invoked with an input parameter designating a CORBA:Object ...No change to the specification
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 128: ServerRequest::op_def() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What is the purpose of the ServerRequest::op_def method? It is not described in the Chap. 5 discussion of ServerRequest or in 18.4.1.

Resolution: close issue, no change
Revised Text:
Actions taken:
September 23, 1996: Received issue
February 23, 1999: closed issue

Discussion:

Issue 129: DSI and oneway operations (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: After calling a Dynamic Invocation Routine, how can the ORB know whether to send a response back to the client (i.e., whether the operation was "oneway")?

Resolution: The ORB uses protocol information (i.e. from GIOP response_expected) to make this decision.
Revised Text: Close no change in 2.3a with explanation as above.
Actions taken:
September 23, 1996: Received issue
February 22, 1999: closed issue

Discussion:

Issue 130: Unions with enum as discriminator type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: How is it possible in IDL to specify a union with an enum discriminator type?

Resolution: no change necessary, close issue
Revised Text: No change to spec. All conforming IDL compilers shall permit use of enum types as discriminators for union types
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 132: Scope of standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Page 3-35 doesn"t really say that the list of standard exceptions belong to the CORBA module, although 3.12 seems to clarify.

Resolution: resolved, close issue
Revised Text: Section 3.12 requires that conforming IDL compilers behave as if the standard system exceptions were defined in module CORBA. ?? issue for CORE RTF: Should IDL text in 3.15.1 be bracketed by "module CORBA {"and"}"?
Actions taken:
September 23, 1996: Received issue
March 25, 1997: Closed issue

Discussion:

Issue 133: Repository IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: I would expect a lookup on IDL:/CORBA/Object:1.0 to return an InterfaceDef. It would seem more logical if Object was represented by a "default" InterfaceDef in the repository.

Resolution: resolved, close issue
Revised Text:
Actions taken:
September 23, 1996: Received issue
February 26, 1998: closed issue

Discussion:

Issue 137: Do simple/anonymous types have repository IDs? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: Do simple types like "long" have specified repository IDs? ("IDL:CORBA/long:1.0") How about anonymous types, like "sequence <long, 10>"?

Resolution: clarified, close issue
Revised Text: Clarification
Actions taken:
September 26, 1996: Received issue
January 6, 1997: closed issue

Discussion:

Issue 156: Apparent error in CORBA 2.0 Interoperability (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: in 13.5.6 "The DCE ESIOP", "Location Policy Component" there is for module IOP a list of 4 "const octet statements.. The BNF appears to suggest that this is invalid.

Resolution: issue closed, no change
Revised Text:
Actions taken:
October 8, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 233: Pseudo-IDL identifiers differ by case only (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity: LOW
Summary:

Summary: IDL identifiers in chapter 4 differ by case only [Ch 17 CORBA2.0] Some of the identifiers used in the IDL in Ch 4 differ only by case, which is not legal in IDL.

Resolution:
Revised Text: Reassign issue to orb_revision, because it affects the DII chapter. The defect is still present in the 2.3 draft. For example, on page 7-5, we have: void create_request( // ... out Request request, // newly created request // ... ); This is only pseudo-IDL, but we might as well fix it.
Actions taken:
October 14, 1996: received issue
June 13, 2000: moved to orb_revision
October 30, 2000: closed issue

Discussion:

Issue 283: Similar structure to IR::Identifier (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is no such type as IR::Identifier? It should really say CORBA::Identifier. Are ServiceTypeNames limited to characters allowed in IDL Identifier and also case sensitive?

Resolution: resolved in 2.2
Revised Text:
Actions taken:
October 19, 1996: received issue
February 23, 1999: moved to orb_revision
February 26, 1999: closed issue

Discussion:

 closed issue

Issue 300: Recursive sequence TypeCodes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Are they a new TypeCode kind (tk_kind) or are they of the tk_sequence TypeCode kind/

Resolution: subsumed by issue 116, close issue.
Revised Text:
Actions taken:
October 29, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 306: Portability and the #include directive (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: #include has same definition that C and C++ programmers are used to.HP treats #include at global scope as merely introducing declarations. This idea needs closer examination

Resolution: close no change in 2.4
Revised Text:
Actions taken:
November 23, 1996: received issue
August 12, 1999: close dissue

Discussion:

Issue 380: Interface for managing interceptors is missing (orb_revision)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

Summary: List of interceptors to be called during request and order in which interceptor will be called: Needs to be resolved by Alec Thomas but shouls also be moved to ORB RFT

Resolution: close no change
Revised Text:
Actions taken:
November 18, 1996: received issue
April 17, 1998: moved from secrev to orb_revision
August 12, 1999: closed issue

Discussion:

This is now subject of an RFP that has been issued, and is beyond the scope of an RTF

Issue 384: CORBA2.0, 1.2.2 Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para points to C Language Binding chapter and the DII for info on dynamic invocation of objects. It implies that DII is only available in C. Text should pobably be more clear

Resolution: resolved, close issue
Revised Text: Change the parenthesis in the second paragraph of 1.2.2 (top of page 1-3)to read:"(Refer to the Dynamic Invocation Interface chapter for descriptions of these request forms)."
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 385: 1.2.2 Requests Paragraph last - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "Descriptions of the values and exceptions...." to "For descriptions of the values and exceptions..."

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 386: 2.1 Structure of an Object Request Broker (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1, editorial:  Change "....up the "request." to "....up the request."

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 387: 2.5 Structure of an Object Adapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 2, editorial:  Change " registration of implementations" to "Registration of implementations"

Resolution: resolved, close issue
Revised Text: Changed
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 388: 3.9 Exception Declaration (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 2, editorial: Change "...(as specified by the <member> in its declaration." to "...(as specified by the <member> in its declaration)."

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 389: 3.10.3 Raises Expressions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para last, comment: We understand why standard exceptions may not be listed on a raises expression, but it would make IDL definition of interface more complete if permitted.

Resolution: resolved, close issue
Revised Text: No change to spec. Conforming IDL source files shall not include system exceptions in raises expressions. Conforming IDL compilers may accept non-conforming IDL source files.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 390: 3.10.3 Raises Expressions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It would make iDL definition of an interface much more complete if they were permitted. X/Open would like OMG to consider permitting listing of Standard Exceptions in raises clauses.

Resolution: Duplicate of issue # 389...closed
Revised Text:
Actions taken:
November 26, 1996: received issue
December 6, 1996: closed issue, duplicate of issue 389

Discussion:

Issue 391: 3.15.2 Object Non-Existence, Para 1, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "This standard system exception" to "The OBJECT_NOT_EXIST exception", to make explicit which exception is being discussed

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 392: 4.1 Overview, Paragraph 3, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Dynamic Invocation Interface is a proper name, and should be capitalized and italicized

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 393: 4.1.1 Common Data Structures, Paragraph 6, comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The usage of len could easily lead to a situation where it was inconsistent with TypeCode through erronous usage. WOuld be great if standard System exception was available for this case.

Resolution: Close no change in 2.3a
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 394: 4.1.2 Memory usage, Para 1, editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is an extra space between the table reference "Table 21" and the period

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 395: 4.1.3 Return Status and Exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open recommends that the specification is being modified to require DII functions to return a Status as an unsigned long. Implementations without return value return value:non-conforming

Resolution: closed issue, resolved
Revised Text:
Actions taken:
November 26, 1996: received issue
March 1, 1999: closed issue

Discussion:

Issue 396: 4.2.1 create_request Paragraph 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This paragraph should be deleted, since it is not useful for an application programmer.

Resolution: issue closed, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 397: 4.2.2 add_arg Paragraph 5-comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open believes there is no need to use different wording. They don"t believe that it is useful to indicate that mixing of methods might be allowed someday

Resolution: In Section 5.2.2 Para 5 Rev 2.2 remove the word "currently" from the last sentence
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 398: 4.2.3 invoke (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1 - editorial : The leading "c" in create_request is not boldface

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 399: 4.6 Context Object Operations, Para 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Spec reads " Property names are stored preserving their case, however names cannot differ simply by their case." This sentence should be deleted.

Resolution: Propose to apply resolution as above and close issue in 2.3
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 400: 4.3.1 sen3 - comment 23 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open recommends that this para is being reworded to require that applications call get_response after a send. Spec could also be modified to detect errors if response is not required

Resolution: close issue, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 401: 4.3.3 get_response (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 0 - editorial: Add a line containing ");" to the PIDL for get_response, to match the PIDL given in section 4.2.

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 402: 4.6.2 set_on_value Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text reads:"Currently, only string values are supported by the context object." Sentence should be deleted, since PIDL requires that a string be the value provided

Resolution: Propose apply resolution to rev 2.3 and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 403: 4.6.3 set_values (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: See comment on set_value in issue # 402

Resolution: Propose apply resolution to rev 2.3 and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 404: 4.6.4 get_values Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The error to be returned must be specified.. Since a status is not required to be returned, it"s incorrect to say that error is returned.  Exception is raised.

Resolution: add text to sections 5.6.4, 5.6.5 and 5.6.7 stating what exceptions are raised under what condition
Revised Text: Section 5,6,4 get_values
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 405: 4.6.4 get_values Paragraph 4 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text indicates that "Value scope names are implementation-specific." Items not necessary for portable development of applications are unspecified,undefined.

Resolution: Remove paragraph 4. Does not add any value to the spec.
Revised Text: Incorporate change proposed above and close
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 406: 4.6.4 get_values Paragraph 5 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Text reads " If the specified scope name is not found, an exception is returned." Error to be indicated must be specified. See objection for Paragraph 2.

Resolution: See resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 407: 4.6.5 delete_values Paragraph 1 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "value(s) values" to "value(s)

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 408: 4.6.5 delete_values Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This paragraph indicates that an exception is returned. See objection for 4.6.4 get_values Paragraph 2

Resolution: see resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 409: 4.6.7 delete Paragraph 4 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The exception to be returned is not specified. See objection for 4.6.4 get_values Paragraph 2.

Resolution: see resolution of 404
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 410: 5.2 Explicit Request State: ServerRequest Pseudo Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 4: editorial   Change "..OMG IDL for operation.." to "..OMG IDL for the operation...:.

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 411: 5.3.2 Registering Dynamic Implementation Routines Para 1- comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph starts off by explaining that previous versions of CORBA weren"t complete. Not necessary to belabor this point. It"s not clear whether or not this lack has been repaired.

Resolution: This is fixed by the new DSI text from the Portability FP
Revised Text:
Actions taken:
November 26, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 417: 6.3.1 Managing Interface Repositories (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Paragraph 1 - editorial: Change the reference to "get_interface" to the appropriate type-face

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 418: 6.4.3 Interface Objects Paragrapg 1 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Numbered bullet list following this para is formatted poorly. Text items  should be alligned and offset from the numbers in a consistent way

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 419: 6.4.3 Interface Objects Paragraph 2 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Change "...not by modify..." to "...not by modifying..."

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 420: 6.4.3 Interface Objects Paragraph 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Final Para describes the types of support interfaces that might be available in some implementations. These are not interesting for portable application develpoment.

Resolution: no change necessary, issue closed
Revised Text:
Actions taken:
November 26, 1996: received issue
March 26, 1998: closed issue

Discussion:

Issue 421: 6.5.2 IRObject Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Write Interface description indicates that it is error to invoke destroy on a Repository or PrimitiveDef. Should state that behavior is undefined.

Resolution: close issue, resolved
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 422: 6.5.3 Contained Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that IRs are not required to support simultaneous containment of multiple versions of the same named object. Required that IRs are able to handle multiple versions of objects

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 423: 6.5.3 Contained - Paragraph 7 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This initial Para of the Write Interface section indicates that an error is returned if an object with specified ID attribute already exists. Error should be specified.

Resolution: Close with annotation as above.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 424: 6.5.3 Contained Paragraph 10 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that name attribute is changed to new_name, and version attribute is changed to new_version. If name already exists and IR doesn"t support versioning=error. What error?

Resolution: Subsumed by 778 . Closed with that annotation
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 425: 6.5.4 Container Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It"s not clear what lookup operation returns when it is successful. We can tell from the IDL, but it should be explicitly defined. We think it returns object reference to scoped name.

Resolution: no change required, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 426: 6.5.4 Container Paragraph 5 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para descibes exclude_inherited argumentto the content operation. Format is poor, it"s not clear what the default setting for this argument might be (if any).

Resolution: no change required, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 427: 6.5.4 Container Paragraph 6 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para starts the description of the arguments for the lookup_name operation. It should stand out more instead of being intended in such a way that it looks like part of previous item"s description.

Resolution: changed, close issue
Revised Text: Changed. make layout conform to other sections, and fix confusing indentation
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue
February 26, 1998: closed issue

Discussion:

 closed issue

Issue 428: 6.5.4 Container Paragraph 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What other values of levels_to_search are legal? What happens if values other than those described are used?Is an exception raised? If so, what exception?

Resolution: resolved, close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 26, 1998: closed issue

Discussion:

Issue 429: 6.5.4 Container Paragraph 10 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This para and para 4 both describe a limiy_type argument. These should be described in the same way since they appear to have the same semantics

Resolution: Incorporate resolution and close issue.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 430: 6.5.4 Container Paragraph 11 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Same as issue # 429 with respect to 6.5.4 Container Paragraph 5.

Resolution: Incorporate resolution and close issue.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 431: 6.5.4 Container Paragraph 12 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para refers to the describe operation. This operation is part of the parent interface from which container interface is inherited.There should be a pointer to the parent interface

Resolution: Close no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 432: 6.5.4 Container Paragraph 15 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para describes create_<type> operations. It indicates that there are errors returned under differing circumstances. Possible errors should be defined.

Resolution: Superceded by 778
Revised Text: Close with annotation that it is now being handled as part of 778.
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 433: 6.5.4 Container Last Paragraph - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The trailing period is missing.

Resolution: changed, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 434: 6.5.6. Repository Paragraph 2 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that there may be more than 1 interface Repository in any given environment. How can portable application determine this, and how can it determine what the requirements are?

Resolution: the application should use either the naming or trading service to determine which IR to use.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed, no change to 2.3a

Discussion:

Issue 435: 6.5.6 Repository Paragraph 4 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para refers to a PrimitiveDef. There should be a pointer to where this is defined.

Resolution: In section 8.5.6 second para under Read Interface, add a cross reference to section 8.5.13 where Pr
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 436: 6.5.6 Repository Paragraph 4 - editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The mention of the kind attribute should be bold-face

Resolution: resolved, close issue
Revised Text: Changed.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 437: 6.5.8 ConstantDef Interface Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There should be a pointer to the list of simple types.

Resolution: Replace the phrase "simple type( ..... )" by the phrase "primitive types allowed in a constant decl
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 438: 6.5.10 StructDef Last paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Resolution: Remove the phrase "is ignored" from the last sentence of section 8.5.9 rev 2.2
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 439: 6.5.11 UnionDef Last Paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Resolution: Incorporate resolution and close issue
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 440: 6.5.20 AttributeDef Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What does the describe operation return for this interface?

Resolution: Add the sentence "The describe operation for an AttributeDef object returns an AttributeDescription
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 441: 6.5.22 InterfaceDef Paragraph 6 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: This Para indicates that the base_interface attribute can return an error if there are name conflicts. What error is returned?

Resolution: Subsumed by 778
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 442: 6.5.22 InterfaceDef Paragraphs 7 and 8 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: These paras indicate that an error is returned if the ID already exists in the repository. What is the error and what happens of the IR supports versioning?

Resolution: Superceded by 778
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 443: 6.6.1 OMG IDL Format Paragraph 5 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The semantics of minor version number changes should be a requirement on conforming applications (objects).

Resolution: That"s what the sections appears to say. close issue, no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 444: 6.6.4 Pragma Directives for RepositoryId Para 1 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Conforming compilers should ignore pragmas that are not defined. in this spec, and that they do not explicitly support. Portable applications should only use pragmas defined in this spec.

Resolution: The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i
Revised Text: Append the following sentences to Para 1 of section 8.6.4
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 445: 6.7 TypeCodes Paragraph 3 - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: It"s better to say "However, TypeCode "literals" shall have a representation such that they can be placed in C include files."

Resolution: Offending sentence removed in the resolution of issue 73. This is the same as issue 73
Revised Text:
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 446: 6.7.1 The TypeCode Interface All Paragraphs - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: PIDL for this interface describes the exceptions that might be raised, but the text doesn"t define the conditions when all of those exceptions might occur. This must be addressed.

Resolution: Fixed in 2.2 close no change.
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 447: 6.7.1 The Type Code Interface Paragraph 4 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Last sentence: It"s not clear under which conditions this is permitted. It"s permitted when a structure,union,enumeration or alias typecode wasn"t obtained from Interface Repository.

Resolution: Fixed in 2.2 close no change
Revised Text:
Actions taken:
November 26, 1996: received issue
February 23, 1999: closed issue

Discussion:

Issue 448: 6.7.2 TypeCode Constants Last Paragraph - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para indicates that form of TypeCode constants might be implementation specific.Does that mean the contents of the TypeCode implementation as opposed to signature of programmer?

Resolution: Offending language has been removed in Revision 2.3
Revised Text: Close no change in 2.3a
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 449: 7.1 Converting Object References to Strings Para 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: it"s not clear from this whether the string generated by object_to_string is portable accross ORBs or among clients. Please add text clarifying portability of generated string.

Resolution: resolved, close issue
Revised Text: For all conforming ORBs, if obj is a valid reference to an object then string_to_object(object_to_string(obj)) will return a valid reference to same object if two operations are performed on same ORB. For all conforming ORBs supporting IOP this remains t
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 450: 7.2.1 Determining the Object Implementation and Interface (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para 1-comment: These interfaces are very important parts of ORB interface. Their semantics are very unclear. What exceptions are they permitted to raise? Expand on this definition.

Resolution: resolved, close issue
Revised Text: add a new paragraph at the beginning of 7.2.1, as follows:"Note: The get_implementation() operation is deprecated in this version of the specification, and will be removed in a future version of the specification."
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 451: 7.2.4 Equivalence Checking Operation Paragraph 3 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Concept of "type safe narrow" isn"t really described. What"s it"s importance, announcement mechanism, and whether it can be portably relied on by programmers. Where"s more info in spec??

Resolution: resolved, close issue
Revised Text: section 7.2.4, 3rd para: No change to this paragraph - it is non-normative. Replace "string" with "RepositoryID" in PIDL above
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 452: 7.2.5 Probing for Object Non-Existence Paragraph 2 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Para describes implementation strategies that ORB implementors might use to ensure ORBS remain synchronized about presence of objects.Info really appropriate for this spec?

Resolution: no change required, close issue
Revised Text: No change. This text is clearly non-normative.
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 453: 7.4 ORB Initialization Last Paragraph - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: X/Open would like to see either the provision for a system default ORB or an interface that application could use to get list of available ORBs from which to choose.

Resolution: No change to the specification. The existing spec supports a default ORB
Revised Text: No change to the specification. The existing spec supports a default ORB
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 454: 7.4 ORB Initialization Last Paragraph - objection (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Unacceptable to say that "calling the ORB_init function multiple times for the same ORB may be required where an ORB is implemented as a shared library."

Resolution: defer to portability
Revised Text: Intend od 2nd sentence is that some applications because of their thread structures, may have to call ORB_init() more than once in order to ensure that it is called at least once. This is a non-normative explanation of 1st sentence. Defer to Portability
Actions taken:
November 26, 1996: received issue
March 25, 1997: closed issue

Discussion:

Issue 455: 8.1 Role of the Basic Object Adapter Para 1 - comment (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Last sentence: Seems like an odd thing to say. All X/Open specs only guarantee that they are correct if system is configured correctly. Not a big deal

Resolution: resolved, close issue
Revised Text: The BOA will be replaced in a future version of the specification
Actions taken:
November 26, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 457: CORBA::Bounds and CORBA::TypeCode::Bounds (orb_revision)

Click here for this issue's archive.
Nature: Bug
Severity: Critical
Summary:

Summary: Does Bounds have data members or not? At what scope should Bounds be defined? Given that Bounds exception is also used by Request interface, I suspect what is meant is CORBA::Bounds

Resolution: no change to spec., close issue
Revised Text: No change to the specification. There are 2 definitions of Bounds: CORBA::Bounds and CORBA::typeCode::Bounds. Neither has data members
Actions taken:
November 13, 1996: received issue
December 11, 1996: closed issue

Discussion:

Issue 458: IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is an inconsistency between the IDL grammar as defined in chapter 3 of CORBA2.0 spec and an IDL example from same chapter(Example p. 3-16..rule 71 and rule 36 specify different

Resolution: resolved, close issue
Revised Text: Find the resolution in the corresponding archives file
Actions taken:
December 5, 1996: received issue
June 20, 1997: closed issue

Discussion:

Issue 459: CORE spec reference (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: CORE contains specific language binding information which should be in a language binding chapter or in a new appendix

Resolution: Such information now exists only in the way of examples of what a particular piece of pseudo-IDL me
Revised Text: Close no change in 2.3a
Actions taken:
November 26, 1996: received issue
February 22, 1999: closed issue

Discussion:

Issue 464: DII operations "get_response and get_next_response (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Both operations permit the flag CORBA::RESP_NO_WAIT to be set. How is is invoker being informed that there is no response available? Incorrect to use exception.

Resolution: resolved, closed issue
Revised Text: The CORBA 2.2 revision changed the mapping for some DII operations and invalidated the C mapping for deferred synchronous DII. It may have done the same for other languages that followed the C mapping rather than the C++ mapping. This is both a language mapping issue and a Core issue because of the well-known mess in the PIDL for Request. Since the text for the C mapping is in the DII chapter (that is, Core), until that mess is cleaned up, it appears that orb_revision is the place to deal with the faulty C mapping. The problem is that the original (pre-2.2) PIDL for CORBA::Request had the operation Status get_response( in Flags invoke_flags); If the RESP_NO_WAIT flag is set, return is immediate, even if the response is not complete. Since "Status" was allowed to be mapped as a "long" (in CORBA 2.1 and before), the return value could be used to determine whether the response was ready by those implementations that cared. With CORBA 2.2, "Status" was replaced by "void", making it impossible to determine whether the response completed. Exactly the same situation is true for the mapping of operation get_next_response, for which no PIDL was ever given, only very disparate language mappings. The C++ mapping didn't use the Status approach. Its mapping added (among others) operations CORBA::Request::poll_response and CORBA::ORB::poll_next_response and redefined Request::get_response. The same was true for Smalltalk. We propose a similar approach to repair the C mapping. This does nothing to move the C, C++, and Smalltalk mappings out of the chapter, as they should be, but it at least makes the C mapping valid. Adding "poll_response" to the Request pseudo-object doesn't heal the disconnect between the PIDL and the language mappings -- obviously more needs to be done to get to a cleaner spec -- but at least a valid C language mapping would be restored. Revised Text: All references are to draft CORBA 2.3 (15-Nov-98). 1. Section 7.2 Request Operations, change the get_response operation and add the poll_response operation to the IDL at the end: void get_response () raises (WrongTransaction); boolean poll_response(); 2. Before 7.3.3, insert a section and renumber the following: 7.3.x poll_response /* C */ CORBA_boolean CORBA_Request_poll_response ( CORBA_Request, CORBA_Environment *); poll_response determines whether the request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether the response has completed or not. Values in the request are not changed. 3. Change the current 7.3.3 "get_response" to the following, except leave the last paragraph as is. //PIDL void get_response () raises (WrongTransaction); get_response returns the result of a request. | If get_response is called before the request has | completed, it blocks until the request has | completed. Upon return, the out parameters and return values defined in the Request are set appropriately and they may be treated as if the Request invoke operation had been used to perform the request. 4. In the current 7.3.4 "get_next_response" a. Change the C mapping code to the following: /* C */ CORBA_boolean CORBA_poll_next_response ( CORBA_Environment *); void CORBA_get_next_response ( CORBA_Request *req, CORBA_Environment *env ); b. After the Smalltalk mapping, add the following paragraph. poll_next_response determines whether any request has completed. A TRUE return indicates that it has; FALSE indicates it has not. Return is immediate, whether any response has completed or not. c. Remove the two paragraphs beginning with: "If the RESP_NO_WAIT flag..." "The following response flag is defined ..."
Actions taken:
December 18, 1996: received issue
March 5, 1999: moved from c-rev-wg to orb_revisiojn

Discussion:

Issue 499: Internationalization (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: New Idl types have been introduced to cover non-ISO code sets.Sec 5.4.1 indicates that where "generic strings" are required in a spec "wstring"should be used. Place holder in naming spec: Istring

Resolution: not interpretable, closed
Revised Text:
Actions taken:
February 12, 1997: received issue
February 12, 1997: issue logged
February 23, 1999: moved to orb_revision
February 26, 1999: closed issue

Discussion:

 moved to orb_revision

Issue 542: Interface Repository (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the Interface Repository spec, StructDef,UnionDef, and ExceptionDef should be derived from Container,since types can be defined within structs,unions,and exceptions according to IDL gram

Resolution: resolved, close issue
Revised Text: In section 6.5.10 add a sentence to the end of the first paragraph:"It can contain structs, unions, and enums." and change the IDL declaration (see corresponding archive file)
Actions taken:
April 15, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 545: Enums and enumerators (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

Resolution: issue closed, no change
Revised Text:
Actions taken:
April 10, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 551: Object::is_a (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Some ORBs are sloppy about existence. One ORB used raises INV_OBJREV whenever object doesn"t exist, even when server can be reached. Behavior is compliant..tighten spec here.

Resolution: close no change in 2.4
Revised Text:
Actions taken:
April 22, 1997: received issue
February 23, 1999: moved to orb_revision

Discussion:

Issue 556: OTS 1.1 specification changes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: OTS 1.1 spec doesn"t clearly say which module defines the TRANSACTION_REQUIRED, TRANSACTION_ROLLEDBACK, INVALID_TRANSACTION WRONG_TRANSACTION exceptions.

Resolution: resolved close issue
Revised Text: Add 3 lines to the end of 3.15.1 as follows: exception TRANSACTION_REQUIRED ex_body; exception TRANSACTION_ROLLEDBACK ex_body; exception INVALID_TRANSACTION ex_body. Add a new section 3.15.3, as follows: <find new section in corresponding archive file>
Actions taken:
April 28, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 557: WRONG_TRANSACTION (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: OTS 1.1 spec (page 10-17 and 10-18) is not clear whether the WRONG_TRANSACTION exception is intended to be a system exception or a user exception

Resolution: issue resolved, see revised text
Revised Text: Add a new paragraph at the end of 4.1 as follows. --> Find new paragraph in corresponding archives file
Actions taken:
April 28, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 563: Object terminal missing from IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Given the current IDL grammar, there is no way to parse any IDL containing the keyword "Object". It never appears in the grammar as a terminal symbol.

Resolution: resolved, closed in "97
Revised Text: Append a line to production (31) and (32) <base_type_spec>, as follows:"| <object_type>", and insert a new production between (31) and (32), as follows"(31a) <object_type> ::="Object"". also, append sentence to second para of 3.2.4 (see corresponding arc
Actions taken:
May 1, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 564: Description of constant expression semantics is unclear (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary:

Resolution: resolved, closed issue
Revised Text: replace 3rd para of 3.7.2 with the following (find full text in the corresponding archive file)
Actions taken:
May 1, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 565: Terminology consistency (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships?

Resolution: resolved closed issue
Revised Text: This issue is being addressed by the ORMSC in its revision of the OMA. When they complete the revision a new issue if necessary will be filed to bring the Core Chapters 1 and 2 in line with the new OMA. For now nothing should be done in this regard to the Core chapters pending the completion of the OMA revision
Actions taken:
May 20, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 566: OMG IDL prefix pragma (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: All standard OMG IDL including the CORE and all services have implicit #pragma prefix "omg.org". Make sure this appears intext of ALL IDL that is specified, particular in CORBAServices

Resolution: closed issue
Revised Text: Fixed by IOP 1.1
Actions taken:
May 22, 1997: received issue
June 20, 1997: closed issue

Discussion:

Issue 567: Scope and use of prefix pragma in IDL-style repository IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: There is confusion about effect of "prefix" pragma evident in the Interface Repository chapter. Whole notion of prefix should be explained more fully in section 6.6.1

Resolution: Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq
Revised Text: Close no change in 2.3a
Actions taken:
May 12, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 568: inherit vs. include (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Ther is sense in which an interface "includes" operations it inherits from its base interface.Does it also "include" types, constants, and exceptions?

Resolution: close issue with annotation fixed in Rev 2.2+
Revised Text:
Actions taken:
May 21, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 569: What exactly is a request (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: One may expect it to be a reply or response.Reading chapters 1,4,5 makes clear that it is the entirety of an invocation of an operation, including request and response. Change possible soon?

Resolution: Clarify the sense in which the term Request is used in section 1.2.2
Revised Text: Replace the second sentence of the first paragraph of section 1.2.2 by: "The term Request is broadly used to refer to the entire sequence of causally related events that transpires between a client intiating it and the last event causally associated with that initiation, e.g. the client receives the final response associated with that Request from the server, or the server carries out the associated operation in case of a oneway request, or the sequence of events associated with the Request terminates in a failure of some sort. The initiation of a Request is an event."
Actions taken:
May 20, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 570: "service"~~operation or interface? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Does a service consist of  single operation, or a collection of related operations, exceptions, types, and constants?

Resolution: Cleaning up the use of the word service throughout the document does not seem to be an achievable g
Revised Text: 1. In section 1.2.5 append the following phrase to the first sentence:
Actions taken:
May 20, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 571: Question about IDL grammar (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

Resolution: subsumed by issue 725
Revised Text:
Actions taken:
May 6, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 588: limited-length strings (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section?

Resolution: Incorporate change in 2.3a and close issue
Revised Text: � A string type, which consists of a variable-length array of characters
Actions taken:
May 29, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 595: Section 16.7: only C++ mapping defines string_free and string_dup (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Only the C++ mapping defines string_free and string_dup. Why are these methods not present in other language mappings? If they are generally applicable they should be added to the IDL

Resolution: They are C++ language specific helper functions, that is why they are in the C++ mapping section. T
Revised Text:
Actions taken:
July 9, 1997: recived issue
February 23, 1999: issue closed, no change

Discussion:

Issue 596: request() should be added to IDL (section 17.13.2) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The Object C++ mapping has an _request() method that is not in the IDL. This method should be added to the IDL

Resolution: The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed, no change

Discussion:

Issue 597: Sequence parameter specified is ignored (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Why does mapping ignore the sequence parameter specified in the IDL for the initialization service and split this single parameter into 2 separate ones in the mapping?

Resolution: That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping
Revised Text: Close no change in 2.3a
Actions taken:
July 9, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 598: sec 17.7.1: IDL for interface request doesn"t match C++ mapping (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The IDL for interface Request does not match the C++ mapping. There are a series od add_arg methods in the mapping that should be added to the IDL.

Resolution: Language mappings are allowed to have custom mappings for pseudo-interfaces.
Revised Text: Close no change in 2.3a
Actions taken:
July 9, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 604: Section 7.2: get_implementation function (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Why does Object have a get_implementation function instead of a readonly implementation attribute? (likewise for get_interface)

Resolution: closed issue, no change
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue, no change

Discussion:

Issue 607: No defined value for OBJECT_NIL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 7.2.3: reference is made to OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

Resolution: resolved, close issue
Revised Text:
Actions taken:
July 9, 1997: received issue
February 26, 1998: closed issue

Discussion:

Issue 609: TCKind enum should be updated (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.8: TCKind enum should be updated to include adopted IDL type extensions as follows: tk_longlong, tk_longdouble, tk_wstring, tk_wchar. Update DefinitionKind and PrimitiveKind enum

Resolution: Close, fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 610: create_exception() is declared outside any interface scope (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 6.8: The create_exception() methos is declared outside any interface scope. It seems logical to move it to Container Interface along with other create_XXX() methods

Resolution: Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 611: Syntax for basic types must be updated (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 3.8.1: The syntax for basic types must be updated to include the adopted IDL type extensions.

Resolution: Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 623: Section 7.8: editorial (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 7.8: ; is missing from definition of attribute policy_type

Resolution: Close, Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 624: Section 3.7.2: take new IDL type extensions into account (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The section states that the <<and>> operands must be in the range 0 to 32. Should be changed to 0 to 64 to take new IDL type extensions into account

Resolution: Close, Fixed in 2.2
Revised Text:
Actions taken:
July 9, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 641: Do identifiers and keywords clash if they differ in case? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section 3.2.3 and 3.2.4: It"s not said explicitly that an identifier may not differ from a keyword only in case since it differs only in case from a keyword

Resolution: Fixed in 2.2+, Close
Revised Text:
Actions taken:
July 30, 1997: received issue
June 25, 1998: closed issue
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 665: TypeCode equality (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: TypeCode equality is not very well-specified or portable.

Resolution: Incorporate more complete specification as shown below:
Revised Text: In section 3.8.2 following to the paragraph describing the any type:
Actions taken:
August 11, 1997: received issue
May 12, 1998: issue moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

: complete the changes that were intended in the resolution of issue 665 by adding 
the missing pieces in Chapter 15 
Revised Text: 
Page 15-23, first para following heading "Encoded Idnetifiers and Names": 

Change the para to read: 

        The Repository ID parameters in tk_objref, tk_struct, tk_union, 
        tk_enum, tk_alias, tk_except, tk_native, tk_value, tk_value_box 
        and tk_abstract_interface TypeCodes are Interface Repository 
        RepositoryId values, whose format is described in the specification 
        of the Interface Repository. For GIOP 1.2 onwards, repositoryID 
        values are mandatory. For GIOP 1.0 and 1.1, RepositoryId values are 
        required for tk_objref and tk_except TypeCodes; for tk_struct, 
        tk_union, tk_enum, and tk_alias TypeCodes RepositoryIds are 
        optional and encoded as empty strings if omitted. 

Actions taken: Send this issue with the recommendation to adopt the proposed 
resolution and revised text as above to the Interop RTF, with a strong

Issue 666: Native types with respect to typecodes, DII, DSI,Interface Reposit. (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details)

Resolution: Proposed resolution is to add representation of native type in the IR. Details below as proposed by
Revised Text: Here are the proposed extensions to allow native types in the IR. Our
Actions taken:
August 11, 1997: received issue
May 12, 1998: issue moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 675: Section 3.3.8.16:deactivate_object() operation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: Section states that the deactivate_object() operation doesn"t wait for etherialize operation to complete before it returns. This is impossible to implement in single-threaded ORB

Resolution:
Revised Text:
Actions taken:
August 13, 1997: received issue
February 25, 1999: moved to cxx_revision
March 8, 1999: moved from cxx_revision to orb_revision
October 30, 2000: resolved

Discussion:

 moved from cxx_revision to orb_revision

Issue 719: CDR encoding of TypeCode names inconsistent with equal operation (orb_revision)

Click here for this issue's archive.
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:

Issue 724: Non ASCII alphabetics in IDL identifiers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: IDL identifiers can contain non-ASCII alphabetic characters. None of the language maappings deals with this. To fix this restrict IDL identifiers to ASCII characters, digits and underscore

Resolution: Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character
Revised Text: All revisions refer to base document Rev 2.2+ i.e. Rev 2.2 as modified by ptc/98-03-03
Actions taken:
September 17, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 725: Octet and enum constants (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: IDL should permit enum and octet constants.

Resolution: The following changes add enum and octet constants to IDL:
Revised Text: Page 3-11, production 13:
Actions taken:
September 17, 1997: received issue
February 23, 1999: closed issue

Discussion:

:=

Issue 726: Figure 2-2 in CORBA 2.0 and CORBA 2.1 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary:

Summary: In the figure all the interfaces/skeletons/adaptors/stubs have either an Up-call or a Normal-call arrow or both with the exception of the Dynamic Skeleton which has neither

Resolution: Add an Up-Call Arrow to the Dynamic skeleton box.
Revised Text:
Actions taken:
September 18, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 727: Bug in the 2.1.spec for IDL unions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Table 3-11 on page 3-26 shows wchar as al legal switch type for unions. The grammar on page 3-26 doesn"t have wchar as a legal switchtype. The same is true for grammar on page 3-13. Is wchar legal for union discriminator? Spec will need to be fixed

Resolution:
Revised Text:
Actions taken:
October 17, 1997: received issue
May 6, 1999: moved from idltx to core RTF
October 30, 2000: closed issue

Discussion:

Issue 749: Issue with ObjectId_to_string and string_to_ObjectId (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Section 18.4 "illegal characters": It should be clarified what corresponds to the concept of "illegal characters". On the othe hand, do we want to specify that ObjectIds generated by the POA should not include those "illegal characters?

Resolution:
Revised Text:
Actions taken:
October 6, 1997: received issue
June 8, 1999: moved from C++ to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 751: Inclusion of standard exception (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary:   The proposal is to define a new standard exception, called
   EXTERNAL_ACCESS (the name is not important) that carries
   an any value.  Another alternative may be to re-define
   the exception COMM_FAILURE so that it may carry an any in
   addition to the existing minor and completed fields.

Resolution: close no change in 2.4
Revised Text:
Actions taken:
October 6, 1997: received issue
August 12, 1999: closed issue

Discussion:

Not clear that an RTF is the right place for  adding such featurelets. This should be added as part of some appropriate submission to some RFP.

Issue 753: Inheriting exceptions in IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: When writing IDL, why is it not possible to have an exception declaration inherit from another exception? It"s possible to have an interface inherit another interface, so it seems logical to derive an exception class from an already declared exception area

Resolution: close issue with no change with the above explanation.
Revised Text:
Actions taken:
October 23, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 754: Minor bug in 2.1 spec (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer

Resolution: incorporate changes in 2.3 and close this issue and 1066.
Revised Text: 1. Change Production 80 to remove <fixed_pt_type> as a valid parameter type:
Actions taken:
October 21, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 776: CORBA 2.1 IR Structdef typo (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: "Read Interface" section of 7.5.10: The second sentence is a typo. The StructDef as a whole can "contain" structs, unions, and enums. However, the members attribute is a CORBA IDL data type not a subtype of Container, and hence cannot "contain" anything in the sense used elsewhere in the IR spec. The sentence should be deleted

Resolution: Remove the second sentence in section 8.5.10 of Rev 2.2
Revised Text:
Actions taken:
October 30, 1997: received issue
February 23, 1999: closed issue

Discussion:

Issue 777: TypedefDef issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: Is it legal for a TypedefDef to contain another TypedefDef that is NOT mentioned in it"s "members" attribute? If not, should the IR spec explicitly forbid this?

Resolution: resolved, issue closed
Revised Text: StructDef, UnionDef, ExceptionDef, InterfaceDef, and ValueDef are derived from Container, but may only legally contain certain types of Interface Repository definitions. StructDef, UnionDef, and ExceptionDef objects may only contain StructDef, UnionDef, or EnumDef definitions. InterfaceDef and ValueDef objects may only contain TypedefDef (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions. Revised Text: Add the following text to the second paragraph of 10.5.4.2: Certain interfaces derived from Container may restrict the types of definitions that they may contain. Any create_<type> operation that would insert a definition that is not allowed by a Container will raise the BAD_PARAM exception with minor code 4. Add to the end of 10.5.10.2: A StructDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.11.2: A UnionDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.20.2: An ExceptionDef used as a Container may only contain StructDef, UnionDef, or EnumDef definitions. Add to the end of 10.5.23.2: An InterfaceDef used as a Container may only contain TypedefDef, (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions. Add to the end of 10.5.24.2: An InterfaceDef used as a Container may only contain TypedefDef, (including definitions derived from TypedefDef), ConstantDef, and ExceptionDef definitions.
Actions taken:
October 30, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 778: Proposed IFR exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {};   raised by create_* and move():  exception RIDAlreadyDefined {};    exception NameALreadyDefined {};

Resolution: Incorporate changes in 2.3a and close issue.
Revised Text: 1. In Chapter 3 section 3.17.2 table of minor codes add the following rows in the BAD_PARAM group:
Actions taken:
November 7, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 779: Containers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: On the issue of making StructDef, UnionDef, and ExceptionDef inherit from container, would it be possible to introduce the depreciation of including anything other than members in these three types?

Resolution: This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit
Revised Text:
Actions taken:
November 7, 1997: received issue
August 12, 1999: closed issue

Discussion:

Issue 780: RIDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: The definition of IDL Repository IDs the example in the IFR chapter 7.6.6 indicates that prefixes when not set are not separated. Definition says that "typically" it is the prefix and scoped name separated with "/".

Resolution: Fixed with sepcific example in section 10.6.5.2 in Rev 2.3
Revised Text: Close no change in 2.3a
Actions taken:
November 7, 1997: received issue
February 22, 1999: closed issue

Discussion:

Issue 783: IDL types are ambiguous with inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: What is the return type of parent(), short or long? The spec does not say whether the inherited ::y::y::z takes precedence, or whether it is ::x::z. The scope resolution rules don"t mention how to resolve such an ambiguity. The spec should be updated to state that ::x::z takes precedence (IDL example in corresponding archive "issue783")

Resolution: Close noting that this has been explained in Revised Chapter 3.
Revised Text:
Actions taken:
November 25, 1997: received issue
January 5, 1998: issue moved from C++ to ORB Revision
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 797: locally constrained (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: What is the consensus for the notation to use for interfaces to objects
 that are in the orb but not outside. We use to call them psuedo objects.
 During the last talk I got the feel that there are three options:
 
 1.	//PIDL
 2.      "psuedo" keyword placed before "interface"
 3.	//locally constrained

Resolution:
Revised Text:
Actions taken:
December 9, 1997: received issue
December 23, 1997: closed issue
December 23, 1997: moved issue to orb_revision
October 30, 2000: closed issue

Discussion:

Issue 811: union typecode (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: 1. The label value corresponding to a default label should be
 designated explicitly either as an ignored field whose size equals the
 size for the discriminator type, as some value that does not coincide
 with another label value, as reserverd for future use, or as absent
 (Table 12-2 and page 12-16, "encoding the tk_union Default Case" of
 IIOP 2.1).

Resolution:
Revised Text:
Actions taken:
December 23, 1997: received issue
December 29, 1997: closed issue

Discussion:

Issue 812: union typecode (02) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: 2. I cannot locate where the definition of typecodes for unions with
 members with multiple labels. The natural semantics with respect to
 the member accessor operations on that typecode and the CDR
 marshalling of that typecode would seem to be that the union
 declaration is treated as if the member definition in question were
 replicated once for each label.

Resolution:
Revised Text:
Actions taken:
December 23, 1997: received issue
March 26, 1998: closed issue

Discussion:

Issue 884: Appendix B lists incorrect CORBA Components IDs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: 1. Appendix B lists the CORBA Component IDs. This listing is
    incorrect: Proposed resolution: Change Appendix B to correspond to the
    main text.

Resolution: Proposed resolution: Change Appendix B to correspond to the
Revised Text:
Actions taken:
January 7, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 903: Ambiguity in non_existent() specification (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There is a minor ambiguity here. Consider the case where the ORB cannot
 make a reliable determination because the client-side run-time cannot
 reach the implementation repository or the server. In that case, most
 ORBs will raise a TRANSIENT or COMM_FAILURE exception. I can read the
 above words in the spec to mean that a compliant implementation of
 non_existent is allowed to hide the exception from me and return false
 instead.
 I suggest to amend the wording such that non_existent is obliged to propagate
 any exception other than OBJECT_NOT_EXIST back to the caller.

Resolution: Sugested text below , close issue
Revised Text:
Actions taken:
January 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 910: #pragma processing (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 7-32, the 2.1 spec says about #pragma processing:
 An IDL compiler must either interpret these annotations
 as specified, or ignore them completely.
 I don"t think this makes sense.
 If the prefix pragma isn"t honored in one ORB, but used by another ORB,
 the repository IDs will disagree for types generated from the same
 IDL definition, but with different IDL compilers. This in turn means
 that interoperability is destroyed.

Resolution: See resolution of 999 , close issue
Revised Text:
Actions taken:
January 23, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 911: Question about typecode creation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Consider the following operation in the ORB pseudointerface:
 
         TypeCode create_union_tc (
             in RepositoryId id,
             in Identifier name,
             in TypeCode discriminator_type,
             in UnionMemberSeq members)
 
 Suppose that in some mapping this is invoked with the given arguments,
 i.e. an id, a name, a discriminator_type, and members..
 For concreteness, suppose that the id argument has the value
 "IDL:foo/bar:1.0".
 
 There are three main cases:<<Go to issue archive>>

Resolution: Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i
Revised Text:
Actions taken:
January 21, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 912: Inheritance of Exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This is a request to add an optional extension to IDL which would
 permit an exception declaration to include a specification of the
 superexception or superexceptions for a given exception, exactly the
 same way superinterfaces may be specified when defining an interface.The advantage of this extension is that it (optionally) permits
 interface designers to organize exceptions into categories, which can
 help clarify the design of the exceptions.

Resolution: close issue, resolved
Revised Text:
Actions taken:
January 22, 1998: received issue
February 23, 1999: closed issue

Discussion:

 close issue, resolved

Issue 913: defined_in member of ModuleDescription for top-level module (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What is the value member of what is returned by
 CORBA::Contained::describe when invoked on a CORBA::ModuleDef object
 corresponding to a top-level IDL module?

Resolution: Incorporate change in 2.3 and close issue
Revised Text:
Actions taken:
January 21, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 915: Trader constraint language and international characters (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the trader constraint language (page 16-98, 2.1 spec) defines a
 character class "<other>". This class is used in the definition of
 what characters may appear inside a string literal (on page 16-97).
 The problem is that the definition limits the legal character values
 that may appear in a string literal. Only character positions 0x1
 to 0x7f are legal, anything else is illegal.

Resolution: Replace section B.2.3 with corresponding text from the ISO Trader standard
Revised Text: Replace section B.2.3 on page 16-97 of formal/97-12-23 by the following: "B.2.3 Character Set Issues The previous BNF has been complete up to the non-terminals <Leader>, <Follow>, <Alpha>, <Digit>, and <Other>. For a particular character set, one must define the characters which make up these character classes. Each character set which the trading service is to support must define these character classes. The character classes for the ISO Latin-1 character set are: <Leader> := <Alpha> <Follow> := <Alpha> | <Digit> | _ <Alpha> is the set of alphabetic characters(letters), as defined in ISO/IEC 14750 <Digit> is the set of digits [0-9] <Other> is the set of Latin-1 characters that are not <Alpha>, <Digit>, or <Special>"
Actions taken:
January 21, 1998: received issue
August 12, 1999: closed issue

Discussion:

Issue 916: Resetting #pragma prefix? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the spec doesn"t say how I can reset a repository ID prefix back to nothing
 after I have set it. Consider
 
 	#pragma prefix "dstc.edu.au"
 	interface foo {};
 	#pragam prefix ""		// Attempt to reset prefix
 	interface bar {};
 
 This doesn"t work with at least one ORB I have tried.

Resolution: See resolution of issue 999 , close issue
Revised Text:
Actions taken:
January 26, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 917: Incorrect definition of "object type" (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The definition of interface and object type in the Object Model
 are imprecise, if not incorrect.  [See section 1.2.5 of the Corba 2.1
 spec (Aug 1997)]

Resolution: Clarify as follows
Revised Text:
Actions taken:
January 27, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 918: CORBA::Contained::describe() underspecified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The describe() operation of the CORBA::Contained interface of the
 Interface Repository is under-specified in CORBA 2.1. (section 7.5.3
 on page 7-12).  The text should add that the "kind" field of the returned
 Description struct should give the DefinitionKind for the "most derived" 
 type of the object.  Without this, the spec can be read as allowing
 describe() to return a kind of dk_Typedef, or even dk_all!

Resolution: incorporate the proposed clarification
Revised Text:
Actions taken:
January 25, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 991: Operation to add to CORBA::ORB pseudo-object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: The following operations should be added to the CORBA::ORB
 pseudo-object:
 
 module CORBA {
         interface ORB {
 
                 ...
                 typedef sequence<octet> SerializedData;
                 typedef unsigned long   SerializedEncoding;
 
                 const SerializedEncoding CDR_ENCODING   = 0;
 
                 SerializedData  serialize(in Any data,
                                           in SerializedEncoding how);
                 Any             unserialize(in SerializedData data,
                                             in SerializedEncoding how);
                 ...
         };
 };

Resolution: Close no change in 2.4
Revised Text:
Actions taken:
March 4, 1998: received issue
August 12, 1999: closed issue

Discussion:

This issue is very unlikely to get resolved resolved through the RTF process. It was attempted once and it failed. Some of the objections were that it is inappropriate
to add such a complete featurelet through the RTF. It is probably better added through some submission to some RFP. It is therefore proposed that this issue be
closed.

Issue 992: CORBA 2.2 - "native" and the interface repository (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: Whilst implementing the POA I noticed that there were no extensions to
 the Interface Repository or TypeCodes to handle native types.
 
 The nett result appears to be that there is no way to express some of
 the POA interfaces in the Interface Repository. Obviously the native
 interfaces themselvse can"t be expressed, but nor can some of the IDL
 specified interfaces.
 
 e.g. ServantLocator has two operations (preinvoke and postinvoke) both
 of which have a Cookie listed as a parameter. There appears to be no way
 to generate a TypeCode for the Cookie (native) paramter and therefore no
 way to perform an InterfaceDef.create_operation to desribe either of
 preinvoke or postinvoke.

Resolution:
Revised Text:
Actions taken:
March 5, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 999: #pragma prefix issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: How does the scope of #pragma prefix interact with #include? Find details in the corresponding archive

Resolution:
Revised Text: The following text changes describe the resolution. Since vote 3 the changes to 8.6 have been added
Actions taken:
March 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1054: Marshalling is_equivalent (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.2 GIOP does not define a way to invoke is_equivalent on an object remotely

Resolution: close no change with above explanation
Revised Text:
Actions taken:
March 13, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1066: Fixed point constant typo in 2.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.7.2 of CORBA 2.2 contains an error on page 3-20, last para:
 
 	For example, 0123.450d is considered to be fixed<5.2> and
 	3000.00 is fixed<1,-3>.
 
 This is in conflict with section 3.2.5 on page 3-9, last para:
 
 	A fixed-point decimal literal consists of an integer part, a
 	decimal point, a fraction part and d or D. [ ... ]
 	Either the integer part of the fraction part (but not both)
 	may be missing; the decimal point (but not the letter d (or D))
 	may by missing.
 
 So, it seems that the "3000.00" on page 3-20 really should be
 "3000.00d" or "3000.00D".

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1067: Wide character and wide string literals (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.2.5 on page 3-9, 2nd para says:
 
 	Wide character and wide string literals are specified exactly
 	like character and string literals. All character and string
 	literals, both wide and non-wide, may only be specified
 	(portably) using the characters found in the ISO 8859-1 character
 	set, that is interface, names, operation names, type names, etc., will
 	continue to be limited to the ISO 8859-1 character set.
 
 - The first part says that wide character literals and wide string literals
   are to be specified exactly like character and string literals.
 
   This seems to be impossible - if they were exactly the same, there would
   be no point in having them... At any rate, the sentence seems to
   imply that I must restrict myself to ISO Latin-1 characters in
   wide literals.
 
 - The second part then says that wide literals are restricted to 8859-1,
   but that interface names (etc.) will continue to be limited to 8859-1.
 
   Now what is that supposed to mean? Interface names have always (and
   incorrectly) been limited to 8859-1. Nothing has changed. Am I to
   imply then that the sentence was meant to suggest that wide literals
   can actually contain wide characters other than 8859-1?
 
 This paragraph simply doesn"t make sense as it stands.

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1068: Fixed point constants issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 3-20 of CORBA 2.2:
 
 	A fixed-point literal has the apparent number of total and
 	fractional digits, except that leading an trailing zeros are
 	factored out, including non-significant zeros before the decimal
 	point. For example, 0123.450d is considered to be fixed<5,2> and
 	3000.00 is fixed<1,-3>.
 
 Apart from the fact that 3000.00 is not a fixed point constant literal,
 I"m confused about something else...
 
 If 3000.00d is fixed<1,-3>, then 3000.0000d is also fixed<1,-3>.
 
 These rules result in
 
 	3000.00d	being		fixed<1,-3>
 BUT
 	3000.01d	being		fixed<6,2>
 
 This doesn"t seem to make sense. If I bother to write the trailing zeros,
 surely I have a reason, namely, that I mean to use that scale. In other words,
 I think that
 
 	3000.00d	should be 	fixed<6,2>
 and
 	3000.0000d 	should be	fixed<8,4>
 
 Why are fractional trailing zeros thrown away but fractional trailing
 non-zeros retained?

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1071: Type of fixed point quotients (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

Summary: the 2.2 spec on page 3-20 defines the type of a fixed point division as:
 
 	fixed<(d1-s1+s2) + Sinf, Sinf>
 
 I"m having a problem with this: The type of the result cannot be known
 at compile-time because it depends on the actual values.
 
 This differs from the add, subtract, and multiplication operators,
 where the result type can be determined statically.
 
 There is a C++ mapping problem too. The C++ mapping uses a template
 type for fixed point, where the digits and the scale are template parameters
 (i.e. must be compile-time constants).

Resolution:
Revised Text:
Actions taken:
March 19, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1074: Typo in type code section (13.3.4) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 13-13, CORBA 2.2:
 
 	A "simple" parameter list has a fixed number of fixed length entries,
 	or a single parameter which is has its length encoded first.
 
 This should probably be
 
 	... single parameter which has is length encoded first.

Resolution:
Revised Text:
Actions taken:
March 19, 1998: received issue
June 25, 1998: closed issue

Discussion:

Issue 1086: How to deal with object identity (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m not quite sure where this should go, but there should be an explicit
 statement somewhere in the CORBA descriptions that states how to deal
 with object identity with respect to subscribe/unsubscribe schemes.
 
 The (language/CORBA/etc independent) pattern
     interface SomeSender {
         void addSomeListener( in SomeListener theListener );
         void removeSomeListener( in SomeListener theListener );
         ...
     }
 is very commonly found, and as far as I understand it (I might be wrong,
 but if so, it needs to be documented that this would be incorrect),
 SomeListener actually needs to implement a "is_identical( Object )"
 operation that would be called by the removeSomeListener() operation
 in order to find out which of the registered listeners should be removed.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1087: IDl "module" construct - IDL files (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: It appears that the IDL concept of a module is tightly bound to
 the storage of IDL statements in files. In other words, it does not
 seem to be possible to distribute IDL statements in the same logical
 module across multiple files. Consequently, few people use the
 concept, and name collisions occur sooner or later when trying to
 integrate systems that have not been developed by only one group.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1088: ORB_init (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 4-9 of CORBA 2.2:
 
 	ORBid strings other than the empty string are intended to be used
 	to uniquely identify each ORB used within the same address space
 	in a multi-ORB application.
 
 I don"t believe this is possible, mainly because the language mappings
 do not permit multiple ORB run-time libraries to be linked into the same
 address space.

Resolution:
Revised Text:
Actions taken:
March 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1091: Editorial issue, chapter 8 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: In the recap IDL at the end of chapter 8, there is a missing comma after
 the tk_except enumerator in the definition of TCKind.

Resolution:
Revised Text:
Actions taken:
March 21, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1094: Indentation on page 4-4 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: interface Object on page 4-4  shows:
 
 	interface Object {
 		ImplementationDef get_implementation();
 		InterfaceDef get_interface();
 		boolean is_nil();
 		Object duplicate();
 		void		release();
 		boolean			is_a(...);
 		boolean			non_existent();
 		boolean 		is_equivalent(...);
 		unsigned		long hash(...);		<======
 		// ...
 	};
 
 The first four declarations use no indentation, the fifth declaration
 uses one indentation level, and the final four declarations use a different
 indentation level. This could be tidied up a bit.

Resolution:
Revised Text:
Actions taken:
March 22, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1145: Forward declarations and inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL spec explains forward declarations at the end of section 3.5.2.
 However, it does *not* make the following illegal:
 
 	interface base;			// Forward declaration
 
 	interface derived: base {	// Should be illegal
 		// ...
 	};
 
 	interface base {
 		// ...
 	};
 
 The problem here is that a forward-declared interface is used as a base
 interface before the definition for that interface has been seen.
 In the absence of further words in the spec, this is legal, but clearly,
 it should be illegal (otherwise, I can"t use a single-pass compiler).

Resolution:
Revised Text:
Actions taken:
April 16, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 22, 1999: closed issue

Discussion:

Issue 1146: Semantics and standard exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec lists the standard exceptions in section 3.15.1.
 
 However, for many of these, there are no semantics specified anywhere.
 Instead, for the majority of standard exceptions, the *only* "semantics"
 are what is in the comments in section 3.15.1.
 We badly need an explanation of which standard exception indicates what
 error condition in the spec, otherwise we"ll never get agreement on which
 exception means what...

Resolution:
Revised Text:
Actions taken:
April 16, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 1153: Domain manager related specification shortcoming(s) (01) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 1) The specification lacks any operations for moving an object reference
 from one domain manager to another, thus making the domain manager
 abstraction less useful as a means for managing allocation of policies
 to groups of object references, the memberships of which change over a
 period of time.

Resolution: This issue is included in the mandatory requirements of the Security Domain Membership Management R
Revised Text:
Actions taken:
April 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1154: Domain Manager related specification shortcoming (02)-ConstructionPolicy (orb_revision)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Summary: 2) The associated ConstructionPolicy object does not provide any
 facility for allocating an object reference to any domain manager other
 than the domain manager to which the creator (if an object) belongs or a
 completely new domain manager.

Resolution: This issue is included in the mandatory requirements of the Security Domain Membership management R
Revised Text:
Actions taken:
April 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1155: Domain Manager related specification shortcomings (03) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 3) There is no way at present to implement the
 Object:get_domain_managers operation in an interoperable fashion. To fix
 this it seems a new GIOP message needs to be defined to carry the
 implicit get_domain_managers operation. There of course may be other
 ways to fix this. Some of the submitters of the original security spec
 saw domain managers as replicated objects such that a replica of it was
 present in each ORB instance where there was an object belonging to that
 domain manager was instantiated, thus relegating the problem of getting
 the domain manager information to the replication mechanism. Well, the
 hoped for replication facility has not happened yet and there is no
 other way to implement this interoperably. This needs to be fixed.

Resolution: get_domain_managers operation in an interoperable fashion. To fix
Revised Text:
Actions taken:
April 17, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1156: resolve_initial_references under-specified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: resolve_initial_references can raise an InvalidName exception. However,
 the text in section 4.5 does not attach any semantics to that exception
 (in fact, it does not mention the exception at all).
 
 The spec needs to state explicitly *when* InvalidName should be raised.
 Presumably, the intent was that it would be raised for unknown ObjectIds,
 such as "XXXX".

Resolution: Needs no further action in Core RTF. Close this issue no change.
Revised Text:
Actions taken:
April 17, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
August 19, 1999: closed issue

Discussion:

 This has been addressed in the submission that was accepted in response to the Interoperable Name Service RFP, and hence will be fixed in Core as
soon as that adopted spec is incorporated into Core

Issue 1160: GIOP typo, section 4.2 (page 4.4) of CORBA 2.2 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Section 4.2 (page 4.4) of the corba 2.2 spec defines a "non_existent" operation
 on CORBA::Object. In Section 13.4.1 (page 13-23) it sates that the operation
 name for such a request is encoded as the string "_not_existent". This latter
 string  looks like a typo, and we propose to change this (on page 13.23) to
 "_non_existent".

Resolution: :Object. In Section 13.4.1 (page 13-23) it sates that the operation
Revised Text:
Actions taken:
April 20, 1998: received issue
June 25, 1998: closed issue

Discussion:

 resolved, close issue

Issue 1164: Versioning by the back door? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"ve always been under the impression that CORBA does not have versioning.
 it looks like we
 actually *do* have versioning. Could someone please let me know what
 the correct interpretation should be? Has this versioning stuff sort
 of quietly snuck in via the back door?
 
 I find this section of the spec particularly stunning because a few pages
 earlier, it says about #pragma directives:
 
 	An IDL compiler must eithe rinterpret these annotations
 	as specified, or ignore them completely.
 
 So, on the one hand, we can happily ignore #pragma, and a few pages
 later, we go and add semantics to the version pragma?!

Resolution:
Revised Text:
Actions taken:
April 22, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1241: / in prefix pragma? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: currently, #pragma prefix is completely unconstrained and can contain
 any character. This includes potentially troublesome things such as space
 and "/", or non-printing characters.
 
 I would suggest to define a syntax for #pragma prefix. In particular, I think
 that "/" should be forbidden in a prefix. This is because otherwise, given
 a repository ID, I cannot work out where the prefix ends and the scoped
 name starts. In addition, things that cannot normally be part of file names
 or identifiers should probably be forbidden as well, otherwise we could
 get problems with things like the class path in Java.

Resolution:
Revised Text:
Actions taken:
April 27, 1998: received issue
June 25, 1998: moved from port-rtf to orb_revision
February 23, 1999: closed issue

Discussion:

Issue 1315: Semantics of system exception completion_status (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The CORBA 2.2 spec says the following about completion_status:
 
 Each standard exception also includes a completion_status code which
 takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}.
 These have the following meanings:
 
 COMPLETED_YES	The object implementation has completed processing prior
 to the
 		exception being raised.
 COMPLETED_NO	The object implementation was never initiated prior to the
 exception
 		being raised.
 COMPLETED_MAYBE	The status of implementation completion is
 indeterminate.
 
 These definitions do not cover the case where the standard exception was
 raised by the object implementation itself.

Resolution:
Revised Text:
Actions taken:
May 11, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 1394: Typos in IR IDL in spec (01) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The following problems appear in the 2.2 spec (98-02-23) and the IDL 
 summary extracted from it (98-03-01.idl).
 
 - Section 8.8 page 8-45: need forward declaration of ExceptionDef, i.e., 
 "interface ExceptionDef" before use on page 8-47. There are a number of 
 forward declarations in the middle of 8-45 that would seem to be the 
 logical place for it.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1395: Typos in IR IDL in Specification (02) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-47: need forward declarations of WstringDef and 
 FixedDef before use on page 8-48. Again, it would seem that they were 
 left out of the list of forward declarations on 8-47.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1396: Typos in IR IDL in Specification (03) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-48: remove incorrect "};" between "create_array" and 
 "create_fixed".

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1397: Typos in IR IDL in Specification (04) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-53: add "," after "tk_except" in definition of TCKind.

Resolution:
Revised Text: Fix and close
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 closed issue

Issue 1398: Typos in IR IDL in Specification (050 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: - Section 8.8 page 8-55: change "element type" to "element_type" in 
 operation create_sequence_tc.

Resolution:
Revised Text:
Actions taken:
May 20, 1998: received issue
February 23, 1999: closed issue

Discussion:

 received issue

Issue 1422: Does the DII support the standard object operations? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There are two types of standard operations:  ones that are transmitted
 over the wire, and ones that are not.  Now it seems reasonable to
 support the over-the-wire operations via the DII, such as "is_a",
 "non_existent", "get_interface" and "get_implementation" (obsolete), but
 what about the ones that don"t go over the wire:
 
 	hash
 	is_equivalent
 	get_policy
 	get_domain_managers
 
 I would guess that the DII should not support these operations, but the
 spec does not explicitly say that.  So, should we add a statement to the
 DII part of the spec that an attempt to invoke these non-over-the-wire
 operations should raise BAD_OPERATION?

Resolution:
Revised Text:
Actions taken:
June 2, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1537: Typo in chapter 8 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Table 8-1 on page 3-39 of the CORBA spec contains a typo.
 "tx_fixed" should be "tk_fixed".

Resolution:
Revised Text:
Actions taken:
June 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1541: Type code typos (as only one issue) (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: There are a few typos in the spec for type codes.
 
 Page 8-40:
 
 	A structure with N members results in a tk_struct TypeCode with
 	2N+1 parameters.
 
 This is no longer correct. Because of the Repository ID parameter that
 was added, this is now 2N+2.
 
 Similar fixes need to be applied to the text for unions (3N+3 parameters,
 not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by
 the text), and aliases (they have three parameters, not two).
 
 The text for tk_objref also needs updating, because it states that
 it has one parameter instead of two.
 
 Also, Table 7-1 for tk_objref should be updated because it is internally
 inconsistent.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1542: Type code operations under-specified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: On page 8-38:
 
 	Member_count [sic] returns the number of members
 	constituting the type.
 
 This is a little ambiguous and easily confused with the number of parameters.
 For clarity, I would suggest to add a sentence to make this clearer, e.g.
 "For example, the member count of a structure with three members is three."
 
 This would help to avoid confusion with parameters (if I am not careful,
 I might think the number is six, because a the three members of a structure
 are described by six parameters, or I might think that the number is nine,
 because a three-member structure has a total of nine parameters).
 
 The origin for the index to the member_name operation is never defined.
 Presumably, indexes start at zero? If so, this must be stated.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1543: Type code parameter ordering (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: 
 the TypeCode pseudo interface makes no mention about the order of parameters
 for structured types. For example, given the IDL struct
 
 	struct MyStruct {
 		char	c_mem;
 		string	s_mem;
 	};
 
 it is legal for member_name(0) to return "s_mem" and member_name(1) to
 return "c_mem" (provided member_type(0) returns a char type code and
 member_type(1) returns a string type code).
 
 The same comments apply to unions, exceptions, and enums, where the order
 in which members are presented is not necessarily the same order as in the IDL
 definition.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue

Discussion:

Issue 1545: Type codes cannot describe all unions (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Fix this by stating that member_label returns an Any containing
 a *sequence* of labels if a single member has more than label.
 
 Add a typedef to the TypeCode pseudo-IDL:
 
 	typedef sequence<any> LabelSeq;
 
 A sequence of this type would be contained in the Any returned by
 member_label() if a member has multiple labels (this avoids changing the
 signature of member_label()).
 
 For the above union, the member_count() operation would return 2, not 5.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1585: IDL struct issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: IDL structs are specified to have "one or more" members rather than
 "zero or more".
 
 Whilst it might be argued from a stylistic point of view that an empty
 struct is of limited use, of should be avoided, there are places where
 it may be desirable to specify a placeholder struct for later expansion,
 or for machine generated code where there happens to be nothing to fill
 the struct with.
 
 I can see no compelling technical reasons for requiring that a struct
 contain at least one member, so I propose that the grammar be revised to
 alow for a struct with zero members.
 
 Such a change would not break any existing IDL.

Resolution:
Revised Text:
Actions taken:
June 26, 1998: received issue
March 1, 1999: closed issue

Discussion:

Issue 1587: name scoping issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the course of a discussion Philippe Gautron pointed out to me that in
 ISO-C++, the scope of a class begins with its declaration, and hence a
 member or type declaration in the class  may not introduce the same name
 as that of the class, exception being constructors of the class.
 Analogous rules apply to struct and namespace. When this principle is
 extended to the case insensitivity of IDL a consequence is that
 
 	interface I {
 		void i();
 	};
 
 is illegal as is:
 
 	module M {
 		interface m {....};
 	};
 
 The basic rule is that the name of the scope, if it has one is
 implicitly inserted into the scope and hence cannot be reused for other
 purposes in that scope. Given that IDL has to be mapped to C++ this
 seems like an eminently reasonable restriction. However, I could not
 find this explicitly stated anywhere. Do y"all feel this is reasonable?
 If so, and if it is indeed not mentioned then I think we should add a
 line or two in 3.13 clarifying this?

Resolution:
Revised Text:
Actions taken:
June 26, 1998: received issue
March 1, 1999: closed issue

Discussion:

Issue 1612: Description of Wide String type (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Null termination is a marshalling and language mapping issue and should not
 appear as part of the semantic description of the IDL type. It should be
 completely valid for a language with a native wide string type to handle the
 varying length nature of the wide string with or without use of null
 termination and certainly without exposing it to the user. Therefore, the
 description of the wide string type in 3.8.3 should not mention null
 termination. 
 
 Also the syntax should be included.

Resolution:
Revised Text:
Actions taken:
June 29, 1998: received issue
February 23, 1999: closed issue

Discussion:

Issue 1622: TypeCode comparison proposal (01) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Points 1 through 9 need to be considered as one unit.  Point 10 can be
 voted on independently, but does provide a useful capability for
 controlling the size and content of TypeCodes.
 
 Proposal:
 
 1.  Make RepositoryIds mandatory for all TypeCodes that have them. [This
 was done by the previous core RTF.  I am just reiterating it here for
 completeness.]
 
 2.  All TypeCode constants generated by the IDL compiler, as well as all
 TypeCodes returned by the Interface Repository must include alias
 TypeCodes wherever a typedef declaration appears in the original IDL
 source.
 
 3.  Each IDL programming language mapping must provide a mechanism for
 the programmer to ensure that values of the IDL any type contain the
 exact typecode desired by the programmer.
 
 4.  The name() and member_name() fields of the TypeCode are for
 documentary purposes only, and are never considered significant when
 comparing TypeCodes.
 
 5.  Define a new equivalent operation for TypeCodes:
 
 pseudo interface TypeCode {
     ...
     boolean equivalent(in TypeCode other);
     ...
 };
 
 with the following semantics:
 
 a)  If the two TypeCodes are the same primitive type (null, void, short,
 long, ushort, ulong, float, double, boolean, char, octet, any, TypeCode,
 longlong, ulonglong, longdouble, wchar) then equivalent() returns true.
 
 b)  If the two TypeCodes are string, wstring or fixed with the same
 parameters (bounds, digits or scale) then equivalent() returns true.
 
 c)  If the two TypeCodes are both arrays or both sequences, with the
 same bounds and their component types are equivalent(), then
 equivalent() returns true.
 
 d)  If the two TypeCodes are both object references, return true if the
 their RepositoryIds are the same.
 
 e)  If the two TypeCodes are both structs, exceptions, unions, enums or
 aliases, and they have the same RepositoryId, then equivalent() returns
 true.  Note in this case that member TypeCodes are not compared.
 
 f)  If either or both of the TypeCodes have an empty RepositoryId, then
 equivalent() falls back to a structural comparison, and returns true if
 all members of the two TypeCodes also are equivalent(). This case will
 only occur when interoperating with an older ORB that does not yet
 require RepositoryIds as mandatory for these TypeCodes.   Note that the
 name() and member_name() fields are not used in this comparison.
 
 g)  Otherwise, equivalent() returns false.
 
 6.  The ORB uses TypeCode::equivalent for all internal TypeCode
 comparisons, such as for supporting any (and thus DII and DSI) and
 DynAny.
 
 7.  If the programmer needs to distinguish between a type and/or
 different aliases of that type, he can call TypeCode::id() and compare
 the RepositoryIds.
 
 8.  All DynAny insert & get operations do not consider aliases as
 significant.  The type() operation however, will return the TypeCode
 with all of the aliases intact, including type() from any DynAny member
 components.  DynAny::assign() and DynAny::from_any compare the internal
 TypeCode of the DynAny with the TypeCode of its argument using
 TypeCode::equivalent() and raise Invalid if equivalent() returns false.
 
 9.  The TypeCode::equal() operation is not used internally by the ORB
 and is deprecated.

Resolution:
Revised Text:
Actions taken:
July 1, 1998: received issue
July 1, 1998: closed issue

Discussion:

Issue 1623: TypeCode comparison proposal (02) (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 10.  Define two new operations on TypeCodes:
 
 pseudo interface TypeCode {
     ...
     TypeCode    get_compact_typecode();
     TypeCode    get_canonical_typecode();
     ...
 };
 
 TypeCode::get_compact_typecode() strips out all optional name & member
 name fields.  TypeCode::get_canonical_typecode() looks up the TypeCode
 in the Interface Repository and returns the fully fleshed-out TypeCode.
 If the top level TypeCode does not contain a RepositoryId, (such as
 array and sequence TypeCodes, or TypeCodes from older ORBs), then a new
 TypeCode is constructed by calling TypeCode::get_canonical_typecode() on
 each member TypeCode of the original TypeCode.  If the Interface
 Repository is unavailable, or does not contain the information needed,
 the call raises the INTF_REPOS system exception.

Resolution:
Revised Text:
Actions taken:
July 1, 1998: received issue
July 1, 1998: closed issue

Discussion:

Issue 1665: Lifetime of ORB and validity of ORB pointe (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: In CORBA 2.2 added the ORB::shutdown operation. What operations are
 valid during the potentially lengthy shutdown process while ongoing
 operations complete? What is the validity of the ORB reference after the
 shutdown? Is the ORB destroyed? Can a new ORB be reconstituted by
 ORB_init?
 
 This issue came up during the port-rtf discussion for CORBA 2.3. It goes
 beyond considerations for the POA so it should be addressed by
 orb_revision.
 r

Resolution: Fix the problem as described below
Revised Text: 1. Change the following text to ORB::perform_work() (Section 4.11.2) after the polling loop example: Once the ORB has shutdown, work_pending() and perform_work() will raise the BAD_INV_ORDER exception. An application can detect this exception to determine when to terminate a polling loop. 2. Change the text for ORB::run() (Section 4.11.3) to: This operation provides execution resources to the ORB so that it can perform its internal functions. Single threaded ORB implementations, and some multithreaded ORB implementations, need the use of the main thread in order to function properly. For maximum portability, an application should call either run() or perform_work() on its main thread. run() may be called by multiple threads simultaneously. This operation will block until the ORB has completed the shutdown process, initiated when some thread calls shutdown(). 2. Change the text for ORB::shutdown() (Section 4.11.4) to: This operation instructs the ORB to shut down, that is, to stop processing in preparation for destruction. Shutting down the ORB causes all object adapters to be destroyed, since they cannot exist in the absence of an ORB. Shut down is complete when all ORB processing (including request processing and object deactivation or other operations associated with object adapters) has completed and the object adapters have been destroyed. In the case of the POA, this means that all object etherializations have finished and root POA has been destroyed (implying that all descendent POAs have also been destroyed). If the wait_for_completion parameter is TRUE, this operation blocks until the shut down is complete. If an application calls shutdown(TRUE) in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. If the wait_for_completion parameter is FALSE, the shutdown may not have completed upon return. An ORB implementation may require the application to call run() or perform_work() after the shutdown(FALSE) has been called in order to complete the shutdown process. While the orb is in the process of shutting down, the ORB operates as normal, servicing incoming and outgoing requests until all requests have been completed. An implementation may impose a time limit for requests to complete while a shutdown is pending. Once an ORB has shutdown, invoking any operation on that ORB or any object reference obtained from that ORB will raise the BAD_INV_ORDER system exception with the OMG minor code 4, except for the reference management operations: duplicate(), release(), and is_nil(). 3. Add a new section (4.11.5) for the new ORB::destroy() operation: void destroy(); This operation destroys the ORB so that its resources can be reclaimed by the application. Any operation invoked on a destroyed ORB reference will raise the OBJECT_NOT_EXIST exception. Once an ORB has been destroyed, another call to ORB_init with the same ORBid will return a reference to a newly constructed ORB. If destroy() is called on an ORB that has not been shutdown, it will start the shutdown process and block until the ORB has shutdown before it destroys the ORB. If an application calls destroy() in a thread that is currently servicing an invocation, the BAD_INV_ORDER system exception will be raised with the OMG minor code 3, since blocking would result in a deadlock. For maximum portability and to avoid resource leaks, an application should always call shutdown() and destroy() on all ORB instances before exiting. 4. Add the following entries to the minor exception code table in section 3.17.2: SYSTEM EXCEPTION MINOR CODE EXPLAINATION BAD_INV_ORDER 3 Operation would deadlock. 4 ORB has shutdown.
Actions taken:
July 10, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1667: Proposal on floating point fixes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m preparing a proposal to "fix" fixed point types, but I"d like to
 outline what I am thinking before I have it completed, in order to give
 people a chance to comment.
 Michi has pointed out a few issues with the fixed point constant
 grammar, but I think I can resolve those pretty easily by making changes
 so that fixed point constants are only allowed to be defined using the
 syntax:
 
 const fixed FOO = 1.2D;
 
 Some people have expressed the idea that the fixed point type
 specification is lacking sufficient semantic content, and they are
 afraid that since different languages or even implementations of
 languages might do the math differently that portability or
 interoperability is affected.  Frankly, I don"t see the problem as
 serious for the CORE RTF.  In most cases, the fixed point type is mapped
 to the native fixed point facility of the language.  If that isn"t
 sufficiently robust to support stuff like banking applications, the CORE
 RTF can"t do much to fix it anyway.
 
 For the C++ RTF:
 
 For the C++ binding, of course, things are broken.  However, I think I
 may have a solution to the problem:
 
 First, define a new class CORBA::FixedValue which is used as the results
 of all of the Fixed arithmetic operations, as well as for the type for
 fixed point constants.  FixedValue would store the digits and scale
 information dynamically.  All of the defined fixed point types would be
 convertable from/to the FixedValue type, with the DATA_CONVERSION
 exception available to signal overflow.
 
 Second, get rid of the explicit reference to a template type.  Since the
 grammar will be changed to no longer allow anonymous fixed point
 declarations (as parameter types), there is no longer a specific need to
 define the exact type name for the Fixed types, and in fact,
 implementations no longer must implement fixed as a template type.

Resolution:
Revised Text:
Actions taken:
July 13, 1998: received issue
July 15, 1998: closed issue -- resolved by issue754

Discussion:

Issue 1679: DynStruct::get_members needs exception (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: If get_members is called on a DynStruct whose members have not been
 initialized, what should it do? It can"t return any values, because there
 are none.
 
 I suggest allowing it to raise DynAny::Invalid in this case. If there are
 objections to adding a raises clause, I suggest having it raise BAD_INV_ORDER.

Resolution: incorproate changes and close issue in 2.4
Revised Text:
Actions taken:
July 14, 1998: received issue
August 19, 1999: closed issue

Discussion:

Added TypeMismatch exceptions to deal with empty exceptions. 
Added types for DynAny. Added exceptions to deal with situations where there cannot be a member or 
where the current position does not indicate a member. 
Revised Text: see ptc/99-03-02

Issue 1688: Illegal IDL in CosTime module (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL in module CosTime for the compare_time and
 time_to_interval operations is illegal.  Reference
 http://www.omg.org/archives/experts/msg00890.html
 for further information.

Resolution:
Revised Text: //www.omg.org/archives/experts/msg00890.html
Actions taken:
July 16, 1998: revceived issue
February 23, 1999: closed issue

Discussion:

  All references to formal/97-12-21.pdf

Issue 1725: CosObjectIdentity::ObjectIdentifiers can"t be UUIDs? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Does anyone know why the CosObjectIdentity::ObjectIdentifier was changed
 from "typedef sequence<octet,16>" to "typedef unsigned long"? This
 happened some time ago between the 3/94 and 3/95 versions of the
 CosRelationships specification.
 
 It seems odd since the earlier version could support the 128 bit UUIDs
 used in DCE and the 128 bit GUIDs found in Microsoft but the current
 version is only one quarter the size. Also, all available literature I
 can find on the topic indicates that the 128 bit version is necessary
 for uniqueness "across space and time". In large distributed object
 environments, I don"t think the 32 bit version will cut it.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1728: Proposed change to IDL in section 3.10.2, page 3-32 "Parameter Declaration (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Firstly, in Section 3.10.2, "Parameter Declarations" on
 page 3-32, the last paragraph states:
 
         When an unbounded string or sequence is passed as an
         inout parameter, the returned value cannot be longer
         than the input value.
 
 This seems like an undesirable and unnecessary restriction to me.
 Is there any chance that you could remove this restriction in a
 future version of the specification? Alternatively, if there is
 a good reason for this restriction then perhaps you could document
 it in a future revision of the specification.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1729: Change to IDL for anonymous types (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Secondly, anonymous types are generally a pain to deal with
 for a language mapping. I know that anonymous sequences are
 a necessary evil because they are needed to define recursive
 structs and recursive unions. For example:
 
         struct node {
                 long            data;
                 sequence<node>  children;
         };
 
 However, IDL allows anonymous sequences and arrays to be used
 in other ways for which they are not essential.

Resolution:
Revised Text:
Actions taken:
July 23, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 1753: Size of IDL char (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary: The IDL chapter says on page 3-24:
 
 	OMG IDL defines a char data type that is an 8-bit quantity which...
 
 This seems to imply that chars must map to an 8-bit type in the target
 language. Not all CPUs can do this. For example, on a Cray, chars are a
 32-bit type.
 
 I would suggest to remove the size requirement.

Resolution:
Revised Text:
Actions taken:
July 30, 1998: received issue
February 22, 1999: closed issue, no action in 2.3a

Discussion:

Issue 1772: Incorrect LifeCycle IDL? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 6.2 of formal/98-07-05 mentions
 
 typedef Naming::Name Key;
 
 I believe it should be CosNaming::Name instead.

Resolution:
Revised Text:
Actions taken:
August 4, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1796: Missing orb.idl (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: It appears that during the editing for the POA changes for 2.2, Appendix A
 of the old BOA chapter was dropped without a trace. As a result, it looks
 like the definition for the orb.idl include file has disappeared.

Resolution:
Revised Text:
Actions taken:
August 11, 1998: received issue
February 22, 1999: closed issue

Discussion:

 Add the following text to Section 3.14, following the example IDL that shows

Issue 1797: Types defined in the CORBA module? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: Where am I supposed to pick up the types defined in the CORBA module,
 such as CORBA::Identifier, if I want to use them in my IDL?
 
 The (now apparently missing) orb.idl file gave me access to the
 TypeCode interface and the IFR interfaces, but mentioned nothing about
 other types defined in the CORBA module.

Resolution: :Identifier, if I want to use them in my IDL?
Revised Text:
Actions taken:
August 11, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1802: Multiple paths to a recursive sequence typecode (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

Summary: What exactly is the story for how the TypeCodes are created?  Is there
 one call to create_recursive_sequence_tc per recursive sequence template in the
 source, or one per cycle in the type graph?  I think this is worth clarifying
 in section 8.7.3, which doesn"t seem to conceive of the possibility of multiple
 type graph cycles through the same recursive sequence type.

Resolution: This was fixed in the process of resolving issue 1928 in Core Revision 2.3a. See resolution of 1928.
Revised Text:
Actions taken:
August 12, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1892: Nested scopes (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The name of an interface or a module may not be redefined within
 the immediate scope of the interface or the module. For example:
 
 module M {
 	typedef short M; // Error: M is the name of the module
 			    in the scope of which the typedef is.
 	interface I {
 		void i (in short j); // Error: i clashes with the interface name I
 	};
 };

Resolution: Incorporate changed text and close issue in 2.4
Revised Text: : (i) Editorial fixed in 2.3a (ii) extend the restriction to struct, union and exception to be consistent across the board. Revised Text: On page 3-48 of ptc/98-12-04 change the paragraph which currently reads: The name of an interface, value type, or a module may not be redefined within the immediate scope of the interface, value type, or the module. For example: To read: The name of an interface, value type, struct, union, exception or a module may not be redefined within the immediate scope of the interface, value type, struct, union, exception or the module. For example:
Actions taken:
August 27, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1893: page 3-47: Identifiers (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Page 3-47:
 
 	"Identifiers for the following kinds of definitions are scoped:
 
 		- types
 		- constants
 		- enumeration values
 		- exceptions
 		- interfaces
 		- attributes
 		- operations"
 
 I"m not sure I understand the purpose of this list. In particular, what
 is meant by "are scoped"? Scoped by what? I think the intent was to state
 that if any of these identifiers appears within a nested scope, it needs
 to be unique only within that nested scope?

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Replace the following text on page 3-47, 3-48 at the beginning of section 3.15.2: An entire OMG IDL file forms a naming scope. In addition, the following kinds of definitions form nested scopes: * module * interface * valuetype * structure * union * operation * exception Identifiers for the following kinds of definitions are scoped: * types * constants * enumeration values * exceptions * interfaces * valuetype * attributes * operations An identifier can only be defined once in a scope. However, identifiers can be redefined in nested scopes. An identifier declaring a module is considered to be defined by its first occurrence in a scope. Subsequent occurrences of a module declaration within the same scope reopen the module allowing additional definitions to be added to it. By the text: Contents of an entire OMG IDL file, together with the contents of any files referenced by #include statements, forms a naming scope. Definitions that do not appear inside a scope are part of the global scope. There is only a single global scope, irrespective of the number of source files that form a specification. The following kinds of definitions form scopes: * module * interface * valuetype * struct * union * operation * exception The scope for module, interface, valuetype, struct and exception begins immediately following its opening '{' and ends immediately preceding its closing '}'. The scope of an operation begins immediately following its '(' and ends immediately preceding its closing ')'. The scope of an union begins immediately following the '(' following the keword "switch", and ends immediately preceding its closing '}'. The appearance of the declaration of any of these kinds in any scope subject to semantic validity of such declaration, opens a nested scope associated with that declaration. An identifier can only be defined once in a scope. However, identifiers can be redefined in nested scopes. An identifier declaring a module is considered to be defined by its first occurrence in a scope. Subsequent occurrences of a module declaration with the same identifier within the same scope reopens the module and hence its scope, allowing additional definitions to be added to it.
Actions taken:
August 27, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1928: Proposal for creating recursive TypeCodes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: We have spent some time pondering the various issues surrounding
 recursive TypeCodes and OBV, and have come up with a proposed
 solution.  This is not a formal proposal (it does not include actual
 changes to the CORBA spec) and is intended mostly to promote
 discussion.
 
 For this discussion a recursive TypeCode is defined as a TypeCode
 which contains data members which refer to the containing type or any
 type containing the containg type.
 
 The basic problem of creating recursive TypeCodes has become more
 complex with the addition of valuetypes.  The current mechanism for
 creating TypeCodes (as adopted by the last RTF) cannot create
 TypeCodes for a large number of cases, and can be quite confusing.
 The new proposal solves the problem of creating recursive TypeCodes in
 general and would deprecate all existing mechanisms for creating
 recursive TypeCodes.

Resolution:
Revised Text:
Actions taken:
September 2, 1998: received issue
February 22, 1999: closed issue

Discussion:

Issue 1944: Typo on pages 10-53, 10-55, and 10-70 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The create_value_tc() api and C++ example use ValueMembersSeq, but the name
 should match the ValueMemberSeq ( no "s" after Member) definition given on page
 10-33 & 10-65

Resolution:
Revised Text:
Actions taken:
September 11, 1998: received issue
September 21, 1998: closed issue

Discussion:

Issue 1950: deactivate_object page no: 9-35 (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: deactivate_object page no: 9-35
 
 void deactivate_object(in Objectid oid) 
   raises (ObjectNotActive,WrongPolicy)
 
 If a servant manager is associated with the poa, ServantLocator:: etherealize will be invoked  with the oid and the servant.
 It should be ServantActivator::etherealize instead of ServantLocator:: etherealize.
 
 The Note of deactivate object it should be ServantActivator::etherealize  instead of ServantLocator:: etherealize

Resolution:
Revised Text:
Actions taken:
September 15, 1998: received issue
September 29, 1998: close issue

Discussion:

:etherealize instead of ServantLocator:: etherealize.

Issue 1967: New proposal for recursive TypeCode creation (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The basic problem of creating recursive TypeCodes has become more
 complex with the addition of valuetypes.  The current mechanism for
 creating TypeCodes (as adopted by the last RTF) cannot create
 TypeCodes for a large number of cases, and can be quite confusing.
 The new proposal solves the problem of creating recursive TypeCodes in
 general and would deprecate all existing mechanisms for creating
 recursive TypeCodes.

Resolution:
Revised Text:
Actions taken:
September 17, 1998: received issue
November 3, 1998: closed issue

Discussion:

Issue 1969: Handling of minor codes for standard exceptions underspecified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Looking at ptc-98-08-07, I find the discussion of minor codes hopelessly
 underspecified.  The text in 3.17.2 doesn"t actually mention the OMG
 space explicitly; it should.  Also, the definition of the partitioning
 of the minor code, at the beginning of 3.17, is hopelessly vague -- what
 ``high order bits"" are used, what ``low order bits""?  What"s the
 policy for obtaining a new vendor registration?

Resolution: I believe that this issue has been adequately addressed in the 2.3a revision. So I propose that we c
Revised Text:
Actions taken:
September 23, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1970: set_servant_manager (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: What exception should POA::set_servant_manager raise if the wrong servant
 manager type is passed? For example, if a POA has RETAIN and I try to
 register a ServantLocator, should set_servant_manager raise WrongPolicy, or
 some system exception? With respect to set_servant_manager, the spec says
 
 "This method requires the USE_SERVANT_MANAGER policy; if not present, the
 WrongPolicy exception is raised."
 
 Because WrongPolicy is used to denote whether set_servant_manager can be
 called correctly or not, it seems like the wrong exception to also use for
 the case of passing the wrong servant manager type. May I suggest that
 BAD_PARAM be raised in that case instead?

Resolution: Incorporate change in 2.4 and close issue.
Revised Text: The OBJ_ADAPTER exception should be raised in this case. The reasoning for this is as follows: I think the cases can best be shown in a table: Policies Servent manager Arg Narrowable to Servant Activator Servent manager Arg Narrowable to Servant Locator Servent manager Arg Narrowable to Other USE_SERVENT_MANAGER & RETAIN (ok) OBJ_ADAPTER OBJ_ADAPTER USE_SERVANT_MANAGER & NON_RETAIN OBJ_ADAPTER (ok) OBJ_ADAPTER not(USE_SERVANT_MANAGER) WrongPolicy WrongPolicy WrongPolicy The columns are the cases of what type the argument to set_servant_manager can be narrowed to. It would be weird but (at least theoretically) possible for the argument to have its most derived type be ServantManager or some other derived type. That is the last column. The rows are cover relevant combinations of poa policies. In the cells are my proposals for what exception should be raised. The two cells marked (ok) are the only ones where the call works without exception. I have used OBJ_ADAPTER rather than BAD_PARAM for the reasons already discussed in the archive. Revised Text: In section 11.3.8.11 (set_servant_manager), add an additional paragraph between the first and second (last) paragraph: "If the ServantRetentionPolicy of the POA is RETAIN, then the ServantManager argument (imgr) shall support the ServantActivator interface. (E.g. in C++ imgr is narrowable to ServantActivator.) If the ServantRetentionPolicy of the POA is NON_RETAIN, then the ServantManager argument shall support the ServantLocator interface. If the argument is nil, or does not support the required interface, then the OBJ_ADAPTER exception is raised."
Actions taken:
September 24, 1998: received issue
August 19, 1999: closed issue

Discussion:

Issue 1972: Missing equality for DynAny (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Type DynAny has no equality operator. This makes it impossible
 to determine whether or not two DynAnys contain the same value, unless
 I am prepared to recursively iterate over all of a DynAny"s components
 to determine whether they are equal. This is rather inconvenient.
 
 I would suggest to add a new operation to DynAny:
 
 	boolean equal(in DynAny da);

Resolution: added comparison operator
Revised Text: see ptc/99-03-02
Actions taken:
September 30, 1998: received issue
August 19, 1999: close dissue

Discussion:

Issue 1974: DynUnion::member() (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What does DynUnion::member() return if a union does not have a default
 case label and has no active member? A nil reference? A DynAny
 with TCKind tk_null?
 
 It"s not specified, but should be.

Resolution: incorporate change and close in 2.4
Revised Text: see ptc/99-03-02
Actions taken:
September 17, 1998: received issue
August 19, 1999: closed issue

Discussion:

 Revision of DynUnion fixes this problem

Issue 1981: Which OBV initialiser to run is under-specified (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: Detail: The 2.3 draft says:
 
   There may be any number of init declarations, as long as the signatures 
   of all the initializers declared within the same scope are unique.
 
 To me, this implies that initialiser selection is done by matching the actual call parameter types against the formal parameter types in all the initialisers, and choosing the one that applies. However (a) this isn"t said explicitly and (b) if it is the intention, it"s fairly easy to construct a case where no one initialiser is more applicable than any other. Assuming initialiser parameters are allowed to be interface types (it doesn"t say they aren"t), consider a declaration of two initialisers in the same scope with parameter interfaces A and B, then calling the initialiser with a parameter of C, an interface that inherits from both A and B. It is impossible to say that one initialiser is more or less applicable than the other. The specification should make clear what choice a compliant ORB should make.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: The solution is to eliminate the possibility of there being a question of which initializer to call in the face of polymorphism. In effect, outlawing the potential overloading implied by the current design. The proposal requires the IDL designer to specify a unique name for the initializer. The syntax is changed to be: factory <identifier> ( <in_parameter_list> ) Language mappings specify how the <identifier> is mapped to a method in the target language. Normally this would wind up being a create operation of some kind on the value factory. Changes are specified against the draft CORBA2.3a document. Revised Text: 1. In section 10.5.24 ValueDef Add a new field to Initializer struct Initializer { StructMemberSeq members; Identifier name; }; 2. Make the same change in 10.8 3. In Section 5.2.5.2 change Value instance -> Value type 4. In the example change the initializer to: factory init(in string name, in string SSN); 5. In Section 3.4 OMG IDL Grammar In production 24 <init_dcl> change "init" to "factory" <identier> 6. In Section 3.8.5 Initializers Change "init" to "factory" <identifier> Replace the 2 descriptive paragraphs by the following single paragraph: In order to ensure portability of value implementations, designers may also define the signatures of initializers (or constructors) for non abstract value types. Syntactically these look like local operation signatures except that they are prefixed with the keyword "factory", have no return type, and must use only in parameters. There may be any number of factory declarations. The names of the initializers are part of the name scope of the value type. 7. In 3.8.1.6 Value Type Example Change the initializer to "factory" init(....) 8. In Section 3.2.4 Keywords remove "init" as a keyword. add "factory" as a keyword.
Actions taken:
September 20, 1998: received issue
February 26, 1999: moved from obv-rtf to orb_revision
August 19, 1999: closed issue

Discussion:

Issue 1997: What does interface substitutability mean in CORBA? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA
 revision work that is going on in ORMSC about what the ORB vendors think
 "substitutability" means.

Resolution:
Revised Text:
Actions taken:
September 29, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2000: OMG VMCID (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Well, it looks like I get to choose what OMG"s VMCID is going to be. My
 > current thoughts are to allocate 65613 as OMG"s VMCID. This will make
 > the minor code value unsigned long appear on the wire as \x00, "M",
 > \x0<e>, <E>; where <e> is the high four bits of the minor code and <E>
 > is the lower 8 bits of the minor code.

Resolution:
Revised Text:
Actions taken:
September 29, 1998: received issue
September 30, 1998: closed issue

Discussion:

 non-issue

Issue 2007: TypeCode constants for bounded strings? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.2 has the following sentences near the beginning of section
 8.7.2:
 
 In the case of an unnamed, bounded string type used directly in an
 operation or attribute declaration, a TypeCode constant named
 TC_string_n, where n is the bound of the string is produced. (For
 example, "string<4> op1();" produces the constant "TC_string_4".)
 
 CORBA 2.3 is missing these sentences.

Resolution:
Revised Text:
Actions taken:
September 28, 1998: received issue

Discussion:

Issue 2034: Recursive IDL types (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The current spec is not terribly clear on how recursive IDL types are
 supposed to work.A minor problem here is that the terminating semicolon is missing following
 the closing curly brace.
 
 But more seriously, it leaves it open whether, for example, the following
 is legal:
 
 	struct foo {
 		union u switch (long) {
 		case 0:
 			sequence<foo> foo_mem;
 		case 1:
 			char c_mem;
 		} u_mem;
 
 		long l_mem;
 	};

Resolution:
Revised Text:
Actions taken:
October 5, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2070: InconsistentTypeCode exception in CORBA 2.3 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The current CORBA 2.3 ORB interface chapter (ptc/98-08-08) does not 
 match the resolution which was voted on for the InconsistentTypeCode
 exception (issue 1089).
 
 The proposed resolution from ptc/98-05-01 was to place the exception
 in the ORB interface with InvalidName, not in the CORBA module.
 Jishnu, could we correct this mistake by moving InconsistentTypeCode
 from the CORBA module into the ORB interface?

Resolution: Already fixed in 2.3a Draft
Revised Text:
Actions taken:
October 10, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2084: Recursive exceptions? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Is the following IDL legal?
 
 	exception e {
 		sequence<e> e_seq;
 	};
 
 The grammar permits it, so from that, I would have to conclude it"s legal.
 However, not all ORBs I"ve tried can handle this -- some accept it and it
 works, others accept it but generate bad code, and yet others won"t compile
 the IDL.

Resolution:
Revised Text:
Actions taken:
October 15, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2119: long double problem? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: (2.2 3-24) and (2.2 13-8)
 I"m no floating point expert, but it seems to me that these two
   definitions are inconsistent. The first implies 1 + 15 + 64 = 80
   bits of information, while the second implies 1 + 15 + 112 = 128 bits
   of information.

Resolution: No inconsistency exists as explained in the archive.
Revised Text:
Actions taken:
October 23, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2156: Exception for abstract interface inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Abstract interfaces can only inherit from other abstract interfaces,
 yet the Interface Repository chapter (98-10-08) does not define the
 behavior of an InterfaceDef object when an attempt is made to violate
 this rule.
 
 Text should be added to section 10.5.23.2 defining the behavior of
 the mutators is_abstract and base_interfaces.
 
 Since none of the BAD_PARAM minor codes really apply, it appears
 that a new one is needed.

Resolution:
Revised Text:
Actions taken:
November 2, 1998: receive dissue
October 30, 2000: closed issue

Discussion:

Issue 2162: void * in DII Chapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Now that we have the native type, it is time to replace those void *s in
 the DII specification PIDL and restate them in terms of native types.

Resolution: Incorporate changes in text and close issue.
Revised Text: Resolution: void * is used in four places in Chapter 7 to denote an opaque value which is interpreted in an implementation language specific way to get hold of a value to associate with a Request or an NVList. Essentially it is as if a native type were defined as follows: native OpaqueValue; and used to type those parameters. It happens so that in the C language mapping OpaqueValue maps to void *. SO it is proposed to introduce the native type OpaqueValue and state that individual language mappings map it to whetever is appropriate for that language. We should raise an issue with each language mapping RTF to revise the appropriate pieces of those chapters to align with the "native" terminology. Revised Text: 1. In IDL on top of page 7-5, insert the first line in module CORBA to read: native OpaqueValue; 2. In IDL on top of page 7-5, replace the following line: in void * value, // argument value to be added by the line: in OpaqueValue value, // argument value to be added 3. Immediately preceding section 7.2.1 insert the following paragraph: "In IDL, The native type OpaqueValue is used to identify the type of the implementation language representation of the value that is to be passed as a parameter. For example in the C language this is the C language type "void *". Each language mapping specifies what OpaqueValue maps to in that specific language". 4. In section 7.2.2 on page 7-7 in IDL for add-arg replace the line in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added 5. On page 7-11 section 7.4 in the IDL for NVList::add-item replace the line: in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added 6. On page 7-12 section 7.4.2 in IDL for add_item replace the line: in void * value, // argument value to be added by the line in OpaqueValue value, // argument value to be added
Actions taken:
November 3, 1998: received issue
November 3, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2200: Typo in POA (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On P. 11-52 I see:
 
    ...Assuming the POA has the USE_SERVANT_MANAGER policy and no servant
    manager is associated with a POA, any request received by the POA for
    an Object Id value not present in the Active Object Map will result
    in an OBJECT_NOT_EXIST exception.
 
 However on P. 11-9:
 
   If the POA has the USE_SERVANT_MANAGER policy, a servant manager
   has been associated with the POA so the POA will invoke incarnate or
   preinvoke on it to find a servant that may handle the request. (The
   choice of method depends on the NON_RETAIN or RETAIN policy of the
   POA.) If no servant manager has been associated with the POA, the POA
   raises the OBJ_ADAPTER system exception.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: The issue is clearly valid - there is an inconsistency that needs to be removed. The only choice is whether to make the exception be OBJECT_NOT_EXIST or OBJ_ADAPTER. I agree with the submitter of the issue that it should be OBJ_ADAPTER. My reasoning is that error should be obviously different than the case where the servant manager is present but does not want to provide a servant. This is an internal error in the implemenation of the server, and the client ought to be able to easily tell the difference. Revised Text: In the second paragraph of 11.6.4 (first paragraph on pg 11-52), replace "OBJECT_NOT_EXIST" with "OBJ_ADAPTER".
Actions taken:
November 9, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2202: Scoping resolution for member names (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The wording of the current 2.3 spec says nothing to suggest that member names in structs are in (or
 out) of the scope of the struct.  That is, whether
 
   struct s {
     struct t {...} t;
   };
 
 is legal or illegal.

Resolution: Close this issue in 2.4 noting that the resolution of issue 1893 subsumes this issue.
Revised Text: The resolution of 1893 takes care of the problem described in this issue by precisely stating where the scope of a struct (among other constructs) begins and where it ends. In particular struct s { struct t { ... } t; }; is illegal.
Actions taken:
November 10, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2206: Need namespace for Policy Type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: To allow vendors to define their own value added Policies, the
 PolicyType should be partitioned into spaced that can be assigned to
 vendors.  Since the PolicyType is a CORBA long, just like the system
 exception minor code, we can just reuse the VMCID for this purpose.

Resolution: resolved and closed
Revised Text: Resolution: Do it, using essentially the same space as VMCID, ensuring that the appropriate blocks of values that are reserved for experimental and OMG allocated VMCIDs and VPVIDs are honored in the allocation of either. Also point out that getting an allocation of VMCID results in the allocation of the same value as VPVID to the vendor. Take note of the following facts: (i) PolicyTypes associated with adopted standards have already been allocated in the "0" space. (ii) VMCID of 0 is used widely for experimental use (iii) The VMCID OMGVMCID is reserved for the use of OMG hence the same VPVID value should be reserved by OMG (but perhaps not used). (iv) Propose that VMCID/VPVID of 1 - \xf be reserved for OMG use. (v) Propose that \xfffff be reserved for experimental use. Revised Text: 1. Replace the following text in section 4.9.1 on page 4-21: PolicyType defines the type of Policy object. The values of PolicyTypes are allocated by OMG. New values for PolicyType should be obtained from OMG by sending mail to request@omg.org. In general the constant values that are allocated are defined in conjunction with the definition of the corresponding Policy object. by: PolicyType defines the type of Policy object. In general the constant values that are allocated are defined in conjunction with the definition of the corresponding Policy object. The values of PolicyTypes for policies that are standardized by OMG are allocated by OMG. Additionally, vendors may reserve blocks of 4096 PolicyType values identified by a 20 bit Vendor PolicyType Valueset ID (VPVID) for their own use. PolicyType which is an unsigned long consists of the 20-bit VPVID in the high order 20 bits, and the vendor assigned policy value in the low order 12 bits. The VPVIDs 0 through \xf are reserved for OMG. All values for the standard PolicyTypes are allocated within this range by OMG. Additionally, the VPVIDs \xfffff is reserved for experimental use and OMGVMCID (ref) is reserved for OMG use. These will not be allocated to anybody. Vendors can request allocation of VPVID by sending mail to tag-request@omg.org. When a VMCID (ref) is allocated to a vendor automatically the same value of VPVID is reserved for the vendor and vice versa. So once a vendor gets either a VMCID or a VPVID registered they can use that value for both their minor codes and their policy types. 2. In section 3.17 on page 3-52 of ptc/98-12-04, replace the paragraph that reads: "Within a vendor assigned space, the assignment of values to minor codes is left to each ORB implementation." by: Within a vendor assigned space, the assignment of values to minor codes is left to the vendor. Vendors may request allocation of VMCIDs by sending email to tag-request@omg.org. The VMCID 0 and \xfffff are reserved for experimental use. The VMCID OMGVMCID (re) and 1 - \xf are reserved for OMG use.
Actions taken:
November 11, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2214: create_policy specification needs to be completed (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The specification of the create_policy operation in Chapter 4 section
 4.9.2 (ptc-98-10-05, 5 November 98) is missing the following important
 elements:
 
 1. There is no specification of what is expected of someone who is
 defining a new policy type, in order to use this operation as the
 factory for policy objects of that type.
 
 2. Policy objects of wich of the PolicyTypes can be created using this
 operation in release 2.3 is not specified. Consequently, the types that
 are valid as input through the "val" parameter are unspecified also.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Insert two new sections 4.9.5 and 4.9.6 as follows: 4.9.5 Specification of New Policy Objects When new PolicyTypes are added to CORBA specifications, the following details must be defined. It must be clearly stated which particular uses of a new policy are legal and which are not: o Specify the assigned CORBA::PolicyType and the policy's interface definition. o If the Policy can be created through CORBA::ORB::create_policy, specify the allowable values for the any argument 'val' and how they correspond to the initial state/behavior of that Policy (such as initial values of attributes). For example, if a Policy has multiple attributes and operations, it is most likely that create_policy will receive some complex data for the implementation to initialize the state of the specific policy: //IDL struct MyPolicyRange { long low; long high; }; const CORBA::PolicyType MY_POLICY_TYPE = 666; interface MyPolicy : Policy { readonly attribute long low; readonly attribute long high; }; If this samply MyPolicy can be constructed via create_policy, the specification of MyPolicy will have a statement such as: "When instances of MyPolicy are created, a value of type MyPolicyRange is passed to CORBA::ORB::create_policy and the resulting MyPolicy's attribute 'low' has the same value as the MyPolicyRange member 'low' and attribute 'high' has the same value as the myPolicyRange member 'high'. o If the Policy can be passed as an argument to POA::create_POA, specify the effects of the new policy on that POA. Specifically define incompatibilities (or inter-dependencies) with other POA policies, effects on the behavior of invocations on objects activated with the POA, and whether or not presence of the POA policy implies some IOR profile/component contents for object references created with that POA. If the POA policy implies some addition/modification to the object reference it is marked as "client-exposed" and the exact details are specified including which profiles are affected and how the effects are represented. Typically, the Messaging::TAG_POLICIES component is used to carry this information. o If the Policy can be set within a client to tune the client's behavior, specify the policy's effects on the client specifically with respect to (a) establishment of connections and reconnections for an object reference; (b) effects on marshaling of requests; (c) effects on insertion of service contexts into requests; (d) effects upon receipt of service contexts in replies. In addition, incompatibilities (or inter-dependencies) with other client-side policies are stated. For policies that cause service contexts to be added to requests, the exact details of this addition are given. o If the Policy can be used with POA creation to tune IOR contents and can also be specified (overriden) in the client, specify how to reconcile the policy's presence from both the client and server. It is strongly recommended to avoid this case! As an excercise in completeness, most POA policies can probably be extended to have some meaning in the client and vice versa, but this does not help make usable systems, it just makes them more complicated without adding really useful features. There are very few cases where a policy is really appropriate to specify in both places, and for these policies the interaction between the two must be described. o Pure client-side policies are assume to be immutable. This allows efficient processing by the runtime that can avoid re-evaluating the policy upon every invocation and instead can perform updates only when new overrides are set (or policies change due to rebind). If the newly specified policy is mutable, it must be clearly stated what happens if non-readonly attributes are set or operations are invoked that have side-effects. o For certain policy types, override operations may be disallowed. If this is the case, the policy specification must clearly state what happens if such overrides are attempted. 4.9.6. Standard Policies Table xxx below lists the standard policy types that are defined by various parts of CORBA and CORBA Services in this version of CORBA Policy Type Policy Interface Definion in section/page Uses create_policy? <OMG editing staff, complete with all current standard policies before publishing>
Actions taken:
November 16, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2218: WRONG_TRANSACTION (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: WRONG_TRANSACTION Exception
 
 	The CosTransactions module adds the WRONG_TRANSACTION exception
 	that can be raised by the ORB when returning the response to a
 	deferred synchronous request. This exception is defined in Chapter 4
 	of the Common Object Request Broker: Architecture and Specification.
 This para doesn"t state what module is to be used for
 	  WRONG_TRANSACTION. I assume what is meant is that it should be
 	  a system exception?
 
 	- I can"t find this exception in either chapter 4 or chapter 3
 	  of the 2.3 spec. Looks like it needs to be added. I don"t know
 	  why the above para refers to chapter 4 though -- it seems that
 	  this exception should be added to the list of system exceptions
 	  in chapter 3?

Resolution: issue merged with issue1963
Revised Text:
Actions taken:
November 17, 1998: received issue
November 18, 1998: issue closed, merged with issue 1963

Discussion:

Issue 2221: Core uses both "standard" and "system" exception terminology (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The core chapters (chapter 3, for example) uses both "standard" and
 "system" to describe the same class of exceptions.  Most of the core
 seems to prefer "standard", however the C++ language mapping uses
 SystemException.
 
 The core should be cleaned up to use "standard" as the normal term, and
 then state that "system" is used in some language mappings as a synonym.

Resolution:
Revised Text:
Actions taken:
November 19, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2223: Local operations on CORBA::Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Basically, people get confused about which operations on CORBA::Object
 can go remote. It"s clear from the GIOP spec that only non_existent(),
 is_a(), get_interface(), and get_domain_managers() can go on the wire.
 It follows that things like nil(), hash(), and is_equivalent() must be
 local. However, as Owen Rees pointed out, this only applies to GIOP, not
 the core, but a compliant ORB need not provide GIOP.
 
 It seems that it would be a good idea to add some clarification to the core
 to state which operations on CORBA::Object must be local and which ones
 may (but need not) go remote.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Provide clarifying text in Chapter 4 for each of the Object operations stating which ones may go remote and which are local only. Revised Text: Change text in Chapter 4 as follows: 1. In section 4.3.1 append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the last paragraph of the section. 2. In section 4.3.9, append the sentence: "The implementation of this operation may involve contacting the ORB that implements the target object." to the first paragraph of the section. 3. In section 4.3.7, append the sentence: "The implementation of this operation may involve remote invocation of an operation (e.g. DomainManager::get_domain_policy for some security policies) for some policy types." to the first paragraph of the section. 4. Add the following paragraph at the end of section 4.3 (immediately preceding section 4.3.1: "Unless otherwise stated, the operations in the IDL above do not require access to remote information."
Actions taken:
November 19, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2230: is_a underspecified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the description of is_a suffers from the same problem that we fixed for
 non_existent in 2.3: it is not clear what the operation should do if
 it could not make a determination due to a hard error. This means that
 the application does not know whether failure to make a determination
 returns false, or whether that will raise an exception (and false is
 returned only if the object doesn"t have the expected type).

Resolution: clarify
Revised Text: Add the following text before the last para of section 4.3.4 (add text at the top of page 4-12): Determining whether an object's type is compatible with the logical_type_id may require contacting a remote ORB or interface repository. Such an attempt may fail at either the local or the remote end. If is_a cannot make a reliable determination of type compatibility due to failure, it raises an exception in the calling application code. This enables the application to distinguish among the true, false, and indeterminate cases.
Actions taken:
December 1, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2235: uses of recursive_tc (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: According to ptc/98-10-08, 16 Oct. 98 [REVIEW], p. 10-53,
     "Once the recursive TypeCode has been properly embedded in the
       enclosing TypeCode which corresponds to the specified repository
       id, it will function as a normal TypeCode."
 
 Given the following idl:
 
     valuetype v {
         public v m0;
    };
 
 And the following C++ code to generate the typecode for v:
 
     CORBA::ORB_ptr orb = ...;
     CORBA::TypeCode_ptr tcRecursive =
 orb->create_recursive_tc("IDL:v:1.0");
     CORBA::ValueMemberSeq v_seq;
     v_seq.length(1);
     v_seq[0].type = tcRecursive;
     ...
     CORBA::TypeCode_ptr tcV = orb->create_value_tc("IDL:v:1.0", "v",
                                        VM_NONE, CORBA::TypeCode::_nil(),
 v_seq);
 
 After tcRecursive has been properly embedded, what does "tcRecursive
 functioning
 like a normal TypeCode" mean?  Does it mean that one can call on
 tcRecursive the same
 methods that are available on tcV? For example, will
 
    CORBA::Visibility vis = tcRecursive->member_visibility(0);
 
 work?

Resolution: Close no change in 2.4
Revised Text: -currently, the spec says the embedded typecode is incomplete when constructed but must function as a real typecode when embedded. This requires implementers to perform some sort of delegation for a recursive tc. - the issue proposes that even once completed, the embedded typecode raise an exception whenever it is programmatically queried. In both scenarios, ORBs must implement a special typecode (the embedded one). In one case to do delegation, in the other to raise exceptions. Both wordings of the spec (the current wording and your proposal) impose a limitation on implementations of recursive typecodes. There doesn't appear to be any pressing reason to make the embedded typecode unusable if it can just as easily (and with some additional benefits for implementors who are using reference counting) perform the delegation so the wording should remain unchanged.
Actions taken:
December 3, 1998: received issue
September 16, 1999: closed issue

Discussion:

Issue 2252: DynValue::get_members/set_members (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The final draft (ptc/98-10-16 - from 15-Nov-98) defines
 DynValue::get_members/set_members as:
 
 --
 struct NameValueAccess {
    FieldName id;
    Visibility access;
    any value
 };
 
 typedef sequence<NameValueAccess> NameValueAccessSeq
 
 NameValueAccessSeq get_members();
 void set_members(in NameValueAccessSeq values) raises (InvalidSeq),
 --
 
 and goes on to say "Any attempt to set or get a member which has been
 declared private in the IDL definition of the value contained in the
 dynamic any raises the exception NO_PERMISSION."

Resolution: :get_members/set_members as:
Revised Text:
Actions taken:
December 10, 1998: revceived issue

Discussion:

Issue 2254: Destruction of ORB (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: how is the ORB object destroyed? There is no ORB::destroy() operation,
 like for the POA. (With "destroy", I mean to remove it from memory
 (C++), or to allow it to be garbage collected (Java).)
 
 Is shutdown to be meant to destroy the ORB? If so, then this must be
 clarified in the specification. For example, if shutdown() destroys the
 ORB, all subsequent calls to ORB operations (via ORB references) must
 raise OBJECT_NOT_EXIST, just as it is with any other (locality
 constrained) object.
 
 If shutdown() does not destroy the ORB, but just shuts down
 communications and stops handling of further requests, then some other
 operation is needed to destroy the ORB.

Resolution:
Revised Text:
Actions taken:
December 14, 1998: receive dissue
December 14, 1998: closed issue

Discussion:

Issue 2258: OBV, value-reference substitution, Multiple Inheritance (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Hi, is it possible to pass a supporting value type by value when used as
 a interface?  It looks like this is droped from the OBV spec
 (ptc/98-10-06.pdf says when a supporting value type is used as a
 interface then an object reference will be used).

Resolution:
Revised Text:
Actions taken:
December 15, 1998: received issue
February 19, 1999: moved to orb_revision

Discussion:

Issue 2275: Sequences of recursive structs/unions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: If I have a recursive struct or union type and want to pass a sequence 
 of that type to an operation, I am completely stuck if I want to do
 this with C++. I"m not sure about other mappings, but I expect that
 Java, Ada, etc. will all suffer from the same problem.

Resolution:
Revised Text:
Actions taken:
December 21, 1998: received issue
October 30, 2000: closed issue

Discussion:

Issue 2296: Custom marshalling & AbstractBase (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The 2.3a draft defines DataOutputStream as having the following
 operation (see p. 5-12):
 
   void write_Abstract(in AbstractBase value);
 
 Yet there is no definition of the type `AbstractBase" anywhere
 in the document.

Resolution: Add AbstractBase as a native type in the CORBA module, together with explanation in Chapter 6.
Revised Text: 1. In section 6.2, add a new numbered list item 4. Renumber existing items 4 and higher to 5 and higher. The text is: "Abstract interfaces implicitly inherit from CORBA::AbstractBase. This type is defined as native. It is the responsibility of each language mapping to specify the actual programming language type that is used for this type. module CORBA { // IDL native AbstractBase; }; " 2. In Section 4.2 in the CORBA IDL, insert the line: native AbstractBase; immediately preceding the line that reads "interface NVList".
Actions taken:
January 7, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2303: POA threading policies (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The POA offers the SINGLE_THREAD_MODEL policy. It guarantees that, for
 a POA with this policy, all invocations are serialized. (The only other
 threading policy, ORB_CTRL_MODEL, allows to ORB to thread invocations as
 it sees fit.)
 
 There is a pragmatic problem here: SINGLE_THREAD_MODEL guarantees
 serialization for only a particular POA. This means that if I have a server
 that uses three POAs, all of which use SINGLE_THREAD_MODEL, invocations on
 any one of these POAs are serialized but invocations on different POAs
 can be dispatched in parallel.

Resolution:
Revised Text:
Actions taken:
January 10, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2308: POA SINGLE_THREAD_MODEL description ambiguous (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The description for the SINGLE_THREAD_MODEL policy only states that the
 POA makes all upcalls in a manner that is safe for code that is
 multi-thread-unaware.  This statement could be read to disallow
 recursive upcalls from one object implementation to another mediated by
 the same POA on a single thread.
 
 Proposed resolution:
 
 Add the following sentence to both sections 9.2.8 and 9.3.7, where the
 text defines the Single Threaded Model:
 
 A single-threaded POA will still allow recursive upcalls, where an
 object"s implementation invokes an operation on an object implemented
 using the same POA.

Resolution:
Revised Text:
Actions taken:
January 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2310: Missing minor code (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the 2.3a core chapters, there is a minor code missing from page 3-58,
 table 3-13.  BAD_PARAM minor code 1 should also be raised for errors 
 trying to lookup and unregister a value factory.  Alternatively we could
 add new minor codes for these.

Resolution: Let minor code one be used for all value factory related exceptions.
Revised Text: In table 3-13 on page 3-58 change the "Explanation" field for BAD_PARAM minor code 1 to read: "failure in attempt to register, unregister or lookup value factory."
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2311: Custom Marshaling clarification (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the core 2.3a chapters, page 5-11, section 5.5.1, last paragraph needs
 to be clarified or deleted.  This paragraph originally referred to the
 "streaming policy" registration APIs that used to be specified here but
 have since been deleted.
 
 Do we still intend to allow language mappings to provide alternative 
 mechanisms for custom marshaling as well as the standard mechanism of
 having the valuetype implementation provide the CustomMarshal methods
 marshal and unmarshal?  If not, this paragraph should be deleted.  If so,
 the last part of the paragraph should be reworded, for example "... to
 support other ways for value types to implement custom marshaling".

Resolution: Incorporate change in 2.4 and close issue
Revised Text: Delete last paragraph of section 5.5.1 (the one starting "This API is guaranteed").
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Delete last paragraph of section 5.5.1 (the one starting "This API 
is guaranteed"). 

Rationale: 

This is a hangover from a previous level of the spec (the version that 
used streaming policies) and now serves no purpose other than to confuse 
the reader.

Issue 2312: Names of Data*Stream methods (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The method names in DataInputStream and DataOutputStream have been
 chosen to match the method names in the Java portability streams.
 There is a proposal before the Java RTF to change some of the latter
 names.  If this is accepted, we should change the corresponding names 
 in Data*Stream as well.  
 
 This affects page 5-12 in the core 2.3a chapters.  write_Value should
 change to write_value and write_Abstract to write_abstract_interface.
 The corresponding read_* methods on page 5-14 should also be changed.

Resolution:
Revised Text:
Actions taken:
January 20, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2314: Supporting multiple abstract interfaces (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Valuetypes should be able to support multiple abstract interfaces but
 only a single regular interface.  See also comments number 28 and 31
 in the list of core 2.3a errata I just sent out.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: Resolution: Make changes to allow valutypes to support multiple abstract interfaces. The current prohibition on valuetypes supporting multiple interfaces was intended to prevent the OBV spec introducing multiple interface support by the "back door." The argument went that there is not much if any difference between a valuetype supporting multiple IDL interfaces and any implementation supporting sulitple IDL interfaces. Since we had no standard way to do the latter, we should not invent a standard way to do the former but not the latter, and we should not invent a standard way to do the latter as part of adding OBV. All very logical and reasonable. This consideration does not require disallowing support of multiple abstract interfaces. These are just giving the valuetype additional type semantics, as in C++ where a class has multiple abstract base classes containing only pure virtual functions, or in Java where a class implements multiple Java (not IDL) interfaces. So there is no reason to prevent this. The reason to allow this is the Java to IDL mapping. A Java serializable class that implements multiple RMI abstract interfaces (i.e., interfaces that do not extend java.rmi.Remote but whose methods throw RemoteException) is mapped to an IDL valuetype that supports multiple IDL abstract interfaces. If the latter is prohibited, we cannot correctly support the former. Revised Text: a. Page 3.13, section 3.4, production 19. Change last line to [ "supports" <interface_name> { "," <abstract_interface_name> }* ] b. Page 3.13, section 3.4, add new production <abstract_interface_name> ::= <scoped_name> c. Make above two changes in section 3.8.1.3 on page 3-23. d. Page 3-24, section 3.8.1.3, first line. Change "and <interface_name>" to "<interface name>, and <abstract_interface_name>". e. Page 3-27, section 3.8.5, third paragraph, add "and any number of abstract interfaces" at end of sentence. f. Page 3-27, section 3.8.5, third line of fifth paragraph. Change "interfaces and abstract interface" to "interface and abstract interfaces". g. Page 3-27, table 3-10. Add new column for Abstract Interface following the column for Interface. Contents are the same as the existing column for Interface except that the entry for Stateful Value should be "supports". h. Page 3-27, table 3-10. Abstract Value inherits from Interface should be "supports single". Also add new row for Abstract Interface, with contents (Interface) (Abs Int) (Abs Val) (Stfl Val) (Box Val) no multiple no no no i. Page 6-2, add new numbered point 6 before existing point 6 (which becomes point 7): Value types may support any number of abstract interfaces, but no more than one regular interface. j. Page 10-16: Change the supported_interface parameter of the create_value method of Container to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-58. k. Page 10-19: Change supported_interface to supported_interfaces. l. Page 10-34: Change the supported_interface attribute of ValueDef to a parameter named supported_interfaces with a data type of InterfaceDefSeq. Also make this change on page 10-64. m. Page 10-35: Change the supported_interface member of ValueDescription to a member named supported_interfaces with a data type of RepositoryIdSeq. Also make this change on page 10-66. n. Page 10-36: Change the first paragraph of section 10.5.24.1 to "The supported_interfaces attribute lists the interfaces that this value type supports." o. Page 10-36: In section 10.5.24.2, change supported_interface to supported_interfaces.
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

 a. Page 3.13, section 3.4, production 19.  Change last line to

Issue 2316: Codebases with multiple URLs (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: To support JDK 1.2 correctly, the codebase support for Objects By Value
 needs to support multiple URLs rather than a single URL as at present.
 
 This affects page 5-16 in the core 2.3a chapters.  Either the signatures
 of the implementation and implementations methods need to change to:
   URLSeq implementation(in CORBA::RepositoryId x); 
   URLSeqSeq implementations(in CORBA::RepositoryIdSeq x);
 
 or we need to say that the URL string can be a blank-separated
 sequence of URLs.  This also affects the OBV grammar on page 15-19.

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: It needs one or other of the following resolutions: Option A. Encode multiple URLs as a blank-separated string. This leaves the existing IDL unchanged, but requires changes to the supprting text in chapters 5 and 15 to state that a codebase URL can be multiple blank-separated URLs. Option B. Encode multiple URLs as a sequence of strings. This requires IDL changes to page 5-16 and 15-19. It is proposed that we resolve this issue using option B because: (a) Encoding multiple URLs as a sequence of strings is more natural in IDL (b) The Java to IDL mapping already does it this way. This means that the core IDL remains unchanged. However, the text and code comments should be clarified. Revised Text: On page 5-16, change the line: typedef string URL; to: typedef string URL; // blank-separated list of one or more URLs Also change the comment: // Operations to obtain a URL to the implementation code to: // Operations to obtain the location of the implementation code In the last paragraph on page 5-17, change the text: In this case, in addition to the codebase URL that is sent in the service context, each value which has a different codebase may have a codebase URL associated with it. to the text: In this case, in addition to the codebase URL(s) sent in the service context, each value which has a different codebase may have codebase URL(s) associated with it. One unrelated editorial point on this section. It is currently section 5.5.3 (part of "Custom Marshalling"). This is incorrect. It should be section 5.6 as it has nothing to do with custom marshalling. Apparently the wrong head level was used. Some changes to chapter 15 are also required. In section 15.3.4.1, first bullet, add a sentence at the end: The <codebase_URL> string is a blank-separated list of one or more URLs. In section 15.3.4.1, second last paragraph, change "codebase URL" to "codebase URL information". In section 15.3.4.2, first paragraph, change "a URL" to "codebase URL information". In section 15.3.4.3, second sentence, change "a codebase URL" to "codebase URL information". In section 15.3.4.3, third sentence, change "codebase URL" to "codebase URL information".
Actions taken:
January 20, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2318: Misleading text in section 3.2.5.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The second last paragraph in section 3.2.5.2 is confusing.  The
 second last sentence says (modulo typos) that since a string is a
 sequence of character literals, a sequence of \u literals can be 
 used to define a wide string literal.  
 
 This seems to me to be a non sequitur.  The conclusion does not 
 follow from the premise.  I think this sentence was supposed to say
 that since a wide string is a sequence of wide character literals,
 a sequence of \u literals can be used to define a wide string literal.

Resolution: Fix it
Revised Text: On page 3-10, second last paragraph, replace the last two sentences by the following: Since a wide string literal is defined as a sequence of wide character literals, a sequence of \u literals can be used to define a wide string literal. Attempts to set a char type to a \u defined literal or a string type to a sequence of \u literals result in an error.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2319: Clarify meaning of no IDL initializers (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.8.1.5 on page 24 does not make it clear what it means to 
 have no initializers for an IDL valuetype.  The decision of the OBV 
 designers, which is reflected in the C++ and Java language mappings,
 was that this means there is no portable way to create an instance
 of the value type.  This should be clearly stated in the definition of
 IDL semantics for valuetypes, not deduced from the language mappings.

Resolution: Fix it
Revised Text: Page 3.24, section 3.8.1.5, add new paragraph after first paragraph: If no initializers are specified in IDL, the value type does not provide a portable way of creating a runtime instance of its type. There is no default initializer. This allows the definition of IDL value types which are not intended to be directly instantiated by client code.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2320: Signature of unmarshal method is wrong (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 5-11, section 5.5.1, the signature of the unmarshal method is
 wrong.  It should return void, not ValueBase.

Resolution: Fix it
Revised Text: On page 5-11 in IDL for CustomMarshal replace the line: ValueBase unmarshal (in DataInputStream is); by the line void unmarshal (in DataInputStream is);
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2321: Errors in figure 10-2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-8, the section of figure 10-2 describing the module object
 has become wrongly ordered when the green text was inserted.  It says:
 
     InterfaceDef
     ValueDef
     ValueBoxDef
     ModuleDef
 
 It should say:
 
     ModuleDef
     ValueBoxDef
     InterfaceDef

Resolution: fix the order and indentation
Revised Text: Change the figure to look like: (A) Repository (B) ConstantDef TypedefDef ExceptionDef InterfaceDef ValueDef ValueBoxDef ModuleDef (C) ConstantDef TypedefDef ExceptionDef ValueBoxDef ModuleDef InterfaceDef (D) ConstantDef TypedefDef ExceptionDef AttributeDef OperationDef ValueDef (E) ConstantDef TypedefDef ExceptionDef AttributeDef OperationDef ValueMemberDef With the following annotation in the right column against the blocks identified by letters in parens in the left margin above: (A) Each interface repository is represented by a global root repository object. (B) The Repository IR object represents the constants, typedefs, exceptions, interfaces valuetypes value boxes and modules that are defined outside the scope of a module. (C) The Module IR object represents the constants, typedefs, exceptions, interfaces, valuetypes, value boxes and other modules defined within the scope of the module. (D) An Interface IR object represents constants, typedefs, exceptions, attributes, and operations defined within or inherited by the interface. (E) A value type IR object represents constants, typedefs, exceptions, attributes, operations and members defined within or inherited by the value type.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2322: No description for NativeDef (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.5.26, NativeDef, has no description of its read and write
 interfaces.  This is inconsistent with other sections.

Resolution: Provide description
Revised Text: Add the following paragraph at the end of section 10.5.26: The inherited <font>type</font> attribute is a <font>tk_native TypeCode</font> describing the native type.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2323: is_a description is wrong (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-36, the "is_a" description is wrong.  "interface_id" should
 be "value_id" for consistency with the IDL.
 
 Actually, it would be more correct to name this "value_or_interface_id" 
 or just "id" since both values and interfaces can be passed to the is_a
 method of ValueDef.  This requires changing the IDL on pages 10-34 and
 10-65.

Resolution: Incorporate changes in 2.4 and close issue.
Revised Text: The parameter named value_id should changed to id to reflect the fact that it can be either and interface or a value id. Revised Text: On pages 10-34 and 10-65, change the argument name in the is_a operation from "value_id" to "id". In section 10.5.24.1 on page 10-36, in the "is_a" description, change "interface_id" to "id".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue
September 16, 1999: closed issue

Discussion:

Issue 2325: No description for ValueBoxDef (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.5.25, ValueBoxDef, has no description of its read and write
 interfaces.  This is inconsistent with other sections.
 
 Proposed resolution:
 
 Add copies of sections 10.5.13.1 and 10.5.13.2 here.

Resolution: Provide description
Revised Text: Add copies of sections 10.5.13.1 and 10.5.13.2 as section 10.5.25.1 and 10.5.25.2 to this section. The second para of new section 10.5.25.1 shall read: The inherited type attribute is a tk_value_box TypeCode describing the value box.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2327: Error in ValueDef IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-35, the first line should be "RepositoryId supported_interface;".
 
 Also, on page 10-65, the eleventh member of FullValueDescription should be
 "RepositoryId supported_interface;" (same change).

Resolution: The resolution of this is tied to the resolution of issue 2314. So this issue is attached to and sub
Revised Text:
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2328: Text was inserted in wrong place (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 10-9, the recently added second paragraph should be moved to the
 bottom of the section.  The parapgraph preceding it and the two paragraphs
 following it refer back to numbered points 1, 2 and 3 at the bottom of 
 page 10-8, so this block of text should not be broken up.

Resolution: Make it so
Revised Text: Move the paragraph: "Analagous operations are provided for manipulating value types." to the end of the section.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2329: RMI Repository ID missing from section 10.6 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 10.6 needs to be updated to reflect the addition of RMI
 Hashed Format RepositoryIds.

Resolution: change introductory sentence to fix this problem in section 10.6
Revised Text: In section 10.6 change the sentence that currently says: This specification defines three formats: one derived from OMG IDL names, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment. to: This specification defines four formats: one derived from OMG IDL names, one that uses OMG IDL names and Java serialization version UIDs, one that uses DCE UUIDs, and another intended for short-term use, such as in a development environment.
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2330: Error in text describing TypeCode interface (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL on page 10-47 describing the TypeCode interface says that
 the member_count, member_name, and member_type operations apply to
 tk_except TypeCodes.  However, the text on page 10-49 says that
 these do not apply to exception TypeCodes.

Resolution: Fix it.
Revised Text: Page 10-49, "member_count" and "member_name" operations description, second line. After "non-boxed valuetype" add ", exception". Page 10-49, "member_type" operation description, first line. After "non-boxed valuetype" add ", exception".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2331: Clarify text in section 15.3.7 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 15-26, last sentence of section 15.3.7, the phrase "The abstract
 encoding of value type" is not very clear.  This refers to abstract 
 interfaces, but a reader might think it refers to abstract valuetypes.

Resolution: Incorporate change in 2.4 and close issue
Revised Text: On page 15-26, last sentence of section 15.3.7 change the phrase "The abstract encoding of value type" to "The encoding of value types marshaled as abstract interfaces".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2332: Clarifications needed in section 5.2.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In section 5.2.2 it states in the second paragraph that instances of
 valuetypes passed into valuetype methods are passed by reference (in a
 programming language sense).  That"s fine, but:
 
 1. This paragraph should also state that returned results are passed
    by reference.  This is necessary to ensure consistent IDL 
    valuetype semantics across different implementation languages.
 
 2. The last sentence of the following paragraph is confusing because
    it appears to contradict the statement in the second paragraph
    about reference semantics.  It says that "normal semantics for the
    programming language in question apply".  So if I have a language
    that only does pass-by-value, pass-by-value semantics would apply
    (so this says).  This cannot be correct, since it would prevent
    valuetypes from having well-defined semantics at the IDL level.

Resolution: Fix it.
Revised Text: 1. In the first sentence of the second paragraph of 5.2.2 page 5-3, change "passed into" to "passed into and returned by". 2. In the last sentence of the third paragraph, change "the normal semantics .... apply" to "programming language reference semantics apply".
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2334: Value base and the IFR (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Consider the following IDL:
 
 // IDL
 interface I
 {
     void op(in ValueBase vb);
 };
 
 How is this represented in the IFR? What is the IDLType of the vb
 parameter?
 
 I think it should be a PrimitiveDef, just as it would be the case if I
 would pass "Object" instead of "ValueBase". However, there is no
 pk_ValueBase defined. Shouldn"t this be added?

Resolution: Add value base to primitive defs.
Revised Text: (1) In section 10.5.14 page 10-25 enum declaration for PrimitiveDefs append to the list pk_ValueBase (2) Append the following sentence to the paragraph that immediately foolows the IDL referred to in (1) above: "A PrimitiveDef with kind pk_ValueBase represents the IDL type ValueBase."
Actions taken:
January 21, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2340: Forward-Declared Interfaces (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: there just has been raging discussion on the OB list about forward-declared
 interfaces. The words we have right now are inadequate. You could argue that the
 interface is defined in the same "specification" here. However,
 current IDL compilers (if they implmement the check at all) require
 the interface to be defined in the same compilation unit as the
 forward declaration.
 
 Now, we could allow a forward-declared interface to not be defined in
 the same compilation unit, but then, I think, we would have to very
 carefully specify what sort of things I can do with the forward-declared
 interface. (If we don"t do that, we"ll make separate compilation impossible
 because the compiler doesn"t know the size of a forward-declared interface
 nor its base interfaces.)
 
 What"s the general feeling here? I think we could simple change "specification"
 to "IDL source file" and be done with it. That"s the simple way out.

Resolution:
Revised Text:
Actions taken:
January 22, 1999: receive dissue
October 30, 2000: closed issue

Discussion:

Issue 2341: Calling get_response twice? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What if I call get_response on a request a second time, after I"ve already
 retrieved the response previously? It seems that an exception should
 be raised but the spec doesn"t say which one.
 
 Also, the spec could be interpreted right now to say that it"s OK to
 call get_response twice for the same request (because the spec says nothing
 about that). However, to me, permitting this would be silly because it would
 oblige the ORB to keep the reply around until the request object is destroyed
 or is used to initiate another request.

Resolution:
Revised Text:
Actions taken:
January 22, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2343: Grammar section 3.9.2 missing "float" rules, and other problems (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 3.9.2 has the following problems:
 
 No rules for combining floats are given, although double and long double types are mentioned.
 
 The rules for sizing intermediate forms of constant expressions that must result in an octet type
 are unspecified.
 
 The size a positive integer constant is required to have is not specified; I imagine it should be
 restricted to (at most) an "unsigned long" size, as larger sizes would not make valid array indices
 in several languages.

Resolution: Sumsume this issue in 1139, and close this issue with that annotation in 2.4.
Revised Text:
Actions taken:
January 25, 1999: received issue
September 16, 1999: closed issue

Discussion:

This issue is closely related to issue 1139, and therefore should be merged into 1139, so that the wholeissue of constant arithmetic can be dealt with in a single
consolidated resolution

Issue 2371: Issue - no PIDL, just language bindings (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In section 7.3.2 of CORBA 2.3a (ptc/98-10-07 pg 7-9) the description of
 send_multiple_requests gives the C, C++, and SmallTalk bindings for the
 operation but does not describe it in PIDL. This is inconsistent with
 the description style for other operations. It is unnecessarily biased
 towards these particular languages, and complicates the process of
 maintaining the specifications of the individual language bindings.
 
 The same comment applies to section 7.3.4 regarding get_next_response.
 In this case the language binding is in fact inconsistent with that
 published in the C++ language binding.

Resolution: Incorporate changes in 2.4 and close issue and raise new issue in C++ RTF
Revised Text: Resolution: Remove all the language mappings from the DII chapter and insert corresponding PIDL. Also update the PIDL in Chapter 4 ORB interface and make it consistent with Chapter 7. Use the ORB pseudo interface in the C++ and Java language binding chapter as the basis for this cleanup. Since this is just PIDL cleanup that simply aligns the PIDL with the way things are in the C++ and Java mappings, it has relatively little immediate impact on the most important language mappings. Even those language mappings that diverge a little from this setup are not necessarily broken, since language mappings have considerable latitude in how they map PIDL. If necessary they can eventually get aligned more closely. What is proposed involves removing C language mapping specific flag values and such from the Core chapters and requesting the C language mapping RTF to incorporate them in the C mapping chapter. Revised Text: 1. In the PIDL for the ORB interface on page 4-2, immediately following the line "interface DynValue ..." insert the lines: interface Request; // forward declaration typedef sequence <Request> RequestSeq; 2. In chapter 4 on page 4-3 in the IDL for ORB interface immediately following the get_default_context operation add the following lines of PIDL: void send_multiple_requests_oneway(in RequestSeq req); void send_multiple_requests_deferred(in RequestSeq req); boolean poll_next_response(); void get_next_response(out Request req); 3. In the third paragraph below the PIDL on page 4-7 which reads: "For a description of the create_list and create_operation_list operations, see ?List Operations? on page 7-11. The get_default_context operation is described in the section ?get_default_context? on page 7-15." Add the sentences: "send_multiple_request_oneway and send_multiple_request operations are described in the section "send_multiple_request" on page 7-9. poll_next_response and get_next_response are described in the section "get_next_response" on page 7-10." 4. In section 7.3.2 on page 7-9 remove the C, C++ and Smalltalk language mappings at the beginning of the section and place there instead the PIDL: interface Request; // forward declaration typedef sequence <Request> RequestSeq; void send_multiple_requests_oneway(in RequestSeq req); void send_multiple_requests_deferred(in RequestSeq req); 5. Remove the last four paragraphs of section 7.3.2. They belong in specific language mapping sections that happen to use the Flags, as C language does. 6. In section 7.3.4 on page 7-10 remove the C, C++ and Smalltalk language mappings at the beginning of the section and place there instead the PIDL: interface Request; // forward declaration boolean poll_next_response(); void get_next_response(out Request req) raises (WrongTransaction); Actions taken: 1. Incorporate changes in 2.4 and close issue. 2. Raise a new issue for C language mapping RTF to take the C language specific material repoved from the core chapters and incorporate them in the C chapter.
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2372: Use UNICODE Character set (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  I am member of the nation using another set of accented Latin letters than is LATIN-1 standard (ISO 8859.1), namely LATIN-2. For this reason, I must comment your preference of one particular character set as an unfortunate case. I would understand, that if you would limit character set to basic Latin characters of the basic ASCII code, but preference of one national enhancements of this code brings my doubts.
  In fact, the problem is not so hot, as it may seem on the first view. I know at present no classical compiler allowing use of the national character set e.g. for the language identifiers, and the limitation of the character sets to pure Latin characters is considered by Czech (and other nation"s) programmers as no significant limitation, with exception of the comments. The same concerns CORBA identifiers used in the OMG IDL language.

Resolution: Close issue in 2.4 with no change.
Revised Text:
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

 IDL only allows ASCII characters. strings (and char) may contain characters from the Latin-1 set. The wchar and wstring type can be used for unicode
character and unicode strings. Consequently no change is required in the standards to address the concerns raised in this issue.

Issue 2377: Application Interface issue (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  During study of the ORBIX software, I analyzed structure of internal stubs generated by IDL compiler on the both client and server side of the CORBA connection. I appreciated, that for creation of the both sides are used the same constructions like Request object, not different objects Request on the client side and ServerRequest on the server side. Naturally, there was also possibility to use CORBA compliant ServerRequest object when requested, but generated stubs used "old" IONA logic. May be, there are some sophisticated reasons why OMG specification use various objects on both client and server sides which I do not know, but in general, I prefer more simple approach of IONA. Please, let application interface as simple as possible.

Resolution: This issue is adequately dealt with in the POA specification.
Revised Text:
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2378: Try to define obligatory and optional parts of the CORBA specification. (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

Summary:  This comment uses examples from the chapter 3, but its idea concernes style of the all specification, as a general rule.
 6)  In the version CORBA 2.2, there were introduced new features and new simple data type. I understand, that such types like long long and/or long double may be key parts for some application. On the other hand, majority of applications need not such data types, and I see no reason to introduce them as obligatory to all CORBA implementations. For this reason, try to difference various features as obligatory for any CORBA compliant implementation and other ones as optional. 
 In general, it is good idea to specify advanced features of this system to unify various its implementators, but, on the other hand, why those features are made obligatory? For this reason, try to define obligatory and optional parts of the CORBA specification.

Resolution: Close in 2.4 with no change.
Revised Text: Creating multiple conformance points will make the management of conformance problem very difficult and will make interoperability considerably more difficult thus defeating the very purpose and one of the cornerstones of the success of CORBA. The implementation of a particular application may use whatever subset it chooses but the at the interface the entire set of types must be supported.
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2432: clarification and bug in InterfaceDef::FullInterfaceDescription (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The text in the interface repository specification that describes FullInterfaceDescription is ambiguous. CORBA v2.3a draft, section 10.5.23.1, page 10-22 reads:

The describe_interface operation returns a FullInterfaceDescription
describing the interface, including its operations and attributes. The
inherited describe operation for an InterfaceDef returns an
InterfaceDescription.

It does not specify whether the elements of the FullInterfaceDescription should describe only items (e.g., operations, attributes) that where defined in the interface being described, or whether they should describe items inherited from base interfaces as well. My naive, assumed rationale is that the full description is intended to improve efficiency. It should allow a dynamic client to obtain all of the information it needs to invoke any operation supported by the interface in a single request, avoiding the need to traverse the graph of base interfaces. If this is the case, then the full description should include inherited items as well, and the spec should say so. I checked our implementation (VisiBroker) and this is what it does.

My suggested remedy is to add the following words to the paragraph cited above:

"The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described."

The bug (I think) is that the FullInterfaceDescription description doesn"t include the boolean is_abstract member. The abbreviated InterfaceDescription struct has been extended with this member, and the FullInterfaceDescription should be a superset of the InterfaceDescription.

The suggested fix is to add the the following member to the InterfaceDef::FullInterfaceDescription struct:

boolean is_abstract;

Resolution: Incorporate changes in 2.4 and close issue
Revised Text: Resolution: Clarify that the FullInterfaceDescription structure includes all operations and attributes in the transitive closure of the inheritance graph. The "bug" mentioned above has already been fixed editorially. Revised Text: In section 10.5.23.1, page 10-22, append the following sentence: "The operations and attributes fields of the FullInterfaceDescription structure include descriptions of all of the operations and attributes in the transitive closure of the inheritance graph of the interface being described." to the paragraph that reads: "The describe_interface operation returns a FullInterfaceDescription describing the interface, including its operations and attributes. "
Actions taken:
February 2, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2435: Interceptors broken (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: There seems to be general consensus that the interceptor spec is
 unimplementable fantasy material. Given this, it would seem advisable to
 remove interceptors from the core.
 
 Also, there is some doubt as to whether P&P rules were followed when
 interceptors were added. My understanding is that an RTF cannot add
 new features to a spec, yet interceptors definitely seem to fall into
 that category.
 
 Given that no RFP was ever issues and that the feature is obviously broken,
 I suggest to remove the interceptor section until the outcome of the
 Portable Interceptors RFP can be added.

Resolution: Close in 2.4 with no change.
Revised Text: What is proposed in this issue is well outside the scope of what an RTF can do, i.e. an RTF cannot add new features or remove exisiting ones. It can only fix it, and if the fix requires an extremely substantial change, the fix has to be done using an RFP. Since there already is an RFP out to fix the chapter in question, it would seem inappropriate for an RTF to step in and usurp what another TF is already trying to do properly..
Actions taken:
February 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2436: another problem with IDL specification section 3.9.2 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec doesn"t say how octal and hex integral constants are treated.
 For instance, is the following line legal IDL or not:
 
   const short s = 0xFFFF;  // Valid???
 
 If the interpretation of "0xFFFF" in this context is "65535", then
 this is illegal, since the value is out of range.  If the interpretation
 is "-32768", then this assignment is valid.  The wording in this section specifies that
 each operand is converted immediately to the size of the eventual
 storage location, but fails to specify *how* that conversion is to be
 performed for hexadecimal and octal literals.

Resolution: closed issue
Revised Text:
Actions taken:
February 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Resolution: This issue is closely related to issue 1139. It therefore makes sense to subsume this issue into 1139 and thus aid in producing a single consolidated
resolution ot the constant arithmetic related stuff associated with 1139.

Issue 2442: POA Construction Policy. (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: >From what I understand of the POA document is that
 the POA or POAs are process resident, and that the servants they register
 are within their own process space, i.e. the Server.

Resolution:
Revised Text:
Actions taken:
February 5, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2444: Problems in Chapter 5 IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In ptc/98-12-04 Chapter 5, page 5-14, a DataInputStream operation 
 has the signature "long long long read_long()".  It should be 
 "long long read_longlong()"
 
 Also, the spelling of W[Cc]harSeq is inconsistent between its 
 declaration and its usage on pages 5-12 to 5-14.

Resolution: Close no change in 2.4
Revised Text:
Actions taken:
February 9, 1999: received issue
September 16, 1999: closed issue, no action in 2.4

Discussion:

 These errors have been fixed editorially in Rev 2.3a and they will appear in the fixed form in the published 2.3 spec which incorporate the output of the
2.3 and 2.3a RTFs.

Issue 2446: Inheritance of value types (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary:

Summary: There is a need for clarification regarding inheritance
 for value types. Must a value type that inherits from
 abstract bases always inherit from a "concrete"
 value? This seems to be enforced by the IDL
 grammar and the introduction of the ValueBase
 primitive type (as a concrete base in case no
 other concrete base is inherited).
 
 This seems somewhat ambiguous.

Resolution: close this issue with the note that it is resolved as part of 2490 in 2.4
Revised Text:
Actions taken:
February 9, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2447: What value type does ValueDef"s base_value() return? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary: full_desc: What does a ValueDef"s base_value() operation
 return for a value type that does not inherit from
 any concrete value?
 
 I see two possible resolutions: (1) make base_value()
 return ValueDef::_nil() in this case, or (2) add a
 pk_ValueBase primitive type to PrimitiveDef and
 return that.

Resolution:
Revised Text:
Actions taken:
February 9, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2450: IR Changes in 2.3 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Jishnu has pointed out (very pointedly i might add :-) that a whole slew of 
   upwardly incompatible changes have been made to the IR.
 
   E.g. old structs that have been modified (e.g. full interface description), 
   new structs have been added, operations added to container, changed
   tckind, etc., etc.
 
   The question before us is how, if at all, to reflect this change.
 
   We came up with several options (listed in no particular order and
   with no particular recommendation.)
 
   1. Do nothing. This is the traditional approach but probably becoming
      less and less appropriate as we mature :-)
 
   2. Add a #pragma version name_of versioned_thingy major.minor 
      for every definition. (Jishnu thinks that in
      principle all the #pragma version statements could go in one place,
      say at the end of the CORBA module. [We leave it as exercise to the
      reader to work out why they have to go at the end] )
 
   3. Change the name of the enclosing module. say CORBA -> CORBA_2_3, gulp!!

Resolution: incorporate changes in 2.4 and close issue.
Revised Text: Tag all remotely accessible IR Contained's (those things that have a version attribute) in the IR specifications that have changed with the version tag 2.3. This includes not only those that have been modified themselves but in addition all those that pass any that have been modified as parameters or return values, and in general those that contain things that have changed, which pretty much boils down to all interfaces and many structs, and many enums. Also to keep things easy to remember, all new stuff that has been added in 2.3 is tagged with 2.3. These version tags enable those implementations that want to provide this information in their IR, to do so, while not forcing those that would rather not into doing so. Additionally, to maintain the sanctity of module version, it is required that whenever the content of a module is changed its version tag must be changed, which implies that once a particular version of the CORBA module is published with a specific version tag - 2.3 in this case, any changes that are proposed to the CORBA module would require the change of the version tag. The revised text keeps the actual choice of version number open for resolution by the marketing/publishing department of OMG. It however requires that a version number be assigned as directed before the standard is published. Revised Text: In the following the string <x.y> represents the version number of the published standard. The editor should replace this with the version number of the published standard. For example if the published standard is 2.3 then <x.y> should be replaced by 2.3 before publication. On the other hand if it happens to be 2.4 then <x.y> should be replaced by 2.4. (1) In section 3.14 append the following paragraph: "The version of CORBA specified in this release of the specification is version <x.y>, and this is reflected in the IDL for the CORBA module by including the following pragma version (ref pragma version): #pragma version CORBA <x.y> as the first line immediately following the very first CORBA module introduction line, which in effect associates that version number with the CORBA entry in the IR. The version number in that version pragma line must be changed whenever any changes are made to any remotely accessible parts of the CORBA module in an officially relaeased OMG standard." (2) In the IDL in section 10.8 insert a line of the form: #pragma version <name> <x.y> immediately following the line in which the <name> appears in the full declaration of the <name>. for the following module, struct, enum, union, interface, valuetype: DefinitionKind IRObject Container Contained Initializer IDLType Repository All *Def All *Description except ExceptionDescription Value* TCKind Note that in case of modules that are opened multiple times, the version pragma must appear only once, immediately following the first module declaration line for such modules.
Actions taken:
February 12, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2454: Inconsistent spellings of "policy" related identifiers: (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

Summary:  I have found inconsistent spellings of "policy" related identifiers:
 
  "DomainManagersList" is used on pages 4-4 and 4-8
 
  "DomainManagerList" is used on pages 4-17,20-87,20-88,20-110
 
 Also, the operation identifer
 
  "set_policy_override" is used on pages 20-87, 20-88, 20-110
 
 However, this same operation identifier is consistently spelled as
 
  "set_policy_overrides" on pages 15-52,15-61,15-65,15-66,15-103,
 	15-104,15-105,15-106,15-108,15-109,15-111,15-199,15-218,
 	and 15-219
 
 in 98-12-03.pdf (Security Service Specification - Security Service
 	 v1.5 15 December 1998 [FINAL]
 
 So what is the "correct" spelling of these identifiers?

Resolution: Close no change in 2.4
Revised Text: DomainManagerList is correct, and all occurences of DomainManagersList in Chapter 4 is changed to DomainManagerList before publishing. Necessary changes will be made in the Security spec as required too before Security 1.5 is published. set_policy_overrides is correct. The latest version of C++ mapping reflects this in ptc/98-09-03. It should also be pointed out that set_policy_overrides pertains to an operation of the Object interface the mappings of which to individual languages munge names anyway. While it is desirable that the mappings do not munge the names in arbitrary ways, an error slipping in is not a show-stopping disaster, and it can be fixed in the next round of revision.
Actions taken:
February 17, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2456: CORBA::Object::ping ? (orb_revision)

Click here for this issue's archive.
Nature: Enhancement
Severity:
Summary:

Summary: I"d like to float the idea of adding a ping operation to CORBA::Object:
 
 	module CORBA {
 		interface Object {
 			void ping();
 			// ...
 		};
 		// ...
 	};
 
 The reason for suggesting this is that developers have a frequent need
 for this functionality. (How to determine object reachability (as opposed
 to object existence) is a FAQ).

Resolution:
Revised Text:
Actions taken:
February 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2487: Inconsistent Definition of Flags type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In Section 4.3 of V2.3a specification, the typedef of Flags is "long". In
 Section 7.1.1, it is "unsigned long".

Resolution: Make it uniformly unsigned long
Revised Text: In the IDL on page 4-9 replace the line: typedef long Flags; by the line typedef unsigned long Flags
Actions taken:
February 24, 1999: received issue
June 4, 1999: closed issue

Discussion:

Issue 2490: What use is CORBA::exception_type? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This enumeration type is defined in 3.17.1, but used no where else.  Why
 is it even there?

Resolution: incorporate changes in 2.4 and close issue.
Revised Text: Fix the grammar problems as shown below and also remove the possibility of deriving anything explicitly from ValueBase keeping in line with the way in which Object is handled. Revised Text: In section 3.4, replace productions 19 and 20 by: (19) <value_inheritance_spec> ::= [":" ["truncatable"] <value_name> {"," <value_name>}*] ["supports" <interface_name> {"," <interface_name>}*] (20) value_name> ::= <scoped name> Delete production 21. Replace section 3.8.1.3 by the following: 3.8.1.3 Value Inheritance Specification <value_inheritance_spec> ::= [":" ["truncatable"] <value_name> {"," <value_name>}*] ["supports" <interface_name> {"," <interface_name>}*] <value_name> ::= <scoped name> Each <value_name> and <interface_name> in a <value_inheritance_spec> must denote a previously defined value type or interface. See ?Valuetype Inheritance? on page 3-27 for the description of value type inheritance. The truncatable modifier may not be used if the value type being defined is a custom value.
Actions taken:
February 25, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2492: Error in IRObject definition in 98-12-04 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The definition of IRObject in 10.5.2 somehow got an additional attribute
 that makes no sense:  "readonly attribute InterfaceName type_name". 
 This is probably an editorial mistake.

Resolution: They have been fixed in ptc/98-12-04.
Revised Text:
Actions taken:
February 26, 1999: received issue
June 4, 1999: closed issue

Discussion:

Issue 2502: Need to specify exception for abstract interface error (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: An abstract interface type in an operation signature indicates that
 at runtime the value passed will either be an object reference or a
 valuetype.  However, it is possible for user code invoking this
 operation to supply (incorrectly) a runtime programming language object
 that is neither of these.  For example, an IDL abstract interface type
 maps into a Java interface, and the object passed at runtime could be
 any Java type that implements this interface.
 
 The spec does not currently define an exception to be used in this
 error case.  The Java to IDL mapping needs a defined exception so that
 it can detect this error and return a NotSerializableException to the
 application.

Resolution: Add a new minor code to the BAD_PARAM system exception:
Revised Text: Add a new minor code to the BAD_PARAM system exception table 3-13 on page 3-58: 6 Incorrect type for abstract interface
Actions taken:
March 3, 1999: received issue
March 8, 1999: moved from java2idl-rtf to orb_revision
September 16, 1999: closed issue

Discussion:

Issue 2507: Scope of SendingContextRunTime service context (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: It is not clear what is the scope of the SendingContextRunTime service
 context defined in section 13.6.7.
 
 Since the content of this service context will remain constant through
 the lifetime of a connection, it needs to be sent only once per
 connection.  This is much more efficient than requiring it to be sent
 on a per-request basis.
 
 This seems to parallel the current usage of the CodeSets service context.
 Section 13.7.2.6 says:
  Code set negotiation is not performed on a per-request basis, but only
  when a client initially connects to a server. All text data communicated
  on a connection are encoded as defined by the TCSs selected when the 
  connection is established.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 3, 1999: received issue
March 4, 1999: moved from orb_revision to interop
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2508: omg.org prefix not well specified (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The core spec says in section 10.6.7 that:
 
 Unless pragma directives establishing RepositoryIds for all definitions
 are present in an IDL definition officially published by the OMG, the
 following directive is implicitly present at file scope preceding all 
 such definitions: 
  #pragma prefix �omg.org�
 
 What does an IDL compiler need to do to be compliant with this?  How
 is it supposed to recognize IDL definitions officially published by the
 OMG so that it can insert the required implicit pragma?

Resolution: Incorporate change in 2.4 and close issue
Revised Text: The sentence quoted is asking for the impossible, since as Simon has pointed out it is impossible for anyone to figure this info out of thin air. So it should be removed. The current policy is that each OMG standard IDL file must contain the pragma prefix "omg.org", unless the file is included in standard by reference to another standard from a different standards organization like the W3C, in which case there must be a pragma prefix identifying the source standards organization. Revised Text: In section 10.6.7. replace the following text:: "Unless pragma directives establishing RepositoryIds for all definitions are present in an IDL definition officially published by the OMG, the following directive is implicitly present at file scope preceding all such definitions: #pragma prefix �omg.org� For example, if an existing official specification included the IDL fragment: module CORBA { // non-normative example IDL interface Nothing { void do_nothing(); }; }; the RepositoryId of the interface would be �IDL:omg.org/CORBA/Nothing:1.0�. " by: "All official OMG IDL files shall contain a pragma prefix directive: #pragma prefix "omg.org" unless said file already contains a pragma prefix identifying the original source of the file (e.g "w3c.org")."
Actions taken:
March 3, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2509: Can an any with a tk_null or tk_void TypeCode be encoded with CDR? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec is silent about whether an any with a TypeCode of tk_null or
 tk_void can be marshalled and unmarshalled with CDR.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 3, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2511: POA that has IdAssignmentPolicy=SYSTEM--portability problem (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: For a POA that has IdAssignmentPolicy=SYSTEM, there is a portability
 problem in the combination of the POA generation of an ObjectId and
 the language functions that convert between ObjectId and string.
 
 The C++ functions PortableServer::ObjectId_to_string (and wstring)
 state that
 
    If conversion of an ObjectId to a string would
    result in illegal characters in the string (such
    as a NUL), the [...] functions throw the
    CORBA::BAD_PARAM exception.
 
 This apparently assumes that the conversion does nothing but take the
 sequence of octet and recast it as a char*. Thus, an embedded null
 would cause the string to be interpreted as shorter than the sequence,
 so it"s an error.

Resolution: Close no change in 2.4
Revised Text: Let people write non-portable code and have redundant conversion routines. Recommend to the language mapping RTFs that the individual language RTFs that have null-octet restrictions for CORBA::ObjectId_to_string (and cousins) should add a warning. The warning should state that the use of these functions is intended only for converting from original, user-specified strings to ObjectId and back, not the reverse
Actions taken:
March 4, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2513: POA issue, section 11.3.8.10 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 11.3.8.10 of the Core draft 2.3a says that the application is
 free to assign its own servant manager to the root POA, but the next
 section says that the
 set_servant_manager() operation requires that the POA in question must
 support the request  processing policy of USE_SERVANT_MANAGER. But as
 the root
 POA has a req. proc. policy of USE_ACTIVE_OBJECT_MAP_ONLY, surely the
 user CANNOT assign a servant manager to the root POA.
 
 The text is a mistake, isn"t it? The application cannot "assign its own
 servant manager to the root POA". Unless there is some subtlety to the
 meaning of the word "assign" which make it different from "set". I
 thought the root POA was something the user could not tamper with in any
 way.

Resolution:
Revised Text:
Actions taken:
March 5, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2521: LocateReply body alignment issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Hi folks, I know this is a bit late but I  was going through some GIOP
 1.2 issues  with  Bob  and   I only  just  noticed  another   required
 clarification for LocateReply messages. Bascially the text added under
 Request/Reply which states "In  GIOP 1.2, the Request[/Reply]  Body is
 always aligned on   an 8 octet boundary"   was not also  added  to the
 description for LocateReply"s (15.4.2.2).   I presume  the requirement
 was intended for the body data of all message types. If so, perhaps it
 would make sense to move this  text to the  start of 15.4 and reworded
 to indicate the requirement for all message body data in general.
 
 If the LocateReply body  alignment issue will not  be clarified in the
 GIOP 1.2  specification then I  wish to  submit this as  a new interop
 issue.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 8, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2522: forward declaration in ptc/98-10-04 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

Summary:   Pages 3-18 and 3-19 of the CORBA 2.3a spec state that a forward declaration consists of the following:
      [abstract] "interface" <identifier>
     I believe that this should be:
      [abstract] "interface" <scoped_name>
 
     Otherwise, the following would be illegal:
     module A
      {
        interface B::d;  //forward decl of d
        interface c
         {
            B::d f();
          };
       };
    module B
      {
         interface d
          {
             A::c f();
           };
       };

Resolution: Close no change in 2.4
Revised Text: This has already been recognized as illegal and we wanted it to stay that way. You can rewrite the code like this: module B { interface d; }; module A { interface c { B::d f(); }; }; module B { interface d { A::c f(); }; };
Actions taken:
March 9, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2529: RMI style repository ID hash code (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There is a problem with the currently defined algorithm for computing
 the hash code component of the RMI Hashed Format repository ID as 
 defined in section 10.6.2.  Because it is based only on the structural
 information in the most derived Java class and does not take into 
 acoount any superclass information, it can give a "false positive"
 result when the state of a superclass changes but the state of the
 most derived class does not.
 
 This is a core RTF issue since the affected text is in chapter 10.

Resolution: Replace the currently defined algorithm with one that fixes the problem as described below
Revised Text: In section 10.6.2, replace the paragraph starting "The hash code is" by the following text: For classes that do not implement java.io.Serializable, and for interfaces, the hash code is always zero, and the RepositoryID does not contain a serial version UID. For classes that implement java.io.Externalizable, the hash code is always the 64-bit value 1. For classes that implement java.io.Serializable but not java.io.Externalizable, the hash code is a 64-bit hash of a stream of bytes. An instance of java.lang.DataOutputStream is used to convert primitive data types to a sequence of bytes. The sequence of items in the stream is as follows: 1. The hash code of the superclass, written as a 64-bit long. 2. The value 1 if the class has no writeObject method, or the value 2 if the class has a writeObject method, written as a 32-bit integer. 3. For each field of the class that is mapped to IDL, sorted lexicographically by Java field name, in increasing order: a. Java field name, in UTF encoding b. field descriptor, as defined by the Java Virtual Machine Specification, in UTF encoding The National Institute of Standards and Technology (NIST) Secure Hash Algorithm (SHA-1) is executed on the stream of bytes produced by DataOutputStream, producing a 20 byte array of values, sha[0..19]. The hash code is assembled from the first 8 bytes of this array as follows: long hash = 0; for (int i = 0; i < Math.min(8, sha.length); i++) { hash += (long)(sha[i] & 255) << (i * 8); }
Actions taken:
March 12, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2539: Incorrect IDL is section 5.5.3 (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

Summary: The IDL in section 5.5.3 is incorrect.  It refers to 
   CORBA::FullValueDescription
 but the correct name for this type according to chapter 10 is
   CORBA::ValueDef::FullValueDescription
 
 Proposed Resolution:
 
 Change chapter 5 to match up with chapter 10.

Resolution: make it so.
Revised Text: On page 5-15 and 5-16 replace occurences of CORBA::FullValueDescription by: CORBA::ValueDef::FullValueDescription
Actions taken:
March 15, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2543: confusing rules for operations on Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Section 4.3 of ptc/98-10-05 documents Object Reference Operations. These
 are described as "not operations in the normal sense, in that they are
 implemented directly by the ORB, not passed on to the object
 implementation".
 
 This includes a variety of operations, requiring varying contexts to be
 used successfully: 
 - Some require remote communication to the orb of the server
   or (contrary to the quote above) may actually be passed on
   to the object implementation, or something similar like a
   servant manager (e.g. is_a, non_existent)
 - some may require remote communication to an interface repository
   (e.g. get_interface)
 - some require the local orb to be operational
   (e.g. create_request)
 - some can function even without a local orb
   (e.g. is_nil, duplicate, release)

Resolution:
Revised Text:
Actions taken:
March 16, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2547: DynAny.insert_valuetype shoud be insert_val (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The IDL in section 9.2 of ptc/98-12-04 is incorrect.  The OBV RTF adopted
 method names insert_val and get_val instead of the original insert_value
 and get_value which conflicted with the get_value method in the DynFixed
 subclass.  The IDL incorectly shows these methods as insert_valuetype
 and get_valuetype.
 
 Proposed Resolution:
 
 Change insert_valuetype to insert_val and get_valuetype to get_val.

Resolution: fix the names in section 9.2
Revised Text: Do a global replace of all occurences of get_valuetype by get_val and insert_valuetype by insert_val in section 9.2
Actions taken:
March 16, 1999: received issue
September 16, 1999: closed issue

Discussion:

Issue 2548: Repository ID for Object (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Latest 2.3, draft (98-10-10), page 13-17:
 
 	"A Null TypeID is the only mechanism that can be used to represent
 	 the type CORBA::Object."
 
 I am aware of more than one ORB that uses "IDL:omg.org/CORBA/Object:1.0".
 
 I don"t understand why:
 
 	- a null ID should mean Object
 
 	- why a perfectly good repository ID for Object should be disallowed
 
 Related to this is the fact that we made repository IDs mandatory in
 reference TypeCodes with the 2.3 revision. Unless an implementation is
 very careful, this could mean that, if it gets a reference that doesn"t
 have the repository ID, it could present an illegal TypeCode (with an
 empty ID) for that reference to the application.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
March 17, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2549: activate_object_with_id and exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: If I use activate_object_with_id and the object ID is already in the AOM,
 the operation raises ObjectAlreadyActive.
 
 If I use activate_object_with_id and the servant is already in the AOM, and
 the POA has UNIQUE_ID, the operation raises ServantAlreadyActive.
 
 What happens if I have UNIQUE_ID, and I run the following code?
 
 	poa->activate_object_with_id(my_id, my_servant);
 	poa->activate_object_with_id(my_id, my_servant);	// ???
 
 Which exception is raised on the second call, ObjectAlreadyActive or
 ServantAlreadyActive?

Resolution:
Revised Text:
Actions taken:
March 18, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2553: ORB::shutdown again (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I"m sorry to reopen this can of worms, but I believe that the shutdown()
 issue we voted on (1665) still only offers a partial solution. The problem
 appears to be that terminating the event loop and ORB destruction must be
 separate steps.
 
 Consider a very simple application that uses RETAIN, NO_IMPLICIT_ACTIVATION,
 and USER_ID. No servant manager is used.

Resolution: This issue should be closed no change.
Revised Text:
Actions taken:
March 23, 1999: received issue
February 27, 2001: closed issue

Discussion:

This issue should be closed no change. 

The best way to deal with the destruction of POAs issue 
is to arrange the POAs into a hierarchy such that POAs that depend 
on other POAs are destroyed first, followed by those POAs that don't depend 
on other POAs. The semantics of POA::destroy() are already sufficient 
to achieve this. 

In addition, by using reference-counted servants, the issue goes away too 
because one can then rely on the POA to take care of removing servants from the 
AOM, so one doesn't have to call deactivate_object() in the destructor.

Issue 2559: deactivate_object asymmetry (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In the POA, we have
 
 	ObjectId activate_object(in Servant s) raises(...);
 	void activate_object_with_id(in ObjectId id, in Servant s) raises(...);
 
 However, for deactivation, we have only one function:
 
 	void deactivate_object(in ObjectId id) raises(...);
 
 This lacks symmetry. If I can use implicit activation of a servant,
 why can"t I use implicit deactivation? For symmetry, I would have expected:
 
 	void deactivate_object() raises(...);
 	void deactivate_object_with_id(in ObjectId id) raises(...);

Resolution:
Revised Text:
Actions taken:
March 29, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2574: Clarification on IdUniquenessPolicy (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

Summary: The description of IdUniquenessPolicy in section 11.3.7.3 fails to
 mention how this policy interacts with the ServantRetentionPolicy.
 
 My interpretation is that the IdUniquenessPolicy is irrelevant when the
 ServantRetentionPolicy is NON_RETAIN. If this is the case it should be
 explicitly stated. Alternatively, one specific value might be required
 when NON_RETAIN is in effect. (If so, it ought to be MULTIPLE_ID.)
 
 Without some statement clarifying this there could be portability
 problems with some orbs allowing either value while others require a
 particular value.

Resolution:
Revised Text:
Actions taken:
March 31, 1999: received issue
March 31, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2576: UNIQUE_ID and ServantActivator issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: What should happen if the servant returned from a
 ServantActivator::incarnate call is already registered for another
 object id, and the POA has the UNIQUE_ID policy?  
 
 Since this is clearly an error, I suggest raising the OBJ_ADAPTER
 exception (which will be returned to the client whose request prompted
 the call to incarnate).  I also suggest requiring the POA to call
 ServantActivator::etherealize for that object id.  The latter is
 necessary to allow the application to dispose of any resources
 associated with that object, and to ensure that an application will
 never recieve two calls to ServantActivator::incarnate for a particular
 object id without an intervening call to ServantActivator::etherealize.

Resolution: Incorporate change and close issue
Revised Text: Add the following sentence to the second-last paragraph of section 11.3.5.1 on page 11-24 (preceding the note): In this case, etherealize is not called by the POA because the servant was never added to the Active Object Map.
Actions taken:
April 2, 1999: received issue
October 6, 2000: closed issue

Discussion:

Based on the log, it seems that the behavior of raising OBJ_ADAPTER is 
already specified. 

Regarding the idea of calling etherealize, the are some possible 
benefits, but they are dubious for a servant locator that has already 
proven itself to be broken. Consequently, we should clarify that 
etherialize is not invoked in this case.

Issue 2577: sharing valuetypes across Anys (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Should valuetype identity be preserved across arguments when those
 valuetypes reside within Anys?

Resolution:
Revised Text:
Actions taken:
April 5, 1999: receive dissue
October 30, 2000: closed issue

Discussion:

 receive dissue

Issue 2579: is_abstract parameter missing from create_interface() IDL (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: I noticed the IDL for Container in ptc/98-12-04, page 10-59 is missing
 is_abstract parameter in create_interface() operation.
 The instance on page 10-16 does include it.

Resolution:
Revised Text:
Actions taken:
April 8, 1999: received issue
April 8, 1999: closed issue

Discussion:

Issue 2615: The insert_dyn_any and get_dyn_any operations are barely documented (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 1) The insert_dyn_any and get_dyn_any operations are barely documented. It
 seems the only explanation is given on 9-15: "The get_dyn_any and
 insert_dyn_any operations are provided to deal with any values that contain
 another any." The insert_dyn_any function should be specified as behaving
 identically to insert_any, except that it allows an any in the form of a
 DynAny to be inserted. The get_dyn_any should be specified as behaving
 identically to get_any, except that it returns its result in the form of a
 DynAny rather than an any.

Resolution: "The get_dyn_any and
Revised Text:
Actions taken:
April 20, 1999: received issue
April 20, 1999: received issue
April 26, 1999: moved to Core RTF from C++ RTF

Discussion:

Issue 2616: DynAny::equal operator issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The DynAny::equal operator does not mention how to compare object
 references or TypeCodes. It should be specified to require is_equivalent()
 to be called for object reference comparison and equivalent() to be called
 for TypeCode comparison.

Resolution:
Revised Text:
Actions taken:
April 20, 1999: received issue
April 26, 1999: moved from C++ to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 2617: DynFactory or DynAnyFactory? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Page 9-10 of the new DynAny draft says that you pass "DynFactory" to
 resolve_initial_references() to get a DynAnyFactory. The third comment on
 page 9-2, however, says the string should be "DynAnyFactory". I believe the
 latter is correct.

Resolution:
Revised Text:
Actions taken:
April 20, 1999: received issue
April 26, 1999: closed issue, fixed

Discussion:

 fixed, issue is closed

Issue 2674: New "opaque" data type (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  I propose the addition of the new basic data type "opaque."
 
  Many applications require the sending or retrieving of opaque data,
 like graphical data or file contents. Currently, such data is packaged
 as sequence<octet>.
  In the past, the performance of passing sequence<octet> parameters
 was not satisfactory because of the generic mapping of sequences. In
 the recent C++ mapping, the dubious get_buffer() is introduced for
 the mapping of sequences.
  I feel that this matter is best resolved by adding a new data type
 which can then be mapped efficiently into target languages without
 the side effect of complicating the mapping of other sequences.
  After all, a "string," too, is nothing but a sequence of char.

Resolution:
Revised Text:
Actions taken:
May 30, 1999: received issue
December 16, 1999: ransferred from C++ RTF to Core RTF
October 30, 2000: closed issue

Discussion:

Issue 2791: Expected behavior of POA configured with ServantLocator receiving LocateRe (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This is an issue with the Portable Object Adapter:
 
 If a POA configured with a ServantLocator receives a LocateRequest, what
 is the expected behavior?  A ServantLocator expects to receive an operation
 name as a parameter to preinvoke() and postinvoke(), but there is no
 operation name in a LocateRequest.
 
 We could just return a true response to the LocateRequest and not involve
 the ServantLocator.  That might mislead the sender though.  If the sender
 received a true response and then sent a message they might get an
 OBJECT_NOT_EXIST exception back.
 
 We could pass an operation name like "_locate" to the manager.  That would
 let the manager know that a location request was being processed, and the
 underscore would signify that it is an internal message since it"s not a
 _get or _set.

Resolution: Add a subsection to section 11.3.6 specifying "_locate" and its usage.
Revised Text: 1) New section 11.3.6.3 titled "ServantLocator and Location Determination" contain the following text: "Under certain circumstances, an ORB may need to determine the actual location of an object's implementation. For objects that are managed by a POA that is configured with a ServantLocator, it may invoke preinvoke and postinvoke or it may determine the object's location by some other means. If it invokes preinvoke and postinvoke under these circumstances it shall use the argument "_locate". " 2) New section 15.4.6.3 titled "Handling ForwardRequest exception from ServantLocator" containing the following text: "If the ServantLocator in a POA raises a ForwardRequest exception the ORB shall send a LocateReply message to the client with locate_status set to OBJECT_FORWARD, and with the body containing the object reference from the ForwardRequest exception's forward_reference field."
Actions taken:
July 8, 1999: received issue
July 16, 1999: moved from Java RTF to Core RTF
October 6, 2000: Incorporate core change and forward to interop RTF recommendi

Discussion:

Issue 2796: The syntax for stringified IORs in section 13.6.6 (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Hewlett-Packard EIAL
Summary:

Summary: The syntax for stringified IORs in section 13.6.6 shows: =
 "IOR:" The problem is that URL scheme names are supposed to be case
 insensitive. So, "Ior:"
 or "ioR:" should be allowed to. I would suggest to add a footnote to
 state that case for the scheme name is ignored.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 9, 1999: received issue
August 11, 1999: moved from Core RTF to Interop
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2817: Null Value semantics under specified (orb_revision)

Click here for this issue's archive.
Source: Objective Interface Systems (Mr. Victor Giddings, victor.giddings(at)mail.ois.com)
Nature:
Severity:
Summary:

he description of null value semantics (in ptc/99-03-07) is insufficient to ensure an adequate mapping to an
implementation language. Issues that should be specified include: - Creation. How are null values created? Are all declared (but
uninitialized) values born null? Is this a language mapping requirement or allowance? - Invocation. Presumably invoking an
operation ON a null value should result in an exception. But, what exception? Shouldn't the exception be specified for application
portability? - Passing. Presumably, it is allowable to provide a null value as the actual parameter for a non member operation (i.e.,
not on itself). True? - Typing: are null values typed, untyped, or is this governed by the language mapping? - Substitutability (see
"typing" above): -- Presumably: a null value may be successfully widened to a null value of an ancestor stateful value type. True?
-- Can a null value be successfully widened to a (null) supporting concrete interface? (Can a null value be activated as a servant?)
-- Can a null value be successfully widened to a (null) supporting abstract interface? -- Can a null value be successfully widened
to a (null) ancestor abstract value type? The only mentions of null values currently are: - the bullet in 5.2 - 5.2.4.2

Resolution: close issue, no change
Revised Text:
Actions taken:
July 21, 1999: received issue
May 4, 2000: closed issue

Discussion:

1. Creation. How are null values created? Are all declared (but 
uninitialized) values born null? Is this a language mapping 
requirement or allowance? 

The DynAny aspect of this is being addressed in DynValue issue. 
The rest is a language mapping issue, and needs to be dealt with in each 
language mapping. 

2. Invocation. Presumably invoking an operation ON a null  value should 
result in an exception. But, what exception? Shouldn't the exception 
be specified for application portability? 

Yes, but the exception is language mapping specific, and hence 
should be specified for each language mapping, and not in the Core. 

3. Passing. Presumably, it is allowable to provide a null  value as the 
actual parameter for a non member operation (i.e., not on itself). True? 

True. 

4. Typing: are null values typed, untyped, or is this governed by the 
language mapping? 

The wire format for a null value contains no type information. 
 So technically I think that null values are untyped. That is about 
all that can be said by the core or interop. 

 In a language mapping that supports static typing, the variable that 
 contains a null value may be typed, and in this case the value may be 
 considered to have that type. But that is actually a property of the 
 variable and not the value. 

5. Substitutability (see "typing" above): 
    -- Presumably: a null value may be successfully widened to a null 
value of an ancestor stateful value type. True? 
   -- Can a null value be successfully widened to a (null) supporting 
concrete interface? (Can a null value be activated as a servant?) 
   -- Can a null value be successfully widened to a (null) supporting 
abstract interface? 
   -- Can a null value be successfully widened to a (null) ancestor 
abstract value type? 

These are entirely language mapping issues.

Issue 2819: interop issue: what system exceptions may be raised on GIOP 1.0? (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: An issue we"ve run across is enumerating the set of system exceptions
 that are valid to be passed via GIOP 1.0 (and similarly for 1.1, and
 1.2).  This is important for implementations of GIOP, which are, for
 instance, attempting to map wire exceptions to C++ exceptions, and is
 also important for packet-sniffing implementations.
 
 Since many conforming GIOP 1.0 implementations were built (and bought)
 and incorporated into products before various CORBA system exceptions
 were added to the Core, it seems that servers should not raise `newer"
 exceptions back to older clients -- that is, clients speaking GIOP 1.0. 
 Instead, they should map those `newer" exceptions to UNKNOWN, I"d guess.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 21, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2822: mixing giop versions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: The spec is currently unclear on when and how messages with different
 giop versions may share a single connection.
 
 This has already been discussed, with different RTF members holding
 positions running the range from: "all messages on a connection must
 have the same giop version" to "messages with differing giop versions
 must be permitted on the same connection". So clearly there is an issue.
 
 The resolution of this issue should address at least the following
 unclear points:
 
 1) suppose a client orb supporting giop 1.2 initiates an invocation on
 an IOR with iiop version 1.1. As a result, it establishes a new
 connection and sends the request using giop 1.1. Later, the same client
 obtains another IOR referencing the same transport address, but
 specifying iiop version 1.0.
 
 - may the same connection be used to send a request to the new IOR?
 - if so, what giop version should be used to send the request?
 
 2) Later, the same client obtains another IOR referencing the same
 transport address, but specifying iiop version 1.2.
 
 - may the same connection be used to send a request to the new IOR?
 - if so, what giop version should be used to send the request
 - if so, what giop version should be used to send subsequent requests
   to the IORs mentioned in (1).
 
 3) Imagine a day in the not too distant future, when giop 1.3 has been
 approved and implemented. A client that supports giop 1.3 obtains an IOR
 with iiop version 1.2, establishes a new connection, and then sends a
 request using giop 1.2. A service context offering bidirectional giop is
 sent with this request, and accepted by the server. The client provides
 the server (that supports giop 1.3) with a callback IOR that has iiop
 version 1.3, and the server attempts to call back on it.
 
 - may the callback use the incoming connection?
 - if so, what giop version should the request use?
 - if so using v1.2, what if the callback request requires a feature
   only available in giop 1.3?

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
July 26, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue'

Discussion:

Issue 2828: (orb_revision)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: resolved in interop RTF
Revised Text:
Actions taken:
August 2, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Discussion:

Issue 2843: Changebars missing from POA chapter (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: Many changes between CORBA 2.2 and CORBA 2.3 are not changebarred. Some
 examples from the POA chapter (docs/formal/99-07-15.pdf):
 
 - Page 11-20: added PortableServer::POAManager::get_state() method.
 - Page 11-28: change in the TRANSIENT lifespan policy"s semantics
   (from "cannot outlive the process" to "cannot outlive the POA instance")
 - Page 11-35: change in PortableServer::POA::set_servant_manager()
   semantics wrt multiple invocations
 
 I wonder which other tidbits I"ve overlooked so far. Is there a complete
 list of changes (such as a CVS log) anywhere?

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue

Discussion:

 change in PortableServer::POA::set_servant_manager()

Issue 2844: OBV interface support inconsistencies (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.3 chapter 3.8.5 (docs/formal/99-07-07.pdf, p. 3-27) claims that
 a stateful value can only support a single interface.
 
 CORBA 2.3 chapter 5.2 (docs/formal/99-07-09.pdf, p. 5-2) claims that
 a concrete (stateful) value can support multiple interfaces.
 
 The latter is obviously wrong.

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2846: POA: false placement of paragraph (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: In CORBA 2.3, chapter 11.3.8.11 (docs/formal/99-07-15.pdf, p. 11-35):
 seems to me as if the paragraph that was added to the description of
 get_servant_manager() is really intended for set_servant_manager().

Resolution:
Revised Text:
Actions taken:
August 15, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2847: ambiguity in wstrings having a Unicode escape sequence (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary:  According to the spec, a wide string may contain one or
  more Unicode escape sequences of the form \uxxxx, where
  the x"s are hex digits. It also says that such an
  escape sequence may not have the value 0, and that
  leading 0s are optional in the hex digits.
  Taking all this into account, how does a parser
  tell the difference between (imaginary parentheses
  inserted to show the writer"s intent)

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2848: chapter 3 and recursion (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: CORBA 2.3, chapter 3, section 3.10.2, page 3-35 says: "Although the IDL
 syntax allows the generation of recursive constructed type specifications,
 the only recursion permitted for constructed types is through the use of
 the sequence template type." With the introduction of valuetypes, this is
 no longer true. A valuetype is allowed to have a member of its own type,
 either directly or indirectly.

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed sisue

Discussion:

Issue 2849: CORBA 2.3: minor editorial issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: On page 4-5 of CORBA 2.3 the deprecated create_recursive_sequence_tc
 operation is missing its open parenthesis for its parameter list.

Resolution:
Revised Text:
Actions taken:
August 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

 received issue

Issue 2859: Wchar as discriminator in union (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: 	Just got a question from our IDL compiler folks - I think they"ve
 found a bug in the 2.3 IDL chapter..... (actually the bug has been there
 for a while)..
 
 Looking at the new CORBA2.3 book,
 
 The syntax for discriminated unions are described on two pages (3-16 and
 3-36). 
 On both pages the <wchar_type> isn"t included in the grammar for
 <switch_type_spec>. Therefore my conclusion was that it shouldn"t be
 allowed. The problem is that further down on page 3-36 there is a table
 for "case label matching" and in that table wchar is listed as a
 discriminator type.
 
 
 
 So, was the wchar type forgotten from the grammar for switch type spec,
 or
 was wchar mistakenly added to the table?

Resolution:
Revised Text:
Actions taken:
August 26, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2861: POA exception minor codes (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: There are several cases in the POA specification where the POA is required to
 raise system exceptions.  We should assign OMG minor exception codes to
 each of these cases so that applications can diagnose these conditions
 better.
 
 Examples:
 
 1.  POA has the USE_DEFAULT_SERVANT policy but no servant is assigned, the
 POA raises OBJ_ADAPTER.
 
 2.  If no adapter activator is available (or the available one refuses to
 create a POA), the OBJECT_NOT_EXIST exception is raised.

Resolution:
Revised Text:
Actions taken:
August 31, 1999: received issue
August 31, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2883: IDL constant declarations (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: the spec makes no statement as to the legality of the following constant
 definitions:
 
 	const long C1 = 3.14;
 	const short C2 = 1.0;
 	const unsigned long C3 = -1;
 	const char C4 = 10;
 	const char C5 = 500;
 	const long C6 = 999999;
 	const short C7 = C6;
 	const octet C8 = 1000;
 	const short C9 = C5;
 	const short C10 = 100 * 100 * 100;
 
 I"m sure that there are lots of others I haven"t thought of, but you get
 the idea...
 
 There are certainly lots of holes in the spec, with respect to both the
 legal types of the RHS and rules for overflow/underflow and mixed-type
 arithmetic. Looks like this will require a major cleanup...

Resolution:
Revised Text:
Actions taken:
September 12, 1999: received issue

Discussion:

Issue 2892: DataInputStream specification is inefficient for Java (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Summary: This issue is for the Core RTF.  Although it shows up in the context of Java,
 fixing it requires a change to an API defined in the CORBA core. 
 
 The CORBA::DataInputStream type (part of the CORBA core) is specified in
 a way that makes it extremely inefficient to implement in Java.  A small
 change to this IDL definition would reduce the number of Java classes needed
 to implement it from 27 to 1.  (Really!)

Resolution:
Revised Text:
Actions taken:
September 17, 1999: received issue
October 30, 2000: closed issue

Discussion:

Issue 2896: What is the RepId of Object? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

"Can someone please clue me in as to what the
> repository ID of Object is? Is it "IDL:omg.org/CORBA/Object:1.0"? Or is
> it "IDL:omg.org/Object:1.0"?"

Resolution:
Revised Text:
Actions taken:
October 20, 1999: received issue
October 30, 2000: closed issue

Issue 2898: Why are Standard Exceptions defined in IDL chapter? (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the Standard Exception definitions are in Chapter 3 IDL
Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces?
I would like to get a feel for how the RTF membership feels about moving the
entire section 3.21 from Chapter 3 to Chapter 4.

Resolution:
Revised Text:
Actions taken:
October 13, 1999: received issue
October 30, 2000: closed issue

Issue 2900: URLs interact poorly with code set selection (orb_revision)

Click here for this issue's archive.
Source: Cisco Systems (Mr. Paul Kyzivat, pkyzivat(at)cisco.com)
Nature: Uncategorized Issue
Severity:
Summary:

The corbaname & corbaloc url formats provide a situation where an IOR
designating a server is created and used by a client without input by
that server.

One (optional) element of an IOR is a CodeSetComponent specifying the
code sets that the server is willing/able to utilize. Normally these are
examined by a client and used to select a pair of code sets (narrow and
wide) to be used for communication between client and server.

Chapter 13 of the Corba spec states: "If the code set component is not
present in a multi-component profile structure, then the deault char
code set is ISO 8859-1 for backward compatibility. However, there is no
default wchar code set. If a server supports interfaces that use wide
character data but does not specify the wchar code sets that it
supports, client-side ORBs will raise exception INV_OBJREF."

This seems to imply one of the following:
1) URLs may not be used to reference interfaces that employ wide
   characters;
2) URLs must generate IORs with a code set component supporting
   wchar data;
3) The CORE must be changed to relax the above restrictio

Resolution:
Revised Text:
Actions taken:
October 5, 1999: received issue
October 30, 2000: closed issue

Issue 2901: Semantics of DynAny with alias TypeCodes (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3 spec for DynAny makes no mention whatsoever of how it should
handle Any values corresponding to TypeCodes whose kind is tk_alias.  

The implementation of (CORBA 2.2) DynAny in a popular free ORB strips off
typecode aliases when it creates a DynAny.  While this seems to be contrary to
the overall intent of the DynAny spec, I can find nothing in the 2.2 or 2.3 
spec that definitively precludes this (IMO bogus) behaviour.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2903: Use of incomplete recursive TypeCodes underspecified (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

Section 10.7.3 of the CORBA 2.3 spec says that operations on recursive
TypeCodes and recursive sequence TypeCodes before they have been embedded
give undefined results.  

However, it is not clear whether this applies to other uses of these
TypeCodes ... or other incomplete TypeCodes or Anys that contain them.  For 
example, can an incomplete TypeCode be used:

  * as a parameter to create_dyn_any_from_type_code,

  * as a parameter to a DII or DSI operation; e.g. the arg_type parameter 
    of CORBA::Request::add_arg(), or

  * as a (CORBA IDL) parameter or result of a regular operation invocation?

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2906: DynFixed editorial issue (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

In the CORBA 2.3 spec for DynFixed::set_value (page 9-14) it says, "If val
contains a value whose scale exceeds that of the DynFixed or is not
initialized, the operation raises InvalidValue."

Later in the same paragraph it says, "If val has more fractional digits
than can be represented in the DynFixed, fractional digits are truncated
and the return value is false."

Given that the term "scale" is used with the fixed-point type to describe
the number of fractional digits, these two quoted sentences are confusing
and appear to contradict one another.

I propose changing the first quoted sentence to: "If val contains a value
whose number of digits exceeds the maximum number of digits specified by
the TypeCode of the DynFixed, or if val is not initialized, the operation
raises InvalidValue."

Resolution:
Revised Text:
Actions taken:
September 29, 1999: received issue
October 30, 2000: closed issue

Issue 2907: creation of arguments to TypeCode creation ops (orb_revision)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, crawley(at)dstc.edu.au)
Nature: Uncategorized Issue
Severity:
Summary:

It is not clear from section 10.7.3 of CORBA 2.3 how much param checking
the ORB operations for TypeCode creation should do.  It is also unclear
whether only the BAD_PARAM exception should be raised, or whether some
others are legitimate; e.g. BAD_TYPECODE.

Here are some detailed questions on TypeCode creation argument checking:

  1)  should the operations that take a "name" argument check that it 
      is a valid IDL name?  A non null string?

  2)  should the operations that take a "RepositoryId" argument check
      that it has a recognisable format?  

  3)  should the operations that take content and member types as
      parameters check that they are legitimate; i.e. that they
      don't have kinds tk_null, tk_void or tk_exception.

  4)  should the operations that take members check that the member
      names are valid IDL names and that they are unique within the
      member list?

  5)  should create_union_tc check that there are no duplicate label
      values?  Should it check that the labels' TypeCodes are equal to
      discriminator TypeCode?  Or equivalent?

  6)  should create_union_tc check that the supplied discriminator
      type is legitimate?

There are probably more cases as well.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2908: CORBA::ORB::RequestSeq definition obsolete (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3 added the CORBA::RequestSeq definition to orb.idl.  The C++
mapping defines CORBA::ORB::RequestSeq, which is now redundant and
should be removed.

Resolution:
Revised Text:
Actions taken:
October 12, 1999: received issue
October 30, 2000: closed issue

Issue 2909: formal/99-08-01.txt missing pragmas (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The ORB Core IDL extracted in formal/99-08-01.txt is missing the various
'#pragma' definitions for the IFR interfaces.

Resolution:
Revised Text:
Actions taken:
October 12, 1999: received issue
October 30, 2000: closed issue

Issue 2910: CORBA 2.3 spec hasn't been updated with corrections in COM-CORBA Part B (orb_revision)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

 I notice that the CORBA 2.3 spec hasn't been updated with one of the corrections  in
 part B of the COM-CORBA Interworking spec (orbos/97-09-06).

page 13C-130 of the Part B spec, CORBA::Char mapping to UI1 has not been updated 
in the corresponding section in the CORBA 2.3 spec (19.3.1, page 19-10).

Resolution:
Revised Text:
Actions taken:
October 13, 1999: received issue
October 30, 2000: closed issue

Discussion:

 with one of the corrections  in
 part B of the COM-CORBA Interworking spec (orbos/97-09-06).

Issue 2911: Problem with text of POAManager::deactivate() (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The first paragraph of 11.3.2.6 says:

This operation changes the state of the POA manager to inactive. If
issued while the POA manager is in the inactive state, the
AdapterInactive exception is raised. Entering the inactive state causes
the associated POAs to reject requests that have not begun to be
executed as well as any new requests.

But the last paragraph says:

If deactivate is called multiple times before destruction is complete
(because there are active requests), the etherealize_objects parameter
applies only to the first call of deactivate; subsequent calls with
conflicting etherealize_objects settings will use the value of the
etherealize_objects from the first call. The wait_for_completion
parameter will be handled as defined above for each individual call
(some callers may choose to block, while others may not).

So which is right?  Is does a subsequent call to deactivate() raise
AdapterInactive, or does it succeed, perhaps blocking until completion?

Resolution: Incorporate changes and close issue
Revised Text: Replace the sentence in the first paragraph of 11.3.2.6 that says: "If issued while the POA manager is in the inactive state, the AdapterInactive exception is raised." with: "This operation has no affect on the POA manager's state if it is already in the inactive state, but may still block if wait_for_completion is TRUE and another call to deactivate on the same POA manager is pending."
Actions taken:
October 18, 1999: received issue
February 27, 2001: closed issue

Discussion:

In this case it is best to NOT throw the exception and allow 
multiple concurrent calls to deactivate().  Otherwise, if an 
application 
needs to have this behavior (where different threads might call 
deactivate()), it requires more code to catch the exception and then 
block waiting for the other deactivate call to complete.

Issue 2912: (CORBA Core) Data streams missing arrays of long double (orb_revision)

Click here for this issue's archive.
Source: Oracle (Dr. Dan Frantz, )
Nature: Uncategorized Issue
Severity:
Summary:

DataInputStream and DataOutputStream (CORBA 2.3, Section 5.5.2) has
definitions for reading and writing individual items and arrays of
primitive data types except long double. This seems to be an
oversight.

Resolution:
Revised Text:
Actions taken:
September 22, 1999: received issue
October 30, 2000: closed issue

Issue 2913: Component ids in 13.6.2.2 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Also, 13.6.2.2 claims "ORB services are assigned component identifiers
 in a namespace that is distinct from the the profile identifiers".
 What is the significance of this statement?

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
September 28, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 2944: Editorial issue for CORBA 2.3, 1.3.8.20 (orb_revision)

Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 11.3.8.20 (servant_to_id) was not updated in the same fashion as
section 11.3.8.21.

There are two problems:

1.  The RETAIN policy in the first paragraph needs bold face.

2.  Behaviors 1 & 2 should both require the RETAIN policy, just like the
text in section 11.3.8.21.

Resolution:
Revised Text:
Actions taken:
October 20, 1999: received issue
October 30, 2000: closed issue

Issue 2945: CORBA 2.3 Editorial issue for TypeCodes & abstract_interface (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The comments in the definition of TypeCode in 10.7.1 shows that id() and
name()
are valid for TypeCodes of kind tk_abstract_interface, but the text
descriptions of the id() and name() operations do not list abstract
interface TypeCodes as supporting these operations.

Resolution:
Revised Text:
Actions taken:
October 21, 1999: received issue
October 30, 2000: closed issue

Issue 2954: Exception section issue (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the Standard Exception definitions are in Chapter 3 IDL
Syntax and Semantics. Shouldn't they be better in Chapter 4 ORB Interfaces? I would like to get a feel for how the RTF membership feels about moving the
entire section 3.21 from Chapter 3 to Chapter 4.

Resolution:
Revised Text:
Actions taken:
October 14, 1999: received issue
October 30, 2000: closed issue

Issue 2955: General Exception Question (orb_revision)

Click here for this issue's archive.
Source: International Business Machines (Mr. Russell Butek, )
Nature: Uncategorized Issue
Severity:
Summary:

Could someone explain to me the justification for all the restrictions on
> exceptions?  Why CAN'T we:  pass exceptions as parameters, use them as
> elements in container types?  I know the IDL language doesn't allow it, I
> just want to know why it was designed that way.  Other languages certainly
> allow it.

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2959: Minor codes for Standard System Exceptions in Chapter 5 missing (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 5 (formal/99-07-09) is missing specification of minor codes for all the
standard system exceptions that are specified to be raised under various
circumstances.

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2960: Minor codes for Standard System Exceptions in Chapter 8 missing (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 8 (formal/99-07-12) is missing specification of minor codes for all the
standard system exceptions that are specified to be raised under various
circumstances.

Resolution:
Revised Text:
Actions taken:
October 26, 1999: received issue
October 30, 2000: closed issue

Issue 2963: Type Code Section issue (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

I was wondering why the TypCodes definition section is in Chapter 10, Interface
Repository. Type Codes are used by lots of other things that have very little to
do with Interface Repository. Wouldn't it be better to move the TypeCode section
to Chapter 4.

Resolution:
Revised Text: Resolution: Move the TypeCode section from Chapter 10 to Chapter 4 and readjust section numbers in both chapters and update all cross references. Revised Text: All changes with reference to orbrev/01-03-01: 1. Move section 10.7 to become section 4.11. Slide section 4.11 "Exceptions" to become section 4.12, and old section 10.8 to become new section 10.7. 2. Remove the TypeCode related IDL from section 10.8 starting at about middle of page 10-73 and ending at the end of the section. This is already there in section 10.7 that is moved to Chapter 4. 3. Update all affected cross references appropriately.
Actions taken:
October 27, 1999: received issue
November 5, 1999: moved from core to components ftf
May 19, 2001: moved from components ftf back to core
October 3, 2001: closed issue

Issue 2974: PIDL vs Local (orb_revision)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

Regarding using a version in a repository ID:

If old PIDL were to be recast to local, each time the
interface def would be enhanced (by adding new local
operations), the IDL module would have to be appropriately
versioned.

I also point out that using a version for corba::object's repository
id seems inappropriate, since there are multiple version of
corba::object which the omg never bothered to version, since they
did not have to.  

Thus, in summary, putting version 1.0 to correspond to a pidl interface
implies stability in that inteface (i.e., it will not change without
changing
the version number), which the OMG has never enforced for PIDL.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
October 25, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 2976: IDL and C++ relationship (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

page 3-2 of the spec says (Section 3.1, para 3 and para 5):

	OMG IDL obeys the same lexical rules as C++.

	[ ... ]

	The OMG IDL grammar is a subset of the proposed ANSI C++ standard...

Both paragraphs are simply wrong. IDL doesn't obey the same lexical rules
and it isn't a subset of C++. In addition, we now have the final ISO/IEC
C++ standard, so talking about the proposed or draft standard is out of date.

I would suggest to systematically replace references to ANSI C++, the
"proposed" standard, or the "draft" standard with the proper ISO/IEC
reference.

The verbage about IDL being a subset of C++ and obeying the same lexical
rules should be removed. It simply isn't true.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2977: Preprocessing of IDL (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Page 3-12:

        OMG IDL preprocessing, which is based on ANSI C++ preprocessing, ..
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The highlighted phrase is meaningless and should be deleted.

In addition, the last para of 3.3 says that

	A complete description of the preprocessing facilities may be found
	in the The Annotated C++ Reference Manual.

For one, the ARM is badly out of date. Second, the para implies, but doesn't
actually say, that IDL preprocessing is exactly like C++ preprocessing.

I would suggest to replace the last para with a definitive statement to
say that IDL is preprocessed as described for C++ in the ISO/IEC C++ standard.
In addition, that statement should probably be used as the lead-in to
section 3.3.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2978: Meaningless sentence on page 3-11? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature:
Severity:
Summary:

Page 3-11 says about string literals:

	The size of a string literal is the number of character literals
	enclosed by the quotes, after concatenation. The size of the
	literal is associated with the literal.

The final sentence appears to be meaningless. Suggest to delete it.

Resolution:
Revised Text:
Actions taken:
November 3, 1999: received issue
October 30, 2000: closed issue

Issue 2980: Problem with the "Special scoping" rules in 3.15.3 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The special scoping rules make it clear that they apply only to
identifiers that name a type, however the second IDL example claims that
the import of a constant definition (in this case the identifier I) into
an interface scope behaves the same way.

So which one is it?  Do the rules only apply to type identifiers or to
all identifiers?

Resolution: The changes below provide clarification.
Revised Text: The text below is replacement text for page 3-56 and replaces the paragraph beginning with Once a type identifier has been *used* anywhere within the scope... up to (but excluding) the paragraph Note that redefinitinos of a type after use in a module is OK as in the example: Replacement text: The scope of of a type definition extends from the point of definition to the end of its enclosing scope. (Constant and exception definitions are considered type definitions.) A type is *introduced* into a scope by its use in that scope, if the type name is not a fully-qualified type name. For example: typedef short TempType; // Scope of TempType begins here module M { typedef string ArgType; // Scope of ArgType begins here struct S { ::M::ArgType a1; // Nothing introduced here M::ArgType a2; // M introduced here ::TempType temp; // Nothing introduced here }; // Scope of (introduced) M ends here // ... }; // Scope of ArgType ends here // Scope of global TempType ends here (at end of file) The scope of an introduced type name is from the point of introduction to the end of its enclosing scope. However, if a *type* name is *introduced* into a scope that is nested in a non-module scope definition, its *potential* scope extends over all its enclosing scopes out to the enclosing non-module scope. (For types that are defined outside an inon-module scope, the scope and the potential scope are identical.) For example: module M { typedef long ArgType; const long I = 10; typedef short Y; interface A { struct S { struct T { ArgType x[I]; // ArgType and I introduced long y; // a new y is defined, the existing Y // is not used } m; }; typedef string ArgType; // Error: ArgType redefined enum I { I1, I2 }; // Error: I redefined typedef short Y; // OK }; // Potential scope of ArgType and I ends here }; A type may not be redefined within its scope or potential scope, as shown in the preceding example. This rule prevents type names from changing their meaning throughout a non-module scope definition, and ensures that reordering of definitions in the presence of introduced types does not affect the semantics of a specification. Note that, in the following, the definition of M::A::U::I is legal because it is outside the potential scope of the I introduced in the definition of M::A::S::T::ArgType. However, the definition of M::A::I is still illegal because it is within the potential scope of the I introduced in the definition of M::A::S::T::ArgType. module M { typedef long ArgType; const long I = 10; interface A { struct S { struct T { ArgType x[I]; // ArgType and I introduced } m; }; struct U { long I; // OK, I is not a type name }; enum I { I1, I2 }; // Error: I redefined }; // Potential scope of ArgType and I ends here };
Actions taken:
November 8, 1999: received issue
February 27, 2001: closed issue

Issue 3000: Codeset conversions and unions (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

Recently, we decided not to permit wchar as the discrinator type for
unions because of the impossibility of dealing with different codesets.

Well, it looks like we have exactly the same problem for char

Resolution:
Revised Text:
Actions taken:
November 4, 1999: received issue
October 30, 2000: closed issue

Issue 3001: The algorithm for TypeCode::equivalent in 10.7.1 was not updated (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The algorithm for TypeCode::equivalent in 10.7.1 was not updated to
reflect the new TypeCode::member_visibility, TypeCode::type_modifier,
and TypeCode::concrete_base_type operations.

Resolution:
Revised Text:
Actions taken:
November 4, 1999: received issue
October 30, 2000: closed issue

Issue 3015: why was is_abstract added to structs in CORBA IR? (orb_revision)

Click here for this issue's archive.
Nature: Clarification
Severity:
Summary:

I was wondering if anyone can explain the rationale for adding the field
'is_abstract' to the CORBA::InterfaceDescription and
CORBA::InterfaceDef::FullInterfaceDescription struct types in the CORBA
2.3 Interface Repository specification. (I do know about abstract interfaces,
I am really looking for the rationale for breaking backwards compabitility).

Basically, a CORBA 2.3 client using stubs compiled from the latest IDL cannot
interoperate using IIOP with the Interface Repository of a pre-CORBA 2.3 ORB,
because virtually any client of the IR will want to obtain a
FullInterfaceDescription from an InterfaceDef, and a pre-CORBA 2.3 ORB will
not marshal the 'is_abstract' field for the description struct, thereby the
CORBA 2.3 client will fail to unmarshal the struct.

Resolution: flagged as urgent....resolved
Revised Text: 0. Add a new minor code <foo> to the BAD_PARAM exception in Section 3.17.2, that says "Attempt to derive abstract interface from non-abstract base interface in the Interface Repository". [Note: This is necessary to cover for the fact that someone could try to AbstractInterfaceDef::_set_base_interfaces with an InterfaceDefSeq that contains an InterfaceDef that is not an AbstractInterfaceDef.] 1. Add a new enum value dk_AbstractInterface to CORBA::DefinitionKind. This is used as the value returned by the inherited def_kind attribute. 2. add create_abstract_interface to CORBA::Container AbstractInterfaceDef create_abstract_interface( in RepositoryId id, in Identifier name, in VersionSpec version in AbstractInterfaceDefSeq base_interfaces ); and add the following text description: The create_abstract_interface operation returns a new empty AbstractInterfaceDef with the specified base_interfaces. Other types can be added in the same way as InterfaceDef allows types to be added. 3. Add a new section 10.5.xx as follows 10.5.xx AbstractInterfaceDef An AbstractInterfaceDef object represents a CORBA 2.3 abstract interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. *Its base interfaces can only contain AbstractInterfaceDefs.* module CORBA { interface AbstractInterfaceDef; typedef sequence<AbstractInterfaceDef> AbstractInterfaceDefSeq; interface AbstractInterfaceDef : InterfaceDef { }; 10.5.xx.1 Read Interface [Note: I have filled in the actual text describing the operations from the corresponding text in InterfaceDef, so that minor changes can be made to the text to account for minor differences.] The inherited base_interfaces attribute returns a list of abstract interfaces from which this abstract interface inherits. Note: base_interfaces is of type InterfaceDefSeq, but since AbstractInterfaceDef is derived from InterfaceDef, a list of AbstractInterfaceDefs can legitimately be returned in an InterfaceDefSeq. The inherited is_a operation returns TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the abstract interface identified by its interface_id parameter, or if the value of interface_id is IDL:omg.org/CORBA/AbstractBase:1.0 . Otherwise it returns FALSE. The inherited describe_interface operation returns a FullInterfaceDescription describing the abstract interface, including its operations and attributes. The inherited describe operation for an AbstractInterfaceDef returns an InterfaceDescription. The inherited contents operation returns the list of constants, typedefs, and exceptions defined in this AbstractInterfaceDef and the list of attributes and operations either defined or inherited in this AbstractInterfaceDef. If the exclude_inherited parameter is set to TRUE, only attributes and operations defined within this interface are returned. If the exclude_inherited parameter is set to FALSE, all attributes and operations are returned. 10.5.xx.2 Write Interface Setting the inherited base_interfaces attribute causes a BAD_PARAM exception with standard minor code 5 to be raised if the name attribute of any object contained by this AbstractInterfaceDef conflicts with the name attribute of any object contained by any of the specified base AbstractInterfaceDefs. *If any of the InterfaceDefs in base_interface are not AbstractInterfaceDefs then a BAD_PARAM exception with standard minor code <foo> is raised.* The inherited create_attribute operation returns a new AttributeDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, type_def, and mode attributes are set as specified. The type attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object�s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. The inherited create_operation operation returns a new OperationDef contained in the AbstractInterfaceDef on which it is invoked. The id, name, version, result_def, mode, params, exceptions, and contexts attributes are set as specified. The result attribute is also set. The defined_in attribute is initialized to identify the containing AbstractInterfaceDef. An error is returned if an object with the specified id already exists within this object�s Repository, or if an object with the specified name already exists within this AbstractInterfaceDef. 4. Make the following changes to section 10.5.23: First paragraph: restore it to as it was before 2.3. An InterfaceDef object represents an interface definition. It can contain constants, typedefs, exceptions, operations, and attributes. IDL: restore this part to as it appeared in CORBA 2.2. module CORBA { interface InterfaceDef; typedef sequence <InterfaceDef> InterfaceDefSeq; typedef sequence <RepositoryId> RepositoryIdSeq; typedef sequence <OperationDescription> OpDescriptionSeq; typedef sequence <AttributeDescription> AttrDescriptionSeq; interface InterfaceDef : Container, Contained, IDLType { // read/write interface attribute InterfaceDefSeq base_interfaces; // read interface boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; OpDescriptionSeq operations; AttrDescriptionSeq attributes; RepositoryIdSeq base_interfaces; TypeCode type; }; FullInterfaceDescription describe_interface(); // write interface AttributeDef create_attribute ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType type, in AttributeMode mode ); OperationDef create_operation ( in RepositoryId id, in Identifier name, in VersionSpec version, in IDLType result, in OperationMode mode, in ParDescriptionSeq params, in ExceptionDefSeq exceptions, in ContextIdSeq contexts ); }; struct InterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; VersionSpec version; RepositoryIdSeq base_interfaces; }; }; Read interface: Remove the description of the is_abstract attribute. 7. Remove all version pragmas from all IFR related IDL. [Note: This is necessary in order to make sure that a 2.2 InterfaceDef is not rejected as not equivalent to t 2.3 InterfaceDef. Admittedly this is a bit hokey since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional operations through derivation when compared to 2.2 InterfaceDef, but from an interoperability and backward compatibility perspective this is relatively benign since a 2.3 client attempting to invoke a 2.3 operation on a 2.2 IFR will merely get a BAD_OPERATION. A 2.2 client will never be able to invoke a 2.3 operation anyway. There are cases where a 2.2 client may get back a 2.3 IRObject containing a dk_* value that is unknown to the 2.2 client. In the better written ORBs these will cause MARSHAL exception due to failure to unmarshal the unknown value of an enumerator. In other ORBs the client may have a problem if it is not programmed defensively.]
Actions taken:
November 9, 1999: received issue
February 4, 2000: closed issue

Discussion:

Adding the is_abstract member to the Structs InterfaceDescription and FullInterfaceDescription and associated
changes to the InterfaceDef interface was an error. The correct way to do this is shown below.

A proper resolution to 3015 should recognize that because Abstract
Interfaces are a distinct type in IDL, they should be their own type in the
IFR as well. This distinction has already been addressed in TypeCodes with
create_abstract_interface_tc and tk_abstract_interface. Because the
behaviors of interfaces and abstract interfaces are very different, this
should also be stressed in the IFR.

Consequently, in keeping with the general pattern established with the way abstract
interfaces are handled in TypeCodes, it is porposed that AbstractInterfaceDef be
defined as an IFR object that represents Abstract Interfaces, and that otherwise
has all the attribtues, operations and properties similar to InterfaceDef. This is represented
by having AbstractInterfaceDef derive from InterfaceDef, sort of recognizing
that an AbstractInterfaceDef IR Object is an InterfaceDef of a special restricted kind.
It is necessary to ensure, however, that the base_interfaces of AbstractInterfaceDefs only
contain AbstractInterfaceDefs.

Also, It is necessary to remove version pragmas at least from InterfaceDef
in order to make sure that a 2.2 InterfaceDef is not
rejected as not equivalent to a 2.3 InterfaceDef. Admittedly this is a bit hokey
since a 2.3 InterfaceDef derives from a 2.3 Container and hence has additional
operations through derivation when compared to 2.2 InterfaceDef, but from
an interoperability and backward compatibility perspective this is relatively benign
since a 2.3 client attmepting to invoke a 2.3 operation on a 2.2 IFR will
merely get a BAD_OPERATION. A 2.2 client will never be able to invoke
a 2.3 operation anyway.

Since it would then be absurd for a 2.2 (aka 1.0) InterfaceDef to be deriving from
a 2.3 Container, it is necessary to remove version pragmas from the transitive closure
of the dependency graph for InterfaceDef. It is much easier to remove all version
pragmas from IFR interfaces and other IDL entities.

It is acknowledged that this is not a complete and clean resolution, but it is also acknowledged
that it is impossible to fix all version problems that have accumulated in the
IFR due to past carelessness. With these changes, it is believed that pre-2.3 and 2.3 IFR are
able to interoperate compatibly with pre 2.3 or 2.3 clients. Future enhancements to IFR
should be carried out with greater care and with more attention towards compatibility and
cleanliness of versioning.

Issue 3018: Missing "abstract" in forward declaration (orb_revision)

Click here for this issue's archive.
Source: Perot Systems (Mr. Charles W. Binko, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

In the new Core 2.3.1 (http://www.omg.org/cgi-bin/doc?formal/99-10-07),
section 3.7.4 is incorrect in that it does not mention the optional
"abstract" keyword.

A forward declaration declares the name of an interface without defining it.
This
permits the definition of interfaces that refer to each other. The syntax
consists simply

of the keyword interface followed by an <identifier> that names the
interface. The
actual definition must follow later in the specification.

The paragraph is not in sync with the idl grammar in section 3.4

(6) <forward_dcl> ::= [ "abstract" ] "interface" <identifier>

Resolution:
Revised Text:
Actions taken:
November 10, 1999: receive dissue
October 30, 2000: closed issue

Issue 3020: Question about IDL \uxxxx escape format (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Clarification
Severity:
Summary:

Why was the \uxxxx escape from C++ added to wide string & char literals
in IDL, but the equivalent \Uxxxxxxxx escape was not?

Resolution: Duplicate
Revised Text:
Actions taken:
November 11, 1999: received issue
October 30, 2000: closed issue

Issue 3021: Section 7.6: IDL context housecleaning (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Now that we've bitten the bullet and moved the Exception section from
chapter 3 to chapter 4, shouldn't we do the same thing with section 7.6,
since IDL contexts actually have little to do with the DII?

I propose that we move section 7.6 to chapter 4 as well.

Resolution:
Revised Text:
Actions taken:
November 12, 1999: received issue
October 30, 2000: closed issue

Issue 3022: What is the NO_RESPONSE exception good for? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 3.17.1.15 states:

"NO_RESPONSE

This exception is raised if a client attempts to retrieve the result of
a deferred synchronous call, but the response for the request is not yet
available."

Meanwhile, section 7.3.4 states:

"get_response returns the result of a request. If get_response is called
before the request has completed, it blocks until the request has
completed."

So if get_response blocks, how and when will and ORB ever raise
NO_RESPONSE?

Resolution:
Revised Text:
Actions taken:
November 12, 1999: received issue
October 30, 2000: closed issue

Issue 3041: Editorial glitch in DynAny::destroy, section 9.2.3.6 (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

The first paragraph of 9.2.3.6 refers to "creation operations on the ORB
interface".  This needs to be changed to "creation operations on the
DynAnyFactory interface".

Resolution:
Revised Text:
Actions taken:
November 16, 1999: received issue
October 30, 2000: closed issue

Issue 3048: TypeCode issue (orb_revision)

Click here for this issue's archive.
Source: ZeroC (Mr. Marc Laukien, marc(at)zeroc.com)
Nature: Uncategorized Issue
Severity:
Summary:

At present, the following IDL code is illegal:

interface I
{
    CORBA::TypeCode get_type();
};

To make it legal, "orb.idl" must be included. From the spec:

"The file orb.idl contains the IDL definitions for the CORBA module. The
file orb.idl must be included in IDL files that use names defined in the
CORBA module."

I don't think that this is a good idea, because of the following
reasons:

- TypeCode is PIDL, not IDL. So orb.idl can only be used as a "switch"
to enable TypeCode, but it cannot contain a "real" IDL definition for
TypeCode.

- Having to include orb.idl for every little program that requires
TypeCode means a huge overhead, as orb.idl includes *everything* from
the CORBA module (including the IFR!).

I don't see any reason why TypeCode should only be available if orb.idl
is included. To me, TypeCode is "built-in", even if it doesn't have a
keyword. So it appears rather strange to me that I have to artificially
disable TypeCode in our  IDL parser if orb.idl is not included, just to
be compliant with the spec.

I would therefore propose to allow CORBA::TypeCode in IDL even if
orb.idl is not included.

Resolution:
Revised Text:
Actions taken:
November 23, 1999: receved issue
October 30, 2000: closed issue

Issue 3069: OMG IDL Syntax and Semantics issue (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

The following thing is unnoticed in CORBA V2.3, June 1999, OMG document 
99-07-07.pdf, Chapter 3, "OMG IDL Syntax and Semantics", pages 3-37..3-39,
definition of "sequence" type:

There is no explicit definition what length sequence may have at run 
time. Things are perfectly defined for sequence bounds (i.e. maximum
size at compile time) which is explicitly declared to be a positive
integer. However, nothing is said whether length of sequence at run
time can be: (a) positive; or (b) non-negative; or even (c) negative.

Resolution:
Revised Text:
Actions taken:
November 29, 1999: received issue
October 30, 2000: closed issue

Issue 3072: value type substitutability (orb_revision)

Click here for this issue's archive.
Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com)
Nature: Uncategorized Issue
Severity:
Summary:

Chapter 5.2.5: Value type semantics should not define that an instance of a 
value type can be passed (directly) as a parameter that is declared as an 
interface type. The reason is that this is not true in some of the language 
mappings (e.g. C++) because it contradicts the kind and nature of value types.

A value type instance IS NOT an object reference even if it is registered with 
the ORB. Therefore, if a construct conceptually is not a subtype of another 
construct, it should not be possible that it substitutes the other. Also, it 
should not be required that there are any shortcuts which automatically convert 
a registered valuetype to it's associated object reference.

Resolution: Clarify the ambiguity that leads to the possible inappropriate interpretation
Revised Text: 1. Leave the first paragraph of section 5.2.5 unchanged. 2. Replace the second paragraph by: "There are three cases to consider: the parameter type is a regular interface, the parameter type is an abstract interface, and the parameter type is a value type." 3. Replace the current text in section 5.2.5.1 by: "A value type that supports a regular interface is not a subtype of that interface, and hence cannot be substituted for that interface in an invocation parameter. In this case an object reference corresponding to the value type instance that has been registered with the ORB must be obtained and this object reference must be used as the actual parameter. Different language mappings provide different facilities to aid in such parameter passing." 4. Add a new section 5.2.5.2 Value Instance -> Abstract interface type: "A value type that supports an abstract interface is a subtype of that interface, and can be substituted for that interface in an invocation parameter." 5. Renumber the existing section 5.2.5.2 to 5.2.5.3.
Actions taken:
November 30, 1999: received issue
February 27, 2001: closed issue

Issue 3073: create_POA and inactive state? (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

what should happen if I call create_POA() on a POA whose POA manager is
in the inactive state (that is, a POA on which, previously, deactivate()
was called?

The spec says nothing about this. Seeing that creating a new POA on a "dead"
POA doesn't make sense, I would suggest to raise BAD_INV_ORDER, possibly
with a new minor code.

Resolution:
Revised Text:
Actions taken:
December 2, 1999: received issue
October 30, 2000: closed issue

Issue 3095: Use of Principal in GIOP Module erroneous (orb_revision)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jmukerji(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

In spite of objections based on misunderstandings from certain quarters
I would like to propose that Principal in the IDL describing GIOP as
excerpted below be replaced by "sequence <octet>". For whatever it might
be worth, doing so would make the IDL in the GIOP module actually
compilable for the first time in its entire existence!:-)

module GIOP { // IDL extended for version 1.1 and 1.2
        // GIOP 1.0
        struct RequestHeader_1_0 { // Renamed from RequestHeader
                IOP::ServiceContextList service_context;
                unsigned long request_id;
                boolean response_expected;
                sequence <octet> object_key;
                string operation;
                Principal requesting_principal;
                ^^^^^^^^^
        };

        // GIOP 1.1
        struct RequestHeader_1_1 {
                IOP::ServiceContextList service_context;
                unsigned long request_id;
                boolean response_expected;
                octet reserved[3]; // Added in GIOP 1.1
                sequence <octet> object_key;
                string operation;
                Principal requesting_principal;
                ^^^^^^^^^
        };

        ...
};

Firstly, ever since the GIOP standard was adopted, the use of Principal 
in that struct has been erroneous, since it is undefined in GIOP module,
unless adorned with a CORBA:: prefix. Secondly, in effect all that it is
trying to say
is that the Principal is represented as a  sequence<octet> in the header
field
requesting_principal, not a Principal pseudo-interface, which is
undefined in that context anyway. Thirdly, even if you could find a
definition for an unadorned Principal somewhere, what is the meaning of
that type when CDR encoded? It really is
nothing but sequence<octet>.

I think this issue should go to the Interop RTF.

Resolution: closed in interop/2000-01-01
Revised Text:
Actions taken:
December 6, 1999: received issue
March 7, 2002: moved to Core RTF
March 22, 2002: closed issue

Issue 3104: Non-standard system exceptions (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Section 3.17.1 says that "ORB implementations may raise non-standard system
exceptions."  This raises a number of questions:

1. How are non-standard system exceptions defined?  Are they defined using
   IDL, or are they PIDL?  If they are IDL, how are they identified as
   system exceptions by the language mappings?

2. The definitions in section 3.17.1 for standard system exceptions appear
   to be IDL, but I believe the intention is that they are PIDL.  This 
   should be stated clearly.

3. Should non-standard system exceptions be defined in the CORBA module like
   the standard system exceptions?  There are three choices:
    a. They must be in the CORBA module.
    b. They must not be in the CORBA nmodule.
    c. They can either be in the CORBA nodule or in other modules.

4. Point 3 raises the more general question of whether it is legal for ORB 
   vendors to add non-standard definitions to the CORBA module.  Section 3.14 
   says that "Names defined by the CORBA specification are in a module named
   CORBA," but it does not say whether these are the only names that may appear
   in the module named CORBA.  This should be clarified.

Resolution: See text below for resolution
Revised Text: With reference to ptc/99-12-07, make the following changes: 1. Replace the paragraph in section 4.11.3 that reads: "The standard system exceptions are defined below. Clients must be prepared to handle system exceptions that are not on this list, both because future versions of this specification may define additional standard exceptions, and because ORB implementations may raise non-standard system exceptions." by: "The standard system exceptions are defined in this sections." 2. In the first sentence of the last paragraph of section 4.11.2 replace the phrase: "Each standard exception....." by the phrase: "Each system exception....." 3. Move the line of PIDL which reads #define ex_body {unsigned long minor; completion_status completed;} from the PIDL in section 4.11.3 to the IDL in section 4.11.2 4. Append the following paragraphs to section 4.11.2, immediately following table defining COMPLETED_YES etc.:: Client applications must be prepared to handle system exceptions other than the standard system exception defined below in section 4.11.3, both because future versions of this specification may define additional standard system exceptions, and because ORB implementations may raise non-standard system exceptions. Vendors may define non-standard system exceptions, but these exceptions are discouraged because they are non-portable. A non-standard system exception, when passed to an ORB that does not recognize it, shall be presented by that ORB as an UNKNOWN standard system exception. The minor code and completion status from the unrecognized exception shall be preserved in the UNKNOWN exception. Non-standard system exceptions shall have the same structure as of standard standard system exceptions as specified in section 4.11.3 below - ie., they have the same ex_body. They also shall follow the same language mappings as standard system exceptions. Although they are PIDL, vendors should ensure that their names do not clash with any other names following the normal naming and scoping rules as they apply to regular IDL exceptions."
Actions taken:
December 10, 1999: received issue
October 6, 2000: closed issue

Issue 3105: Errors in published IDL for CORBA module (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

I found a lot of errors in the CORBA IDL text file that's on the server
for download:
In general, the layout of the file is a mess. Inconsistent, meaningless
indentation, whitespace before semicolons on occasion, comments indented
poorly, etc, etc. Wouldn't hurt to clean this up -- it's quite embarrassing
as it is now.

Resolution:
Revised Text:
Actions taken:
December 10, 1999: received issue
October 30, 2000: closed issue

Issue 3109: DynAny & abstract interfaces don't mix! (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 9.2.2 states:

"The operation raises InconsistentTypeCode if value has a TypeCode with
a TCKind of tk_Principal, tk_native, or tk_abstract_interface."

This is totally broken for abstract interfaces.  What happens if I do
this:

// IDL
abstract interface I {
};

struct S {
    I	an_i;
};

// C++
    S		mys;
    CORBA::Any	a;
    
    a <<= s;

    DynamicAny::DynAnyFactory_var	daf = ...;
    DynamicAny::DynAny_var		da = daf->create_dyn_any(a);
    DynamicAny::DynAny_var		component = da->current_component();

Obviously the value of component must be meaningful, otherwise there is
no way to examine or construct a value of type S.

Resolution:
Revised Text:
Actions taken:
December 10, 1999: received issue
October 30, 2000: closed issue

Issue 3115: Do valueboxes have factories? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Nowhere in the CORBA 2.3 specification is it made clear whether or not
valueboxes have or need a valuefactory.

Since valueboxes are clearly completely concrete types, with no
operations, and with no factory initializers, there is no need for a
factory for valueboxes.

Proposal:

Add the following to secion 5.2.8.1:

"Value box types do not need or use factories."

Resolution:
Revised Text:
Actions taken:
December 14, 1999: received issue
October 30, 2000: closed issue

Issue 3132: What is the TypeCode for ValueBase? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

I know this is late, but I think it is quite urgent, and we ought to
add it to the last Core 2000 vote.]

The spec is silent about the existence and properties of a TypeCode
constant for ValueBase, even though it is necessary to define one so
that the DII, DSI and IFR can operate properly.

There also is no explicit information about what values operation calls
on the TC_Object typecode constant return.

Proposal:

1.  Add to the list of TypeCode constants in 10.7.2:

TC_ValueBase = tk_value { ValueBase }

2.  Add at the end of section 10.7.2:

For the TC_Object TypeCode constant, calling id returns
"IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object".  For
the TC_ValueBase TypeCode constant, calling id returns
"IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase",
calling member_count returns 0, calling type_modifier returns
CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.

Resolution: Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via t
Revised Text: 1. Add to the list of TypeCode constants in 10.7.2: TC_ValueBase = tk_value { ValueBase } 2. Add at the end of section 10.7.2: For the TC_Object TypeCode constant, calling id returns "IDL:omg.org/CORBA/Object:1.0" and calling name returns "Object". For the TC_ValueBase TypeCode constant, calling id returns "IDL:omg.org/CORBA/ValueBase:1.0", calling name returns "ValueBase", calling member_count returns 0, calling type_modifier returns CORBA::VM_NONE, and calling concrete_base_type returns a nil TypeCode.
Actions taken:
December 17, 1999: received issue
October 6, 2000: Incorporate changes in CORBA 2.3 via urgent resolution proces
October 6, 2000: closed issue

Discussion:

Yes, this is a signficant outage. It should be fixed and the fix should be incorporated in 2.3 via the urgent process.

Issue 3134: OMG wchar <-> COM WCHAR in CORBA 2.3 (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Thomas Moriarty, Thomas.Moriarty(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The CORBA 2.3 spec states in table 18-2 that OMG IDL wstring maps to LPWSTR
in COM.

This was presumably added with the introduction of CORBA support for
wstrings. I don't see any mapping defined for OMG wchar. This would
naturally map to COM WCHAR.

Is this an error/omission in the 2.3 spec?

Resolution: OMG IDL wchar should indeed map to COM WCHAR. Add it to table 18-1
Revised Text: Add the following row to Table 18-1 on page 18-2: wchar WCHAR
Actions taken:
December 17, 1999: received issue
October 6, 2000: closed issue

Issue 3135: valuebox and DynAny (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The DynAny chapter says absolutely nothing about value boxes. Do they
fulfill only the base DynAny interface, or the DynValue interface, or do we
need a new DynValueBox interface? If the DynValue interface is supposed to
be used, do you treat the boxed value as a single member? If so, what is
its name?

Resolution: Following text changes address the outage raised in this issue as well as the one from issue 3250
Revised Text: 1. Replace the IDL for DynValue in 9.2 with: interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; ------------------------------------------------------------------------------ 2. Change the complex type initialization bullet in section 9.2.2 for DynValue from: o For DynValue, the members are initialized as for DynStruct. to: o For DynValue and DynValueBox, initialize to a null value ------------------------------------------------------------------------------ 3. Replace section 9.2.10 with: 9.2.10 The DynValueCommon interface DynValueCommon provides operations supported by both the DynValue and DynValueBox interfaces. interface DynValueCommon : DynAny { boolean is_null(); void set_to_null(); void set_to_value(); }; boolean is_null(); The is_null operation returns TRUE if the DynValueCommon represents a null valuetype. void set_to_null(); The set_to_null() operation changes the representation of a DynValueCommon to a null valuetype. void set_to_value(); If the DynValueCommon represents a null valuetype, then set_to_value() replaces it with a newly constructed value, with its components initialized to default values as in DynAnyFactory::create_dyn_any_from_type_code. If the DynValueCommon represents a non-null valuetype, then this operation has no effect. 9.2.11 The DynValue interface DynValue objects are associated with non-boxed valuetypes. interface DynValue : DynValueCommon { FieldName current_member_name() raises(TypeMismatch, InvalidValue); CORBA::TCKind current_member_kind() raises(TypeMismatch, InvalidValue); NameValuePairSeq get_members() raises(InvalidValue); void set_members(in NameValuePairSeq value) raises(TypeMismatch, InvalidValue); NameDynAnyPairSeq get_members_as_dyn_any() raises(InvalidValue); void set_members_as_dyn_any(in NameDynAnyPairSeq value) raises(TypeMismatch, InvalidValue); }; The DynValue interface can represent both null and non-null valuetypes. For a DynValue representing a non-null valuetype, the DynValue's components comprise the public and private members of the valuetype, including those inherited from concrete base valuetypes, in the order of definition. A DynValue representing a null valuetype has no components and a current position of -1. The remaining operations on the DynValue interface generally have equivalent semantics to the same operations on DynStruct. When invoked on a DynValue representing a null valuetype, get_members and get_members_as_dyn_any raise InvalidValue. When invoked on a DynValue representing a null valuetype, set_members and set_members_as_dyn_any convert the DynValue to a non-null valuetype. Warning: indiscriminantly changing the contents of private valuetype members can cause the valuetype implementation to break by violating internal constraints. Access to private members is provided to support such activities as ORB bridging and debugging and should not be used to arbitrarily violate the encapsulation of the valuetype. 9.2.12 The DynValueBox interface DynValueBox objects are associated with boxed valuetypes. interface DynValueBox : DynValueCommon { any get_boxed_value() raises(InvalidValue); void set_boxed_value(in any boxed) raises(TypeMismatch); DynAny get_boxed_value_as_dyn_any() raises(InvalidValue); void set_boxed_value_as_dyn_any(in DynAny boxed) raises(TypeMismatch); }; The DynValueBox interface can represent both null and non-null valuetypes. For a DynValueBox representing a non-null valuetype, the DynValueBox has a single component of the boxed type. A DynValueBox representing a null valuetype has no components and a current position of -1. any get_boxed_value() raises(InvalidValue); The get_boxed_value operation returns the boxed value as an any. If the DynBoxedValue represents a null valuetype, the operation raises InvalidValue. void set_boxed_value(in any boxed) raises(TypeMismatch); The set_boxed_value replaces the boxed value with the specified value. If the DynBoxedValue represents a null valuetype, it is converted to a non-null value. The get_boxed_value_as_dyn_any and set_boxed_value_as_dyn_any have the same semantics as their any counterparts, but accept and return values of type DynAny instead of any.
Actions taken:
December 17, 1999: received issue
October 6, 2000: closed issue

Issue 3159: null & void TCs and DynAny (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The DynAny chapter says nothing about whether
DynAnyFactory::create_dyn_any_from_type_code is supposed to correctly
handle a TypeCode argument that has a TCKind of either tk_null or tk_void.

I assume these are valid argument TypeCodes that do not result in an
InconsistentTypeCode exception, and the returned DynAny is simply one that
fulfills the basic DynAny interface and has no components. However, it
would be nice to explicitly document the cases for these two TypeCodes,
though, given that they're a little different from other TypeCodes in that
they can't have any associated values.

Resolution: Clarify with additional text as shown below
Revised Text: With reference to ptc/99-12-07 Insert the following paragraph at the bottom of page 9-9, immediately following the new paragraph added by Core RTF 2k: "Creation of DynAnys with TCKind tk_null and tk_void is legal and results in the creation of a DynAny without a value and with zero components."
Actions taken:
December 21, 1999: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3172: Bug in 11.3.7.6 (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

on page 11-30, we have:

	RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY

	This combination represents the situation where the POA does no
	automatic object activation (that is, the POA searches only the
	Active Object Map). The server must activate all objects served
	by the POA explicitly, using either the activate_object or
	activate_object_with_id operation.

The final sentence is wrong. Implicit activation is controlled by the
ImplicitActivation policy.

Resolution: Remove the incorrect sentence
Revised Text: Remove the last sentence in the "RETAIN and USE_ACTIVE_OBJECT_MAP_ONLY" subsection on page 11-30, which reads: "The server must activate all objects served by the POA explicitly, using either the activate_object or activate_object_with_id operation."
Actions taken:
January 2, 2000: receive dissue
October 6, 2000: Incorporate change and close issue.

Issue 3173: IDL scoping rules (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

on page 3-48, we have:

	On the other hand, if module Inner2 were:

	module Inner2 {
		typedef Inner1::S1 S2;	// Inner1 introduced
		typedef string inner1;	// Error
		typedef string S1;	// OK
	};

	The definition of inner1 is now an error because the identifier
	Inner1 referring to the module Inner1 has been introduced in the
	scope of module Inner2 in the first line of the module declaration.
	Also, the declaration of S1 in the last line is OK since the
	identifier S1 was not introduced into the scope by the use of
	Inner1::S1 in the first line.

This is fine, but it doesn't make it clear that, if the name is qualified,
it is *not* introduced into the scope.

Resolution: Additional clarifying words are needed as shown below.
Revised Text: Append the following sentences to the paragraph that immediately follows the module Inner2 example on page 3-54: "Only the first identifier in a qualified name is introduced into the current scope. This is illustrated by Inner1::S1 in the example above, which introduces "Inner1" into the scope of "Inner2" but does not introduce "S1". A qualified name of the form "::X::Y::Z" does not cause "X" to be introduced, but a qualified name of the form "X::Y::Z" does."
Actions taken:
January 2, 2000: receive dissue
October 6, 2000: Incorporate changes and close issue.

Issue 3174: servant_to_id (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

the following text in the spec could be made a bit clearer:

	2. If the POA has the IMPLICIT_ACTIVATION policy and either the
	   POA has the MULTIPLE_ID policy or the specified servant is not
	   active, the servant is activated using a POA-generated Object Id
	   and the Interface Id associated with the servant, and that Object
	   Id is returned.

Although it is stated elsewhere that IMPLICIT_ACTIVATION requires SYSTEM_ID,
it wouldn't hurt to reflect this here too:

	2. If the POA has the IMPLICIT_ACTIVATION policy and either the
	   POA has the MULTIPLE_ID policy or the specified servant is not
	   active and the POA has the SYSTEM_ID policy, the servant is
		  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	   activated using a POA-generated Object Id
	   and the Interface Id associated with the servant, and that Object
	   Id is returned.

Another question:

	What should be returned if the USER_ID policy is present?

The spec doesn't say. Given that we can't add a new user exception,
OBJ_ADAPTER seems appropriate.

Resolution: Close with no change, since a POA cannot have IMPLICIT_ACTIVATION and USER_ID.
Revised Text:
Actions taken:
January 4, 2000: received issue
October 6, 2000: Close no change.

Issue 3177: local interfaces and the DII (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The current spec for local interfaces disallows making calls to a local
interface via the DII. It turns out that this is rather inconvenient
for implementors of scripting languages. That's because, for a scripting
language, *everything* is a DII request. Local interfaces, therefore, force
the implementor to wrap all pseudo-objects and local interfaces in
special wrapper objects.

For pseudo-objects, there is nothing we can do. However, for local
interfaces, we could require DII calls to be supported.

Resolution: resolved, see above
Revised Text:
Actions taken:
January 5, 2000: received issue
January 5, 2000: moved from core rtf to components ftf
May 19, 2001: moved from components ftf back to core
May 13, 2002: closed issue

Discussion:

Since local interfaces are allowed to take native values for parameters, which 
you cannot pass via DII. So we'll have to limit DII usage on local inter- 
faces anyway (e.g. you could not call activate_object on the POA).

Issue 3181: special-casing TypeCode is unnecessary (orb_revision)

Click here for this issue's archive.
Source: Progress Software (Mr. Steve Vinoski, steve.vinoski(at)iona.com)
Nature: Uncategorized Issue
Severity:
Summary:

The resolution to issue 3048 special-cases TypeCode in a manner that
essentially makes it a keyword. First of all, given that TypeCode lives in
the CORBA module, and thus is properly named CORBA::TypeCode, this is
highly irregular because it means we have a scoped keyword. Second, this
change also significantly breaks working products -- it adopts
implementation details of certain compilers and rules out already-working
implementation approaches of other existing compilers. The OMG is not
supposed to dictate implementation. Finally, the rationale for the changes
made for 3048 centered around unquantifiable performance issues that IMO
affect only a very small minority of applications.

Resolution: Incorporate changes and close issue.
Revised Text: n Section 3.14, page 3-51 orbrev/00-09-01, replace the following paragraph: "The file orb.idl contains the IDL definitions for the CORBA module. Except for CORBA::TypeCode, the file orb.idl must be included in IDL files that use names defined in the CORBA module. CORBA::TypeCode can be used in IDL files without having to include orb.idl." by: " The file orb.idl contains the IDL definitions for the CORBA module. Except for CORBA::TypeCode, the file orb.idl must be included in IDL files that use names defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its definition by including either the file orb.idl or the file TypeCode.idl. The exact contents of TypeCode.idl are implementation dependent. One possible implementation of TypeCode.idl may be: // PIDL #ifndef _TYPECODE_IDL_ #define _TYPECODE_IDL_ #pragma prefix "omg.org" module CORBA { interface TypeCode; }; #endif // _TYPECODE_IDL_ For IDL compilers that implicitly define CORBA::TypeCode, TypeCode.idl could consist entirely of a comment as shown below: // PIDL // CORBA::TypeCode implicitly built into the IDL compiler // Hence there are no declarations in this file Because the compiler implicitly contains the required declaration, this file meets the requirement for compliance. "
Actions taken:
January 6, 2000: received issue
February 27, 2001: closed issue

Discussion:

This issue requests reversal of an action taken in a previous RTF which was supported by an overwhelming majority. Such a step
would be justified if new facts have come to light to justify such a reversal. Implementors have had considerable time to gain
experience with the change that was put in place. So the first question to vote on was: 

Have any new facts come to light as a result of experience gained since the change was made to justify considering reversal of
the resolution for issue 3048 that was adopted with iverwhelming majority?. 

Since YES prevailed it is further decided that the previous change in 3048 resolution went too far causing invalidation of perfectly
legitimate implementations of IDL compilers which actually gets the definition of TypeCode from its IDL declaration instead of
implicitly defining it within the compiler. In order to make both kinds of compilers admissible as compliant, the changes shown
below are proposed. 

These changes allow compilers that depend on the declaration of TypeCode in IDL file to  deliver said definition in the
TypeCode.idl file and #include that file at an appropriate place in the orb.idl file, or use any other combination that works. 

Additionally, compilers that implicitly define TypeCode in the compiler can deliver in effect an empty TypeCode.idl file, and
comply with this change. 

Users of any IDL compiler that need the definition of TypeCode are expected to either #include TypeCode.idl or #include orb.idl.

Issue 3185: Efficient construction of Any types w/o DynamicAny (orb_revision)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 The current C++ mapping does not offer efficient insertion or
extraction of data from CORBA::Any if static type information
(IDL-generated insertion and extraction operators) are not
available.

 I'm thinking of a dynamic DII gateway that needs to shovel large
amounts of data, such as a sequence<octet>. Presently, the gateway
must employ the DynAny type, and loop over the number of elements,
calling insert_octet() or get_octet() repeatedly. This is inefficient,
especially for large sequences/arrays of basic types.

 I think that a more efficient mechanism might be useful for some
applications.

Resolution: Incorporate changes and close issue
Revised Text: 1) Add the following operations to the DynamicAny::DynAny interface: module DynamicAny { ... interface DynAny { ... void insert_boolean_seq(in CORBA::BooleanSeq value) raises(TypeMismatch, InvalidValue); void insert_octet_seq(in CORBA::OctetSeq value) raises(TypeMismatch, InvalidValue); void insert_char_seq(in CORBA::CharSeq value) raises(TypeMismatch, InvalidValue); void insert_short_seq(in CORBA::ShortSeq value) raises(TypeMismatch, InvalidValue); void insert_ushort_seq(in CORBA::UShortSeq value) raises(TypeMismatch, InvalidValue); void insert_long_seq(in CORBA::LongSeq value) raises(TypeMismatch, InvalidValue); void insert_ulong_seq(in CORBA::ULongSeq value) raises(TypeMismatch, InvalidValue); void insert_float_seq(in CORBA::FloatSeq value) raises(TypeMismatch, InvalidValue); void insert_double_seq(in CORBA::DoubleSeq value) raises(TypeMismatch, InvalidValue); void insert_longlong_seq(in CORBA::LongLongSeq value) raises(TypeMismatch, InvalidValue); void insert_ulonglong_seq(in CORBA::ULongLongongSeq value) raises(TypeMismatch, InvalidValue); void insert_longdouble_seq(in CORBA::LongDoubleSeq value) raises(TypeMismatch, InvalidValue); void insert_wchar_seq(in CORBA::WCharSeq value) raises(TypeMismatch, InvalidValue); CORBA::BooleanSeq get_boolean_seq() raises(TypeMismatch, InvalidValue); CORBA::OctetSeq get_octet_seq() raises(TypeMismatch, InvalidValue); CORBA::CharSeq get_char_seq() raises(TypeMismatch, InvalidValue); CORBA::ShortSeq get_short_seq() raises(TypeMismatch, InvalidValue); CORBA::UShortSeq get_ushort_seq() raises(TypeMismatch, InvalidValue); CORBA::LongSeq get_long_seq() raises(TypeMismatch, InvalidValue); CORBA::ULongSeq get_ulong_seq() raises(TypeMismatch, InvalidValue); CORBA::FloatSeq get_float_seq() raises(TypeMismatch, InvalidValue); CORBA::DoubleSeq get_double_seq() raises(TypeMismatch, InvalidValue); CORBA::LongLongSeq get_longlong_seq() raises(TypeMismatch, InvalidValue); CORBA::ULongLongongSeq get_ulonglong_seq() raises(TypeMismatch, InvalidValue); CORBA::LongDoubleSeq get_longdouble_seq() raises(TypeMismatch, InvalidValue); CORBA::WCharSeq get_wchar_seq() raises(TypeMismatch, InvalidValue); ... }; ... }; 2) Add the following text to the end of section 9.2.3.8: In the same way that basic types are inserted/extracted from a DynAny object, arrays or sequences of basic types can be inserted/extracted from a DynAny. For example, the get_boolean_seq operation extracts a sequence of booleans from a DynAny that contains either a sequence or an array of booleans, and the insert_boolean_seq operation stores the sequence back into the DynAny. The TypeCode of the DynAny, or the TypeCode of the component at the current position of the DynAny, must be equivalent to a sequence or array TypeCode with the basic type as its element, otherwise the operations raise TypeMismatch. For the insert operations, if the length of the sequence is incompatible with a bounded sequence or array represented by the DynAny, then the operations raise InvalidValue.
Actions taken:
January 7, 2000: received issue
January 7, 2000: moved from C++ to Core RTF
February 27, 2001: closed issue

Discussion:

New operations cribbed from the DataInputStream & 
DataOutputStream interfaces for custom valuetypes are added 
to facilitate this.  I only added inserters and extractors for types that 
map to a fixed memory size, since they are the only ones that I anticipate 
a good performance gain.

Issue 3194: Ordering issues in the DII (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The following are currently undefined in the spec:

	- What happens if poll_response or get_response is called
	  before send_deferred?

	- What happens if get_response is called after invoke?

	- What if get_response is called more than once?

	  [ Interestingly, the resolution to issue 2341 resolved something,
	    but it wasn't issue 2341 ;-)  That's because the resolution
	    doesn't say that calling get_response twise is illegal. ]

	- Is it legal to call poll_response more than once?

I think that, for the first three, we should raise BAD_INV_ORDER. We
also need minor codes for those.

For case four, I'd suggest that calling poll_response multiple times is OK,
but that calling it once get_response was called should raise BAD_INV_ORDER.

Resolution: Fix as described above.
Revised Text: Section and page numbers are based on 2.3.1. Symbolic names for standard minor codes will need to be replaced with manifest constants for table 3-13 on page 3-58 as follows (all entries are to be made in the BAD_INV_ORDER section): REUSE Attempt to send a DII request after it was sent previously. NO_INIT Attempt to poll a DII request or to retrieve its result before the request was sent. FINAL Attempt to poll a DII request or to retrieve its result after the result was retrieved previously. SYNC Attempt to poll a synchronous DII request or to retrieve results from a synchronous DII request. Change the final para of 7.2.3, last sentence to read: Calling invoke on a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. Add the following text at the end of section 7.3.1: Calling send on a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. Add the following text at the end of section 7.3.2: Calling send_multiple_requests for a request after invoke, send, or send_multiple_requests for that request was called raises BAD_INV_ORDER with standard minor code REUSE. If send_multiple_requests raises BAD_INV_ORDER, the actual number of requests that were sent is implementation dependent. Add the following text at the end of section 7.3.3: Calling poll_response before send or send_multiple_requests for that request raises BAD_INV_ORDER with standard minor code NO_INIT. Calling poll_response after calling invoke raises BAD_INV_ORDER with standard minor code SYNC. Calling poll_response after calling get_response raises BAD_INV_ORDER with standard minor code FINAL. Calling poll_response after that request was returned by get_next_response raises BAD_INV_ORDER with standard minor code FINAL. Add the following text at the end of section 7.3.4: Calling get_response before send or send_multiple_requests for that request raises BAD_INV_ORDER with standard minor code NO_INIT. Calling get_response after calling invoke raises BAD_INV_ORDER with standard minor code SYNC. Calling get_response after calling get_response raises BAD_INV_ORDER with standard minor code FINAL. Calling get_response after that request was returned by get_next_response raises BAD_INV_ORDER with standard minor code FINAL. Add the following text at the end of section 7.3.5: Calling get_next_response or poll_next_response at a time when no requests are outstanding raises BAD_INV_ORDER with standard minor code NO_INIT. If concurrent calls to get_next_response or poll_next_response are in progress, the exact outcome is implementation dependent; however, get_next_response is guaranteed not to return the same completed request to more than one caller.
Actions taken:
January 11, 2000: received issue
October 6, 2000: Incorporate changes and close issue.

Issue 3196: poll_response() (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

there really is a different issue here. On page 7-5:

	boolean poll_response();

On page 7-9:

	boolean poll_response ( in Request req);

Resolution: Already fixed editorially in draft.
Revised Text:
Actions taken:
January 11, 2000: received issue
October 6, 2000: closed issue, no change

Issue 3203: Inheritence table 3-10 wrong? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

There appears to be a minor glitch in table 3-10.  It states that
stateful valuetypes can only support one non-abstract interface, but it
is not clear what is correct for abstract valuetypes or abstract
interfaces, since it uses the words "supports", not "supports single" or
"multiple" which are used elsewhere.  It certainly does not appear
reasonable for abstract valuetypes to be able to inherit from more than
one non-abstract interface when stateful valuetypes cannot.

This brings up a question: Can abstract valuetypes support non-abstract
interfaces?  It's not clear to me what the answer to this ought to be.

Anyway, it appears to me that part of the table should look like this
instead:

May inherit from:	| Interface		| Abstract Interface
---------------------------------------------------------------------------
Abstract		| *no or supports single| multiple
Value			|
---------------------------------------------------------------------------
Stateful		| supports single	| multiple
Value			|			|
---------------------------------------------------------------------------

* depending on the answer to the question above

Resolution: The table needs to be changed to clarify as shown below
Revised Text: May inherit from: | Interface | Abstract Interface --------------------------------------------------------------------------- Abstract | supports single | supports multiple Value | --------------------------------------------------------------------------- Stateful | supports single | supports multiple Value | | ---------------------------------------------------------------------------
Actions taken:
January 10, 2000: received issue
October 6, 2000: Incorporate changes and close issue

Issue 3205: Semantics for DynAny::equal underspecified (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3.1, 9.2.3.5 says:  "Two DynAny values are equal if their
TypeCodes are equivalent and, recursively, all component DynAnys have
equal values."

We already added text in the Y2K RTF to clarify equal for object
references & typecodes, but this leaves an exercise for the reader to
figure out what equal means for some IDL types, particularly fixed,
sequences & valuetypes.  I believe that an experienced person thinking
about it can come up with the correct rules, but why leave it up to
mistaken interpretation.

Resolution: Resolve as suggested
Revised Text: Ok, now for the specific proposal for issue 3205: 1. Change the IDL for DynAnyFactory interface to: module DynamicAny { ... exception MustTruncate { }; ... interface DynAnyFactory { exception InconsistentTypeCode {}; DynAny create_dyn_any(in any value) raises(InconsistentTypeCode); DynAny create_dyn_any_from_type_code(in CORBA::TypeCode type) raises(InconsistentTypeCode); DynAny create_dyn_any_without_truncation(in any value) raises(InconsistentTypeCode, MustTruncate); DynAnySeq create_multiple_dyn_anys(in AnySeq values, in Boolean allow_truncate) raises(InconsistentTypeCode, MustTruncate); AnySeq create_multiple_anys(in DynAnySeq values); }; }; 2. Add the following text to section 9.2.2 to describe the new DynAnyFactory operations: The create_dyn_any_without_truncation operation has the same semantics as create_dyn_any, but will raise the MustTrucate exception if it cannot avoid truncating a valuetype. The create_multiple_dyn_anys operation converts a sequence of anys into a sequence of DynAnys, ensuring that each reference to a valuetype instance is converted consistently to the same DynValue or DynValueBox instance. If the allow_truncate parameter is false, the operation will raise the MustTruncate exception if it cannot avoid truncating a valuetype. The create_multiple_anys operation converts a sequence of DynAnys into a sequence of anys, ensuring that each DynValue or DynValueBox instance is consistently converted to the same valuetype instance. 3. Change the the last paragraph of 9.2.3.5 to: The equal operation compares two DynAny references for equality and returns true if the DynAnys are equal, false otherwise. For DynAny references that are not derived from DynValueCommon, they are equal if their TypeCodes are equivalent and, recursively, all component DynAnys are equal. For DynAny references that are derived from DynValueCommon, they are equal only if they are exactly the same reference. The current position of the two DynAnys being compared has no effect on the result of equal. To determine equality of object references, the equal operation uses Object::is_equivalent. To determine equality of type codes, the equal operation uses TypeCode::equivalent. 4. Add the following text to the end of section 9.2.10: A reference to a DynValueCommon interface (and interfaces derived from it) exhibit the same sharing semantics as the underlying valuetype that it represents. This means that the relationships between valuetypes in a graph of valuetypes will remain unchanged when converted into DynAny form and vice versa. This is necessary to ensure that applications that use the DII and DSI can correctly view and preserve the semantics of the valuetype graph.
Actions taken:
January 10, 2000: received issue
May 13, 2002: closed issue

Discussion:

As briefly as possible, here is a description of the problems that 
valuetypes and the DynAny interfaces have in the Corba 2.4.2 
specification right now: 

#1.  There is confusion over what a DynValue represents:  is it a 
reflective interface to a real underlying valuetype instance, or is it 
a separate thing that represents a valuetype and is converted to/from 
a real valuetype via DynAny::to_any()/from_any()? 

#2.  The semantics of DynAny::equal() when applied to DynValues is 
underspecified:  is it reference equality or contents equality? 

#3.  The DynAny/DynValue interface is lacking expressiveness to properly 
implement a DII/DSI application that can properly inspect/copy/construct 
a valuetype graph that appears in more than one argument of an 
invocation.  This also breaks the ability to write a generic bridge 
that can handle valuetypes. 

#4.  The interaction between valuetype truncation and conversion to a 
DynValue is underspecified. 

My first suggested solution to the problem was to declare that 
DynValue is actually a reflective interface that provides access 
directly to the members of an underlying real valuetype instance. 
This generated some pretty strong objections from a couple of RTF 
members and that stalled the discussion about a year ago. 

After quite a while to reflect on this, I've got another approach that 
avoids this problem.  However, it does have some implications that I 
want to air before working up a final proposal. 

The basic idea is to treat DynValue (and DynValueBox) as a proxy for a 
real valuetype with the same identity semantics.  This means that if I 
convert a graph of valuetypes into its representation as a collection 
of DynAny objects, each valuetype will be represented by a single 
DynValue instance, no matter where it appears in the graph. 

Along with this, we need operations added to DynAnyFactory to batch 
convert multiple anys to DynAnys and vice versa.  This batch 
conversion process will map the same valuetype instance to the same 
DynValue instance. 

As for truncation & DynValue, since the CCM spec has put a stake in 
the ground that a valuetype that remains in an Any should be able to 
be retransmitted by a server that does not know the specific type of 
that valuetype, it's clear to me that a mode of conversion to DynAny 
that avoids truncation is necessary, since otherwise we break DII/DSI 
and bridges again.  The DynAnyFactory might use the 
SendingContextRunTime service context or the IFR directly to lookup 
the complete TypeCode of the truncatable valuetype.  Also, the 
DynAnyFactory needs a new exception to indicate that it could not find 
the TypeCode of a truncatable valuetype. 

I think this solves the four problems listed above as follows: 

#1.  DynValue stands as a proxy for a valuetype instance that will be 
constructed when the DynValue is converted into a real valuetype 
embedded in an any.  It is not a reflective interface to a real 
valuetype instance with all of the baggage that entails. 

#2.  DynAny::equal for valuetypes should be defined as reference 
equality in order to get the same comparison semantics that we 
already have for valuetypes. 

#3.  The batch conversion operations on DynAnyFactory allow a DII/DSI 
to preserve the relationships between valuetypes when they are 
converted to DynValues and vice versa. 

#4.  When a truncatable valuetype is converted to a DynValue, the 
application can indicate that the valuetype not be truncated.  This 
allows generic DII/DSI applications to manipulate truncatable 
valuetypes correctly as long as the application can find the correct 
TypeCode for the valuetype.

Issue 3219: attributes and system exceptions (orb_revision)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

The components spec permits attributes to raise user exceptions, to
bring them in line with operations. That's a really nice idea, but
raises yet another versioning problem. In particular, no new IDL that
uses an attribute with a raises clause can be compiled by an older IDL
compiler. (Simply deleting the raises clause and then compiling with
an older compiler is risky at best -- marshaling code won't in general
expect to get a user exception in reply to accessing an attribute...)

Resolution: withdrawn by submitter
Revised Text:
Actions taken:
January 18, 2000: received issue
February 3, 2000: closed issue

Issue 3220: Does a value in a valuebox make sense? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

Although legal in the CORBA 2.3 IDL grammar, creating a valuebox of
another valuebox or valuetype is of dubious use.  I can't see why having
an extra level of indirection here would ever be useful.  None of the
language mappings that have defined mappings for valuebox (C++, Java,
Ada) address this issue either.

Does it make sense to disallow valueboxing valueboxes or valuetypes?

Resolution: Incorporate changes and close issue.
Revised Text: In section 3.8.2 insert the following right before the paragraph that starts "The declaration of a boxed value type...": "Any IDL type may be used to declare a value box except for a valuetype."
Actions taken:
January 15, 2000: received issue
October 6, 2000: Incorporate changes and close issue.

Discussion:

It makes sense to disallow valueboxing of valuetypes. This was 
apparently the sense of the original OBV RTF, but it never got reflected in 
any text in the spec

Issue 3221: International Strings in Encapsulations (orb_revision)

Click here for this issue's archive.
Source: Fujitsu (Mr. Tom Rutt, tom(at)coastin.com)
Nature: Uncategorized Issue
Severity:
Summary:

It seems that the only time an international string will ever appear in an
encapsulation
would be a private IOR component.  

If we can keep the issue down to International strings in encapsulations
this will
simplify the solution.   

If anyone has an example of how any other GIOP header string could carry an
international
string please come forth with it quickly.

The use of international strings in GIOP 1.1 and 1.2 is dependant on the
asserted use
of service context code set negotiation. In particular:
	1) if the negotiatiation is not initiated, then strings are passed
as latin-1 only and wstrings are not allowed to be passed as parameters.
	2) If the negotiation is initated and successfully completed, the
agreed codesets are used
respectively for string and wstring
	3) If negotiation is initated by no comon codeset is agreed, then
UTF-8 is the default for
string and UTF-16 is the default for Wstring (note: the current codeset
negotiation does not
discuss the big endian or litte endian aspects of UTF-16).

There is also text somewhere in GIOP stating that Encapsulations in IORs
should be
encoded in giop 1.0 for maximum interoperability.

It just occured to me that disallowing international strings in IOR
encapsulations (i.e., private
IOR components) is equivalent to assuming that negotiation is not initiated
for encapsulations.
This seems to be a consistent set of semantics.

The only problem with this interpretation, is that it does not allow
international strings
in IOR encapsulations.

Resolution: closed in interop/2000-05-01
Revised Text:
Actions taken:
January 17, 2000: received issue
March 7, 2002: moved to Core RTF

Issue 3250: Null valuetypes not supported by DynValue (orb_revision)

Click here for this issue's archive.
Source: IONA (Mr. Mark Spruiell, )
Nature: Uncategorized Issue
Severity:
Summary:

DynValue is missing support for null valuetypes. There is no
way to determine whether a DynValue represents a null valuetype,
nor is there any way to dynamically construct an Any containing
a null valuetype.

Proposed resolution:

Add the following operations to the DynValue interface:

     boolean is_null();
     void set_to_null();
     void set_to_value();

And replace the description of the interface with the following text:

The DynValue interface can represent both null and non-null
valuetypes. For a DynValue representing a non-null valuetype, the
DynValue's components comprise the public and private members of
the valuetype, including those inherited from concrete base valuetypes,
in the order of definition. A DynValue representing a null valuetype
has no components and a current position of -1.

     boolean is_null();

The is_null operation returns TRUE if the DynValue represents
a null valuetype.

     void set_to_null();

The set_to_null operation changes the representation of a DynValue
to a null valuetype. Specifically, the current components of the DynValue
are destroyed, component_count returns zero and the current position is
set to -1.

     void set_to_value();

The set_to_value operation changes the representation of a DynValue
to a non-null valuetype. The state of the DynValue is initialized
exactly as if create_dyn_any_from_type_code had been invoked.
The set_to_value operation has no effect when invoked on a DynValue
representing a non-null valuetype.

The remaining operations of the DynValue interface have equivalent
semantics to DynStruct. When invoked on a DynValue representing a
null valuetype, get_members and get_members_as_dyn_any return an empty
sequence.

Resolution: Merge with 3135 and provide resolution as part of 3135
Revised Text:
Actions taken:
January 25, 2000: received issue
October 6, 2000: Merged with 3135 and closed

Issue 3258: Can native be used in constructed IDL types? (orb_revision)

Click here for this issue's archive.
Source: Floorboard Software (Mr. Jonathan Biggar, jon(at)floorboard.com)
Nature: Uncategorized Issue
Severity:
Summary:

CORBA 2.3.1, section 3.10.5 says:

"A native type may be used to define operation parameters and results.
However, there is no requirement that values of the type be permitted in
remote invocations, either directly or as a component of a constructed
type."

This is ambiguous as to whether a native type may be used in a
constructed IDL type that is intended to be used only locally:

// IDL

native MyNative;

struct MyStruct {
    MyNative	a_native;
};

So, should the first sentence in 3.10.5 be read to mean that native may
ONLY be used in parameters & results?  If so, we ought to put the word
"only" in there.

Resolution: Incorporate changes and close issue.
Revised Text: This is done by changing the two sentences in CORBA 2.3.1 section 3.10.5 that says: "A native type may be used to define operation parameters and results. However, there is no requirement that values of the type be permitted in remote invocations, either directly or as a component of a constructed type." to read: "A native type may be used only to define operation parameters and results. Native type parameters are permitted only in operations of local interfaces or valuetypes."
Actions taken:
January 26, 2000: received issue
February 27, 2001: closed issue

Discussion:

While the second sentence in the quoted text from 2.3.1 section 3.10.5 
alludes to using natives in constructed types, trying to generalize its 
use in general structs etc adds considerable complexity to marshaling 
time checking etc. So native should not be allowed anywhere else o