XMI12 — bi-directional References and redundancy

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

;
class C2

;
association A

;
};

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.