Issue 15859: Problems in MOF operations delete(), invoke() and isInstanceOfType() operations (mof2core-rtf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: 13.3 describes an operation Object::delete() that does not appear in figure 13.2. The operation isInstanceOfType() makes sense for an Element but not for an Object where it is misspelled. The operation invoke() should be defined only on Object and should return set of Objects instead of a set of Elements. Resolution: in 13.3, delete the following operations: delete() isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean replace: invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] with: invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] in the metamodel, add: MOF::CMOFReflection::Object::invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] in 13.4, delete the operation: invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] in 13.4, rename the operation: instanceOfType(type: Class, includeSubtypes: Boolean): Boolean to: isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean Update the diagrams & metamodel accordingly Resolution: It is unclear from the MOF2.0 Core specification where the Object::delete() operation is to be defined; it could be in MOF::Reflection::Object or in MOF::CMOFReflection::Object. It is also unclear whether each specialization of Object should have a delete operation – e.g., there is no delete() for MOF::Common::ReflectiveCollection. With so many important details under-specified, it is better to remove this operation than to leave it. Since the resolution to issue 15825 for Object::getType() is deferred, it does not make sense to have Object::isInstanceOfType() either, this operation should be deleted and only defined for Element as described in the summary. In 13.3, invoke() returns a collection of Elements but in 13.4, it returns a collection of Objects. Clearly an operation could return any kind of Object; the return type should be Object, not Element. Since MOF::Common::ReflectiveCollection provides the capability for representing a collection of Objects, it is not necessary for invoke() to return yet another collection of Objects, a single Object suffice; if the actual return is in fact a collection of Objects, then the return can be a single ReflectiveCollection object. Therefore, the multiplicity on the return parameter should be changed from 0..* to 0..1 Revised Text: see pages 67 - -70 of OMG document ptc/2010-12-07 Actions taken: December 2, 2010: received issue April 25, 2011: closed issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Dec 2010 10:03:58 -0500 To: issues@omg.org, mof2core-rtf@omg.org From: Juergen Boldt Subject: issue15859 -- MOF 2 Core RTF issue From: "Rouquette, Nicolas F (316A)" To: Juergen Boldt CC: Steve Cook , Pete Adaptive Date: Wed, 1 Dec 2010 21:58:58 -0800 Subject: Re: CMOFReflection::Object::delete() Thread-Topic: CMOFReflection::Object::delete() Thread-Index: AcuR5gQoWYSJDfCjQpaF3h+2O9B9OA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id oB25cmvR006057 Juergen, We need an issue number for the last ballot for MOF2.4 for the following: Title: Problems in MOF operations delete(), invoke() and isInstanceOfType() operations Summary: 13.3 describes an operation Object::delete() that does not appear in figure 13.2. The operation isInstanceOfType() makes sense for an Element but not for an Object where it is misspelled. The operation invoke() should be defined only on Object and should return set of Objects instead of a set of Elements. Resolution: in 13.3, delete the following operations: delete() isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean replace: invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] with: invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] in the metamodel, add: MOF::CMOFReflection::Object::invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] in 13.4, delete the operation: invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] in 13.4, rename the operation: instanceOfType(type: Class, includeSubtypes: Boolean): Boolean to: isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean Update the diagrams & metamodel accordingly. -- Nicolas. On Dec 1, 2010, at 5:43 PM, Rouquette, Nicolas F (316A) wrote: > So it's version 2 then -- Do you agree Pete? > > - Nicolas. > > On Dec 1, 2010, at 5:37 PM, Steve Cook wrote: > >> It seems to me that option 1 leaves no reflective invoke() operation at all, which seems wrong. >> >> -----Original Message----- >> From: Rouquette, Nicolas F (316A) [ mailto:nicolas.f.rouquette@jpl.nasa.gov] >> Sent: 01 December 2010 17:31 >> To: Steve Cook; Pete Adaptive >> Subject: Re: CMOFReflection::Object::delete() >> >> Steve, Pete: >> >> We're getting close -- if I understand you Steve, the choice boils down to version 1 or 2 below. >> >> version 1: >> >>>> in 13.3, delete the 3 operations, i.e.: >>>> >>>> delete() >>>> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >>>> isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean >>>> >>>> in 13.4, delete the operation: >>>> >>>> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >>>> >>>> in 13.4, rename the operation: >>>> >>>> instanceOfType(type: Class, includeSubtypes: Boolean): Boolean >>>> >>>> to: >>>> >>>> isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean >>>> >>>> Update the diagrams & metamodel accordingly. >> >> version2: >> >> >>>> in 13.3, delete the 3 operations, i.e.: >>>> >>>> delete() >> >> replace: >> >> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >> >> with: >> >> invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] >> >> in the metamodel, add: >> >> MOF::CMOFReflection::Object::invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*] >> >>>> >>>> in 13.4, delete the operation: >>>> >>>> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >>>> >>>> in 13.4, rename the operation: >>>> >>>> instanceOfType(type: Class, includeSubtypes: Boolean): Boolean >>>> >>>> to: >>>> >>>> isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean >>>> >>>> Update the diagrams & metamodel accordingly. >> >> I can do either one and ask Juergen for an issue but I need your concurrence to do anything. >> >> - Nicolas. >> >> On Dec 1, 2010, at 5:18 PM, Steve Cook wrote: >> >>> Nic >>> >>>> It is my professional opinion that MOF2.4, as specified, is >>>> unimplementable >>> I agree with you. But it's still significantly better than MOF 2.0. >>> >>> As far as I am concerned, the only goal for MOF 2.4 is to publish it so that the XMI for UML 2.4 has some "normative" legitimacy. In that sense, the reflective API is of no consequence. Since the reflective API is no worse than it was in previous versions of the MOF spec I think this is an appropriate point to declare success. >>> >>> As for the rest, it is all grist for the mill of the Architecture Ecosystem. There needs to be some appropriate successor to MOF which is well-defined. OCL needs to be properly integrated. And so on. But that is all for the future. >>> >>> -- Steve >>> >>> -----Original Message----- >>> From: Rouquette, Nicolas F (316A) >>> [ mailto:nicolas.f.rouquette@jpl.nasa.gov] >>> Sent: 01 December 2010 15:21 >>> To: Steve Cook >>> Cc: Pete Adaptive >>> Subject: Re: CMOFReflection::Object::delete() >>> >>> invoke(), as specified in 13.4 is really an embarrassment. >>> >>> 15.4's version of invoke() is much better: >>> >>> Object::invoke(Operation op, Set{Tuple{Parameter p, ValueSpecification >>> v}} args):Element >>> >>> This one is better but it is still not adequate. >>> >>> Object::invoke() should operate on a BehavioralFeature, not just an Operation. >>> Since BehavioralFeature::parameter is an ordered collection, it should have a Sequence, not a Set of tuples. >>> The tuples should be of Parameter/Object, not Parameter/ValueSpecification. >>> >>> I'll stop here. >>> >>> It is my professional opinion that MOF2.4, as specified, is unimplementable; put it another way, I think that any vendor claiming to implement MOF2.4 would either be an absolute fool or a liar. >>> >>> Element/Link::delete() is an embarrassing implementation trap -- trying to delete a circular structure of objects/links leads to an infinite recursion. >>> >>> MOF2.4 lacks a capability to convert between ValueSpecifications & Objects and vice-versa. >>> FUML has one but it has the same infinite recursion trap as >>> Element/Link::delete() in MOF2.4 >>> >>> The right fix would be to define delete(), invoke() and conversion operations in Factory. >>> Factory provides the only context where an implementation can properly handle the cases for converting/deleting recursive structures. >>> However, I think that this is definitely beyond what is reasonable to do in MOF2.4. >>> >>> - Nicolas. >>> >>> On Dec 1, 2010, at 2:46 PM, Steve Cook wrote: >>> >>>> Almost. I was not suggesting deleting invoke() from 13.4 - I think that reflective invocation on Element should stay. >>>> >>>> To be honest I don't really understand what operations should be on Object and what operations should be on Element. By the way the existing semantics chapter is totally confused about Object vs Element, so I am not the only one that is confused here. >> >>>> >>>> -- Steve >>>> >>>> -----Original Message----- >>>> From: Rouquette, Nicolas F (316A) >>>> [ mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>> Sent: 01 December 2010 14:03 >>>> To: Steve Cook >>>> Cc: Pete Adaptive >>>> Subject: Re: CMOFReflection::Object::delete() >>>> >>>> Steve, >>>> >>>> Are you suggesting a raising an issue whose resolution would be the following: >>>> >>>> in 13.3, delete the 3 operations, i.e.: >>>> >>>> delete() >>>> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >>>> isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean >>>> >>>> in 13.4, delete the operation: >>>> >>>> invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*] >>>> >>>> in 13.4, rename the operation: >>>> >>>> instanceOfType(type: Class, includeSubtypes: Boolean): Boolean >>>> >>>> to: >>>> >>>> isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean >>>> >>>> Update the diagrams & metamodel accordingly. >>>> >>>> Is this correct? >>>> >>>> Note that we still have operations on Object: >>>> >>>> 15825 adds Object::getType(). >>>> 15832 moved several operations from Element to Object: equals, get/set/isSet/unset for object properties. >>>> >>>> - Nicolas. >>>> >>>> >>>> On Dec 1, 2010, at 1:43 PM, Steve Cook wrote: >>>> >>>>> 13.3 also says we have Object::invoke() and Object::isInstanceOfType(), which are obvious duplicates of the ones in Element. >>>>> >>>>> I thought we agreed we'd get rid of all the operations on Object, because they don't show up in figure 13.2 (and because the signature of Object::Invoke is clearly wrong), and change Element::instanceOfType() to Element::isInstanceOfType(), because it is spelt wrongly in 13.4. >>>>> >>>>> -- Steve >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Rouquette, Nicolas F (316A) >>>>> [ mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>> Sent: 01 December 2010 13:19 >>>>> To: Steve Cook >>>>> Cc: Pete Adaptive >>>>> Subject: Re: CMOFReflection::Object::delete() >>>>> >>>>> Doing nothing isn't an option because 13.3 already states we have Object::delete() The problem therefore is where do we stick this operation? >>>>> >>>>> The first issue is the simplest fix I can think of that leaves MOF well-formed and incorporates the intent of clause 13. >>>>> >>>>> I can do this today and the resolution for 15820 but I need to know if you and Pete concur. >>>>> >>>>> - Nicolas. >>>>> >>>>> On Dec 1, 2010, at 12:56 PM, Steve Cook wrote: >>>>> >>>>>> I think we are fast running out of time. Is it possible to create a well-formed model without doing this? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Rouquette, Nicolas F (316A) >>>>>> [ mailto:nicolas.f.rouquette@jpl.nasa.gov] >>>>>> Sent: 01 December 2010 11:40 >>>>>> To: Steve Cook; Pete Adaptive >>>>>> Subject: CMOFReflection::Object::delete() >>>>>> >>>>>> Pete, Steve, >>>>>> >>>>>> The situation for Object::delete() is a tad more convoluted. >>>>>> We need 2 separate issues. >>>>>> >>>>>> issue 1: MOF::CMOFReflection::Object::delete() >>>>>> >>>>>> This operation is described in clause 13.3 Object but isn't shown in any of the diagrams. >>>>>> >>>>>> The proposed resolution would be: >>>>>> >>>>>> - Show in figure 13.2 both MOF::Reflection::Object (without delete) and MOF::CMOFReflection::Object (with delete). >>>>>> - Define MOF::CMOFReflection::Object::delete() as non-abstract. >>>>>> - MOF::CMOFReflection::Link::delete { redefines >>>>>> MOF::CMOFReflection::Object::delete() } >>>>>> - MOF::CMOFReflection::Element::delete { redefines >>>>>> MOF::CMOFReflection::Object::delete() } >>>>>> >>>>>> issue 2: EMOF/CMOF Object hierarchy & capabilities >>>>>> >>>>>> The taxonomy of Object in EMOF/CMOF is under specified: some classes in MOF::CMOFReflection are defined without explicitly specializing Object or Element: Exception, Argument Clause 13.3 gives CMOF the capability to delete CMOF Objects; surely, there must be a capability for deleting EMOF Objects as well, including ReflectiveCollection, Extent & Element. >>>>>> >>>>>> Deferred in MOF2.4. >>>>>> >>>>>> Do you agree? >>>>>> >>>>>> - Nicolas. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org