Issue 784: External Types as DataTypes Limits Modeling (mof-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Minor Summary: Summary: Because typedefs and external types are represented as instances of DataType, it is not possible to inherit from, or define an association with, an external type, such as CORBA::InterfaceDef Resolution: closed, to be implemented Revised Text: RESOLUTION 1/12/99: Option 3 has the limitation of 'pollutes' the metamodel with extra-neous IDL generation properties. Approach 2 allows integration of existing CORBA IDL and hence Interfaces better with the MOF. Implementation: Following email discussions ... added "Note" in Section , “Class Generalization,” on page 2-8 refers to use of a Tag to specify IDL inheritance. Added text to define Tags in Section 5.6.3, “Tags for specifying IDL inheritance,” on page 5-37. Done. [SC] Implementation: Ammended template sections to call up these tags; see sections 5.8.4, 5.8.6, 5.8.7 and 5.8.10. Added a note to Section 5.2.2, “The Meta Object Interface Hierarchy,” on page 5-4 to mention the effect of the Tags on the inheritance graph. Done. [SC] Actions taken: December 3, 1997: received issue July 23, 1999: closed issue Discussion: Discussion: The manner in which MOF provides for representation of external types (types not defined within a MOF Model) is through the DataType class. For models translated into IDL, only IDL external types (interfaces) are interesting. Since each DataType object identifies its type through a TypeCode, the external type can be represent-ed as either an object reference or type alias TypeCode. However, in so doing, the external type can only be treated in MOF models as a DataType, so instances of MofClass cannot inherit from them, and associations cannot be defined between a MofClass and an external type. This restriction makes it impossible to define a MofClass which derives from the Life Cycle Service interface CosLifeCycle::LifeCycleObject, for instance. The best solution re-quires some research. Perhaps an ExternalClass type should be added to the MOF Model, derived from MofClass, with a TypeCode attribute. Then additional constraints could in-sure that object reference and type aliases which resolve to object references could only be used in ExternalClass, and that ExternalClass could use no other TypeCode kinds. DSTC Response (kerry@dstc.edu.au). There are 3 possible solutions. 1. Do nothing. Any interface produced by the MOF's IDL generation can be further extend-ed by inheritance, if desired. If only a few interfaces require such extension, then this is the simplest route for the implementer. However, if every interface needs to be extended e.g. to incorporate COS LifeCycle or other CORBAservices, it would be inconvenient to do it this way (possible but inconvenient). If we take this solution, we should document it in a FAQ. 2. Relax the constraint that prevents Class being Generalised by DataType. Since any ex-ternal object type can be introduced into a MOF model as a DataType, allowing a Class to inherit from such DataTypes would achieve the desired inheritance. Naturally, there would have to be an associated constraint that the DataType was an object-type and not (say) an integer. There might be some minor impact on the Namespaces (to be further investigated). The disadvantage of this approach is that the Generalises association is about concept gen-eralisation (a first class issue), rather than inheritance of the generated IDL (a second class issue). 3. Add a new ModelElement to the MOF Model called (say) "Interface" which models any CORBA object . Add a new Association called (say) "Extends". The Extends Association would relate a Class with the legacy Interface that it was extending. Orlando RTF Resolution. Add a new ModelElement to the MOF Model called (say) "Interface" which models any CORBA object . Add a new Association called (say) "Extends". The Extends Association would relate a Class with the legacy Interface that it was extending. DSTC Response (crawley@dstc.edu.au). This could be made to work. We are in danger of moving down the "slippery slope" of mod-elling CORBA IDL in the core MOF, and by implication subsuming the function of the CORBA Interface Repository. Is this activity within the scope of what the MOF-RTF should be doing? If we go down this road here/now, we risk making the current problems CORBA has with interface versioning a LOT worse. So far, MOF has carefully avoided the need to duplicate or replace existing IFR function-ality by using CORBA TypeCodes to represent "ordinary" CORBA data and object types. In the case of the object types, the TypeCode contains a RepositoryId for the interface that can be used to retrieve the interface definition from a CORBA IFR. End of Annotations:===== Return-Path: Subject: MOF RTF Issue - External Types as DataTypes Limits Modeling To: mof-rtf@omg.org Date: Wed, 3 Dec 1997 02:13:50 +0000 (GMT) From: GK Khalsa Reply-to: khalsa@objectrad.com Organization: Object Radiance, Inc. Source: Unisys (GK Khalsa, khalsa@objectrad.com) Nature: Mof Model Severity: Minor Summary: Because typedefs and external types are represented as instances of DataType, it is not possible to inherit from, or define an association with, an external type, such as CORBA::InterfaceDef Resolution: Revised Text: Actions taken: Discussion: The manner in which MOF provides for representation of external types (types not defined within a MOF Model) is through the DataType class. For models translated into IDL, only IDL external types (interfaces) are interesting. Since each DataType object identifies its type through a TypeCode, the external type can be represented as either an object reference or type alias TypeCode. However, in so doing, the external type can only be treated in MOF models as a DataType, so instances of MofClass cannot inherit from them, and associations cannot be defined between a MofClass and an external type. This restriction makes it impossible to define a MofClass which derives from the Life Cycle Service interface CosLifeCycle::LifeCycleObject, for instance. The best solution requires some research. Perhaps an ExternalClass type should be added to the MOF Model, derived from MofClass, with a TypeCode attribute. Then additional constraints could insure that object reference and type aliases which resolve to object references could only be used in ExternalClass, and that ExternalClass could use no other TypeCode kinds. --- GK Khalsa khalsa@objectrad.com Object Radiance, Inc. v: +1 909 677 2518 http://www.objectrad.com f: +1 909 677 1478 Return-Path: To: khalsa@objectrad.com Cc: mof-rtf@omg.org Subject: Re: MOF RTF Issue - External Types as DataTypes Limits Modeling Date: Wed, 03 Dec 1997 13:27:56 +1000 From: Kerry Raymond > However, in so doing, the external type can only be treated in MOF > models as a DataType, so instances of MofClass cannot inherit from > them, and associations cannot be defined between a MofClass and an > external type. This restriction makes it impossible to define a > MofClass which derives from the Life Cycle Service interface > CosLifeCycle::LifeCycleObject, for instance. >From a modelling perspective, we *shouldn't* allow people to define MofClasses which derive from an existing CORBA interface. One is a model; the other is an interface; two different things ... What I think GK is really asking for is to enable the interfaces IDL-generated from the MofClass to inherit from Life Cycle or other existing CORBA interfaces ... And my answer to that is ... there is nothing that stops anyone from defining an interface which multiply-inherits from a MOF-generated interface and some existing CORBA interface like LifeCycle. I think there *is* an important distinction between the functionality that MOF requires (and hence generates IDL for) and any additional functionality that is required in an implementation. I think it would be a mistake to allow a MofClass to have attached info of the form "inherit from this CORBA interface when IDL is generated". I could be sympathetic to an argument specifically about LifeCycle. That is, I could be talked into having all MOF interfaces inherit from LifeCycle, provided we had some detailed semantic rules on what it means to "move" or "delete" things that have dependencies to other MOF objects. Kerry ============================================================================= Dr Kerry Raymond, Architecture Unit Leader E-mail: kerry@dstc.edu.au CRC for Distributed Systems Technology Phone: +61 7 3365 4310 University of Queensland 4072 Australia Fax: +61 7 3365 4311 =========================================== WWW: http://www.dstc.edu.au/kerr