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 760: CORBAservices (editorial page 17-21)
Issue 761: CORBAservices (editorial page 17-22)
Issue 762: CORBAservices (editorial page 17-23)
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 959: CORBAservices IDL
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 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 1985: Elapsed Time since 10/15/1582
Issue 2009: COM/CORBA keywords
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 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 4901: IDL keyword clash in CosNotification.idl
Issue 4979: OMG TimeService spec error
Issue 5434: Licensing Service issue
Issue 6412: testing issue
Issue 6585: Do we really need SDOSystemElement
Issue 7087: AggregateIDs differently numbered than OPC HDA AGGREGATE
Issue 7154: DeploymentSpecification - notation for DeploymentSpecification on the insta
Issue 7259: UML diagram interchange: schema usage needed
Issue 7269: UML diagram interchange: use of bounds limiting
Issue 7270: UML diagram interchange: size of graph node with autosize
Issue 7271: UML diagram interchange: list updating and nested graph nodes
Issue 7599: Which type of name should be used
Issue 7663: UML Mapping in DI specification inadequate
Issue 7790: Section: Section 8.2
Issue 7833: CORBA Source Annotation Namespace in schema
Issue 7982: initialValue attribute only exists for a ParameterType or ArgumentType
Issue 8179: Section: 8.5 Properties
Issue 8971: Diagram Interchange clarification
Issue 9018: Section: 10.3
Issue 10088: section 2.1.2.5.2.16 "get_default_datareader_qos"
Issue 10499: Section: Annex C
Issue 10660: Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file
Issue 10833: Deployment
Issue 11605: Section 4.2.4.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 13191: Ambigous line crossings
Issue 13533: di-schema.xsd
Issue 14059: Need to have an explicit way to bind flow properties or atomic flow ports to block properties
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 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 17640: Section 8.4: Indicate clearly the clauses in which the differences are described
Issue 18302: XML type description not orthogonal and not consistent
Issue 18837: Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI

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

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

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

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 ();
   };

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 / 

testing the issue db

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. 

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 

The proposal mainly talks about the schema of the UML diagram notation. It does not detail the expected usage of that schema or the “format”. The format should at least include the view aggregation hierarchies and the view properties assignment (what properties are installed for every view). Recently there was an appendix that talks about the aggregation hierarchy. 

There is a Nesting Guide which defines the hierarchy of DiagramElements for every semantic element. The Nesting Guide is subject of issue 7257 and attached to ballot.
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred.

The use of Bounds (x, y, width, height) as layout constraints maybe acceptable for rendering diagrams, but is not very suitable for editing ones that employ other types of layout algorithms that might not necessarily use a Bounds constraint. (attributes could be laid out in their compartment using a flow layout that only considers the order of attributes in their collection to be what is relevant to the layout). 

Other layout algorithm can be used to layout elements of the diagrams (like features). In this case the bounds can be ignored. But this may lead to a different layout. E.g. if the preferred font is not available on the current system it can be necessary for a readable layout. But the standard is designed to preserve the layout as it is designed by the author of the model. So if all properties are set correct the bounds of all elements (including the position of consecutive text elements, vertical or horizontal) gives an exact information to layout the diagram correctly.
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred

In case of autosize (the size property is omitted) all across the aggregation hierarchy, how would you calculate the size of a graph node?

 This depends on the semantic model element of the graph nodes. The size of a graph node which is connected to a text (like an attribute) is calculated by the bounds of text. If the graph node contains other diagram elements the size is calculated by the size of the contained elements. 
The calculated size may depend on the system (and properties like the font properties) but this is intended. If the size should exaclty be the same it cannot be omitted.
The omitting size is mostly designed for graph nodes containing text to make it easier to describe a flow layout (see issue 7269).
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred.

If you are going to represent list items like attributes or operations by nested graph nodes, what happens if the semantic element has changed (lost an operation or gained an attribute) after the diagram is created. When should the list be updated? 

 Each GraphElement has a SemanticModelBridge and if the bridge is connected to a semantic model element the bridge and the GraphElement has to be deleted if the semantic model element is deleted because of the 1-1 relationship.
The GraphElement depends on the semantic context. If there is no semantic model element there has to be a SimpleSemanticModelElement which defines the context of the GraphElement. A GraphElement without a semantic context is not allowed.
So the list has to be updated each time the semantic model has changed. If the semantic model has changed but the diagram interchange model is not updated the model is not valid anymore. The constraint is broken that a GraphElement has a semantic context.
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred.

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

