Issue 17507: Surplus classifier field serialized in Superstructure.xmi (uml2-rtf) Source: No Magic, Inc. (Mr. Tomas Juknevicius, tomasjkn(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: I've encountered one slight problem in the superstructure XMI file of UML2.4.1 . I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here: http://www.omg.org/spec/UML/2.4.1/ On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.: > <ownedLiteral xmi:type="uml:EnumerationLiteral" > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered" > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind"> There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I think there will also be cases like this) Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and chapter 7.3.17 (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is not derived). Since derived fields are not usually serialized by XMI production rules (unless this is overridden, which seems not to be the case), I think these fields should be cleaned out. Resolution: Revised Text: Actions taken: July 19, 2012: received issue Discussion: End of Annotations:===== ted-NM: yes Date: Thu, 19 Jul 2012 13:32:07 +0300 From: Tomas Juknevicius User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: uml2-rtf@omg.org, issues@omg.org Subject: Surplus classifier field serialized in Superstructure.xmi X-Enigmail-Version: 1.4.3 Hello, I've encountered one slight problem in the superstructure XMI file of UML2.4.1 . I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here: http://www.omg.org/spec/UML/2.4.1/ On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.: > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered" > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind"> There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I think there will also be cases like this) Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and chapter 7.3.17 (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is not derived). Since derived fields are not usually serialized by XMI production rules (unless this is overridden, which seems not to be the case), I think these fields should be cleaned out. Sincerely, -- Tomas Juknevicius System Analyst No Magic Europe Savanoriu 363 - IV fl., LT-49425, Kaunas, Lithuania Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas.Juknevicius@nomagic.com WWW: http://www.magicdraw.com, http://www.nomagic.com Subject: RE: Surplus classifier field serialized in Superstructure.xmi Date: Thu, 19 Jul 2012 09:04:06 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Surplus classifier field serialized in Superstructure.xmi Thread-Index: Ac1lmdjL4ZAlRqU4Q4eP7Cez0pTQzwALTgdw From: "Pete Rivett" To: "Tomas Juknevicius" , Cc: See Ed's earlier response attached. Pete -----Original Message----- From: Tomas Juknevicius [mailto:tomasjkn@nomagic.com] Sent: Thursday, July 19, 2012 3:32 AM To: uml2-rtf@omg.org; issues@omg.org Subject: Surplus classifier field serialized in Superstructure.xmi Hello, I've encountered one slight problem in the superstructure XMI file of UML2.4.1 . I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here: http://www.omg.org/spec/UML/2.4.1/ On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.: > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered" > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind"> There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I think there will also be cases like this) Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and chapter 7.3.17 (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is not derived). Since derived fields are not usually serialized by XMI production rules (unless this is overridden, which seems not to be the case), I think these fields should be cleaned out. Sincerely, -- Tomas Juknevicius System Analyst No Magic Europe Savanoriu 363 - IV fl., LT-49425, Kaunas, Lithuania Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas.Juknevicius@nomagic.com WWW: http://www.magicdraw.com, http://www.nomagic.com X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from EXSMTPD001-1.DEX001.intermedia.net ([64.78.19.138]) by DHOST001-50.DEX001.intermedia.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 10:17:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from exmfd001-2.intermedia.net ([64.78.61.165]) by EXSMTPD001-1.DEX001.intermedia.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Oct 2011 10:17:52 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by exmfd001-2.intermedia.net (Postfix) with ESMTP id 3C91BDBC6 for ; Thu, 6 Oct 2011 10:17:25 -0700 (PDT) Received: from exmfd001-2.intermedia.net ([127.0.0.1]) by localhost (exmfd001-2.intermedia.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnC0nJ1fbjvL for ; Thu, 6 Oct 2011 10:17:21 -0700 (PDT) Received: from otransport.mailprotector.net (outbound98-1.mailprotector.net [66.45.16.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by exmfd001-2.intermedia.net (Postfix) with ESMTP id BEC86DAF4 for ; Thu, 6 Oct 2011 10:17:21 -0700 (PDT) Received: from ogate101.mailprotector.net (unknown [10.1.31.1]) by transport102.mailprotector.net (Postfix) with ESMTPS id A61FF2228FB; Thu, 6 Oct 2011 17:17:20 +0000 (UTC) Received: from outbound.mailprotector.net (unknown [10.1.50.225]) by ogate101.mailprotector.net (Postfix) with ESMTPS id 8C300200DD; Thu, 6 Oct 2011 13:17:20 -0400 (EDT) Received: from EXCH2K7CCR.VIRTUMEN.LOCAL ([10.1.50.227]) by VMDC1.VIRTUMEN.LOCAL ([10.1.50.225]) with mapi; Thu, 6 Oct 2011 13:17:20 -0400 Content-class: urn:content-classes:message Subject: RE: Issue on UML and MOF 2.4.1 XMI files Date: Thu, 6 Oct 2011 10:17:20 -0700 Message-ID: In-Reply-To: <674FC3679265A241ACB4BF58BA0EB3BE020F165E@DHOST001-50.DEX001.intermedia.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue on UML and MOF 2.4.1 XMI files Thread-Index: AcyERvGu9QMXIsfYQ4i68BH1icZDrQAAnr3g References: <674FC3679265A241ACB4BF58BA0EB3BE020F165E@DHOST001-50.DEX001.intermedia.net> From: "Ed Seidewitz" To: "Pete Rivett" , Cc: , , 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 X-Trusted-NM: yes Date: Fri, 20 Jul 2012 10:57:34 +0300 From: Tomas Juknevicius User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Juergen Boldt Subject: Re: Surplus classifier field serialized in Superstructure.xmi X-Enigmail-Version: 1.4.3 Hello Juergen, Tomas, should I file as an issue? I think - yes. This needs to be clarified one way or another - either classifier field should be removed from serialization, or there should be an explicit statement somewhere that this is an exception (preferably with reasoning - why). Sincerely, -- Tomas Juknevicius System Analyst No Magic Europe Savanoriu 363 - IV fl., LT-49425, Kaunas, Lithuania Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas.Juknevicius@nomagic.com WWW: http://www.magicdraw.com, http://www.nomagic.com On 2012-07-19 17:28, Juergen Boldt wrote: Tomas, should I file as an issue? -Juergen At 06:32 AM 7/19/2012, you wrote: Hello, I've encountered one slight problem in the superstructure XMI file of UML2.4.1 . I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here: http://www.omg.org/spec/UML/2.4.1/ On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.: > xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered" > classifier="Activities-CompleteActivities-ObjectNodeOrderingKind"> There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I think there will also be cases like this) Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and chapter 7.3.17 (EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is not derived). Since derived fields are not usually serialized by XMI production rules (unless this is overridden, which seems not to be the case), I think these fields should be cleaned out. Sincerely, -- Tomas Juknevicius System Analyst No Magic Europe Savanoriu 363 - IV fl., LT-49425, Kaunas, Lithuania Phone: +370-37-324032; Fax: +370-37-320670 e-mail: Tomas.Juknevicius@nomagic.com WWW: http://www.magicdraw.com, http://www.nomagic.com Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org