Issues for Meta-Object Facility Revision Task Force discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Jira Issues

Issue 1082: Generated operations returning attributes/references should not raise Cons Jira Issue MOF14-61
Issue 1505: MOF RTF Isue: Conflict between "Facility" and "Package Object " Jira Issue MOF14-62
Issue 1540: ModelElement needs to have permanent, unique, unchanging, identifier Jira Issue MOF14-63
Issue 1804: Semantics of Reference "set" onto an ordered Association. Jira Issue MOF14-64
Issue 2046: What is a UML "profile"? Jira Issue MOF14-65
Issue 2165: Tags that parameterize a meta-model mapping Jira Issue MOF14-66
Issue 2173: Validate the OCL constraints in the MOF specification Jira Issue MOF14-67
Issue 2174: Add support for default values to MofAttribute Jira Issue MOF14-68
Issue 2177: Add support for Exception generalization Jira Issue MOF14-69
Issue 2178: Define a MOF Class that is the supertype of all Classes Jira Issue MOF14-70
Issue 2179: Add appropriate Attribute default values to the MOF Model Jira Issue MOF14-71
Issue 2181: Specify the semantics of Constraint verification Jira Issue MOF14-72
Issue 2182: Freezing mechanism for all models Jira Issue MOF14-73
Issue 2183: Add a new technical overview chapter between chapters 2 and 3" Jira Issue MOF14-74
Issue 2186: Need for light-weight References Jira Issue MOF14-75
Issue 2188: MOF Model IDL versus OMG Style guidelines Jira Issue MOF14-76
Issue 2224: Should Reflective.DesignatorType be "string"? Jira Issue MOF14-77
Issue 2449: Provide tools to chapter 5 UML 1.3R9 draft Jira Issue MOF14-78
Issue 2527: IDL for Reflective Package Interfaces can conflict Jira Issue MOF14-79
Issue 2839: Do non-public Attributes need initialising? Jira Issue MOF14-80
Issue 2876: WG: Attribute accessors and mutators Jira Issue MOF14-81
Issue 2923: mof rtf issue - setting UUIDs Jira Issue MOF14-82
Issue 2925: mof rtf issue - coverage of RefXXX interfaces by MOF metamodel Jira Issue MOF14-83
Issue 3043: MOF and IDL repository ids Jira Issue MOF14-1
Issue 3112: Template should suppress add for [x..x] Attributes Jira Issue MOF14-2
Issue 3411: MOF specifies no interfaces for actually (de-)serializing a model Jira Issue MOF14-3
Issue 3445: MOF 1.3 IDL template for clustering uses wrong name Jira Issue MOF14-4
Issue 3447: MOF 1.3 Why prevent nonpublic Associations? Jira Issue MOF14-5
Issue 3448: MOF 1.3 Package should subtype Classifier Jira Issue MOF14-6
Issue 3744: Minor changes to some Reflective operations Jira Issue MOF14-7
Issue 3745: Reflective interface for Package factory Jira Issue MOF14-8
Issue 3897: Specify XMI parameters for the MOF / XMI interchange format Jira Issue MOF14-9
Issue 4111: The Metadata architecture needs to move away from the 4 levels and labels Jira Issue MOF14-10
Issue 4231: predefined tag for marking attributes to act as qualifier in classifier Jira Issue MOF14-11
Issue 4232: role is named 'containedElement' while the reference is named 'contents' Jira Issue MOF14-12
Issue 4238: The role name of the Namespace->ModelElement association end Jira Issue MOF14-13
Issue 4255: MOF IDL rules to minimize network roundtrips Jira Issue MOF14-14
Issue 4267: MOF-RTF issue: AttachesTo.modelElement - ordered Jira Issue MOF14-15
Issue 4383: The current MOF package level import is not sufficient Jira Issue MOF14-16
Issue 4419: Disallow null instance values Jira Issue MOF14-17
Issue 4483: Add 'semantics' attribute to Operation. Jira Issue MOF14-18
Issue 4484: Delete all non-MOF-specific terms from the Glossary Jira Issue MOF14-19
Issue 4568: Representation of constraints Jira Issue MOF14-20
Issue 4569: Modeling OCL Helper Functions Jira Issue MOF14-21
Issue 4584: mof-rtf issue: Association Generalization Jira Issue MOF14-22
Issue 4586: Tracking identity of replicated / interchanged metadata Jira Issue MOF14-23
Issue 4592: Alignment of reflective interfaces with JMI Jira Issue MOF14-24
Issue 4593: Deprecate object inheritance of class proxy interface Jira Issue MOF14-25
Issue 4594: Remove obsolete material Jira Issue MOF14-26
Issue 4607: resolveQualifiedName operation Jira Issue MOF14-27
Issue 4609: Looking up metaobject using MOFID Jira Issue MOF14-28
Issue 4621: Navigability of assoc. ends in MOF model Jira Issue MOF14-29
Issue 4622: Restrictions needed for nested Packages and Classes Jira Issue MOF14-30
Issue 4664: Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong Jira Issue MOF14-31
Issue 4700: Multiplicity be optional for non-navigable association ends. Jira Issue MOF14-32
Issue 4715: Unnecessary constraint on import by nested packages Jira Issue MOF14-33
Issue 4720: Association Generalization Proposal Jira Issue MOF14-34
Issue 4798: "exposedEnd" for any of the references in the MOF metamodel. Jira Issue MOF14-35

Issue 1082: Generated operations returning attributes/references should not raise Cons (mof-rtf)

Summary: The generated IDL for the MOF includes ConstraintError in   the raises clause of operations generated via the Attribute   Template and Reference Template, although these templates do   not include spcification of that exception (identified in a   separate issue).  When that specification is updated, it   should specify that the generated "read" operations do not   raise this exception.  The current IDL has ConstraintError   in the raises clause of the following operations, which do   not change the state of the model:    

Response: The situation is more complex than it seems. What should we do if we discover  that the current value of an Attribute or Reference violates the applicable Constraints? Do  we raise the ConstraintError exception, or just return the value and not warn the user thatthe value is violating the model's constraints?  Deferred pending specification of Constraint verification. (#1085).  Implementation: This issue is mostly superceded by the overhaul of the exceptions in  which ConstraintError is rolled into MofError; see �Issue 1085:  Consider a better approach to generated exceptions (mof-rtf)�.  Implementation: However, we should not rule out constraint errors occuring in At-tribute  / Reference read operations. In particular, when the At-tribute  or referenced Association is derived. This is discussed in  Section 4.11.5, �Access operations should avoid raising Constraint  exceptions,� on page 4-23. Done [SC]

