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.

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

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:

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.

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.

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:

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.

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.

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

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

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.

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.

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

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.

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.

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

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

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.

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.

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.

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.

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

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

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

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.

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.

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.

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.

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.

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)

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

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.

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

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.

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.