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.

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

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).

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.

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

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

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.

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.

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.

Revise as suggested

Diagram Common should reuse MOF Primitive Types

Remove DD primitive types and import UML PrimitiveTypes into DC

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

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

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.

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

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

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

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?

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

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

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

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.

This duplicates 16628.
Disposition: Duplicate/Merged

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

Revise as suggested.

DD should use the latest formal version of CMOF

See resolution of 16628.
Disposition: Merge/Duplicate

The DI metamodel can be simplified by removing
planes (diagrams can be nested) and leaving
packaging out of scope (DiagramCollection, and
the association between Diagram and Style).

The DI metamodel is simplified by merging planes and plane elements into diagrams and diagram elements, respectively, and removing labels and diagram collections
Planes are removed. These were to support nested diagrams, but it was decided the additional layer of terminology wasn't necessary, especially when some communities simply call them "nested diagrams". In the revised text, diagrams can be nested. Top level diagrams are those diagrams that happen not to be nested. We discussed various possibilities for modeling this, and settled on treating everything as a nestable diagram element, including diagrams, which are taken as a kind of shape. This means diagrams can have model elements, for example, as in UML composite structure. Top level diagrams won't use bounds. Diagrams can be connected by edges, for diagrams of diagrams.
Labels are removed. The only difference from shapes is they are rendered as strings, which would often be determined by the mapping to DG. Language-specific DI's can define these as kinds of shapes if needed.
It was decided that packaging should be out of scope, because domain languages usually have their own packaging mechanisms, resulting in these changes:
The existing association between Diagram and Style is removed, because it was only packaging styles, it didn't mean styles applied to the diagram, like the association between DiagramElement and Style, which Diagram now inherits.
DiagramCollection is removed, and its packaging associations to Style.
Packaging of styles is left in Diagram Graphics, because DG is not intended to extend a domain language that might have its own packaging mechanism.
Updates to the Annexes for these changes will be addressed in separate issues.

The last pagraph of the DiagramElement section says:

Other properties of diagram elements that tools need to interchange
but are not defined in the metamodel can be interchanged using the
extensibility mechanism that is native to the used interchange
format. For example, in an XMIbased interchange, extended data can be
placed on diagram elements within <xmi:extension> tags.

I'm not sure we should be mentioning interchange level extensions,
especially without mentioning metamodel extensions, and domain-specific
extensions like profiles. Can we remove this paragraph, or generalize
it to include other kinds of extension mechanisms?

The specification should not suggest ways of interchanging non-standard information

The default for Diagram::resolution should be shown in the metamodel figures.

It is shown in Figure 9.3 (Diagram).
Revised Text:
None

Disposition: Closed, no change

For example, as in compartmented property strings

Agreed that Shape::bounds should be optional. This is addressed in the resolution to 15902.
Revised Text:
None

Disposition: Duplicate

Some tools might autoplace edge end points.

Agreed that Edge::waypoints should be optional. This is addressed in the resolution to 15902.
Revised Text:
None

Disposition: Duplicate

The other DI classes are abstract.

Agreed that it should be abstract. This is addressed in the resolution to 15902.
Revised Text:
None

Disposition: Duplicate

Update Annex A (UML Diagram Definition Example) for the changes in FTF ballot 1 and complete the example.

Add a small example defining a subset of the UML Class diagram with DD

After the first FTF ballot, the DI diagrams are small enough to be merged into one

The DI metamodel is indeed small enough after Ballot 1 that all concepts can fit in one diagram.

Cascade specification in DG isn't as specific as DI. DG should align with DI (local overrides shared overrides inherited), so the mapping from DI to DG won't need to repeat the cascade algorithm. Multiple styles in DG can be ordered to resolve conflicts

The algorithms only appear different because of a typographic error.

Rename DG::Canvas::style to packagedStyle (and fills and markers) to clarify it is not applied to the canvas, like the one inherited from GraphicalElement::localStyle.

Rename all the composite associations on Canvas to have a “packaged” prefix

DG::GraphicalElement::local/sharedStyle should have unbounded upper multiplicity, to enable DI and the mapping to DG to both introduce styles. The style properties from these two sources might overlap for properties with upper multiplicity greater than one. Use ordering to prioritize styles in case of conflict.

Change the multiplicities as suggested above, and explain the use case.

After 15996, bounds should not be required, for example, search on "with a given bounds". Explain that if DI does not specify bounds, then the mapping to DG does.

The only text remaining after 15902 that implies the presence of bounds is examples were bounds is supposed to be specified.
Revise the description of bounds to indicate it is optional.

The spec sometimes refers to style cascading incorrectly as inheritance. Inheritance applies to classes, cascading applies to instances. Search on "inherit" to find them.

Revise as suggested

After issue 15902, the spec should not refer to owning styles, for example, see DI, DiagramElement, fourth paragraph, next to last sentence, and DI, Style, second paragraph, first sentence.

Revise as suggested

Update for compliance with MOF 2.4 (for example UML:Element instead of MOF:Element), and change text to not refer to MOF, just "metamodel extension".

MOF 2.4 is not formalized yet. It is valid to leave the property typed by CMOF::Element as it is the super class of all metaclasses. We should add a package import from DI to CMOF to make the dependency explicit.

Remove "?"s before attribute names

The “•” (composition) symbols got replaced by “?” symbols by mistake during the editing process of the Beta 2 specification. The fix is to restore the “•” symbols

After 15959, multiple waypoints should not be required, for example, see DI Edge, first paragraph, and in the attribute description.

Revise and suggested.

Would be easier to read the specification with the "+" visibilitiy markers in the figures and attribute/association sections.

We agree with the proposal to remove the visibility symbol as it is not relevant for metamodels

Some of the clause 9.3.1 description is redundant with 8.1.3, and it does not make sense after changes from ballot 1.

Remove the redundant paragraph as suggested

Collections should be called sets, except when they are non-unique

The word collection is valid as it is a generic way of describing sets, lists, sequences...etc. All metamodel properties are already annotated with the specific kinds of collections.
Disposition: Closed, No Change

Update or remove Annex B (DG to SBV Mapping).

Remove the annex until we have content for it.