It is hard to understand relationship between this sub clause and Figure 12-1 through 12-4. Because there is no sentence as explaining Figure 12-1 through 12-4. Add sentences to explain relationship to Figure 12-1 through 12-4.

No Data Available

The first sentence implies that certain changes are specified in this clause, but there is no specification. However, unless the current document is intended as a delta document with respect to some earlier standard, which does not appear to be the case, then identifying such changes in the body of the standard is not appropriate. Indicate clearly the clauses in which the differences are described. If the differences are described, consider moving the information to an informative annex.

Proposed Resolution by NB:
Indicate clearly the clauses in which the differences are described. If the differences
are described, consider moving the information to an informative annex.
Discussion:
Delete subclause 8.4.
Disposition: Merged with issue 18661

"remove(object: Object): Object
Removes the specified object from the collection. Returns true if the object was removed."

Maybe the operation should return a Boolean.

Agreed. Correct the operation signature to return Boolean

References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 .

Agreed. The resolution for issue 15608 removed all remaining references to
Infrastructure and Superstructure (where applicable) and updated all affected
diagrams. However the figures listed above were deemed valuable and have
therefore been updated and not removed.
Disposition: Merged with 15608

This is a condensed issue covering the individual comments recorded in the consecutive issues 17631 to 17717, which shall be resolved as Duplicate/Merged with this issue, which was created to make the document revision process more manageable.

Resolve the ISO PAS comments sequentially throughout the document

Annex C is only described as an agreement for OMG. Delete Annex C.

No Data Available

It is hard to understand relationship between this sub clause and Figure 15-1. Because there is no sentence as explaining Figure 15-1. Add sentences to explain relationship to Figure 15-1.

No Data Available

Annexes should be referred as Annex A,B,C. Change A, B, C to Annex A, Annex B, Annex C.

No Data Available

Issue as “migration from MOF, v1.4” is not needed because it is informative. Move to an annex or delete this clause.

No Data Available

This diagram uses a color. Get rid of the color.

No Data Available

Annex B is not needed because it is not relevant to this standard. Delete Annex B.

No Data Available

Annex A is not adequate as normative. Because it refers external documents that are not standardized. Put enough description in Annex A or change to an informative annex.

No Data Available

Caption is missing for a diagram in this sub clause. Add a caption.

No Data Available

Title “Notes” is not suitable for clauses. Change to a note format defined in ISO/IEC Directive Part 2.

No Data Available

In this the last line, there is "Figure 11.1". However, the figure label is "Figure 11-1". Be consistent with each other.

No Data Available

It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

No Data Available

It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

No Data Available

Sentences of this part header are not needed. Delete this part.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 14-1. Add “Common” as a fourth package.

No Data Available

In this the first line, there is "Figure 14.2". However, there is no figure labeled "Figure 14.2". Refer an existing figure.

No Data Available

There are three figures in Page 49, 50 and 53 as same number as 14-1. Renumber a second figure as 14-2 and a third figure as 14-3.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

This designates "None". This prescription is insufficient. Describe adequately.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

MOF1.4 ?ISO/IEC19502

No Data Available

The sentence should define a grammatical prescription. However this definition is constraint and insufficient. Replace the text with precise one.

No Data Available

It is hard to understand relationship between this sub-clause and figures as Figure 13-1 and 13-2. Because there is no sentence as explaining Figure 13-1 and 13-2. Add sentences to explain relationship to Figure 13-1 and 13-2.

No Data Available

There are references to W3C documents in the Term [5]. These are normative reference. Besides, this definition style is different from UML 2.4.1 and OCL 2.4.1. Be consistent with UML 2.4.1 and OCL 2.4.1

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
MOF1.4 --> ISO/IEC19502

No Data Available

These diagrams as Figure 12-1, 12-2, 12-3 and 12-4 are filled with color. However, these colors are meaningless. Get rid of the color.

No Data Available

There are two figures in Page 32 and 33 as same number as 12-1. Renumber a second figure as 12-3 and following figures in order.

No Data Available

It is hard to understand relationship between this sub clause and Figure 12-1. Because there is no sentence as explaining Figure 12-1. Add sentences to explain relationship to Figure 12-1.

No Data Available

