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 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 7663: UML Mapping in DI specification inadequate
Issue 8179: Section: 8.5 Properties

Issue 7259: UML diagram interchange: schema usage needed (uml2di-ftf)

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.

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

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'