MOF merges the UML package into its Reflection package. The UML contains many packages, such as CommonStructure. The package merge defines that such packages are deep copied into the resulting package. All the packages of the UML are also imported into the UML package. Package merge just copies these import relationships. It doesn't merge the imported elements: UML 2.5: Imported elements are not merged (unless there is also a PackageMerge to the Package owning the imported element).

In effect, it means that MOF contains two unrelated element definitions: CommonStructure::Element and Reflection::Element. In fact all MOF elements are not merged with their UML counterparts.

In UML 2.4 all the packages were merged into the UML package. Therefore, all elements were directly contained in this package. Therefore, it was sufficient to merge it.

A possible solution: Create in MOF a package structure mirroring the UML packages.

The OCL is as follows. The restriction that ownedEnd->size() < 2 is not justified by the text of the constraint nor the specification, which refer only to memberEnds and size being limited to 2.
In fact associations which own both their ends are a frequently used and useful (e.g. to link 2 independnetly developed (meta)models.
The constraint should be ownedEnd->size() <= 2.

>>>>>>>>>>>>>>
– 14.3 [1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e., n-ary Associations are not supported);
– unlike EMOF, CMOF associations can have navigable association-owned ends.
– see also: https://sites.google.com/site/metamodelingantipatterns/catalog/mof/association-does-not-have-two-member-ends

context Association
inv CMOF_14_3_1: memberEnd->size() = 2 and ownedEnd->size() < 2

<<<<<<<<<<<<<<<

No import of the MOF::Common package is required by the MOF::Reflection package.
It's actually the opposite because the MOF::Common::ReflectiveCollection class inherits from the MOF::Reflective::Object (cf. Figure 10.2 on page 19).
The problem is also present in the MOF/20131001/MOF.xmi (ptc/14-08-10) document.

Another problem in the document: the 10.4 sub-chapter describing the MOF::Common package should not be a sub-chapter of the MOF::Identifiers main chapter (chapter 10), but in a specific main chapter for itself (chapter 11).

Annex B (informative) provides convenience links to the executable OCL files that implement the EMOF and CMOF constraints (with respect to the shared metamodel for MOF Core and UML). The provided links are crossed:
The constraints for EMOF are in: http://www.omg.org/spec/MOF/20131001/CMOFConstraints.ocl The constraints for CMOF are in: http://www,omg.org.spec/MOF/20131001/EMOFConstraints.ocl

Also, the second link has a comma instead of a period between www and omg.

The word 'metamodel' is misspelled as 'meatmodel' in the lower-most paragraph of page 1. The sentence which contains it is:

"The lightweight subset representing the MOF meatmodel is specified by specifying constraints against the UML metamodel."

The oppositeRoleName tag was introduced to support inverse navigation by OCL expressions since an OCL navigation needs to know the name to be navigated. An OCL navigation also needs to know whether the far end is a collection or not, and, if it is a collection, whether it is ordered and/or has unique values.The vast majority of opposite end characteristics can be reconstructed by assuming [0..1] !ordered, unique. However for the UML 2.5 model, this erroneously characterizes one ordered collection as not-ordered, about 10 lower bounds as 0 rather than 1, and about 100 upper bounds as 1 rather than 2 or *.

If EMOF is to be useable by OCL and related tools, additional
org.omg.emof.oppositeLower
org.omg.emof.oppositeUpper
org.omg.emof.oppositeOrdered
org.omg.emof.oppositeUnique

tags are need to avoid corruption of metamodel relationships.

(The discussion on Issue 12800 that introduced oppositeRoleName suggested that the above might be necessary. Experience has shown that they are necessary. For instance for QVTr, a QVTc middle metamodel is synthesized with unidirectional navigation to the user metamodels. These unidirectional relationships are navigated in reverse as part of the trace and must have correct multiplicities.)

The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier. The sentence currently reads:

The OCL constraints limiting this metamodel to the MOF 2 - relevant subsets are defined in Clause for EMOF and Clause for CMOF. A reference to files with the OCL source code is provided in Annex.

There should be a number after "Clause" both times it appears ("12" and "14", perhaps?) and a letter at the end following Annex ("B"?).

The model in Figure 11.1 ("The Extension package") does not specify a multiplicity for the tag property of MOF::Reflection::Element

That is in conflict with one sentence in Section 11.1
"The MOF Extension capability provides a simple mechanism to associate a collection of name-value pairs with model elements in order to address this need."

and in Section 11.2
"A model element can be associated with many Tags"

Just as a sidenote, the two sections have two other issues:
1) 11.2 is stating that "A model element cannot have more than one tag with the same name." but there is no OCL constraint to formalize that
2) The property owner:Element [0..1] mentioned in 11.2 is not mentioned on Figure 11.1

