Issue 16585: EnumerationLiterals in the XMI (mof2core-rtf) Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com) Nature: Uncategorized Issue Severity: Summary: The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel. Even if not derived it would be the inverse of the owning composition so should not be serialized. Resolution: This issue is outdated. Disposition: Closed - No Change Revised Text: Actions taken: October 6, 2011: received issue September 13, 2012: moved to the MOF 2 Core RTF April 6, 2015: closed issue Discussion: End of Annotations:===== ubject: Issue on UML and MOF 2.4.1 XMI files Date: Thu, 6 Oct 2011 09:42:32 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue on UML and MOF 2.4.1 XMI files Thread-Index: AcyERvGu9QMXIsfYQ4i68BH1icZDrQ== From: "Pete Rivett" To: Cc: , , (I guess this needs to end up as 2 separate issues . one for each RTF) The EnumerationLiterals in the XMI include values for the .classifier. property which is redefined to be derived in the metamodel. Even if not derived it would be the inverse of the owning composition so should not be serialized. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: Ed Seidewitz To: Pete Rivett , "issues@omg.org" CC: "mof2core-rtf@omg.org" , "uml2-rtf@omg.org" , "kenn.hussey@gmail.com" Date: Thu, 6 Oct 2011 13:17:20 -0400 Subject: RE: Issue on UML and MOF 2.4.1 XMI files Thread-Topic: Issue on UML and MOF 2.4.1 XMI files Thread-Index: AcyERvGu9QMXIsfYQ4i68BH1icZDrQAAnr3g Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.225]|10.1.50.225|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.225, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-16280-c Pete . This issue sounds familiar. I think we addressed it before, and specifically decided that EnumerationLiteral::classifier should be serialized. The owning composition is the enumeration/ownedLiteral association. The classifier/enumerationLiteral association (which redefines classifier/instanceSpecification) is not a composition. It just so happens that the derivation of EnumerationLiteral::classifier (which was added in UML 2.4) simply requires that the classifier property of an EnumerationLiteral happens to be the same as its owning enumeration. Note that in MOF 2.0 EnumerationLiteral was not a subclass of InstanceSpecification, so this was not an issue so that simply was no classifier property of EnumerationLiterals to worry about. But, with the MOF 2.4 abstract syntax being a subset of UML 2.4, EnumerationLiterals in MOF are now the same as in UML and the classifier property should be serialized for them in metamodel XMI, as redundant as that is. (One of the downsides of making MOF 2.4 a subset of UML 2.4 is it picks up some of the oddities like this from the full UML metamodel.) -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, October 06, 2011 12:43 PM To: issues@omg.org Cc: mof2core-rtf@omg.org; uml2-rtf@omg.org; kenn.hussey@gmail.com Subject: Issue on UML and MOF 2.4.1 XMI files (I guess this needs to end up as 2 separate issues . one for each RTF) The EnumerationLiterals in the XMI include values for the .classifier. property which is redefined to be derived in the metamodel. Even if not derived it would be the inverse of the owning composition so should not be serialized. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dYUQkQgkxD1M2Cl5v3rz6JEoV1bqe96S/NOVB4SQ+eY=; b=iW1gshCPpqvqnOGNBvZN/7f/QStrs/8Gf/rqdsH0+OFSbSDCbF4ma7QB10M7FDDEv3 2HIsfsqt7089CvrGFeemu3R0qjlFNIjW6gQhIj4er1Mxof9cCvUOs/zusaNkEdO6oNvB RwWCjY54vQiabVZfbjEsn2BIGeU+TWiFm0xNs= Date: Fri, 14 Oct 2011 10:08:12 -0400 Subject: Re: Issue on UML and MOF 2.4.1 XMI files From: Kenn Hussey To: Ed Seidewitz Cc: Pete Rivett , "issues@omg.org" , "mof2core-rtf@omg.org" , "uml2-rtf@omg.org" Ed, But the EnumerationLiteral::classifier property is derived, so unless the org.omg.xmi.serialize tag has been attached to the property with a value of .true., it must not be serialized. Kenn On Thu, Oct 6, 2011 at 1:17 PM, Ed Seidewitz wrote: Pete . This issue sounds familiar. I think we addressed it before, and specifically decided that EnumerationLiteral::classifier should be serialized. The owning composition is the enumeration/ownedLiteral association. The classifier/enumerationLiteral association (which redefines classifier/instanceSpecification) is not a composition. It just so happens that the derivation of EnumerationLiteral::classifier (which was added in UML 2.4) simply requires that the classifier property of an EnumerationLiteral happens to be the same as its owning enumeration. Note that in MOF 2.0 EnumerationLiteral was not a subclass of InstanceSpecification, so this was not an issue so that simply was no classifier property of EnumerationLiterals to worry about. But, with the MOF 2.4 abstract syntax being a subset of UML 2.4, EnumerationLiterals in MOF are now the same as in UML and the classifier property should be serialized for them in metamodel XMI, as redundant as that is. (One of the downsides of making MOF 2.4 a subset of UML 2.4 is it picks up some of the oddities like this from the full UML metamodel.) -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, October 06, 2011 12:43 PM To: issues@omg.org Cc: mof2core-rtf@omg.org; uml2-rtf@omg.org; kenn.hussey@gmail.com Subject: Issue on UML and MOF 2.4.1 XMI files (I guess this needs to end up as 2 separate issues . one for each RTF) The EnumerationLiterals in the XMI include values for the .classifier. property which is redefined to be derived in the metamodel. Even if not derived it would be the inverse of the owning composition so should not be serialized. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: Ed Seidewitz To: Kenn Hussey CC: Pete Rivett , "issues@omg.org" , "mof2core-rtf@omg.org" , "uml2-rtf@omg.org" Date: Fri, 14 Oct 2011 10:18:03 -0400 Subject: RE: Issue on UML and MOF 2.4.1 XMI files Thread-Topic: Issue on UML and MOF 2.4.1 XMI files Thread-Index: AcyKesCsoe4F+yJMQ/Grks3IdeNLsAAAJWEg Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Mailprotector-Decision: deliver X-Mailprotector-Connection: TLSv1|[10.1.50.226]|10.1.50.226|outbound.mailprotector.net|0|0|0|new|ugly|0|0|0|0 X-Mailprotector-Results: null_ptr clean X-Mailprotector-Score: 40 X-Mailprotector-IP-Analysis: 0, 10.1.50.226, Ugly c=0 p=0 Source New X-Mailprotector-Scan-Diagnostics: 0-0-0-23663-c Kenn . Oh, yeah, you.re right! It should not be serialized because it is derived, not because it is the inverse of a composition association (which it isn.t). -- Ed -------------------------------------------------------------------------------- From: Kenn Hussey [mailto:kenn.hussey@gmail.com] Sent: Friday, October 14, 2011 10:08 AM To: Ed Seidewitz Cc: Pete Rivett; issues@omg.org; mof2core-rtf@omg.org; uml2-rtf@omg.org Subject: Re: Issue on UML and MOF 2.4.1 XMI files Ed, But the EnumerationLiteral::classifier property is derived, so unless the org.omg.xmi.serialize tag has been attached to the property with a value of .true., it must not be serialized. Kenn On Thu, Oct 6, 2011 at 1:17 PM, Ed Seidewitz wrote: Pete . This issue sounds familiar. I think we addressed it before, and specifically decided that EnumerationLiteral::classifier should be serialized. The owning composition is the enumeration/ownedLiteral association. The classifier/enumerationLiteral association (which redefines classifier/instanceSpecification) is not a composition. It just so happens that the derivation of EnumerationLiteral::classifier (which was added in UML 2.4) simply requires that the classifier property of an EnumerationLiteral happens to be the same as its owning enumeration. Note that in MOF 2.0 EnumerationLiteral was not a subclass of InstanceSpecification, so this was not an issue so that simply was no classifier property of EnumerationLiterals to worry about. But, with the MOF 2.4 abstract syntax being a subset of UML 2.4, EnumerationLiterals in MOF are now the same as in UML and the classifier property should be serialized for them in metamodel XMI, as redundant as that is. (One of the downsides of making MOF 2.4 a subset of UML 2.4 is it picks up some of the oddities like this from the full UML metamodel.) -- Ed -------------------------------------------------------------------------------- From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: Thursday, October 06, 2011 12:43 PM To: issues@omg.org Cc: mof2core-rtf@omg.org; uml2-rtf@omg.org; kenn.hussey@gmail.com Subject: Issue on UML and MOF 2.4.1 XMI files (I guess this needs to end up as 2 separate issues . one for each RTF) The EnumerationLiterals in the XMI include values for the .classifier. property which is redefined to be derived in the metamodel. Even if not derived it would be the inverse of the owning composition so should not be serialized. -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp