Issues for Issues: unassigned, reported bugs, problems and questions with OMG specs and adopted submissions.

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

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

Issue 62: Failure behavior for iterator operations
Issue 63: Suggested changes to Collection spec.
Issue 184: Compiler being able to translate from OMG-IDL into ANSI
Issue 284: Malformed PropertyName
Issue 489: PropertySetFactory
Issue 490: allowed_properties and allowed_properties_defs constraints
Issue 491: What does "Def" in PropertySetDef stand for?
Issue 492: Properties are typed, named values associated with an object
Issue 493: Why doesn"t the trader use the property service?
Issue 498: Name equivalence
Issue 535: WWW Form output
Issue 546: Trader Type repository breaks polymorphism
Issue 547: list_types needs iterator
Issue 548: Interface names insufficiently constrained
Issue 549: Type eqivalence problems in trader
Issue 550: Sequence valued trader properties
Issue 558: OfferIdIterator::next_n return value
Issue 559: Trader spec forces read-ahead
Issue 560: OfferIdIterator Problem
Issue 561: list_offers() description incorrect
Issue 562: list_offers is under-specified
Issue 755: Error in CosCollection information
Issue 763: CORBAservices (editorial page 17-71 to 17-73)
Issue 764: CORBAservices (editorial page 17-74, 17-75)
Issue 765: Map/SortedMap
Issue 766: Collection.add_element
Issue 767: page 17-23: Collection.remove_all
Issue 768: Page 17-26: Collection.all_elements_do
Issue 769: Page 17-29: OrderedCollection.remove_element_at_position
Issue 770: Interface OrderedCollection
Issue 961: TypedConsumerAdmin interface (4.9.2))
Issue 1114: Timestamp format used in SFP is not adequate (AV streams issue)
Issue 1293: ObjectCreationError and Nofactory exceptions in Externilazition
Issue 1322: IDL does not match
Issue 1985: Elapsed Time since 10/15/1582
Issue 2009: COM/CORBA keywords
Issue 3271: semantics of boolean iterator.next(out thing) ...
Issue 3342: Correction of CORBA specification (page 18-51)
Issue 3522: CosConsurrencyControl service bug or not?
Issue 3741: Simulation specification issue
Issue 4188: CosExternaliazation Service (bug?)
Issue 4216: Inconsisten IDL in the Minimum CORBA chapter
Issue 4220: Contradictory WFR
Issue 4225: Trader issue (Section 2.2.1.1) on page 44
Issue 4336: Hole in trader constraint language
Issue 4507: Fixed Types in COM
Issue 5434: Licensing Service issue
Issue 6585: Do we really need SDOSystemElement
Issue 7599: Which type of name should be used
Issue 7982: initialValue attribute only exists for a ParameterType or ArgumentType
Issue 9018: Section: 10.3
Issue 10088: section 2.1.2.5.2.16 "get_default_datareader_qos"
Issue 10833: Deployment
Issue 12305: Location: 4 Abbreviations and Conventions
Issue 12529: 'synchrobnous' and 'asynchronous' switched
Issue 12574: Section: 2.1.4.1.2 The behaviour of next_member is under defined
Issue 12857: add interface ORB { Object string_to_object ( in wstring str ); };
Issue 13191: Ambigous line crossings

Issue 62: Failure behavior for iterator operations (issues)

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: Existing software based on messages with ASNI format description and a future version based on IDL. Does anybody know something about such a compiler?

Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help

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 Name equivalence issue has appeared in comp. object.corba. Follow up posting from Michi Henning