No need subtitle as “General.” Because title “The MOF Model” is enough to understand the meaning of this part. Delete subtitle “General.”

No Data Available

It is hard to understand relationship between this sub clause and Figure 11-1. Because there is no sentence as explaining Figure 11-11. Add sentences to explain relationship to Figure 11-1.

No Data Available

Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 12-1. Add “Common” as a fourth package.

No Data Available

This clause “introduction” explains an overview of EMOF model. However, there are many sub clauses “general” as explaining overviews. Change “introduction” to “general.”

No Data Available

It is hard to identify a clause for MOF Model’s requirements and use UML 2 Infrastructure. Change to “CMOF Abstract Semantics.”

Reflective Collection and Reflective Sequence are defined in Common package. However, they are described as a part of Identifiers Package. Change a sub clause as 10.5 Reflective Collection and 10.6 Reflective Sequence to a sub clause as 11.1 and 11.2.

No Data Available

There are two diagrams in one Figure 10-1. Split it into two figures 10-3 as classes and 10-4 as relationship between packages.

No Data Available

Sub clause MOF::Common describes for Common Package. However, other descriptions for packages are described in clauses. Change a sub clause as 10.4 to a clause as 11 and renumber following clauses.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

It is hard to understand relationship between this sub clause and Figure 10-1. Because there is no sentence as explaining Figure 10-1. Add sentences to explain relationship to Figure 10-1

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

Split it into two figures 10-1 as classes and 10-2 as relationship between packages.

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

No Data Available

“Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes

No Data Available

There are two diagrams in one Figure 9-1. Split it into two figures 9-1 as classes and 9-2 as relationship between packages.

No Data Available

It is hard to understand relationship between this sub clause and Figure 9-1. Because there is no sentence as explaining Figure 9-1.Add sentences to explain relationship to Figure 9-1.

No Data Available

Four packages are described in this part rather than three as Reflection, Identifiers and Extension.

No Data Available

There are two figures in Page 21 and 23 as same number as 10-1. Renumber a second figure as 10-3.

No Data Available

No need subtitle as “General.” Because title “Capabilities” is enough to understand the meaning of this part. Delete subtitle “General.”

No Data Available

MOF 1.4 and 2.4.1 are independent specifications. “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”.
Use ISO/IEC19502 for MOF 1.4

No Data Available

There are unexplained terms for language formalism as Properties, Operations, Constrains, Semantics, Rationale, and so on.

No Data Available

To change a title to “MOF 2 Design Requirements.” There must be some statements to be ISO standards.. MOF1.4 had become ISO.

No Data Available

There are descriptions of "UML2.0", "MOF2.0". And, "UML2", "MOF2", within this standard (for example Section 8 and etc.). These designations are ambiguous.

No Data Available

No Data Available

In this the last line, there is "Figure 7.1". However, the figure label is "Figure 7-1". Make it consistent

No Data Available

Delete the title “7.1 General”.
Then Re-numbering must be needed.

No Data Available

There is no reference of other specifications as UML. However, many symbols of UML are used. To add sentences for reference of symbols used in this specification

No Data Available

Terms and concepts that were used in this document should be defined here.

No Data Available

No need subtitle as “General Information.” Because title “Introduction” is enough to understand the meaning of this part.

No Data Available

There are two clauses as “Introduction.” It made a “Hanging Paragraph”. Merge into one clause

No Data Available

Section 6.4 Clause “Acknowledgements” is informative - move to an informative ANNEX

see pages 65 - 83 of ptc/2014-09-35

MOF1.4 (ISO/IEC 1502)

No Data Available

Move to an informative ANNEX or delete this clause. Is it allowed to show the mailing List as an ISO standard.. The contact must be a NB.

No Data Available

In the last line of this section, a description: "U2P, UU and 3C team" is meaningless.

No Data Available

To use “ISO/IEC 19505-2:2012 Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 2: Superstructure”.

No Data Available

The title "Reference" is insufficient. The title should be "Normative Reference".

No Data Available

To define conformance clearly or delete this clause.

No Data Available

It should provide a clear focus as an ISO standard. Especially, relationship to other ISO standards, such as ISO/IEC 19505 or 19502 &3

No Data Available

The style of Reference does not conform to the JTC1 style.

No Data Available

Information technology – Open Distributed Processing – Type Repository Function”.

