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 760: CORBAservices (editorial page 17-21) Jira Issue COLL-10
Issue 761: CORBAservices (editorial page 17-22) Jira Issue COLL-11
Issue 762: CORBAservices (editorial page 17-23) Jira Issue COLL-12
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 13218: Typos in the Ruby CORBA Langaugae Mapping spec Jira Issue RCLM-2
Issue 13837: Section: 7.25.2 Jira Issue RCLM-1
Issue 15680: valuetype is missing Jira Issue RCLM11-1
Issue 16004: Abstract interface spec is missing Jira Issue RCLM11-2
Issue 16544: minor grammer error Jira Issue RCLM12-1
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)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: What should be done for remove/replace/retrieve_element_set_to_next if the element cannot be deleted/replaced/retrieved?
Resolution:
Revised Text:
Actions taken:
July 24, 1996: received issue
Discussion:
Issue 63: Suggested changes to Collection spec. (zz-collection)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: A number of interface changes suggested for the Collection specification.
Resolution:
Revised Text:
Actions taken:
July 24, 1996: received issue
Discussion:
Issue 489: PropertySetFactory (zz-property)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: PropertySetFactory interface has method create_constrained_propertyset. Why doesn"t PropertySet interface have methods get_allowed_property_types and get_allowed_properties
Resolution:
Revised Text:
Actions taken:
January 23, 1997: received issue
Discussion:
Issue 490: allowed_properties and allowed_properties_defs constraints (zz-property)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
January 23, 1997: received issue
Discussion:
Issue 491: What does "Def" in PropertySetDef stand for? (zz-property)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: What does "Def" in PropertySetDef stand for?
Resolution:
Revised Text:
Actions taken:
January 23, 1997: received issue
Discussion:
Issue 492: Properties are typed, named values associated with an object (zz-property)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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???
Resolution:
Revised Text:
Actions taken:
January 23, 1997: received issue
Discussion:
Issue 493: Why doesn"t the trader use the property service? (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: Why doesn"t the trader use the property service?
Resolution:
Revised Text:
Actions taken:
January 23, 1997: received issue
Discussion:
Issue 546: Trader Type repository breaks polymorphism (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: The semantics of mandatory and read-only modifiers in the service type repository for trading are broken in the fact of inheritance.
Resolution:
Revised Text:
Actions taken:
April 21, 1997: received issue
Discussion:
Issue 547: list_types needs iterator (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
April 21, 1997: received issue
Discussion:
Issue 548: Interface names insufficiently constrained (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
April 21, 1997: received issue
Discussion:
Issue 549: Type eqivalence problems in trader (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
April 22, 1997: received issue
Discussion:
Issue 550: Sequence valued trader properties (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 22, 1997: received issue
Discussion:
Issue 558: OfferIdIterator::next_n return value (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: Boolean return value of OfferIdIterator::next_n() is redundant. and it is ill-defined to control a loop. (see archive to this issue)
Resolution:
Revised Text:
Actions taken:
April 28, 1997: received issue
Discussion:
Issue 559: Trader spec forces read-ahead (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: Summary: From spec for the next_n operation (...) Definition forces the trader implementation to do read-ahead. This seems inconsistent.
Resolution:
Revised Text:
Actions taken:
April 28, 1997: received issue
Discussion:
Issue 560: OfferIdIterator Problem (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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
Resolution:
Revised Text:
Actions taken:
April 28, 1997: received issue
Discussion:
Issue 561: list_offers() description incorrect (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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..
Resolution:
Revised Text:
Actions taken:
April 28, 1997: received issue
Discussion:
Issue 562: list_offers is under-specified (zz-trader)
Click here for this issue's archive.
Nature: Uncategorized
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
April 28, 1997: received issue
Discussion:
Issue 755: Error in CosCollection information (zz-collection)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary: 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".
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 760: CORBAservices (editorial page 17-21) (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: After ElementInvalid and KeyInvalid, you discuss ParameterInvalid. There is a space written in it: Paramete_rInvalid
Resolution: editoral
Revised Text:
Actions taken:
September 29, 1997: received issue
March 19, 2002: closed issue
Discussion:
Issue 761: CORBAservices (editorial page 17-22) (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: There are three comments in the interface description that do not have the same style (font) as the other comments
Resolution: editorial
Revised Text:
Actions taken:
September 29, 1997: received issue
March 19, 2002: closed issue
Discussion:
Issue 762: CORBAservices (editorial page 17-23) (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: In the description of the first parameter "collection_interface" of type Istring, ther starting quote of the word collection_interfaceis missing.
Resolution: editorial
Revised Text:
Actions taken:
September 29, 1997: received issue
March 19, 2002: closed issue
Discussion:
Issue 763: CORBAservices (editorial page 17-71 to 17-73) (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: The operation "create (ParameterList parameters) raises (ParameterInvalid)" is not mentioned in the CollectionFactories interface, while it is fully explained on page 17-73
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 764: CORBAservices (editorial page 17-74, 17-75) (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: Summary: Same case for RACollectionFactories) on page 17-74, 17-75 as in issue 763
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 765: Map/SortedMap (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: 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.
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 766: Collection.add_element (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: 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?
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 767: page 17-23: Collection.remove_all (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: 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?
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 768: Page 17-26: Collection.all_elements_do (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: 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?
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 769: Page 17-29: OrderedCollection.remove_element_at_position (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: 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?
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 770: Interface OrderedCollection (zz-collection)
Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary: 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?
Resolution:
Revised Text:
Actions taken:
September 29, 1997: received issue
Discussion:
Issue 1322: IDL does not match (zz-collection)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: 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
Resolution:
Revised Text:
Actions taken:
May 14, 1998: received issue
Discussion:
Issue 3271: semantics of boolean iterator.next(out thing) ... (zz-collection)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary: 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.
Resolution:
Revised Text:
Actions taken:
February 4, 2000: received issue
Issue 4225: Trader issue (Section 2.2.1.1) on page 44 (zz-trader)
Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary: (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 };
Resolution:
Revised Text:
Actions taken:
March 16, 2001: received issue
Issue 4336: Hole in trader constraint language (zz-trader)
Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:
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.
We want to report the following small changes to the Beta 1 spec: Page 13 corrected font of section �Normative References� Page 13 updated CORBA v3.0.3 to v3.1 in section 1.1 and 3 Page 18 7.4.1 corrected mechamism to mechanism Page 12 7.12 changed typechecking into �type checking� Page:22 7.11 Mapping for Wide string types: change first phrase to "The OMG IDL Wide string type" 7.12.2 Change last sentence 'if the Any contained a specific' should be 'if the Any contains a specific' Page:27 7.20 para 4: change "a accessor" to "an accessor" 7.20 updated reference to CORBA v3.1 Page 29 Removed a few empty lines 7.23 : '_get_ �firstname, as defined' should be '_get_firstname, as defined' Page 31 7.25.1 Changed toplevel to �top level� Page 31 Removed reference to Test.idl and TestS.rb, that only makes the example unclear Page 32 Changed accomodate to accommodate Page 34 7.25.2, changed �Ofcourse� to �Of course� and �coulde� to �could� Change 'The implementation method result depends then on the number of result values:' to 'The implementation method result depends on the number of result values as follows:' Check heading of table 7.3
In the default implementation in section 7.25.2, class "PortableServer::DynamicImplementation", there is an "&&" which should be "&&".
The spec lacks the mapping of valuetypes, this should be added
Abstract interface spec is missing. Should be added.
Review comment from the AB, can address this in the next RTF Specific Comments: Section 7.19.4 : minor grammar error - change 'mapped on' to 'mapped to' or mapped 'on to' if that is what you mean.
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.