Issue 7749: Question on M-Levels (mu2i-ftf) Source: SAP AG (Dr. Axel Uhl, axel.uhl@sap.com axel.uhl@gmx.de) Nature: Uncategorized Issue Severity: Summary: section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF. Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate. However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object. The sentence from 7.2 suggests that I can have the following: myDog.getClass() == Dog Dog.getClass() == UML::Class UML::Class.getClass() == MOF::Class However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance. Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance. Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above. Any ideas? Resolution: Revised Text: Actions taken: September 9, 2004: received issue Discussion: End of Annotations:===== m: "Uhl, Axel" To: mof@omg.org Subject: Question on M-Levels Date: Thu, 9 Sep 2004 12:19:05 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out Hi there, section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF. Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate. However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object. The sentence from 7.2 suggests that I can have the following: myDog.getClass() == Dog Dog.getClass() == UML::Class UML::Class.getClass() == MOF::Class However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance. Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance. Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above. Any ideas? To: Juergen Boldt Cc: mof2idl-ftf@omg.org, mof2xmi-ftf@omg.org, mu2i-ftf@omg.org Subject: Re: Fwd: Question on M-Levels X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Fri, 17 Sep 2004 15:09:34 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/17/2004 13:09:35, Serialize complete at 09/17/2004 13:09:35 Axel, In order to achieve recursive traversal of multiple metalevels, all your model has to do is implement MOF reflection. That is, in your example, UML::Class and Dog would need to specialize MOF::Reflection::Object. UML::Class could specialize EMOF::Class, but this is a different decision which would only have indirect bearing on reflection. Juergen Boldt 09/17/2004 12:39 PM To mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, mof2idl-ftf@omg.org cc Subject Fwd: Question on M-Levels not sure if anybody saw this one....should I log this one as an issue? If yes, which FTF would take care of it? -Juergen From: "Uhl, Axel" To: mof@omg.org Subject: Question on M-Levels Date: Thu, 9 Sep 2004 12:19:05 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out Hi there, section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF. Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate. However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object. The sentence from 7.2 suggests that I can have the following: myDog.getClass() == Dog Dog.getClass() == UML::Class UML::Class.getClass() == MOF::Class However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance. Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance. Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above. Any ideas? -- Axel (puzzled...) ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org ================================ Subject: RE: Fwd: Question on M-Levels Date: Sat, 18 Sep 2004 10:20:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: Question on M-Levels Thread-Index: AcSc64EeK/xuRqCNSl+7SN614qwOJwAnX6Wg From: "Pete Rivett" To: "Jim Amsden" , "Juergen Boldt" Cc: , , X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i8IEQA1U015852 It's even easier - you never need to explicitly specialize MOF::Reflection::Object since at MOF 2 this is implicitly the superclass of everything. Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com ________________________________ From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Friday, September 17, 2004 8:10 PM To: Juergen Boldt Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org Subject: Re: Fwd: Question on M-Levels Axel, In order to achieve recursive traversal of multiple metalevels, all your model has to do is implement MOF reflection. That is, in your example, UML::Class and Dog would need to specialize MOF::Reflection::Object. UML::Class could specialize EMOF::Class, but this is a different decision which would only have indirect bearing on reflection. Juergen Boldt 09/17/2004 12:39 PM To mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, mof2idl-ftf@omg.org cc Subject Fwd: Question on M-Levels not sure if anybody saw this one....should I log this one as an issue? If yes, which FTF would take care of it? -Juergen From: "Uhl, Axel" To: mof@omg.org Subject: Question on M-Levels Date: Thu, 9 Sep 2004 12:19:05 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out Hi there, section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF. Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate. However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object. The sentence from 7.2 suggests that I can have the following: myDog.getClass() == Dog Dog.getClass() == UML::Class UML::Class.getClass() == MOF::Class However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance. Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance. Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above. Any ideas? -- Axel (puzzled...) ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org Subject: RE: Fwd: Question on M-Levels Date: Wed, 22 Sep 2004 22:37:10 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: Question on M-Levels Thread-Index: AcSdssQGZiJ+SmVyTTyc/nR4fY0V8wDYbMlA From: "Pete Rivett" To: "Uhl, Axel" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i8N2gw1U031919 You pass the Dog class as the metaclass parameter to the Reflective::Factory.create() operation. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: Saturday, September 18, 2004 7:56 PM > To: Pete Rivett > Subject: RE: Fwd: Question on M-Levels > > Pete, > > sorry, but I still don't get it. My understanding of what > you're writing is that my object of type UML::Class which I > named Dog is implicitly a MOF::Object instance. So far, so > good. But then, how do I create an *instance* of this > MOF::Object which represents a class, namely the "Dog" class? > > -- Axel > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Saturday, September 18, 2004 4:22 PM > > To: Uhl, Axel > > Subject: FW: Fwd: Question on M-Levels > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > Chief Scientist, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Pete Rivett > > > Sent: Saturday, September 18, 2004 3:10 PM > > > To: 'Jim Amsden'; Juergen Boldt > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org > > > Subject: RE: Fwd: Question on M-Levels > > > > > > It's even easier - you never need to explicitly specialize > > > MOF::Reflection::Object since at MOF 2 this is implicitly the > > > superclass of everything. > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > Chief Scientist, Adaptive Inc. > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > BH1 1HL, UK > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > > Sent: Friday, September 17, 2004 8:10 PM > > > To: Juergen Boldt > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org > > > Subject: Re: Fwd: Question on M-Levels > > > > > > > > > > > > Axel, > > > In order to achieve recursive traversal of multiple > > > metalevels, all your model has to do is implement MOF > > > reflection. That is, in your example, UML::Class and Dog > > > would need to specialize MOF::Reflection::Object. UML::Class > > > could specialize EMOF::Class, but this is a different > > > decision which would only have indirect bearing on reflection. > > > > > > > > > > > > > > > Juergen Boldt > > > > > > 09/17/2004 12:39 PM > > > > > > > > > To > > > mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, > > > mof2idl-ftf@omg.org > > > cc > > > > > > Subject > > > Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > not sure if anybody saw this one....should I log this > > > one as an issue? If yes, which FTF would take care of it? > > > > > > -Juergen > > > > > > > > > From: "Uhl, Axel" > > > To: mof@omg.org > > > Subject: Question on M-Levels > > > Date: Thu, 9 Sep 2004 12:19:05 +0200 > > > X-Mailer: Internet Mail Service (5.5.2657.72) > > > X-SAP: out > > > > > > Hi there, > > > > > > section 7.2 of the MOF 2.0 specification (similar to > > > previous versions of the MOF spec) still contains this bold > > > sentence: "The MOF 1.4 Reflection interfaces allow traversal > > > across any number of metalayers recursively." I'm wondering > > > how I would create a MOF-based system with more than three > > > layers that really "live" inside a MOF-based repository. > > > Let's take a look at UML, for example. If we forget for a > > > while that UML 2.0 and MOF 2.0 share a common core, I could > > > consider the UML metamodel as just another modeling language > > > defined using MOF. > > > > > > Now the UML metamodel defines zillions of classes, all > > > of them being instances of MOF::Class. One of them happens to > > > be UML::Class, a classifying model element which allows me to > > > create model elements in the UML modeling languages that > > > themselves conceptually act as meta-objects that I may wish > > > to instantiate. > > > > > > However, apart from the "shared core trick," the MOF > > > doesn't have any knowledge about the MOF::Class object > > > UML::Class being special, and in particular being a > > > classifying meta-object. > > > > > > The sentence from 7.2 suggests that I can have the following: > > > > > > myDog.getClass() == Dog > > > Dog.getClass() == UML::Class > > > UML::Class.getClass() == MOF::Class > > > > > > However, creation of a model element with the > > > reflective capabilities as found in the MOF 2.0 specification > > > seems to allow me only to create the UML::Class instance > > > named "Dog" as I can use UML::Class as an argument to > > > Factory::createObject(...). The resulting object, however, is > > > no longer an instance of MOF::Class and can therefore not be > > > used for a factory call in order to create an instance. > > > > > > Currently available language bindings for MOF 1.4 as I > > > understand them correspondingly don't allow for this flexible > > > multi-layering idea. Take JMI, for example. While the > > > standard defines how to derive the class proxy for > > > UML::Class, I cannot simply instantiate the UML::Class > > > instance Dog because it's not a MOF::Class instance. > > > > > > Would I have to import the MOF core into my metamodel > > > and have UML::Class specialize MOF::Class? (Tricky enough, > > > MOF 2.0 doesn't even have to create a specialization relation > > > because the two are identical. But I think you get the > > > picture; I could have chosen to use my own metamodel, > > > different from UML, but still introducing a classifying > > > class.) If this was the case, then probably there would be > > > something missing from the language bindings and reflective > > > capabilities. For the JMI example, I'd then expect to be able > > > to obtain a class proxy for an instance of my UML::Class so > > > that I can create instances of that particular UML class, > > > e.g., the "myDog" instance used in the example above. > > > > > > Any ideas? > > > > > > -- Axel (puzzled...) > > > > > > > > > ================================= > > > Jürgen Boldt > > > Director, Member Services > > > > > > Object Management Group > > > 250 First Avenue, Suite 100 > > > Needham, MA 02494 > > > > > > Tel. +1 781 444 0404 ext. 132 > > > Fax: +1 781 444 0320 > > > email: juergen@omg.org > > > www www.omg.org > > > > > > ================================ > > > > > > > > > From: "Uhl, Axel" To: Pete Rivett Cc: mu2i-ftf@omg.org Subject: RE: Fwd: Question on M-Levels Date: Thu, 23 Sep 2004 09:33:16 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out X-SAP: out ...but that won't work because Reflective::Factory.create(...) accepts an instance of type MOF::Class, and Dog just happens to be of type UML::Class. I know, I know, accidentally UML::Class *is* MOF::Class, but I could've used some metamodel other than UML, e.g., AxelsMetamodel, and in there have defined AxelsMetamodel::Class and consequently, Dog would've been an instance of AxelsMetamodel::Class. Therefore, I won't be able to pass my instance named "Dog" to Reflective::Factory.create(...). -- Axel (still puzzled) > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Thursday, September 23, 2004 4:37 AM > To: Uhl, Axel > Cc: mu2i-ftf@omg.org > Subject: RE: Fwd: Question on M-Levels > > You pass the Dog class as the metaclass parameter to the > Reflective::Factory.create() operation. > > Regards > Pete > > Pete Rivett (mailto:pete.rivett@adaptive.com) > Chief Scientist, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > Sent: Saturday, September 18, 2004 7:56 PM > > To: Pete Rivett > > Subject: RE: Fwd: Question on M-Levels > > > > Pete, > > > > sorry, but I still don't get it. My understanding of what > > you're writing is that my object of type UML::Class which I > > named Dog is implicitly a MOF::Object instance. So far, so > > good. But then, how do I create an *instance* of this > > MOF::Object which represents a class, namely the "Dog" class? > > > > -- Axel > > > > > -----Original Message----- > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > Sent: Saturday, September 18, 2004 4:22 PM > > > To: Uhl, Axel > > > Subject: FW: Fwd: Question on M-Levels > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > Chief Scientist, Adaptive Inc. > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > http://www.adaptive.com > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Pete Rivett > > > > Sent: Saturday, September 18, 2004 3:10 PM > > > > To: 'Jim Amsden'; Juergen Boldt > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > It's even easier - you never need to explicitly specialize > > > > MOF::Reflection::Object since at MOF 2 this is implicitly the > > > > superclass of everything. > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > Chief Scientist, Adaptive Inc. > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > BH1 1HL, UK > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > > > Sent: Friday, September 17, 2004 8:10 PM > > > > To: Juergen Boldt > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > mu2i-ftf@omg.org > > > > Subject: Re: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > Axel, > > > > In order to achieve recursive traversal of multiple > > > > metalevels, all your model has to do is implement MOF > > > > reflection. That is, in your example, UML::Class and Dog > > > > would need to specialize MOF::Reflection::Object. UML::Class > > > > could specialize EMOF::Class, but this is a different > > > > decision which would only have indirect bearing on reflection. > > > > > > > > > > > > > > > > > > > > Juergen Boldt > > > > > > > > 09/17/2004 12:39 PM > > > > > > > > > > > > To > > > > mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, > > > > mof2idl-ftf@omg.org > > > > cc > > > > > > > > Subject > > > > Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > > > > > not sure if anybody saw this one....should I log this > > > > one as an issue? If yes, which FTF would take care of it? > > > > > > > > -Juergen > > > > > > > > > > > > From: "Uhl, Axel" > > > > To: mof@omg.org > > > > Subject: Question on M-Levels > > > > Date: Thu, 9 Sep 2004 12:19:05 +0200 > > > > X-Mailer: Internet Mail Service (5.5.2657.72) > > > > X-SAP: out > > > > > > > > Hi there, > > > > > > > > section 7.2 of the MOF 2.0 specification (similar to > > > > previous versions of the MOF spec) still contains this bold > > > > sentence: "The MOF 1.4 Reflection interfaces allow traversal > > > > across any number of metalayers recursively." I'm wondering > > > > how I would create a MOF-based system with more than three > > > > layers that really "live" inside a MOF-based repository. > > > > Let's take a look at UML, for example. If we forget for a > > > > while that UML 2.0 and MOF 2.0 share a common core, I could > > > > consider the UML metamodel as just another modeling language > > > > defined using MOF. > > > > > > > > Now the UML metamodel defines zillions of classes, all > > > > of them being instances of MOF::Class. One of them happens to > > > > be UML::Class, a classifying model element which allows me to > > > > create model elements in the UML modeling languages that > > > > themselves conceptually act as meta-objects that I may wish > > > > to instantiate. > > > > > > > > However, apart from the "shared core trick," the MOF > > > > doesn't have any knowledge about the MOF::Class object > > > > UML::Class being special, and in particular being a > > > > classifying meta-object. > > > > > > > > The sentence from 7.2 suggests that I can have > the following: > > > > > > > > myDog.getClass() == Dog > > > > Dog.getClass() == UML::Class > > > > UML::Class.getClass() == MOF::Class > > > > > > > > However, creation of a model element with the > > > > reflective capabilities as found in the MOF 2.0 specification > > > > seems to allow me only to create the UML::Class instance > > > > named "Dog" as I can use UML::Class as an argument to > > > > Factory::createObject(...). The resulting object, however, is > > > > no longer an instance of MOF::Class and can therefore not be > > > > used for a factory call in order to create an instance. > > > > > > > > Currently available language bindings for MOF 1.4 as I > > > > understand them correspondingly don't allow for this flexible > > > > multi-layering idea. Take JMI, for example. While the > > > > standard defines how to derive the class proxy for > > > > UML::Class, I cannot simply instantiate the UML::Class > > > > instance Dog because it's not a MOF::Class instance. > > > > > > > > Would I have to import the MOF core into my metamodel > > > > and have UML::Class specialize MOF::Class? (Tricky enough, > > > > MOF 2.0 doesn't even have to create a specialization relation > > > > because the two are identical. But I think you get the > > > > picture; I could have chosen to use my own metamodel, > > > > different from UML, but still introducing a classifying > > > > class.) If this was the case, then probably there would be > > > > something missing from the language bindings and reflective > > > > capabilities. For the JMI example, I'd then expect to be able > > > > to obtain a class proxy for an instance of my UML::Class so > > > > that I can create instances of that particular UML class, > > > > e.g., the "myDog" instance used in the example above. > > > > > > > > Any ideas? > > > > > > > > -- Axel (puzzled...) > > > > > > > > > > > > ================================= > > > > Jürgen Boldt > > > > Director, Member Services > > > > > > > > Object Management Group > > > > 250 First Avenue, Suite 100 > > > > Needham, MA 02494 > > > > > > > > Tel. +1 781 444 0404 ext. 132 > > > > Fax: +1 781 444 0320 > > > > email: juergen@omg.org > > > > www www.omg.org > > > > > > > > ================================ > > > > > > > > > > > > > > From: "Uhl, Axel" To: Pete Rivett Cc: mu2i-ftf@omg.org Subject: RE: Fwd: Question on M-Levels Date: Thu, 23 Sep 2004 12:48:17 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out X-SAP: out All true, but I acknowledged all that in my e-mail already and for this purpose outlined my idea using a non-UML metamodel that introduces its own Class construct which is unrelated to MOF::Class. If what you're saying is the complete answer, then the MOF-stack can have more than three accessible layers only if all layers including M2 and above are MOF or an extension of MOF (such as the UML is), and all meta-objects intended to identify instantiatable classifiers extend or *are* MOF::Class (like UML::Class). If this assumption is correct, I suggest this should be added as a clarifaction to the MOF 2.0 specification. It also has to show effects in the language bindings: meta-objects that extend or are MOF::Class (such as UML::Class) have to be treated in a special way, making their representation in the language binding compatible to MOF::Class so its instances can be passed, e.g., to Factory.create(MOF::Class). -- Axel > -----Original Message----- > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > Sent: Thursday, September 23, 2004 12:50 PM > To: Uhl, Axel > Cc: mu2i-ftf@omg.org > Subject: RE: Fwd: Question on M-Levels > > Axel, > There is no longer a distinction between MOF and UML classes > in the way there was at 1.x. > The parameter to Reflective::Factory.create(...) is of type > Class. Since the MOF metamodel is now based on UML > Infrastructure this in effect means Class from the Basic > package of UML Infrastructure (which is in turn reused by > Superstructure). > So you can use your UML Dog class, subject to it meeting the > constraints imposed by MOF which are documented in the MOF > Core specification. > > Regards > Pete > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > Chief Scientist, Adaptive Inc. > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > http://www.adaptive.com > > > > > > -----Original Message----- > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > Sent: Thursday, September 23, 2004 8:33 AM > > To: Pete Rivett > > Cc: mu2i-ftf@omg.org > > Subject: RE: Fwd: Question on M-Levels > > > > ...but that won't work because > > Reflective::Factory.create(...) accepts an instance of type > > MOF::Class, and Dog just happens to be of type UML::Class. I > > know, I know, accidentally UML::Class *is* MOF::Class, but I > > could've used some metamodel other than UML, e.g., > > AxelsMetamodel, and in there have defined > > AxelsMetamodel::Class and consequently, Dog would've been an > > instance of AxelsMetamodel::Class. Therefore, I won't be able > > to pass my instance named "Dog" to Reflective::Factory.create(...). > > > > -- Axel (still puzzled) > > > > > -----Original Message----- > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > Sent: Thursday, September 23, 2004 4:37 AM > > > To: Uhl, Axel > > > Cc: mu2i-ftf@omg.org > > > Subject: RE: Fwd: Question on M-Levels > > > > > > You pass the Dog class as the metaclass parameter to the > > > Reflective::Factory.create() operation. > > > > > > Regards > > > Pete > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > Chief Scientist, Adaptive Inc. > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > http://www.adaptive.com > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > > Sent: Saturday, September 18, 2004 7:56 PM > > > > To: Pete Rivett > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > Pete, > > > > > > > > sorry, but I still don't get it. My understanding of what > > > > you're writing is that my object of type UML::Class which I > > > > named Dog is implicitly a MOF::Object instance. So far, so > > > > good. But then, how do I create an *instance* of this > > > > MOF::Object which represents a class, namely the "Dog" class? > > > > > > > > -- Axel > > > > > > > > > -----Original Message----- > > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > > Sent: Saturday, September 18, 2004 4:22 PM > > > > > To: Uhl, Axel > > > > > Subject: FW: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > Chief Scientist, Adaptive Inc. > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > BH1 1HL, UK > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Pete Rivett > > > > > > Sent: Saturday, September 18, 2004 3:10 PM > > > > > > To: 'Jim Amsden'; Juergen Boldt > > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > mu2i-ftf@omg.org > > > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > > > > > It's even easier - you never need to explicitly specialize > > > > > > MOF::Reflection::Object since at MOF 2 this is > implicitly the > > > > > > superclass of everything. > > > > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > > Chief Scientist, Adaptive Inc. > > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > > BH1 1HL, UK > > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > > > > > Sent: Friday, September 17, 2004 8:10 PM > > > > > > To: Juergen Boldt > > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > > > mu2i-ftf@omg.org > > > > > > Subject: Re: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > Axel, > > > > > > In order to achieve recursive traversal of multiple > > > > > > metalevels, all your model has to do is implement MOF > > > > > > reflection. That is, in your example, UML::Class and Dog > > > > > > would need to specialize MOF::Reflection::Object. > UML::Class > > > > > > could specialize EMOF::Class, but this is a different > > > > > > decision which would only have indirect bearing on > > reflection. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juergen Boldt > > > > > > > > > > > > 09/17/2004 12:39 PM > > > > > > > > > > > > > > > > > > To > > > > > > mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, > > > > > > mof2idl-ftf@omg.org > > > > > > cc > > > > > > > > > > > > Subject > > > > > > Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > not sure if anybody saw this one....should I log this > > > > > > one as an issue? If yes, which FTF would take care of it? > > > > > > > > > > > > -Juergen > > > > > > > > > > > > > > > > > > From: "Uhl, Axel" > > > > > > To: mof@omg.org > > > > > > Subject: Question on M-Levels > > > > > > Date: Thu, 9 Sep 2004 12:19:05 +0200 > > > > > > X-Mailer: Internet Mail Service (5.5.2657.72) > > > > > > X-SAP: out > > > > > > > > > > > > Hi there, > > > > > > > > > > > > section 7.2 of the MOF 2.0 specification (similar to > > > > > > previous versions of the MOF spec) still contains this bold > > > > > > sentence: "The MOF 1.4 Reflection interfaces allow > traversal > > > > > > across any number of metalayers recursively." I'm wondering > > > > > > how I would create a MOF-based system with more than three > > > > > > layers that really "live" inside a MOF-based repository. > > > > > > Let's take a look at UML, for example. If we forget for a > > > > > > while that UML 2.0 and MOF 2.0 share a common core, I could > > > > > > consider the UML metamodel as just another modeling > language > > > > > > defined using MOF. > > > > > > > > > > > > Now the UML metamodel defines zillions of classes, all > > > > > > of them being instances of MOF::Class. One of them > happens to > > > > > > be UML::Class, a classifying model element which > allows me to > > > > > > create model elements in the UML modeling languages that > > > > > > themselves conceptually act as meta-objects that I may wish > > > > > > to instantiate. > > > > > > > > > > > > However, apart from the "shared core trick," the MOF > > > > > > doesn't have any knowledge about the MOF::Class object > > > > > > UML::Class being special, and in particular being a > > > > > > classifying meta-object. > > > > > > > > > > > > The sentence from 7.2 suggests that I can have > > > the following: > > > > > > > > > > > > myDog.getClass() == Dog > > > > > > Dog.getClass() == UML::Class > > > > > > UML::Class.getClass() == MOF::Class > > > > > > > > > > > > However, creation of a model element with the > > > > > > reflective capabilities as found in the MOF 2.0 > specification > > > > > > seems to allow me only to create the UML::Class instance > > > > > > named "Dog" as I can use UML::Class as an argument to > > > > > > Factory::createObject(...). The resulting object, > however, is > > > > > > no longer an instance of MOF::Class and can > therefore not be > > > > > > used for a factory call in order to create an instance. > > > > > > > > > > > > Currently available language bindings for MOF 1.4 as I > > > > > > understand them correspondingly don't allow for > this flexible > > > > > > multi-layering idea. Take JMI, for example. While the > > > > > > standard defines how to derive the class proxy for > > > > > > UML::Class, I cannot simply instantiate the UML::Class > > > > > > instance Dog because it's not a MOF::Class instance. > > > > > > > > > > > > Would I have to import the MOF core into my metamodel > > > > > > and have UML::Class specialize MOF::Class? (Tricky enough, > > > > > > MOF 2.0 doesn't even have to create a > specialization relation > > > > > > because the two are identical. But I think you get the > > > > > > picture; I could have chosen to use my own metamodel, > > > > > > different from UML, but still introducing a classifying > > > > > > class.) If this was the case, then probably there would be > > > > > > something missing from the language bindings and reflective > > > > > > capabilities. For the JMI example, I'd then expect > to be able > > > > > > to obtain a class proxy for an instance of my UML::Class so > > > > > > that I can create instances of that particular UML class, > > > > > > e.g., the "myDog" instance used in the example above. > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > -- Axel (puzzled...) > > > > > > > > > > > > > > > > > > ================================= > > > > > > Jürgen Boldt > > > > > > Director, Member Services > > > > > > > > > > > > Object Management Group > > > > > > 250 First Avenue, Suite 100 > > > > > > Needham, MA 02494 > > > > > > > > > > > > Tel. +1 781 444 0404 ext. 132 > > > > > > Fax: +1 781 444 0320 > > > > > > email: juergen@omg.org > > > > > > www www.omg.org > > > > > > > > > > > > ================================ > > > > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: Fwd: Question on M-Levels Date: Thu, 23 Sep 2004 06:49:50 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: Question on M-Levels Thread-Index: AcShQTeknZ2up2PSRa2xQOLeKkQL8gAF7jBQ From: "Pete Rivett" To: "Uhl, Axel" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i8NAtn1U002037 Axel, There is no longer a distinction between MOF and UML classes in the way there was at 1.x. The parameter to Reflective::Factory.create(...) is of type Class. Since the MOF metamodel is now based on UML Infrastructure this in effect means Class from the Basic package of UML Infrastructure (which is in turn reused by Superstructure). So you can use your UML Dog class, subject to it meeting the constraints imposed by MOF which are documented in the MOF Core specification. Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: Thursday, September 23, 2004 8:33 AM > To: Pete Rivett > Cc: mu2i-ftf@omg.org > Subject: RE: Fwd: Question on M-Levels > > ...but that won't work because > Reflective::Factory.create(...) accepts an instance of type > MOF::Class, and Dog just happens to be of type UML::Class. I > know, I know, accidentally UML::Class *is* MOF::Class, but I > could've used some metamodel other than UML, e.g., > AxelsMetamodel, and in there have defined > AxelsMetamodel::Class and consequently, Dog would've been an > instance of AxelsMetamodel::Class. Therefore, I won't be able > to pass my instance named "Dog" to Reflective::Factory.create(...). > > -- Axel (still puzzled) > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Thursday, September 23, 2004 4:37 AM > > To: Uhl, Axel > > Cc: mu2i-ftf@omg.org > > Subject: RE: Fwd: Question on M-Levels > > > > You pass the Dog class as the metaclass parameter to the > > Reflective::Factory.create() operation. > > > > Regards > > Pete > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > Chief Scientist, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > Sent: Saturday, September 18, 2004 7:56 PM > > > To: Pete Rivett > > > Subject: RE: Fwd: Question on M-Levels > > > > > > Pete, > > > > > > sorry, but I still don't get it. My understanding of what > > > you're writing is that my object of type UML::Class which I > > > named Dog is implicitly a MOF::Object instance. So far, so > > > good. But then, how do I create an *instance* of this > > > MOF::Object which represents a class, namely the "Dog" class? > > > > > > -- Axel > > > > > > > -----Original Message----- > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > Sent: Saturday, September 18, 2004 4:22 PM > > > > To: Uhl, Axel > > > > Subject: FW: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > Chief Scientist, Adaptive Inc. > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > BH1 1HL, UK > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pete Rivett > > > > > Sent: Saturday, September 18, 2004 3:10 PM > > > > > To: 'Jim Amsden'; Juergen Boldt > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; mu2i-ftf@omg.org > > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > > > It's even easier - you never need to explicitly specialize > > > > > MOF::Reflection::Object since at MOF 2 this is implicitly the > > > > > superclass of everything. > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > Chief Scientist, Adaptive Inc. > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > BH1 1HL, UK > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > > > > Sent: Friday, September 17, 2004 8:10 PM > > > > > To: Juergen Boldt > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > > mu2i-ftf@omg.org > > > > > Subject: Re: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > Axel, > > > > > In order to achieve recursive traversal of multiple > > > > > metalevels, all your model has to do is implement MOF > > > > > reflection. That is, in your example, UML::Class and Dog > > > > > would need to specialize MOF::Reflection::Object. UML::Class > > > > > could specialize EMOF::Class, but this is a different > > > > > decision which would only have indirect bearing on > reflection. > > > > > > > > > > > > > > > > > > > > > > > > > Juergen Boldt > > > > > > > > > > 09/17/2004 12:39 PM > > > > > > > > > > > > > > > To > > > > > mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, > > > > > mof2idl-ftf@omg.org > > > > > cc > > > > > > > > > > Subject > > > > > Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > not sure if anybody saw this one....should I log this > > > > > one as an issue? If yes, which FTF would take care of it? > > > > > > > > > > -Juergen > > > > > > > > > > > > > > > From: "Uhl, Axel" > > > > > To: mof@omg.org > > > > > Subject: Question on M-Levels > > > > > Date: Thu, 9 Sep 2004 12:19:05 +0200 > > > > > X-Mailer: Internet Mail Service (5.5.2657.72) > > > > > X-SAP: out > > > > > > > > > > Hi there, > > > > > > > > > > section 7.2 of the MOF 2.0 specification (similar to > > > > > previous versions of the MOF spec) still contains this bold > > > > > sentence: "The MOF 1.4 Reflection interfaces allow traversal > > > > > across any number of metalayers recursively." I'm wondering > > > > > how I would create a MOF-based system with more than three > > > > > layers that really "live" inside a MOF-based repository. > > > > > Let's take a look at UML, for example. If we forget for a > > > > > while that UML 2.0 and MOF 2.0 share a common core, I could > > > > > consider the UML metamodel as just another modeling language > > > > > defined using MOF. > > > > > > > > > > Now the UML metamodel defines zillions of classes, all > > > > > of them being instances of MOF::Class. One of them happens to > > > > > be UML::Class, a classifying model element which allows me to > > > > > create model elements in the UML modeling languages that > > > > > themselves conceptually act as meta-objects that I may wish > > > > > to instantiate. > > > > > > > > > > However, apart from the "shared core trick," the MOF > > > > > doesn't have any knowledge about the MOF::Class object > > > > > UML::Class being special, and in particular being a > > > > > classifying meta-object. > > > > > > > > > > The sentence from 7.2 suggests that I can have > > the following: > > > > > > > > > > myDog.getClass() == Dog > > > > > Dog.getClass() == UML::Class > > > > > UML::Class.getClass() == MOF::Class > > > > > > > > > > However, creation of a model element with the > > > > > reflective capabilities as found in the MOF 2.0 specification > > > > > seems to allow me only to create the UML::Class instance > > > > > named "Dog" as I can use UML::Class as an argument to > > > > > Factory::createObject(...). The resulting object, however, is > > > > > no longer an instance of MOF::Class and can therefore not be > > > > > used for a factory call in order to create an instance. > > > > > > > > > > Currently available language bindings for MOF 1.4 as I > > > > > understand them correspondingly don't allow for this flexible > > > > > multi-layering idea. Take JMI, for example. While the > > > > > standard defines how to derive the class proxy for > > > > > UML::Class, I cannot simply instantiate the UML::Class > > > > > instance Dog because it's not a MOF::Class instance. > > > > > > > > > > Would I have to import the MOF core into my metamodel > > > > > and have UML::Class specialize MOF::Class? (Tricky enough, > > > > > MOF 2.0 doesn't even have to create a specialization relation > > > > > because the two are identical. But I think you get the > > > > > picture; I could have chosen to use my own metamodel, > > > > > different from UML, but still introducing a classifying > > > > > class.) If this was the case, then probably there would be > > > > > something missing from the language bindings and reflective > > > > > capabilities. For the JMI example, I'd then expect to be able > > > > > to obtain a class proxy for an instance of my UML::Class so > > > > > that I can create instances of that particular UML class, > > > > > e.g., the "myDog" instance used in the example above. > > > > > > > > > > Any ideas? > > > > > > > > > > -- Axel (puzzled...) > > > > > > > > > > > > > > > ================================= > > > > > Jürgen Boldt > > > > > Director, Member Services > > > > > > > > > > Object Management Group > > > > > 250 First Avenue, Suite 100 > > > > > Needham, MA 02494 > > > > > > > > > > Tel. +1 781 444 0404 ext. 132 > > > > > Fax: +1 781 444 0320 > > > > > email: juergen@omg.org > > > > > www www.omg.org > > > > > > > > > > ================================ > > > > > > > > > > > > > > > > > > > > Subject: RE: Fwd: Question on M-Levels Date: Thu, 23 Sep 2004 18:38:13 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: Question on M-Levels Thread-Index: AcShXH5Subw0Q4jzSOq7j9PjPRpJSwAASpuQ From: "Pete Rivett" To: "Uhl, Axel" Cc: X-Virus-Scanned: by amavisd-new at sentraliant.com X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id i8NMiD1U010944 I was assuming that AxelsMetamodel in some way extended UML:Basic, since that defines the essence of what it is to be a metamodel. In order to be able to instantiate a class, its metaclass needs to have some notion of typed features/properties etc. And there neeeds to be some defined way of generating an implementation and/or interchaneg format for the class definition: which is defined by MOF for metamodels based on UML:Basic. What would you like to see instead? Note that in metamodel terms UML does not really extend MOF - it's the other way round! Regards Pete Pete Rivett (mailto:pete.rivett@adaptive.com) Chief Scientist, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com > -----Original Message----- > From: Uhl, Axel [mailto:axel.uhl@sap.com] > Sent: Thursday, September 23, 2004 11:48 AM > To: Pete Rivett > Cc: mu2i-ftf@omg.org > Subject: RE: Fwd: Question on M-Levels > > All true, but I acknowledged all that in my e-mail already > and for this purpose outlined my idea using a non-UML > metamodel that introduces its own Class construct which is > unrelated to MOF::Class. If what you're saying is the > complete answer, then the MOF-stack can have more than three > accessible layers only if all layers including M2 and above > are MOF or an extension of MOF (such as the UML is), and all > meta-objects intended to identify instantiatable classifiers > extend or *are* MOF::Class (like UML::Class). > > If this assumption is correct, I suggest this should be added > as a clarifaction to the MOF 2.0 specification. It also has > to show effects in the language bindings: meta-objects that > extend or are MOF::Class (such as UML::Class) have to be > treated in a special way, making their representation in the > language binding compatible to MOF::Class so its instances > can be passed, e.g., to Factory.create(MOF::Class). > > -- Axel > > > -----Original Message----- > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > Sent: Thursday, September 23, 2004 12:50 PM > > To: Uhl, Axel > > Cc: mu2i-ftf@omg.org > > Subject: RE: Fwd: Question on M-Levels > > > > Axel, > > There is no longer a distinction between MOF and UML classes > > in the way there was at 1.x. > > The parameter to Reflective::Factory.create(...) is of type > > Class. Since the MOF metamodel is now based on UML > > Infrastructure this in effect means Class from the Basic > > package of UML Infrastructure (which is in turn reused by > > Superstructure). > > So you can use your UML Dog class, subject to it meeting the > > constraints imposed by MOF which are documented in the MOF > > Core specification. > > > > Regards > > Pete > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > Chief Scientist, Adaptive Inc. > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > http://www.adaptive.com > > > > > > > > > > > -----Original Message----- > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > Sent: Thursday, September 23, 2004 8:33 AM > > > To: Pete Rivett > > > Cc: mu2i-ftf@omg.org > > > Subject: RE: Fwd: Question on M-Levels > > > > > > ...but that won't work because > > > Reflective::Factory.create(...) accepts an instance of type > > > MOF::Class, and Dog just happens to be of type UML::Class. I > > > know, I know, accidentally UML::Class *is* MOF::Class, but I > > > could've used some metamodel other than UML, e.g., > > > AxelsMetamodel, and in there have defined > > > AxelsMetamodel::Class and consequently, Dog would've been an > > > instance of AxelsMetamodel::Class. Therefore, I won't be able > > > to pass my instance named "Dog" to > Reflective::Factory.create(...). > > > > > > -- Axel (still puzzled) > > > > > > > -----Original Message----- > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > Sent: Thursday, September 23, 2004 4:37 AM > > > > To: Uhl, Axel > > > > Cc: mu2i-ftf@omg.org > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > You pass the Dog class as the metaclass parameter to the > > > > Reflective::Factory.create() operation. > > > > > > > > Regards > > > > Pete > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > Chief Scientist, Adaptive Inc. > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > BH1 1HL, UK > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Uhl, Axel [mailto:axel.uhl@sap.com] > > > > > Sent: Saturday, September 18, 2004 7:56 PM > > > > > To: Pete Rivett > > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > > > Pete, > > > > > > > > > > sorry, but I still don't get it. My understanding of what > > > > > you're writing is that my object of type UML::Class which I > > > > > named Dog is implicitly a MOF::Object instance. So far, so > > > > > good. But then, how do I create an *instance* of this > > > > > MOF::Object which represents a class, namely the "Dog" class? > > > > > > > > > > -- Axel > > > > > > > > > > > -----Original Message----- > > > > > > From: Pete Rivett [mailto:pete.rivett@adaptive.com] > > > > > > Sent: Saturday, September 18, 2004 4:22 PM > > > > > > To: Uhl, Axel > > > > > > Subject: FW: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > > Chief Scientist, Adaptive Inc. > > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > BH1 1HL, UK > > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Pete Rivett > > > > > > > Sent: Saturday, September 18, 2004 3:10 PM > > > > > > > To: 'Jim Amsden'; Juergen Boldt > > > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > > mu2i-ftf@omg.org > > > > > > > Subject: RE: Fwd: Question on M-Levels > > > > > > > > > > > > > > It's even easier - you never need to explicitly > specialize > > > > > > > MOF::Reflection::Object since at MOF 2 this is > > implicitly the > > > > > > > superclass of everything. > > > > > > > > > > > > > > > > > > > > > Pete Rivett (mailto:pete.rivett@adaptive.com) > > > > > > > Chief Scientist, Adaptive Inc. > > > > > > > Dean Park House, 8-10 Dean Park Crescent, Bournemouth, > > > > > BH1 1HL, UK > > > > > > > Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 > > > > > > > http://www.adaptive.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > From: Jim Amsden [mailto:jamsden@us.ibm.com] > > > > > > > Sent: Friday, September 17, 2004 8:10 PM > > > > > > > To: Juergen Boldt > > > > > > > Cc: mof2idl-ftf@omg.org; mof2xmi-ftf@omg.org; > > > > mu2i-ftf@omg.org > > > > > > > Subject: Re: Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > > > > > Axel, > > > > > > > In order to achieve recursive traversal of multiple > > > > > > > metalevels, all your model has to do is implement MOF > > > > > > > reflection. That is, in your example, UML::Class and Dog > > > > > > > would need to specialize MOF::Reflection::Object. > > UML::Class > > > > > > > could specialize EMOF::Class, but this is a different > > > > > > > decision which would only have indirect bearing on > > > reflection. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Juergen Boldt > > > > > > > > > > > > > > 09/17/2004 12:39 PM > > > > > > > > > > > > > > > > > > > > > To > > > > > > > mu2i-ftf@omg.org, mof2xmi-ftf@omg.org, > > > > > > > mof2idl-ftf@omg.org > > > > > > > cc > > > > > > > > > > > > > > Subject > > > > > > > Fwd: Question on M-Levels > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > not sure if anybody saw this one....should I log this > > > > > > > one as an issue? If yes, which FTF would take care of it? > > > > > > > > > > > > > > -Juergen > > > > > > > > > > > > > > > > > > > > > From: "Uhl, Axel" > > > > > > > To: mof@omg.org > > > > > > > Subject: Question on M-Levels > > > > > > > Date: Thu, 9 Sep 2004 12:19:05 +0200 > > > > > > > X-Mailer: Internet Mail Service (5.5.2657.72) > > > > > > > X-SAP: out > > > > > > > > > > > > > > Hi there, > > > > > > > > > > > > > > section 7.2 of the MOF 2.0 specification (similar to > > > > > > > previous versions of the MOF spec) still contains > this bold > > > > > > > sentence: "The MOF 1.4 Reflection interfaces allow > > traversal > > > > > > > across any number of metalayers recursively." I'm > wondering > > > > > > > how I would create a MOF-based system with more > than three > > > > > > > layers that really "live" inside a MOF-based repository. > > > > > > > Let's take a look at UML, for example. If we forget for a > > > > > > > while that UML 2.0 and MOF 2.0 share a common > core, I could > > > > > > > consider the UML metamodel as just another modeling > > language > > > > > > > defined using MOF. > > > > > > > > > > > > > > Now the UML metamodel defines zillions of classes, all > > > > > > > of them being instances of MOF::Class. One of them > > happens to > > > > > > > be UML::Class, a classifying model element which > > allows me to > > > > > > > create model elements in the UML modeling languages that > > > > > > > themselves conceptually act as meta-objects that > I may wish > > > > > > > to instantiate. > > > > > > > > > > > > > > However, apart from the "shared core trick," the MOF > > > > > > > doesn't have any knowledge about the MOF::Class object > > > > > > > UML::Class being special, and in particular being a > > > > > > > classifying meta-object. > > > > > > > > > > > > > > The sentence from 7.2 suggests that I can have > > > > the following: > > > > > > > > > > > > > > myDog.getClass() == Dog > > > > > > > Dog.getClass() == UML::Class > > > > > > > UML::Class.getClass() == MOF::Class > > > > > > > > > > > > > > However, creation of a model element with the > > > > > > > reflective capabilities as found in the MOF 2.0 > > specification > > > > > > > seems to allow me only to create the UML::Class instance > > > > > > > named "Dog" as I can use UML::Class as an argument to > > > > > > > Factory::createObject(...). The resulting object, > > however, is > > > > > > > no longer an instance of MOF::Class and can > > therefore not be > > > > > > > used for a factory call in order to create an instance. > > > > > > > > > > > > > > Currently available language bindings for MOF 1.4 as I > > > > > > > understand them correspondingly don't allow for > > this flexible > > > > > > > multi-layering idea. Take JMI, for example. While the > > > > > > > standard defines how to derive the class proxy for > > > > > > > UML::Class, I cannot simply instantiate the UML::Class > > > > > > > instance Dog because it's not a MOF::Class instance. > > > > > > > > > > > > > > Would I have to import the MOF core into my metamodel > > > > > > > and have UML::Class specialize MOF::Class? > (Tricky enough, > > > > > > > MOF 2.0 doesn't even have to create a > > specialization relation > > > > > > > because the two are identical. But I think you get the > > > > > > > picture; I could have chosen to use my own metamodel, > > > > > > > different from UML, but still introducing a classifying > > > > > > > class.) If this was the case, then probably there > would be > > > > > > > something missing from the language bindings and > reflective > > > > > > > capabilities. For the JMI example, I'd then expect > > to be able > > > > > > > to obtain a class proxy for an instance of my > UML::Class so > > > > > > > that I can create instances of that particular UML class, > > > > > > > e.g., the "myDog" instance used in the example above. > > > > > > > > > > > > > > Any ideas? > > > > > > > > > > > > > > -- Axel (puzzled...) > > > > > > > > > > > > > > > > > > > > > ================================= > > > > > > > Jürgen Boldt > > > > > > > Director, Member Services > > > > > > > > > > > > > > Object Management Group > > > > > > > 250 First Avenue, Suite 100 > > > > > > > Needham, MA 02494 > > > > > > > > > > > > > > Tel. +1 781 444 0404 ext. 132 > > > > > > > Fax: +1 781 444 0320 > > > > > > > email: juergen@omg.org > > > > > > > www www.omg.org > > > > > > > > > > > > > > ================================ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: "Uhl, Axel" To: Pete Rivett Cc: mu2i-ftf@omg.org Subject: RE: Fwd: Question on M-Levels Date: Fri, 24 Sep 2004 14:19:05 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-SAP: out X-SAP: out Pete, thanks for the clarification. The key sentence you wrote is: > I was assuming that AxelsMetamodel in some way extended > UML:Basic, since that defines the essence of what it is to be > a metamodel. You may even use the term "meta-metamodel" instead of "metamodel" because AxelsMetamodel would be a metamodel even if it didn't extend UML:Basic. Doing so would raise it one M-level higher. > In order to be able to instantiate a class, its > metaclass needs to have some notion of typed > features/properties etc. And there neeeds to be some defined > way of generating an implementation and/or interchaneg format > for the class definition: which is defined by MOF for > metamodels based on UML:Basic. > > What would you like to see instead? Not instead, but maybe clarifying in addition. The essence of our thread could appear in the MOF spec and the language bindings, saying that a stacking more than the usual amount of M-levels on top of each other within one MOF environment requires the extension of UML:Basic. Complementary, the language binding specifications have to clarify that once a metamodel extends UML:Basic they are meta-meta, and some of the instances of the classes they define may themselves be classifiers that can further be instantiated. The language bindings should support that explicitly, and it should become clear how to do this. -- Axel (puzzled...)