here's a thing that has been bugging me for a while: the description of the
semantics of the iterators in some of the CORBA Services seems to be unclear
and inconsistent. They falls into two categories:

Semantics A: returned value is relevant for the next invocation

PropertyService says:

The next_one() operation returns TRUE if an item exists at the current
position in the iterator ... A return of FALSE signifies no more items in
the iterator.

Interoperable Naming Service says:

The next_one() operation returns the next binding. It returns TRUE if it is
returning a binding, FALSE if there are no more bindings to retrieve. If
next_one() returns FALSE, the returned Binding is indeterminate.

(the intention behind this is actually different, see below, as Michi
Henning pointed out to me)

The Trader Service (e.g. OfferIdIterator) says:

The next_n() operations returns TRUE if there are further offer identifiers
to be extracted from the iterator. It returns FALSE if there are no
further offer identifiers to be extracted.

(this is also clear, even though I don't think this is the rigth design).

Semantics B: returned value is relevant for the past invocation:

The Collection Service:

retrieve_element_set_to_next() returns TRUE if an element has been
retrieved.

(This is really clear)

In case A, a client always has to check whether s/he got something useful in
the out parameter (since a FALSE return only says something about the
subsequent call); this is not very elegant. In case B, a client always has to
spend a fruitles round-trip to the server to know when the iteration is
finished. This is IMO a better solution, and should preferably be adhered to
by any OMG standard.

Summary: The idl spec for the CollectionFactories interface in Chapter 17 of Corba Common Object Services document and the spec for the same interface in The CORBAservices OMG IDLText File(last updated Feb, 1998) do not match. The doocument (17-73) describes a method

Summary: A number of interface changes suggested for the Collection specification.

Summary: What should be done for remove/replace/retrieve_element_set_to_next if the element cannot be deleted/replaced/retrieved?

Summary: In the description of the first parameter "collection_interface" of type Istring, ther starting quote of the word collection_interfaceis missing.

editorial

Summary: There are three comments in the interface description that do not have the same style (font) as the other comments

editorial

Summary: After ElementInvalid and KeyInvalid, you discuss ParameterInvalid. There is a space written in it: Paramete_rInvalid

editoral

Summary: Calls for removing and retrieving the first and last element can throw an EmptyCollection exception. Why can"t the calls remove_elements_at_position and retrieve_element_at_position throw such an exception?

Summary: Positions are numbered. When I remove 1 element, what happens with the indices?Do the portions of the indices of the elements located after the removed element decrement one?

Summary: If a invocation of do_on on a certain element returns false, does the iteration have to stop, leaving some of the objects undone?Or do I continue until the end and then return false?

Summary: The side effects states that iterators that point to removed elements go in-between, and others keep theit state. If all elements are removed I doubt that some iterators can keep their state. I would set all iterators the invalid state...comments?

Summary: Page 17-23:"If the collection supports unique elements or keys...". If I already have a different element with the same key, do I return and add false?

Summary: There is a confusing/conflicting situation in 2 parts of the document. Page 17-12 Map/SortedMap states that you can insert an object with 2 different keys (nicknames). The first note on page 17-122 states that if both key and element equality are defined, element and equality must imply key equality.

Summary: Same case for RACollectionFactories) on page 17-74, 17-75 as in issue 763

Summary: The operation "create (ParameterList parameters) raises (ParameterInvalid)" is not mentioned in the CollectionFactories interface, while it is fully explained on page 17-73

Summary: Page 17-89, description of the retrieve_element_set_to_next operation in the Iterator interface: The signature of this operation is missing the second parameter "more".