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

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