XML Metadata Interchange Avatar
  1. OMG Specification

XML Metadata Interchange — Closed Issues

  • Acronym: XMI
  • Issues Count: 26
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
XMI11-99 MOF and UML DTDs XMI 1.0 XMI 1.1 Resolved closed
XMI11-98 Reference to ""restrictions"" is unclear." XMI 1.0 XMI 1.1 Resolved closed
XMI11-94 Multiple Inheritance hard to handle in XMI XMI 1.0 XMI 1.1 Resolved closed
XMI11-97 . XMI has specific rules for attribute ordering. Can this be relaxed? XMI 1.0 XMI 1.1 Resolved closed
XMI11-96 Is it valid to use alternative DTD generation rules? XMI 1.0 XMI 1.1 Resolved closed
XMI11-95 How should null values be transmitted XMI 1.0 XMI 1.1 Resolved closed
UML25-629 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-620 15.3.14 Transition (from BehaviorStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML14-30 Inheritance violation in "Auxiliary Elements" XMI 1.0 UML 1.4.2 Resolved closed
UML14-33 class EnumerationLiteral issue XMI 1.0 UML 1.4.2 Resolved closed
UML14-31 Incomplete Inheritance Specification XMI 1.0 UML 1.4.2 Resolved closed
UML14-32 Datatypes: Expression XMI 1.0 UML 1.4.2 Resolved closed
UML14-34 Interfaces on Nodes XMI 1.0 UML 1.4.2 Resolved closed
UML14-17 Parametrizable model elements not shown XMI 1.0 UML 1.4.2 Resolved closed
UML14-19 Guard in current metamodel can be replaced by Constraint with stereotype XMI 1.0 UML 1.4.2 Resolved closed
UML14-18 Need for notation for dealing with evolution of UML models XMI 1.0 UML 1.4.2 Resolved closed
UML14-25 Missing OCL XMI 1.0 UML 1.4.2 Resolved closed
UML14-24 OCL needs to be added XMI 1.0 UML 1.4.2 Resolved closed
UML14-26 ElementOwnership XMI 1.0 UML 1.4.2 Resolved closed
UML14-28 extension to the notation for a transition XMI 1.0 UML 1.4.2 Resolved closed
UML14-23 Page 19 semantic doc. name XMI 1.0 UML 1.4.2 Resolved closed
UML14-22 UML 1.1.section 4.2:editorial XMI 1.0 UML 1.4.2 Resolved closed
UML14-27 User-defined symbols for tagged values and properties XMI 1.0 UML 1.4.2 Resolved closed
UML14-29 Associate a predicate with a state XMI 1.0 UML 1.4.2 Resolved closed
UML14-21 Figure 7 p. 43 of the UML semantics guide XMI 1.0 UML 1.4.2 Resolved closed
UML14-20 AssociationEnd needs ownerScope XMI 1.0 UML 1.4.2 Resolved closed

Issues Descriptions

MOF and UML DTDs

  • Key: XMI11-99
  • Legacy Issue Number: 4393
  • Status: closed  
  • Source: International Business Machines ( Mr. Tim Grose)
  • Summary:

    I propose that the XMI RTF not regenerate UML and MOF DTDs, for the
    following reasons:

    1) UML 1.1 and MOF 1.1 are now out of date.
    2) Both the UML RTF and the MOF RTF are now creating their own DTDs, so it
    is not appropriate for the XMI RTF to continue to create them.

  • Reported: XMI 1.0 — Tue, 3 Jul 2001 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 19:58 GMT

Reference to ""restrictions"" is unclear."

  • Key: XMI11-98
  • Legacy Issue Number: 3828
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The second and third paragraphs in 6.6.1 define exactly how to use Namespaces in XMI DTDs and serve as both the restriction and the solution. Accept. Clarify to indicate that the following text is the definition of the restriction.

  • Reported: XMI 1.0 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    Accept. Clarify to indicate that the following text is the definition of the restriction.

  • Updated: Sat, 7 Mar 2015 19:58 GMT

