Issue 3446: MOF 1.3 Why have rule against abstract packages? (mof-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: In the MOF 1.3 Specification, constraint C-44, which prevents a package being abstract, does not appear to serve any useful purpose. It does prevent definition of general, abstract metamodels that must be subclassed with more specific metamodels in order to be deployed. A MOF package defines a type of a package extent, and such types support polymorphism through package inheritance. The concept of abstract packages is as useful to metamodeling as the concept of abstract classes is to object modeling. Recommendation: Delete C-44. Resolution: This is a duplicate of issue 4202. Close with no further action. Revised Text: Actions taken: March 22, 2000: received issue December 3, 2001: closed issue Discussion: End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: MOF 1.3 Why have rule against abstract packages? Date: Wed, 22 Mar 2000 17:38:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _CTd9eMh!!ZM(e9M0)e9 In the MOF 1.3 Specification, constraint C-44, which prevents a package being abstract, does not appear to serve any useful purpose. It does prevent definition of general, abstract metamodels that must be subclassed with more specific metamodels in order to be deployed. A MOF package defines a type of a package extent, and such types support polymorphism through package inheritance. The concept of abstract packages is as useful to metamodeling as the concept of abstract classes is to object modeling. Recommendation: Delete C-44. Don Baisley Unisys X-Mailer: exmh version 2.1.0 09/18/1999 To: "Baisley, Donald E" cc: issues@omg.org, crawley@dstc.edu.au Subject: Re: MOF 1.3 Why have rule against abstract packages? In-Reply-To: Message from "Baisley, Donald E" of "Wed, 22 Mar 2000 17:38:13 CST." Mime-Version: 1.0 Date: Thu, 30 Mar 2000 14:58:12 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: C[ld9B^-!!A#!e9B?;!! > In the MOF 1.3 Specification, constraint C-44, which prevents a package > being abstract, does not appear to serve any useful purpose. It does > prevent definition of general, abstract metamodels that must be subclassed > with more specific metamodels in order to be deployed. A MOF package > defines a type of a package extent, and such types support polymorphism > through package inheritance. The concept of abstract packages is as useful > to metamodeling as the concept of abstract classes is to object modeling. > > Recommendation: Delete C-44. In theory you are probably correct. Abstract MOF Packages sound rather useful. However, in practice: 1) This change would further de-align the MOF Model with the UML meta-model. As far as I know, UML does not allow you to declare Packages to be abstract. This is significant for those people who like to use UML tools to prepare MOF meta-models. 2) We would need to analyse the implications of this change for the IDL mapping 3) We would need to work out what restrictions (if any) need to be made on importing, clustering and nesting involving abstract Packages. All in all, I'd prefer that we left this proposed change alone for now. -- Steve X-Mailer: exmh version 2.1.0 09/18/1999 To: mof-rtf@omg.org Subject: Re: MOF 1.3 Why have rule against abstract packages? Mime-Version: 1.0 Date: Mon, 03 Apr 2000 12:29:18 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: eUj!!'X,!!'_`!!KGZ!! > In the MOF 1.3 Specification, constraint C-44, which prevents a package > being abstract, does not appear to serve any useful purpose. It does > prevent definition of general, abstract metamodels that must be subclassed > with more specific metamodels in order to be deployed. A MOF package > defines a type of a package extent, and such types support polymorphism > through package inheritance. The concept of abstract packages is as useful > to metamodeling as the concept of abstract classes is to object modeling. > > Recommendation: Delete C-44. In theory you are probably correct. Abstract MOF Packages sound rather useful. However, in practice: 1) This change would further de-align the MOF Model with the UML meta-model. As far as I know, UML does not allow you to declare Packages to be abstract. This is significant for those people who like to use UML tools to prepare MOF meta-models. 2) We would need to analyse the implications of this change for the IDL mapping 3) We would need to work out what restrictions (if any) need to be made on importing, clustering and nesting involving abstract Packages. All in all, I'd prefer that we left this proposed change alone for now. - -- Steve