The MOF Facilities Object Lifecycle (MOF FOL) 2.0 spec defines "factory" methods in MOFFOL::Facility::createExtent(…)

This method can create either an Extent or a URIExtent.

MOF VD defines VersionedExtent as a specialization of URIExtent and Extent.
However MOF VD provides no operation for creating a VersionedExtent.
Are are such entities to be created?

The slides produced by Geoff Clemm for the submission presentation were very helpful and should be included in the specification itself along with a bit of detail as to how they relate to the metamodel

The diagram on p6 includes URIStore but with incomplete lines.

There is no subsection for it in 6.2.

Summary:
At MOF 1.4, packages can be related through:

• import
• nesting
• inheritance
• clustering
  We haven't really addressed this aspect of migration which should be added to Chapter 9.
  Personally I think there's little value in MOF 1.4 nesting and inheritance relationships and they're infrequently used in real metamodels (if people know what they're doing - occasionally people nest packages in UML Profile for MOF without realizing the implications).

In UML2 though we do still have a nesting relationship between packages so should consider the implications in terms of MOF constraints and extents.

Conversely we no longer have clustering (the most useful relationship in MOF 1.4) though we do have merging (with 2 flavors): we need to consider the runtime implications of instantiating a package that merges other packages. Is it the same as clustering?

Summary:
isID semantics - the 'may be used' is too weak. I think myself and Joaquin have made the point that we
need to specify the URI structure to get interoperability (and I don't mean the W3C standard - I mean how to construct
the URI from the objects/extents/properties/containers being identified).

The overview diagram in section 6.2 shows an operation:

Facility::getWorkspace(id : String[0..1]) : Workspace

However, section 6.2.1.3 describes an operation with a different signature:

Facility::getWorkspace(id : String[0..1]) : Workspace[0..*]

Which is it?

2. Section 7 should be applied to the other specifications not left in this specification

1. The figures should have numbers and captions

The figure in section 6.2 shows a URIStore class with two broken lines (associations? Generalizations? Something else?)
There is no entry for URIStore in the spec but there is a reference to it in 6.2.1.3:

Facility::createStore(name : String, contextURI : String[0..1], ….)

The description of the contextURI parameter says:

The URI to be used to address this Store. If specified, an instance of URIStore will be created.

So, is there a URIStore metaclass in MOF FOL or not?

MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram

MOF should publish a convenience document that pre-merges all the different packages

MOF has always lacked the capabilities to navigate an association
qualified by the values of properties of the end to which to navigate.
This has been a feature in UML since at least UML 1.3. When implementing
MOF, this leads to the unpleasant effect that in order to pick elements
from a collection returned from navigating a to-many association
requires iterating over all elements returned and filtering for the ones
meeting the desired criteria. The way MOF works, this makes it
impossible to provide an efficient implementation that yet is
standard-compliant.

Key qualifiers address exactly this issue. However, when the UML was
split into infrastructure and superstructure, this valuable UML feature
was placed into the superstructure, thus not being accessible by the MOF
specification. MOF itself doesn't provide its own approach to qualified
navigation either.

A concrete example of why the current situation is less than optimal is
the UML with its association between Namespace and NamedElement, using
role names "ownedMember" and "namespace." When navigating to a member of
a namespace with a particular name, one has to enumerate all elements
owned by that namespace and compare its name with the name looked for.
The effort scales with the number of elements contained by that
namespace, and there is no way for a repository to provide an efficient
implementation for that in a standard-compliant way.

A fix for this problem would be to move the association from
UML::Classes::AssociationClasses::Property to itself with properties
named "qualifier" and "associationEnd" to
InfrastructureLibrary::Core::Basic and connect it to
InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2
could use this useful feature, and a language binding for MOF2 could use
this to offer qualified navigation. Repository implementations may
provide a naive implementation at least, whereas advanced repositories
may use the opportunity to maintain internal index structures that
facilitate performant qualified access.

I don't know whether this changes anything in the way an issue is
handled by the OMG, but I've already talked to several vendors, current
MOF implementors and active OMG contributors (also see Cc list), and
there is wide consensus that this would be a very helpful change.

In ptc/04-10-15, Chapter 9 (EMOF Reflection) has some limited exceptions defined but Chapter 13 (CMOF Reflection) has none

The simplification and alignment between UML and MOF in the 2.4 series is incomplete.
In particular, the extensions that MOF adds to UML are missing in UML.
The MOF extensions that are missing in UML mean that statements like the one below in UML 2.5, section 6.2 are technically incorrect:

Since version 2.4.1 a MOF 2.x metamodel, including the UML 2.x metamodel, is a valid UML 2.x model. This was a substantial simplification and alignment compared to earlier versions. It is expected that future versions of MOF and UML will continue to be aligned in this manner.

For example, UML has no mechanism to specify the information about MOF::Extension::Tag. Without this information, it is currently not possible to fully rely on the above statement to use UML as a language for representing models of UML itself or parts of it such as the PrimitiveTypes library.

One fairly simple option would be to define a MOF profile with stereotypes corresponding to the contents of the MOF-specific extensions of UML

The uml diagram in chapter 10.4 MOF:Common specifie that ReflexiveCollection remove method return a Boolean. Just after, when describing this method (chapter 10.5) it is set to Object.

As per MOF specification only one property can be id. isID defines Id property for Class. Query is... 1) IF I have a Class say "Class1" which has property say "prop1" which is defined as Id. And there is "Class2" which inherits from "Class1" Then 1)Does "Class2" also inherit Id of "Class1"? 2)Can "Class2" has its owned id property? like overiding id property etc? Basically in specification there is no mention of relationship between inheritance of Classes and there id properties. 2) Also we see a single id property is too restrictive. In fact for the UML Meta model's Classes we could not define any single property as a identifying property. Is there any plan to make multiple properties as identifier in MOF?