No Data Available

To use “ISO/IEC DIS 195059 Information technology – Object Management Group – MOF 2 XMI Version 2.4.1”.

No Data Available

This specification refers to CORBA, QVT and OCL.

No Data Available

There is a JTC1 standard of UML 2.4.1.However, an OMG document is referenced

No Data Available

The first sentence appears to make a normative reference to a “UML Infrastructure document”, but there is no specific identification of such a document.

No Data Available

This unnumbered clause, lying between 6.4 and 7, contains only historical background and motivational material. As such it has no place in the normative body of an International Standard. It should be deleted.

No Data Available

It is not usual in ISO or IEC standards to acknowledge contributors to the document. It is not obvious that in all cases the terms used uniquely identify a specific organisation.

see pages 65 - 83 of ptc/2014-09-35

The first sentence refers to “Part 1”, which suggests that this is a multi-part standard, which is not the case. Assuming that the reference is intended to be to some subdivision of the text of the current document, there is no hint either here of in the Table of Contents as to what constitutes “Part 1”

No Data Available

The second sentence would be better placed in the Introduction, as it is essentially commentary rather than specification.

No Data Available

To change to “Information technology – Object Management Group Meta Object Facility (MOF) Core Version 2.4.1”.

No Data Available

Value judgements, such as “An advantage of ...” are not appropriate in the normative text of a standard. Rewrite the introduction paragraph to contain only straight facts relevant to construction of implementations or exploitation of implementations of this standard

No Data Available

This unnumbered clause, lying between 8.5 and 9, contains material that should be in a numbered clause, as it appears to be essential normative text. However, some of the text might be more appropriate to the Introduction or a description of MOF concepts.

No Data Available

This clause is essentially a definition of “Null” with some supporting information.

No Data Available

Who owns LinkSlots? When an association end is owned by a Classifier, are there two slots for its instances (one for the link and one for the element) or only one?
In the abstract semantics there is a concept called LinkSlot, which is shown as weakly aggregated (white diamond) by AssociationInstance. White diamond has not meaning in this context. Is it possible that a LinkSlot may be owned either by the link or by the adjacent instance, depending on “navigability”?
The following sentence appears to be key: “Where the feature is a navigable end, then the ClassInstance Slot is consistent with the Link slot.” The reference to "navigable" is surely incorrect. What does "consistent" mean?

LinkSlots are owned by the AssociationInstance. Update diagram 15-1 to show this
correctly.

Per UML2.4.1, a

In 12.4, constraint [8] currently reads:

An EMOF metamodel is restricted to use the following concrete metaclasses from UML’s Kernel:
• Class
• Comment
• DataType
• Enumeration
• EnumerationLiteral
• Generalization
• InstanceValue
• LiteralBoolean
• LiteralInteger
• LiteralNull
• LiteralReal
• LiteralString
• LiteralUnlimitedNatural
• Operation
• Package
• Parameter
• PrimitiveType
• Property

The list includes InstanceValue but incorrectly omits InstanceSpecification.

InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification;
see UML2.4.1, 7.3.23:

• instance: InstanceSpecification [1]
The instance that is the specified value.

Since the list includes Class and a Class can have Property features, an InstanceSpecification that is the value of an InstanceValue in EMOF may have to specify values for the instantiated Class' Property features. Therefore, the list should also include UML2.4.1's Slot as well.

The list should be corrected as follows:

• Class
• Comment
• DataType
• Enumeration
• EnumerationLiteral
• Generalization
• InstanceSpecification
• InstanceValue
• LiteralBoolean
• LiteralInteger
• LiteralNull
• LiteralReal
• LiteralString
• LiteralUnlimitedNatural
• Operation
• Package
• Parameter
• PrimitiveType
• Property

In 14.4, constraint [10] currently reads:

A CMOF metamodel is restricted to use the following concrete metaclasses from UML’s Kernel:
• Association
• Class
• Comment
• Constraint
• DataType
• ElementImport
• Enumeration
• EnumerationLiteral
• Generalization
• InstanceValue
• LiteralBoolean
• LiteralInteger
• LiteralNull
• LiteralReal
• LiteralString
• LiteralUnlimitedNatural
• OpaqueExpression
• Operation
• Package
• PackageImport
• PackageMerge
• Parameter
• PrimitiveType
• Property