Summary: Issue regarding implementation of the Query IDL specifications on a Java ORB. Issue involves implementing following idl definition from the CosQueryCollection module

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: in section 4.9.2 last paragraph:
 
 "Such a ProxyPushSupplier is guaranteed only to invoke operations defined in
 interface I.  Any event on the channel that does not correspond to an
 operation defined in interface I is NOT passed on to the consumer.  Such a 
 ProxyPushSupplier is therefore an event filter based on type".
 
 My question is:  if we have this proxy to block generic calls (push() in this
 case) why does TypedPushConsumer inherit CosEventComm::PushConsumer, whish does
 support push() ?  Why should the generic calls like push() be blocked anyway
 if (according to 4.7.1) TypedPushConsumer should support both typed and generic
 models ?
 
 Is there something I am misunderstanding ?
 

Summary: The timestamp format used in SFP is not adequate for many applications
 particularly non-linear editing and post-production systems. These systems
 require a more comprehensive timestamping format. Furthermore, the current
 timestamp, expressed in microseconds wraps around too quickly. This needs
 to be addressed without loss of precision.
 
 

Summary: There is a bit of confusion in the specification concerning the
 exceptions that are possible during the internalization process.
 
 The internalize operation can raise CosLifeCycle::NoFactory and
 StreamDataFormatError exceptions. This operation calls the
 internalize_from_stream operation of the Streamable interface that can
 raise the CosLifeCycle::NoFactory, StreamDataFormatError, and
 ObjectCreationError exceptions.The last paragraph on page 8-20 (August
 1997 release) states that the ObjectCreationError and
 StreamDataFormatError exceptions of the internalize_from_stream
 operation originate from the read_object amd read_<type> operations on
 the StreamIO interface. However, the ObjectCreationError is not raised
 by any of these, according to the IDL in figure 8-6.
 

:NoFactory, StreamDataFormatError, and

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: Questions: Is there a formula to determine the amount of elapsed time
 >since 10/15/1582 as specified in the TimeService Specification?
 >
 >After finding that September of 1752 only has 19 days and
 >a few different interpretations of leap year rules, I believe
 >there is some ambiguity as to what should be placed in a 
 >TimeBase::Utc time value to represent a specific date/time.
 >
 

:Utc time value to represent a specific date/time.

Summary: I can"t find in the COM/CORBA spec parts A and B any mention of how to
 deal with IDL identifiers that are keywords to the Microsoft "mktyplib" tool.
 This tool mangles the following identifier (not necessarily a complete list) by
 prepending them with "_":
 
         "BSTR", "CALLCONV", "coclass", "CY",
         "CURRENCY", "DATE", "DECIMAL", "DISPID", "DISPPARAMS",
         "dual", "EXCEPINFO", "guid", "GUID",
         "HRESULT", "importlib", "IDispatch",
         "INTERFACEDATA", "IUnknown", "LCID",
         "METHODDATA", "odl", "oleautomation",
         "PARAMDATA", "properties", "propget", "propput", "retval",
         "SAFEARRAY", "SAFEARRAYBOUND", "SCODE",
         "VARIANT", "VARIANTARG", "VARIANT_BOOL",
         "VARTYPE", "VARENUM"
 
 As far as I can tell, the output of the "mktyplib" tool makes use 
 (directly or indirectly) of the regular C++ bindings, whose identifiers
 are not mangled the same way.  This makes it impossible to emit COM bindings
 for IDL files that contain the above keywords.
 
 The problem that I"m running into is in CosTrading IDL, where the identifier
 "properties" is used.
 

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.

>You write on page 18-51:
>In COM V2.0, interfaces can have single inheritance. However, as opposed to
>CORBA,
>there is a standard mechanism by which an object can have multiple interfaces
>(without
>an inheritance relationship between those interfaces) and by which clients can
>query
>for these at run-time. (It defines no common way to determine if two interface
>references refer to the same object, or to enumerate all the interfaces
>supported by an
>entity.)
>
>It's not right, that there's no common way to determine if two interface
>references refer to the same object. The IUnknown-Pointer of two different
>interfaces of the same object must be the same (object identity in COM).

I develop CosConcurrencyControl service for JacORB, but I don't
understud from specification how client can destroy LockSet.
When I create Object which allow concurrency access, I create LockSet.
When I destroy this Object I must destroy LockSet, because it's garbage,
bu no way for this does not exists.

