Issues for UML 2.0 Diagram Interchange Finalization Task Force

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

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

Issue 6971: property CoreSemanticModelBridge.element
Issue 6973: UML Diagram interchange -- change Rational ref to IBM
Issue 7165: Allow a Diagram Element to represent multiple Model Elements
Issue 7252: Change role name in DI metamodel
Issue 7257: Introduce a 'Nesting Guide'
Issue 7258: UML diagram interchange: views may need more context
Issue 7259: UML diagram interchange: schema usage needed
Issue 7260: UML diagram interchange: inappropriate diagram properties
Issue 7261: UML diagram interchange: limitation of complex properties
Issue 7262: UML diagram interchange: limitation of complex properties
Issue 7263: UML diagram interchange: more features in schema?
Issue 7264: UML diagram interchange: dubious value of leaf elements
Issue 7265: UML diagram interchange: cut-out diagram feature
Issue 7266: UML diagram interchange: do diagrams have to be nodes?
Issue 7267: UML diagram interchange: translucent property unnecessary?
Issue 7268: UML diagram interchange: unit of measurement
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 7272: UML diagram interchange: association as a graph node
Issue 7273: UML diagram interchange: containment vs reference
Issue 7305: UML 2 Diagram Interchange / Assigning icons to stereotypes
Issue 7568: Rename the specification to OMG Diagram Interchange Specification
Issue 7663: UML Mapping in DI specification inadequate
Issue 7788: A schema definition has to be added for the completeness of the specificati
Issue 8179: Section: 8.5 Properties

Issue 6971: property CoreSemanticModelBridge.element (uml2di-ftf)

The property CoreSemanticModelBridge.element should reference the class
MOF::Object rather than Elements::Element. MOF::Object is the implicit
superclass of everything in UML2/MOF2.
Making this change allows diagram elements to refer to instances of any
metamodel: not just UML2.

The intension of the draft is to reference a superclass of all metamodels specified with MOF so the change is to MOF::Object is necessary

The current draft spec still refers to Rational Software in the front matter. Any references to this should be changed to IBM Rational Software

Replace all occurences of 'Rational Software Corporation' with 'IBM Rational Software'.
There are two occurences:
- Copyright entry on page 4
- Chapter 6.3, Acknowledgement

SemanticModelBridge.element (actually realized on its subclasses
currently) has a multiplicity of 1. 
There are several cases where one visual diagram element will represent
multiple elements in the metamodel (abstract syntax).
For example 'AssemblyConnector' which I think should be a single symbol
consisting of joined 'cup and ball' (see p148 of Superstructure
ptc/03-08-02).


Proposed resolution: change the multiplicity of
SemanticModelBridge.element from 1 to 1..*.

The intension of the specification is to reference only one semantic model element directly from a SemanticModelBridge and therefore a GraphElement references only one semantic model element. If a GraphElement has to represent multiple semantic model elements the GraphElement has contained diagram elements which reference the set of semantic model elements. Each contained diagram element references one of the model elements which the container GraphElement has to represent. So every possible structure can be represented with a hierarchy of nested diagram elements.
Disposition:	Closed, no change has to be made

Change role name in DI metamodel of the SemanticModelBridge associated with the Diagram from 'namespace' to 'owner'

 

Explanation:

The association between the class 'Diagram' and 'SemanticModelBridge' in the DI metamodel has the intension to model which namespace is assigned to a diagram. So the name of the role of the SemanticModelBridge has been 'namespace'. But state diagrams and activity diagrams belong to a state machine. So the name 'owner' fits better in this context.

Introduce a 'Nesting Guide' to specify the contained-container hierarchies
of the diagram elements to represents all model elements of the semantic
model


Explanation:


The semantic model elements are typically represented by a hierarchy of
nested diagram elements which have a container-contained relationship. To
specify which hierarchy of diagram elements is needed to model a special
represenation of a model element we need a nesting guide which describes the
hierachies for all model elements. This nesting guide should be an appendix
to the diagram interchange specification and is added as an appendix to this
document.


Gentleware will provide a nesting guide that refers to the UML 1.4
metamodel. As soon as the super- and infrastructure of the UML 2.0 is
finally adopted a nesting guide for UML 2.0 should be created.

Add the 'Nesting Guide' as Appendix C to the specification. (The 'Nesting Guide' is contained on the following pages.)

The semantic bridge contains either a single reference property or a simple string. Some views, however, need more semantic context than that. (eg: pattern instance views need two semantic references to represent the semantic context).

Discussion:	
The concept is that every GraphElement represents at most one semantic element. If needed the GraphElements are nested. Each nested GraphElement is 'responsible' for one of the semantic model elements and one GraphElement is the container and represents the whole semantic item. This container-GraphElement has typically a SimpleSemanticModelElement.
 
Disposition:	Closed, no change has to be made

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.

Some properties like the diagram zoom level or viewport positions might not be suitable for a team environment, where each person could change them without having to share this preference with the rest of the team. By persisting these properties in the mode, team members would have to share these (not necessary the expectation). Alternatively, these properties could be part of the workspace preferences. 

These properties can be seen as a default for the view the author has preferred.
The viewport and zoomfactor of the DiagramLink can be useful for example if a class diagram is linked to a package and the diagram is displayed inside this package with a reduced zoomfactor. 
In another context this diagram is displayed with a different zoom factor without the package as container.
Tools which support team development could easily ignore these properties if the zoomfactor should be stored individually for every team member. But this is not the scope of the DI standard.
Disposition:		Closed, no change has to be made

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists�etc)? 

