Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

Summary: The IDL for internalizing roles could be optimized to reduce the size of the externalized data as well as simplifying the implementation

Deferred

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

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

No Data Available

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

No Data Available

Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name()

Duplicate of issue 665

Summary: The question is: What is the exact marshalling for an encapsulation
of a zero length sequence? (Service context is an encapsulation of a
sequence. CORBA 2.1, Section 10.6.7, page 10-22.)
While it may or may not be an ambiguity,
it does appear that ORB vendors differ in their interpretations, so
it might be important to clarify it.

closed, no revision required

Summary: Its not clear to me how octet indices used for alignment and for
TypeCode indirection offsets are calculated in the presence of
fragmentation. Different interpretations will prevent successful
interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

closed with revision

Summary: There are 2 changes:
1. add the request id to message fragments so that fragmentation is usable.
2. change the alignment rules so that message headers may be changed
without having to remarshal the body.
[ as an aside we"d really like to remove all the alignment rules so that
any"s no longer have to be double marshaled, but we don"t think its
possible to deal with all the details quickly ]
3. Add some more addressing information to request, locate_request,etc.

No Data Available

Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
A number of the PIDL classes include a member function _duplicate.
It should be declared as a static member function
with an argument; i.e. the pointer to be "duplicated".

No Data Available

Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

Fixed in CORBA 2.2 editing process

Summary: Add an additional enumeration to the ReplyStatusType (and
LocationStatusType) called LOCATION_FORWARD_PERM (and
OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
OBJECT_FORWARD), but can be used as a hint by the client that it should
permanently discard the original IOR and replace it with the new IOR.

No Data Available

Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement
that an eight byte alignment occur before the body of any message.
This allows for numerous optimizations that currently cannot be performed
because the alignment of the beginning of the bodies is not consistent.

No Data Available

Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

close with no change: The scale information is in the IDL definition of the fixed-point type

Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is
supposed to be compatible with the type ProfileBody of earlier
versions of CORBA. Unfortunately, it has a different repository
ID, leading to incompatibilities.
Proposed change: Add two pragmas to section 12.7.2, inside
the module IIOP

No Data Available

Summary: Add a rule to CDR that allows an empty string to be marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.
For a structure with five simple data members, this reduces the size of the
TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

No Data Available

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.

No Data Available

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

No Data Available

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

Close noting that this has been explained in Revised Chapter 3.

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

Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i

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.

See resolution of 999 , close issue

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!

incorporate the proposed clarification

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.

Sugested text below , close issue

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

Proposed resolution: Change Appendix B to correspond to the

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.

Replace section B.2.3 with corresponding text from the ISO Trader standard

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?

Incorporate change in 2.3 and close issue

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.

close issue, resolved

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

Fixed with sepcific example in section 10.6.5.2 in Rev 2.3

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?

This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit

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

Clarify as follows

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.

See resolution of issue 999 , close issue

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

Incorporate changes in 2.3a and close issue.

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?

resolved, issue closed

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

Remove the second sentence in section 8.5.10 of Rev 2.2

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?

No Data Available

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

No Data Available

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

Add an Up-Call Arrow to the Dynamic skeleton box.

Summary: IDL should permit enum and octet constants.

The following changes add enum and octet constants to IDL:

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

Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character

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

incorporate changes in 2.3 and close this issue and 1066.

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

close issue with no change with the above explanation.

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.

close no change in 2.4