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.

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)?

No Data Available

A schema definition has to be added for the completeness of the specification

No Data Available

Introduce a 'Nesting Guide' to specify the contained-container hierarchies
of the diagram elements to represents all model elements of the semantic
model

Explanation:

The semantic model elements are typically represented by a hierarchy of
nested diagram elements which have a container-contained relationship. To
specify which hierarchy of diagram elements is needed to model a special
represenation of a model element we need a nesting guide which describes the
hierachies for all model elements. This nesting guide should be an appendix
to the diagram interchange specification and is added as an appendix to this
document.

Gentleware will provide a nesting guide that refers to the UML 1.4
metamodel. As soon as the super- and infrastructure of the UML 2.0 is
finally adopted a nesting guide for UML 2.0 should be created.

No Data Available

Change role name in DI metamodel of the SemanticModelBridge associated with the Diagram from 'namespace' to 'owner'

Explanation:

The association between the class 'Diagram' and 'SemanticModelBridge' in the DI metamodel has the intension to model which namespace is assigned to a diagram. So the name of the role of the SemanticModelBridge has been 'namespace'. But state diagrams and activity diagrams belong to a state machine. So the name 'owner' fits better in this context.

No Data Available

The coordinate system assumes ‘pixel’ to be the unit of measurement. Often publishing applications use a physical measurement instead (like himetric). Do we need to consider that? Which is more common for the types of applications in consideration?

No Data Available

Is the ‘Translucent’ property needed? Cannot be inferred by not having a background color property?

No Data Available

If you considered zoom and viewport position to be in the workspace, then a diagram just has a name. This means a diagram does not have to be a node. It could just be a GraphElement. Also the diagram link having the same properties will have the same issue (By persisting these properties in the mode, team members would have to share these (not necessarily the expectation). )

No Data Available

With regard to the OMG issue of changing the semantic bridge’s association with the diagram role from ‘namespace’ to ‘owner’, the request is appropriate but the justification that state diagrams are owned by state-machines and therefore the role name has to change is not correct. In fact, the important relationship between a state diagram and its state-machine should not be the containment but rather the reference relationship. A state diagram references a state-machine element through the semantic bridge’s ‘semantic model’ role. The containment relationship is optional; a state diagram could legitimately be referencing a state-machine but contained within another namespace (although not typical).

No Data Available

You gave an example about the adornment of an association and its representation as a graph node. I thought this information can be deduced from the semantic relationship! Why do you need to explicitly represent it as a node?

No Data Available

Some properties like the diagram zoom level or viewport positions might not be suitable for a team environment, where each person could change them without having to share this preference with the rest of the team. By persisting these properties in the mode, team members would have to share these (not necessary the expectation). Alternatively, these properties could be part of the workspace preferences.

No Data Available

The semantic bridge contains either a single reference property or a simple string. Some views, however, need more semantic context than that. (eg: pattern instance views need two semantic references to represent the semantic context).

No Data Available

Regarding the cut-out diagram feature, I cannot see how the large diagram can layout out its referenced diagrams without explicitly store layout information. Is there any? This should be documented.

No Data Available

Rendering UML shapes is the responsibility of the tool. Therefore, there is no value in using Leaf Elements in the aggregation of UML views. If the intention of using them is notational (like whether attribute visibility should be textual or iconic) then a property is the better way to represent it.

No Data Available

The current title of the document reflects the original RFP but is far
too specific for the standard produced and unnecessarily limits how
people may think it can be applied.

Proposed resolution:
Rename the specification to OMG Diagram Interchange Specification

No Data Available

There is a need to uniquely assign one or more stereotype icons to a stereotype, when that stereotype is defined. It should be explained how this stereotype is displayed and how multiple stereotypes are handled.

No Data Available

Vendors usually add more features to UML diagrams which could require more features in the schema. Is it expected for these features to be omitted when exporting to DI? If no, then there has to be an agreement on those formats as well

No Data Available

The representation of properties as a collection of string key-value pairs means that non-string properties need to be encoded as strings. Can this present a limitation for more complex properties (references, maps, lists…etc)?

No Data Available

The property CoreSemanticModelBridge.element should reference the class
MOF::Object rather than Elements::Element. MOF::Object is the implicit
superclass of everything in UML2/MOF2.
Making this change allows diagram elements to refer to instances of any
metamodel: not just UML2.

No Data Available

SemanticModelBridge.element (actually realized on its subclasses
currently) has a multiplicity of 1.
There are several cases where one visual diagram element will represent
multiple elements in the metamodel (abstract syntax).
For example 'AssemblyConnector' which I think should be a single symbol
consisting of joined 'cup and ball' (see p148 of Superstructure
ptc/03-08-02).

Proposed resolution: change the multiplicity of
SemanticModelBridge.element from 1 to 1..*.

No Data Available

The current draft spec still refers to Rational Software in the front matter. Any references to this should be changed to IBM Rational Software

No Data Available