so I like DD... DI is great... DG needs some work... DG only allows one to do static things... first of all, just cite SVG and be done with it
and don't try to redo SVG... second of all... the things I need to do in SVG requires scripting... for example, based on an enumeration
in a TaggedValue of a Stereotype on a Dependency... I need to show that dependency in a very different way then say another enumerationLiteral on that same Enumeration...

so I think we have MOF and MOF models where we have some API that can be generated from them (do we have a standard for that?)... we have SVG standard (which has engines etc for tool developers)... we have ECMAScript which could be one (perhaps the default) of many scripting languages we could use in the SVG standard... we just need to be able to tie the scripting in the SVG to the model... SVG has a document element which allows it to get into the HTML and navigate that... we need a "model" element (and an api from MOF) which allows us to get into that... and then we can produce SVG outputs that have embedded scripts which allows us to do the dynamic things (i.e. based on things like EnumerationLiterals) to output the iconography for a language... this could then be a tool-independent output for every language out there that a tool could just import in along with the XMI file that defines the structure of the language...

we have needed this kind of capability for a long time now... and I think could easily fix this problem... it is been a source of incompatibility for a long time... and also would be a standard for notation for a language even if the tool vendor decided to do it in a different way than SVG

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

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?

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.

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.