XMI 1.2 MAILINGLIST Avatar
  1. OMG Issue

XMI12 — bi-directional References and redundancy

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

    In addition to other anomalies with References, XMI's handling of
    bi-directional References puts redundant information into an XMI
    document. This redundancy adds unnecessary complexity for XMI
    document consumers.

    Discussion:

    For example, consider the following meta-model:

    package P {
    class C1

    { reference r1 to c2_end of A; }

    ;
    class C2

    { reference r2 to c1_end of A; }

    ;
    association A

    { end set [0..*] of C1 c1_end; end set [0..*] of C2 c2_end; }

    ;
    };

    An XMI document will represent a link between a C1 & C2 instance something
    like this:

    ...
    <P.C1 id="id1">
    <P1.C1.r1 idref="id2" />
    </P.C1>
    ...
    <P.C2 id="id2">
    <P1.C2.r2 idref="id1" />
    </P.C2>
    ...

    It may not be obvious, but when the References are bi-directional (i.e.
    on both ends of an Association), one of them is actually redundant.

    So what?

    The problem is that this introduces considerable complexity for an
    XMI document consumer, especially if the consumer is to protect itself
    against erroneous input.

    If the consumer assumes that the document is correct, it can statically
    choose to use either the "r1" or "r2" information to reconstruct the
    links. [The choice is more complex if the Association is ordered or one
    end is not Referenced.] Note that you can't simply create links for any
    References, since that will lead to duplicate links exceptions (or
    worse).

    The risk with this approach is that the consumer may lose information if
    the XMI document doesn't include elements for both References. For
    example, if the input document was produced by hand ...

    It is therefore better for the consumer not to assume that the document
    is correct. There are two options:

    1) Make sure that the "r1" and "r2" information is consistent. This
    is complex, and probably entails building in-memory copies of
    the links ... which may present scalability problems.

    2) Create links from the "r1" and "r2" information, catching and
    ignoring any duplicate link exceptions. This has a couple of
    problems:

    • If there are any inconsistencies, they won't be noticed.
    • It doesn't work for ordered Associations because if you
      add the link corresponding to a Reference that "refers to"
      the unordered end first, you will trash the ordering
      information.

    My preferred resolution to this issue would be to drop all XMI handling
    of References and represent the 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