Summary: There is a major conflict between the "Facility" Package   described in Section 4 and the M1-level object model expressed in   Section 7.  Section 4 defines a concept of a "model repository",   embodied by the Facility::ModelRepository class, as the boundary for   M1-level associations and classifier level state.  Indeed, this seems   to be the main purpose of Facility::ModelRepository instances.  On the   other hand, the IDL mapping in Section 7 defines the M1-level   <package-name>Package interface with the primary purpose of providing   this boundary.  [Section 5 is ambiguous.]  This overlap in purpose and   functionality is causing confusion, and is obscuring the need for   standardisation of something to provide a container and a directory   for a set of (possibly unrelated) models and meta-models.    

Discussion - [email protected]: In recent between DSTC and UNISYS, these points  have become clearer:  1. The Facility section tries to address the problem of clustering Packages. This prob-lem  is really a core meta-modelling issue rather than a "repository" issue. UNISYS  agree with this analysis, and DSTC and UNISYS have jointly developed the "Pack-age  Clustering" Model extension (see issue 2176) to address this aspect.  2. The Facility "package" can also be understood as a design pattern that uses the  MOF meta-modelling constructs to extend the interfaces of M1 level instances of a  Package in a meta-model. For example, ModelRepository adds hierarchical nam-ing  of Model::Package instances and some convenience functions, and MofPack-age  adds support for external Tags.  3. The Facility section was not intended to define a MOF repository architecture.  4. UNISYS have (I believe) agreed that Facility can be an optional compliance point.  Proposed partial resolution:  1. The Facilities chapter should be made an optional conformance point.  2. The use of MofRepository as Package clustering mechanism should be deprecated  in favour of the proposed Model extension for Package consolidation.  3. MofRepository instances should contain (freezable) TagSets rather than Tags, and  a mechanism should be implemented that allows a client to find the relevant Tags  starting from an M1 level RefPackage instance.  4. The Facilities chapter should be updated to make it clearer what its purpose is. It  is important to separate the "design pattern" from the "application" of that pattern  to extend the functionality of the MOF Model.  Further discussion - [email protected]:  1. Does the MOF specification need to address conventional repository issues? For  example, should it define interfaces that provide a "top level" naming structure for  models and meta-models? Should it specify / discuss how to implement different re-pository  architectures; e.g. "open", "closed" and "single model".  2. While it is appropriate using modelling to specify extensions to the functionality of  Package instances, is it appropriate to use the MOF Model to IDL mapping to im-plement  them?:  � Pro: the Facility approach allows you to implement required "repository"  extensions without changing the base meta-model. Using the MOF Model  mappings to generate the interfaces and implementation avoids the need to  hand write IDL, MDL, Java classes and so on.  � Con: the Facility approach gives bloated IDL. For example, the IDL for Fa-cility  contains 6 interfaces, where only one would be required to implement  the same functionality extensions directly in IDL.  1. Is the Facility pattern the best way to extend functionality? Would alternative mod-elling  patterns would give better interfaces? For example, if we defined Facility as a subtype package of Model and MofRepository as a subtype class of Package, we  wouldn't need to have the "kludge" of a MofRepository object with a Model::Mod-elPackage  object as an attribute.  One way to "address" the repository architectures and interfaces requirements is to rule  them out of scope for the RTF. We should then consider issuing a new RFP to address these  issues.  Washington - A proposal to support COS::Naming and JNDI for name service is being re-searched  to address some the issues identified. Proposal to be made before March meeting.  Post-Washington discussion: In view of resourcing this RTF, it was decided to defer this  issue to MOF2. The existing Facility material will be removed to avoid people implement-ing  it now and then objecting if we try to do something different in MOF2.  Pre San Jose - The AB has (informally) intervened to point out that an RTF is not allowed  to make major changes a CORBA spec. Dropping the Facility Package would be consid-ered  by the AB to be a major change.  The RTF has therefore reversed its decision to drop the Facility Package chapter. Instead  it has decided to add a BIG NOTE saying that it recommends that the material be replaced  at the earliest opportunity. Other references to the Facility Chapter have (already) been  eliminated.  It is sincerely hoped that MOF implementors will take the hint and not spend time trying to  implement the current Facility Chapter material.  Implementation: Moved Facility Package chapter to make it Chapter 7. Reinstated  Facility to the definition of the first MOF compliance point. Added  notes to say what the RTF recommends. [SC 24/9/99]  Implementation: Deleted a paragraph describing the Facility Package from  Section 3.3, �The Structure of the MOF Model,� on page 3-10. Re-moved  mention of the Facility Package from first paragraph in  Appendix �MOF IDL Summary�. Removed the Facility IDL section  from Appendix �MOF IDL Summary�. Removed mention of the Fa-cility  Package from first paragraph of Appendix �MODL Descrip-tion  of the MOF�. Removed the Facility MODL section from  Appendix �MODL Description of the MOF�. [KR]  Implementation: Removed the reference to the Facility Package in the is_singleton  attribute in Section 3.4.6, �Class,� on page 3-33. Done [SC] The problem of the Facility chapter not being "fit for purpose" remains.  The revised MOF RTF 1.3 report says we intend to address this issue urgently.     "A Strawman Proposal for  MOF 1.4 Repository Framework" by Steve C is 15 page document proposing a solution.  PLEASE READ IT!     

Summary: ModelElement needs to have a permanent, unique, unchanging,    non-redundant (within the transitive closure of a "large" namespace)   (meta)identifier in addition to or as a replacement for qualifiedName    as a local (meta)attribute.      

