In Table 1 a few standardized properties are defined. To be more conveniened with other standards (mainly SVG)the DI should use the property names 'fill' and 'stroke' instead of 'BackgroundColor' and 'ForegroundColor'

I tried to load the diagram-interchange.xml file in the referenced zip file into the Rational Rose UML 1.4 xmi addin. This addin reports 4 errors:

Could not add DataType "Image" to Logical View – probably duplicate name.
Could not add DataType "Dimension" to Logical View – probably duplicate name.
Could not add DataType "Point" to Logical View – probably duplicate name.
Relation "Generalization" @ in 'Image' was not resolved – not added.

The first three are cases where data type names duplicate classes in the same package. This is at least bad form, if not actually illegal. Rose does not allow it.

THe final error is a case where one of the "generalization" references of the "Image" class points to a Generalization object that is not in the file:

<UML:GeneralizableElement.generalization>

<UML:Generalization xmi.idref="EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06"/>

</UML:GeneralizableElement.generalization>

There is no object with an ID of "EAID_B3BDA775_38C1_4989_87D1_A4CDF297DA06" in the file.

I was looking over the specification wanting to create a program that will be able to produce and read the format. However, I could use some clarification in Annex C, C.2.1 Class Diagram. There is no representation for an association. I had been, for a short time, believed that it was DiAssociationClass, but upon looking that up, I found it was not. For DiAssociationEnd, the tree does not match up with the example, as I understand it, in Annex B. Annex C says that the RoleAdornment should product a node with simpleSemanticModelElement of 'RoleAdornment'. But there is no such nesting. The GraphNode(<AssociationEnd>)'s next nestings go straight to 'name', 'visibility', and 'multiplicity'. Could you clarify this for me? Also in the zip example, there is an undefined compartment used called 'ExpressionCompartment'. DiAssociationClass refers to 'Stereotypes'. Is that supposed to be StereotypeCompartment? In C.1, there are a few areas where ',' appears that is should be '<'.

The di-schema.xsd available from the link http://www.omg.org/cgi-bin/doc?ptc/05-06-07 import namespace <xsd:import namespace="http://www.omg.org/XMI" schemaLocation="XMI.xsd"/>. XMI.xsd is not present in the same package throws schema error on di-schema.xsd. Where can be the approved XMI.xsd found that the di-schema refers to.

The following figure shall picture a Part of a composite structure
diagram. Are the graphically informations like the colon that seperates the
name and the type of the part, the brackets that surround the multiplicity,
and the ".." points that display the range of the Multiplicity legal
Diagram Interchange informations ? Till now I saved
those informations as TextElements with a SimpleSemanticModelElement.
Is this ok or can I disregard those informations ?

______________________________________

The current mapping from the Diagram Interchange meta model to UML is inadequately specified in Appendix A of the DI specification. It will not enable a standard encoding of DI models from the UML 2.0 meta model across vendors. Specifically:

• the mapping does not cover UML 2.0
• the mapping solely consists of a table listing a subset of UML meta classes
• the mapping does not cover the complexities of UML 2.0 decomposition details, as specified in the UML 2.0 specification in the area of Sequence Diagrams, Activity Diagrams and State Machines.

If you are going to represent list items like attributes or operations by nested graph nodes, what happens if the semantic element has changed (lost an operation or gained an attribute) after the diagram is created. When should the list be updated?

In case of autosize (the size property is omitted) all across the aggregation hierarchy, how would you calculate the size of a graph node?

The use of Bounds (x, y, width, height) as layout constraints maybe acceptable for rendering diagrams, but is not very suitable for editing ones that employ other types of layout algorithms that might not necessarily use a Bounds constraint. (attributes could be laid out in their compartment using a flow layout that only considers the order of attributes in their collection to be what is relevant to the layout).

The proposal mainly talks about the schema of the UML diagram notation. It does not detail the expected usage of that schema or the “format”. The format should at least include the view aggregation hierarchies and the view properties assignment (what properties are installed for every view). Recently there was an appendix that talks about the aggregation hierarchy.