As solution of this problem,  I add in CosConcurrencyControl.idl  next
changes:
exception LockExists{};

and method
void destroy raises (LockExists);

in interface LockSet.

As I undestand this changes is wrong, but have you idea about desigion
this problem.

The High Level Archicture Programmers Guide states
(8.3) Encoding and Object Updates:
"When producing an AHVPS [AttributeHandleValuePairSet, Ralf.],
 the federate is responsible for any data marshalling (encoding)."

This principles has been transferred to the DSS proposal,
but encoding is what ORBs are good for;
a participant in distributed simulation should not explicitly handle it.

Attribute type names will be listed in the FOM/SOM description
and are mapped to RTI internal handles,
but that does not help with generating or interpreting value encodings.

As we already have a runtime type information packager (CORBA Any),
we should use it and replace all occurences of "AttributeHandleValuePairSet"
at least with "any", so a common coding scheme will be used.
The same holds for HLA interaction parameters.

Page 2-7 of the CosExternalization Service Specification (April 2000)
defines the following interfaces:
CosStream::Node
CosStream::Role
CosStream::Relationship

A CosStream::Node inherits from the CosStream::Streamable interface and
therefore is a streamable object -- it has an external_form_id attribute
that enables a FactoryFinder to recreate the object using the
create_uninitialized operation.

Unfortunately, the CosStream::Role and CosStream::Relationship interfaces do
not support the CosStream::Streamable interface and therefore are not
"streamable;" in particular, there is no standard method to obtain a KEY for
them when it is time to internalize them.