This means that a model element in a metamodel will be identified by an id that will not  change from one release to another if a concept does not change (even if the name of one  of the enclosing packages chages)and the id will change if the meaning changes (e.g a local  meta attribute is deleted or gets a new data type, a local meta-relationship is deleted), even  if the name does not change.  Discussion ([email protected]):  I agree that there is a need for something like this. For example, without it, it is hard to  implement a reliable, efficient caching mechanisms. [This is biting me at the moment ...]  However, I think that such a facility needs to apply to all MOF meta-models not just to the  MOF meta-meta-model. Assuming this is so, the correct place to put such functionality is in Reflective::RefObject or maybe Reflective::RefBaseObject.  We also need to precisely specify the domain(s) of the identifiers uniqueness, and/or decide  what should not be specified:  � Temporal: should identifiers last forever, or can the be recycled i.e. used on a new  object? If an object that has been deleted is "returned from the dead" (e.g. restored  from a backup) should it have its original identifier or a new one?  � Logical: should the domain in which object identifiers are required to be unique be  a) the "package instance", b) the "repository", c) the MOF server, d) a federation  of MOF servers, e) all MOF servers, or f) something else.  � Physical: should logical copies of the same meta-object have different identifiers?  I'm particularly concerned that any identifier scheme works (has acceptable semantics,  and has a reasonable implemention without "magic") in centralized, federated and discon-nected  meta-data repository scenarios.  I think this presupposes an analysis of the requirements; i.e. what do people want to be able  to use these identifiers for?  Discussion ([email protected]):  Agree that the identity solution needs to apply to all MOF compliant meta models and that  the Reflective interfaces are an appropriate mechanism to expose these interfaces  In general - I think reusing Ids (from dead objects) is a problematic one.  In general copies should have their own identity, with potentially optional associations to  'originator'  Logical - I need think this thru - Feel it should at least be a federation of MOF servers. I  dont know any easy way of enforcing 'all MOF servers'  Discussion ([email protected]):  I discussed this further with various people around the time of the Seattle meeting, and  came to the conclusion that different people have up to three (and maybe more) kinds of  unique identifiers in mind:  1. Identifiers that can be compared to test for object identity of (mutable) MOF meta-objects.  2. Identifiers that can be compared to test for value equivalence of (immutable) MOF  meta-objects.  3. Identifiers that can be compared to test if two distinct meta-objects denote "corre-sponding"  meta-objects in a model / meta-model, where details of the concept's rep-resentations  may differ. For example, they might be used to relate objects that  "correspond" after a round-trip model exchange, or objects in different models that  denote the same "concept".  Of these, we can currently only implement the first kind of identifier. The other two require  additional mechanisms that the MOF does not currently provide.  Proposed resolution:  1. Add a new operation to RefBaseObject to return a meta-object's identifier.  2. Define the external representation of identifiers as based on human readable  strings, using a prefix to distinguish formats. 3. Require identifiers to be unique in time across all domains with actual or possible  connectivity. Suggest DCE UUIDs as the preferred identifier mechanism.  4. Define binding between object and identifier as being one-to-one and immutable  through the lifetime of the object. In other words, no reuse of identifiers after object  deletion, and no changing of an object's identifier while the object exists ... in any  form.  5. State that a MOF implementation is non-compliant if its identifiers are locally  unique but are non-unique in the context of actual interoperation. Ditto for a MOF  implementation that does not implement binding rules in the context of actual inter-operation.  6. Rule other kinds of unique identifier out of scope for the MOF RTF.  Implementation: Added a description of the mof_id operation to Section 6.2.2, �Re-flective::  RefBaseObject,� on page 6-5 with the description of it be-ing  unique and immutable. Also added the mof_id operation to the  IDL in Section 6.2.2, �Reflective::RefBaseObject,� on page 6-5 and  Appendix B.2 �MOF IDL Summary�. [KR]  Implementation: Added text on semantics, including text on ensuring uniqueness and  on conformance to Section 6.2.2, �Reflective::RefBaseObject,� on  page 6-5. [SC]  Implementation: Removed the Section "Requirements to Support Object Identity"  from Appendix �MOF Implementation Requirements� as there now  is a system of MOF object identification. Done. [KR] This issue was closed following MOF RTF 1.3.  However, an AB member (Jeff Mishinsky?) suggested that the RTF ought to standardise a preferred format for MOF id strings, rather than just describing the properties that MOF ids must have.     

Summary: The description of the semantics of Reference operations   in section 6.2.2.1 needs to be extended to cover the multi-value   update operations; i.e. "set" and "unset" when the referenced   AssociationEnd is multi-valued.  In particular, the semantics when   either of the AssociationEnds is ordered need to be spelled out.    

 resolved, to be implemented

Summary: The concept of profile may need to be escalated to the MOF level (for   example as a subset of metadata constructs packaged together with   appropriate classifiers, tags, constraints etc. -).  I agree that   creating new metamodels for each minor extension is not a tractable   solution to the problem - especially if it means tool vendor cost of   supporting it is too much.    

One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of  additional Constraints on the Package, that might (for example) disallow the use of certain  model elements or combinations that are allowed in the base Package. If so, expressing this  using the MOF Model might require changes. For example, constraint [35] says that the  'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's  container.  Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined.  This is part of the broader discussion of heavy weight extension mechanisms part of MOF  2.0 and UML 2.0  Implementation: Nothing to do. Done [KR]. One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of additional Constraints on the Package, that might (for example) disallow the use of certain model elements or combinations that are allowed in the base Package. If so, expressing this using the MOF Model might require changes. For example, constraint [35] says that the 'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's container. Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined. This is part of the broader discussion of heavy weight extension mechanisms part of MOF 2.0 and UML 2.0 Implementation.     This is supposedly being addressed in either UML 1.4 or the UML 2.0 Infrastructure RFP.       

Summary: Summary: If we allow Tags to parameterize a meta-model (e.g. IDL) mapping    as proposed for issue 1307 (for example), there needs to be a reliable   way for a client of the mapped interfaces to find that Tags that were    in force.  Without this, it cannot reflectively work out what the mapped   interfaces do.      Additional text:       

Discussion: The least impact fix is to change the text to match the IDL / MODL.  Proposed resolution: Change the text to match the IDL / MODL.  Implementation: Revised the text and IDL in Section 3.4.2, �Namespace,� on  page 3-22 to say that an exception is raised. Done [KR]  Implementation: Also revised text and IDL for lookup_element_extended in  Section 3.4.3, �GeneralizableElement,� on page 3-26. Done[SC]

Summary: Take steps to validate as much as possible of the OCL in the    MOF specification. Ideally, they should all be compiled and "executed"    to ensure that they behave as expected. This should be feasible at least    for the OCL constraints in the Model package.       

This issue has been reopened to remind the RTF that the OCL in the MOF spec still needs to be checked by an OCL compiler / evaluator if one becomes available.       

