Issues for Mailing list of the Diagram Definition 1.1 Revision Task Force

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

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

Issue 16492: Constraints
Issue 16628: DiagramElements cannot represent multiple model Elements
Issue 16907: CMOF version
Issue 16908: Figure A.1 multiplicities
Issue 16909: DiagramElement ownership
Issue 16910: Z-order in DC -> DI and DG
Issue 16991: Multiple modelElements per diagram element
Issue 17099: DG library for string bounding
Issue 17147: DG library for BNF parsing
Issue 17453: Use MOF Primitive Types
Issue 18675: MarkedElement should be abstract in provided CMOF files
Issue 18679: Styling capabilities of Canvas ambiguous
Issue 18680: Consider possibility of adding Port concept to DI

Issue 16492: Constraints (dd-rtf)

The spec currently has no constraint sections.  Should we add them?  For
example, we might require unowned diagram elements to be diagrams

The definition of DiagramElement has an association to the depicted MOF Element with a multiplicity of [0..1]; so, one DiagramElement can represent at most one model Element.  However, UML contains at least one notation in which a single symbol represents more than one Element: using a single State symbol to represent multiple similar States (see p.601 of the UML 2.4 Superstructure Specification).  Will DD be able to support this notation?

DD should use the latest formal version of CMOF

In Figure A.1 (UML DI Metamodel), the multiplicities opposite UMLLabel should be 0..1.

In Figure 9.2 (Diagram Element) DiagramElement ownership should be ordered and given occlusion semantics, per Section 8.1.3 (Z-Order).

Section 8.1.3 (Z-Order) should be specific to the ownership association on DiagramElement to itself, and should be moved to DI and DG.

Diagram elements might have multiple modelElements (for example, state lists in UML state machines, combined merge/decision diamonds in UML activities).  Languages can specialize to 1 or order as needed.

Is a DG library needed to calculate bounding boxes for strings in particular fonts?

A DG library for BNF parsing would enable language-specific DI's capture strings, instead of modeling BNF constraints.

Diagram Common should reuse MOF Primitive Types

In the standard the description of MarkedElement states "It is an abstract super class of all graphical elements whose vertices are explicitly specified and ordered.". However the heading declares "[Class]", which is inconsistent with the naming of other classes. The heading should declare it "[Abstract Class]". And in the CMOF files the MarkedElement is not modeled as an abstract class.

The description of the Canvas element does not say how attributes inherited from GraphicalElement are handled. Since the Canvas explicitly references a background color and a fill, I assume that the attributes "sharedStyle" and "localStyle" are only taken into account for calculation of an effective style of child elements. Since the canvas defines a background, I guess it should fill the parent UI control, so a clip path wouldn't make much sense. Since transforms can also be applied to the fill of an application, I guess the transforms are just applied to the group of containing children. Please clarify, if this assumptions are correct.

Hi, the concept of ports, attached to the outside bounds of an element allowing connections between elements is a widespread concept. Adding this concept would help generic layouting algorithms taking ports into account (such as KIELER) doing a much better job. Since DI defines abstract subclasses, meta models without ports can simply choose to not use the concept.