Issue 3447: MOF 1.3 Why prevent nonpublic Associations? (mof-rtf) Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com) Nature: Uncategorized Issue Severity: Summary: In the MOF 1.3 Specification, constraint C-37 requires Associations to be public. Support for nonpublic Associations is a valuable capability that should not be forbidden. In particular, when there are references on all navigable ends of an Association, the M1 Association object is fully redundant in the capabilities it provides. Making the Association private or protected eliminates the need to support redundant public interfaces for capabilities available most conveniently through references. The association is an important part of the model in that it defines the semantics and behavior of the references, but no public Association interface is needed. The IDL and other interfaces generated from metamodels is already too large. Constraint C-37 simply makes it larger than it needs to be. Note that the CWM submitters to OMG desire to use nonpublic associations extensively in CWM's 26 metamodels. Recommendation: Delete C-37. Resolution: Revised Text: Actions taken: March 22, 2000: received issue Discussion: End of Annotations:===== From: "Baisley, Donald E" To: issues@omg.org Subject: MOF 1.3 Why prevent nonpublic Associations? Date: Wed, 22 Mar 2000 18:51:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: j>D!!'05!!M1C!!@HJ!! In the MOF 1.3 Specification, constraint C-37 requires Associations to be public. Support for nonpublic Associations is a valuable capability that should not be forbidden. In particular, when there are references on all navigable ends of an Association, the M1 Association object is fully redundant in the capabilities it provides. Making the Association private or protected eliminates the need to support redundant public interfaces for capabilities available most conveniently through references. The association is an important part of the model in that it defines the semantics and behavior of the references, but no public Association interface is needed. The IDL and other interfaces generated from metamodels is already too large. Constraint C-37 simply makes it larger than it needs to be. Note that the CWM submitters to OMG desire to use nonpublic associations extensively in CWM's 26 metamodels. Recommendation: Delete C-37. Don Baisley Unisys X-Mailer: exmh version 2.1.0 09/18/1999 To: "Baisley, Donald E" cc: issues@omg.org, crawley@dstc.edu.au Subject: Re: MOF 1.3 Why prevent nonpublic Associations? In-Reply-To: Message from "Baisley, Donald E" of "Wed, 22 Mar 2000 18:51:15 EST." Mime-Version: 1.0 Date: Thu, 30 Mar 2000 15:57:30 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: 5aE!!V In the MOF 1.3 Specification, constraint C-37 requires Associations to be > public. Support for nonpublic Associations is a valuable capability that > should not be forbidden. In particular, when there are references on all > navigable ends of an Association, the M1 Association object is fully > redundant in the capabilities it provides. Making the Association private > or protected eliminates the need to support redundant public interfaces for > capabilities available most conveniently through references. The > association is an important part of the model in that it defines the > semantics and behavior of the references, but no public Association > interface is needed. The IDL and other interfaces generated from metamodels > is already too large. Constraint C-37 simply makes it larger than it needs > to be. Oh dear. We've been here before. IMO, "visibility" of metadata is oxymoronic. Since MOF 1.3, it has been clear that the MOF Model is a language for expressing abstract Information models for metadata. For historical and political reasons, the Model is currently "polluted" with stuff that is to do with interface specification. The "visibility" attribute is one example. Others include References, Operations, "changeability", "navigability" and so on. [As a rough rule of thumb, we are talking about those Model features that are irrelevant to the XMI mappings ... ] There are serious problems with having stuff that specifies interfaces in the MOF Model: 1) Some aspects of interfaces are necessarily technology specific. For instance, IDL has no notion "visibility", "navigability" makes little sense if your metadata is in memory, Operations have the problem of how to specify what they mean. 2) If you start embedding technology specific design decisions in a MOF meta-model, you will run into problems when you try to use the meta-model in the context of a different technology. Meta-modelling decisions made in the original context may lead to inconvenient or even unworkable 3) In many situations, decisions about what interfaces ought to look like are better viewed as application design issues rather than meta-modelling issues. Meta-modelling is mostly about deciding / agreeing on what metadata means. For this reason, I disagree with allowing protected and/or private Associations. IMO, we shouldn't be going further down the wrong road. In an ideal world, here's what I think we should do ... 1) Go through the MOF Model, removing those constructs that are to do with specifying metadata interfaces, behaviour and the concrete representation of data values. 2) Create a new meta-meta-model called the IDL Mapping Model that allows you to: - suppress interfaces, attributes, operations, etc - rename mapped interfaces, operations, attributes, etc - select between different ways of dealing with multi-valued things; e.g. sequences versus iterators, elementwise update or not. - add Operations, derived Attributes, References, etc - select or override use of concrete data types - specify IDL supertypes, prefixes, This needs to be done conjunction with an overhaul of the IDL mapping 3) Create a new new meta-meta-model called (say) the Java Mapping Model that allows you to: - do any of the above that are meaningful in a Java context - specify Java package structures - specify which classes, attributes, operations, etc are private protected, public, etc. This needs to be done in conjunction with specification of a new Java Mapping. 4) Revisit the XMI mapping and do something similar. If References are gone from the MOF Model, we could flatten out the generated DTDs. Alternatively, we could put stuff in the XMI Mapping Model that allows the meta-modeller to tell the XMI mappings to produce "nicer" DTDs and XML documents. OK, so this is a huge lot of work. But at some point we are going to have to do something like this if we are going to achieve the goal of a technology independent metadata framework. > Note that the CWM submitters to OMG desire to use nonpublic associations > extensively in CWM's 26 metamodels. What the CWM submitters really want and need is the ability to more closely control the APIs produced by the IDL mapping. Lets give it to them, but lets do it without twisting the concept of visibility. 1) The long term solution is to overhaul the MOF Model as above. 2) The short term solution is to add some Tags to the IDL Mapping to allow you to suppress particular IDL interfaces or operations. We were talking about doing 2) in MOF 1.3, but nobody put forward a concrete proposal. -- Steve X-Mailer: exmh version 2.1.0 09/18/1999 To: mof-rtf@omg.org Subject: Re: MOF 1.3 Why prevent nonpublic Associations? Mime-Version: 1.0 Date: Mon, 03 Apr 2000 12:30:04 +1000 From: Stephen Crawley Content-Type: text/plain; charset=us-ascii X-UIDL: %60!!j/e!!Xj_!!&d7e9 > In the MOF 1.3 Specification, constraint C-37 requires Associations to be > public. Support for nonpublic Associations is a valuable capability that > should not be forbidden. In particular, when there are references on all > navigable ends of an Association, the M1 Association object is fully > redundant in the capabilities it provides. Making the Association private > or protected eliminates the need to support redundant public interfaces for > capabilities available most conveniently through references. The > association is an important part of the model in that it defines the > semantics and behavior of the references, but no public Association > interface is needed. The IDL and other interfaces generated from metamodels > is already too large. Constraint C-37 simply makes it larger than it needs > to be. Oh dear. We've been here before. IMO, "visibility" of metadata is oxymoronic. Since MOF 1.3, it has been clear that the MOF Model is a language for expressing abstract Information models for metadata. For historical and political reasons, the Model is currently "polluted" with stuff that is to do with interface specification. The "visibility" attribute is one example. Others include References, Operations, "changeability", "navigability" and so on. [As a rough rule of thumb, we are talking about those Model features that are irrelevant to the XMI mappings ... ] There are serious problems with having stuff that specifies interfaces in the MOF Model: 1) Some aspects of interfaces are necessarily technology specific. For instance, IDL has no notion "visibility", "navigability" makes little sense if your metadata is in memory, Operations have the problem of how to specify what they mean. 2) If you start embedding technology specific design decisions in a MOF meta-model, you will run into problems when you try to use the meta-model in the context of a different technology. Meta-modelling decisions made in the original context may lead to inconvenient or even unworkable 3) In many situations, decisions about what interfaces ought to look like are better viewed as application design issues rather than meta-modelling issues. Meta-modelling is mostly about deciding / agreeing on what metadata means. For this reason, I disagree with allowing protected and/or private Associations. IMO, we shouldn't be going further down the wrong road. In an ideal world, here's what I think we should do ... 1) Go through the MOF Model, removing those constructs that are to do with specifying metadata interfaces, behaviour and the concrete representation of data values. 2) Create a new meta-meta-model called the IDL Mapping Model that allows you to: - suppress interfaces, attributes, operations, etc - rename mapped interfaces, operations, attributes, etc - select between different ways of dealing with multi-valued things; e.g. sequences versus iterators, elementwise update or not. - add Operations, derived Attributes, References, etc - select or override use of concrete data types - specify IDL supertypes, prefixes, This needs to be done conjunction with an overhaul of the IDL mapping 3) Create a new new meta-meta-model called (say) the Java Mapping Model that allows you to: - do any of the above that are meaningful in a Java context - specify Java package structures - specify which classes, attributes, operations, etc are private protected, public, etc. This needs to be done in conjunction with specification of a new Java Mapping. 4) Revisit the XMI mapping and do something similar. If References are gone from the MOF Model, we could flatten out the generated DTDs. Alternatively, we could put stuff in the XMI Mapping Model that allows the meta-modeller to tell the XMI mappings to produce "nicer" DTDs and XML documents. OK, so this is a huge lot of work. But at some point we are going to have to do something like this if we are going to achieve the goal of a technology independent metadata framework. > Note that the CWM submitters to OMG desire to use nonpublic associations > extensively in CWM's 26 metamodels. What the CWM submitters really want and need is the ability to more closely control the APIs produced by the IDL mapping. Lets give it to them, but lets do it without twisting the concept of visibility. 1) The long term solution is to overhaul the MOF Model as above. 2) The short term solution is to add some Tags to the IDL Mapping to allow you to suppress particular IDL interfaces or operations. We were talking about doing 2) in MOF 1.3, but nobody put forward a concrete proposal. - -- Steve