Multiple Inheritance hard to handle in XMI

  • Key: XMI11-94
  • Legacy Issue Number: 2854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: THe background it is the use of XMI for interchange of warehouse
    information. The person prototyping
    the exchange is Brain Volpi so if you have follow on questions, please
    copy him since I am on vacation for the next two weeks.

    1. We are using UML to define the meta models and the created the DTD"s
    and document streams.

    • our model contains multiple inheritance which is hard to handle
      in XMI. Does anyone have any
      comments or suggestion on the mapping to XMI we should consider.
    • our model contains UML interface definitions which we have mapped
      into abstract classes
      any comments on a better way to do this?
    • UML has ordered associations and we are currently assuming the
      XMI stream will always be
      in the correct order. Is this valid?
  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

  • Updated: Fri, 6 Mar 2015 20:59 GMT

. XMI has specific rules for attribute ordering. Can this be relaxed?

  • Key: XMI11-97
  • Legacy Issue Number: 2857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4. XMI has specific rules for attribute ordering. Can this be relaxed?

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Is it valid to use alternative DTD generation rules?

  • Key: XMI11-96
  • Legacy Issue Number: 2856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3. XMI uses containment rules to drive the document generation process.
    Is it valid to use alternative
    DTD generation rules that allow for reference semantics where we can
    use bi-directional references
    instead of the single direction references you are limited to with
    containment. We need roles at both
    ends.

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

  • Updated: Fri, 6 Mar 2015 20:59 GMT

How should null values be transmitted

  • Key: XMI11-95
  • Legacy Issue Number: 2855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2. How should null values be transmitted. Currently we don"t transmit
    them. This is really the issue of
    partial models versus null values that Steve raised in the original
    submission discussions.

  • Reported: XMI 1.0 — Fri, 20 Aug 1999 04:00 GMT
  • Disposition: Resolved — XMI 1.1
  • Disposition Summary:

    resolved in XMI 1.1 RTF

  • Updated: Fri, 6 Mar 2015 20:59 GMT

15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)

  • Key: UML25-629
  • Legacy Issue Number: 7862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Attributes:

    /isComposite

    /isSimple

    /isSubmachineState

    defined without a type ( it must be Boolean).

    2. Associations:

    redefinedState : State [0..1]

    Must be subsets RedefinableElement::redefinedElement.

    3.

    region : Region [*] – subsets ownedMember

    Must be “subsets Namespace::ownedMember”.

    4.

    /redefinitionContext : Classifier [1]

    This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

    5.

    region : Region [0..1]

    Second member named ‘region’ with another multiplicity and different semantic.

    6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

  • Reported: XMI 1.0 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

15.3.14 Transition (from BehaviorStateMachines)

  • Key: UML25-620
  • Legacy Issue Number: 7864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (different multiplicity).

    2.

    container [1]

    Defined without type (but (wonder?) with multiplicity!). J

    3.

    Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

    But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

  • Reported: XMI 1.0 — Tue, 7 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inheritance violation in "Auxiliary Elements"

  • Key: UML14-30
  • Legacy Issue Number: 2361
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: UML Semantics 1.1, Sep. 1997 and UML Semantics 1.3 Beta, Jan
    1999 and the associated Rational Rose model files

    Specification section reference: UML Semantics 1.1 Part 2, Section 4.3
    Well-formedness rules, pp.32 and UML Semantics 1.3, Part 2, Section
    2.5.3, pp.2-49

    Nature: Clarification

    Severity: Medium
    Summary: In the 1.1 model file, there is an inheritance relationship
    between
    "Presentation" (in "Auxiliary Element") and "Element" (in "Core").
    "Presentation" is an association class and "Element" is a normal class.
    The two types are not the same, this this brings up the following
    constraint in the semantic document:

    self.subtype.oclType = self.supertype.oclType

    Question:
    1) Is "Presentation" suppose to inherit from "Element"? The other
    association classes "ElementOwnership" and "ElementReference" do no
    appear to do so.

    2) If the answer to (1) is yes, then isn"t it a violation of the UML
    semantics" well-formedness rule.

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

