Issue 4383: The current MOF package level import is not sufficient (mof-rtf) Source: (Dr. Guus Ramackers, Guus.Ramackers(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: The current MOF package level import is not sufficient. For instance, if a user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can only indicate "Datatypes" in MOF now. What is needed is that the user can say "Datatypes::Boolean" as a dependency. It would be counter-productive to create 12 subpackages of Datatypes and put each datatype in its own Package, just because it would let people reuse individual datatypes (without changing the MOF import rule). Resolution: Revised Text: Actions taken: June 20, 2001: received issue Discussion: End of Annotations:===== From: "Iyengar, Sridhar" To: issues@omg.org, Juergen Boldt Cc: Guus Ramackers Subject: Please log and send me a reference Date: Wed, 20 Jun 2001 15:27:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 1Qed9ben!!SI0e9J/4!! Issue : # (juergen to asssign) The current MOF package level import is not sufficient. For instance, if a user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can only indicate "Datatypes" in MOF now. What is needed is that the user can say "Datatypes::Boolean" as a dependency. It would be counter-productive to create 12 subpackages of Datatypes and put each datatype in its own Package, just because it would let people reuse individual datatypes (without changing the MOF import rule). Raised by Guus Raamackers, Oracle Guus - pls confirm that I have captured the issue to be considered by MOF RTF (of a future RFP correctly) . Note that MOF does support referring to Datatypes::Boolean but this implies a package level dependency. ---------------------------------------------------------------------------- Sridhar Iyengar Unisys Fellow, Director of Advanced Technology 25725, Jeronimo Road Mission Viejo, CA 92691 E-mail : Sridhar.iyengar2@unisys.com Phone : 949-380-5692 Fax : 949-380-6632 ---------------------------------------------------------------------------- ---------- X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Juergen Boldt cc: mof-rtf@emerald.omg.org, Guus Ramackers Subject: Re: issue 4383 -- MOF RTF issue In-Reply-To: Message from Juergen Boldt of "Wed, 20 Jun 2001 17:00:16 -0400." <4.3.2.7.2.20010620165934.00e59d90@emerald.omg.org> Mime-Version: 1.0 Date: Thu, 21 Jun 2001 10:12:44 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: G_;!!/_Pd9@5/!!ne=!! I have a feeling that Guus is misunderstanding something. Perhaps he can clarify his issue. The way that MOF importing works at the moment, when you import a Package, any contained element of that Package is >>available<< to be used. You are not forced to reuse contained elements that you don't want to / need to. Furthermore, names of the contained elements do not "pollute" the Namespace into which they are imported. If we were to support importing of individual elements, it wouldn't make any difference to the IDL mapping. The IDL mapping translates an Import into a "#include" for the IDL representing the outermost Package. [There's no other way to do it!] And that means that the IDL compiler would generate stubs, etc for all of the elements in the Package ... not just the ones you imported. In short, I cannot see what would be achieved by importing individual elements of a Package. -- Steve X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: ramackers@acm.org (Guus Ramackers) Cc: Jeffrey Mischkinsky , crawley@dstc.edu.au (Stephen Crawley), mof-rtf@emerald.omg.org Subject: Re: issue 4383 -- MOF RTF issue In-Reply-To: Message from Jeffrey Mischkinsky of "Thu, 21 Jun 2001 10:12:32 MST." <200106211712.KAA02604@wheel.dcn.davis.ca.us> Mime-Version: 1.0 Date: Fri, 22 Jun 2001 11:10:36 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: p5dd9N-f!!NH]d9OC:e9 Guus, After discussion with Sridhar, it seems that you may actually want MOF to a qualitatively different kind of import semantics. But neither Sridhar or I are confident that we understand what you are asking for. Could you provide a detailed description of what you want selective importing to do? An example would also be useful, as would your view on why the current MOF import mechanism doesn't work. I wrote: > > If we were to support importing of individual elements, it wouldn't make > > any difference to the IDL mapping. The IDL mapping translates an Import > > into a "#include" for the IDL representing the outermost Package. > > [There's no other way to do it!] And that means that the IDL compiler > > would generate stubs, etc for all of the elements in the Package ... not > > just the ones you imported. Jeff replied: > Not necessarily. > > There is a large variation in the behavior of real IDL compilers when > they process #include. Some generate stubs, some don't, some have other > flags to control what gets generated, etc., etc. I'll accept this is true. But I have a feeling that it is a side issue anyhow. IMO, the most important issue (for now) is whether or not we need to extend / change MOF's import semantics. -- Steve From: Jeffrey Mischkinsky Message-Id: <200106211712.KAA02604@wheel.dcn.davis.ca.us> Subject: Re: issue 4383 -- MOF RTF issue To: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 21 Jun 2001 10:12:32 -0700 (PDT) Cc: juergen@omg.org (Juergen Boldt), mof-rtf@emerald.omg.org, ramackers@acm.org (Guus Ramackers) In-Reply-To: <200106210012.f5L0CW628422@piglet.dstc.edu.au> from "Stephen Crawley" at Jun 21, 2001 10:12:44 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'SYd9O^Ud9+-'!!`V2!! 'Stephen Crawley' writes: > > > I have a feeling that Guus is misunderstanding something. Perhaps he > can clarify his issue. > > The way that MOF importing works at the moment, when you import a > Package, any contained element of that Package is >>available<< to be > used. You are not forced to reuse contained elements that you don't > want to / need to. Furthermore, names of the contained elements do not > "pollute" the Namespace into which they are imported. > > If we were to support importing of individual elements, it wouldn't make > any difference to the IDL mapping. The IDL mapping translates an Import > into a "#include" for the IDL representing the outermost Package. > [There's no other way to do it!] And that means that the IDL compiler > would generate stubs, etc for all of the elements in the Package ... not > just the ones you imported. Not necessarily. There is a large variation in the behavior of real IDL compilers when they process #include. Some generate stubs, some don't, some have other flags to control what gets generated, etc., etc. I wouldn't count on particular semantics in the real world --- regardless of what the words in the IDL spec say. I'm sure you can find (almost) endless debate on this topic in the archives of the core (and other) rtfs. jeff > > In short, I cannot see what would be achieved by importing > individual > elements of a Package. > > -- Steve > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "Guus Ramackers" , ramackers@acm.org cc: uml-rtf@omg.org, mof-rtf@omg.org, mof2@omg.org, uml2-wg@omg.org Subject: Re: Issue 4383: The current MOF package level import is not sufficient Mime-Version: 1.0 Date: Fri, 26 Oct 2001 13:56:45 +1000 From: Stephen Crawley X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) Content-Type: text/plain; charset=us-ascii X-UIDL: 0('e9L)?e9!g+e9%*:!! Guus, and others interested in MOF 1.x RTF Issue 4383. Please excuse the length of this email, but the issue is a complex one. [I think it would be most appropriate to direct any followup email discussion to , but that's up to responders.] > Summary: > The current MOF package level import is not sufficient. For > instance, if a > user wants to reuse "Boolean" from UML 1.4 Datatypes package, then > she can > only indicate "Datatypes" in MOF now. What is needed is that the > user can > say "Datatypes::Boolean" as a dependency. It would be > counter-productive to > create 12 subpackages of Datatypes and put each datatype in its own > Package, > just because it would let people reuse individual datatypes (without > changing the MOF import rule). Dave Mellor filled the MOF RTF in on the background of this issue at today's teleconference. IMO, it really boils down to you needing a workaround for MOF 1.x's restriction that MOF Packages cannot be cyclically dependent. In your example where a user wants to reuse Datatypes::Boolean, it hardly matters that he/she imports the entire contents of DataTypes rather than just the Boolean declaration. The imported Package contents do not need to be implemented in the importing Package. Importing merely makes the imported contents' type signatures (in the broad sense) available in the importing Package. The real problem is that Datatypes might already depend on something in the user's Package. So importing all of DataTypes might creat a cyclic dependency. And that is forbidden. So WHY does MOF 1.x forbid cyclic dependencies? The real answer is because of IDL generation, and ultimately because of a peculiarity of the OMG IDL to C++ mapping! OMG IDL allows you to write IDL split over multiple modules. Normally, if two types in different modules are mutually dependent, you solve this by writing IDL that looks like this (after preprocessing): module A { interface X; typedef long Z; ... }; module B { interface Y { void op(in A::X my_x); }; }; module A { interface X { void op2(in B::Y my_y); }; }; The first occurence of module A declares A and some of its contents. The seccond (and subsequent) occurences of A, "reopen" the module to allow new declarations, and completion of forward declared names. The problem is that the IDL to C++ mapping relies on C++ namespaces to implement IDL module reopening. Unfortunately, some old C++ compilers to not support namespaces. Therefore, the C++ mapping has a get-out clause for pre ANSI C++ compilers that says that module reopening is not required to be supported. The MOF IDL mapping translates MOF Packages into IDL modules, and MOF Imports into #include statements. [These are the only sensible options in CORBA 1.x / 2.x.] If MOF allowed cyclic imports between Packages, then the MOF IDL mapping would need to use module reopening in order for the generated IDL to be compileable. But, that is problematical for some C++ ORBs. Note: this problem also applies with your requested "selective" Import construct. You cannot selectively #include just part of an IDL file, to get around IDL module reopening. When MOF 1.0 came out many C++ Compilers / ORBs did not support C++ namespaces. So that's why MOF 1.0 didn't use reopeing, but forbade cyclic dependencies instead. While most C++ developers who have a choice in the matter will now use a modern C++ compiler, ORB vendors still have to support platforms with pre-ANSI C++ compilers. [My source on this is Michi Henning.] So what can we do? # In MOF 2.0, the IDL mapping could be designed to use CORBA 3 "import" statements allowing both Package and "selective" Imports. (There would probably also need to be an alternative for CORBA 2.x ORBs too.) # In MOF 2.0, the IDL mapping could be designed on the assumption that all ORBs implement IDL module reopening. This would be problematical for some CORBA 2.x C++ ORBs / platform, but the "no cyclic dependencies" restriction is proving to be a major problem for MOF metamodellers. However, it is hard to justify trying to fix this in MOF 1.5. The expected short lifetime of MOF 1.5, and the likelihood that everything will change in MOF 2.0 will make MOF vendors reluctant to support a change like this with a potentially significant implementation burden. Just specifying MOF 1.5 templates to do module reopening is not trivial, at least at first sight. Besides, I understand that UML 2.0's refactoring / repackaging will remove the problematical cross-Package dependencies from the UML metamodel. Thus the specific reuse problem which (I understand) lead to this Issue being raised can be side-stepped. -- Steve [*** Apparently, another explanation has been used to argue against this issue, supposedly based on MOF extent semantics. I've not heard the argument "from the horses mouth", but I gather it goes like this: 1) Each MOF metamodel must be stored in a repository in a separate Model::ModelPackage instance. 2) Each such instance defines an "extent". 3) The MOF's "Reference Closure" rule means that the repository cannot represent the required links between extents. (Or something like that.) In my opinion, this argument falls down at point 1). The MOF 1.x spec does >>not<< require each metamodel to be stored in its own ModelPackage instance. This is a MOF implemenation design choice / limitation. If you weren't convinced, I'm not surprised :-) ***] Date: Fri, 26 Oct 2001 17:51:48 +0100 From: Guus Ramackers Organization: Oracle Corporation X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Crawley CC: guus.ramackers@oracle.com, uml-rtf@omg.org, mof-rtf@omg.org, mof2@omg.org, uml2-wg@omg.org Subject: Re: Issue 4383: The current MOF package level import is not sufficient References: <200110260356.f9Q3uec11270@piglet.dstc.edu.au> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: %^e!!N]e!!GC9!!$dkd9 Steve, Thank you for your detailed reply. I concur with your conclusion: > However, it is hard to justify trying to fix this in MOF 1.5. It makes sense to address this in MOF 2.0 context (I like the 1st approach): > # In MOF 2.0, the IDL mapping could be designed to use CORBA 3 "import" statements allowing both Package and "selective" Imports. (There would probably also need to be an alternative for CORBA 2.x ORBs too.) > # In MOF 2.0, the IDL mapping could be designed on the assumption that all ORBs implement IDL module reopening. This would be problematical for some CORBA 2.x C++ ORBs / platform, but the "no cyclic dependencies" restriction is proving to be a major problem for MOF metamodellers. > Besides, I understand that UML 2.0's refactoring / repackaging will remove the problematical cross-Package dependencies from the UML metamodel. Thus the specific reuse problem which (I understand) lead to this Issue being raised can be side-stepped. UML 2.0's refactoring will make it easier to reuse UML. Because of finer grained Packages, Package level reuse will cover a large number of cases. However, it will not be the case that all possible reuse will be effective on the basis of reuse a "Packages as a whole". In those cases a selective import mechanism will be useful for experienced metamodel engineers. Thanks, Guus Stephen Crawley wrote: > Guus, and others interested in MOF 1.x RTF Issue 4383. > > Please excuse the length of this email, but the issue is a complex >one. > > [I think it would be most appropriate to direct any followup email > discussion to , but that's up to responders.] > > > Summary: > > The current MOF package level import is not sufficient. For >instance, if a > > user wants to reuse "Boolean" from UML 1.4 Datatypes package, then >she can > > only indicate "Datatypes" in MOF now. What is needed is that the >user can > > say "Datatypes::Boolean" as a dependency. It would be >counter-productive to > > create 12 subpackages of Datatypes and put each datatype in its >own Package, > > just because it would let people reuse individual datatypes >(without > > changing the MOF import rule). > > Dave Mellor filled the MOF RTF in on the background of this issue at >today's > teleconference. IMO, it really boils down to you needing a >workaround > for MOF 1.x's restriction that MOF Packages cannot be cyclically >dependent. > > In your example where a user wants to reuse Datatypes::Boolean, it > hardly matters that he/she imports the entire contents of DataTypes > rather than just the Boolean declaration. The imported Package > contents do not need to be implemented in the importing Package. > Importing merely makes the imported contents' type signatures (in >the > broad sense) available in the importing Package. > > The real problem is that Datatypes might already depend on something >in > the user's Package. So importing all of DataTypes might creat a >cyclic > dependency. And that is forbidden. > > So WHY does MOF 1.x forbid cyclic dependencies? The real answer is > because of IDL generation, and ultimately because of a peculiarity >of > the OMG IDL to C++ mapping! > > OMG IDL allows you to write IDL split over multiple modules. >Normally, > if two types in different modules are mutually dependent, you solve > this by writing IDL that looks like this (after preprocessing): > > module A { > interface X; > typedef long Z; > ... > }; > > module B { > interface Y { > void op(in A::X my_x); > }; > }; > > module A { > interface X { > void op2(in B::Y my_y); > }; > }; > > The first occurence of module A declares A and some of its contents. > The seccond (and subsequent) occurences of A, "reopen" the module to > allow new declarations, and completion of forward declared names. > > The problem is that the IDL to C++ mapping relies on C++ namespaces >to > implement IDL module reopening. Unfortunately, some old C++ >compilers > to not support namespaces. Therefore, the C++ mapping has a get-out > clause for pre ANSI C++ compilers that says that module reopening is >not > required to be supported. > > The MOF IDL mapping translates MOF Packages into IDL modules, and >MOF > Imports into #include statements. [These are the only sensible >options > in CORBA 1.x / 2.x.] If MOF allowed cyclic imports between >Packages, > then the MOF IDL mapping would need to use module reopening in order > for the generated IDL to be compileable. But, that is >problematical > for some C++ ORBs. > > Note: this problem also applies with your requested "selective" >Import > construct. You cannot selectively #include just part of an IDL >file, > to get around IDL module reopening. > > When MOF 1.0 came out many C++ Compilers / ORBs did not support C++ > namespaces. So that's why MOF 1.0 didn't use reopeing, but forbade > cyclic dependencies instead. While most C++ developers who have a >choice > in the matter will now use a modern C++ compiler, ORB vendors still >have > to support platforms with pre-ANSI C++ compilers. [My source on >this is > Michi Henning.] > > So what can we do? > > # In MOF 2.0, the IDL mapping could be designed to use CORBA 3 >"import" > statements allowing both Package and "selective" Imports. (There > would probably also need to be an alternative for CORBA 2.x ORBs >too.) > > # In MOF 2.0, the IDL mapping could be designed on the assumption >that > all ORBs implement IDL module reopening. This would be >problematical > for some CORBA 2.x C++ ORBs / platform, but the "no cyclic >dependencies" > restriction is proving to be a major problem for MOF >metamodellers. > > However, it is hard to justify trying to fix this in MOF 1.5. The > expected short lifetime of MOF 1.5, and the likelihood that >everything > will change in MOF 2.0 will make MOF vendors reluctant to support a > change like this with a potentially significant implementation >burden. > Just specifying MOF 1.5 templates to do module reopening is not >trivial, > at least at first sight. > > Besides, I understand that UML 2.0's refactoring / repackaging will > remove the problematical cross-Package dependencies from the UML > metamodel. Thus the specific reuse problem which (I understand) >lead to > this Issue being raised can be side-stepped. > > -- Steve > > [*** Apparently, another explanation has been used to argue against >this > issue, supposedly based on MOF extent semantics. I've not heard the > argument "from the horses mouth", but I gather it goes like this: > > 1) Each MOF metamodel must be stored in a repository in a separate > Model::ModelPackage instance. > > 2) Each such instance defines an "extent". > > 3) The MOF's "Reference Closure" rule means that the repository >cannot > represent the required links between extents. (Or something like >that.) > > In my opinion, this argument falls down at point 1). The MOF 1.x >spec > does >>not<< require each metamodel to be stored in its own >ModelPackage > instance. This is a MOF implemenation design choice / limitation. > > If you weren't convinced, I'm not surprised :-) > > ***] > -- Guus Ramackers Product Manager UML Products, Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK e-mail: guus.ramackers@oracle.com work: +44-(0)1189-245101 fax: +44-(0)1189-245148