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