The list includes InstanceValue but incorrectly omits InstanceSpecification.

InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification;
see UML2.4.1, 7.3.23:

• instance: InstanceSpecification [1]
The instance that is the specified value.

Since the list includes Class and DataType, both of which can have Property features, an InstanceSpecification that is the value of an InstanceValue in CMOF may have to specify values for the instantiated Class' or DataType's Property features. Therefore, the list should also include UML2.4.1's Slot as well.

The list should be corrected as follows:

• Association
• Class
• Comment
• Constraint
• DataType
• ElementImport
• Enumeration
• EnumerationLiteral
• Generalization
• InstanceSpecification
• InstanceValue
• LiteralBoolean
• LiteralInteger
• LiteralNull
• LiteralReal
• LiteralString
• LiteralUnlimitedNatural
• OpaqueExpression
• Operation
• Package
• PackageImport
• PackageMerge
• Parameter
• PrimitiveType
• Property
• Slot

Accept the proposal

Whilst the statement that the document contains no formal definitions taken from other documents may well be true, it is not particularly useful. It may also be true that no terms are used in this document with meanings that cannot be found in common dictionaries. If this is the case, then a statement to that effect would be more useful than the existing statement. Otherwise definitions of terms that are used with special meanings must be included here. There are a number of abbreviations, e.g. EMOF and CMOF in 8.1, that are used in the body of the document without explanation. They should be expanded or otherwise explained here.

Include an "Abbreviation" clause, and if appropriate a populated Definitions clause.

The final line of the clause identified UML 2.4.1 as a required specification, but does not give any indication of the source of the specification. The Introduction refers in non-normative text to ISO/IEC 19505 as a specification of UML 2.4.1

Starting with version 2.4, MOF shares the metamodel with UML (Superstructure).
Therefore from version 2.4 on, MOF depends only on the corresponding UML
Superstructure specification. Within the document, replace all mentioning of UML
Infrastructure by UML Superstructure and add normative references to UML
Superstructure as ISO and as OMG document to clause 3.
Disposition: Merged with 18661

The technical intent of the document is reasonably clear, and it appears to have been used for several effective implementations. The presentation of the material in the document is a long way from the ISO/IEC format, which is permitted for the first version of a standard introduced by the JTC1 PAS process, but there are a number of places where small changes would bring it closer to what users of ISO/IEC standards usually expect. There are also a number of places where the text is unclear or does not make obvious sense.

No Data Available

In MOF 2.4, Reflection::Element merges UML::Element. Then it is stated that Reflection::Element is an implicit superclass of all metaclasses defined using MOF. Hence UML::Element is a subclass of Reflection::Element which merges UML::Element. Reflection::Element has all of the properties of UML::Element (e.g. ownedComment) and so UML::Element may not validly have these properties.

The solution is for MOF not to merge any part of UML, because there is no need to do so. MOF should simply refer to UML for its definitions.

The fact that MOF merges UML is actually correct, and requires no changes. The
important “fine print” detail is that PackageMerge is not inheritance. With
PackageMerge, matching elements in the mergingPackage and the
receivingPackage are merged into a single element without changing the position of
that resulting element in the type hierarchy. This means in case of UML::Element
versus Reflection::Element that UML::Element is augmented with the reflective
capabilities defined in Reflection::Element without changing its position in the type
hierarchy of the UML metamodel. In particular, UML::Element is not a subclass of
Reflection::Element. If seen in the context of MOF, it remains unchanged the
superclass of all UML metaclasses, but augmented with the MOF capabilities.
Since version 2.4, MOF is based on a constrained-down UML metamodel. The only
way to add the additional capabilities of MOF without altering the type hierarchy is
PackageMerge, therefore MOF needs to merge UML.
To provide absolute clarity, the clause describing the Package composition of MOF
shall be improved.

In MOF 2.4, section 3, Normative References, there is a single paragraph which is repeated. Both paragraphs refer to the UML Superstructure 2.4, but they refer to it with different document numbers – the first is 2010-08-02 and the second is 2010-11-14. The second would be correct for 2.4, although needs to be revised again for 2.4.1.

This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661.
Disposition: Merged with 18661

