UML Diagram Interchange Avatar
  1. OMG Specification

UML Diagram Interchange — Open Issues

  • Acronym: UMLDI
  • Issues Count: 10
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Section: 8.5 Properties

  • Key: UMLDI-30
  • Legacy Issue Number: 8179
  • Status: open  
  • Source: Gentleware AG ( Stefan Mueller)
  • Summary:

    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'

  • Reported: UMLDI 1.0 — Mon, 31 Jan 2005 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:48 GMT

Invalid "diagram-interchange.xml" file in DI 2.0 's ptc/05-06-07 zip file

  • Key: UMLDI-28
  • Legacy Issue Number: 10660
  • Status: open  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Fri, 9 Feb 2007 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Section: Annex C

  • Key: UMLDI-27
  • Legacy Issue Number: 10499
  • Status: open  
  • Source: PCMS ( Russell Block)
  • Summary:

    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 '<'.

  • Reported: UMLDI 1.0b1 — Sat, 2 Dec 2006 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

di-schema.xsd

  • Key: UMLDI-29
  • Legacy Issue Number: 13533
  • Status: open  
  • Source: NHS ( Ravi Natarajan)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Fri, 20 Feb 2009 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Diagram Interchange clarification

  • Key: UMLDI-26
  • Legacy Issue Number: 8971
  • Status: open  
  • Source: gmx.de ( Ludger Goeke)
  • Summary:

    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 ?

    ______________________________________

     
    myPart : myPartType [1..*]
    _____________________________________
  • Reported: UMLDI 1.0b1 — Fri, 19 Aug 2005 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML Mapping in DI specification inadequate

  • Key: UMLDI-25
  • Legacy Issue Number: 7663
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    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.
  • Reported: UMLDI 1.0b1 — Wed, 25 Aug 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: list updating and nested graph nodes

  • Key: UMLDI-24
  • Legacy Issue Number: 7271
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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?

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: size of graph node with autosize

  • Key: UMLDI-23
  • Legacy Issue Number: 7270
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

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

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: use of bounds limiting

  • Key: UMLDI-22
  • Legacy Issue Number: 7269
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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).

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

UML diagram interchange: schema usage needed

  • Key: UMLDI-21
  • Legacy Issue Number: 7259
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    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.

  • Reported: UMLDI 1.0b1 — Thu, 22 Apr 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT