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.