Revise the conventions used in the MOF specification document to avoid unnecessary duplication of descriptions for inherited operations.
in particular, the add/addAll/remove operations in 10.7 ReflectiveSequence are unnecessary duplicate descriptions of the add/addAll/remove operations inherited from 10.6 ReflectiveCollection

Compared to the UML2 specifications, documenting inherited operations is unusual. More importantly, the MOF2.0 Core specification document lacks a clause documenting the specification and diagram formats used; however, this issue is beyond the scope of the MOF2.4 RTF.
Disposition: Deferred

In 13.6, elementsOfType has a parameter includeSubtypes, but linksOfType does not. There is no reason for this disparity – Associations can be generalized.

Clause 13.7 – operation linksOfType()
Replace the signature:
linksOfType(type : Association) : Link[0..*]
by:
linksOfType(type : Association, includesSubtypes : Boolean) : Link[0..*]
Perform the same change in the MOF model.
Replace the explanatory sentence following signature by the following text:
This returns those links in the extent that are instances of the supplied Association,
or of any of its specializations if includesSubtypes is true.
[ the diagram will be updated by resolution of 15608 ]

The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

Even if not derived it would be the inverse of the owning composition so should not be serialized.

This issue is outdated.
Disposition: Closed - No Change

In section 9.1 the description of the exceptions refer to ‘element’ instead of ‘object’ as the parameter.

And the whole section needs clarification of null e.g. does C.isInstance(null) = true for any class or datatype?

Agreed. Correct the operation signature to return Boolean.
C.isInstance(null) should return false at all time. Null is not a valid classifier and
violates the constrains of UML::Type on which MOF::Reflection::Type is based.

MOF 2 should merge UML 2 (merged) as opposed to Kernel and use the automated constraints from UML 2.4 production.

Since UML2 now has a normative merged metamodel it makes sense to reference this – especially since Kernel will be disappearing at UML 2.5.

The UML 2.4 team has produced a more complete set of executable constraints for valid MOF 2.4 metamodels which should be incorporated.

This is part of a larger effort to do the final steps of MOF – UML harmonization.
Change the MOF Model to merge UML (from 2.5) instead of UML::Kernel.
Revise the whole MOF Core specification document to change any remaining
references to Basic, Infrastructure, Kernel, etc. to the corresponding references
based on UML 2.5. This effort includes replacement of diagrams where necessary

Reflection package of the MOF defines operation

MOF::Element.equals(element:Object):Boolean

for testing equality of model elements. Description of this function (on page 16) tells, that "For instances of DataType, returns true if the object has the same value as this Element instance."

But instances of particular DataTypes (e.g. Integer, Bolean etc.) are just values (actually, I did not found, where exactly in MOF or UML Infrastructure specification, but somewhere I saw a definition of PrimitiveTypes like "instances of primitive types are identified only by their values"). So they are not Element-s (as I understand, they are Object-s, so each of primitive type, i.e. Integer, Boolean, String, UnlimitedNatural, can be considered as derived from Object, although they are not defined in such a way in MOF specification).

As so, instances of primitive type has no operation "equals" (which is quite OK, as they should have no operations - for this reasons they are PrimitiveTypes). So we cannot call "equals" operation as member of e.g. Integer Object. So, we cannot compare two integer objects.

Being more specific, let's cosider example (it is invalid call...):

some_property.get(lower).equals(MOF::Factory.CreateFromString(integer, "1"))

this test for equality (if lower bound of "some_property" equals to 1) is invalid, as "get" operation returns just number (value, instance of Integer), and it has not operation "equals".

Note: in example above "some_property" is instance of MOF::Property, which represents some property of some class, and "lower" is either instance of MOF::Property, which represents lower bound of "some_proerty". "integer" is an instance of MOF::PrimitiveType meta-metaclass, which represents MOF::Integer meta-primitive-type.

Actually, currently I have no Proposal for solution of this inconsistency, so this message is just report about it.

closed no change

The statement in clause 9.1 semantics

"Class Element is the superclass of all model elements in MOF, and is the
superclass of all instances of MOF model elements."

is confusing since instances do not normally have superclasses.

The statement could be interpreted to mean that every class always has
Element as a superclass including user-defined classes. But this would then
make it impossible to model lightweight application classes supporting
solely the required functionality.