Constraint [7] in section 14.3 of the MOF2 specification says that visibilities will be ignored, everything is assumed to be public, and name classes are possible and should be avoided. This constraint also appears in section 12.4 EMOF Constraints, constraint [4]. This is necessary for EMOF because it does not support package import or visibility. However, CMOF, which is based on InfrastructureLibrary Constructs does support both package import, namespace visibility, and visibility kind. It is not clear why CMOF would define visibility and then introduce a rule to ignore it. Perhaps this rule should be relaxed.

UML uses operation redefinition quite extensively, but MOF says nothing about what this means, and UML itself leaves it rather open – see for example issues 17924 and 15499. UML 2.5 beta leaves it even more open than 2.4.1, which means that MOF needs to be specific for UML to be well-defined.

My suggestion is that MOF requires parameters in redefined operations to have the same number, type, multiplicity, uniqueness and ordering as the parameters in the operation being redefined.

The portion of text ""An Extent is a context in which an Element in a set of Elements in a set can be identified"".
I think that this way is better: ""An Extent is a context in which an Element in a set of Elements can be identified""

That way, I can understanding. To more detail, in my language (portuguese), the Google shows a concise translation.

Regarding to spec:
§13.4 Object (from CMOF Reflection)
"CMOF Reflection adds the following extra operations.
invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]"

But this operation is present into http://www.omg.org/spec/MOF/20131001/MOF.xmi file for MOF::Reflection::Object :

<packagedElement xmi:type="uml:Class" name="Object" xmi:id="_MOF-Reflection-Object">
...
<ownedOperation xmi:type="uml:Operation" name="invoke" visibility="public" xmi:id="_MOF-Reflection-Object-invoke">
...
</ownedOperation>

Moreover it uses <type xmi:idref="_MOF-CMOFReflection-Argument"/> from CMOF.

Thanks

The text "An Extent is a context in which an Element in a set of Elements in a set can be identified." contains sentence fragment duplication.

The where clause is lack of a right brace for the Outer relation definition.

The example given for transformation, i.e., "transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {" is lack of a right brace.

In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF 2.4 seems to be silent on the semantics of association generalization.

According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: “Each instance of the specific classifier is also an indirect instance of the general classifier.”

However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics.

Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply.

But there is a problem. Let’s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval. That gives anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug.

In summary, the CMOF API that allows links to be explicitly manipulated and navigated should be defined so that a link of a sub-association is also a link of its super-associations.

Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties, i.e., set, ordered set, bag and sequence

Clause 2 specifies a requirement that compliant products shall support certain technology mappings, but there is no reference either here or in Clause 3, Normative references, to sources of specifications of those mappings.

There is an inconsistency in the current spec between link equality and link delete. Link equality only checks for the end values and the association, whereas link delete says: “This may leave the same elements associated by other links for this Association”, implying more than one distinguishable link per pair of elements. This should be resolved according to the fact that in OCL and UML collections resulting from navigating associations can be bags, i.e. contain the same element more than once. Links must be distinguishable individually, not simply by equality of their ends. This will imply that links have some identity criteria: uuids would seem to fit the bill perfectly.

There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects

Section 9.2 contains a set of constraints – these should be rationalized with the ‘main” constraints in 12.4 (CMOF) and 14.3 (CMOF). A lot of them are in fact redundant (e.g. UML constraints) or not needed

URIExtent should provide the capability of accessing links as well as elements by URI. This will enable SMOF multiply-classified links to be serialized with their uuids.

There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1

The file http://www.omg.org/spec/MOF/20131001/MOF.xmi starts with:

<xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
<packagedElement xmi:type="uml:Package" xmi:id="_MOF" name="MOF">
...

Is it correct to have <packagedElement> as root Model element ?

Why isn't it :

<xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
<uml:Package xmi:id="_MOF" name="MOF">
...

Thanks