class EnumerationLiteral issue

  • Key: UML14-33
  • Legacy Issue Number: 2582
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think that the class EnumerationLiteral should be an heir of DataValue
    (this inheritance relationship is currently missing).

    Once this is fixed, the association between EnumerationLiteral and Enumeration
    should be seen as a refinement of the association between DataValue and DataType
    (itself implicitly inherited from the association between Instance and classifier),
    with a supplementary OCL constraint in the case of EnumerationLiteral,
    namely that self.classifier.oclIsKindOf(Enumeration)
    (to ensure covariance, as is done for DataValue wrt DataType).

    BTW, shouldn"t there be a symetric OCL constraint in DataType
    specifying that its Instances are all DataValues,
    and similarly in Enumeration specifying that its instances are all EnumerationLiterals ?

  • Reported: XMI 1.0 — Mon, 12 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incomplete Inheritance Specification

  • Key: UML14-31
  • Legacy Issue Number: 2362
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Source: HO Wai-Ming, PhD research Student, IRISA, France

    Reference: Rational Rose model files for UML 1.1 and UML 1.3 beta

    Specification section reference: None

    Nature: Clarification

    Severity: Minor

    Summary: There is an oddity in the inheritance relationship of
    "Classifier" in "Core". Is "Classifier" suppose to inherit from
    "Taxon-Datatype", but the specification is incomplete. Rational Rose
    and Rose98 raises an error for this association during a "Check Model".

  • Reported: XMI 1.0 — Mon, 1 Feb 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Datatypes: Expression

  • Key: UML14-32
  • Legacy Issue Number: 2541
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: the metaclass Expression includes an attribute called "language" of type
    Name. To enable tools to check OCL expressions, it is neccesary to
    define a standard value for this attribute, which denotes the fact that the
    expressions is an OCL expression.
    Without such a standard defined value tools cannot distinguish OCL
    expresions and cannot interpret them (for purposes of typechecking,
    code generation, etc....)

    I propose to add the value "OCL" as a standard value for the attribute
    "language" of metaclass "Expression" to the chapter on datatypes.

  • Reported: XMI 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interfaces on Nodes

  • Key: UML14-34
  • Legacy Issue Number: 2613
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In looking through the UML 1.3 alpha R2 documentation set, I cannot
    determine if interfaces are allowed on Nodes. Since a Node is a kind
    of classifier, it seems possible that a Node can realize an interface.
    However, since this relationship is not explicitly mentioned as allowed
    or not, I am unclear as to the intention.

  • Reported: XMI 1.0 — Mon, 19 Apr 1999 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Parametrizable model elements not shown

  • Key: UML14-17
  • Legacy Issue Number: 1209
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Notation 5.11.1 pg. 39 says "Parametrisation can be applied to other
    ModelElements". Implicitly not to all ModelElements. Which ModelElements
    can
    and which cannot be templates?
    Some clarifications would be welcome, in what concerns the
    parametrisation of other kind of model elements, such as packages,
    operations and methods.

  • Reported: XMI 1.0 — Thu, 23 Apr 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Guard in current metamodel can be replaced by Constraint with stereotype

  • Key: UML14-19
  • Legacy Issue Number: 2020
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Guard metatype in the current metamodel contains only one attribute
    of type BooleanExpression. Since a guard is semantically equivalent to
    a Constraint on the transition, we can remove the Guard metaclass and
    add e standard stereotype <<guard>> for Constraints, with the same
    semantics.

    It simplifies the metamodel by unifying the Guard and Constraint concepts.
    It also allows OCL as the optional language to write the guard expression.

    Within the OCL specification, it should be checked if there are any
    additions that need to be made to support everything neded to express
    udseful guards.

  • Reported: XMI 1.0 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for notation for dealing with evolution of UML models

  • Key: UML14-18
  • Legacy Issue Number: 1512
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a need for a notation for dealing with evolution of UML models. Currently, UML does not provide adequate support for dealing with evolution of software components in a disciplined way. With disciplined evolution we mean that there should be a general mechanism to express how a modelling element evolves over time by adding, removing or changing parts of it. In the current version of UML, 2 mechanisms could be used to describe the evolution process, but they both have their shortcomings:

  • Reported: XMI 1.0 — Mon, 8 Jun 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing OCL

  • Key: UML14-25
  • Legacy Issue Number: 2289
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to note that in the UML Semantics specification (versions 1.1
    and 1.2) the third well-formedness rule for Association does not have an
    OCL expression. It has only the natural language expression.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OCL needs to be added

  • Key: UML14-24
  • Legacy Issue Number: 2278
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Only binary associations may be aggregates. There needs to
    be OCL added to do this.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    Add the missing OCL

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ElementOwnership

  • Key: UML14-26
  • Legacy Issue Number: 2290
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In UML versions 1.1, 1.2, and 1.3 the class diagram for the Core Backbone
    declares ElementOwnership as an AssociationClass. This appears to be a
    violation of MOF compliance, since the MOF meta-meta-model does not support
    the notion of an AssociationClass.

    Of course one could extrapolate AssociationClass from the MOF
    meta-meta-model since it does support both Association and Class, and one
    could also logically extrapolate a MOF-IDL and MOF-XML mapping for an
    extrapolated MOF AssociationClass. However, two architects might
    extrapolate these mappings in perfectly valid but different manners, since
    there is no standard mapping for a MOF AssociationClass. Apparently such
    an extrapolation has been performed in order to derive the IDL for the UML
    meta-model that concerns ElementOwnership, but doing this without a
    standard mapping seems dangerous.

  • Reported: XMI 1.0 — Tue, 5 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