Yes, this is a limitation. But the properties are not designed to store complex model information. There are some standard properties for style issues and the properties are meant to be used for non-standard extension but it is no concept to store complicated tool specific information.
Disposition:		Closed, no change has to be made

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists�etc)? 

Duplicated (Issue 7271)

Vendors usually add more features to UML diagrams which could require more features in the schema. Is it expected for these features to be omitted when exporting to DI? If no, then there has to be an agreement on those formats as well

Discussion:	
 Generally additional features should be omitted or stored in the properties.
Disposition:		Closed, no change has to be made

Rendering UML shapes is the responsibility of the tool. Therefore, there is no value in using Leaf Elements in the aggregation of UML views. If the intention of using them is notational (like whether attribute visibility should be textual or iconic) then a property is the better way to represent it. 

The intension is not to store redundant information in the DI. The aggregation/composition information is available in the semantic model and there is no need to store them again. 
If there are different representation possible and the information of the representation is not available in the semantic model, then the current representation is available from the 'presentation' attribute of the 'SemanticModelBridge'. The Actor is an example for the use of it.
Disposition:		Closed, no change has to be made

Regarding the cut-out diagram feature, I cannot see how the large diagram can layout out its referenced diagrams without explicitly store layout information. Is there any? This should be documented.

Discussion:	
 The part of a diagram which is shown as a cut-out has the same layout as the original diagram. The cut-out can be moved as a whole if it is nested in another GraphElement because all positions are relative. If the layout should be changed a cut-out cannot be used but a new diagram should be created. 
The cut-out can be used to avoid the need of updating the diagram if the original diagram has changed because the changes are reflected in the cut-out.
Disposition:		Closed, no change has to be made

If you considered zoom and viewport position to be in the workspace, then a diagram just has a name. This means a diagram does not have to be a node. It could just be a GraphElement. Also the diagram link having the same properties will have the same issue (By persisting these properties in the mode, team members would have to share these (not necessarily the expectation). ) 

The zoom and viewport should be stored for every Diagram and DiagramLink, see resolution of issue 7260.
Disposition:		Closed, no change has to be made

Is the ‘Translucent’ property needed? Cannot be inferred by not having a background color property? 

 No, if the background color is not set the element inherits the background color from its container. This is the strategy for all color and font properties. So if an element should be translucent an extra property has to be set. This strategy avoids the need to specify a lot of properties in a deep nested element hierarchy.
Disposition:		Closed, no change has to be made

The coordinate system assumes ‘pixel’ to be the unit of measurement. Often publishing applications use a physical measurement instead (like himetric). Do we need to consider that? Which is more common for the types of applications in consideration?

The relative coordinates and size is important for the layout of the diagrams not the absolute measurement. The scaling of the presentation depends on the representation medium. The unit 'pixel' can be easily handled. It was one goal of the standard not to redefine complex graphic issues like measurement or color systems but to preserve the layout information which are important for the readily understanding of the model.
(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.

You gave an example about the adornment of an association and its representation as a graph node. I thought this information can be deduced from the semantic relationship! Why do you need to explicitly represent it as a node? 

The position of the representation of an adorment is not defined by the semantic context. It can be freely moved. Other properties like the font, font size or color can only be defined with a GraphElement representing the adorment too.
Disposition:		Closed, no change has to be made

With regard to the OMG issue of changing the semantic bridge’s association with the diagram role from ‘namespace’ to ‘owner’, the request is appropriate but the justification that state diagrams are owned by state-machines and therefore the role name has to change is not correct. In fact, the important relationship between a state diagram and its state-machine should not be the containment but rather the reference relationship. A state diagram references a state-machine element through the semantic bridge’s ‘semantic model’ role. The containment relationship is optional; a state diagram could legitimately be referencing a state-machine but contained within another namespace (although not typical). 

 The 'semantic model' role of a diagram is defined with a SimpleSemanticModelElement with a 'typeInfo'. This typeInfo defines the type of a diagram, e.g. a state diagram has the typeInfo 'StateDiagram'. Therefore the owner for diagrams must be defined with an extra link to the according element in the semantic model. This is done by the owner-role for the Diagram.
Disposition:		Closed, no change has to be made

There is a need to uniquely assign one or more stereotype icons to a stereotype, when that stereotype is defined. It should be explained how this stereotype is displayed and how multiple stereotypes are handled. 

Each stereotype is represented with its own GraphElement. If the stereotype should be represented by an image an instance of the class Image is nested in the GraphNode. The nesting of the GraphElement and the 'Image' is described in the Nesting Guide in detail (e.g. the GraphNode has a SemanticModelElement with representation= "StereotypeImage"). The Nesting Guide is subject of issue 7257 and can be found in ballot 1.
Disposition:		Closed, no change has to be made

The current title of the document reflects the original RFP but is far
too specific for the standard produced and unnecessarily limits how
people may think it can be applied.


Proposed resolution:
 Rename the specification to OMG Diagram Interchange Specification

The scope of the specification is UML 2.0 and the title should represent this scope. Therefore the title should not be changed to a title which excludes this scope.
 
Disposition:		Closed, no change has to be made

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

A schema definition has to be added for the completeness of the specification

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'