Summary: It has been suggested that Model should be extended to allow   attributes to specified to have default values. Default values can be   defined in the MOF Model by adding an attribute of type "any" to   MofAttribute.  [Default expressions are too hard.]       

The following alternatives are available for default constructors in the specific interfaces:  1. If an Attribute has a default value, the corresponding specific create operation has  no initialiser parameter for that attribute.  2. When necessary, provide two constructor / factory operations in the specific inter-faces,  one with initialisers for attributes with defaults, one without.  3. No support for default initialisation in specific factory operation. The client must  use the Reflective operation to get default constructor behaviour.  In the Reflective interface, there are various options. For example:  1. Parameters are positional, with nil Any values as position holders and trailing pa-rameters  possibly omitted.  2. Parameters are Designator / Value pairs, supplied in any order. This requires an  operation signature change.  Discussion: ([email protected])  Of the alternatives available, I prefer alternative 2 for specific interfaces and alternative 1  for reflective interfaces. However, I would prefer to treat this as out of scope of the RTF,  since there is no pressing need for default values  MOF RTF Burlingame - Deferred to MOF 2.0. This is an extension to the MOF and a po-tentially  useful one. The following alternatives are available for default constructors in the specific interfaces:     If an Attribute has a default value, the corresponding specific create operation has no initialiser parameter for that attribute.   When necessary, provide two constructor / factory operations in the specific inter-faces, one with initialisers for attributes with defaults, one without.   No support for default initialisation in specific factory operation. The client must use the Reflective operation to get default constructor behaviour.   In the Reflective interface, there are various options. For example:   Parameters are positional, with nil Any values as position holders and trailing pa-rameters possibly omitted.   Parameters are Designator / Value pairs, supplied in any order. This requires an operation signature change   

Summary:  UML currently supports Exception hierarchies, as do many   object orient programming languages.  MOF"s lack of support for this   is perceived to be a limitation and an impediment to its use as a   middleware independent meta-data framework.       

We need to decide if this is within the scope of the MOF RTF.  We can modify the MOF Model so that Exception inherits from GeneralizableElement.  However, we should not to alter the Model - IDL mapping at this time. Instead, add a new  precondition for IDL generation that Exceptions do not inherit.  Exception hierarchies are not currently supported by CORBA IDL, and none of the cur-rently  implementable alternatives for mapping to "flat" exceptions are appealing. Steve Vi-nowski  has suggested a clever way to use OBV value types to simulate exception  hierarchies in IDL, but this depends on OBV implementations being available.  Status: Deferred to MOF 2.0  Implementation: Nothing to do. Done [KR] We can modify the MOF Model so that Exception inherits from GeneralizableElement. However, we should not to alter the Model - IDL mapping at this time. Instead, add a new precondition for IDL generation that Exceptions do not inherit. Exception hierarchies are not currently supported by CORBA IDL, and none of the currently implementable alternatives for mapping to "flat" exceptions are appealing. Steve Vinowski has suggested a clever way to use OBV value types to simulate exception hierarchies in IDL, but this depends on OBV implementations being available.     

Summary: Define a MOF Class that is the supertype of all Classes.   It could be represented as a single-valued subclass of Model::Class.          

This would allow us to specify some useful "generic" Packages. For example:  package Extension {  class ExtensionTag {  attribute string tag_name;  attibute any tag_value;  reference to the_element of TagAttachesTo tagged_element;  };  association TagAttachesTo {  ExtensionTag the_tag;  UniversalClass the_element; // need the universal supertype here  };  };  The above approach could be used to make the MOF Model tagging mechanism apply to  all meta-models.  Status: no decisions made. This would allow us to specify some useful "generic" Packages. For example:     package Extension {   class ExtensionTag {   attribute string tag_name;   attribute any tag_value;   reference to the_element of TagAttachesTo tagged_element;  };   association TagAttachesTo {   ExtensionTag the_tag;   UniversalClass the_element; // need it here  };  };  The above approach could be used to make the MOF Model tagging mechanism apply to all meta-models.

Summary: Assuming that we add the capability of defining defaults for   Attributes [see previous issue], there are a number of Attributes in    the MOF Model that could / should have default values; for example    "visibility" should default to "public", and "is_root"/"is_leaf" should    default to "dont_care".       

See also Issue 2174

Summary: We need a thorough specification of the semantics of Constraint    verification. This should cover the following:     1) What happens; e.g. is the verification allowed to give up on the         first error?      2) When evaluation of deferrable Contraints can occur; i.e. where could         the ConstraintError exceptions be raised?     3) How evaluation of deferred Constraints is triggered.        

The specification should cover:  1. What happens; e.g. is the verification allowed to give up on the first error?  2. When evaluation of deferrable Contraints can occur; i.e. where can the Constrain-tError  exceptions be raised?  3. How evaluation of deferred Constraints is triggered. One possibility is to tie this to  one or more Operations in a meta-model. If so, how do we meta-model this?  It is assumed that we want verification semantics that work for Constraints on all meta-models,  not just for Constraints on MOF Model.  Cross reference Issue 1082  Status: Beyond RTF scope - except for specific clarifications. Deferred to MOF 2.0; Desir-able  feature..  Implementation: A description of what is not currently specified is in Section , �Con-sistency  Checking Mechanisms,� on page 2-18. Also mentioned in  Section 4.6, �Extents,� on page 4-9. Done. [SC] The specification should cover:     What happens; e.g. is the verification allowed to give up on the first error?   When evaluation of deferrable Contraints can occur; i.e. where can the Constrain-tError exceptions be raised?   How evaluation of deferred Constraints is triggered. One possibility is to tie this to one or more Operations in a meta-model. If so, how do we meta-model this?   It is assumed that we want verification semantics that work for Constraints on all meta-models, not just for Constraints on MOF Model. See also Issue 1082

Summary: The MOF Model currently has a mechanism for freezing meta-models.    It is underspecified, but the intent is that under certain conditions you    can atomically freeze a valid meta-model. This issue proposes that this   mechanism be re-specified so that it is available for all models.      Additional text:      Arguably this is an extension rather than an RTF issue.              

Arguably this is a MOF extension rather than an RTF issue. Arguably this is an extension rather than an RTF issue.       

Summary: The MOF specification needs a technical overview before chapter    3 to help the reader put the details in the rest of the MOF specification    into a perspective.      Additional text:      I am in the process of drafting a possible overview chapter.       