extension to the notation for a transition

  • Key: UML14-28
  • Legacy Issue Number: 2336
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to make an appeal for an extension to the notation for a transition
    to allow its effect to be specified declaratively rather than only imperatively by
    means of an action sequence, e.g.

    e() / [p]

    While I realize there are ways to work around this (e.g. by writing "e() / pTrue()"
    where the query pTrue() has the postcondition "result = p and in targetState"), I
    think the issues are readability and ease of use.

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 19 semantic doc. name

  • Key: UML14-23
  • Legacy Issue Number: 2277
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Page 19 semantic doc. name is described here but is not shown as
    a metalevel attribute on Figure 6. It should be.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 1.1.section 4.2:editorial

  • Key: UML14-22
  • Legacy Issue Number: 2276
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Aggregation: "when on target end, specifies whether target end
    with respect to source end". I think target and source are the wrong
    way round here.

  • Reported: XMI 1.0 — Tue, 22 Dec 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

User-defined symbols for tagged values and properties

  • Key: UML14-27
  • Legacy Issue Number: 2291
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: UML allows users to define specific symbols and icons for stereotypes. It should also be allowed to define specific symbols and icons for tagged values and properties. For example, users that often use the properties

    {ordered}

    ,

    {frozen}

    and

    {add only}

    may define they own user-defined icons for those properties, because UML does not define them.

    Suggested Solution:
    UML users should be allowed to define specific symbols and icons for tagged values and properties.

  • Reported: XMI 1.0 — Wed, 6 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Associate a predicate with a state

  • Key: UML14-29
  • Legacy Issue Number: 2337
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Related to the previously submitted issue regarding the declarative specification of
    the effects of transitions, I would like to suggest that it be possible to associate
    a predicate with a state.

    Such a predicate (e.g. written in OCL) would appear within the state box in the
    notation, just below the name of the state.

    Rather than extend the notation directly, I suggest this be a predefined property,
    e.g.

    {predicate = boolean-expression}

    .

  • Reported: XMI 1.0 — Fri, 22 Jan 1999 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 7 p. 43 of the UML semantics guide

  • Key: UML14-21
  • Legacy Issue Number: 2208
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: On Figure 7 p. 43 of the UML semantics guide,
    Template is described as a shared aggregate of its templateParameters,
    while Binding (representing an instantiation of a Template) is described
    as a composite aggregate of the actual arguments.

  • Reported: XMI 1.0 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AssociationEnd needs ownerScope

  • Key: UML14-20
  • Legacy Issue Number: 2083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I believe AssociationEnd needs an ownerScope attribute. How else could one
    model a static (as in Java) relationship? Currently, it appears to only be
    possible using an Attribute of Classifier.

  • Reported: XMI 1.0 — Thu, 15 Oct 1998 04:00 GMT
  • Disposition: Resolved — UML 1.4.2
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT