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 760: CORBAservices (editorial page 17-21)
Issue 761: CORBAservices (editorial page 17-22)
Issue 762: CORBAservices (editorial page 17-23)
Issue 959: CORBAservices IDL
Issue 1582: Type vs. Implementastion class
Issue 1713: CosTime::TIO::spans and CotTime::TIO::overlaps issue
Issue 1717: Description of the IN parameter tdf is missing (Time Service)
Issue 2347: INS: why NamingService instead of NameService?
Issue 2488: Query Service IDL code
Issue 2820:
Issue 2821:
Issue 2824:
Issue 2825:
Issue 2826:
Issue 2827:
Issue 2829:
Issue 2830:
Issue 2831:
Issue 2832:
Issue 4901: IDL keyword clash in CosNotification.idl
Issue 4979: OMG TimeService spec error
Issue 6412: testing issue
Issue 7087: AggregateIDs differently numbered than OPC HDA AGGREGATE
Issue 7154: DeploymentSpecification - notation for DeploymentSpecification on the insta
Issue 7790: Section: Section 8.2
Issue 7833: CORBA Source Annotation Namespace in schema
Issue 10088: section 2.1.2.5.2.16 "get_default_datareader_qos"
Issue 10833: Deployment
Issue 11605: Section 4.2.4.3
Issue 13191: Ambigous line crossings
Issue 14198: OCL 2.0, 2.1 Loop iterators are not ordered and other inconsistencies
Issue 14430: UML2::Constraint
Issue 15430: DDS should use typed modules
Issue 16096: The current Java PSM makes an implicit assumptions on member ordering

Issue 760: CORBAservices (editorial page 17-21) (issues)

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

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

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

Summary: In CosStream Module the CompoundExternaliztion.idl is included
 > (needed for CosCompoundExternalization::Node), and in the
 > CosCompoundExternalization Module the Stream.idl is included (needed
 > for CosStream::Streamable and CosStream::StreamIO). Now correct me
 > if I am wrong but isn"t this self-referential loop going to cause
 > problems with the IDL compiler, in that either CosStream will not
 > know about CosCompoundExternalization or vice-versa causing a
 > compiler error.

Summary: Suggested rewording for the paragraph in Section 5.9.1, pg 35 of the
 Notation Guide, version 1.1.  Complete suggested text is availabl ein the issues"s archive

 closed issue

Summary: n Appendix B, p14-21 the return type of the interfaces
 	CosTime::TIO::spans
 and
 	CosTime::TIO::overlaps
 is declared as boolean. This is in contradiction to p 14-10,11 of the
 same document that states a return type of OverlapType.
 
 The correct return type is OverlapType.
 

Summary: For the interface
 	UTO CosTime::TimeService::new_universal_time(
 		in TimeBase::TimeT time,
 		in TimeBase::InaccuracyT inaccuracy,
 		in TimeBase::TdfT tdf
 	);
 the description of the IN parameter tdf is missing.
 
 

Summary: INS specifies that the default object key for the `root" context of a
 CosNaming service is "NamingService".  However, the keyword passed to
 CORB::ORB::resolve_initial_references() to locate the CosNaming service
 is "NameService".  This is bound to create confusion, if only among
 implementors.  Suggest changing the object key of the root naming
 context to "NameService".
 

Summary: The Query Service IDL code (document 97-12-18) has multiple syntax
 errors. I have checked it with Orbix, OrbixWeb and Visibroker IDl
 compiler. 
 

see note at end of issue text message - should have already been closed

CosNotification.idl contains a struct named 'EventType', which
clashes with the new CCM-related keyword 'eventtype'.

Just came accoss an issue with the publichsed CosTime IDL.
The specification for the TIO interface contains a return 
value of OverlapType for a couple of its operations. However,
the published IDL for CosTime returns a boolean.

   interface TIO
   {
     OverlapType spans( in UTO time, out TIO overlap);
     OverlapType overlaps( in TIO interval, out TIO overlap);
     UTO time ();
   };

IDL defintion:

   interface TIO 
   {
     boolean spans( in UTO time, out TIO overlap);
     boolean overlaps( in TIO interval, out TIO overlap);
     UTO time ();
   };

testing the issue db

The AggregateID numbering is different from the OPC HDA AGGREGATE numbering. This complicates bridges. Change the AggregateID numbering to be the same as the OPC HDA AGGREGATE numbering.

DeploymentSpecification - notation for DeploymentSpecification on the instance level 

There are several examples of DeploymentSpecification on the instance level which use the notation name: value (i.e. execution: thread) instead of the default notation for slots (see InstanceSpecification on p. 59) name = value (i.e. execution = thread) 

See - Figure 132 on page 191 - Table 8, 2nd row, 2nd column on page 199 

For performance/dependability analysis the models are usually stochastics. How to specify distributions ? The "statisticalQualifier" attribute associated to a <<QoS dimension>> attribute allows to declare that the type of value of the attribute is a distribution but not the "type of distribution". On the other hand, a syntax is not given for the specification of the type of distribution as well as, in general, for complex timing values. To illustrate a possible solution let us consider a system UML model in which we want to specify the service time for two resources COM and MEM as random variables distributed according to the uniform PdF and to the negative exponential PdF, respectively. The annotation has to be as simple as possible but at the same time detailed enough to be useful for the construction of a stochastic model. 

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.

The reference to CADMID should be removed as this contradicts the
statement of process neutrality in the Rationale (section 1.7.1)

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.

Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2. 

Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2. 

Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

Since multiple iterators in forAll and exists are just syntactic sugar, the Abstract Syntax would be simpler if the sugar was expanded during CST mapping; too late now.

Making the iterator collection ordered and consistently 1..2 just narrows the specification to what the well-formedness constraints assume.

A syntax change and further work is needed in the IterateExpCS syntax mapping to support multiple iterators. Since forAll is realised by IteratorExpCS, it perhaps doesn't matter that the elaborated concrete syntax in 11.9.1 is a fiction.

The text changes below fix everything except this last point.

When modelling a constraint in UML on several constrained elements, how is itpossible to know which constrained element is the context of the constraint?

In the spec, the metaattribute context of Constraint is derived, but the spec does not define how it is derived.

The DDS specfication has typed interfaces (writer/reader/etc) which are currently not expressed in IDL. The DDS specification should use the typed modules as introduced in the dds4ccm specification to express all interfaces explicitly in IDL, including the typed ones.

The current Java PSM makes an implicit assumptions on member ordering when defining  DDS Types in POJO that is not inherently guaranteed by the Java Language Specification. The possible resolution for this issue is to require @ID annotations when defining DDS Types using POJOs. In this case the ID would be used to uniquely defining the order to the attribute members.