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'.

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.

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').

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.

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).

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)

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).

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).

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.

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.

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.

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, 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".

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.

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.

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.

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.

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, 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.