The current mapping from the Diagram Interchange meta model to UML is inadequately specified in Appendix A of the DI specification. It will not enable a standard encoding of DI models from the UML 2.0 meta model across vendors. Specifically:
- the mapping does not cover UML 2.0
- the mapping solely consists of a table listing a subset of UML meta classes
- the mapping does not cover the complexities of UML 2.0 decomposition details, as specified in the UML 2.0 specification in the area of Sequence Diagrams, Activity Diagrams and State Machines.

Appendix C contains a Nesting Guide which describes the needed nesting of DiagramElements to represent the elements of the semantic model of UML. The Nesting Guide was subject of issue 7257 and is part of ballot 1.
(Previously recommended Disposition: Resolved, no change has to be made)
Based on the concerns from FTF members and the inability to develop a revised resolution within the given timeframe, this issue has been deferred and should be re-addressed in the future Diagram Interchange RTF.

Disposition:		Deferred

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. 

In Table 1 a few standardized properties are defined. To be more conveniened with other standards (mainly SVG)the DI should use the property names 'fill' and 'stroke' instead of 'BackgroundColor' and 'ForegroundColor'

The following figure shall picture a Part of  a composite structure
diagram. Are the graphically informations like the colon that seperates the
name and the type of the part, the brackets that surround the multiplicity,
and the ".." points that display the range of the Multiplicity   legal
Diagram Interchange informations ? Till now I saved
those informations as TextElements with a SimpleSemanticModelElement.
Is this ok or can I disregard those informations ?


    ______________________________________
    |                                     |
    |     myPart : myPartType [1..*]      |                          
    |_____________________________________|

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.

I was looking over the specification wanting to create a program that will be able to produce and read the format. However, I could use some clarification in Annex C, C.2.1 Class Diagram. There is no representation for an association. I had been, for a short time, believed that it was DiAssociationClass, but upon looking that up, I found it was not. For DiAssociationEnd, the tree does not match up with the example, as I understand it, in Annex B. Annex C says that the RoleAdornment should product a node with simpleSemanticModelElement of 'RoleAdornment'. But there is no such nesting. The GraphNode(<AssociationEnd>)'s next nestings go straight to 'name', 'visibility', and 'multiplicity'. Could you clarify this for me? Also in the zip example, there is an undefined compartment used called 'ExpressionCompartment'. DiAssociationClass refers to 'Stereotypes'. Is that supposed to be StereotypeCompartment? In C.1, there are a few areas where ',' appears that is should be '<'.

I tried to load the diagram-interchange.xml file in the referenced zip file into the Rational Rose UML 1.4 xmi addin.  This addin reports 4 errors: 
 
Could not add DataType "Image" to Logical View -- probably duplicate name.
Could not add DataType "Dimension" to Logical View -- probably duplicate name.
Could not add DataType "Point" to Logical View -- probably duplicate name.
Relation "Generalization" @  in 'Image' was not resolved -- not added.

 
The first three are cases where data type names duplicate classes in the same package.  This is at least bad form, if not actually illegal.   Rose does not allow it.
 
THe final error is a case where one of the "generalization" references of the "Image" class points to a Generalization object that is not in the file:
 
<UML:GeneralizableElement.generalization>

<UML:Generalization xmi.idref="EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06"/>

</UML:GeneralizableElement.generalization>

There is no object with an ID of "EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06" in the file.

Invalid "diagram-interchange.xml" file in Diagram Interchange 2.0 's ptc/05-06-07 zip file

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

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.

The di-schema.xsd available from the link http://www.omg.org/cgi-bin/doc?ptc/05-06-07 import namespace <xsd:import namespace="http://www.omg.org/XMI" schemaLocation="XMI.xsd"/>. XMI.xsd is not present in the same package throws schema error on di-schema.xsd. Where can be the approved XMI.xsd found that the di-schema refers to.

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.

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.

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

The XML description of a type seems cumbersome and not orthogonal. I have lots of questions regarding it. Why do we propose 2 separate XML representations (Valid and Well-formed) that both have obvious flaws instead of 1 XML representation that satisfies the requirements of both representations? PrismTech has written an extensive proposal on how represent the types in XML that is both valid, well-formed and orthogonal. I would propose to give that proposal a thought. (Can't attach the document to this ticket, but I will gladly make it available. Angelo also has access to that document

Provide sub-clauses like the resolution for issue 18831