Summary: A requirement possibly exists for a light-weight version of   References (or something like them), which at the M1 level does not   require the existence of Attribute instance objects and the associated   heavy weight querying mechanisms.       

Possible solutions:  1. No change. Is the requirement met by allowing Class values Attributes with aggre-gation==  none/composite semantics? How about Attributes that have an aggrega-tion  attribute?  2. Define the Association with visibility==private. This "works" for the IDL mapping,  because no IDL would get generated. However in Java for example, declaring the  corresponding Association class as "private" does not eliminate the need for it. So  unless a (hypothetical) mapping to Java did something odd-ball for Associations  with visibility==private, the heavy-weight query mechanisms may still be used; e.g.  in Constraint evaluation.  3. Add a "is_hidden" Attribute to Association that allows the modeller to specify that  querying interfaces are not required. [A server may choose to build references on  top of queries, but that is an implementation issue.] Possible solutions:     No change.   Redefine the Model constraints and the IDL mapping such that an Association with visibility==private or protected can be referenced, but that it will have no Association IDL.   Add a "is_hidden" Attribute to Association that allows the modeller to specify that querying interfaces are not required. [A server may choose to build references on top of queries, but that is an implementation issue.]   Define a Tag (e.g. "org.omg.mof.idl_lightweight" or "org.omg.mof.idl_suppress") that tells the IDL mapping to leave out the Association's IDL interface.   The first (non-)solution is not acceptable. This issue perceived to be a serious problem.   The second solution "works" in the context of the IDL mapping. However, consider a mapping to Java ... where a visibility is orthogonal to suppression of implementation machinery.  The danger is that by co-opting Model::Association::visibility to mean that an interface is to be suppressed in the IDL context, we risk causing future problems in other contexts.     The third solution involves an unnecessary change to the MOF Model.     The fourth solution doesn't seem to have any significant disadvantages.  It might also be worth generalizing this to allow suppressing of IDL elements for Classes, Attributes, Operations and so on.  For instance, by suppressing an Attribute, you might remove individual set/get operations, limiting access / update to a (hypothetical) "get_all_attributes" or via "ref_*" operations.     

Summary: It has been pointed out to me that the MOF IDL doesn"t   conform with the OMG style guidelines and conventions in two    respects.  First, there is no "#pragma prefix "org.omg"" in any of   the core IDL files.  Second, there is a convention that the   outermost module names for OMG specs have a standard prefix   depending on its "positioning" in the OMA; e.g. Cos, Cf or    whatever. 

Discussion  The #pragma prefix for the Mof Model should be set using the mechanism defined as a re-sult  of the previous issue. For Reflective, it should simply be edited into the IDL.  Dan Franz has confirm that the module name prefix for MOF should be Cf. He has also  stated that there is no requirement on the MOF RTF to rename the MOF modules, since  the MOF specification predates the style guide.  Changing the module names could be done by changing the top-level Package names; e.g.  Model - CfModel, Reflective - CfReflective. If we are going to do this, I propose that we  think about choosing some package names that are more appropriate. They need to be  clearly MOF associated, and also they need to more accurately indicate their purpose. For  example, Model - CfMetaModels and Reflective - CfMetaObjects.  Clearly, changing the core MOF Package names at this stage will have significant impact  on existing MOF code bases. This must be taken into account. On the other hand, fixing the  prefixes will probably cause minimal problems at this stage.  Status: no decisions , Deferred to MOF 2.0  Implementation: Nothing to do. Done [KR] The #pragma prefix for the Mof Model should be set using the mechanism defined as a re-sult of the previous issue. For Reflective, it should simply be edited into the IDL. Dan Franz has confirm that the module name prefix for MOF should be Cf. He has also stated that there is no requirement on the MOF RTF to rename the MOF modules, since the MOF specification predates the style guide.     Changing the module names could be done by changing the top-level Package names; e.g. Model - CfModel, Reflective - CfReflective. If we are going to do this, I propose that we think about choosing some package names that are more appropriate. They need to be clearly MOF associated, and also they need to more accurately indicate their purpose. For example, Model - CfMetaModels and Reflective - CfMetaObjects.     Clearly, changing the core MOF Package names at this stage will have significant impact on existing MOF code bases. This must be taken into account. On the other hand, fixing the prefixes will probably cause minimal problems at this stage.     

Summary: The Reflective interfaces currently use object references to   "designate" the feature (etc) to which a reflective operation applies.   In practice, I am finding that this is inconvenient for clients of the   API and potentially difficult for implementations.  I suggest that we   reconsider the alternative; i.e. designating features using CORBA   strings.       

Summary: I would like to suggest that the UML model interface defined by Chapter 5 of the   UML1.3R9 draft provide tools the ability to register for notification of changes to the    model contents in a manner consistent with the Observer pattern.      This would provide a better mechanism for tool integration around a common   model respository, allowing each tool in a tool suite containing tools developed   by different vendors to present its own up to date "view" of the underlying model in   a simple fashion.    

Summary: The IDL for the Reflective Package interfaces can conflict with IDL generated according to the MOF Model to IDL mapping rules.  For example, when generating IDL for the UML metamodel, the UML class called Instance causes generation of an operation called create_instance which conflicts with the Reflective create_instance.  The reflective interfaces should be changed to avoid such conflicts.    

Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e   "create_<classname>" operation should have parameters to provide initial   values for Attributes whose visibility is "protected_vis" or "private_vis".   The same applies for 5.8.3 for classifier-level Attributes in the Package   factory interface. 

Summary: 1) Should the describe() and modify() operation available be on instance and   class level interfaces? For class level attributes it is not necessarly   needed because they probably will not be read and modified very often in a   group.      2) The property set should be defined in a value-struct. Which attributes   should the instance level value-struct contain? class level and instance   level attributes. I would prefer only to have instance level attributes in   the instance level modify() and describe() operations because of (hopefully)   the separation of instance and class level interfaces (no inheritance   anymore!).      3) Should the value-struct also contain multi-valued attributes. I would   prefer, not to include multi-valued attributes in the value-struct because   of the modify() operation.      4) How about read-only attributes. If the same value-struct is used for   describe() and modify(), should the read-only attributes be included in the   value-struct and ignored in the modify() operation?      5) To define the value-struct as a NamedValue sequence with the values of   the type any (as available in the Reflective interface) is not optimal   because this operation is untyped and requires the use of the any type. The   value-struct should be typed.      6) In our work we have defined the value-struct, modify() and describe()   operations as model-specific operations (this is fully MOF-compliant). This   allows us to customize the value-struct as needed. However, because probably   everybody has the same requirements there should be a way in the MOF-spec to   defined such constructs in a standard way.    

