Issues for Diagram Definition 1.2 Revision Task Force
To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 16628: DiagramElements cannot represent multiple model Elements Jira Issue DD11-5
Issue 16907: CMOF version Jira Issue DD11-6
Issue 16908: Figure A.1 multiplicities Jira Issue DD11-7
Issue 16909: DiagramElement ownership Jira Issue DD11-8
Issue 16910: Z-order in DC -> DI and DG Jira Issue DD11-9
Issue 16991: Multiple modelElements per diagram element Jira Issue DD11-10
Issue 17099: DG library for string bounding Jira Issue DD11-11
Issue 17147: DG library for BNF parsing Jira Issue DD11-12
Issue 17453: Use MOF Primitive Types Jira Issue DD11-13
Issue 18675: MarkedElement should be abstract in provided CMOF files Jira Issue DD11-14
Issue 18679: Styling capabilities of Canvas ambiguous Jira Issue DD11-15
Issue 18954: DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1 Jira Issue DD11-16
Issue 16628: DiagramElements cannot represent multiple model Elements (dd-rtf)
Click here for this issue's archive.
Source: Northrop Grumman (Mr. Christopher McClure, christopher.mcclure(at)ngc.com)
Nature: Clarification
Severity: Significant
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?
Resolution: Loosen multiplicity of DiagramElement::/modelElement property to *. Also resolves 16907 by using UML::Element instead of CMOF::Element in the Diagram Interchange metamodel
Revised Text: see pages 12 - 13 of ptc/2014-03-01 for details
Actions taken:
October 18, 2011: received issue
July 15, 2014: closed issue
Issue 16907: CMOF version (dd-rtf)
Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Revision
Severity: Significant
Summary: DD should use the latest formal version of CMOF
Resolution: See resolution of 16628. Disposition: Merge/Duplicate
Revised Text:
Actions taken:
December 14, 2011: received issue
July 15, 2014: closed issue
Issue 16908: Figure A.1 multiplicities (dd-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Minor
Summary: In Figure A.1 (UML DI Metamodel), the multiplicities opposite UMLLabel should be 0..1.
Resolution: Revise as suggested.
Revised Text: In Figure A.1 (UML DI Metamodel), replace �1� to �0..1� (two occurrences) next to the diamonds under the rectangles labelled UMLCompartment and UMLShape.
Actions taken:
December 14, 2011: received issue
July 15, 2014: closed issue
Discussion:
Issue 16909: DiagramElement ownership (dd-rtf)
Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Revision
Severity: Significant
Summary: In Figure 9.2 (Diagram Element) DiagramElement ownership should be ordered and given occlusion semantics, per Section 8.1.3 (Z-Order).
Resolution: 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
Revised Text: Remove Subclause 8.1.3 (Z-Order). In Clause 8.1 (Overview), remove all of Subclause 8.1.3 (Z-Order). In Clause 9 (Diagram Interchange) In Figure 9.2 (Diagram Element), add the modifier �ordered, � before �readonly� for the property DiagramElement::/ownedElement. Subclause 9.3.2 (DiagramElement) Description, second paragraph, First sentence, replace �graph� with �tree�. Replace the last sentence (the one beginning �This collection is also�) with �This collection is ordered, to specify z-order for owned elements.� After the last sentence, in the same paragraph, insert the contents of Subclause 8.1.3 (Z-Order), not including the title, modified as follows: Remove �(or graphical) �. Replace the second sentence (the one beginning �The general rules�) with �Z-order of owned diagram elements is determined as follows:� First bullet, After �Owned�, insert � diagram�. After �owning�, insert � diagram�. Second bullet, Replace �Elements� with �Diagram elements�. Replace �higher in the same �ordered� composition collection� with �earlier in the ordered collection�. Replace �lower in the same collection� with �later�. Remove the third bullet. Association Ends, /ownedElement, After �union�, add �, ordered�. Before �collection� insert �ordered �. In Clause 10.3.12 (Group), Description, insert a new paragraph after the first starting with the sentence �The collection of members is ordered, to specify z-order for owned elements.� Followed by the contents of Subclause 8.1.3 (Z-Order), not including the title, modified as follows: Replace �Diagram (or graphical)� with �Graphical�. Replace the second sentence (the one beginning �The general rules�) with �Z-order of owned graphical elements is determined as follows:� First bullet, After �Owned�, insert � graphical�. Replace �owning elements�, with �owning groups�. Second bullet, Replace �Elements� with �Graphical elements�. Replace �higher in the same �ordered� composition collection� with �earlier in the ordered collection�. Replace �lower in the same collection� with �later�. Remove the third bullet.
Actions taken:
December 14, 2011: received issue
July 15, 2014: closed issue
Issue 16910: Z-order in DC -> DI and DG (dd-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
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.
Resolution: This is merged with 16909, which addresses the same topic. Disposition: Duplicate/Merged
Revised Text:
Actions taken:
December 14, 2011: received issue
July 15, 2014: closed issue
Issue 16991: Multiple modelElements per diagram element (dd-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
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.
Resolution: This duplicates 16628. Disposition: Duplicate/Merged
Revised Text:
Actions taken:
January 11, 2012: received issue
July 15, 2014: closed issue
Issue 17099: DG library for string bounding (dd-rtf)
Click here for this issue's archive.
Source: NASA (Dr. Maged Elaasar, Maged.E.Elaasar(at)jpl.nasa.gov)
Nature: Revision
Severity: Significant
Summary: Is a DG library needed to calculate bounding boxes for strings in particular fonts?
Resolution: 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
Revised Text:
Actions taken:
February 8, 2012: received issue
July 15, 2014: closed issue
Issue 17147: DG library for BNF parsing (dd-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary: A DG library for BNF parsing would enable language-specific DI's capture strings, instead of modeling BNF constraints.
Resolution: 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
Revised Text:
Actions taken:
February 22, 2012: received issue
July 15, 2014: closed issue
Issue 17453: Use MOF Primitive Types (dd-rtf)
Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Revision
Severity: Significant
Summary: Diagram Common should reuse MOF Primitive Types
Resolution: Remove DD primitive types and import UML PrimitiveTypes into DC
Revised Text: In Subclause 8.1 (Overview), first paragraph, First sentence, replace �contains a number of common primitive types as well as� with �imports MOF�s Primitive Types library, as shown in Figure 8.1, and defines�. Remove last sentence. In Subclause 8.2 (Abstract Syntax), Figure 8.1 (The primitive types) Change the caption to �Dependencies of the DC package�. Replace the graphic with the following: Remove Subclauses 8.3.2 (Boolean), 8.3.6 (Integer), 8.3.9 (Real), 8.3.10 (String) and renumber the others accordingly.
Actions taken:
June 21, 2012: received issue
July 15, 2014: closed issue
Issue 18675: MarkedElement should be abstract in provided CMOF files (dd-rtf)
Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Max Bureck, max.bureck(at)fokus.fraunhofer.de)
Nature: Enhancement
Severity: Minor
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.
Resolution: Revise as suggested
Revised Text: In Clause 10 (Diagram Graphics), Figure 10.3 (Primitive Elements), change the label �MarkedElements� to be in italics. Subclause 10.3.17 (MarkedElement), in the title, insert �Abstract � before �Class�. Subclause 10.3.11 (GraphicalElement), Specializations, after �MarkedElement [� insert �Abstract �. Subclause 10.3.14 (Line), Generalizations, after �MarkedElement [� insert �Abstract �. Subclause 10.3.21 (Path), Generalizations, after �MarkedElement [� insert �Abstract �. Subclause 10.3.24 (Polygon), Generalizations, after �MarkedElement [� insert �Abstract �. Subclause 10.3.25 (Polyline), Generalizations, after �MarkedElement [� insert �Abstract �.
Actions taken:
April 17, 2013: received issue
July 15, 2014: closed issue
Issue 18679: Styling capabilities of Canvas ambiguous (dd-rtf)
Click here for this issue's archive.
Source: Fraunhofer FOKUS (Mr. Max Bureck, max.bureck(at)fokus.fraunhofer.de)
Nature: Clarification
Severity: Minor
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.
Resolution: 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.
Revised Text: In Subclause 10.3.12 (Group), Description, First sentence, Replace �does not have a visual manifestation itself but is rather used to group a collection of member graphical elements in order to apply� with �applies�. Replace �to them� with �to its member elements� After the first sentence, insert a new sentence �Specialized groups can introduce visual representations, for example see Canvas, but Group does not define any itself.�. Second sentence (third after the revision above), Replace �cascade� with �apply�. After �member elements�, insert �, not to the group�. Replace cross reference from �Text� to �Style�.
Actions taken:
April 22, 2013: received issue
July 15, 2014: closed issue
Issue 18954: DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1 (dd-rtf)
Click here for this issue's archive.
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary: DD 1.0 defines DI, DC, DG as Models which is not in the CMOF subset for MOF 2.4.1
Resolution: This is a change to the DD XMI to replace Models with Packages. There is no change to the primary specification. Disposition: Resolved
Revised Text:
Actions taken:
September 23, 2013: received issue
July 15, 2014: closed issue