Issues for MOF 2.0 Core revision Task Force

To comment on any of these issues, send email to mof2core-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7605: no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema (mof2core-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist?

Resolution: This is requesting that an XMI-compliant XML Schema be provided for MOF itself, as an example of a metamodel. This is an issue for MOF not XMI. Revised Text: - none - Disposition: Transferred to MOF RTF
Revised Text:
Actions taken:
July 27, 2004: received issue
May 27, 2011: trsnsferred to MOF 2 Core RTF

Issue 8267: MOF 2 Core: undefined behavior of convertToString (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Section 9.1 of ptc/04-10-15 defines operation convertToString that takes an Object parameter and converts to a string representation for a supplied DataType.
However no exception is defined for when the supplied Object is an instance of a ModelElement and not a DataType.

Resolution: see below
Revised Text: Replace the following sentence in section 9.2 for convertToString(): Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage(). By Exception: IllegalArgumentException if datatype is not a member of the package returned by getPackage() or the supplied object is not a valid instance of that datatype.
Actions taken:
February 11, 2005: received issue
April 25, 2011: closed issue

Issue 8268: MOF 2.0 Core: Exceptions missing for CMOF Reflective operations (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
February 11, 2005: received issue

Discussion:

Significant work is needed to develop a complete set of exceptions.

Disposition:	Deferred

Issue 8269: MOF 2.0 Core: Inconsistency about use of defaults (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

In ptc/04-10-05, section 9.1, the documentation for isSet() states that it "returns true if the value of the Property is different than the default value of that property. "
However later on in the section under Semantics, it states:
 
If a single-valued property has a default:

....

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

Thus there is an inconsistency as to the value if isSet() in the case where the property has been explicitly set to a value that happens to be the same as its default.

Resolution: It’s important to note that Property::default is used only for initial assignment on element creation, not as the value returned in absence of an explicit value.
Revised Text: For the description of isSet() in section 9.1 replace the following paragraph: 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. If Property has multiplicity upper bound >1, isSet() returns true if the number of objects in the list is > 0. With: isSet() returns true if the value of the Property has been explicitly set. See below for detailed semantics.
Actions taken:
February 11, 2005: received issue
April 25, 2011: closed issue

Issue 8695: Key Qualifiers Missing in MOF (mof2core-rtf)

Click here for this issue's archive.
Source: SAP AG (Dr. Axel Uhl, axel.uhl(at)sap.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
April 11, 2005: received issue
October 10, 2012: moved to the MOF 2 Core RTF

Discussion:

Disposition:	Deferred to UML 2.4 RTF

Issue 8751: Relations (mof2core-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations.

Resolution: It is not clear that all connections between elements in the UML2 model are a kind of Relationship or DirectedRelationship. A better way to achieve generic traversal is to use MOF reflection to navigate metaclass containment associations. Tools would be free to merge MOF2 Reflection into UML2 compliance levels to provide this capability. If this change were to be made it could have a significant impact on existing implementations and, therefore, is outside the scope of an RTF Disposition: Closed, no change
Revised Text:
Actions taken:
May 1, 2005: received issue
June 13, 2006: transferred to mof2core-rtf
January 20, 2011: closed no change
April 25, 2011: closed issue

Discussion:

It is not clear that all connections between elements in the UML2 model are a kind of
Relationship or DirectedRelationship. A better way to achieve generic traversal is to use
MOF reflection to navigate metaclass containment associations. Tools would be free to
merge MOF2 Reflection into UML2 compliance levels to provide this capability.
If this change were to be made it could have a significant impact on existing
implementations and, therefore, is outside the scope of an RTF

Issue 8997: CMOF should not itnore visibilities (mof2core-rtf)

Click here for this issue's archive.
Source: International Business Machines (Mr. Jim Amsden, jamsden(at)us.ibm.com)
Nature:
Severity:
Summary:

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.

Resolution: Significant work is needed to develop a complete support for visibilities. Disposition: Deferred
Revised Text:
Actions taken:
September 19, 2005: received issue

Issue 9147: Container and owningProperty (mof2core-rtf)

Click here for this issue's archive.
Source: Honeywell (Mr. David Oglesby, david.oglesby(at)honeywell.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.


How is that not backwards? The value of an object's composite properties
are the objects it *contains*. Don't we want (op|
op.opposite.isComposite and self.get(op) <> null)?

Resolution: see below
Revised Text: Section 15.8, additional Operations [4] Change definition of owningProperty as follows: post: result = self.allProperties->select(op| op.opposite <> null and op.opposite.isComposite and self.get(op)<> null)
Actions taken:
November 10, 2005: received issue
April 25, 2011: closed issue

Issue 9360: Issue for MOF 2 spec (ptc/04-10-15) (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Disposition: See issue 8269 for disposition
Revised Text:
Actions taken:
February 9, 2006: received issue
April 25, 2011: closed issue

Issue 9466: Multiple classifiers for an instance in MOF and RDF as defined in ODM (mof2core-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Cory B. Casanave, cory-c(at)modeldriven.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 22, 2006: 010306
January 20, 2011: closed no change
April 25, 2011: closed issue

Discussion:

This is outside the scope of the RTF and is being addressed by the SMOF RFP 

Disposition:	Closed, no change

Issue 9802: Remove Annex B (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

Annex B does not have any content - it just announces an intention - so is certainly not Normative as claimed. In fact even the announced intention is wrong: the current intention is for a group of all the main vendors (and others) to create a Java Interface for MOF 2 and submit it to OMG (not JCP) via the RFC process.
 
In fact the Annex really does not belong in the Core specification at all: there is no equivalent Annex for the IDL binding, for example.
 
Proposed resolution
Remove Annex B.

Resolution: Entirely remove Annex B and update contents page
Revised Text: Entirely remove Annex B and update contents page
Actions taken:
June 5, 2006: received issue
April 25, 2011: closed issue

Issue 10968: Wrong URLs (mof2core-rtf)

Click here for this issue's archive.
Source: Hewlett-Packard (Dr. Jishnu Mukerji, jishnu(at)hp.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: 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.
Revised Text: In Annex A, Replace: http://schema.omg.orb/spec/MOF/2.0/emof.xml With: http://www.omg.org/spec/MOF/2.4/emof/20080301 Replace: http://schema.omg.orb/spec/MOF/2.0/cmof.xml With: http://www.omg.org/spec/MOF/2.4/cmof/20080302
Actions taken:
April 23, 2007: received issue
April 25, 2011: closed issue

Issue 11157: FormalNumber: formal/02-04-03 section 3.6.2 (mof2core-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

In the specification [The “lower” bound of a MultiplicityType to be “Unbounded.” [C-54]] [The “upper” bound of a MultiplicityType cannot be less than 1. [C-56]] and it should be [The “upper” bound of a MultiplicityType to be “Unbounded.” [C-54]] [The “lower” bound of a MultiplicityType cannot be less than 1. [C-56]]

Resolution:
Revised Text:
Actions taken:
July 18, 2007: received issue
January 20, 2011: closed no change
April 25, 2011: closed issue

Discussion:

This was raised on MOF 1.4 (which is formal 02-04-03) and no longer applies

Disposition:	Closed, no change

Issue 12175: MOF 2.1 should be based on UML 2.1 Infrastructure (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

This will not result in significant changes to the spec itself (beyond replacing UML 2.0 with UML 2.1) but will have a significant change on the XMI due to the nature of the changes in UML

Resolution: MOF should be aligned with an appropriate version of UML and XMI – probably UML 2.4. This will change the XMI but have virtually no impact on the specification document.
Revised Text: Update section 3, Normative References, to refer to UML 2.4 Infrastructure. Change the normative XMI for MOF.
Actions taken:
January 14, 2008: received issue
April 25, 2011: closed issue

Issue 12800: Capturing Unnavigable Opposite Property Role Names (mof2core-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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.
Revised Text: Add a new Section, specifically Section 12.6 named “Predefined Tags” that reads as follows: This Section defines a predefined Tag whose name is “org.omg.emof.oppositeRoleName” which can be applied to instances of Property within instances of the EMOF model. Constraints context Tag inv: --The predefined Tag can only be applied to instances of Property whose “opposite” Property is empty name = “org.omg.emof.oppositeRoleName” implies element.oclIsKindOf(Property) and element.oclAsType(Property).opposite->isEmpty() Semantics If an instance of a Tag has “org.omg.emof.oppositeRoleName” as its “name”, then its “value” specifies a role name that expressions can use to traverse in the opposite direction of the Property, such as OCL expressions and QVT expressions. If an expression uses a role name specified using a Tag with “name” “org.omg.emof.oppositeRoleName”, and more than one Property has such a Tag with that role name, then it is up to the expression language to decide whether this is an error condition or represents a reverse navigation across all those Properties. An expression language should not choose to pick one such Property at random in case of ambiguity. Rationale Use of this Tag is lighter weight than using Property’s “opposite” Property. Use of the “opposite” Property in all cases where what is required is only the ability for expressions to traverse in the opposite direction would have the following negative consequences: • It would result in tighter coupling among Classes • It would add to the runtime burden that instances of the model place upon the underlying infrastructure that manages them, by: 1) increasing the overall footprint, since the opposite Property adds substantially to the contract of the Class that owns the additional Property designated as the opposite of the original Property; 2) requiring that storage be allocated for instances of the additional Property; and 3) requiring that referential integrity be maintained in storage among instances of the original Property and instances of the additional Property. It is beyond the scope of MOF Core to specify the concrete syntax that expressions use for traversal via the org.omg.emof.oppositeRoleName in languages such as OCL and QVT.
Actions taken:
August 31, 2008: receved issue
April 25, 2011: closed issue

Issue 13127: Section 9.1: paragraph needs clarification (mof2core-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Cory B. Casanave, cory-c(at)modeldriven.com)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution: Further description would be useful than suggested in the issue
Revised Text: Replace the quoted paragraph in section 9.1 Semantics with the following: Class Element is the superclass of all classes defined in MOF, and is an implicit superclass of all metaclasses defined using MOF: this superclass relationship to Element does not need to be explicitly modeled in MOF-compliant metamodels, and if implicit in this way Element is not included in the list of superclasses. By creating Properties with type Element it is possible to reference elements in any MOF-compliant model, similar to the use of xsd:any in XML Schemas. 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.”
Actions taken:
November 26, 2008: received issue
April 25, 2011: closed issue

Issue 13444: Annex A refers to non-existing CMOF file (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Gene Mutschler, gene.mutschler(at)adaptive.com)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: 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.
Revised Text: none
Actions taken:
February 4, 2009: received issue
April 25, 2011: closed issue

Issue 14553: MOF semantics chapter says nothing about ordering of links when association ends are marked “ordered”. (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The decision needs more evaluation time, need to be addressed by a future RTF. Disposition: Deferred
Revised Text:
Actions taken:
October 9, 2009: received issue

Issue 15118: We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Revision
Severity: Critical
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 5, 2010: received issue
January 20, 2011: closed no change
April 25, 2011: closed issue

Discussion:

Any rules for these values are a matter of (OMG) policy not for the specifications. The MOF 2 Facility specification provides a basic scheme for use of Package::uri in constructing URLs.

Disposition:	Closed, no change

Issue 15143: Outdated descriptions (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text: General: Replace all usages of MOF 2.0 and UML 2.0 with MOF 2 and UML 2 Section 1: replace the following: This MOF 2.0 Core specification is in response to the Object Management Group Request For Proposals ad/01-11-14 (MOF 2.0 Core RFP). This MOF 2.0 specification is based on the following OMG Specifications: • MOF 1.4 Specification -- MOF 2.0 is a major revision of the MOF 1.4 Specification. MOF 2.0 addresses issues deferred to MOF 2.0 by the MOF 1.4 RTF. For information on migration from MOF 1.4 to MOF 2.0 please refer to the “Migration from MOF 1.4” chapter. • UML 2.0 Infrastructure Convenience Document: ptc/04-10-14 -- MOF 2.0 reuses a subset of the UML 2.0 Infrastruc- ture Library packages. • MOF 2.0 XMI Convenience document: ptc/04-06-11 -- Defines the XML mapping requirements for MOF 2.0 and UML 2.0. With the following: This MOF 2 Core specification provides the basis for metamodel definition in OMG’s family of MDA languages and is based on a simplification of UML2’s class modeling capabilities. In addition to providing the means for metamodel definition it adds core capabilities for model management in general, including Identifiers, a simple generic Tag capability and Reflective operations which are generically defined and can be applied regardless of metamodel. MOF 2 Core is built on by other OMG MOF specifications, including the following (in this list ‘MOF based model’ means any model that instantiates a metamodel defined using MOF, which includes metamodels themselves): • MOF 2 XMI – for interchanging MOF-based models in XML • MOF 2 IDL – defines a platform-specific API for MOF Core operations for OMG’s CORBA platform • MOF 2 Facility and Object Lifecycle – for connecting to and managing collections of MOF-based model elements • MOF 2 Versioning and Development Lifeycle – for managing versions and configurations of MOF-based models • MOF Queries Views and Transformations – for transforming MOF-based models • MOF Models to Text – for generating text, such as programs, from MOF-based models • Object Constraint Language – for specifying constraints on MOF-based models Section 2: Replace the following: Compliant products shall support one or more of the following technology mappings: MOF 2.0 XMI ( ptc/04-06-11), MOF 2.0 IDL, and MOF 2.0 Java binding. Additional conformance rules based on MOF 2.0 IDL and MOF 2.0 Java binding will be specified in separate specifications. With: Compliant products shall support one or more of the following technology mappings: MOF 2 XMI, MOF 2.0 IDL. Additional conformance rules based on are specified in these specifications. Section 3: Replace the following: Readers of this MOF 2.0 specification are expected to be familiar with the UML Infrastructure V 2.0 specification. The MOF 2.0 model packages Essential MOF (EMOF) and Complete MOF (CMOF) are constructed by merging the UML2 Infrastructure Library packages. The main body of the document describes the technical specification itself. This specification references the following documents: • UML 2.0 Infrastructure Convenience Document: ptc/04-10-14 • MOF 2.0 XMI Convenience document: ptc/04-06-11 With: Readers of this MOF 2 specification are expected to be familiar with the UML Infrastructure specification. The MOF 2 model packages Essential MOF (EMOF) and Complete MOF (CMOF) are constructed by merging the UML2 Infrastructure Library packages. The main body of the document describes the technical specification itself. This specification references the following documents: • UML 2.4 Infrastructure (provide up to date reference) • MOF 2.4 XMI (provide up to date reference) Part I – Introduction: In para 3 replace the following: The Meta Object Facility (MOF), an adopted OMG standard, (latest revision MOF 1.4) With: The Meta Object Facility (MOF) In para 5 replace the following: This collaboration continues to this day as the vendors working on UML 2.0 Infrastructure and MOF 2.0 are attempting even greater reuse (as required by the OMG RFPs) With: This collaboration continues to this day as the vendors working on UML 2 and MOF 2 are attempting even greater reuse Delete the following para: Since then, MOF Revision Task Forces have produced several minor revisions, the most recent being the MOF 1.4 specification, which was adopted in October 2001. In para 7 replace the following: The use of MOF and XMI over the last few years has raised numerous application and implementation issues by vendors. As of the time of this writing over 150 formal usage and implementation issues have been submitted to the OMG for consideration. While a vast majority of these issues have been addressed by MOF 1.4, some are considered too major to be addressed by a Revision Task Force (RTF), and therefore, a series of MOF 2.0 RFPs (seven so far: MOF 2.0 Core, MOF 2.0 IDL Mapping, MOF 2.0 XMI Mapping, MOF 2.0 Versioning and MOF 2.0 Query/View/Transformations, MOF 2.0 Facility RFP, MOF 2.0 Facility RFP) have been issued. With: MOF 2 is represented by a set of specifications: MOF 2 Core, MOF 2 IDL Mapping, MOF 2 XMI Mapping, MOF 2 Facility and Object Lifecycle, MOF 2 Versioning and Development Lifecycle, MOF 2 Query/View/Transformations, MOF Model to Text. In para 8 replace the following: The reader must keep in mind that the individual RFPs and the proposals can be used incrementally and independently, and this modularity is a design goal of MOF 2.0. For example, vendors can implement the MOF 2.0 Model as a framework for metamodeling and metadata representation and management without using MOF 2.0 IDL or MOF 2.0 Java mapping. This was considered very important to provide more choice for MOF implementers. With: The reader must keep in mind that the individual specifications can be used incrementally and independently, and this modularity was a design goal of MOF 2. For example, vendors can implement the MOF 2 Core as a framework for metamodeling and metadata representation and management without using MOF 2 IDL or MOF 2 Facility. This was considered very important to provide more choice for MOF implementers. In para 9 replace the following: This MOF 2.0 specification integrates and reuses the complementary UML 2.0 Infrastructure submission to provide a more consistent modeling and metadata framework for OMG’s Model Driven Architecture. UML 2.0 provides the modeling framework and notation, MOF 2.0 provides the metadata management framework and metadata services. The manner in which the specification addresses individual RFP requirements is explained in the Scope of this specification. Considerable progress has been made in eliminating overlapping modeling constructs in UML 1 and MOF 1 specifications (for example, the confusion between MOF References and UML AssociationEnds has been eliminated). More importantly the modeling constructs from the UML2 Infrastructure Library are reused (using import) by both the MOF 2, UML2 Infrastructure, and UML2 Superstructure specifications. With: This MOF 2 specification integrates and reuses the complementary UML 2 Infrastructure submission to provide a more consistent modeling and metadata framework for OMG’s Model Driven Architecture. UML 2 provides the modeling framework and notation, MOF 2 provides the metadata management framework and metadata services. Considerable progress has been made in eliminating overlapping modeling constructs in UML 1 and MOF 1 specifications (for example, the confusion between MOF References and UML AssociationEnds has been eliminated). Delete the following paragraph: One of the challenges the MOF 2.0 Core and MOF 2.0 XMI Mapping submissions face is to maintain a stable interchange model (XMI) while MOF 2 and UML 2 are changing quite significantly. To accomplish this, we have begun applying the design principles that have been used in the XMI for XML Schemas and now the MOF 2.0 XMI mapping submission. This is to use a very small subset of the modeling concepts in MOF. We call this Essential MOF or EMOF which basically models simple classes with attributes and operations to fix the basic mapping from MOF to XML and Java. Additional mapping rules are provided in a manner consistent with XMI 2.0 for more complex modeling constructs. Please refer to the MOF 2.0 XMI Convenience document: ptc/04-06-11 for more details. Section 7.1: Delete the following paragraph: While much progress has been made in unification of the modeling concepts in MOF 2 and UML 2, the goal of reuse of meta model packages across object and non-object systems continues to be challenging. To address this the initial MOF 2.0 Core submission included a chapter titled “Common Concepts.” In the revised submission (in part to meet current submission deadlines and because this task proved to be more difficult than anticipated) we have scaled back these goals to focus on reuse between just UML and MOF. The MOF2 submission team recommends additional OMG RFPs be issued to address this broader reuse of metamodel packages between object and non-object systems. Section 7.2: Replace the following: The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively. With: The MOF 2 Reflection interfaces allow traversal across any number of metalayers recursively. Section 7.3: Replace the following: The UML 2.0 Infrastructure Library uses fine grained packages to bootstrap the rest of UML 2.0. A design goal (and RFP Requirement) is to reuse this infrastructure in the definition of the MOF 2.0 Model. In MOF 2.0 this reuse is simply accomplished by using a standard CMOF extensibility mechanism -- importing, combining, and merging existing MOF 2.0 compliant packages. Importing packages makes model elements contained in the imported package visible in the importing package. Merging packages extends model elements in the merging package with new feature deltas from the merged package. The details are covered in the UML 2.0 Infrastructure Convenience document in the section on PackageMerge. Note that we have designed both the UML 2.0 model and the MOF 2.0 model to be compliant to MOF 2.0 and be instantiable from MOF 2.0. With: The UML 2 Infrastructure Library uses fine grained packages to bootstrap the rest of UML 2. A design goal is to reuse this infrastructure in the definition of the MOF 2 Model. In MOF 2 this reuse is simply accomplished by using a standard CMOF extensibility mechanism - merging existing MOF 2.0 compliant packages. Merging packages extends model elements in the merging package with new feature deltas from the merged package. The details are covered in the UML 2 Infrastructure Convenience document in the section on PackageMerge. Note that both the UML 2 model and the MOF 2 model are designed to be compliant to MOF 2 and be instantiable from MOF 2. Section 8.1: Replace the following: Please refer to the chapter “Language Formalism” in the UML 2.0 Infrastructure Convenience document. With: Please refer to the chapter “Language Formalism” in the UML 2 Infrastructure specification. Section 9: Delete the following: Note – The Factory class has some overlap with the MOF Life cycle RFP and will need to be reconciled when submissions for that RFP are adopted.
Actions taken:
March 24, 2010: received issue
April 25, 2011: closed issue

Issue 15271: MOF 2.0 9.1 Contradictory isSet default value semantics (mof2core-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: duplicate of issue 15821
Revised Text:
Actions taken:
June 2, 2010: received issue
January 12, 2012: closed issue

Issue 15272: MOF 2.0 9.1 Confusing instance superclass statement (mof2core-rtf)

Click here for this issue's archive.
Source: Nomos Software (Dr. Edward Willink, ed(at)willink.me.uk)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 2, 2010: received issue

Issue 15397: Remove isId and uri (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity:
Summary:

With the conclusion of Ballot 10 of the UML 2.4 RTF, Package:uri and Property:isId have been added to UML so there is no need to add them in MOF.

Proposed resolution:

            Update Figure 10.1 to remove Package and Property.

            Remove sections 10.2 Package and 10.3 Property and ‘shuffle up’ the remaining sections in Chapter 10.

            Add the following constraint, formerly in section 10.3, to sections 12.4 and 14.3:

Property.isID can only be true for one Property of a Class.

Resolution:
Revised Text: As per the proposed resolution
Actions taken:
August 7, 2010: received issue
April 25, 2011: closed issue

Issue 15398: Use UML models ‘as is’ for metamodels (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity:
Summary:

Requiring a format conversion to make a UML model into a MOF metamodel has proved a significant impediment and time-waster: especially since no UML tools directly support Infrastructure as originally envisioned.

There is no reason why MOF could not use suitably constrained UML models directly, especially as UML 2.4 has now added Property::isId and Package::uri – the only structural differences in MOF.

 

Proposed resolution (outline):

General:

            Change section 3 introduction and reference to refer to UML 2.4 Superstructure instead of Infrastructure 

            Update Annex A to use UML 2.4 URIs

For CMOF:

Update section 14 to explain the above

Update Figure 14.1 to show CMOF merging UML Kernel instead of Constructs

Update Figure 14.2 to show the same elements but as defined in UML Kernel 

Update section 14.3 CMOF Constraints with the following constraints, and include OCL for these and the original constraints:

-          A CMOF metamodel may not include instances of the following UML metaclasses:

o   InstanceValue

o   InstanceSpecification

o   Slot

o   Interface

o   AssociationClass

o   GeneralizationSet

-          The following properties must be empty

o   Class::nestedClassifier

o   Property::qualifier

-          The value of Property::defaultValue and Parameter::defaultValue must be of kind LiteralSpecification

-          The value of MultiplicityElement::lowerValue and upperValue must be of kind LiteralInteger and LiteralUnlimitedNatural respectively

-          Dependencies (and subclasses) will be ignored

            

For EMOF:

Update section 12 to explain the above

Update Figure 12.1 to show CMOF merging UML Kernel instead of Basic

Update Figure 12.2 to show the same elements but as defined in UML Kernel 

Update section 12.4 EMOF Constraints with the following additional constraints (to those listed for CMOF above), and include OCL for these and the original constraints:

-          An EMOF metamodel may not include instances of the following UML metaclasses:

o   Association

o   Constraint

o   DataType (only instances of PrimitiveType and Enumeration)

o   Expression

o   OpaqueExpression

o   ElementImport

o   PackageImport

o   PackageMerge

-          The following properties must be empty

o   Parameter::defaultValue

o   Parameter::direction

o   Property::subsettedProperty

o   Property::redefinedProperty

Resolution: As per the proposed resolution. In addition, for CMOF, Feature::isStatic must be ‘false’
Revised Text: see pages 35 - 42 of OMG document ptc/2010-12-07 (word format)
Actions taken:
August 7, 2010: received issue
April 25, 2011: closed issue

Issue 15442: Primitive type values cannot be tested for equality using Reflection (mof2core-rtf)

Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 3, 2010: received issue

Discussion:

Issue 15608: MOF 2 should merge UML 2 (merged) as opposed to Kernel (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 21, 2010: received issue

Issue 15646: Bad description of set() (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution:
Revised Text:
Actions taken:
September 27, 2010: received issue

Discussion:

Issue 15661: linksOfType needs includeSubtypes parameter (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 28, 2010: received issue

Issue 15820: Update and formalize the constraints that MOF applies to UML models (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity: Significant
Summary:

At the moment the constraints do not reflect the more rigorous process that was deployed when creating the MOF metamodel for UML 2.4.

Resolution:
Revised Text: Replace 12.4 [3], currently: [3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool). with the following: [3] Names are required for all NamedElements except for ValueSpecifications. Replace 12.4 [4], currently: [4] Core::Basic and EMOF does not support visibilities. All property visibilities expressed in the UML MOF model will be ignored (and everything assumed to be public). Name clashes through names thus exposed should be avoided. with the following: [4] Core::Basic and EMOF do not support visibilities. All property visibilities must be explicitly set to public where applicable, that is for all NamedElements, ElementImports and PackageImports. Furthermore, no alias is allowed for any ElementImport. Replace 12.4 [8] from resolution to 15398 in ballot 2, i.e: [8] An EMOF metamodel may not include instances of the following UML metaclasses: • AssociationClass • Constraint • DataType (only instances of PrimitiveType and Enumeration) • ElementImport • Expression • GeneralizationSet • InstanceValue • InstanceSpecification • Interface • OpaqueExpression • PackageImport • PackageMerge • Slot with the following: [8] An EMOF metamodel is restricted to use the following concrete metaclasses from UML’s Kernel: • Association • Class • Comment • DataType • Enumeration • EnumerationLiteral • Generalization • InstanceValue • LiteralBoolean • LiteralInteger • LiteralNull • LiteralReal • LiteralString • LiteralUnlimitedNatural • Operation • Package • Parameter • PrimitiveType • Property Replace 12.4 [9] from resolution to 15398 in ballot 2, i.e: [9] The following properties must be empty: • Class::nestedClassifier • Classifier::/general for instances of Datatype • Operation::bodyCondition • Operation::postcondition • Operation::precondition • Operation::redefinedOperation • Parameter::defaultValue • Property::qualifier • Property::redefinedProperty • Property::subsettedProperty with the following: [9] The following properties must be empty: • Association::navigableOwnedEnd • Class::nestedClassifier • Classifier::/general for instances of Datatype • Operation::bodyCondition • Operation::postcondition • Operation::precondition • Operation::redefinedOperation • Parameter::defaultValue • Property::qualifier • Property::redefinedProperty • Property::subsettedProperty Replace 12.4 [10] from resolution to 15398 in ballot 2, i.e: [10] The following properties must be false: • Association::isDerived • Association::ownedNavigableEnd • Classifier::isFinalSpecialization • Feature::isStatic • Operation::isQuery • Property::isDerivedUnion • RedefinableElement::isLeaf with the following: [10] The following properties must be false: • Association::isDerived • Classifier::isFinalSpecialization • Feature::isStatic • Property::isDerivedUnion • RedefinableElement::isLeaf Replace 12.4 [12] from resolution to 15398 in ballot 2, i.e: [12] An Association has exactly 2 memberEnds, may never have an ownedNavigableEnd (they will always be owned by Classes) and may have at most one ownedEnd with the following: [12] An Association has exactly 2 memberEnds, may never have a navigableOwnedEnd (they will always be owned by Classes) and may have at most one ownedEnd Replace 12.4 [13] from resolution to 15398 in ballot 2, i.e: [13] Parameter::direction is ignored unless the value is ‘return’ (it is used to derive the multiplicity of the Operation) with the following: [13] An Operation can have up to one Parameter whose direction is ‘return’; furthermore, an Operation cannot have any ParameterSet per 12.4 [8]. Replace 12.4 [16] from resolution to 15398 in ballot 2, i.e: [16] Property::aggregation values of ‘shared’ will be ignored and treated as ‘none’ with the following: [16] Property::aggregation must be either ‘none’ or ‘composite’ Add the following: [17] Enumerations may not have attributes or operations [18] BehavioralFeature must be sequential. [19] Class must not be active. [20] An EnumerationLiteral must not have a ValueSpecification. [21] An Operation Parameter must have no effect, exception or streaming characteristics. [22] A TypedElement cannot be typed by an Association. [23] A TypedElement other than a LiteralSpecification or an OpaqueExpression must have a Type. [24] A TypedElement that is a kind of Parameter or Property typed by a Class cannot have a default value. [25] For a TypedElement that is a kind of Parameter or Property typed by an Enumeration, the defaultValue, if any, must be a kind of InstanceValue. [26] For a TypedElement that is a kind of Parameter or Property typed by an PrimitiveType, the defaultValue, if any, must be a kind of LiteralSpecification. [27] A composite subsetting Property with mandatory multiplicity cannot subset another composite Property with mandatory multiplicity. [28] A Property typed by a kind of DataType must have aggregation = none. [29] A Property owned by a DataType can only be typed by a DataType. [30] Each Association memberEnd Property must be typed by a Class. [31] A multi-valued Property or Parameter cannot have a default value. [31] The values of MultiplicityElement::lowerValue and upperValue must be of kind LiteralInteger and LiteralUnlimitedNatural respectively. Add an appendix with the specification of EMOF constraints for clause 12.4 from the file EMOFConstraints.ocl In clause 14.3, replace the first paragraph, currently: This section details additional constraints owned by the CMOF package that are applied to metamodels to be processed by a CMOF implementation. with the following: This section details the constraints owned by the CMOF package that are applied to metamodels to be processed by a CMOF implementation. These constraints supersede the EMOF constraints from clause 12.4; that is, validating a CMOF should be done with respect to all the CMOF constraints defined in this clause ignoring all the constraint definitions from clause 12.4. Replace 14.3 [1], currently: [1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e., n-ary Associations are not supported). context Association inv: memberEnd->size() = 2 with the following: [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. In 14.3 [2], delete the following: context Operation inv: raisedException.oclIsType(Class) In 14.3 [3], delete the following: context Integer inv: value >= -2^31 and value <= 2^31 - 1 Replace 14.3 [6], currently: [6] Names are required for all classifiers and features (though there is nothing to prevent these names being automatically generated by a tool). context Classifier inv: not(name = OclUndefined) context StructuralFeature inv: not(name = OclUndefined) with the following: [6] Names are required for all NamedElements except for ValueSpecifications. Replace 14.3 [7], currently: [7] Visibilities will be ignored (and everything assumed to be public). Name clashes through names thus exposed should be avoided. with the following: [7] CMOF does not support visibilities. All property visibilities must be explicitly set to public where applicable, that is for all NamedElements, ElementImports and PackageImports. Furthermore, no alias is allowed for any ElementImport. In 14.3 [8], delete: context Enumeration inv: isEmpty(feature) Replace 14.3 [9] from resolution to 15398 in ballot 2, i.e: [9] A CMOF metamodel may not include instances of the following UML metaclasses: • AssociationClass • GeneralizationSet • InstanceValue • InstanceSpecification • Interface • Slot with the following: [9] A CMOF metamodel is restricted to use the 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 Replace 14.3 [12] from resolution to 15398 in ballot 2, i.e: [12] The value of Property::defaultValue and Parameter::defaultValue must be of kind LiteralSpecification with the following: [12] A multi-valued Property or Parameter cannot have a default value. The default value of a Property or Parameter typed by a PrimitiveType must be a kind of LiteralSpecification. The default value of a Property or Parameter typed by an Enumeration must be a kind of InstanceValue. A Property or Parameter typed by a Class cannot have a default value. Delete 14.3 [14] from resolution to 15398 in ballot 2, i.e: [14] Instances of Dependency (and subclasses) will be ignored Replace 14.3 [15] from resolution to 15398 in ballot 2, i.e: [15] Generalization::isSubstitutable must be true with the following: [14] Generalization::isSubstitutable must be true Replace 14.3 [16] from resolution to 15398 in ballot 2, i.e: [16] Only one member attribute of a Class may have isId=true. Any others (e.g. those inherited) must be redefined: either made unavailable or redefined to change isId = false. with the following: [15] Only one member attribute of a Class may have isId=true. Any others (e.g. those inherited) must be redefined: either made unavailable or redefined to change isId = false. Replace 14.3 [17] from resolution to 15398 in ballot 2, i.e: [17] Property::aggregation values of ‘shared’ will be ignored and treated as ‘none’ with the following: [16] Property::aggregation must be either ‘none’ or ‘composite’ Add the following: [17] BehavioralFeature must be sequential. [18] Class must not be active. [19] An EnumerationLiteral must not have a ValueSpecification. [20] An Operation Parameter must have no effect, exception or streaming characteristics. [21] A TypedElement cannot be typed by an Association. [22] A TypedElement other than a LiteralSpecification or an OpaqueExpression must have a Type. [23] A TypedElement that is a kind of Parameter or Property typed by a Class cannot have a default value. [24] For a TypedElement that is a kind of Parameter or Property typed by an Enumeration, the defaultValue, if any, must be a kind of InstanceValue. [25] For a TypedElement that is a kind of Parameter or Property typed by an PrimitiveType, the defaultValue, if any, must be a kind of LiteralSpecification. [26] A composite subsetting Property with mandatory multiplicity cannot subset another composite Property with mandatory multiplicity. [27] A Property typed by a kind of DataType must have aggregation = none. [28] A Property owned by a DataType can only be typed by a DataType. [29] Each Association memberEnd Property must be typed by a Class. [30] A Constraint must constrain at least one element and must be specified via an OpaqueExpression. [31] The body of an OpaqueExpression must not be empty.
Actions taken:
November 17, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15821: Remove the distinction between isSet and the default value (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity: Significant
Summary:

The MOF spec has been inconsistent about whether isSet is true if the value is explicitly assigned the default value.

Since XMI has no means to serialize otherwise, then it should be true.

This is related to XMI issue 14628.

Resolution: This is addressed in the wording introduced in issue 15832 in this ballot. This supersedes the resolution to 8269.
Revised Text: This is addressed in the wording introduced in issue 15832 in this ballot. This supersedes the resolution to 8269. Revised Text: See description of set() in 15832. In Section 9.1, semantics, replace: • If the value of that property is later explicitly set, even to the default value, isSet=true. By: • If the value of that property is later explicitly set, isSet=true unless it is set to the default value (if any) in which case isSet=false. Also in 9.1, delete the following sentence: In the worst case it can be implemented by having an additional boolean, but usually for a particular implementation it can be implemented more efficiently (e.g., by having an internal distinguished value used to represent “no value set”).
Actions taken:
November 17, 2010: received issue
April 25, 2011: closed issue

Issue 15824: Fix resolution to issue 15398 from MOF2.4 ballot 2 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

MOF::Reflection must merge UML::Classes::Kernel instead of importing it because it defines MOF::Reflection::Element as an increment of UML::Classes::Kernel::Element
MOF::Identifiers does not need to import PrimitiveTypes since MOF::Common already does and that non-conflicting visible elements are imported transitively
MOF::Extension needs to import UML::Classes::Kernel, it does not need to import PrimitiveTypes since Kernel does this already via the merge of Core::Constructs, which imports PrimitiveTypes
MOF::CMOFReflection must merge MOF::Reflection because it uses MOF::Reflection::Object and also defines MOF::CMOFReflection::Element and MOF::CMOF::Reflection::Factory as increments of the classes in MOF::Reflection

Resolution: Apply the changes to the MOF2.4 metamodel as described in the summary. Additionally: - MOF::Reflection must import MOF::Common since operations defined in MOF::Reflection depend on types defined in MOF::Common - MOF::CMOFReflection does not need to import MOF::Common since it merges MOF::Reflection, which imports MOF::Common - MOF::CMOF does not need to merge UML::Classes::Kernel per resolution 15398 because MOF::CMOF merges MOF::CMOFReflection, which merges MOF::Reflection, which merges UML::Classes::Kernel - MOF::EMOF does not need to merge UML::Classes::Kernel per resolution 15398 because MOF::EMOF merges MOF::Reflection, which merges UML::Classes::Kernel
Revised Text: see pages 54 - 57 of OMG document ptc/2010-12-07 (worf format)
Actions taken:
November 22, 2010: received issue
April 25, 2011: closed issue

Issue 15825: Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature:
Severity:
Summary:

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

Resolution: As described in 15.4, Object::getType() : Type would correspond to Element::getMetaClass() : Class from the resolution of issue 5948 in ballot 1. Until the semantics of MOF is properly defined, it is unclear whether it makes sense to define Object::getType() and what cardinality the result should have, i.e., Type[1] or Type[1..*] or something else. Since defining the semantics of MOF also requires resolving issue 15828 that is deferred in MOF2.4, this issue must be deferred for MOF2.4 as well. Revised Text: Disposition: Deferred
Revised Text:
Actions taken:
November 22, 2010: received issue

Issue 15826: Delete the redundant package MOF::CMOFExtension described in clause 14.4 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Delete the redundant package MOF::CMOFExtension described in clause 14.4

Resolution: Every element shown in figure 14.3 (MOF::CMOFExtension) is a matching increment to a corresponding element shown in figure 11.1 (MOF::Extension). As far as these figures are concerned, the MOF::CMOFExtension package provides no additional capability beyond what MOF::Extension already provides. This would be sufficient to warrant deleting the MOF::CMOFExtension package. However, the resolution to issue 15827 involves adding a second association between Element and Tag that can only be expressed within CMOF because it involves a navigable owned association end, a capability that is specifically prohibited for EMOF per the resolution to issue 15820.
Revised Text: In clause 14.4, delete the following subclause: Extension [1] CMOF extends package Extension with role name “tag” for the non-navigable end on the association between Tag and Element. See the resolution to issue 15827 for an update of figure 14.3.
Actions taken:
November 22, 2010: received issue
April 25, 2011: closed issue

Issue 15827: Fix resolution to issue 6905 from MOF2.4 ballot 1 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Change the Element/Tag owner composite association to a composite association that symmetrically subsets the Element owner/ownedElement derived composite association from UML.

Resolution: The resolution to issue 6905 added a property: Tag::owner : Element[0..1] When EMOF or CMOF would be merged, this property would conflict with UML::Element::/owner : Element[0..1] property (see figure 7.3 in UML2.4 superstructure) The fix involves the following: - change the name of ownership property from owner to tagOwner - symmetrically subset the association end properties of the association UML::A_ownedElement_owner - make the composite association end, ownedTag, navigable and owned by the association; this is essential to avoid an incompatible API change to UML::Classes::Kernel::Element. However, because navigable owned association ends are not allowed in EMOF, it is necessary to add the ownedTag/tagOwner association in MOF::CMOFExtension instead of MOF::Extension.
Revised Text: see pages 59 - 60 of OMG document ptc/2010-12-07 (word format)
Actions taken:
November 22, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15828: There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Adding a SemanticDomain package describing the contents of clause 15, CMOF Abstract Semantics, is beyond the scope of the MOF2.4 RTF. Disposition: Deferred
Revised Text:
Actions taken:
November 22, 2010: received issue

Issue 15829: Revise conventions to avoid unnecessary duplication of descriptions for operations (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text:
Actions taken:
November 22, 2010: received issue

Issue 15830: Delete unenforceable MOF constraint 12.4 [7] (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Delete unenforceable MOF constraint 12.4 [7]

Resolution: Since constraint [7] in clause 12.4 refers to an undefined operation MOF::Object.isInstance() and since the only reasonable interpretation of this constraint is that of a tautology, the constraint provides no practical value to the MOF2 Core specification
Revised Text: Delete constraint [7] in clause 12.4
Actions taken:
November 22, 2010: received issue
April 25, 2011: closed issue

Issue 15831: Delete incompletely specified MOF operation Object::verify() in 15.4 and in diagrams in clause 13 (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

Delete incompletely specified MOF operation Object::verify() in 15.4 and in diagrams in clause 13

Resolution: Since the contents of the ReflectiveCollection result is left unspecified, this operation is unimplementable
Revised Text: Delete the reference to Element::verify(deepVerify : Boolean) : ReflectiveCollection from figure 13.2 See resolution to issues 15832, 15859 for updates to figure 13.2 Delete the following description from clause 15.4 and the post-condition: Object::verify() modeled as ObjectInstance::verify() Delete the entry for ‘verify’ in the MOF 2.0 column of the table in clause 16.2
Actions taken:
November 22, 2010: received issue
April 25, 2011: closed issue

Issue 15832: Move operations from 9.1 Element to 9.3 Object: equals, get/set/unset/isSet (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

As currently specified in 9.1, it makes sense to have these operations available in Object, not Element.
Pete concurred with me on making this change in MOF2.4; he said that these operations may have been shuffled at the last minute during MOF2.0 finalization.

Resolution: Move the operations in the metamodel & the specification as indicated in the summary. The specification of get/set operations should be in terms of ReflectiveCollection instead of ReflectiveSequence since the characteristics of a property with upper bound greater than 1 could be that of a sequence, bag, set or ordered set as specified in UML2.4 (see Superstructure clause 7.3.45, table “Collection types for properties”). Adding support for all of the collection types in UML is a separate issue.
Revised Text: see pages 63 - 66 of OMG document ptc/2010-12-07 (word format)
Actions taken:
November 23, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 15833: Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The unification of collection types across UML, OCL and MOF is beyond the scope the 2.4 series of UML, MOF and XMI RTFs. Disposition: Deferred
Revised Text:
Actions taken:
November 23, 2010: received issue

Issue 15859: Problems in MOF operations delete(), invoke() and isInstanceOfType() operations (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: 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
Revised Text: see pages 67 - -70 of OMG document ptc/2010-12-07
Actions taken:
December 2, 2010: received issue
April 25, 2011: closed issue

Discussion:

Issue 16270: MOF does not have the correct semantics for links in the presence of association specialization (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
May 26, 2011: received issue

Issue 16329: No unambiguous way in MOF 2.4 to serialize UML 2.4's StructuredActivityNode (mof2core-rtf)

Click here for this issue's archive.
Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com)
Nature: Revision
Severity: Critical
Summary:

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

Resolution: resolved as an urgent issue
Revised Text:
Actions taken:
June 10, 2011: received issue
January 12, 2012: closed issue

Discussion:

Resolution:
The problem is that the combination of the UML, MOF and XMI specs taken together do not provide an adequate specification of how to serialize StructuredActivityNodes, which leads to ambiguity.
Currently, the ownership of StructuredActivityNode by Activity is derived, and is a subset of Activity::node and Activity::group.  This leads to the question of whether a StructuredActivityNode should be serialized as a node, as a group, or both.  This has obvious impacts on model interchange, and also impacts fUML.
The solution is to make the ownership of StructuredActivityNode by Activity non-derived, and then fix the MOF semantics and XMI serialization rules to ensure that a StructuredActivityNode is serialized in a structuredNode element, and not in a node or a group element.
This resolution fixes the MOF part; there are two counterpart issues corresponding to the UML and XMI parts.
MOF 2.4 currently states that an Element may only have a single slot that refers to its container.  In the MOF semantics, it states for ClassInstance “At most one slot for an isComposite property may have a value. (This needs more work if the owner reference is not navigable)”.  In fact this ought to say “At most one owning slot, i.e. a slot whose property is opposite an isComposite property, may have a value”. The semantics also specifies Object::owningProperty(), unambiguously declaring that an object only has one owning slot at a time.
The issue is that there is no correct specification of which property provides the owning slot where there is redefinition.  In the case of StructuredActivityNode::activity, it redefines ActivityNode::activity and ActivityGroup::inactivity.  MOF needs to be clear that in such a case it is the slot for the redefining property that is the actual owning slot.  Armed with that information, the XMI spec can then say that the correct element to serialize is the one opposite the actual owning slot.
The semantics correctly states for ObjectInstance “the stored StructuralFeatures  … exclude Properties that have been redefined”.  However the main problem is in the definition of Instance::propertySlot(), which is supposed to return the slot corresponding to a particular property.  This in turn calls a function called originalDefinition() which incorrectly climbs up the chain of redefinitions and subsettings to find the highest property in the chain.  This is wrong on two counts: firstly it is the wrong algorithm in principle, because it conflicts with “excluding properties that have been redefined”, and secondly it is wrong to assume that there is only one redefinition/subsetting chain, because in general there are several.
The function originalDefinition is misnamed as well as being ill-conceived.  Instead, we need a function applicableDefinition that determines, for a given instance and a given property, which slot is applicable. 
The semantic function allSlottableProperties is incorrect; it misunderstands and reverses the role of redefinition, it confuses subsetting and redefinition, and it has an incorrect “not” in its attempt to exclude association-owned ends.
The semantic function owningProperty is incorrect because it does not take into account the effect of redefinition.
The semantic function allProperties is extensively used but has no definition.
Note: there are many other syntactic inconsistencies in the semantic definition of MOF 2.4, such as the inconsistent use of body conditions vs postconditions, the inconsistent use of operation names vs result, and the omission of operation call brackets.  This urgent resolution does not attempt to fix those issues.

Revised text:
In Section 15.2, under ClassInstance:
Replace:
2. At most one Slot for an isComposite property may have a value. (This needs more work if the owner reference is not navigable).
by:
2. At most one owning Slot, i.e. a Slot whose property is opposite an isComposite property, may have a value.
In Section 15.8, Additional Operations:
Replace the following definition:
[1] This gives all of the properties in the namespace of the class (including inherited) that require a slot: it excludes properties owned by Associations, derived properties and those that subset or redefine another property (in which case that property will provide the slot and the redefinition will just restrict the values)
Class::allSlottableProperties(): Set(Property);
allSlottableProperties = member->select(p| p.oclIsKindOf(Property) and
not (self.allParents() includes p.namespace)
-- excludes foreign association ends
not(p.isDerived) and
isEmpty(p.redefinedProperty) and
isEmpty(p.subsettedProperty) )

Replace it by:
[1] This gives all of the owned properties of the class (including inherited) that require a slot: it excludes derived properties and those that are redefined in the same classproperties.
Class::allSlottableProperties(): Set(Property);
allSlottableProperties = self.allNonDerivedProperties ()->reject( p | 
    (self.allNonDerivedProperties()->select(r |
              r.allRedefinedProperties()->intersection(self.allProperties())->includes(p))
[2] All the non-derived owned properties (including inherited) of a class.
Class::allNonDerivedProperties(): Set(Property);
allNonDerivedProperties = self.allProperties() -> select( p | not(p.isDerived))
[3
[2] All the non-redefined properties (including inherited) of a class.
Class::allProperties(): Set(Property);
allProperties = member->select(p |  p.oclIsKindOf(Property) and p.owner = self)n |  

[4                                  n.oclIsKindOf(Property))->collect( p |
                                              p.oclAsType(Property))

[3] All of the properties directly or indirectly redefined by a property.
Property::allRedefinedProperties() : Set(Property)
allRedefinedProperties = 
    if
       self.redefinedProperty->isEmpty
    then 
       Set{}
    else 
       self.redefinedProperty->union(
              self.redefinedProperty->collect(r | r.allRedefinedProperties())()))
      

Replace the following definition:
[2] This returns the slot corresponding to the supplied property. For redefining properties it will be the redefined one.
Note that derived properties will only have slots if the redefine a non-derived one so the result may be null.
Instance::propertySlot(Property p): Slot
propertySlot = self.slot->select(definingFeature = p.originalDefinition))
Replace it by:
[54] This returns the slot corresponding to the supplied property. For redefined properties it will be the slot corresponding to the redefining one.
Note that derived properties will only have slots if they are redefined by a non-derived one so the result may be null.
ObjectInstance::propertySlot(Property p): Slot
propertySlot = 
  if 
    self.oclIsKindOf(ClassInstance)
  then 
    self.slot->any(definingFeature =
                                    p.applicableDefinition(self.oclAsType(ClassInstance).classifier))
  else
     self.slot->any(definingFeature =  p)
Replace the following definition:
[3] This returns the original definition of a Property through any number of redefinitions and subsetting.
Property::originalDefinition(): Property
post: (isEmpty(redefinedProperty) and isEmpty(subsettedProperty) and result = self) or
(notEmpty(redefinedProperty) and result = redefinedProperty.originalDefinition()) or
(notEmpty(subsettedProperty) and result = subsettedProperty.originalDefinition())
Replace it by:
[65] This returns the property that defines the slot that will carry the data for the requesting property in an instance of the class c.
Property::applicableDefinition(Class c): Property
applicableDefinition = c.allSlottableProperties().any(p | 
       p.allRedefinedProperties()->includes(self))

Replace the following definition:

[4] This returns the single Property that represents the current owner of the Object based on current instance values; may be null for top level objects

Object::owningProperty(): Property
post: result = self.allProperties->select(op| op.opposite <> null and op.opposite.isComposite and self.get(op)<> null)
Replace it by:
[76] This returns the single Property with a slot that represents the current owner of the Object based on current instance values; may be null for top level objects.

Object::owningProperty(): Property modeled as ClassInstance::owningProperty(): Property
owningProperty = self.classifier.allSlottableProperties()->select(op | 
    op.opposite <> null and op.opposite.isComposite and self.get(op)<> null)

Add the following definition:

[7] All the non-redefined properties of an object.

Object::allProperties(): Set(Property) modeled as ClassInstance:: allProperties (): Set(Property)
allProperties = self.classifier.allProperties()
Renumber all of the remaining definitions to follow on from [8].

Issue 16393: MOF 2.4 issue: duplicated paragraph in section 3 (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
July 25, 2011: received issue

Issue 16394: MOF 2.4 issue: Part III contains the word Gagagaga (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 25, 2011: received issue

Issue 16489: Because MOF merges UML, UML as an instance of MOF is ill-formed (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
August 10, 2011: received issue

Issue 16585: EnumerationLiterals in the XMI (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 6, 2011: received issue
September 13, 2012: moved to the MOF 2 Core RTF

Issue 17049: Invalid restrictions on concrete metaclasses allowed in EMOF and CMOF (mof2core-rtf)

Click here for this issue's archive.
Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov)
Nature: Enhancement
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
January 26, 2012: received issue

Issue 17169: Semantics and ownership of link slots needs clarification (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Enhancement
Severity: Significant
Summary:

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?

Resolution:
Revised Text:
Actions taken:
February 23, 2012: received issue

Discussion:

Issue 17274: There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 23, 2012: received issue

Issue 17275: There is an inconsistency in the current spec between link equality and link delete (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature:
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 23, 2012: received issue

Issue 17276: URIExtent should provide the capability of accessing links as well as elements by URI (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 23, 2012: received issue

Issue 17394: Section 9.2: reconciliation with MOF Lifecycle should happen (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
May 24, 2012: received issue

Issue 17395: Section 9.2 constraints (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
May 24, 2012: received issue

Issue 17631: General comment: The text should be reviewed for clarity before it progresses to IS. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17632: Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17633: Section 3: Include a reference to either or both parts of ISO/IEC 19505:2012, as appropriate. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17634: Section 4: Include an “Abbreviation” clause, and if appropriate a populated Definitions clause (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17635: Section 6.2: Move the content of the second sentence to the (non-normative) Introduction. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17636: Section 6.3: Either drop this clause, or identify the clauses that constitute "Part 1". (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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”

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17637: Section 6.4: Delete the clause. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17638: Subpart 1: Delete the text from this location, possibly moving some of it to the Introduction (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17639: Section 8.2: Identify the document here and provide a full reference in Clause 3. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17641: Section 8.5: Move the definition to clause 3 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17642: Section 8.5, Subpart II” (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17643: Section 9.1 Value judgements, such as “An advantage of ...” are not appropriate in the normative text of a standard (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17644: Title: Category "Object Management Group" is not adequate for standards (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17645: Foreword, page vii: Title of ISO/IEC 19505-2:2011 is different (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17646: Foreword, page vii: Title of ISO/IEC DIS 19509 is different (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17647: Foreword, page vii: Title of ISO/IEC 14769 is different (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17648: Section 1: The scope seems to be focused on OMG standards only, not for ISO standards (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17649: Section 2 Conformance: Definition of conformance is insufficient (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

To define conformance clearly or delete this clause.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17650: Section 3 References: The title should change to "Normative Reference". (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17651: Section 3: To refer ISO/IEC 19505. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17652: Section 3: add references to CORBA, QVT and OCL (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

This specification refers to CORBA, QVT and OCL.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17653: The style of Reference should conform to the JTC1 style. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17654: Section 4 terms & Definitions: Nothing defined (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17655: Section 5: There is no reference of other specifications as UML (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17656: Section 6.2 Technical Specification: Use ISO Number for MOF1.4 -- MOF1.4 (ISO/IEC 1502) (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

MOF1.4 (ISO/IEC 1502)

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17657: Section 6.4 Clause “Acknowledgements” is informative - move to an informative ANNEX (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17658: Section 6.4: delete last line (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17659: Section 6: Clause “Additional Information” is not needed (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17660: Section 6 subpart 1: (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17661: delete subtitle “General Information.” (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17662: Clause 7 and sbuclause7.1 forms a “Hanging Paragraph” (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17663: Section 7: Designate the precise version of the referred standards (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17664: Section 7.2 Subclause title “MOF 2 Design Rationale” is not suitable for goals for this specification. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17665: Section 7.4 Reuse of Common packages (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17666: Section 8: Delete “81. General". It is also a “Hanging Paragraph” (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17667: Section 8: explain all terms for language formalism (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17668: Setion 8.4 Change from MOF1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17669: Subpart II Capabilities General (PP.13) (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17670: Section 9 Reflection: add sentences for Common package (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17671: Figure 9-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17672: Section 9.1, page 15, Figure 9-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17673: Section 9.2: Page 17, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17674: Section 9.3, page 18, paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17675: Section 10.1 page 21 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17676: Section 10.1 page 21, figure 10-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17677: Section 10.2 Page 22, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17678: Section 10.1 page 21, figure 10-1: There are two diagrams in one Figure 10-1. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17679: Section 10.3, page 23, paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17680: Section 10, Page 23 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17681: Section 10, Page 23, Figure 10-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17682: Sections 10.5, 10.6 Page 23, 24 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17683: Section 11.1, Page 27 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17684: Subpart II The MOF Model General Page 29 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Discussion:

Issue 17685: Subpart II The MOF Model, Page 29 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17686: Section 12.1 Page 31 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17687: Section 12.1, Page 31, 2nd Paragraph (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 24, 2012: received issue

Issue 17688: Section 12.1 page 32: add sentences to explain relationship to Figure 12-1. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17689: Section 12.2, Page 32, 33, Figure 12-1: There are two figures in Page 32 and 33 as same number as 12-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17690: Section 12.2, page 32: add sentences to explain relationship to Figure 12-1 through 12-4. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17691: Section 12.2 page 33, 34, Figure 12-1, 12-2, 12-3, 12-4, get rid of volour in diagrams (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17692: 12.4 page 35: Be consistent with UML 2.4.1 and OCL 2.4.1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17693: Section 13.1 page 41: add sentences to explain relationship to Figure 13-1 and 13-2. (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17694: Section 13.2 page 43, Paragraph Semantics (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17695: Section 13.2 page 43, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

MOF1.4 ?ISO/IEC19502

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17696: Section 13.3 page 43, Paragraph Semantics (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17697: Section 13.3 page 43, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 “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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17698: Section 13.4 page 44, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 “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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17699: Section 13.5 page 44, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 “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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17700: Section 13.6 page 45, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 “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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17701: Section 13.7 page 45, Paragraph Changes from MOF 1.4 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

 “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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17702: Subpart IV: Abstract Semantics page 47 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Discussion:

Issue 17703: Section 14.1 page 49, Figure 14-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17704: Sections 14.1, 14.2, 14.5 pages 49, 50, 53, Figure 14-1 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17705: Section 14.2 page 49 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17706: Section 14.3 page 50 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17707: Section 14.5 page 53 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17708: Section 14.5.2 page 53, Note (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17709: Section 15.3 page 55 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17710: Section 15.4 page 58 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17711: Section 15.8 page 62 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17712: Section 15.8 page 62 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17713: Section 16 page 67 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17714: Subpart V Annexes page 71 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17715: Annex A page 73 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17716: Annex B page 75 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 17717: Annex C page 77 (mof2core-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
September 25, 2012: received issue

Issue 18661: Resolve MOF 2 PAS National Body Ballot Comments (mof2core-rtf)

Click here for this issue's archive. Click here for this issue's attachments.
Source: 88solutions (Mr. Manfred R. Koethe, koethe(at)88solutions.com)
Nature:
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
April 12, 2013: received issue

Issue 18782: References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 . (mof2core-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 18, 2013: received issue

Issue 18808: the return type of the remove() operation is inconsistent with the description (mof2core-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
July 10, 2013: received issue

Issue 18811: MOF issue - MOF says nothing about the semantics of operation redefinition (mof2core-rtf)

Click here for this issue's archive.
Source: Microsoft (Mr. Steve Cook, stcook(at)microsoft.com)
Nature: Revision
Severity:
Summary:

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.

Resolution: MOF issue - MOF says nothing about the semantics of operation redefinition
Revised Text:
Actions taken:
July 10, 2013: received issue