Surely it is every M2 (and M3 and ...) class that has Element as a
superclass?

At M1 the superclasses are as modelled by the user.

This is significant for OCL since OCL inserts at least OclAny as the top
type at M1 in order to support some reflective behaviour. If Element really
is an M1 superclass, then OCL should align. If Element is not an M1
superclass, OCL should provide its reflection in OclAny.

closed no change

MOF semantics chapter says nothing about ordering of links when association ends are marked “ordered”. In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether.

Adopt the explanation of “ordered” from UML 2.5 - Association

I'm confused by something in MOF Figure 18. I see that this is a "semantic domain model," and i know i'm not clear on what that means. But i feel my question makes sense absent a clear understanding of what the MOF specification means by 'semantic domain model.' This diagram is apparently the extension of "the UML 2 Instances model" mentioned at 15.1. I'll assume 'Instances model' means the Infrastructure package, Instances. And, indeed, the drawing there is (mostly) reproduced in Figure 18. My question is about the extensions shown. I'll pick one such extension to make the question concrete. The drawing shows a class, Instance, a subclass of InstanceSpecification. The Infrastructure specification is clear: an instance and an instance specification specifying that instance are not in the same model. My question: Does the term 'instance' have a different meaning in MOF than in the Infrastructure, or are the objects of the class, Instance, not instances, or what?

No Data Available

The 'isID' attribute in class MOF::CMOF::Property remains unclear for constructed types like e.g. collections.

Proposed resolution: Detail specifcation of the 'isID' attribute with respect to other than primitive and class types. Suggestions: (1) identity is established for more complex types if identity 'isID' or "natural" identity (i.e. creation based identity) is given recursively for all referenced instances, or (2) if e.g. a collection has itself identity, then identity is established if the collections are the same

No Data Available

The submitters decided to put off to the FTF the chapter 10 rewrite, to correct text that refers to capabilities removed from the final submission.

Proposed resolution: This reporter will prepare a proposed rewrite

No Data Available

The diagrams mostly use «combine», but what that means is not specified. The defined package merge types are define and extend.

No Data Available

Section 9.2 factory starts: “Note – This section will need to be reconciled with the work underway in MOF lifecycle RFP.” Since the latter is now formal, this reconciliation should happen.

No Data Available

The page of the MOF 2.4 spec headed Part III – The MOF Model has the meaningless word Gagagaga at the end of it.

This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661.

This is a question involving ODM as well as MOF XMI and Life-cycle.

In ODM we have RDF and OWL defined as MOF meta models, the assumption being, of course, that you can have MOF instances of RDF graphs. But can you? In RDF & OWL an instance (at any M level) can have (and frequently does have) multiple types – it is classified by more than one class. While this is perfectly legal in UML and even in the MOF meta model, I don’t think the concept is supported in XMI or the current life-cycle. So, can you actually represent RDF in MOF? If not, the ODM models are not valid – I hope I am wrong about this.

The ability for an instance to be classified by more than one class is a major advantage of RDF and of ontology languages, the C++ heritage in MOF of an instance statically being a member of a single class puts MOF at a disadvantage in relation to these other technologies. It makes it very difficult to represent different aspects of an instance, as can be seen from the package merge complexities - which would not have been required is we had multiple classification in MOF.

If this is actually a semantic mis-match between MOF and ODM, is may make more sense to add the capability to MOF since the MOF meta model does not preclude this capability – it is only a restriction of the MOF-PSM (XMI).

No Data Available

The document, which is about a mapping of MOF to XMI, does not define the initialisms MOF or XMI anywhere in the documents, either in Chapter 1 (Scope) or in a glossary, which does not exist in this document.

Chapter 1 starts with "XMI is a widely used interchange format..." and ends with "MOF is the foundation technology for describing metamodels..." but there is no mention of what the terms actually stand for, a significant omission in a formal document.

One may also question the use of "MOF 2 XMI" in the title. While "MOF2XMI" may be a common way to create a meta-abbreviation for a relationship between two concepts denoted by abbreviations, there is little justification to eschew the grammatically correct "MOF-to-XMI Mapping" (with hyphens or spaces) in the document title. Using the numeral "2" is actually ambiguous – does it mean "to" or does it refer to a version 2 of MOF?

