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 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 14059: Need to have an explicit way to bind flow properties or atomic flow ports to block properties
Issue 15486: Need a better example for XML Get Request
Issue 15713: missing document title
Issue 16904: Is compensation allways triggered automatically upon uncaught errors?
Issue 17063: Condition classes should only be used with WaitSets
Issue 17640: Section 8.4: Indicate clearly the clauses in which the differences are described

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? 

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.

Need to have an explicit way to bind flow properties or atomic flow ports to block properties. Currently section 9.3.2.3 lacks such rules. Such rules would allow a consistent way to relay data via flow ports to the properties of blocks and also would allow a convenient way to transmit values via flow port by changing a value of a property owned by the block.

Section 7.2.6.1 only provides a simple example of a GetConfigResponse with no parameters. A better example would provide parameters possibly with multiplicity so implementers have a clearer understanding of how it should be done. Replace current example with:

<?xml version="1.0" encoding="UTF-8"?><GetConfigResponse gems_version="1.1" target="device1"	timestamp="1234.98765" token="ABCD" transaction_id="1" xmlns="http://www.omg.org/gems"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"	xsi:schemaLocation="http://www.omg.org/gems GEMS_base_types.xsd">

	<Result>SUCCESS</Result>	<description>Get config was successful</description>	<Parameter name="name">		<string>Device One</string>	</Parameter>

	<Parameter name="hex">		<hex_value bit_length="16">DEADBEEF</hex_value>	</Parameter></GetConfigResponse>

The document title in PDF metadata 
is "untitled", 
should be 
"Common Object Request Broker Architecture (CORBA)
Specification"

Page 180 (PDF 210) states:
'Note that other mechanisms for interrupting a Transaction Sub-Process will not cause compensation (e.g., Error, Timer, and anything for a non-Transaction Activity).'


Whereas page 305 (PDF 335) states:
'If no error Event Sub-Process is specified for a particular Sub-Process and a particular error, the default behavior is to  automatically call compensation for all contained Activities of that Sub-Process if that error is thrown, ensuring the behavior for auditing and monitoring.'


These statements seem contradicting to me and  therefore I'd like to get a clarification on the following questions:


1. Is compensation allways triggered automatically upon uncaught errors?
2. Is there a difference between compensation of a Transaction Sub-Process and any other Sub-Process?

The DataReader API provides methods to read samples with a condition. This condition can be either a ReadCondition or a QueryCondition, and in this case the samples returned are either filtered by the status (ReadCondition) or the content+status (QueryCondition).
The ReadCondition is completely in overlap with the instance/status/view states and its use is really irrelevant when in combination with the DataReader. On the other end the only aspect of the QueryCondition that really matters to a DataReader are the query expression and parameters. 


By looking carefully at the API, it seems apparent that the ReadCondition and the QueryCondition really make sense only when used with a WaitSet. On the other end, their use in conjunction of a DataReader is a stretch and breaks the semantics of the "Condition". On principle a condition is used to "wait" for a particular status to be true, yet the DataReader "read" are -- rightfully -- always non-blocking. In addition, the API opens up for gratuitous runtime errors as I could write silly code as follows (in C++):


auto  rc = reader.create_readcondition();
reader2.read(..., rc,...);


This although silly is allowed by the API and on a proper DDS implementation should raise an exception.


The same could happen with a QueryCondition!






Resolution
---------------
Limit the use of Read/QueryCondition to waitsets and put in place a more robust mechanism to do status and content filtering on a data-reader read.


An example of what could be done is provided below, where I assume that the DataStatus is the former ReaderState:


   reader
      .filter_status(DataStatus::new_data())
      .filter_content(Query("x < 100 AND  y < 100"))
      .read();


Equally, one could write (again legal C++ below with little magic under-cover) :


   reader
      .instance(handle)
      .filter_status(DataStatus::new_data())
      .filter_content(Query("x < 100 AND  y < 100"))
      .read();




Notice that this code, not only  is very declarative and thus shows very clearly the intent of the programmer, but in addition does not allow for the silly mistakes shown above. Further more, it really highlights he role of the Sample/Instance/View status as a "filter" on the status of data.

The first sentence implies that certain changes are specified in this clause, but there is no specification.  However, unless the current document is intended as a delta document with respect to some earlier standard, which does not appear to be the case, then identifying such changes in the body of the standard is not appropriate. Indicate clearly the clauses in which the differences are described.  If the differences are described, consider moving the information to an informative annex.

Indicate clearly the clauses in which the differences are described.  If the differences are described, consider moving the information to an informative annex.