Issues for which there is not a valid OMG list (because of typos, or issues for which there is no RTF in existence).

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

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

Jira Issues

Issue 62: Failure behavior for iterator operations Jira Issue COLL-13
Issue 63: Suggested changes to Collection spec. Jira Issue COLL-14
Issue 489: PropertySetFactory Jira Issue PROP-1
Issue 490: allowed_properties and allowed_properties_defs constraints Jira Issue PROP-2
Issue 491: What does "Def" in PropertySetDef stand for? Jira Issue PROP-3
Issue 492: Properties are typed, named values associated with an object Jira Issue PROP-4
Issue 493: Why doesn"t the trader use the property service? Jira Issue TRADE-13
Issue 546: Trader Type repository breaks polymorphism Jira Issue TRADE-1
Issue 547: list_types needs iterator Jira Issue TRADE-2
Issue 548: Interface names insufficiently constrained Jira Issue TRADE-3
Issue 549: Type eqivalence problems in trader Jira Issue TRADE-4
Issue 550: Sequence valued trader properties Jira Issue TRADE-5
Issue 558: OfferIdIterator::next_n return value Jira Issue TRADE-12
Issue 559: Trader spec forces read-ahead Jira Issue TRADE-6
Issue 560: OfferIdIterator Problem Jira Issue TRADE-7
Issue 561: list_offers() description incorrect Jira Issue TRADE-8
Issue 562: list_offers is under-specified Jira Issue TRADE-9
Issue 755: Error in CosCollection information Jira Issue COLL-1
Issue 763: CORBAservices (editorial page 17-71 to 17-73) Jira Issue COLL-2
Issue 764: CORBAservices (editorial page 17-74, 17-75) Jira Issue COLL-3
Issue 765: Map/SortedMap Jira Issue COLL-4
Issue 766: Collection.add_element Jira Issue COLL-5
Issue 767: page 17-23: Collection.remove_all Jira Issue COLL-6
Issue 768: Page 17-26: Collection.all_elements_do Jira Issue COLL-7
Issue 769: Page 17-29: OrderedCollection.remove_element_at_position Jira Issue COLL-8
Issue 770: Interface OrderedCollection Jira Issue COLL-9
Issue 1322: IDL does not match Jira Issue COLL-15
Issue 3271: semantics of boolean iterator.next(out thing) ... Jira Issue COLL-16
Issue 4225: Trader issue (Section 2.2.1.1) on page 44 Jira Issue TRADE-10
Issue 4336: Hole in trader constraint language Jira Issue TRADE-11
Issue 18584: The OMG�s address on page viii is obsolete Jira Issue ZZCVL-26
Issue 18585: Scope section: A more nuanced description would be better. Jira Issue ZZCVL-27

Issue 62: Failure behavior for iterator operations (zz-collection)

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

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

Summary: PropertySetFactory interface has method create_constrained_propertyset. Why doesn"t PropertySet interface have methods get_allowed_property_types and get_allowed_properties 

Summary: It seems to serve no purpose other than a boolean to determine if a property has been defined. Constraining property_types or property_modes make sense but not properties and property_defs 

Summary: What does "Def" in PropertySetDef stand for? 

Summary: One could create an association between a PropertySet and an object, but I don"t see any reason why I must. What am I missing??? 

Summary: Why doesn"t the trader use the property service? 

Summary: The semantics of mandatory and read-only modifiers in the service type repository for trading are broken in the fact of inheritance. 

Summary: The list_types operation in the trader service type repository returns a sequence of service type names. This will break badly if the number of types is large. Modify 

Summary: The add_type operation for the trader type repository accepts an if_name parameter of type Identifier. The type name of an IDL type for the service offer is just a string 

Summary: Trader specification problem...The type equivalence is never defined. Both the core and the trader spec should be amended to spell out the intended interpretation 

Summary: independent of whether the trader uses name or structural equivalence for types, I need an IDL sequence type if I want to use sequence-valued properties. Need to include add. IDl file. 

Summary: Boolean return value of OfferIdIterator::next_n() is redundant. and it is ill-defined to control a loop. (see archive to this issue) 

Summary: From spec for the next_n operation (...) Definition forces the trader implementation to do read-ahead. This seems inconsistent. 

Summary: The CosTrading::OfferIdIterator interface has some problems. Calling max_left() may or may not raise an exception, depending on trader, have no choice not to call it if I care about port. cod 

Summary: Spec obliges the trader to return, say, 10 million offers all in "ids" because the text forces "id_itr" to be nil when "how_many" is large enough. Spec should be ammended.. 

Summary: I would suggest to ammend spec to require a value of nil for id_itr for both cases shown in the archive of this issue. This was intended in spec. 

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

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: Same case for RACollectionFactories) on page 17-74, 17-75 as in issue 763 

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

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.  

(Section 2.2.1.1) on page 44, it says:     "The desired_props parameter defines the set of properties describing returned offers that are to be returned with the object reference. There are three possibilities, the importer wants one of the properties, all of the properties (but without having to name them), or some properties (the names of which are provided)."     CORRECTION: "one of the properties" should say "none of the properties". The three possibilities are defined in the IDL as:     enum HowManyProps { none, some, all };  

We have a hole in the trader constraint language:    	interface I1 {  		enum { red, green };  	};    	interface I2 {  		enum { green, red };  	};    The expression    	$.field_name == red    is ambiguous because it's not clear which red is meant. You could argue  that the type of the field on the left will identify what type should  apply for the enumerator on the right. However, that doesn't solve the  problem because    	red == red    is a valid expression.    Attempts to solve the problem by using a scoped name don't work:    	$.field_name == I1::red    That's because the grammar does not allow the use of the :: operator.

The OMG�s address on page viii is obsolete

The Scope section and clause 7 say that CVL is �domain-independent� � surely it is specific to the domain of variability? A more nuanced description would be better.