The MOF interfaces need to provide an API to set uuids.  A convention for  denoting uuids for metamodel objects defined by OMG standards would be  beneficial.  For example, the uuids of the UML Class, Attribute, and Operation  constructs could be set following this convention by the UML RTF.  

This issue is to ensure that the MOF metamodel contains sufficient information  to hold information available through the RefObject and related interfaces.  Examples include the metaObject-instances relationship.    XMI documents using the MOF DTD should include sufficient information to be used  as backup/restore and initialization of a MOF-compatible system.  The MOF  interfaces should be complete enough to enable this capability.  

The AB is insisting that altered IDL types (including types that reference  > altered IDL types) be versioned by specifying a new repository id.  This  > presents special issues for generated IDL when a source model is revised  > and the IDL regenerated.  >   > Recommendation  >   > For generated IDL the safest thing is probably to generate a new UUID-based  > repository id for all generated IDL interfaces and generated IDL structs,  > valuetypes, etc.

The Attribute template suppresses the "remove" operations for multi-valued  Attributes whose lower and upper bounds are the same.  [This makes sense  because removing an element would always trigger an underflow error.] However,  similar logic has not been applied to the "add" operation. We should consider  suppressing "add" operations for multi-valued Attributes whose lower and upper  bounds are the same, since the operation must always trigger an overflow error  in this case.    

MOF specifies no interfaces for actually (de-)serializing a model (to, for example, a XMI stream). Without such an interface it is not possible to guarantee that 2 XMI tools/repositories can communicate with each other, regardless of how completely they support MOF/XMI. Since the OMG is meant to be about interoperability this is a critical omission.  It would make sense for MOF to make use of the Streamable interface defined as part of the Externalization service.  And for the capability to be defined against Namespace to allow reasonable flexibility of granularity.  Obviously XMI is only one possible format for the stream: the XMI specification should also be extended to fit into the detailed specification adopted for streaming MOF-compliant metamodels.

In the MOF 1.3 specification, section 5.8.4, the use of  "<clustered_package_name>_ref" (both in the template and as a subheading) is  incorrect.  It should be "<import_name>_ref".  The Import name provides the  alias for a clustered package within a clustering package.  The Package name  is used to identify the type of the M1 package object, not the IDL attribute  name.    Recommendation:  change "<clustered_package_name>_ref" to  "<import_name>_ref".  

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.  

In the MOF 1.3 Specification, a Package is not a subtype of Classifier.  But  an M2 package does have M1 instances (package extent objects), and the M2  Package defines the type of those M1 objects.  Therefore, a Package really  is a Classifier.  It is a type.  It can be thought of as a component type,  and in that sense a Package should be able to contain behavioral features.  Also, an attribute type that is a Package should be treated as a pointer to  a package extent object.    Recommendation:  make Package a subtype of Classifier, or fold Classifier  into GeneralizableElement.  

The RefAssociation ops that are parameterised by Link would be easier to  use if parameterized by two RefObjects.  The RefObject ops for   add/modify/removing  ele,emts of Attribute/Reference collections should be renamed; i.e. add_value  becomes add_member.  Other minor tweaks would make the interfaces easier to   use.    Discussion:    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.  The previous outcome was to defer this to the MOF 2.0 RFP.  

This topic was discussed by MOF RTF 1.3, but never raised as a formal issue. The previous outcome was to defer this to the MOF 2.0 RFP.   

There is no reflective version of the Package factory interface.  In  retrospect, an abstract interface would be useful for generic package  creation using Package specific factory objects, and a concrete interface  would be useful for a "universal" Package factory object.    Discussion:     This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.  The previous outcome was to defer this to the MOF 2.0 RFP.

This topic was discussed by MOF RTF 1.3, but never raised as a formal issue. The previous outcome was to defer this to the MOF 2.0 RFP.   

The MOF spec standardises an XMI-generated interchange format for MOF  meta-models.  The MOF spec includes the "input" MOF meta-model for the  Model.  It should also include a formal statement of the other XMI  "parameters" used to generate the meta-model interchange format.    

The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'.   

Review section 2.2 and subsections.     Develop appropriate introductory MOF material for separate publication; e.g. on the OMG website.     The description of the MOF meta-data architecture in section 2.2 and subsections could do with some rewording and rearrangement to the points mentioned in the issue clearer.     However, the root problem is that people do not read the MOF spec. What is needed is some (OMG endorsed) introductory or tutorial material on meta-modelling and the MOF. The MOF RTF is best placed to take on the task of developing this material in the first instance.     

 Need a predefined tag for marking attributes that will 'act as a  qualifier' in a classifier.  In a metamodelling tool it may be useful to derive automatically an object  identifier from one  or more relevant attributes of the classifier (for instance a 'name'  attribute).  Note: The attribute 'acting as a qualifier' is owned by the classifier not  by an association.  Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to  any attribute  of a classifier.

The role name of the Namespace->ModelElement association end should  be the same  than the corresponding reference name.  This role is named 'containedElement'  while the reference is named  'contents'.   Even if this is legal, we should avoid this in the MOF model because it's  error prone (in particular  when we use the UML class diagram notation as a convenience for specifying  MOF compliant  metamodels).  

This has been agreed in principle.  However, the RTF needs to determine the impact of this change and similar tidying up / regularisation of names in the MOF Model before proceeding to change the Model, and hence the IDL and generated DTDs and XMI documents.  DSTC expressed concern that the impact of this change could be significant.       

Title: The role name of the Namespace->ModelElement association end should  be the same  than the corresponding reference name.  This role is named 'containedElement'  while the reference is named  'contents'.   Even if this is legal, we should avoid this in the MOF model because it's  error prone (in particular  when we use the UML class diagram notation as a convenience for specifying  MOF compliant  metamodels).  

Various people have complained that retrieving meta-data (typically  features of Classes) using the IDL produced by the MOF IDL mapping  involves too many round-trips.  This is preventing people from using  MOF generated IDL in projects.  This issue calls for a solution (or  solutions) to this problem.  

