UML22 — Regression in XMI from UML 2.1.2 to UML 2.2

At 03:12 PM 8/13/2008, Pete Rivett wrote:

Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all!
Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs.
The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable.

In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP.

>From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant.

Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this.

Pete

From: Nicolas Rouquette [ nicolas.rouquette@jpl.nasa.gov]
Sent: 13 August 2008 19:15
To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor
Subject: unalabelled association-owned memberEnd property names affect the name of an association

I noticed strange differences between the XMI serialization of the UML superstructure in:

UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof
UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12

For example, in UML 2.1.2, we have:

<ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction">
<ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
</ownedMember>

whereas in UML 2.2beta1, we have:

<ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0">
<ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
</ownedMember>

In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec.

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 – i.e., the name of the class with a lowercase initial.

Is it OK for association names to change in this manner from one rev to another or is this a bug?

Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes.

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