Overall, this issue is more about casual editing than about correctness, but I believe it makes the specification weaker, editorially, than the usual OMG standard of documentation.

Make the change as suggested

We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
Does XMI support that?

So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

Any suggestions? Don't you think we should fix that somehow

resolved as an urgent issue

13.3 describes an operation Object::delete() that does not appear in figure 13.2.
The operation isInstanceOfType() makes sense for an Element but not for an Object where it is misspelled.
The operation invoke() should be defined only on Object and should return set of Objects instead of a set of Elements.

Resolution:

in 13.3, delete the following operations:
delete()
isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean

replace:
invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*]
with:
invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]

in the metamodel, add:
MOF::CMOFReflection::Object::invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]

in 13.4, delete the operation:
invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*]

in 13.4, rename the operation:
instanceOfType(type: Class, includeSubtypes: Boolean): Boolean
to:
isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean

Update the diagrams & metamodel accordingly

It is unclear from the MOF2.0 Core specification where the Object::delete() operation is to be defined; it could be in MOF::Reflection::Object or in MOF::CMOFReflection::Object. It is also unclear whether each specialization of Object should have a delete operation – e.g., there is no delete() for MOF::Common::ReflectiveCollection. With so many important details under-specified, it is better to remove this operation than to leave it.
Since the resolution to issue 15825 for Object::getType() is deferred, it does not make sense to have Object::isInstanceOfType() either, this operation should be deleted and only defined for Element as described in the summary.
In 13.3, invoke() returns a collection of Elements but in 13.4, it returns a collection of Objects. Clearly an operation could return any kind of Object; the return type should be Object, not Element. Since MOF::Common::ReflectiveCollection provides the capability for representing a collection of Objects, it is not necessary for invoke() to return yet another collection of Objects, a single Object suffice; if the actual return is in fact a collection of Objects, then the return can be a single ReflectiveCollection object. Therefore, the multiplicity on the return parameter should be changed from 0..* to 0..1

In my opinion it has to be stated in Rule (11) and (12) that getter and setter operations are only generated for non-derived attributes.

No Data Available

The statement under Element::isSet

"If the Property has multiplicity upper bound of 1, isSet() returns true if
the value of the Property is different than the
default value of that property."

is inconsistent with the statement half a page later on semantics

"If the value of that property is later explicitly set, even to the default
value, isSet=true."

the implementation description strongly implies that it is the second
statement that is correct.

Regards

Ed Willink

duplicate of issue 15821

The document still contains large chunks of introductory material that date from the original MOF 2.0 submission and no longer apply. They should be deleted or updated as appropriate.

No Data Available

The following paragrph is not stated clearly and can cause an improper interpretation of the MOF object model: Class Element is the superclass of all model elements in MOF, and is the superclass of all instances of MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Element, MOF supports any number of meta layers as described in Chapter 7, “MOF Architecture.” A better way to say it may be: Class Element is the superclass of all classes defined in MOF, and is a superclass of the metaclass of all MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Element, MOF supports any number of meta layers as described in Chapter 7, “MOF Architecture.”

Further description would be useful than suggested in the issue

EMOF does not support identification of the opposite role name
for a non-navigable association, however QVT requires such role
names to be used. OCL defines an implicit role name, but UML
graphics supports arbitrary names.

At the EclipseCon OMG symposium in February, it seemed appropriate
to resolve the limitation in the following way.

An opposite role name may be denoted by a Comment Comment with the
inner Comment defining a formal function for the outer Comment.
Thus in:

<ownedAttribute name="forward" ...>
<ownedComment body="backward">
<ownedComment body="http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName"/>
</ownedComment>
</ownedAttribute>

"backward" is defined as the oppositeRoleName of "forward".

This practice makes the missing information available, and avoids
any changes to the MOF meta-model and so avoids introducing any
additional Property instances that might bloat existing usage.

It would be helpful if a future MOF version, or an addendum to existing
versions, endorse this practice.

An equivalent Ecore EAnnotation and cross-conversion was introduced
via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms
part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede).

The use of ‘non-navigable’ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on.