This issue was raised at the Irving MOF-RTF meeting by (I believe)  Dave Frankel.  The proposal from that meeting was:    "Consider integrating XMI and MOF such that the interface allows  packaging up the features needed and the corresponding values as an XMI  document. This has the advantage customizing the set of features  returned.    Alternately extend the reflective interfaces to return get_all_features.   Or get_requested_features(featurelist, featurevaluelist)"    I would add a third alternative, which is to define an IDL mapping  Tag that tells the mapping to generate a 'meta-model specific'   get_all_features (or equivalent) operation for the interface(s) for  a tagged Class.    Also, I think we should consider adopting all three approaches.   This issue was raised at the Irving MOF-RTF meeting by (I believe) Dave Frankel. The proposal from that meeting was: "Consider integrating XMI and MOF such that the interface allows packaging up the features needed and the corresponding values as an XMI document. This has the advantage customizing the set of features returned. Alternately extend the reflective interfaces to return get_all_features. Or get_requested_features(featurelist, featurevaluelist)"     I would add a third alternative, which is to define an IDL mapping Tag that tells the mapping to generate a 'meta-model specific' get_all_features (or equivalent) operation for the interface(s) for a tagged Class.     Also, I think we should consider adopting all three approaches.     It looks like Issue 2876 is talking about this problem, as is Issue 3411.     

The modelElement end of AttachesTo association should be ordered. It does  make sense to have one tag attached to several model elements in a specified  order. (E.g. tag decorating a set of class attributes which create a unique  identifier of instances of this class)  

The current MOF package level import is not sufficient. For instance, if a  user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can  only indicate "Datatypes" in MOF now. What is needed is that the user can  say "Datatypes::Boolean" as a dependency. It would be counter-productive to  create 12 subpackages of Datatypes and put each datatype in its own Package,  just because it would let people reuse individual datatypes (without  changing the MOF import rule).   

It can be argued that there is no need to allow null as a valid value  for a Class instance.  The possibility of null means that mapped APIs  need to be more complicated; e.g. the IDL "unset_*" operations.  This   issue proposes that 'null' should be disallowed, making Class instances   consistent with DataType instances.  The IDL mapping could also be   simplified.  

[Steve Crawley]  We need to carefully consider the impact of this  proposed change.  I strongly recommend that we don't try to do this   in MOF 1.4    In normal programming languages where attributes are used to represent  relationships between objects, a null value is typically used to signify  the absence of a relationship.  In MOF, the absence of a relationship  can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or  Association.  However, there are other possible uses of null where there  is no straight-forward alternative.    We also need to consider the impact on the IDL mapping, specifically  in how Class instances are created.  Consider the following:      class C {      attribute C another_one;    };    If null is not a legal value for a 'C' instance, what do you pass as the  initial value for 'another_one' when creating the first ever instance of  'C'?  Maybe the answer is that 'another_one' >>must<< be declared as  [0..1] Attribute for the metamodel to be practical.  Or maybe each  mapping needs to find a solution; e.g. by deferring checking of some  structural constraint ... like the IDL mapping currently does for  Association underflow.    Note: It is currently explicitly illegal to use a null instance value in  Association links and References.  This would not change.   [Steve Crawley] We need to carefully consider the impact of this proposed change. I strongly recommend that we don't try to do this in MOF 1.4 In normal programming languages where attributes are used to represent relationships between objects, a null value is typically used to signify the absence of a relationship. In MOF, the absence of a relationship can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or Association. However, there are other possible uses of null where there is no straight-forward alternative. We also need to consider the impact on the IDL mapping, specifically in how Class instances are created. Consider the following: class C { attribute C another_one; }; If null is not a legal value for a 'C' instance, what do you pass as the initial value for 'another_one' when creating the first ever instance of 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] Attribute for the metamodel to be practical. Or maybe each mapping needs to find a solution; e.g. by deferring checking of some structural constraint ... like the IDL mapping currently does for Association underflow. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change.   

At the moment MOF has no way to describe the behavior of an operation. A new attribute, 'semantics', String (0..1) should be added to Operation. A more sophisticated alternative would be to include a 'language' attribute also, as for Constraint. This would be somewhat restrictive in permitting only one coding of the semantics (e.g. not both OCL and Java). Better would be to use just one multivalued attribute of type StructuredDataType 'Expression'. This would be as in UML and have StructureFields 'language' (String 0..1) and 'body' (String 1..1). It begs the question as to whether this datatype should then be used in Constraint instead of the current 'language' and 'expression' attributes.   

Delete all non-MOF-specific terms from the Glossary. People have trouble enough with MOF terms and it's sensible to have one place to collect them all, without clogging them up with a load of irrelevant UML terms (e.g. action sequence). Plus it create a management issue of having to keep up with UML (which it has failed to already - not even including something as fundamental as 'Profile').  

The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3].     The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.  

Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL).     There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine.     This applies not only to MOF but to other metamodels.   

The MOF model should allow generalization of associations. It is often  useful to have a more general root association and create several  specializations for it (e.g. dependency and several kinds of dependencies as  its subclasses).

When metadata is copied from one repository to another, or saved as an  XMI document, it can be necessary to know if the physically distinct  copies of the metadata are logically the same or logically different.  There need to be mechanisms for testing whether copies are logically the  same or different that work in all cases, not just within the context of  a single repository.

MOF should consider aligning its reflective interfaces with JMI  (specifically split some of RefObject into RefClass and common superclass  RefFeatured). As well as the benefit of consistency it makes the interfaces  more intuitive/comprehensible and typesafe.

MOF should deprecate the use of factory/finder operations on object  instances (i.e. the fact that generated instances inherit not only from  their model superclass but from their class proxy). The main reason for this  is that it does not separate concerns (why should an instance know about  creating other instances or finding the population of the class?) and is not  consistent with JMI.

The document needs a big revamp - e.g. a lot of the ancient pre-UML intro  stuff. We  should bear in mind that a lot of people will be coming to the spec/OMG  cold as a result of JMI takeup and we should make the document as clean,  lean  and approachable as we can.  It will be at least a year before MOF 2.0 reaches a stable/official state so  I feel we should not wait.

I think it would be much more convenient to have resolveQualifiedName as a  "classifier_level" operation on ModelElement instead of "instance_level"  operation on Namespace. Now each time I want to resolve some object using  its qualified name, I have to find all outermost packages (which is quite  slow, because currently there is no better way of doing it than just iterate  through all package instances and check whether they are outermost), then  choose a package with a specified name and call resolveQualifiedName on that  package passing rest of the qualified name as a parameter. This is much more  complicated for users than it should be.  

