XMI 1.2 MAILINGLIST Avatar
  1. OMG Issue

XMI12 — Anomalies with References and ordered Associations.

  • Key: XMI12-48
  • Legacy Issue Number: 4067
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In trying to implement a consumers for ordered Associations, I've
    come across the following anomalies caused by References.

    Consider the following metamodel:

    package P {
    class C1

    { reference r1 to a1_e2 of A1; }

    ;

    class C2

    { reference r2 to a2_e1 of A2; reference r3 to a1_e1 of A1; }

    ;

    association A1

    { end set [0..*] of C1 a1_e1; end ordered set [0..*] of C2 a1_e2; }

    association A2

    { end set [0..*] of C1 a2_e1; end ordered set [0..*] of C2 a2_e2; }

    The first anomaly is with the "r2" Reference. Since this "refers to"
    the unordered end of an Association, the "value" of the Reference does
    not contain any ordering information. But, since the Association has a
    Reference, the links for the Association won't be output in an
    <association-name> element. In other words, the ordering information
    for the Association links will be lost. This is a serious problem. [For
    the record, there is nothing "wrong" with the meta-model either IMO]

    The second anomaly (or maybe it's just a "feature" ...) is with the
    References "r1" and "r3". The problem is that while the xmi entities
    generated for the "r1" Reference can be converted into links, this is
    not true for the reverse "r3" References. Clearly, if I try to use
    "add_links" on a C2 instance to set the "r3" Reference values, it is
    next to impossible to get the ordering of the A1 links correct. This
    makes the "r3" References next to useless ... as well as their being
    redundant.

    My preferred resolution to this issue would be to simply remove all
    handling of References from XMI, and represent all links in the
    <association-name> element.

  • Reported: XMI 1.1 — Tue, 21 Nov 2000 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:12 GMT