Perhaps, I am missing something (it wouldn't be the first time ;-), but
having them support the Streamable interface would certainly make
implementation much easier. Might I suggest the following:

interface Role: CosGraphs::Role, CosStream::Streamable {
...
}
interface Relationship: CosGraphs::Relationship, CosStream::Streamable {
...
}

at a minimum this would permit the CosStream::Node internalize_node()
operation and the CosStream::StreamIO read_graph() operation to use a KEY
value in the FactoryFinder to instantiate the object, before it is
internalized.

  Section 23.14 of the CORBA/IIOP 2.4.1 specification lists the
complete IDL for a minimumCORBA implementation.  However, the text in
the chapter and the IDL are inconsistent, for example, section 23.4.2
reads:

------------------------------------------------------------------------
---------------
The is_a operation is omitted so as not to introduce a requirement
either for holding

detailed type information in the object reference or for getting type
information over

the wire. Instead, minimumCORBA relies on design time resolution of type
checking

issues.

The non_existent operation is omitted, because of the design philosophy
of making

more decisions statically at design time.

The create_request operation is omitted, as the Dynamic Invocation
Interface is

omitted.

I think there is a coherence issue between the WFR 5 and 6 on Transition meta-class:
[5] Transitions outgoing pseudostates may not have a trigger
and
[6] An inital transition at the topmost level either has no trigger or it has trigger with the stereotype "create".
 
Initial transition is a specific case of transition outgoing a pseudostate. The WFR [6] puts then the WFR [5] in the wrong.
 
I propose then to have a single WFR and the following rewriting:
 
[5] The transition  outgoing the initial pseudostate of statemachine root state either has no trigger or it has trigger with the stereotype "create". In all other case, transitions outgoing pseudostates may not have a trigger.
 
Yours,
 
Sébastien Gérard.

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

There is currently no specification for fixed-point types in the COM/CORBA mapping. I'm interested in getting this changed: how can we proceed? better still, is this work already under way??

The Action struct has a member of type ActionRequired, name 'action' . 

The JacORB (1.4 beat 4) IDL comiler/parser complains that the declarator has already been used (identifier collision): 

Error in CosLicensingManager.idl, line:28(17): Declarator action already defined in scope. ActionRequired 1 error(s). Errors compiling CosLicensingManager. 

The Corba spec (2.4 00-10-01) states in the Lexical definitions that upper and lower case are regarded as the same. Is the use of the Action & action definitions twice then a collision? Can the the action variable be renamed in the IDL file to something like action_required without affecting any other specification / 

The meaning of the term might be completely unclear to 3rd party persons. Can we do without using this term? Do we really need SDOSystemElement? One of the reasons for having SDOSystemElement is to allow non-SDOs to participate in the Organisation. Is it correct? If so, then if we decide to get rid of the term non-sdo then probably we do not need SDOSystemElement as well. At least, the term ‘non-SDO’ should be changed. 

This problem is preventing me from implementing a XMI 2.0 Schema generator for a MOF 1.4 metamodeling environment. The specification is often unclear about which type of name (short name, fully-qualified name, or namespace-qualified name) should be used. >From section 1.8.1: “The XML element name for each metamodel class, package, and association in a document is its short name.” Then, in section 2.2.1, rule 4 we have “ClassTypeDef ::= "<xsd:complexType name=’" //Name of Class//…”. Now, the w3 xml schema specification (http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ states that “no complex type definition can have the same name as another simple or complex type definition.” If the spec means that we should use the short name of the Class in rule 4 above, then it isn’t in line with the xml schema specification, because it’s obvious that several classes in different namespaces of the same metamodel can have the same short name. Furthermore, the w3 schema specification defines the name attribute of a complexType declaration to be of type NCName, or ‘non-colonized name’. This means that we can’t use the namespace-qualified name for the Class either. The only solution is to use the fully-qualified name for metamodel elements** when defining their types. **The fully-qualified name of a metamodel element lists all of the encapsulating MOF Namespaces of the element. So, if you have Class A in nested Package B in outermost Package C, the qualified name of A would be ‘C.B.A’. 

As per MOF specification only one property can be id. isID defines Id property for Class. Query is... 1) IF I have a Class say "Class1" which has property say "prop1" which is defined as Id. And there is "Class2" which inherits from "Class1" Then 1)Does "Class2" also inherit Id of "Class1"? 2)Can "Class2" has its owned id property? like overiding id property etc? Basically in specification there is no mention of relationship between inheritance of Classes and there id properties. 2) Also we see a single id property is too restrictive. In fact for the UML Meta model's Classes we could not define any single property as a identifying property. Is there any plan to make multiple properties as identifier in MOF? 

I just wanted to let someone know about a typographical error I saw in the DDS spec 05-12-04-1. In section 2.1.2.5.2.16 "get_default_datareader_qos" The second paragraph reads in part


"The values retrieved get_default_datareader_qos will match the set of values specified
on the last successful call to get_default_datareader_qos, ..."



I believe that last function should be "set_default_datareader_qos" rather than "get_default_datareader_qos". This is consistent with other sections of the specification and makes sense. I just wanted to point this out. It looks like there used to be this same kind of error for set_default_datawriter_qos but was fixed in 05-12-04-1. I didn't see this listed in the DDS issues.

While reading the DDS specification, 'Data Distribution Service for Real-time Systems Version 1.2 OMG Available Specification formal/07-01-01', I found that the 'synchrobnous' and 'asynchronous' was switched as highlighted in red in the below paragraph in the spec.


<para #4, page 11>
On the subscriber’s side however, there are more choices: relevant information may arrive when the application is busy doing something else or when the application is just waiting for that information. Therefore, depending on the way the application is designed, asynchronous notifications or synchronous access may be more appropriate. Both interaction modes are allowed, a Listener is used to provide a callback for synchronous access and a WaitSet associated with one or several Condition objects provides asynchronous data access

The behaviour of next_member is under defined. More details have to be provided about management of exceptions.

We see more and more use of unicode. It happens more and more that users have code that gets unicode (wchar) commandline arguments. In order to smoothen corba usage for these users we propose to add interface ORB { Object string_to_object ( in wstring str ); };