MOF should have a support for looking up metaobjects by MOFIDs (e.g. by adding getObjectByMOFID method to RefPackage interface).  

When I was looking at the current MOF 1.4 spec I could not find a place  where is specified, which assoc. ends are navigable and which are not.  There is an inconsistency between the UML picture of MOF metamodel and XMI  (and IDL). Where the picture indicates that some ends (like  RefersTo.referent) are not navigable, XMI says that they are navigable and  also IDL contains getter method for these ends. So I guess the picture is  wrong. This should be fixed, because it is in fact the only place where the  users of the spec can see the navigability without looking at the  hard-to-read XML file or generated IDL. It would be also helpful to add this  also to the description of particular associations in section 3.5.

In recent MOF RTF telcon discussions, we tentatively concluded that we need   Constraints on the MOF Model to forbid 1) clustering of nested Packages,  2) inheritance of nested Packages and 3) clustering of Classes.    Additional Text:    There are three arguments for the proposed restrictions.  The first  argument is that supporting inheritance / clustering in these cases adds  to the complexity of MOF implementations.  Since practical metamodels  never seem to use these combinations of features, it is hard justify  supporting them.    The second argument is that clustering and inheritance of nested  Packages is problematical.  The elements of a nested Package are  implicitly defined in the context of the nested Package's outer Package.  A Constraint or Operation defined on / within a nested Package may  reasonably refer to Associations or "all_of_*" collections in the  enclosing context.   When a nested Package is inherited or clustered  outside of the context of its parent Package, the Constraint and  Operation semantics may cease to be meaningful.    The second argument does not apply to a nested Package that is   inherited by another nested Package with the same outermost Package.  However, we have not been able to identify a use case for this sort  of thing.  Hence the first argument applies.    The third argument is that the MOF IDL mapping explicitly excludes all  of these cases; see "Section 5.5 - Preconditions for IDL Generation".  

in section 5.8.12 "Reference Template", 1st para, it is stated: "The IDL generated for a Reference is declared within the scope of <ClassName>CLASS interface definition.", while the next para says: "The Reference Template defines the IDL generation rules for References. It declares operations on the INSTANCE interface to query and update links in the Association object for the current extent."    I think, that all reference related IDL operations should go into the Instance interface, and not into the class proxy interface. This view is also compliant with 5.8.8 "Instance Template", that para states explicitly that the reference template is to be applied in the context of the instance template.    Proposed Resolution:  ====================  Change the 1st para of 5.8.12 to "The IDL generated for a Reference is declared within the scope of <ClassName> interface definition.  

If an association end is not navigable, specification of its  Multiplicity should not be required.  There is no practical use for this  information and it does not make sense to require information that is not  used.    Proposed Resolution:  Make Multiplicity optional in the MOF model.

Section 2.3.6.2 and Constraint [C-48] prevent a nested package from  importing from anything else. This seems unnecessarily restrictive and makes  the use practical of nested packages unlikely.

Here is a detailed proposal for adding association generalization to MOF  1.5.  This proposal does not address reference redefinition or overriding.  I hope this proposal provides sufficient detail so that Steve Crawley can  make changes to the specification.  Please send your comments.    Regards,  Don    Changes to Model    Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]  AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.    Add a nonabstract association from AssociationEnd to AssociationEnd called  RedefinesEnd.  One end is called redefinedEnd, has a reference by the same  name, and has multiplicity *.  The other end is called redefiningEnd, has no  reference, and has multiplicity *.  This association is used to correlate an  end with its corresponding end in a supertype association.    Add new constraint:  SupertypeEndsAreRedefined  Evaluation policy: Deferred.  Description:  An end redefines each supertype's end.  Context Association  Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->           forAll(ge : AssociationEnd |                      self.contents->select(sc |  sc.oclIsTypeOf(AssociationEnd))->                forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =  ge)                             and se.otherEnd.redefinedEnd->exists(ore | ore =  ge.otherEnd)))    Add new constraint: RedefinedEndBelongsToSupertype  Evaluation policy: Immediate.  Description: Each redefinedEnd belongs to a supertype.  Context AssociationEnd  Inv: self.container.oclAsType(Association).supertypes.contents->           includesAll(self.redefinedEnd)      By the way, I noticed a bug.  [C-38] AssociationsMustBeBinary is an  immediate constraint, but it should be deferred.  Otherwise, there is no  valid way to create an Association.    Changes to Abstract Mapping    Add the following to Core Association Semantics.    A link cannot be directly created for an Association with isAbstract set to  true, but can be added indirectly as a link of a subtype association.    Where a generalization exists between two associations, each link of the  subtype association is logically a link of the supertype association - for  each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or  <b, a> depending on which subtype end redefines which supertype end).    Removing a link from a Link_Set causes the logical link to be removed from  each subtype association's Link_Set.  Removing a link from a Link_Set also  causes the logical link to be removed from each supertype association's  Link_Set where the logical link is not otherwise present in the supertype  Link_Set based on either having been put explicitly into the supertype  Link_Set (where not abstract) or on being a link of some other subtype of  the supertype.  The net effect is that a Link_Set is a union of links put  explicitly into the Link_Set with the Link_Sets of all subtypes.    Changes to IDL Mapping    In the template for associations, no add or modify operations are generated  for an abstract association.    In the template for references, no set, add, or modify operations are  generated for an abstract association.    Operations on RefObject for setting, adding, and modifying, and operations  on RefAssociation for adding and modifying raise a new MofError, "Abstract  Association", for creating a link of an abstract association.    Changes to JMI    In the template for associations, no add operation is generated for an  abstract association.    In the template for references, no set operation is generated for an  abstract association.  Also, the add and set operations on a reference  collection throws a new JmiException, "AbstractAssociation", for an abstract  association.    For the reflective JMI interfaces, JmiException "AbstractAssociation" is  thrown for refAddLink on an abstract association and for refSetValue on a  reference on an abstract association.  

  If Attribute.isDerived was moved up to StructuralFeature, then you could model derived references. An example of such a derived reference in the MOF meta-model is Reference.exposedEnd, which is equivalent to ref.referencedEnd.otherEnd().     Relatedly, the copy of ptc/2001-10-05 found on the RTF website doesn't include the "exposedEnd" for any of the references in the MOF metamodel.