Further email exchanges on the RTF list discussed using an EMOF Tag instead of a Comment. So the proposed resolution is to introduce an EMOF Tag named “org.omg.emof.oppositeRoleName” that can be applied only to a Property whose “opposite” Property is empty. The “value” of this Tag specifies a role name that expressions (such as OCL expressions and QVT expressions) can use to traverse in the opposite direction of the Property.

All the URL's mentioned below appear really stange. My impression was that all such URI's should have a prefix http://schema.omg.org/. Clearly those are random URI's that will never ever exist on the OMG server and need fixing. See omg/02-03-02 to get guidance on what URLs already do or will soon (within the next two months) exist on the OMG server.

Juergen, you need to file this as an issue for the MOF RTF.

Jishnu.

LONJON Antoine wrote:
Hi Jim,

Since Barbara Price has left, uou seem to be the person to contact regarding the MOF specification.
The CMofXMI.xsd has references to imported files that are not available on the OMG web site.
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/cmofextension" schemaLocation="cmofextension.xsd"/>
<xsd:import namespace="http:///org/omg/uml2/infrastructure/elements" schemaLocation="elements.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/behavioralfeatures" schemaLocation="behavioralfeatures.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/expressions" schemaLocation="expressions.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/redefinitions" schemaLocation="redefinitions.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/constraints" schemaLocation="constraints.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/visibilities" schemaLocation="visibilities.xsd"/>
<xsd:import namespace="http:///org/omg/uml2/infrastructure/super" schemaLocation="super.xsd"/>
<xsd:import
namespace="http:///org/omg/uml2/infrastructure/namespaces" schemaLocation="namespaces.xsd"/>

Do you know where these files are available. I think they should also be posted on the OMG published XSD files in the appropriate directory that Linda is currently creating.

The published document formal/06-01-01 contained proper URLs in Annex A, which did indeed use schema.omg.org. However there was a typo in that ‘orb’ was used instead of ‘org’.
However the recommended structure of the URLs has now changed so MOF 2.1 should move to the new structure, since the files need to change significantly due to move to UML 2.1 as the basis of the metametamodel.

"We urgently need simple and clear rules we can follow to determine, for
each file associated to a given specification, the following:

the value of the cmof:Package or cmof:Profile uri property per clause 10.2
of the MOF2 Core specification.

the XMI namespace URI and the correspondence between an XMI namespace and
anything that is a kind of cmof package, including a profile.

the values of the CMOF tags: org.omg.xmi.nsPrefix and org.omg.xmi.nsURI

Based on the UML 2.3 files, it seemed that the OMG document number - e.g.,
ptc/2009-09-01 for UML 2.3 or ptc/2010-03-01 for SysML 1.2 would have been
sufficient to set unique URIs for each identifiable file document. If this
is incorrect, then we need clear direction for how to do this."

No Data Available

Annex A (which is normative), refers to the availability of the XMI for CMOF in the OMG document ptc/04-10-17. However, this document is not available at the OMG web site (at least not as a publicly available, searchable document). The annex being normative and the spec being publicly available, it would follow that a referenced ptc document would be publicly available. Without an available normative XMI for CMOF, it is not possible to produce a conforming implementation of it. I tried the MOF2.cmof file in the non-normative zip file (document 03-04-08). However, this file is not usable, as it has several errors and missing information.

The lack of this document was caused by structural problems in the UML 2.0 metamodel on which MOF 2.0 was based – which meant that UML 2.0 itself had no XMI file.
The normative XMI file will be produced for this revision of MOF and referenced from Annex A.

There are some shortcomings in the discussion of the isSet() and unset() operations of the Element class. In particular, there is no mention of optional properties in the Semantics section of the Element description.

Is is intended that optional properties be covered by the semantics inSingle-valued properties? If so, how, if at all, does the fact that a property is optional interact with the default for the property? For example, I assume that notwithstanding the spec language:

If a single-valued property has a default:
• It is set to that default value when the element is created. isSet=false

that an optional property will NOT, in fact, be set, and that isSet would be false.

Disposition: See issue 8269 for disposition

On an Object, container() is defined as
result = self.get(self.owningProperty())
where owningProperty() is defined as
result = self.allProperties->select(op| op.isComposite and self.get(op)
<> null)

If I read this correctly, the container of an object is the value of a
property on that object such that isComposite on the property is true
and the value of the property on the object is not null.