Issue 18912: Inconsistent multiple inheritance (qvt-rtf) Source: Model Driven Solutions (Dr. Edward Willink, ed(at)willink.me.uk) Nature: Clarification Severity: Minor Summary: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Resolution: Inconsistent multiple inheritance The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Discussion Transformation is mostly a Class that may have arbitrary Package scoping. This has been successfully prototyped by the Eclipse QVT projects, but not in sufficient detail to justify this slightly breaking change. Revised Text: Actions taken: September 16, 2013: received issue December 22, 2015: Deferred March 29, 2016: closed issue Discussion: A quick experiment suggests that Class features are important but Package features are incidental, so making Transformation extend just Class and requiring a containing Package to provide context could be a good solution. Further investigation is required. (Similar problem for FunctionParameter). Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. From: "Rouquette, Nicolas F (313K)" To: "qvt-rtf@omg.org" Subject: Re: issue 18912 -- MOF QVT RTF issue Thread-Topic: issue 18912 -- MOF QVT RTF issue Thread-Index: AQHOsu1Ucc8uy4LCaUuJMCDe2Bebo5nIgEeA Date: Mon, 16 Sep 2013 15:40:28 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=AI/KmLLA c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=vdU9TLi9Zi3z9FKdOj8A:9 a=Bg7v1thUrTYTmG4s:21 a=COmT0i1S8oeOJJsu:21 a=e2qTBjMJMZnEijxt:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Mon, 16 Sep 2013 17:06:10 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAB43AD//56PAA== Date: Mon, 16 Sep 2013 18:11:58 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, Ah, sorry, I misunderstood your original question. For Transformation defined as a specialization of UML::Package and UML::Class, then: Transformation::package corresponds to property UML::Type::package : UML::Package {subsets A_packagedElement_owningPackage::owningPackage } So, for P, a UML::Package and P::T a Transformation, then P::T.package = P So, there's no problem at all. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 10:00 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas You miss my point. I don't doubt that it is convenient for a Transformation to be both a Class and a Package; I question whether it is legal. (If illegal, we can then consider how the necessary required behaviours can be re-established perhaps by single inheritance and composition). My original report was that P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) implies double containment. More specifically the point you have not addressed is: What is the value returned by Transformation.package? Regards Ed Willink On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=AI/KmLLA c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=lSBEFZh6NCOm8kBl6cUA:9 a=egC4xz2RVapE_lGO:21 a=63z7TmwPsyLTug9o:21 a=LBl-KSup3cpvEVlX:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Mon, 16 Sep 2013 19:55:36 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi OK, this problem will go away once QVT is defined using UML models. Currently QVT uses EMOF/Ecore that cannot handle the dual containment. Regards Ed On 16/09/2013 19:11, Rouquette, Nicolas F (313K) wrote: Ed, Ah, sorry, I misunderstood your original question. For Transformation defined as a specialization of UML::Package and UML::Class, then: Transformation::package corresponds to property UML::Type::package : UML::Package {subsets A_packagedElement_owningPackage::owningPackage } So, for P, a UML::Package and P::T a Transformation, then P::T.package = P So, there's no problem at all. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 10:00 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas You miss my point. I don't doubt that it is convenient for a Transformation to be both a Class and a Package; I question whether it is legal. (If illegal, we can then consider how the necessary required behaviours can be re-established perhaps by single inheritance and composition). My original report was that P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) implies double containment. More specifically the point you have not addressed is: What is the value returned by Transformation.package? Regards Ed Willink On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyA Date: Mon, 16 Sep 2013 16:48:09 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=AI/KmLLA c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=1eZCo3kk5dZeQLg7zawA:9 a=X0HDcb7i6cm4Z-U1:21 a=VqhiW-O6-T_JatuA:21 a=yxbQe0g-OVSlbytX:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Mon, 16 Sep 2013 18:00:42 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas You miss my point. I don't doubt that it is convenient for a Transformation to be both a Class and a Package; I question whether it is legal. (If illegal, we can then consider how the necessary required behaviours can be re-established perhaps by single inheritance and composition). My original report was that P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) implies double containment. More specifically the point you have not addressed is: What is the value returned by Transformation.package? Regards Ed Willink On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAB43AD//56PAIAAgYwA//+bGQA= Date: Mon, 16 Sep 2013 19:54:29 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, There are two problems here: 1) the OMG has not adequately specified the relationship between a model as an instance of a metamodel. Currently, most tools expect a metamodel to be self-contained . e.g., UML. That is, one can instantiate a single metaclass or association defined in the metamodel. Metaclasses or associations that have no common specialization become effectively disjoint . e.g., UML::Package and UML::Class are disjoint for the purposes of creating a model that is an instance of the UML metamodel. 2) The OMG has not adequately specified the semantics of instantiating a metamodel in terms of the construction of that metamodel. Defining the QVT metamodel as an extension of the UML metamodel makes sense; however, this leads to a problem with the under-specified semantics of metamodel instantiation. In this case: - UML::Package and UML::Class are disjoint metaclasses for models created as an instance of the UML metamodel, most tools effectively - UML::Package and UML::Class are not disjoint metaclasses for models created as an instance of the QVT metamodel since QVT::Transformation is defined as a specialization of both UML::Package and UML::Class Currently, the only practical workaround to these two OMG metamodeling semantic deficiencies . I.e., (1) and (2) -- that I know of is to use the OMG-unpopular PackageMerge mechanism. PackageMerge is conceptually a simple additive transformation. It should be specified in QVT. The result of applying PackageMerge to the QVT metamodel should be a merged QVT metamodel that contains: QVT-merged::Transformation (specializes both QVT-merged::Package and QVT-merged::Class) QVT-merged::Package QVT-merged::Class Then, there's no problem at all: one can instantiate QVT-merged::Transformation and it has a single owner, a QVT-merged::Package or QVT-merged::Transformation. So, for implementing QVT at Eclipse, I'd recommend applying the Eclipse UML PackageMerge utility to the QVT metamodel and implement the QVT-merged resulting metamodel. This is roughly what the http://www.eclipse.org/QVT/1.0.0/Operational model does; I.e., Module (see QVT 8.2.1.3) specializes both Ecore::Eclass and Ecore::Epackage (where Ecore is used as an approximation of OMG's EMOF metamodel) Nicolas. From: Ed Willink Date: Monday, September 16, 2013 11:55 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi OK, this problem will go away once QVT is defined using UML models. Currently QVT uses EMOF/Ecore that cannot handle the dual containment. Regards Ed On 16/09/2013 19:11, Rouquette, Nicolas F (313K) wrote: Ed, Ah, sorry, I misunderstood your original question. For Transformation defined as a specialization of UML::Package and UML::Class, then: Transformation::package corresponds to property UML::Type::package : UML::Package {subsets A_packagedElement_owningPackage::owningPackage } So, for P, a UML::Package and P::T a Transformation, then P::T.package = P So, there's no problem at all. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 10:00 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas You miss my point. I don't doubt that it is convenient for a Transformation to be both a Class and a Package; I question whether it is legal. (If illegal, we can then consider how the necessary required behaviours can be re-established perhaps by single inheritance and composition). My original report was that P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) implies double containment. More specifically the point you have not addressed is: What is the value returned by Transformation.package? Regards Ed Willink On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=AI/KmLLA c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=Vh5aTg8E9OrShayHbqgA:9 a=RQSN4DpT-0wLjget:21 a=cA3v5vhma2yHvdxN:21 a=vxcuon4CP54GdomH:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Mon, 16 Sep 2013 21:33:20 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas I can't see anything in your references that actually requires a Transformation to be both Package and Class. The requirement is that a Transformation - has hierarchical structure - is instantiable - has operations - has properties - has types This could be satisfied by a Transformation that extends Package with additional ownedOperations and ownedAttributes. Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpfule. Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. Once the Transformation WFRs are written, I suspect that the dual inheritance will require a significant amount of unwriting of Class/Package. Regards Ed On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgA== Date: Tue, 17 Sep 2013 04:23:31 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Now you're the one who is not answering my question. How are you defining the QVT metamodel with Transformation? In particular, is QVT::Transformation inheriting from UML::Package and UML::Class, just UML::Package, just UML::Class or something else? Are you merging the QVT metamodel at all or are you keeping the Qvt metamodel separate from the metamodel that defines UML::Package and UML::Class? The problems you're having with EMOF may have more to do with the particular construction of the QVT metamodel than the fact that Transformation inherits from both UML::Package and UML::Class. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 1:33 PM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas I can't see anything in your references that actually requires a Transformation to be both Package and Class. The requirement is that a Transformation - has hierarchical structure - is instantiable - has operations - has properties - has types This could be satisfied by a Transformation that extends Package with additional ownedOperations and ownedAttributes. Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpfule. Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. Once the Transformation WFRs are written, I suspect that the dual inheritance will require a significant amount of unwriting of Class/Package. Regards Ed On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=AI/KmLLA c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=ir_JIM_0MulA8P6sF_gA:9 a=XSsD9DSzMqHtLDV9:21 a=-hsrRPdrZ029K8bp:21 a=L7EmrDnX7PHXOoqD:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Tue, 17 Sep 2013 10:04:06 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas We may be at cross-purposes here because my discussion is about Transformation which is an issue for QVTc and QVTr. You have been discussing quite possibly the same issue for QVTo whereby OperationalTransformation extends Module which extends Package and Class. You know much more about QVTo than me; my knowledge and this discussion is on QVTr and QVTc. Will you be in New Brunswick/Miami? ------- I was using the direct Ecore 'merge' whereby genmodel provides a realization of multiple inheritance in which there is a fully inherited implementation of the first superclass (Package) and stubs of secondary superclasses (Class). (The QVT 1.1 Ecore/EMOF are the models I produced to resolve the large number of XMI/Ecore/Text/Picture contradictions in QVT 1.0). I'm now using a very similar Ecore 'merge' of Pivot::Package and Package::Class. It was my bad manual implementation of the Class::getPackage() stub that caused the problem and consequently the consideration of validity. ------- Changing Transformation::getPackage() to return "getNestingPackage()" rather than "this" solves the containment loop but gives a different surprise that a 'Type' may have no containing 'Package'. ------- You say that UML provides execution semantics that doesn't need duplicating. What/where? The semantics of a transformation is what QVT is all about. I see no signs of reuse of Behavior or Action from UML. For QVTo, a UML Operation has to be refined to support a "this" Transformation context rather than a "self" Type context. In QVTbase this change is reflected in the use of Function rather than Operation although the subtleties of extension from Operation remain obscure. Perhaps QVTbase should also specify a "this". A Transformation has many things that need defining; not least of which is transformation extension and its relationship (if any) to the inherited Class superclass semantics. Mappings are where the real 'action' is and UML does not help much here. Regards Ed Willink On 17/09/2013 05:23, Rouquette, Nicolas F (313K) wrote: Ed, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Now you're the one who is not answering my question. How are you defining the QVT metamodel with Transformation? In particular, is QVT::Transformation inheriting from UML::Package and UML::Class, just UML::Package, just UML::Class or something else? Are you merging the QVT metamodel at all or are you keeping the Qvt metamodel separate from the metamodel that defines UML::Package and UML::Class? The problems you're having with EMOF may have more to do with the particular construction of the QVT metamodel than the fact that Transformation inherits from both UML::Package and UML::Class. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 1:33 PM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas I can't see anything in your references that actually requires a Transformation to be both Package and Class. The requirement is that a Transformation - has hierarchical structure - is instantiable - has operations - has properties - has types This could be satisfied by a Transformation that extends Package with additional ownedOperations and ownedAttributes. Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpfule. Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. Once the Transformation WFRs are written, I suspect that the dual inheritance will require a significant amount of unwriting of Class/Package. Regards Ed On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIAAw8AA///k9wA= Date: Tue, 17 Sep 2013 14:27:21 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Ed, Transformation in QVTBase (Figure 7.4) and Module in QVTOperational (Figure 8.1) both inherit from Class and Package. I suspect that this issue affect both QVTr and QVTo. Yes, I'll be in New Brunswick. If you're there, it would be useful to have a QVT 1.2 RTF meeting, even if informal. - Nicolas. From: Ed Willink Date: Tuesday, September 17, 2013 2:04 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas We may be at cross-purposes here because my discussion is about Transformation which is an issue for QVTc and QVTr. You have been discussing quite possibly the same issue for QVTo whereby OperationalTransformation extends Module which extends Package and Class. You know much more about QVTo than me; my knowledge and this discussion is on QVTr and QVTc. Will you be in New Brunswick/Miami? ------- I was using the direct Ecore 'merge' whereby genmodel provides a realization of multiple inheritance in which there is a fully inherited implementation of the first superclass (Package) and stubs of secondary superclasses (Class). (The QVT 1.1 Ecore/EMOF are the models I produced to resolve the large number of XMI/Ecore/Text/Picture contradictions in QVT 1.0). I'm now using a very similar Ecore 'merge' of Pivot::Package and Package::Class. It was my bad manual implementation of the Class::getPackage() stub that caused the problem and consequently the consideration of validity. ------- Changing Transformation::getPackage() to return "getNestingPackage()" rather than "this" solves the containment loop but gives a different surprise that a 'Type' may have no containing 'Package'. ------- You say that UML provides execution semantics that doesn't need duplicating. What/where? The semantics of a transformation is what QVT is all about. I see no signs of reuse of Behavior or Action from UML. For QVTo, a UML Operation has to be refined to support a "this" Transformation context rather than a "self" Type context. In QVTbase this change is reflected in the use of Function rather than Operation although the subtleties of extension from Operation remain obscure. Perhaps QVTbase should also specify a "this". A Transformation has many things that need defining; not least of which is transformation extension and its relationship (if any) to the inherited Class superclass semantics. Mappings are where the real 'action' is and UML does not help much here. Regards Ed Willink On 17/09/2013 05:23, Rouquette, Nicolas F (313K) wrote: Ed, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Now you're the one who is not answering my question. How are you defining the QVT metamodel with Transformation? In particular, is QVT::Transformation inheriting from UML::Package and UML::Class, just UML::Package, just UML::Class or something else? Are you merging the QVT metamodel at all or are you keeping the Qvt metamodel separate from the metamodel that defines UML::Package and UML::Class? The problems you're having with EMOF may have more to do with the particular construction of the QVT metamodel than the fact that Transformation inherits from both UML::Package and UML::Class. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 1:33 PM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas I can't see anything in your references that actually requires a Transformation to be both Package and Class. The requirement is that a Transformation - has hierarchical structure - is instantiable - has operations - has properties - has types This could be satisfied by a Transformation that extends Package with additional ownedOperations and ownedAttributes. Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpfule. Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. Once the Transformation WFRs are written, I suspect that the dual inheritance will require a significant amount of unwriting of Class/Package. Regards Ed On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=XOgJF2RE c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=N659UExz7-8A:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=EBOSESyhAAAA:8 a=oCcaPWc0AAAA:8 a=TwaKVI9hX2bljsBN7JYA:9 a=CRVApoi6ZqeBFQcm:21 a=VhS3MPlIsRo5AYzP:21 a=f8P3F0lX-djr73QI:21 a=pILNOxqGKmIA:10 a=_W_S_7VecoQA:10 a=-zspGdomsggA:10 a=gFGq0ozTCKgA:10 a=c9tJgGcuwpQA:10 a=WP4_USCxRkkA:10 Date: Tue, 17 Sep 2013 17:42:49 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas I plan to arrive in New Brunswick on Monday. I'm not sure if I actually have anything to do; nobody has told me whether the OCL 2.4 RTF report needs an accompanying presentation. Andrew is planning to put forward a motion that I fill the vacant QVT RTF chair. Perhaps we should be co-chairs given our hopefully complementary interests. Regards Ed On 17/09/2013 15:27, Rouquette, Nicolas F (313K) wrote: Ed, Transformation in QVTBase (Figure 7.4) and Module in QVTOperational (Figure 8.1) both inherit from Class and Package. I suspect that this issue affect both QVTr and QVTo. Yes, I'll be in New Brunswick. If you're there, it would be useful to have a QVT 1.2 RTF meeting, even if informal. - Nicolas. From: Ed Willink Date: Tuesday, September 17, 2013 2:04 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas We may be at cross-purposes here because my discussion is about Transformation which is an issue for QVTc and QVTr. You have been discussing quite possibly the same issue for QVTo whereby OperationalTransformation extends Module which extends Package and Class. You know much more about QVTo than me; my knowledge and this discussion is on QVTr and QVTc. Will you be in New Brunswick/Miami? ------- I was using the direct Ecore 'merge' whereby genmodel provides a realization of multiple inheritance in which there is a fully inherited implementation of the first superclass (Package) and stubs of secondary superclasses (Class). (The QVT 1.1 Ecore/EMOF are the models I produced to resolve the large number of XMI/Ecore/Text/Picture contradictions in QVT 1.0). I'm now using a very similar Ecore 'merge' of Pivot::Package and Package::Class. It was my bad manual implementation of the Class::getPackage() stub that caused the problem and consequently the consideration of validity. ------- Changing Transformation::getPackage() to return "getNestingPackage()" rather than "this" solves the containment loop but gives a different surprise that a 'Type' may have no containing 'Package'. ------- You say that UML provides execution semantics that doesn't need duplicating. What/where? The semantics of a transformation is what QVT is all about. I see no signs of reuse of Behavior or Action from UML. For QVTo, a UML Operation has to be refined to support a "this" Transformation context rather than a "self" Type context. In QVTbase this change is reflected in the use of Function rather than Operation although the subtleties of extension from Operation remain obscure. Perhaps QVTbase should also specify a "this". A Transformation has many things that need defining; not least of which is transformation extension and its relationship (if any) to the inherited Class superclass semantics. Mappings are where the real 'action' is and UML does not help much here. Regards Ed Willink On 17/09/2013 05:23, Rouquette, Nicolas F (313K) wrote: Ed, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Now you're the one who is not answering my question. How are you defining the QVT metamodel with Transformation? In particular, is QVT::Transformation inheriting from UML::Package and UML::Class, just UML::Package, just UML::Class or something else? Are you merging the QVT metamodel at all or are you keeping the Qvt metamodel separate from the metamodel that defines UML::Package and UML::Class? The problems you're having with EMOF may have more to do with the particular construction of the QVT metamodel than the fact that Transformation inherits from both UML::Package and UML::Class. - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 1:33 PM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas I can't see anything in your references that actually requires a Transformation to be both Package and Class. The requirement is that a Transformation - has hierarchical structure - is instantiable - has operations - has properties - has types This could be satisfied by a Transformation that extends Package with additional ownedOperations and ownedAttributes. Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpfule. Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. Once the Transformation WFRs are written, I suspect that the dual inheritance will require a significant amount of unwriting of Class/Package. Regards Ed On 16/09/2013 17:48, Rouquette, Nicolas F (313K) wrote: Ed, A transformation is semantically both a kind of package and a kind of class. As a package, it can contain any kind of UML::PackageableElement that a UML::Package can own, e.g.: Nested transformations Classes (e.g., intermediate class in qvto speak) As a class, it can contain any kind of UML::Feature or nested UML::Classifier that a UML::Class can own, e.g.: Nested transformations Classes (I.e., intermediate class in qvto speak) Operations (e.g., transformation mapping, query, helper, intermediate class constructor, .) Properties (e.g., transformation configuration & non-config properties) The nature of a transformation as a kind of UML::Class is essential for the semantics of a transformation. More importantly, the execution semantics of a transformation depend on "instantiating" a transformation; see: "this" (8.1.16) dynamic transformations (8.1.18) module import (8.2.1.4) Transformation (8.3.1.1) and status (8.3.1.3) asTransformation() -- 8.3.5.5 . this is important for runtime meta-transformation (I.e., a transformation T1 that, when executed, creates a new transformation T2 and executes it by calling transform() -- 8.3.6.1) Parallel transformations . 8.3.6.2 . if a transformation T is executed in parallel for several models; each parallel execution instance of T must have its own instance-specific values for all of T's structural features (I.e., config/non-config properties; trace; etc.) Finally, note that UML itself has a kind of half-bred Class + Package; it's called a Component. The only thing missing about a Component is that it's not a kind of Package and therefore one can't import/merge components and one can't apply a profile to a component. Other than that, a Component has the capability to own PackageableElements like a Package can (subject to minor restrictions). - Nicolas. From: Ed Willink Date: Monday, September 16, 2013 9:06 AM To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas In UML, if Package P1 contains Package P2 contains Class C contains Operation O P2.nestingPackage.nestedPackages->includes(P2). C.package.ownedTypes->includes(C) However if P2 and C are merged as T by QVT. Package P1 contains T contains O T.nestingPackage is P2 and P2.nestedPackages could include T. T.package is really the problem. ----- This showed up because the Eclipse QVTd implementation stubbed it out as T.package = T, which caused a QVT to QVT transformation to bomb on a recursive containment. I've just rebuilt in my workspace so that a Transformation is a Package + ownedFunctions (+ownedAttributes + ownedInvariants) and everything seems to work fine with only minor ripples. Regards Ed Willink On 16/09/2013 16:40, Rouquette, Nicolas F (313K) wrote: Ed, I don't understand the problem with Model/Transformation inheriting from Package and Class. Please explain your reasoning based on these constraints: self.nestingPackage.nestedPackages->includes(self) self.package.ownedTypes->includes(self) To conclude that Model/Transformation would have to have distinct owners? - Nicolas. From: Juergen Boldt Date: Monday, September 16, 2013 7:58 AM To: "issues@omg.org" , "qvt-rtf@omg.org" Subject: issue 18912 -- MOF QVT RTF issue From: webmaster@omg.org Date: 16 Sep 2013 09:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Edward Willink Employer: mailFrom: ed@willink.me.uk Terms_Agreement: I agree Specification: QVT Section: Many FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: Many Title: Inconsistent multiple inheritance Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: edwillink.plus.com Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.0; rv:23.0) Gecko/20100101 Firefox/23.0 Time: 09:18 AM Description: The pragmatic decision to define Module/Transformation as inheriting both Package and Class violates UML inheritance. For a Package: self.nestingPackage.nestedPackages->includes(self) For a Class: self.package.ownedTypes->includes(self) But self cannot have two containers. The problem is easily resolved by extending only Package and adding those Class features that are actually required. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org [] No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6670 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6671 - Release Date: 09/16/13 No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6672 - Release Date: 09/16/13 :wq X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FBegBRJn3CDc8gHU0rA/cEFwaST4KLo9+bh9UtzFoJw=; b=kFk6P42xOlDg/V8FFOl9Y9+09OFvrnDHMtO+IIQhXyLdT04lOSA28TYsBZuNvDsSBE lLVROTQchmKP8w2nO6WqXu3YaMeXJ/P9GkJ1bSfya0K0OgUZwNs47mXFKhcUd24469Ad HnpqYHCD9CxGtNAevC7ztVUwAyLZNEuT7v/bv6BWqArky5xuMT0O2q6OHdmSfhidlguK wFj7/GGgMT5u7KYfvsmVWnVaHJwSedtd8FcjLvkQbRR1XmTXIP2Q5XkV/ViUOc8qB4CG blSILqGL4bUon0+51jvly+VT58STO8URO6m6q1y1BI4+ahAdU5hRZZgYoHKZ1tpndTaP 69Ug== X-Gm-Message-State: ALoCoQl2O4JeAMiG5htRkE/P2/rCF9azS7QzpU8Sb6rGJieYHseZe/M6vlmiYhOFRZz0aGtgpiuO X-Received: by 10.152.8.115 with SMTP id q19mr37030959laa.16.1379539077464; Wed, 18 Sep 2013 14:17:57 -0700 (PDT) Sender: adolfosbh@opencanarias.es Date: Wed, 18 Sep 2013 22:17:57 +0100 X-Google-Sender-Auth: zV_48wgH7IYpeORBCBDo7FPKFTI Subject: Re: issue 18912 : Transformation is both Package and Class From: Adolfo Sanchez Barbudo To: "Rouquette, Nicolas F (313K)" Cc: Ed Willink , "qvt-rtf@omg.org" , "Wartik, Steven P Steve" X-Virus-Scanned: amavisd-new at omg.org Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K) Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=92IwtFGauxEvI003YSbCNyAvsHWiEgh6BRxEK7vR1Ko=; b=FuMXQ4uDYgdCwXd031BWo0E9GmO6VMSNU+5db0rMpvqAcP5b+vADmQrH2B9US++Idc 5uS9Ni8SGK2CpMCABu6yN1yQmT7GEdAlhBaXu5KYq0Vw4nKZKzOPf5I0kgfgRNc/nzf4 Yth1N/Czqk94CB+wwWmHgqQ1twLjyiR+MoSVUHvokTsItTf3XfPvf3IJMgjs7ZOkRo2x Ly3Sp/h1ZvH4vM7KI7HiHENQNOwU8ChrGr6+eqvHUrZUWJ0XgPkh6hW7/NrFX+zAg2Tm AcSN3sgKWwzRWL/dg1gU9dnwv2n1j3gPjdI9nT4rfrw3uRPe+u+o3BM9AogZNd2jhn/e 1etQ== X-Gm-Message-State: ALoCoQnrNVUFwaSSbpJzyoNYbJMTXu+C+p95qZnyUSlH83T/mBevIjHFuaqLOwl3GySSe/1lyX7P X-Received: by 10.152.5.162 with SMTP id t2mr36453784lat.1.1379540225344; Wed, 18 Sep 2013 14:37:05 -0700 (PDT) Sender: adolfosbh@opencanarias.es Date: Wed, 18 Sep 2013 22:37:05 +0100 X-Google-Sender-Auth: Y0scSb1W9q0dQ8_eGzP-1Kv7Z88 Subject: Re: issue 18912 : Transformation is both Package and Class From: Adolfo Sanchez Barbudo To: "Rouquette, Nicolas F (313K)" Cc: Ed Willink , "qvt-rtf@omg.org" , "Wartik, Steven P Steve" X-Virus-Scanned: amavisd-new at omg.org Reviewing the thread again. I want to highlighting some comments in one of the last Ed´s email. - Since transformation operation and properties have significant differences to Class operations and properties avoiding confusion is helpful. This needs to be clarified. Which are these significant differences ?. From QVTo point of view they are not obvious. Perhaps, from QVT declarative point of view ? - Since classes have interesting superclass behaviour, avoiding confusion with transformation extension is also beneficial. This needs to be studied. Is really transformation extension very different to Class inheritance. Perhaps this could be different from QVTo::Module and Base::Transformation - All in all, the double inheritance gives many surprising characteristics and difficulties, and is obviously not legal as currently specified in EMOF. I´m not sure if it´s really illegal, what is clear to me is that a WFR could avoid ambiguities about which is the containment property to use when a Package contains a Transformation/Module (in case the double inheritance is preserved). Cheers, Adolfo. 2013/9/18 Adolfo Sanchez Barbudo Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K) Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TtdZwmECrue5JjoxiAKbxoIv6PYm2xGDM3E8JH2rgDg=; b=L5vng4MUph5nFQW+qouJ9+jWBWAw15LqCGH9Bva704WVntPjWM5XqjuDhMmCghMTy6 dYTLH5NMQ6u2nRHD2YKP19F0SZVOmQCfAEb64ihwAQyyie0vqdzwkgePmbVMJ8vXtEht kUXjmwqNp1qzFlpcBxdxCjbqyj7aF5/5KvI6BHtmjh4kX4IdGbhmiDVlXZIkv3tS6phc zRkRyMSXE7u9I0+ZrCd7WDyWFczOws8bqZ0h/rukOdhucVVewKk+1r5qkJdRzg4uiUpD pCsxtkOip7/z3BmszcJGJ/NcstbL7tpcjne90ZO3RA4rS/qt5SZCo8waqpaZ6GVgX4ev NcBA== X-Gm-Message-State: ALoCoQnC2nTngN1PBPcYXW5OI+BjbBJC//WenyS5pAdB991KStor5WYqtyKGbjUrnlZqW/RPjHiT X-Received: by 10.14.208.194 with SMTP id q42mr61670783eeo.31.1379533569917; Wed, 18 Sep 2013 12:46:09 -0700 (PDT) Sender: Adolfo Sanchez Barbudo Date: Wed, 18 Sep 2013 20:46:05 +0100 From: Adolfo Sánchez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "Wartik, Steven P \"Steve\"" CC: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what.s executed is one of a transformation.s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Sq7X+HaoK8J2BGIjw6QGxJVld7+OvgwBj+HvFY/9PfA=; b=cUeT3zUotADRTaVb8aHfqCbW2WJH5+NBOJYDYcvAC0a7xKEw54LsdYFCik80xBmh5k v9K7FWCZoeDVQ+LERTZKSLmR1MgHNeHiCJlwyIPyjJYvxzAA1c6g1sW9TEv+CmAIyf15 qA9FvgrUXuDo3ozYU+xVnnVKDBn9KBxSVSUQ7bMQ4D4f5WNPFkiLu79C63P1HJEb2HIu CpTG5EGi2iyd/wpk1wD6z0Ez532rYQpoYOGHZjyFD0AlYgbwYMvPYetTnAbOp3flbIhU NgPCT2Hhkhm0VKAwMvgEB8Bok4E8W1l4Z5cmfgrePvBKuMODdNawUJeI7irUk8rAhDTJ LCtw== X-Gm-Message-State: ALoCoQn0WelnNOi6xWwIVAz3zsYqNpxRinSFeZbSjg1sY6fvK1BoHkw1HU4jJIQLWdf/V8wdeWTC X-Received: by 10.14.199.3 with SMTP id w3mr20255288een.33.1379778985972; Sat, 21 Sep 2013 08:56:25 -0700 (PDT) Sender: Adolfo Sanchez Barbudo Date: Sat, 21 Sep 2013 16:56:24 +0100 From: Adolfo Sánchez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 To: "Rouquette, Nicolas F (313K)" CC: Ed Willink , "qvt-rtf@omg.org" , "Wartik, Steven P Steve" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo > Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette > Cc: Ed Willink >, "qvt-rtf@omg.org " >, "Wartik, Steven P Steve" > Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K) > Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> X-IronPort-AV: E=Sophos;i="4.90,935,1371078000"; d="scan'208";a="67054007" From: AKEHURST David To: "qvt-rtf@omg.org" Date: Thu, 19 Sep 2013 09:11:21 +0100 Subject: RE: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAyu/g Accept-Language: en-US, en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB X-SpamInfo: helo-dns, X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r8J8DleC026277 Hi, I am new to this discussion. to save me diving into the spec....could someone just remind me (us) why a Transformation needs to specialise package ? I see why it needs to specialise a class. thanks -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 18 September 2013 21:03 To: Adolfo Sáhez-Barbudo Herrera; Ed Willink Cc: qvt-rtf@omg.org; Wartik, Steven P "Steve" Subject: Re: issue 18912 : Transformation is both Package and Class Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=PP82p5aC c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=laOfOvinFzwA:10 a=FsgoC6E41WYA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=lTFofK6QAAAA:8 a=oCcaPWc0AAAA:8 a=HGVeKBf2mTTd03d1OMQA:9 a=wPNLvfGTeEIA:10 a=WP4_USCxRkkA:10 a=pJ89gMeR3iAA:10 Date: Thu, 19 Sep 2013 10:04:31 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Hi David Good question. Sadly none of the original participants seem to read this list so my best guesses at reasons might be Intuitively a Transformation is a big thing and so the fit with a Package seems right. Transformations introduce a new concept of extension / refinement that seems a better fit for a Package than a Class which already has superTypes. IMHO the definition of Transformation/Rule extension/refinement is still a research topic. ?? The original prototypes naturally focussed on Transformation and its contents and ignored the overall context and so neglected to define the outer Package hierarchy (e.g. A::B::MyTx) and so failed to realize that a Class would be simpler ?? ?? QVTo wanted to avoid confusion as to where "self" was and so opted for a "this" ?? ?? The early thinking might have been that a Mapping/Rule has analogies to a Class, so a Transformation should be a step up ?? Not a very convincing rationale. Maybe we could investigate what happens if the Package inheritance vanished. We can then tackle the WFRs that can allow trivial mix-in superTypes but must prohibit more serious anarchy. If a Paxckge is really needed, myabe we emulate the TemplateTypeParameter which is logically a Class, but avoids the confusing inheritance by owning rather than being a Class. So maybe a Transformation has a mandatory ownedType named "This". [The Java code generator for the backend of our QVTr/QVTc/QVTu/QVTm/QVTi transformation chain very nicely realizes a Transformation as a Java class and a Mapping as a Java operation.] If this is to change in QVT 1.2, we have to demonstrate that the double inheritance is wrong, rather than just have an intense dislike for it. In EMOF/Ecore it is broken, but perjhaps in UML it is ok. However it is difficult to avoid one of the following surprises for UML tool sets: all types have a parent package. all operations have an owning type which is not a package. Transformation as just Class could solve all this. Regards Ed On 19/09/2013 09:11, AKEHURST David wrote: Hi, I am new to this discussion. to save me diving into the spec....could someone just remind me (us) why a Transformation needs to specialise package ? I see why it needs to specialise a class. thanks -----Original Message----- From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: 18 September 2013 21:03 To: Adolfo Sáhez-Barbudo Herrera; Ed Willink Cc: qvt-rtf@omg.org; Wartik, Steven P "Steve" Subject: Re: issue 18912 : Transformation is both Package and Class Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what¹s executed is one of a transformation¹s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6677 - Release Date: 09/18/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=PP82p5aC c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=FsgoC6E41WYA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=lTFofK6QAAAA:8 a=KHpXyVWLAAAA:8 a=dBhzj_v1AAAA:8 a=oCcaPWc0AAAA:8 a=i8hixIr-u4Vna0DTQ08A:9 a=qNWRW9J3o-AyBtaf:21 a=3sDXcDdNbPngpM2Z:21 a=QEXdDO2ut3YA:10 a=pJ89gMeR3iAA:10 a=WP4_USCxRkkA:10 a=rsyBdmJBmesA:10 Date: Sat, 21 Sep 2013 17:17:07 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi For CMOF the QVT specification may be tenable. For EMOF the QVT specification is broken, and following David's query, I favour seeing what happens implementation-wise if a Transformation is a just Class with some appropriate WFRs. It is not clear to me that there are any necessary facilities of Package that are missing. The only inconvenience is that a QVT AS model will need an explicit Package to contain the Transformation. Since no one is able to produce killer reasons for Class/Package behaviour by analysis, I don't see much point in further discussion without some empirical discovery. [I already did one experiment with editors for QVTr, QVTc making Transformation just a Package, which consequently required the new features Transformation::ownedAttributes, Transformation::ownedFunctions to repair the damage. It worked and was fairly painless, but we have the surprise that if QVT Functions are Operations, then not all Operations are owned by a Type. The alternative of making a Transformation just a Class may require no repairs and may have no surprises; just the containing Package inconvenience.] [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles of Basic Constructs and EMOF are pursued so there is only single containment, which was where this discussion started.] Regards Ed Willink On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo > Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette > Cc: Ed Willink >, "qvt-rtf@omg.org " >, "Wartik, Steven P Steve" > Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K) > Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: 09/20/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=PP82p5aC c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=FsgoC6E41WYA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=lTFofK6QAAAA:8 a=KHpXyVWLAAAA:8 a=dBhzj_v1AAAA:8 a=oCcaPWc0AAAA:8 a=dt7Qm4huBhIqwLtSfHYA:9 a=zC4kk-7YUzed6DRY:21 a=OOzp27_8lvbegbmP:21 a=QEXdDO2ut3YA:10 a=pJ89gMeR3iAA:10 a=WP4_USCxRkkA:10 a=rsyBdmJBmesA:10 Date: Sat, 21 Sep 2013 19:50:19 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi Nicolas So the only problem with Transformation being just a Class is a URI attribute! IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. We can very easily add a Transformation::URI attribute if it's needed, but given the total absence of any concrete syntax to support it, it is clearly not critical and can easily be provided by a containing Package/Model and a URI fragment. EMF convenience is a poor justification for changing specifications. However EMOF is there to be efficient and QVT should support it, so Transformation/Module as just a Class seems really worth investigation. Regards Ed Willink On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: Thanks Ed and Adolfo for your clarifying explanations. First, 18912 is a genuine issue with the QVT spec. Second, since EMOF precludes subsetting and redefinition, it effectively implies that EMOF::Package and EMOF::Class must be disjoint. This is clearly a subtle consequence that escaped several reviews of QVT 1.0 and 1.1 before. This consequence should be clarified in the MOF spec -- I.e., this is a new MOF-specific issue. Who should we credit this issue to? Third, we can't define QVT::Transformation as just an EMOF::Class. As a kind of EMOF::Package, a QVT::Transformation gains EMOF::Package::URI. The QVT spec should provide concrete syntax for specifying the URI of a transformation as a kind of EMOF::Package. This is a new issue that is a consequence of the changes made from MOF 2.1 to MOF 2.4.1. Without an owning EMOF::Package, an EMOF::Class does not have a URI; I.e., we cannot say that transformation T1 (whose URI is T1.URI) imports transformation T2 (whose URI is T2.URI). The URI of a QVT::Transformation is really important for deploying and reusing compiled transformations. My recommendation would be to consider changing the definition of QVT to a CMOF-based metamodel, not EMOF. This would allow us to define QVT::Transformation as both a kind of CMOF::Package and CMOF::Class. There may be some problems with EMF, which is a kind of strange thing that is mostly EMOF with some CMOF capabilities. It would be reasonable to raise bugzilla issue against EMF to enable the proper construction of QVT where QVT::Transformation is both a kind of EMOF::Epackage and EMOF::Eclass with single ownership. - Nicolas. On 9/21/13 9:17 AM, "Ed Willink" wrote: Hi For CMOF the QVT specification may be tenable. For EMOF the QVT specification is broken, and following David's query, I favour seeing what happens implementation-wise if a Transformation is a just Class with some appropriate WFRs. It is not clear to me that there are any necessary facilities of Package that are missing. The only inconvenience is that a QVT AS model will need an explicit Package to contain the Transformation. Since no one is able to produce killer reasons for Class/Package behaviour by analysis, I don't see much point in further discussion without some empirical discovery. [I already did one experiment with editors for QVTr, QVTc making Transformation just a Package, which consequently required the new features Transformation::ownedAttributes, Transformation::ownedFunctions to repair the damage. It worked and was fairly painless, but we have the surprise that if QVT Functions are Operations, then not all Operations are owned by a Type. The alternative of making a Transformation just a Class may require no repairs and may have no surprises; just the containing Package inconvenience.] [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles of Basic Constructs and EMOF are pursued so there is only single containment, which was where this discussion started.] Regards Ed Willink On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo> Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette> Cc: Ed Willink>, "qvt-rtf@omg.org">, "Wartik, Steven P Steve"> Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K)> Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what¹s executed is one of a transformation¹s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: 09/20/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=PP82p5aC c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=FsgoC6E41WYA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=lTFofK6QAAAA:8 a=dBhzj_v1AAAA:8 a=oCcaPWc0AAAA:8 a=Klv56ax5cXinkJA2tIMA:9 a=-u20hh2VOes-xgOn:21 a=x17dsgC9YpUj872h:21 a=QEXdDO2ut3YA:10 a=pJ89gMeR3iAA:10 a=WP4_USCxRkkA:10 a=rsyBdmJBmesA:10 Date: Sat, 21 Sep 2013 21:05:02 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi I'm obviously missing something. If a Transformation is a Class then it can be referenced in just the same way as any other Class might be, possibly as a Class.superCass, possibly as a TypedElement.type. e.g. Boolean has no URI but we can still use it. I've not studied MOF serialization, but if it fails to provide a generic policy for all UML Elements, we may indeed have to do some more specifying. Regards Ed Willink On 21/09/2013 20:23, Rouquette, Nicolas F (313K) wrote: Ed, Well, it's two things: - having a URI (it was added in MOF 2.4.1; before that, it was based on the MOF tag org.omg.xmi.nsURI) - MOF/XMI mapping which uses a Package's URI as the basis for defining the URI of the package able elements in that Package. So even if you were to define QVT::Transformation as a kind of EMOF::Class + the Package capabilities, including URI, the MOF/XMI spec then says nothing about how we can reference anything defined in a transformation. For example, if we have 2 transformations, T1 and T2 where T2 extends T1, then we can, in principle, override T1's operations (I.e., mapping rules, helpers, etc.) in T2. For this to work at the level of persisted serializations of these transformations, then T1 and T2 must be kinds of EMOF::Packages otherwise the MOF/XMI mapping spec is useless and one would have to define the MOF/XMI serialization of QVT::Transformations. How this affects the Eclipse implementation is a different matter; the point here is that at the level of the OMG specs, QVT::Transformation really must be both a kind of Class and Package. Since it can't be both EMOF::Class and EMOF::Package, then unless we have the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF extension. - Nicolas. On 9/21/13 11:50 AM, "Ed Willink" wrote: Hi Nicolas So the only problem with Transformation being just a Class is a URI attribute! IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. We can very easily add a Transformation::URI attribute if it's needed, but given the total absence of any concrete syntax to support it, it is clearly not critical and can easily be provided by a containing Package/Model and a URI fragment. EMF convenience is a poor justification for changing specifications. However EMOF is there to be efficient and QVT should support it, so Transformation/Module as just a Class seems really worth investigation. Regards Ed Willink On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: Thanks Ed and Adolfo for your clarifying explanations. First, 18912 is a genuine issue with the QVT spec. Second, since EMOF precludes subsetting and redefinition, it effectively implies that EMOF::Package and EMOF::Class must be disjoint. This is clearly a subtle consequence that escaped several reviews of QVT 1.0 and 1.1 before. This consequence should be clarified in the MOF spec -- I.e., this is a new MOF-specific issue. Who should we credit this issue to? Third, we can't define QVT::Transformation as just an EMOF::Class. As a kind of EMOF::Package, a QVT::Transformation gains EMOF::Package::URI. The QVT spec should provide concrete syntax for specifying the URI of a transformation as a kind of EMOF::Package. This is a new issue that is a consequence of the changes made from MOF 2.1 to MOF 2.4.1. Without an owning EMOF::Package, an EMOF::Class does not have a URI; I.e., we cannot say that transformation T1 (whose URI is T1.URI) imports transformation T2 (whose URI is T2.URI). The URI of a QVT::Transformation is really important for deploying and reusing compiled transformations. My recommendation would be to consider changing the definition of QVT to a CMOF-based metamodel, not EMOF. This would allow us to define QVT::Transformation as both a kind of CMOF::Package and CMOF::Class. There may be some problems with EMF, which is a kind of strange thing that is mostly EMOF with some CMOF capabilities. It would be reasonable to raise bugzilla issue against EMF to enable the proper construction of QVT where QVT::Transformation is both a kind of EMOF::Epackage and EMOF::Eclass with single ownership. - Nicolas. On 9/21/13 9:17 AM, "Ed Willink" wrote: Hi For CMOF the QVT specification may be tenable. For EMOF the QVT specification is broken, and following David's query, I favour seeing what happens implementation-wise if a Transformation is a just Class with some appropriate WFRs. It is not clear to me that there are any necessary facilities of Package that are missing. The only inconvenience is that a QVT AS model will need an explicit Package to contain the Transformation. Since no one is able to produce killer reasons for Class/Package behaviour by analysis, I don't see much point in further discussion without some empirical discovery. [I already did one experiment with editors for QVTr, QVTc making Transformation just a Package, which consequently required the new features Transformation::ownedAttributes, Transformation::ownedFunctions to repair the damage. It worked and was fairly painless, but we have the surprise that if QVT Functions are Operations, then not all Operations are owned by a Type. The alternative of making a Transformation just a Class may require no repairs and may have no surprises; just the containing Package inconvenience.] [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles of Basic Constructs and EMOF are pursued so there is only single containment, which was where this discussion started.] Regards Ed Willink On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo> Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette> Cc: Ed Willink>, "qvt-rtf@omg.org">, "Wartik, Steven P Steve"> Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K)> Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what¹s executed is one of a transformation¹s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: 09/20/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=PP82p5aC c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=FsgoC6E41WYA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=lTFofK6QAAAA:8 a=dBhzj_v1AAAA:8 a=oCcaPWc0AAAA:8 a=ifbyiBHb-FEDZJte6akA:9 a=HXFOPjpDS1g2z8Y8:21 a=xHyEGGzsZYyXmMFv:21 a=QEXdDO2ut3YA:10 a=pJ89gMeR3iAA:10 a=WP4_USCxRkkA:10 a=rsyBdmJBmesA:10 Date: Sat, 21 Sep 2013 23:13:42 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit Hi Nicolas Exactly; so if we have an outer package there is no problem with referencing a Transformation that is just a Class as # Regards Ed Willink On 21/09/2013 21:13, Rouquette, Nicolas F (313K) wrote: The href is of the form# See MOF/XMI 7.10.2.2 Linking across Documents. The MOF/XMI spec only defines a URI for a package. Classes don't have URIs. - Nicolas. On 9/21/13 1:05 PM, "Ed Willink" wrote: Hi I'm obviously missing something. If a Transformation is a Class then it can be referenced in just the same way as any other Class might be, possibly as a Class.superCass, possibly as a TypedElement.type. e.g. Boolean has no URI but we can still use it. I've not studied MOF serialization, but if it fails to provide a generic policy for all UML Elements, we may indeed have to do some more specifying. Regards Ed Willink On 21/09/2013 20:23, Rouquette, Nicolas F (313K) wrote: Ed, Well, it's two things: - having a URI (it was added in MOF 2.4.1; before that, it was based on the MOF tag org.omg.xmi.nsURI) - MOF/XMI mapping which uses a Package's URI as the basis for defining the URI of the package able elements in that Package. So even if you were to define QVT::Transformation as a kind of EMOF::Class + the Package capabilities, including URI, the MOF/XMI spec then says nothing about how we can reference anything defined in a transformation. For example, if we have 2 transformations, T1 and T2 where T2 extends T1, then we can, in principle, override T1's operations (I.e., mapping rules, helpers, etc.) in T2. For this to work at the level of persisted serializations of these transformations, then T1 and T2 must be kinds of EMOF::Packages otherwise the MOF/XMI mapping spec is useless and one would have to define the MOF/XMI serialization of QVT::Transformations. How this affects the Eclipse implementation is a different matter; the point here is that at the level of the OMG specs, QVT::Transformation really must be both a kind of Class and Package. Since it can't be both EMOF::Class and EMOF::Package, then unless we have the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF extension. - Nicolas. On 9/21/13 11:50 AM, "Ed Willink" wrote: Hi Nicolas So the only problem with Transformation being just a Class is a URI attribute! IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. We can very easily add a Transformation::URI attribute if it's needed, but given the total absence of any concrete syntax to support it, it is clearly not critical and can easily be provided by a containing Package/Model and a URI fragment. EMF convenience is a poor justification for changing specifications. However EMOF is there to be efficient and QVT should support it, so Transformation/Module as just a Class seems really worth investigation. Regards Ed Willink On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: Thanks Ed and Adolfo for your clarifying explanations. First, 18912 is a genuine issue with the QVT spec. Second, since EMOF precludes subsetting and redefinition, it effectively implies that EMOF::Package and EMOF::Class must be disjoint. This is clearly a subtle consequence that escaped several reviews of QVT 1.0 and 1.1 before. This consequence should be clarified in the MOF spec -- I.e., this is a new MOF-specific issue. Who should we credit this issue to? Third, we can't define QVT::Transformation as just an EMOF::Class. As a kind of EMOF::Package, a QVT::Transformation gains EMOF::Package::URI. The QVT spec should provide concrete syntax for specifying the URI of a transformation as a kind of EMOF::Package. This is a new issue that is a consequence of the changes made from MOF 2.1 to MOF 2.4.1. Without an owning EMOF::Package, an EMOF::Class does not have a URI; I.e., we cannot say that transformation T1 (whose URI is T1.URI) imports transformation T2 (whose URI is T2.URI). The URI of a QVT::Transformation is really important for deploying and reusing compiled transformations. My recommendation would be to consider changing the definition of QVT to a CMOF-based metamodel, not EMOF. This would allow us to define QVT::Transformation as both a kind of CMOF::Package and CMOF::Class. There may be some problems with EMF, which is a kind of strange thing that is mostly EMOF with some CMOF capabilities. It would be reasonable to raise bugzilla issue against EMF to enable the proper construction of QVT where QVT::Transformation is both a kind of EMOF::Epackage and EMOF::Eclass with single ownership. - Nicolas. On 9/21/13 9:17 AM, "Ed Willink" wrote: Hi For CMOF the QVT specification may be tenable. For EMOF the QVT specification is broken, and following David's query, I favour seeing what happens implementation-wise if a Transformation is a just Class with some appropriate WFRs. It is not clear to me that there are any necessary facilities of Package that are missing. The only inconvenience is that a QVT AS model will need an explicit Package to contain the Transformation. Since no one is able to produce killer reasons for Class/Package behaviour by analysis, I don't see much point in further discussion without some empirical discovery. [I already did one experiment with editors for QVTr, QVTc making Transformation just a Package, which consequently required the new features Transformation::ownedAttributes, Transformation::ownedFunctions to repair the damage. It worked and was fairly painless, but we have the surprise that if QVT Functions are Operations, then not all Operations are owned by a Type. The alternative of making a Transformation just a Class may require no repairs and may have no surprises; just the containing Package inconvenience.] [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles of Basic Constructs and EMOF are pursued so there is only single containment, which was where this discussion started.] Regards Ed Willink On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo> Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette> Cc: Ed Willink>, "qvt-rtf@omg.org">, "Wartik, Steven P Steve"> Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K)> Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what¹s executed is one of a transformation¹s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: 09/20/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=OYOhUHjY c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=0MobcR2tXA8A:10 a=FsgoC6E41WYA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=A_Q5DRPsP5QA:10 a=KHpXyVWLAAAA:8 a=lTFofK6QAAAA:8 a=dBhzj_v1AAAA:8 a=oCcaPWc0AAAA:8 a=juTRHyIlk3MA0ze-mCgA:9 a=fgP3K5NelrzqwZtq:21 a=KIWBmclV2vvHaE39:21 a=QEXdDO2ut3YA:10 a=pJ89gMeR3iAA:10 a=WP4_USCxRkkA:10 a=rsyBdmJBmesA:10 Date: Sun, 22 Sep 2013 08:44:15 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Rouquette, Nicolas F (313K)" CC: "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class X-Virus-Scanned: amavisd-new at omg.org Content-Transfer-Encoding: 8bit HI The lack of a package syntax was already a bug; no way to specify A::B::MyTx. There are places where there are hints that arbitrary qualification should be allowed. In QVTc and QVTr this all forms part of the general inadequacy of the TopLevelCS where there is no syntax for imports/includes either, so no ability to resolve any metamodels to participate in the transformation. In my QVTc grammars I allow arbitrary package qualification. So rather than just defining transformation MyTx ... you can do transformation A::B::MyTx NB. This syntax inadequacy is a CS problem. The only AS change is to remove a seemingly unnecessary Transformation to Package inheritance. (Similarly we need to clean up FunctionParameter's dual inheritance which is unnecessary once the magical VariableDeclaration is disentangled from the OCL spec.) Regards Ed Willink On 21/09/2013 23:40, Rouquette, Nicolas F (313K) wrote: Ed, How do you propose to specify this outer containing package? There's no abstract or concrete syntax for this in QVT 1.1 but I suppose that could be fixed as part of a resolution for 18912. - Nicolas. On 9/21/13 3:13 PM, "Ed Willink" wrote: Hi Nicolas Exactly; so if we have an outer package there is no problem with referencing a Transformation that is just a Class as # Regards Ed Willink On 21/09/2013 21:13, Rouquette, Nicolas F (313K) wrote: The href is of the form# See MOF/XMI 7.10.2.2 Linking across Documents. The MOF/XMI spec only defines a URI for a package. Classes don't have URIs. - Nicolas. On 9/21/13 1:05 PM, "Ed Willink" wrote: Hi I'm obviously missing something. If a Transformation is a Class then it can be referenced in just the same way as any other Class might be, possibly as a Class.superCass, possibly as a TypedElement.type. e.g. Boolean has no URI but we can still use it. I've not studied MOF serialization, but if it fails to provide a generic policy for all UML Elements, we may indeed have to do some more specifying. Regards Ed Willink On 21/09/2013 20:23, Rouquette, Nicolas F (313K) wrote: Ed, Well, it's two things: - having a URI (it was added in MOF 2.4.1; before that, it was based on the MOF tag org.omg.xmi.nsURI) - MOF/XMI mapping which uses a Package's URI as the basis for defining the URI of the package able elements in that Package. So even if you were to define QVT::Transformation as a kind of EMOF::Class + the Package capabilities, including URI, the MOF/XMI spec then says nothing about how we can reference anything defined in a transformation. For example, if we have 2 transformations, T1 and T2 where T2 extends T1, then we can, in principle, override T1's operations (I.e., mapping rules, helpers, etc.) in T2. For this to work at the level of persisted serializations of these transformations, then T1 and T2 must be kinds of EMOF::Packages otherwise the MOF/XMI mapping spec is useless and one would have to define the MOF/XMI serialization of QVT::Transformations. How this affects the Eclipse implementation is a different matter; the point here is that at the level of the OMG specs, QVT::Transformation really must be both a kind of Class and Package. Since it can't be both EMOF::Class and EMOF::Package, then unless we have the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF extension. - Nicolas. On 9/21/13 11:50 AM, "Ed Willink" wrote: Hi Nicolas So the only problem with Transformation being just a Class is a URI attribute! IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. We can very easily add a Transformation::URI attribute if it's needed, but given the total absence of any concrete syntax to support it, it is clearly not critical and can easily be provided by a containing Package/Model and a URI fragment. EMF convenience is a poor justification for changing specifications. However EMOF is there to be efficient and QVT should support it, so Transformation/Module as just a Class seems really worth investigation. Regards Ed Willink On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: Thanks Ed and Adolfo for your clarifying explanations. First, 18912 is a genuine issue with the QVT spec. Second, since EMOF precludes subsetting and redefinition, it effectively implies that EMOF::Package and EMOF::Class must be disjoint. This is clearly a subtle consequence that escaped several reviews of QVT 1.0 and 1.1 before. This consequence should be clarified in the MOF spec -- I.e., this is a new MOF-specific issue. Who should we credit this issue to? Third, we can't define QVT::Transformation as just an EMOF::Class. As a kind of EMOF::Package, a QVT::Transformation gains EMOF::Package::URI. The QVT spec should provide concrete syntax for specifying the URI of a transformation as a kind of EMOF::Package. This is a new issue that is a consequence of the changes made from MOF 2.1 to MOF 2.4.1. Without an owning EMOF::Package, an EMOF::Class does not have a URI; I.e., we cannot say that transformation T1 (whose URI is T1.URI) imports transformation T2 (whose URI is T2.URI). The URI of a QVT::Transformation is really important for deploying and reusing compiled transformations. My recommendation would be to consider changing the definition of QVT to a CMOF-based metamodel, not EMOF. This would allow us to define QVT::Transformation as both a kind of CMOF::Package and CMOF::Class. There may be some problems with EMF, which is a kind of strange thing that is mostly EMOF with some CMOF capabilities. It would be reasonable to raise bugzilla issue against EMF to enable the proper construction of QVT where QVT::Transformation is both a kind of EMOF::Epackage and EMOF::Eclass with single ownership. - Nicolas. On 9/21/13 9:17 AM, "Ed Willink" wrote: Hi For CMOF the QVT specification may be tenable. For EMOF the QVT specification is broken, and following David's query, I favour seeing what happens implementation-wise if a Transformation is a just Class with some appropriate WFRs. It is not clear to me that there are any necessary facilities of Package that are missing. The only inconvenience is that a QVT AS model will need an explicit Package to contain the Transformation. Since no one is able to produce killer reasons for Class/Package behaviour by analysis, I don't see much point in further discussion without some empirical discovery. [I already did one experiment with editors for QVTr, QVTc making Transformation just a Package, which consequently required the new features Transformation::ownedAttributes, Transformation::ownedFunctions to repair the damage. It worked and was fairly painless, but we have the surprise that if QVT Functions are Operations, then not all Operations are owned by a Type. The alternative of making a Transformation just a Class may require no repairs and may have no surprises; just the containing Package inconvenience.] [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles of Basic Constructs and EMOF are pursued so there is only single containment, which was where this discussion started.] Regards Ed Willink On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: Hi Nicolas, As Ed commented, that nicely works for UML models, however it struggles using EMOF/Ecore: Those properties are not only derived, as you have pointed out, but also they subset "Pacakage::packagedElement". Refining and subsetting is not allowed in EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). It doesn't work in genuine Ecore models neither, so, for instance, the QVTo metamodel you mentioned in your previous email, indeed, is using two different non-derived contaiment EReferences (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in the new Pivot-based metamodel (Package::nestedPackage, Package::ownedType). So in the end with EMOF/ECore we have to deal with two different non-derived containment properties. Are these metamodels wrong/bad designed? Are they right but limited by EMF/EMOF? Do we need to sort out anything in the OMG specifications ? Changing EMOF what this respects without a sort of sensible Ecore adoption is not acceptable, in my honest opinion. In my opinion, as we have current MOF/UML/QVT specifications, this doesn't seem to be consistent. Providing that EMOF were right (just a possible invalid premise), and we wanted to preserve the double inheritance, I'd at least add the constraint about which containment reference to use when nesting a Module/Transformation inside a Package. Also note, that the QVT specification talks about a QVT for CMOF. Unfortunately, QVT specification is related in terms of EMOF and reserves an specific chapter about QVT for CMOF. Perhaps, for future specification changes, it could be worthy align the specification to the style used by MOF (and for instance, OCL) specification, that is, talk about QVT in terms of CMOF (or UML), and then include an specific chapter to have a QVT for EMOF (which could, similarly to what MOF specification does, add a set of restrictions to define QVT for EMOF). Thoughts? Anyway, looking forward to hearing about your conclusions in New Brunswick. Good luck. Cheers, Adolfo. -- On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo> Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette> Cc: Ed Willink>, "qvt-rtf@omg.org">, "Wartik, Steven P Steve"> Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K)> Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" > wrote: Steve, Since QVTo has being influenced by traditional OOP languages, specifically java, QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) Regardless which are the final conclusion you get the next week, regarding both the declarative Transformation and/or the imperative Module, I think that the problem noticed by Ed needs to be addressed (taking also into consideration that QVT claims to be an EMOF and EssentialOCL extension), even with simple WFR which, for instance, prohibit a Transformations and/or Module be owned via an ownedType reference. An additional constraint in the fashion they are defined for the EMOF metamodel could sort the original (main problem): Type::package must be empty. Even better with some OCL: context Module inv : package->isEmpty() Another hint in this line, is that UML spec doesn't mandate a type to be owned by a package: package : Package [0..1]{subsets A_packagedElement_owningPackage::owningPackage} (opposite Package::ownedType) Specifies the owning Package of this Type, if any. Just some ideas/alternatives to think about. Maybe there are other implications which can't simply be handle with WFR. I hope the meeting is fruitful. Cheers, Adolfo. On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what¹s executed is one of a transformation¹s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: 09/20/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: 09/21/13 From: "Rouquette, Nicolas F (313K)" To: "Wartik, Steven P \"Steve\"" , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgAAQjAA= Date: Wed, 18 Sep 2013 19:16:54 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve, Look at section 4 of the QVT 1.1 spec; terminology & glossary. With QVT Operational, the "instance" aspects of the execution semantics of a transformation become really important. For example, the same transformation T can be executed to operate on distinct models, say, M1 and M2. Besides transformation inputs/outputs, there is a distinct notion of a transformation instance, which is effectively a function of the transformation input models; e.g.: T(M1) and T(M2). These instances are really different in the sense that: They correspond to different traces Values of configuration and non-configuration properties can be different The output models can be accessed after a transformation succeeds. For an example of the latter, see section 8.1.18 in QVT 1.1 - Nicolas. From: , Steve Steven P Date: Wednesday, September 18, 2013 11:22 AM To: "qvt-rtf@omg.org" Subject: RE: issue 18912 : Transformation is both Package and Class Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what.s executed is one of a transformation.s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik From: "Rouquette, Nicolas F (313K)" To: "Wartik, Steven P \"Steve\"" , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgAAQjACAAAkugA== Date: Wed, 18 Sep 2013 19:49:46 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve (again) Perhaps the most compelling evidence for the class-based semantics of all qvt transformations is the override capability See section 7.11.14 for QVTr See section 8.2.1.10 for QVTo The semantics of overriding a feature (operation or property) inherently tied to the class-based semantics of a transformation as the classifier context for overridable features. The distinction between extending vs. accessing a transformation is yet another example of the class-based semantics of a transformation See section 7.11.1.1 for QVT base (i.e., this applies to both QVT core, relational and operational) Nicolas. From: , Nicolas Rouquette Date: Wednesday, September 18, 2013 12:16 PM To: "Wartik, Steven P \"Steve\"" , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Steve, Look at section 4 of the QVT 1.1 spec; terminology & glossary. With QVT Operational, the "instance" aspects of the execution semantics of a transformation become really important. For example, the same transformation T can be executed to operate on distinct models, say, M1 and M2. Besides transformation inputs/outputs, there is a distinct notion of a transformation instance, which is effectively a function of the transformation input models; e.g.: T(M1) and T(M2). These instances are really different in the sense that: They correspond to different traces Values of configuration and non-configuration properties can be different The output models can be accessed after a transformation succeeds. For an example of the latter, see section 8.1.18 in QVT 1.1 - Nicolas. From: , Steve Steven P Date: Wednesday, September 18, 2013 11:22 AM To: "qvt-rtf@omg.org" Subject: RE: issue 18912 : Transformation is both Package and Class Nicolas, The execution semantics of a transformation definitely hinges on a transformation being a kind of class. UML does not define any execution semantics for a package. It makes no sense to duplicate all of this machinery. Does one execute a transformation? I had always considered a transformation to be a packaging construct. To my way of thinking, what.s executed is one of a transformation.s top relations. Wish I could be in New Brunswick to discuss the matter. Regards, Steve Wartik From: "Rouquette, Nicolas F (313K)" To: Adolfo Sáhez-Barbudo Herrera , Ed Willink CC: "qvt-rtf@omg.org" , "Wartik, Steven P \"Steve\"" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AA== Date: Wed, 18 Sep 2013 20:03:25 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r8IK3a45022166 Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> From: "Rouquette, Nicolas F (313K)" To: Adolfo Sanchez Barbudo CC: Ed Willink , "qvt-rtf@omg.org" , "Wartik, Steven P Steve" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgA= Date: Thu, 19 Sep 2013 14:12:26 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.113] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Adolfo, There is no problem with: Package::/nestedPackage (whose opposite is Package::nestingPackage) Package::/ownedType (whose opposite is Type::package) These are derived properties. So, a Transformation that is both a Package and a Class will show up in its parent Package as both Package::/nestedPackage and Package::/ownedType. There's only one ownership, that's Package::packagedElement (a non-derived property). - Nicolas. From: Adolfo Sanchez Barbudo Date: Wednesday, September 18, 2013 2:17 PM To: Nicolas Rouquette Cc: Ed Willink , "qvt-rtf@omg.org" , "Wartik, Steven P Steve" Subject: Re: issue 18912 : Transformation is both Package and Class Hi Nicolas, I didn´t mean there was a problem with EMOF constraints. I meant that as well as EMOF add constraints to define a more convenient UML subset for its definition. The same could be done with QVT what respect to EMOF. As I see, the main issue (there could be others) is that a Transformation may be contained in a Package via two containment properties: Package::nestedPackage (whose opposite is Package::nestingPackage) Package::ownedType (whose opposite is Type::package) What Ed noticed is that a Transformation can´t be contained in a package via those properties. It´s coherent that Transformation may have a container package (via Type::package property) because it´s a Class, as well as a container package (via Package::nestingPackage) because it´s Package. Should we allow a Transformation be contained in any of those containment properties?. I think that this could be constrained to mandate a Module/Transformation be contained via one of them. We agree that for QVTo (Module) this double inheritance is very convenient. I´m simply proposing to add a new WFR (to the QVT spec) which states that Module (and may be to Transformation) must have an empty Type::package value, avoiding any ambiguity, and solving this particular issue without breaking the Class-Package inheritance. Providing that UML doesn´t mandate that a type needs to belong to a package, and as far as I reviewed this evening, EMOF doesn´t do so neither... I´m simply proposing a new constraint to Module to clarify and avoid interpretation about how these properties must be considered when dealing with QVT models. context Module: inv : self.package->isEmpty() Does this make sense ? Cheers, Adolfo. 2013/9/18 Rouquette, Nicolas F (313K) Adolpho, Ed, I still don't understand what is the problem with defining a transformation as a specialization of both Class and Package. Are there any problems with the MOF 2.4.1 OCL rules for EMOF and/or CMOF metamodels? If so, which of these OCL rules are violated? http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl I got the impression that the problem isn't with the MOF 2.4.1 EMOF constraints per se but with implementing the QVT metamodel (base? Core? Relational? Operational?) as an extension of an EMOF metamodel. The original Eclipse QVTO implementation that I use defines QVTO::expressions::Module as an extension of both org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. Since these are interfaces, it's OK to have multiple inheritance. Am I missing something else? - Nicolas. On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" wrote: >Steve, > >Since QVTo has being influenced by traditional OOP languages, >specifically java, QVTo Transformations (Modules) indeed are very >(Java-)Class-ish: > >- may have a main operation (see section 8.1.1) >- are instantiable (see section 8.1.11) >- and executed (see again section 8.1.11 or the libray transform() >operation in section 8.3.6.1) > >Regardless which are the final conclusion you get the next week, >regarding both the declarative Transformation and/or the imperative >Module, I think that the problem noticed by Ed needs to be addressed >(taking also into consideration that QVT claims to be an EMOF and >EssentialOCL extension), even with simple WFR which, for instance, >prohibit a Transformations and/or Module be owned via an ownedType >reference. > >An additional constraint in the fashion they are defined for the EMOF >metamodel could sort the original (main problem): > >Type::package must be empty. > >Even better with some OCL: > >context Module >inv : package->isEmpty() > >Another hint in this line, is that UML spec doesn't mandate a type to be >owned by a package: > >package : Package [0..1]{subsets >A_packagedElement_owningPackage::owningPackage} (opposite >Package::ownedType) >Specifies the owning Package of this Type, if any. > >Just some ideas/alternatives to think about. Maybe there are other >implications which can't simply be handle with WFR. I hope the meeting >is fruitful. > >Cheers, >Adolfo. >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >> Nicolas, >> >> The execution semantics of a transformation definitely hinges on a >> transformation being a kind of class. >> >> UML does not define any execution semantics for a package. >> >> It makes no sense to duplicate all of this machinery. >> >> Does one execute a transformation? I had always considered a >> transformation to be a packaging construct. To my way of thinking, >> what¹s executed is one of a transformation¹s top relations. >> >> Wish I could be in New Brunswick to discuss the matter. >> >> Regards, >> >> Steve Wartik >> From: "Rouquette, Nicolas F (313K)" To: "Wartik, Steven P \"Steve\"" , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgCAAfGLUIAADnYA Date: Fri, 20 Sep 2013 20:44:58 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org Steve, Please read section 7.11.1; QVTBase Package: Syntactically, a Transformation is a subclass of both a Package and a Class. As a Package it provides a namespace for the rules contained in it. As a Class it can define properties and operations - properties to specify configuration values, if any, needed at runtime and operations to implement utility functions, if any, required by the transformation. The analogy with Java is fine; in the case of QVT (base, core, relation,operational), executing a transformation means: create an instance of the transformation class, which must have a class constructor corresponding to the signature of the transformation definition (I.e., in/out/inout parameters) Set values for configuration properties (optional) Run The rules for a transformation execute in the context of an instance of the transformation. This is essential for the semantics of overriding rules in specialized transformations. - Nicolas. From: , Steve Steven P Date: Friday, September 20, 2013 1:07 PM To: "qvt-rtf@omg.org" Subject: RE: issue 18912 : Transformation is both Package and Class Nicolas, I don.t mean to beat this to death, but the definitions in Section 4 are rather informal. Adolfo mentioned the influence of Java on QVTo, and said: QVTo Transformations (Modules) indeed are very (Java-)Class-ish: - may have a main operation (see section 8.1.1) - are instantiable (see section 8.1.11) - and executed (see again section 8.1.11 or the libray transform() operation in section 8.3.6.1) That too is a little informal. Java classes aren.t executed. Java operations are. It is convenient to think of executing a Java application by specifying a class that has a method named main, but that.s a shorthand for what.s actually occurring. Isn.t the same true in QVT? One thinks of executing a transformation, but again that.s a shorthand. As Section 7.11.1.1 says, a transformation contains a set of rules that specify its execution behavior. It.s the rules, not the transformation itself, that provide the semantics. More to the point, an execution engine works on the rules to perform the transformation. I will mention that I.ve worked mostly with QVTr, so perhaps my assessment is colored. I just want to say that to me it makes perfect sense to think of a transformation as a kind of package. Regards, Steve Wartik From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgCAA7cRAIAABcqA//+wPIA= Date: Sat, 21 Sep 2013 18:31:35 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r8LIWPGq010027 Content-Transfer-Encoding: 8bit Thanks Ed and Adolfo for your clarifying explanations. First, 18912 is a genuine issue with the QVT spec. Second, since EMOF precludes subsetting and redefinition, it effectively implies that EMOF::Package and EMOF::Class must be disjoint. This is clearly a subtle consequence that escaped several reviews of QVT 1.0 and 1.1 before. This consequence should be clarified in the MOF spec -- I.e., this is a new MOF-specific issue. Who should we credit this issue to? Third, we can't define QVT::Transformation as just an EMOF::Class. As a kind of EMOF::Package, a QVT::Transformation gains EMOF::Package::URI. The QVT spec should provide concrete syntax for specifying the URI of a transformation as a kind of EMOF::Package. This is a new issue that is a consequence of the changes made from MOF 2.1 to MOF 2.4.1. Without an owning EMOF::Package, an EMOF::Class does not have a URI; I.e., we cannot say that transformation T1 (whose URI is T1.URI) imports transformation T2 (whose URI is T2.URI). The URI of a QVT::Transformation is really important for deploying and reusing compiled transformations. My recommendation would be to consider changing the definition of QVT to a CMOF-based metamodel, not EMOF. This would allow us to define QVT::Transformation as both a kind of CMOF::Package and CMOF::Class. There may be some problems with EMF, which is a kind of strange thing that is mostly EMOF with some CMOF capabilities. It would be reasonable to raise bugzilla issue against EMF to enable the proper construction of QVT where QVT::Transformation is both a kind of EMOF::Epackage and EMOF::Eclass with single ownership. - Nicolas. On 9/21/13 9:17 AM, "Ed Willink" wrote: >Hi > >For CMOF the QVT specification may be tenable. > >For EMOF the QVT specification is broken, and following David's query, I >favour seeing what happens implementation-wise if a Transformation is a >just Class with some appropriate WFRs. It is not clear to me that there >are any necessary facilities of Package that are missing. The only >inconvenience is that a QVT AS model will need an explicit Package to >contain the Transformation. > >Since no one is able to produce killer reasons for Class/Package >behaviour by analysis, I don't see much point in further discussion >without some empirical discovery. > >[I already did one experiment with editors for QVTr, QVTc making >Transformation just a Package, which consequently required the new >features Transformation::ownedAttributes, Transformation::ownedFunctions >to repair the damage. It worked and was fairly painless, but we have the >surprise that if QVT Functions are Operations, then not all Operations >are owned by a Type. The alternative of making a Transformation just a >Class may require no repairs and may have no surprises; just the >containing Package inconvenience.] > >[In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles >of Basic Constructs and EMOF are pursued so there is only single >containment, which was where this discussion started.] > > Regards > > Ed Willink > >On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: >> Hi Nicolas, >> >> As Ed commented, that nicely works for UML models, however it >> struggles using EMOF/Ecore: Those properties are not only derived, as >> you have pointed out, but also they subset >> "Pacakage::packagedElement". Refining and subsetting is not allowed in >> EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). >> >> It doesn't work in genuine Ecore models neither, so, for instance, the >> QVTo metamodel you mentioned in your previous email, indeed, is using >> two different non-derived contaiment EReferences >> (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in >> the new Pivot-based metamodel (Package::nestedPackage, >> Package::ownedType). >> >> So in the end with EMOF/ECore we have to deal with two different >> non-derived containment properties. Are these metamodels wrong/bad >> designed? Are they right but limited by EMF/EMOF? Do we need to sort >> out anything in the OMG specifications ? Changing EMOF what this >> respects without a sort of sensible Ecore adoption is not acceptable, >> in my honest opinion. >> >> In my opinion, as we have current MOF/UML/QVT specifications, this >> doesn't seem to be consistent. Providing that EMOF were right (just a >> possible invalid premise), and we wanted to preserve the double >> inheritance, I'd at least add the constraint about which containment >> reference to use when nesting a Module/Transformation inside a Package. >> >> Also note, that the QVT specification talks about a QVT for CMOF. >> Unfortunately, QVT specification is related in terms of EMOF and >> reserves an specific chapter about QVT for CMOF. Perhaps, for future >> specification changes, it could be worthy align the specification to >> the style used by MOF (and for instance, OCL) specification, that is, >> talk about QVT in terms of CMOF (or UML), and then include an specific >> chapter to have a QVT for EMOF (which could, similarly to what MOF >> specification does, add a set of restrictions to define QVT for EMOF). >> >> Thoughts? >> >> Anyway, looking forward to hearing about your conclusions in New >> Brunswick. Good luck. >> >> Cheers, >> Adolfo. >> -- >> On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: >>> Adolfo, >>> >>> There is no problem with: >>> >>> Package::/nestedPackage (whose opposite is Package::nestingPackage) >>> Package::/ownedType (whose opposite is Type::package) >>> >>> These are derived properties. >>> >>> So, a Transformation that is both a Package and a Class will show up in >>> its parent Package as both Package::/nestedPackage and >>> Package::/ownedType. >>> There's only one ownership, that's Package::packagedElement (a >>> non-derived property). >>> >>> - Nicolas. >>> >>> >>> From: Adolfo Sanchez Barbudo >> > >>> Date: Wednesday, September 18, 2013 2:17 PM >>> To: Nicolas Rouquette >> > >>> Cc: Ed Willink >, >>> "qvt-rtf@omg.org " >> >, "Wartik, Steven P Steve" >> > >>> Subject: Re: issue 18912 : Transformation is both Package and Class >>> >>> Hi Nicolas, >>> >>> I didn´t mean there was a problem with EMOF constraints. I meant that >>>as >>> well as EMOF add constraints to define a more convenient UML subset for >>> its definition. The same could be done with QVT what respect to EMOF. >>>As >>> I see, the main issue (there could be others) is that a Transformation >>> may be contained in a Package via two containment properties: >>> >>> Package::nestedPackage (whose opposite is Package::nestingPackage) >>> Package::ownedType (whose opposite is Type::package) >>> >>> What Ed noticed is that a Transformation can´t be contained in a >>>package >>> via those properties. It´s coherent that Transformation may have a >>> container package (via Type::package property) because it´s a Class, as >>> well as a container package (via Package::nestingPackage) because it´s >>> Package. Should we allow a Transformation be contained in any of those >>> containment properties?. I think that this could be constrained to >>> mandate a Module/Transformation be contained via one of them. >>> >>> We agree that for QVTo (Module) this double inheritance is very >>> convenient. >>> >>> I´m simply proposing to add a new WFR (to the QVT spec) which states >>> that Module (and may be to Transformation) must have an empty >>> Type::package value, avoiding any ambiguity, and solving this >>>particular >>> issue without breaking the Class-Package inheritance. >>> >>> Providing that UML doesn´t mandate that a type needs to belong to a >>> package, and as far as I reviewed this evening, EMOF doesn´t do so >>> neither... I´m simply proposing a new constraint to Module to clarify >>> and avoid interpretation about how these properties must be considered >>> when dealing with QVT models. >>> >>> context Module: >>> inv : self.package->isEmpty() >>> >>> Does this make sense ? >>> >>> Cheers, >>> Adolfo. >>> >>> >>> 2013/9/18 Rouquette, Nicolas F (313K) >> > >>> >>> Adolpho, Ed, >>> >>> I still don't understand what is the problem with defining a >>> transformation as a specialization of both Class and Package. >>> >>> Are there any problems with the MOF 2.4.1 OCL rules for EMOF >>> and/or CMOF >>> metamodels? >>> If so, which of these OCL rules are violated? >>> >>> http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl >>> http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl >>> >>> I got the impression that the problem isn't with the MOF 2.4.1 EMOF >>> constraints per se but with implementing the QVT metamodel (base? >>> Core? >>> Relational? Operational?) as an extension of an EMOF metamodel. >>> >>> The original Eclipse QVTO implementation that I use defines >>> QVTO::expressions::Module as an extension of both >>> org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. >>> Since these are interfaces, it's OK to have multiple inheritance. >>> >>> Am I missing something else? >>> >>> - Nicolas. >>> >>> >>> On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" >>> > wrote: >>> >>> >Steve, >>> > >>> >Since QVTo has being influenced by traditional OOP languages, >>> >specifically java, QVTo Transformations (Modules) indeed are very >>> >(Java-)Class-ish: >>> > >>> >- may have a main operation (see section 8.1.1) >>> >- are instantiable (see section 8.1.11) >>> >- and executed (see again section 8.1.11 or the libray transform() >>> >operation in section 8.3.6.1) >>> > >>> >Regardless which are the final conclusion you get the next week, >>> >regarding both the declarative Transformation and/or the imperative >>> >Module, I think that the problem noticed by Ed needs to be addressed >>> >(taking also into consideration that QVT claims to be an EMOF and >>> >EssentialOCL extension), even with simple WFR which, for instance, >>> >prohibit a Transformations and/or Module be owned via an ownedType >>> >reference. >>> > >>> >An additional constraint in the fashion they are defined for the EMOF >>> >metamodel could sort the original (main problem): >>> > >>> >Type::package must be empty. >>> > >>> >Even better with some OCL: >>> > >>> >context Module >>> >inv : package->isEmpty() >>> > >>> >Another hint in this line, is that UML spec doesn't mandate a type >>> to be >>> >owned by a package: >>> > >>> >package : Package [0..1]{subsets >>> >A_packagedElement_owningPackage::owningPackage} (opposite >>> >Package::ownedType) >>> >Specifies the owning Package of this Type, if any. >>> > >>> >Just some ideas/alternatives to think about. Maybe there are other >>> >implications which can't simply be handle with WFR. I hope the meeting >>> >is fruitful. >>> > >>> >Cheers, >>> >Adolfo. >>> >On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >>> >> Nicolas, >>> >> >>> >> The execution semantics of a transformation definitely hinges on a >>> >> transformation being a kind of class. >>> >> >>> >> UML does not define any execution semantics for a package. >>> >> >>> >> It makes no sense to duplicate all of this machinery. >>> >> >>> >> Does one execute a transformation? I had always considered a >>> >> transformation to be a packaging construct. To my way of thinking, >>> >> what¹s executed is one of a transformation¹s top relations. >>> >> >>> >> Wish I could be in New Brunswick to discuss the matter. >>> >> >>> >> Regards, >>> >> >>> >> Steve Wartik >>> >> >>> >>> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: >>09/20/13 >> >> > From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgCAA7cRAIAABcqA//+wPICAAHqSgP//k+CA Date: Sat, 21 Sep 2013 19:23:18 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r8LJNOMr016426 Content-Transfer-Encoding: 8bit Ed, Well, it's two things: - having a URI (it was added in MOF 2.4.1; before that, it was based on the MOF tag org.omg.xmi.nsURI) - MOF/XMI mapping which uses a Package's URI as the basis for defining the URI of the package able elements in that Package. So even if you were to define QVT::Transformation as a kind of EMOF::Class + the Package capabilities, including URI, the MOF/XMI spec then says nothing about how we can reference anything defined in a transformation. For example, if we have 2 transformations, T1 and T2 where T2 extends T1, then we can, in principle, override T1's operations (I.e., mapping rules, helpers, etc.) in T2. For this to work at the level of persisted serializations of these transformations, then T1 and T2 must be kinds of EMOF::Packages otherwise the MOF/XMI mapping spec is useless and one would have to define the MOF/XMI serialization of QVT::Transformations. How this affects the Eclipse implementation is a different matter; the point here is that at the level of the OMG specs, QVT::Transformation really must be both a kind of Class and Package. Since it can't be both EMOF::Class and EMOF::Package, then unless we have the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF extension. - Nicolas. On 9/21/13 11:50 AM, "Ed Willink" wrote: >Hi Nicolas > >So the only problem with Transformation being just a Class is a URI >attribute! > >IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. > >We can very easily add a Transformation::URI attribute if it's needed, >but given the total absence of any concrete syntax to support it, it is >clearly not critical and can easily be provided by a containing >Package/Model and a URI fragment. > >EMF convenience is a poor justification for changing specifications. >However EMOF is there to be efficient and QVT should support it, so >Transformation/Module as just a Class seems really worth investigation. > > Regards > > Ed Willink > >On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: >> Thanks Ed and Adolfo for your clarifying explanations. >> >> First, 18912 is a genuine issue with the QVT spec. >> >> Second, since EMOF precludes subsetting and redefinition, it effectively >> implies that EMOF::Package and EMOF::Class must be disjoint. >> This is clearly a subtle consequence that escaped several reviews of QVT >> 1.0 and 1.1 before. >> This consequence should be clarified in the MOF spec -- I.e., this is a >> new MOF-specific issue. >> Who should we credit this issue to? >> >> Third, we can't define QVT::Transformation as just an EMOF::Class. >> As a kind of EMOF::Package, a QVT::Transformation gains >>EMOF::Package::URI. >> The QVT spec should provide concrete syntax for specifying the URI of a >> transformation as a kind of EMOF::Package. >> This is a new issue that is a consequence of the changes made from MOF >>2.1 >> to MOF 2.4.1. >> >> Without an owning EMOF::Package, an EMOF::Class does not have a URI; >>I.e., >> we cannot say that transformation T1 (whose URI is T1.URI) imports >> transformation T2 (whose URI is T2.URI). >> The URI of a QVT::Transformation is really important for deploying and >> reusing compiled transformations. >> >> >> My recommendation would be to consider changing the definition of QVT >>to a >> CMOF-based metamodel, not EMOF. >> This would allow us to define QVT::Transformation as both a kind of >> CMOF::Package and CMOF::Class. >> >> There may be some problems with EMF, which is a kind of strange thing >>that >> is mostly EMOF with some CMOF capabilities. >> It would be reasonable to raise bugzilla issue against EMF to enable the >> proper construction of QVT where QVT::Transformation is both a kind of >> EMOF::Epackage and EMOF::Eclass with single ownership. >> >> - Nicolas. >> >> On 9/21/13 9:17 AM, "Ed Willink" wrote: >> >>> Hi >>> >>> For CMOF the QVT specification may be tenable. >>> >>> For EMOF the QVT specification is broken, and following David's query, >>>I >>> favour seeing what happens implementation-wise if a Transformation is a >>> just Class with some appropriate WFRs. It is not clear to me that there >>> are any necessary facilities of Package that are missing. The only >>> inconvenience is that a QVT AS model will need an explicit Package to >>> contain the Transformation. >>> >>> Since no one is able to produce killer reasons for Class/Package >>> behaviour by analysis, I don't see much point in further discussion >>> without some empirical discovery. >>> >>> [I already did one experiment with editors for QVTr, QVTc making >>> Transformation just a Package, which consequently required the new >>> features Transformation::ownedAttributes, >>>Transformation::ownedFunctions >>> to repair the damage. It worked and was fairly painless, but we have >>>the >>> surprise that if QVT Functions are Operations, then not all Operations >>> are owned by a Type. The alternative of making a Transformation just a >>> Class may require no repairs and may have no surprises; just the >>> containing Package inconvenience.] >>> >>> [In Eclipse, leveraging the UML-aligned OCL Pivot model, the principles >>> of Basic Constructs and EMOF are pursued so there is only single >>> containment, which was where this discussion started.] >>> >>> Regards >>> >>> Ed Willink >>> >>> On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: >>>> Hi Nicolas, >>>> >>>> As Ed commented, that nicely works for UML models, however it >>>> struggles using EMOF/Ecore: Those properties are not only derived, as >>>> you have pointed out, but also they subset >>>> "Pacakage::packagedElement". Refining and subsetting is not allowed in >>>> EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). >>>> >>>> It doesn't work in genuine Ecore models neither, so, for instance, the >>>> QVTo metamodel you mentioned in your previous email, indeed, is using >>>> two different non-derived contaiment EReferences >>>> (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs in >>>> the new Pivot-based metamodel (Package::nestedPackage, >>>> Package::ownedType). >>>> >>>> So in the end with EMOF/ECore we have to deal with two different >>>> non-derived containment properties. Are these metamodels wrong/bad >>>> designed? Are they right but limited by EMF/EMOF? Do we need to sort >>>> out anything in the OMG specifications ? Changing EMOF what this >>>> respects without a sort of sensible Ecore adoption is not acceptable, >>>> in my honest opinion. >>>> >>>> In my opinion, as we have current MOF/UML/QVT specifications, this >>>> doesn't seem to be consistent. Providing that EMOF were right (just a >>>> possible invalid premise), and we wanted to preserve the double >>>> inheritance, I'd at least add the constraint about which containment >>>> reference to use when nesting a Module/Transformation inside a >>>>Package. >>>> >>>> Also note, that the QVT specification talks about a QVT for CMOF. >>>> Unfortunately, QVT specification is related in terms of EMOF and >>>> reserves an specific chapter about QVT for CMOF. Perhaps, for future >>>> specification changes, it could be worthy align the specification to >>>> the style used by MOF (and for instance, OCL) specification, that is, >>>> talk about QVT in terms of CMOF (or UML), and then include an specific >>>> chapter to have a QVT for EMOF (which could, similarly to what MOF >>>> specification does, add a set of restrictions to define QVT for EMOF). >>>> >>>> Thoughts? >>>> >>>> Anyway, looking forward to hearing about your conclusions in New >>>> Brunswick. Good luck. >>>> >>>> Cheers, >>>> Adolfo. >>>> -- >>>> On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: >>>>> Adolfo, >>>>> >>>>> There is no problem with: >>>>> >>>>> Package::/nestedPackage (whose opposite is Package::nestingPackage) >>>>> Package::/ownedType (whose opposite is Type::package) >>>>> >>>>> These are derived properties. >>>>> >>>>> So, a Transformation that is both a Package and a Class will show up >>>>>in >>>>> its parent Package as both Package::/nestedPackage and >>>>> Package::/ownedType. >>>>> There's only one ownership, that's Package::packagedElement (a >>>>> non-derived property). >>>>> >>>>> - Nicolas. >>>>> >>>>> >>>>> From: Adolfo Sanchez Barbudo>>>> > >>>>> Date: Wednesday, September 18, 2013 2:17 PM >>>>> To: Nicolas Rouquette>>>> > >>>>> Cc: Ed Willink>, >>>>> "qvt-rtf@omg.org">>>> >, "Wartik, Steven P Steve">>>> > >>>>> Subject: Re: issue 18912 : Transformation is both Package and Class >>>>> >>>>> Hi Nicolas, >>>>> >>>>> I didn´t mean there was a problem with EMOF constraints. I meant that >>>>> as >>>>> well as EMOF add constraints to define a more convenient UML subset >>>>>for >>>>> its definition. The same could be done with QVT what respect to EMOF. >>>>> As >>>>> I see, the main issue (there could be others) is that a >>>>>Transformation >>>>> may be contained in a Package via two containment properties: >>>>> >>>>> Package::nestedPackage (whose opposite is Package::nestingPackage) >>>>> Package::ownedType (whose opposite is Type::package) >>>>> >>>>> What Ed noticed is that a Transformation can´t be contained in a >>>>> package >>>>> via those properties. It´s coherent that Transformation may have a >>>>> container package (via Type::package property) because it´s a Class, >>>>>as >>>>> well as a container package (via Package::nestingPackage) because >>>>>it´s >>>>> Package. Should we allow a Transformation be contained in any of >>>>>those >>>>> containment properties?. I think that this could be constrained to >>>>> mandate a Module/Transformation be contained via one of them. >>>>> >>>>> We agree that for QVTo (Module) this double inheritance is very >>>>> convenient. >>>>> >>>>> I´m simply proposing to add a new WFR (to the QVT spec) which states >>>>> that Module (and may be to Transformation) must have an empty >>>>> Type::package value, avoiding any ambiguity, and solving this >>>>> particular >>>>> issue without breaking the Class-Package inheritance. >>>>> >>>>> Providing that UML doesn´t mandate that a type needs to belong to a >>>>> package, and as far as I reviewed this evening, EMOF doesn´t do so >>>>> neither... I´m simply proposing a new constraint to Module to clarify >>>>> and avoid interpretation about how these properties must be >>>>>considered >>>>> when dealing with QVT models. >>>>> >>>>> context Module: >>>>> inv : self.package->isEmpty() >>>>> >>>>> Does this make sense ? >>>>> >>>>> Cheers, >>>>> Adolfo. >>>>> >>>>> >>>>> 2013/9/18 Rouquette, Nicolas F >>>>>(313K)>>>> > >>>>> >>>>> Adolpho, Ed, >>>>> >>>>> I still don't understand what is the problem with defining a >>>>> transformation as a specialization of both Class and Package. >>>>> >>>>> Are there any problems with the MOF 2.4.1 OCL rules for EMOF >>>>> and/or CMOF >>>>> metamodels? >>>>> If so, which of these OCL rules are violated? >>>>> >>>>> http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl >>>>> http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl >>>>> >>>>> I got the impression that the problem isn't with the MOF 2.4.1 >>>>>EMOF >>>>> constraints per se but with implementing the QVT metamodel >>>>>(base? >>>>> Core? >>>>> Relational? Operational?) as an extension of an EMOF metamodel. >>>>> >>>>> The original Eclipse QVTO implementation that I use defines >>>>> QVTO::expressions::Module as an extension of both >>>>> org.eclipse.emf.ecore.EPackage and org.eclipse.emf.ecore.EClass. >>>>> Since these are interfaces, it's OK to have multiple >>>>>inheritance. >>>>> >>>>> Am I missing something else? >>>>> >>>>> - Nicolas. >>>>> >>>>> >>>>> On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" >>>>> > >>>>>wrote: >>>>> >>>>>> Steve, >>>>>> >>>>>> Since QVTo has being influenced by traditional OOP languages, >>>>>> specifically java, QVTo Transformations (Modules) indeed are very >>>>>> (Java-)Class-ish: >>>>>> >>>>>> - may have a main operation (see section 8.1.1) >>>>>> - are instantiable (see section 8.1.11) >>>>>> - and executed (see again section 8.1.11 or the libray transform() >>>>>> operation in section 8.3.6.1) >>>>>> >>>>>> Regardless which are the final conclusion you get the next week, >>>>>> regarding both the declarative Transformation and/or the imperative >>>>>> Module, I think that the problem noticed by Ed needs to be addressed >>>>>> (taking also into consideration that QVT claims to be an EMOF and >>>>>> EssentialOCL extension), even with simple WFR which, for instance, >>>>>> prohibit a Transformations and/or Module be owned via an ownedType >>>>>> reference. >>>>>> >>>>>> An additional constraint in the fashion they are defined for the >>>>>>EMOF >>>>>> metamodel could sort the original (main problem): >>>>>> >>>>>> Type::package must be empty. >>>>>> >>>>>> Even better with some OCL: >>>>>> >>>>>> context Module >>>>>> inv : package->isEmpty() >>>>>> >>>>>> Another hint in this line, is that UML spec doesn't mandate a type >>>>> to be >>>>>> owned by a package: >>>>>> >>>>>> package : Package [0..1]{subsets >>>>>> A_packagedElement_owningPackage::owningPackage} (opposite >>>>>> Package::ownedType) >>>>>> Specifies the owning Package of this Type, if any. >>>>>> >>>>>> Just some ideas/alternatives to think about. Maybe there are other >>>>>> implications which can't simply be handle with WFR. I hope the >>>>>>meeting >>>>>> is fruitful. >>>>>> >>>>>> Cheers, >>>>>> Adolfo. >>>>>> On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >>>>>>> Nicolas, >>>>>>> >>>>>>> The execution semantics of a transformation definitely hinges on a >>>>>>> transformation being a kind of class. >>>>>>> >>>>>>> UML does not define any execution semantics for a package. >>>>>>> >>>>>>> It makes no sense to duplicate all of this machinery. >>>>>>> >>>>>>> Does one execute a transformation? I had always considered a >>>>>>> transformation to be a packaging construct. To my way of thinking, >>>>>>> what¹s executed is one of a transformation¹s top relations. >>>>>>> >>>>>>> Wish I could be in New Brunswick to discuss the matter. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve Wartik >>>>>>> >>>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: >>>> 09/20/13 >>>> >>>> >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>09/21/13 > From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgCAA7cRAIAABcqA//+wPICAAHqSgP//k+CAABAgEQD//4zugA== Date: Sat, 21 Sep 2013 20:13:10 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r8LKDJc0027418 Content-Transfer-Encoding: 8bit The href is of the form # See MOF/XMI 7.10.2.2 Linking across Documents. The MOF/XMI spec only defines a URI for a package. Classes don't have URIs. - Nicolas. On 9/21/13 1:05 PM, "Ed Willink" wrote: >Hi > >I'm obviously missing something. > >If a Transformation is a Class then it can be referenced in just the >same way as any other Class might be, possibly as a Class.superCass, >possibly as a TypedElement.type. > >e.g. > > >href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes#Boolean"/> > >Boolean has no URI but we can still use it. > >I've not studied MOF serialization, but if it fails to provide a generic >policy for all UML Elements, we may indeed have to do some more >specifying. > > Regards > > Ed Willink > > > >On 21/09/2013 20:23, Rouquette, Nicolas F (313K) wrote: >> Ed, >> >> Well, it's two things: >> >> - having a URI (it was added in MOF 2.4.1; before that, it was based on >> the MOF tag org.omg.xmi.nsURI) >> - MOF/XMI mapping which uses a Package's URI as the basis for defining >>the >> URI of the package able elements in that Package. >> >> So even if you were to define QVT::Transformation as a kind of >>EMOF::Class >> + the Package capabilities, including URI, the MOF/XMI spec then says >> nothing about how we can reference anything defined in a transformation. >> >> For example, if we have 2 transformations, T1 and T2 where T2 extends >>T1, >> then we can, in principle, override T1's operations (I.e., mapping >>rules, >> helpers, etc.) in T2. >> For this to work at the level of persisted serializations of these >> transformations, then T1 and T2 must be kinds of EMOF::Packages >>otherwise >> the MOF/XMI mapping spec is useless and one would have to define the >> MOF/XMI serialization of QVT::Transformations. >> >> How this affects the Eclipse implementation is a different matter; the >> point here is that at the level of the OMG specs, QVT::Transformation >> really must be both a kind of Class and Package. >> Since it can't be both EMOF::Class and EMOF::Package, then unless we >>have >> the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF >>extension. >> >> - Nicolas. >> >> On 9/21/13 11:50 AM, "Ed Willink" wrote: >> >>> Hi Nicolas >>> >>> So the only problem with Transformation being just a Class is a URI >>> attribute! >>> >>> IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. >>> >>> We can very easily add a Transformation::URI attribute if it's needed, >>> but given the total absence of any concrete syntax to support it, it is >>> clearly not critical and can easily be provided by a containing >>> Package/Model and a URI fragment. >>> >>> EMF convenience is a poor justification for changing specifications. >>> However EMOF is there to be efficient and QVT should support it, so >>> Transformation/Module as just a Class seems really worth investigation. >>> >>> Regards >>> >>> Ed Willink >>> >>> On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: >>>> Thanks Ed and Adolfo for your clarifying explanations. >>>> >>>> First, 18912 is a genuine issue with the QVT spec. >>>> >>>> Second, since EMOF precludes subsetting and redefinition, it >>>>effectively >>>> implies that EMOF::Package and EMOF::Class must be disjoint. >>>> This is clearly a subtle consequence that escaped several reviews of >>>>QVT >>>> 1.0 and 1.1 before. >>>> This consequence should be clarified in the MOF spec -- I.e., this is >>>>a >>>> new MOF-specific issue. >>>> Who should we credit this issue to? >>>> >>>> Third, we can't define QVT::Transformation as just an EMOF::Class. >>>> As a kind of EMOF::Package, a QVT::Transformation gains >>>> EMOF::Package::URI. >>>> The QVT spec should provide concrete syntax for specifying the URI of >>>>a >>>> transformation as a kind of EMOF::Package. >>>> This is a new issue that is a consequence of the changes made from MOF >>>> 2.1 >>>> to MOF 2.4.1. >>>> >>>> Without an owning EMOF::Package, an EMOF::Class does not have a URI; >>>> I.e., >>>> we cannot say that transformation T1 (whose URI is T1.URI) imports >>>> transformation T2 (whose URI is T2.URI). >>>> The URI of a QVT::Transformation is really important for deploying and >>>> reusing compiled transformations. >>>> >>>> >>>> My recommendation would be to consider changing the definition of QVT >>>> to a >>>> CMOF-based metamodel, not EMOF. >>>> This would allow us to define QVT::Transformation as both a kind of >>>> CMOF::Package and CMOF::Class. >>>> >>>> There may be some problems with EMF, which is a kind of strange thing >>>> that >>>> is mostly EMOF with some CMOF capabilities. >>>> It would be reasonable to raise bugzilla issue against EMF to enable >>>>the >>>> proper construction of QVT where QVT::Transformation is both a kind of >>>> EMOF::Epackage and EMOF::Eclass with single ownership. >>>> >>>> - Nicolas. >>>> >>>> On 9/21/13 9:17 AM, "Ed Willink" wrote: >>>> >>>>> Hi >>>>> >>>>> For CMOF the QVT specification may be tenable. >>>>> >>>>> For EMOF the QVT specification is broken, and following David's >>>>>query, >>>>> I >>>>> favour seeing what happens implementation-wise if a Transformation >>>>>is a >>>>> just Class with some appropriate WFRs. It is not clear to me that >>>>>there >>>>> are any necessary facilities of Package that are missing. The only >>>>> inconvenience is that a QVT AS model will need an explicit Package to >>>>> contain the Transformation. >>>>> >>>>> Since no one is able to produce killer reasons for Class/Package >>>>> behaviour by analysis, I don't see much point in further discussion >>>>> without some empirical discovery. >>>>> >>>>> [I already did one experiment with editors for QVTr, QVTc making >>>>> Transformation just a Package, which consequently required the new >>>>> features Transformation::ownedAttributes, >>>>> Transformation::ownedFunctions >>>>> to repair the damage. It worked and was fairly painless, but we have >>>>> the >>>>> surprise that if QVT Functions are Operations, then not all >>>>>Operations >>>>> are owned by a Type. The alternative of making a Transformation just >>>>>a >>>>> Class may require no repairs and may have no surprises; just the >>>>> containing Package inconvenience.] >>>>> >>>>> [In Eclipse, leveraging the UML-aligned OCL Pivot model, the >>>>>principles >>>>> of Basic Constructs and EMOF are pursued so there is only single >>>>> containment, which was where this discussion started.] >>>>> >>>>> Regards >>>>> >>>>> Ed Willink >>>>> >>>>> On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: >>>>>> Hi Nicolas, >>>>>> >>>>>> As Ed commented, that nicely works for UML models, however it >>>>>> struggles using EMOF/Ecore: Those properties are not only derived, >>>>>>as >>>>>> you have pointed out, but also they subset >>>>>> "Pacakage::packagedElement". Refining and subsetting is not allowed >>>>>>in >>>>>> EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). >>>>>> >>>>>> It doesn't work in genuine Ecore models neither, so, for instance, >>>>>>the >>>>>> QVTo metamodel you mentioned in your previous email, indeed, is >>>>>>using >>>>>> two different non-derived contaiment EReferences >>>>>> (EPackage::eSubpcakges and EPackage::eClassifiers). The same occurs >>>>>>in >>>>>> the new Pivot-based metamodel (Package::nestedPackage, >>>>>> Package::ownedType). >>>>>> >>>>>> So in the end with EMOF/ECore we have to deal with two different >>>>>> non-derived containment properties. Are these metamodels wrong/bad >>>>>> designed? Are they right but limited by EMF/EMOF? Do we need to sort >>>>>> out anything in the OMG specifications ? Changing EMOF what this >>>>>> respects without a sort of sensible Ecore adoption is not >>>>>>acceptable, >>>>>> in my honest opinion. >>>>>> >>>>>> In my opinion, as we have current MOF/UML/QVT specifications, this >>>>>> doesn't seem to be consistent. Providing that EMOF were right (just >>>>>>a >>>>>> possible invalid premise), and we wanted to preserve the double >>>>>> inheritance, I'd at least add the constraint about which containment >>>>>> reference to use when nesting a Module/Transformation inside a >>>>>> Package. >>>>>> >>>>>> Also note, that the QVT specification talks about a QVT for CMOF. >>>>>> Unfortunately, QVT specification is related in terms of EMOF and >>>>>> reserves an specific chapter about QVT for CMOF. Perhaps, for future >>>>>> specification changes, it could be worthy align the specification to >>>>>> the style used by MOF (and for instance, OCL) specification, that >>>>>>is, >>>>>> talk about QVT in terms of CMOF (or UML), and then include an >>>>>>specific >>>>>> chapter to have a QVT for EMOF (which could, similarly to what MOF >>>>>> specification does, add a set of restrictions to define QVT for >>>>>>EMOF). >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Anyway, looking forward to hearing about your conclusions in New >>>>>> Brunswick. Good luck. >>>>>> >>>>>> Cheers, >>>>>> Adolfo. >>>>>> -- >>>>>> On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: >>>>>>> Adolfo, >>>>>>> >>>>>>> There is no problem with: >>>>>>> >>>>>>> Package::/nestedPackage (whose opposite is Package::nestingPackage) >>>>>>> Package::/ownedType (whose opposite is Type::package) >>>>>>> >>>>>>> These are derived properties. >>>>>>> >>>>>>> So, a Transformation that is both a Package and a Class will show >>>>>>>up >>>>>>> in >>>>>>> its parent Package as both Package::/nestedPackage and >>>>>>> Package::/ownedType. >>>>>>> There's only one ownership, that's Package::packagedElement (a >>>>>>> non-derived property). >>>>>>> >>>>>>> - Nicolas. >>>>>>> >>>>>>> >>>>>>> From: Adolfo Sanchez Barbudo>>>>>> > >>>>>>> Date: Wednesday, September 18, 2013 2:17 PM >>>>>>> To: Nicolas Rouquette>>>>>> > >>>>>>> Cc: Ed Willink>, >>>>>>> "qvt-rtf@omg.org">>>>>> >, "Wartik, Steven P Steve">>>>>> > >>>>>>> Subject: Re: issue 18912 : Transformation is both Package and Class >>>>>>> >>>>>>> Hi Nicolas, >>>>>>> >>>>>>> I didn´t mean there was a problem with EMOF constraints. I meant >>>>>>>that >>>>>>> as >>>>>>> well as EMOF add constraints to define a more convenient UML subset >>>>>>> for >>>>>>> its definition. The same could be done with QVT what respect to >>>>>>>EMOF. >>>>>>> As >>>>>>> I see, the main issue (there could be others) is that a >>>>>>> Transformation >>>>>>> may be contained in a Package via two containment properties: >>>>>>> >>>>>>> Package::nestedPackage (whose opposite is Package::nestingPackage) >>>>>>> Package::ownedType (whose opposite is Type::package) >>>>>>> >>>>>>> What Ed noticed is that a Transformation can´t be contained in a >>>>>>> package >>>>>>> via those properties. It´s coherent that Transformation may have a >>>>>>> container package (via Type::package property) because it´s a >>>>>>>Class, >>>>>>> as >>>>>>> well as a container package (via Package::nestingPackage) because >>>>>>> it´s >>>>>>> Package. Should we allow a Transformation be contained in any of >>>>>>> those >>>>>>> containment properties?. I think that this could be constrained to >>>>>>> mandate a Module/Transformation be contained via one of them. >>>>>>> >>>>>>> We agree that for QVTo (Module) this double inheritance is very >>>>>>> convenient. >>>>>>> >>>>>>> I´m simply proposing to add a new WFR (to the QVT spec) which >>>>>>>states >>>>>>> that Module (and may be to Transformation) must have an empty >>>>>>> Type::package value, avoiding any ambiguity, and solving this >>>>>>> particular >>>>>>> issue without breaking the Class-Package inheritance. >>>>>>> >>>>>>> Providing that UML doesn´t mandate that a type needs to belong to a >>>>>>> package, and as far as I reviewed this evening, EMOF doesn´t do so >>>>>>> neither... I´m simply proposing a new constraint to Module to >>>>>>>clarify >>>>>>> and avoid interpretation about how these properties must be >>>>>>> considered >>>>>>> when dealing with QVT models. >>>>>>> >>>>>>> context Module: >>>>>>> inv : self.package->isEmpty() >>>>>>> >>>>>>> Does this make sense ? >>>>>>> >>>>>>> Cheers, >>>>>>> Adolfo. >>>>>>> >>>>>>> >>>>>>> 2013/9/18 Rouquette, Nicolas F >>>>>>> (313K)>>>>>> > >>>>>>> >>>>>>> Adolpho, Ed, >>>>>>> >>>>>>> I still don't understand what is the problem with defining a >>>>>>> transformation as a specialization of both Class and Package. >>>>>>> >>>>>>> Are there any problems with the MOF 2.4.1 OCL rules for EMOF >>>>>>> and/or CMOF >>>>>>> metamodels? >>>>>>> If so, which of these OCL rules are violated? >>>>>>> >>>>>>> http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl >>>>>>> http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl >>>>>>> >>>>>>> I got the impression that the problem isn't with the MOF >>>>>>>2.4.1 >>>>>>> EMOF >>>>>>> constraints per se but with implementing the QVT metamodel >>>>>>> (base? >>>>>>> Core? >>>>>>> Relational? Operational?) as an extension of an EMOF >>>>>>>metamodel. >>>>>>> >>>>>>> The original Eclipse QVTO implementation that I use defines >>>>>>> QVTO::expressions::Module as an extension of both >>>>>>> org.eclipse.emf.ecore.EPackage and >>>>>>>org.eclipse.emf.ecore.EClass. >>>>>>> Since these are interfaces, it's OK to have multiple >>>>>>> inheritance. >>>>>>> >>>>>>> Am I missing something else? >>>>>>> >>>>>>> - Nicolas. >>>>>>> >>>>>>> >>>>>>> On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" >>>>>>> > >>>>>>> wrote: >>>>>>> >>>>>>>> Steve, >>>>>>>> >>>>>>>> Since QVTo has being influenced by traditional OOP languages, >>>>>>>> specifically java, QVTo Transformations (Modules) indeed are very >>>>>>>> (Java-)Class-ish: >>>>>>>> >>>>>>>> - may have a main operation (see section 8.1.1) >>>>>>>> - are instantiable (see section 8.1.11) >>>>>>>> - and executed (see again section 8.1.11 or the libray transform() >>>>>>>> operation in section 8.3.6.1) >>>>>>>> >>>>>>>> Regardless which are the final conclusion you get the next week, >>>>>>>> regarding both the declarative Transformation and/or the >>>>>>>>imperative >>>>>>>> Module, I think that the problem noticed by Ed needs to be >>>>>>>>addressed >>>>>>>> (taking also into consideration that QVT claims to be an EMOF and >>>>>>>> EssentialOCL extension), even with simple WFR which, for instance, >>>>>>>> prohibit a Transformations and/or Module be owned via an ownedType >>>>>>>> reference. >>>>>>>> >>>>>>>> An additional constraint in the fashion they are defined for the >>>>>>>> EMOF >>>>>>>> metamodel could sort the original (main problem): >>>>>>>> >>>>>>>> Type::package must be empty. >>>>>>>> >>>>>>>> Even better with some OCL: >>>>>>>> >>>>>>>> context Module >>>>>>>> inv : package->isEmpty() >>>>>>>> >>>>>>>> Another hint in this line, is that UML spec doesn't mandate a type >>>>>>> to be >>>>>>>> owned by a package: >>>>>>>> >>>>>>>> package : Package [0..1]{subsets >>>>>>>> A_packagedElement_owningPackage::owningPackage} (opposite >>>>>>>> Package::ownedType) >>>>>>>> Specifies the owning Package of this Type, if any. >>>>>>>> >>>>>>>> Just some ideas/alternatives to think about. Maybe there are other >>>>>>>> implications which can't simply be handle with WFR. I hope the >>>>>>>> meeting >>>>>>>> is fruitful. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Adolfo. >>>>>>>> On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >>>>>>>>> Nicolas, >>>>>>>>> >>>>>>>>> The execution semantics of a transformation definitely hinges on >>>>>>>>>a >>>>>>>>> transformation being a kind of class. >>>>>>>>> >>>>>>>>> UML does not define any execution semantics for a package. >>>>>>>>> >>>>>>>>> It makes no sense to duplicate all of this machinery. >>>>>>>>> >>>>>>>>> Does one execute a transformation? I had always considered a >>>>>>>>> transformation to be a packaging construct. To my way of >>>>>>>>>thinking, >>>>>>>>> what¹s executed is one of a transformation¹s top relations. >>>>>>>>> >>>>>>>>> Wish I could be in New Brunswick to discuss the matter. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve Wartik >>>>>>>>> >>>>>> ----- >>>>>> No virus found in this message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: >>>>>> 09/20/13 >>>>>> >>>>>> >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>>> 09/21/13 >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>09/21/13 > From: "Rouquette, Nicolas F (313K)" To: Ed Willink , "qvt-rtf@omg.org" Subject: Re: issue 18912 : Transformation is both Package and Class Thread-Topic: issue 18912 : Transformation is both Package and Class Thread-Index: AQHOsvbBBHAxbclvdUW4gWMeZ1f/TZnIkxyAgAC0RQCAAA4DgIACe2dQgACODID//49+AIAAii2AgACmFgCAA7cRAIAABcqA//+wPICAAHqSgP//k+CAABAgEQD//4zugIAAlwQA//+SRYA= Date: Sat, 21 Sep 2013 22:40:56 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id r8LMf3jg016539 Content-Transfer-Encoding: 8bit Ed, How do you propose to specify this outer containing package? There's no abstract or concrete syntax for this in QVT 1.1 but I suppose that could be fixed as part of a resolution for 18912. - Nicolas. On 9/21/13 3:13 PM, "Ed Willink" wrote: >Hi Nicolas > >Exactly; so if we have an outer package there is no problem with >referencing a Transformation that is just a Class as > ># > > Regards > > Ed Willink > >On 21/09/2013 21:13, Rouquette, Nicolas F (313K) wrote: >> The href is of the form# >> >> See MOF/XMI 7.10.2.2 Linking across Documents. >> The MOF/XMI spec only defines a URI for a package. >> Classes don't have URIs. >> >> - Nicolas. >> >> On 9/21/13 1:05 PM, "Ed Willink" wrote: >> >>> Hi >>> >>> I'm obviously missing something. >>> >>> If a Transformation is a Class then it can be referenced in just the >>> same way as any other Class might be, possibly as a Class.superCass, >>> possibly as a TypedElement.type. >>> >>> e.g. >>> >>> >> >>> href="http://www.omg.org/spec/UML/20131001/PrimitiveTypes#Boolean"/> >>> >>> Boolean has no URI but we can still use it. >>> >>> I've not studied MOF serialization, but if it fails to provide a >>>generic >>> policy for all UML Elements, we may indeed have to do some more >>> specifying. >>> >>> Regards >>> >>> Ed Willink >>> >>> >>> >>> On 21/09/2013 20:23, Rouquette, Nicolas F (313K) wrote: >>>> Ed, >>>> >>>> Well, it's two things: >>>> >>>> - having a URI (it was added in MOF 2.4.1; before that, it was based >>>>on >>>> the MOF tag org.omg.xmi.nsURI) >>>> - MOF/XMI mapping which uses a Package's URI as the basis for defining >>>> the >>>> URI of the package able elements in that Package. >>>> >>>> So even if you were to define QVT::Transformation as a kind of >>>> EMOF::Class >>>> + the Package capabilities, including URI, the MOF/XMI spec then says >>>> nothing about how we can reference anything defined in a >>>>transformation. >>>> >>>> For example, if we have 2 transformations, T1 and T2 where T2 extends >>>> T1, >>>> then we can, in principle, override T1's operations (I.e., mapping >>>> rules, >>>> helpers, etc.) in T2. >>>> For this to work at the level of persisted serializations of these >>>> transformations, then T1 and T2 must be kinds of EMOF::Packages >>>> otherwise >>>> the MOF/XMI mapping spec is useless and one would have to define the >>>> MOF/XMI serialization of QVT::Transformations. >>>> >>>> How this affects the Eclipse implementation is a different matter; the >>>> point here is that at the level of the OMG specs, QVT::Transformation >>>> really must be both a kind of Class and Package. >>>> Since it can't be both EMOF::Class and EMOF::Package, then unless we >>>> have >>>> the MOF 2.5 RTF fix EMOF, we will have to define QVT as a CMOF >>>> extension. >>>> >>>> - Nicolas. >>>> >>>> On 9/21/13 11:50 AM, "Ed Willink" wrote: >>>> >>>>> Hi Nicolas >>>>> >>>>> So the only problem with Transformation being just a Class is a URI >>>>> attribute! >>>>> >>>>> IIRC UML Packages didn't have a URI attribute when QVT 1.0 came out. >>>>> >>>>> We can very easily add a Transformation::URI attribute if it's >>>>>needed, >>>>> but given the total absence of any concrete syntax to support it, it >>>>>is >>>>> clearly not critical and can easily be provided by a containing >>>>> Package/Model and a URI fragment. >>>>> >>>>> EMF convenience is a poor justification for changing specifications. >>>>> However EMOF is there to be efficient and QVT should support it, so >>>>> Transformation/Module as just a Class seems really worth >>>>>investigation. >>>>> >>>>> Regards >>>>> >>>>> Ed Willink >>>>> >>>>> On 21/09/2013 19:31, Rouquette, Nicolas F (313K) wrote: >>>>>> Thanks Ed and Adolfo for your clarifying explanations. >>>>>> >>>>>> First, 18912 is a genuine issue with the QVT spec. >>>>>> >>>>>> Second, since EMOF precludes subsetting and redefinition, it >>>>>> effectively >>>>>> implies that EMOF::Package and EMOF::Class must be disjoint. >>>>>> This is clearly a subtle consequence that escaped several reviews of >>>>>> QVT >>>>>> 1.0 and 1.1 before. >>>>>> This consequence should be clarified in the MOF spec -- I.e., this >>>>>>is >>>>>> a >>>>>> new MOF-specific issue. >>>>>> Who should we credit this issue to? >>>>>> >>>>>> Third, we can't define QVT::Transformation as just an EMOF::Class. >>>>>> As a kind of EMOF::Package, a QVT::Transformation gains >>>>>> EMOF::Package::URI. >>>>>> The QVT spec should provide concrete syntax for specifying the URI >>>>>>of >>>>>> a >>>>>> transformation as a kind of EMOF::Package. >>>>>> This is a new issue that is a consequence of the changes made from >>>>>>MOF >>>>>> 2.1 >>>>>> to MOF 2.4.1. >>>>>> >>>>>> Without an owning EMOF::Package, an EMOF::Class does not have a URI; >>>>>> I.e., >>>>>> we cannot say that transformation T1 (whose URI is T1.URI) imports >>>>>> transformation T2 (whose URI is T2.URI). >>>>>> The URI of a QVT::Transformation is really important for deploying >>>>>>and >>>>>> reusing compiled transformations. >>>>>> >>>>>> >>>>>> My recommendation would be to consider changing the definition of >>>>>>QVT >>>>>> to a >>>>>> CMOF-based metamodel, not EMOF. >>>>>> This would allow us to define QVT::Transformation as both a kind of >>>>>> CMOF::Package and CMOF::Class. >>>>>> >>>>>> There may be some problems with EMF, which is a kind of strange >>>>>>thing >>>>>> that >>>>>> is mostly EMOF with some CMOF capabilities. >>>>>> It would be reasonable to raise bugzilla issue against EMF to enable >>>>>> the >>>>>> proper construction of QVT where QVT::Transformation is both a kind >>>>>>of >>>>>> EMOF::Epackage and EMOF::Eclass with single ownership. >>>>>> >>>>>> - Nicolas. >>>>>> >>>>>> On 9/21/13 9:17 AM, "Ed Willink" wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> For CMOF the QVT specification may be tenable. >>>>>>> >>>>>>> For EMOF the QVT specification is broken, and following David's >>>>>>> query, >>>>>>> I >>>>>>> favour seeing what happens implementation-wise if a Transformation >>>>>>> is a >>>>>>> just Class with some appropriate WFRs. It is not clear to me that >>>>>>> there >>>>>>> are any necessary facilities of Package that are missing. The only >>>>>>> inconvenience is that a QVT AS model will need an explicit Package >>>>>>>to >>>>>>> contain the Transformation. >>>>>>> >>>>>>> Since no one is able to produce killer reasons for Class/Package >>>>>>> behaviour by analysis, I don't see much point in further discussion >>>>>>> without some empirical discovery. >>>>>>> >>>>>>> [I already did one experiment with editors for QVTr, QVTc making >>>>>>> Transformation just a Package, which consequently required the new >>>>>>> features Transformation::ownedAttributes, >>>>>>> Transformation::ownedFunctions >>>>>>> to repair the damage. It worked and was fairly painless, but we >>>>>>>have >>>>>>> the >>>>>>> surprise that if QVT Functions are Operations, then not all >>>>>>> Operations >>>>>>> are owned by a Type. The alternative of making a Transformation >>>>>>>just >>>>>>> a >>>>>>> Class may require no repairs and may have no surprises; just the >>>>>>> containing Package inconvenience.] >>>>>>> >>>>>>> [In Eclipse, leveraging the UML-aligned OCL Pivot model, the >>>>>>> principles >>>>>>> of Basic Constructs and EMOF are pursued so there is only single >>>>>>> containment, which was where this discussion started.] >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Ed Willink >>>>>>> >>>>>>> On 21/09/2013 16:56, Adolfo Sáhez-Barbudo Herrera wrote: >>>>>>>> Hi Nicolas, >>>>>>>> >>>>>>>> As Ed commented, that nicely works for UML models, however it >>>>>>>> struggles using EMOF/Ecore: Those properties are not only derived, >>>>>>>> as >>>>>>>> you have pointed out, but also they subset >>>>>>>> "Pacakage::packagedElement". Refining and subsetting is not >>>>>>>>allowed >>>>>>>> in >>>>>>>> EMOF (See constraint [9] in page 36 - MOF 2.4.1 spec). >>>>>>>> >>>>>>>> It doesn't work in genuine Ecore models neither, so, for instance, >>>>>>>> the >>>>>>>> QVTo metamodel you mentioned in your previous email, indeed, is >>>>>>>> using >>>>>>>> two different non-derived contaiment EReferences >>>>>>>> (EPackage::eSubpcakges and EPackage::eClassifiers). The same >>>>>>>>occurs >>>>>>>> in >>>>>>>> the new Pivot-based metamodel (Package::nestedPackage, >>>>>>>> Package::ownedType). >>>>>>>> >>>>>>>> So in the end with EMOF/ECore we have to deal with two different >>>>>>>> non-derived containment properties. Are these metamodels wrong/bad >>>>>>>> designed? Are they right but limited by EMF/EMOF? Do we need to >>>>>>>>sort >>>>>>>> out anything in the OMG specifications ? Changing EMOF what this >>>>>>>> respects without a sort of sensible Ecore adoption is not >>>>>>>> acceptable, >>>>>>>> in my honest opinion. >>>>>>>> >>>>>>>> In my opinion, as we have current MOF/UML/QVT specifications, this >>>>>>>> doesn't seem to be consistent. Providing that EMOF were right >>>>>>>>(just >>>>>>>> a >>>>>>>> possible invalid premise), and we wanted to preserve the double >>>>>>>> inheritance, I'd at least add the constraint about which >>>>>>>>containment >>>>>>>> reference to use when nesting a Module/Transformation inside a >>>>>>>> Package. >>>>>>>> >>>>>>>> Also note, that the QVT specification talks about a QVT for CMOF. >>>>>>>> Unfortunately, QVT specification is related in terms of EMOF and >>>>>>>> reserves an specific chapter about QVT for CMOF. Perhaps, for >>>>>>>>future >>>>>>>> specification changes, it could be worthy align the specification >>>>>>>>to >>>>>>>> the style used by MOF (and for instance, OCL) specification, that >>>>>>>> is, >>>>>>>> talk about QVT in terms of CMOF (or UML), and then include an >>>>>>>> specific >>>>>>>> chapter to have a QVT for EMOF (which could, similarly to what MOF >>>>>>>> specification does, add a set of restrictions to define QVT for >>>>>>>> EMOF). >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Anyway, looking forward to hearing about your conclusions in New >>>>>>>> Brunswick. Good luck. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Adolfo. >>>>>>>> -- >>>>>>>> On 19/09/2013 15:12, Rouquette, Nicolas F (313K) wrote: >>>>>>>>> Adolfo, >>>>>>>>> >>>>>>>>> There is no problem with: >>>>>>>>> >>>>>>>>> Package::/nestedPackage (whose opposite is >>>>>>>>>Package::nestingPackage) >>>>>>>>> Package::/ownedType (whose opposite is Type::package) >>>>>>>>> >>>>>>>>> These are derived properties. >>>>>>>>> >>>>>>>>> So, a Transformation that is both a Package and a Class will show >>>>>>>>> up >>>>>>>>> in >>>>>>>>> its parent Package as both Package::/nestedPackage and >>>>>>>>> Package::/ownedType. >>>>>>>>> There's only one ownership, that's Package::packagedElement (a >>>>>>>>> non-derived property). >>>>>>>>> >>>>>>>>> - Nicolas. >>>>>>>>> >>>>>>>>> >>>>>>>>> From: Adolfo Sanchez Barbudo>>>>>>>> > >>>>>>>>> Date: Wednesday, September 18, 2013 2:17 PM >>>>>>>>> To: Nicolas Rouquette>>>>>>>> > >>>>>>>>> Cc: Ed Willink>, >>>>>>>>> "qvt-rtf@omg.org">>>>>>>> >, "Wartik, Steven P >>>>>>>>>Steve">>>>>>>> > >>>>>>>>> Subject: Re: issue 18912 : Transformation is both Package and >>>>>>>>>Class >>>>>>>>> >>>>>>>>> Hi Nicolas, >>>>>>>>> >>>>>>>>> I didn´t mean there was a problem with EMOF constraints. I meant >>>>>>>>> that >>>>>>>>> as >>>>>>>>> well as EMOF add constraints to define a more convenient UML >>>>>>>>>subset >>>>>>>>> for >>>>>>>>> its definition. The same could be done with QVT what respect to >>>>>>>>> EMOF. >>>>>>>>> As >>>>>>>>> I see, the main issue (there could be others) is that a >>>>>>>>> Transformation >>>>>>>>> may be contained in a Package via two containment properties: >>>>>>>>> >>>>>>>>> Package::nestedPackage (whose opposite is >>>>>>>>>Package::nestingPackage) >>>>>>>>> Package::ownedType (whose opposite is Type::package) >>>>>>>>> >>>>>>>>> What Ed noticed is that a Transformation can´t be contained in a >>>>>>>>> package >>>>>>>>> via those properties. It´s coherent that Transformation may have >>>>>>>>>a >>>>>>>>> container package (via Type::package property) because it´s a >>>>>>>>> Class, >>>>>>>>> as >>>>>>>>> well as a container package (via Package::nestingPackage) >>>>>>>>>because >>>>>>>>> it´s >>>>>>>>> Package. Should we allow a Transformation be contained in any of >>>>>>>>> those >>>>>>>>> containment properties?. I think that this could be constrained >>>>>>>>>to >>>>>>>>> mandate a Module/Transformation be contained via one of them. >>>>>>>>> >>>>>>>>> We agree that for QVTo (Module) this double inheritance is very >>>>>>>>> convenient. >>>>>>>>> >>>>>>>>> I´m simply proposing to add a new WFR (to the QVT spec) which >>>>>>>>> states >>>>>>>>> that Module (and may be to Transformation) must have an empty >>>>>>>>> Type::package value, avoiding any ambiguity, and solving this >>>>>>>>> particular >>>>>>>>> issue without breaking the Class-Package inheritance. >>>>>>>>> >>>>>>>>> Providing that UML doesn´t mandate that a type needs to belong >>>>>>>>>to a >>>>>>>>> package, and as far as I reviewed this evening, EMOF doesn´t do >>>>>>>>>so >>>>>>>>> neither... I´m simply proposing a new constraint to Module to >>>>>>>>> clarify >>>>>>>>> and avoid interpretation about how these properties must be >>>>>>>>> considered >>>>>>>>> when dealing with QVT models. >>>>>>>>> >>>>>>>>> context Module: >>>>>>>>> inv : self.package->isEmpty() >>>>>>>>> >>>>>>>>> Does this make sense ? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Adolfo. >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/9/18 Rouquette, Nicolas F >>>>>>>>> (313K)>>>>>>>> > >>>>>>>>> >>>>>>>>> Adolpho, Ed, >>>>>>>>> >>>>>>>>> I still don't understand what is the problem with >>>>>>>>>defining a >>>>>>>>> transformation as a specialization of both Class and >>>>>>>>>Package. >>>>>>>>> >>>>>>>>> Are there any problems with the MOF 2.4.1 OCL rules for >>>>>>>>>EMOF >>>>>>>>> and/or CMOF >>>>>>>>> metamodels? >>>>>>>>> If so, which of these OCL rules are violated? >>>>>>>>> >>>>>>>>> http://www.omg.org/spec/MOF/20110701/EMOFConstraints.ocl >>>>>>>>> http://www.omg.org/spec/MOF/20110701/CMOFConstraints.ocl >>>>>>>>> >>>>>>>>> I got the impression that the problem isn't with the MOF >>>>>>>>> 2.4.1 >>>>>>>>> EMOF >>>>>>>>> constraints per se but with implementing the QVT metamodel >>>>>>>>> (base? >>>>>>>>> Core? >>>>>>>>> Relational? Operational?) as an extension of an EMOF >>>>>>>>> metamodel. >>>>>>>>> >>>>>>>>> The original Eclipse QVTO implementation that I use >>>>>>>>>defines >>>>>>>>> QVTO::expressions::Module as an extension of both >>>>>>>>> org.eclipse.emf.ecore.EPackage and >>>>>>>>> org.eclipse.emf.ecore.EClass. >>>>>>>>> Since these are interfaces, it's OK to have multiple >>>>>>>>> inheritance. >>>>>>>>> >>>>>>>>> Am I missing something else? >>>>>>>>> >>>>>>>>> - Nicolas. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/18/13 12:46 PM, "Adolfo Sáhez-Barbudo Herrera" >>>>>>>>> > >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Steve, >>>>>>>>>> >>>>>>>>>> Since QVTo has being influenced by traditional OOP languages, >>>>>>>>>> specifically java, QVTo Transformations (Modules) indeed are >>>>>>>>>>very >>>>>>>>>> (Java-)Class-ish: >>>>>>>>>> >>>>>>>>>> - may have a main operation (see section 8.1.1) >>>>>>>>>> - are instantiable (see section 8.1.11) >>>>>>>>>> - and executed (see again section 8.1.11 or the libray >>>>>>>>>>transform() >>>>>>>>>> operation in section 8.3.6.1) >>>>>>>>>> >>>>>>>>>> Regardless which are the final conclusion you get the next week, >>>>>>>>>> regarding both the declarative Transformation and/or the >>>>>>>>>> imperative >>>>>>>>>> Module, I think that the problem noticed by Ed needs to be >>>>>>>>>> addressed >>>>>>>>>> (taking also into consideration that QVT claims to be an EMOF >>>>>>>>>>and >>>>>>>>>> EssentialOCL extension), even with simple WFR which, for >>>>>>>>>>instance, >>>>>>>>>> prohibit a Transformations and/or Module be owned via an >>>>>>>>>>ownedType >>>>>>>>>> reference. >>>>>>>>>> >>>>>>>>>> An additional constraint in the fashion they are defined for the >>>>>>>>>> EMOF >>>>>>>>>> metamodel could sort the original (main problem): >>>>>>>>>> >>>>>>>>>> Type::package must be empty. >>>>>>>>>> >>>>>>>>>> Even better with some OCL: >>>>>>>>>> >>>>>>>>>> context Module >>>>>>>>>> inv : package->isEmpty() >>>>>>>>>> >>>>>>>>>> Another hint in this line, is that UML spec doesn't mandate a >>>>>>>>>>type >>>>>>>>> to be >>>>>>>>>> owned by a package: >>>>>>>>>> >>>>>>>>>> package : Package [0..1]{subsets >>>>>>>>>> A_packagedElement_owningPackage::owningPackage} (opposite >>>>>>>>>> Package::ownedType) >>>>>>>>>> Specifies the owning Package of this Type, if any. >>>>>>>>>> >>>>>>>>>> Just some ideas/alternatives to think about. Maybe there are >>>>>>>>>>other >>>>>>>>>> implications which can't simply be handle with WFR. I hope the >>>>>>>>>> meeting >>>>>>>>>> is fruitful. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Adolfo. >>>>>>>>>> On 18/09/2013 19:22, Wartik, Steven P "Steve" wrote: >>>>>>>>>>> Nicolas, >>>>>>>>>>> >>>>>>>>>>> The execution semantics of a transformation definitely hinges >>>>>>>>>>>on >>>>>>>>>>> a >>>>>>>>>>> transformation being a kind of class. >>>>>>>>>>> >>>>>>>>>>> UML does not define any execution semantics for a package. >>>>>>>>>>> >>>>>>>>>>> It makes no sense to duplicate all of this machinery. >>>>>>>>>>> >>>>>>>>>>> Does one execute a transformation? I had always considered a >>>>>>>>>>> transformation to be a packaging construct. To my way of >>>>>>>>>>> thinking, >>>>>>>>>>> what¹s executed is one of a transformation¹s top relations. >>>>>>>>>>> >>>>>>>>>>> Wish I could be in New Brunswick to discuss the matter. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Steve Wartik >>>>>>>>>>> >>>>>>>> ----- >>>>>>>> No virus found in this message. >>>>>>>> Checked by AVG - www.avg.com >>>>>>>> Version: 2013.0.3408 / Virus Database: 3222/6686 - Release Date: >>>>>>>> 09/20/13 >>>>>>>> >>>>>>>> >>>>>> ----- >>>>>> No virus found in this message. >>>>>> Checked by AVG - www.avg.com >>>>>> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>>>>> 09/21/13 >>>> >>>> ----- >>>> No virus found in this message. >>>> Checked by AVG - www.avg.com >>>> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>>> 09/21/13 >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3408 / Virus Database: 3222/6687 - Release Date: >>09/21/13 >