1. OMG Mailing List
  2. Diagram Definition 1.2 Revision Task Force

All Issues

  • All Issues
  • Name: dd-rtf
  • Issues Count: 18

Issues Descriptions

A_style_canvas Association is unnamed

  • Key: DD12-6
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The final Association in DG.xmi

    <packagedElement xmi:type="uml:Association" xmi:id="A_style_canvas" memberEnd="Canvas-packagedStyle A_style_canvas-canvas">
    <ownedEnd xmi:type="uml:Property" xmi:id="A_style_canvas-canvas" name="canvas" type="Canvas" association="A_style_canvas"/>
    </packagedElement>

    has no name. This is at best poor practice and contrary to the guidance at the end of UML 2.5 2.4.2.

  • Reported: DD 1.1 — Tue, 13 Dec 2016 11:18 GMT
  • Updated: Thu, 22 Dec 2016 19:22 GMT

Why does A_style_canvas have no name?

  • Key: DD12-5
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    All the Associations in DC/DG/DI have names except just one:

    <packagedElement xmi:type="uml:Association" xmi:id="A_style_canvas" memberEnd="Canvas-packagedStyle A_style_canvas-canvas">
    <ownedEnd xmi:type="uml:Property" xmi:id="A_style_canvas-canvas" name="canvas" type="Canvas" association="A_style_canvas"/>
    </packagedElement>

    Is this intended?

  • Reported: DD 1.1 — Thu, 14 Apr 2016 08:13 GMT
  • Updated: Thu, 14 Apr 2016 13:56 GMT

Small typos.

  • Key: DD12-1
  • Legacy Issue Number: 19486
  • Status: open  
  • Source: yahoo.fr ( Lambert Clara)
  • Summary:

    There are some typos in the attributes description of Color data type, we can read:
    "Integer [1] - the red component of the color in the range (0..255)"
    for all three components, green and blue included.

    The description should reflect the correct color.

  • Reported: DD 1.0 — Mon, 23 Jun 2014 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Small typo.

  • Key: DD12-2
  • Legacy Issue Number: 19485
  • Status: open  
  • Source: yahoo.fr ( Lambert Clara)
  • Summary:

    There is a small typo in the DD specification document.
    On page 17 we can read:
    "namely the Diagram Graphics(DI) package (Clause 9) and the Diagram Interchange(DG) package"

    The acronyms in the parenthesis are reversed, it should be Diagram Graphics(DG) and Diagram Interchange(DI).

  • Reported: DD 1.0 — Mon, 23 Jun 2014 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Constraints

  • Key: DD12-4
  • Legacy Issue Number: 16492
  • Status: open  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: DD 1.0b1 — Mon, 31 Jan 2011 05:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

Consider possibility of adding Port concept to DI

  • Key: DD12-3
  • Legacy Issue Number: 18680
  • Status: open  
  • Source: Fraunhofer FOKUS ( Max Bureck)
  • Summary:

    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.

  • Reported: DD 1.0 — Mon, 22 Apr 2013 04:00 GMT
  • Updated: Mon, 20 Apr 2015 12:40 GMT

DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1

  • Key: DD11-16
  • Legacy Issue Number: 18954
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1

  • Reported: DD 1.0 — Mon, 23 Sep 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This is a change to the DD XMI to replace Models with Packages. There is no change to the primary specification.
    Disposition: Resolved

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Styling capabilities of Canvas ambiguous

  • Key: DD11-15
  • Legacy Issue Number: 18679
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Max Bureck)
  • Summary:

    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.

  • Reported: DD 1.0 — Mon, 22 Apr 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Since canvases are groups, they inherit the fact that "The (local or shared) styles defined on a group cascade to its member elements" (see Subclause 10.3.12), that is, the styles are not for the group itself (the revision below spells out the meaing of "cascade"). Conversely, canvases support background colors and fills for themselves (backgroundColor and backgroundFill), as opposed to their members.
    Graphical elements, including canvases, can have clip paths applied to them to restrict painting (for example, applying an oval mask to a background). This is separate from the fact that canvases, as groups, are lower in z-order than their members and therefore appear to be additionally clipped by their members.
    Fills can have transforms (Fill::transform) to change how they are applied on their graphical elements. This is separate from transforms on graphical elements (GraphicalElement:transform), which apply to graphical elements themselves.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MarkedElement should be abstract in provided CMOF files

  • Key: DD11-14
  • Legacy Issue Number: 18675
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Max Bureck)
  • Summary:

    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.

  • Reported: DD 1.0 — Wed, 17 Apr 2013 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Revise as suggested

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use MOF Primitive Types

  • Key: DD11-13
  • Legacy Issue Number: 17453
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Diagram Common should reuse MOF Primitive Types

  • Reported: DD 1.0 — Thu, 21 Jun 2012 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Remove DD primitive types and import UML PrimitiveTypes into DC

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DG library for BNF parsing

  • Key: DD11-12
  • Legacy Issue Number: 17147
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: DD 1.0 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Yes, but it would not be a DG library. It would be provided by the mapping language used between DI and DG, which is it is not defined by DD.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DG library for string bounding

  • Key: DD11-11
  • Legacy Issue Number: 17099
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

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

  • Reported: DD 1.0 — Wed, 8 Feb 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    No, would be provided by the mapping language used between DI and DG, which is it is not defined by DD.
    Disposition: Closed No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiple modelElements per diagram element

  • Key: DD11-10
  • Legacy Issue Number: 16991
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: DD 1.0 — Wed, 11 Jan 2012 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This duplicates 16628.
    Disposition: Duplicate/Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Z-order in DC -> DI and DG

  • Key: DD11-9
  • Legacy Issue Number: 16910
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    This is merged with 16909, which addresses the same topic.
    Disposition: Duplicate/Merged

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DiagramElement ownership

  • Key: DD11-8
  • Legacy Issue Number: 16909
  • Status: closed  
  • Source: NASA ( Maged Elaasar)
  • Summary:

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

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Add ordering to DI::DiagramElement::/ownedElement ordered. Move Clause 8.1.3 (Z-Order) to the description of DiagramElement::/ownedElement, modified for diagram elements, and also to DG::Group::member, modified to diagram graphics

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure A.1 multiplicities

  • Key: DD11-7
  • Legacy Issue Number: 16908
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Revise as suggested.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

CMOF version

  • Key: DD11-6
  • Legacy Issue Number: 16907
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    DD should use the latest formal version of CMOF

  • Reported: DD 1.0 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    See resolution of 16628.
    Disposition: Merge/Duplicate

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DiagramElements cannot represent multiple model Elements

  • Key: DD11-5
  • Legacy Issue Number: 16628
  • Status: closed  
  • Source: Northrop Grumman ( Christopher McClure)
  • Summary:

    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?

  • Reported: DD 1.0b1 — Tue, 18 Oct 2011 04:00 GMT
  • Disposition: Resolved — DD 1.1
  • Disposition Summary:

    Loosen multiplicity of DiagramElement::/modelElement property to *. Also resolves 16907 by using UML::Element instead of CMOF::Element in the Diagram Interchange metamodel

  • Updated: Fri, 6 Mar 2015 20:58 GMT