Issues for MOF 2.6 Revision Task Force

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

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

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

Jira Issues

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
May 27, 2011: closed issue; Transfered

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 SE (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 issue; 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 9018: Section: 10.3 (mof2core-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
September 27, 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: received issue
January 20, 2011: closed issue; 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: Micro Focus (Dr. Jishnu Mukerji, jishnu(at)microfocus.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: https://www.omg.org/spec/MOF/2.4/emof/20080301 Replace: http://schema.omg.orb/spec/MOF/2.0/cmof.xml With: https://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 issue; 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: Model Driven Solutions (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: received 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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: Adopt the explanation of �ordered� from UML 2.5 - Association
Revised Text: Clause 13.2 � Semantics After the existing sentence, insert the sentence: When one or more ends of the Association are ordered, links carry ordering information in addition to their end values.
Actions taken:
October 9, 2009: received issue
April 6, 2015: closed 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 issue; 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: Model Driven Solutions (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: Model Driven Solutions (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: closed no change
Revised Text:
Actions taken:
June 2, 2010: received issue
April 6, 2015: closed issue

Discussion:

The offending sentence is no longer in the specification document, the current text  describes the role of Element much clearer.  The concerns expressed by the issue author are possibly no longer current. Since  version 2.4, MOF and UML share a common metamodel, in which Element is on top  of the hierarchy for both. The only difference is, that MOF::Reflection::Element adds reflection capability to Element via extra operations and a derived association to the  Element�s metaclass.

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: closed no change
Revised Text:
Actions taken:
September 3, 2010: received issue
April 6, 2015: closed issue

Discussion:

In version 2.4 and later, the equals() operation compares Objects, which includes  instances of DataTypes. The existing text is clear about the behavior of equals() for  both cases, comparing Elements or Data Values.

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: This is part of a larger effort to do the final steps of MOF � UML harmonization. Change the MOF Model to merge UML (from 2.5) instead of UML::Kernel. Revise the whole MOF Core specification document to change any remaining references to Basic, Infrastructure, Kernel, etc. to the corresponding references based on UML 2.5. This effort includes replacement of diagrams where necessary
Revised Text: see pages 23 - 36 of ptc/2014-09-35for details
Actions taken:
September 21, 2010: received issue
April 6, 2015: closed 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: Agreed. Correct the operation signature to return Boolean. C.isInstance(null) should return false at all time. Null is not a valid classifier and violates the constrains of UML::Type on which MOF::Reflection::Type is based.
Revised Text: Clause 9.4.1 � operation set() In the second Exception: bullet point, replace the signature: isInstance(element) by: isInstance(object) Perform the same change in the MOF model.
Actions taken:
September 27, 2010: received issue
April 6, 2015: closed 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: Clause 13.7 � operation linksOfType() Replace the signature: linksOfType(type : Association) : Link[0..*] by: linksOfType(type : Association, includesSubtypes : Boolean) : Link[0..*] Perform the same change in the MOF model. Replace the explanatory sentence following signature by the following text: This returns those links in the extent that are instances of the supplied Association, or of any of its specializations if includesSubtypes is true. [ the diagram will be updated by resolution of 15608 ]
Revised Text:
Actions taken:
September 28, 2010: received issue
April 6, 2015: closed issue

Discussion:

Agreed. Correct the operation signature to return Boolean

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

Discussion:

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, this issue shall also be deferred.  The MOF 2.6 RTF should consider merging SMOF into MOF Core, which would  provide answers to these questions above. At that time, the resolution needs to make  a statement like �C.isInstance(null) should return false at all time. Null is not a valid  classifier and violates the constrains of UML::Type on which MOF::Reflection::Type  is based.� to satisfy Issue 15646 completely.  Disposition: Deferred

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

Discussion:

The issue submitter has a valid point. However the resolution requires substantial  work and coordination with UML, therefore this issue is deferred.  Ideally, a merger of the four main MOF specifications (MOF Core, SMOF, MOF  Facility, MOF Version) into one combined specification would naturally resolve a  good part of this issue.  Disposition: Deferred

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
April 6, 2015: closed issue

Discussion:

While the signatures of the inherited operations in ReflectiveSequence are identical  to those in the superclass ReflectiveCollection, these operations are not simply  inherited but redefined. Their exact execution semantics differ. Therefore, relisting  these three operations is not only justified, but necessary.  Disposition: Closed � No Change

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 requires substantial time and coordination. 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: This is related to issue 15828. Therefore this issue is also deferred. Disposition: Deferred
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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661. Disposition: Merged with 18661
Revised Text:
Actions taken:
July 25, 2011: received issue
April 6, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661.
Revised Text:
Actions taken:
July 25, 2011: received issue
October 20, 2014: merged with issue 18661
October 20, 2014: closed issue; Duplicate or Merged

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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: The fact that MOF merges UML is actually correct, and requires no changes. The important �fine print� detail is that PackageMerge is not inheritance. With PackageMerge, matching elements in the mergingPackage and the receivingPackage are merged into a single element without changing the position of that resulting element in the type hierarchy. This means in case of UML::Element versus Reflection::Element that UML::Element is augmented with the reflective capabilities defined in Reflection::Element without changing its position in the type hierarchy of the UML metamodel. In particular, UML::Element is not a subclass of Reflection::Element. If seen in the context of MOF, it remains unchanged the superclass of all UML metaclasses, but augmented with the MOF capabilities. Since version 2.4, MOF is based on a constrained-down UML metamodel. The only way to add the additional capabilities of MOF without altering the type hierarchy is PackageMerge, therefore MOF needs to merge UML. To provide absolute clarity, the clause describing the Package composition of MOF shall be improved.
Revised Text: The revised text for this resolution is contained in the textual changes performed by the resolution for issue 15608. For convenience to the document editor, these changes are not separated. ]
Actions taken:
August 10, 2011: received issue
April 6, 2015: closed 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: This issue is outdated. Disposition: Closed - No Change
Revised Text:
Actions taken:
October 6, 2011: received issue
September 13, 2012: moved to the MOF 2 Core RTF
April 6, 2015: closed issue

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: Accept the proposal
Revised Text: Clause 12.4 � EMOF Constraints In the bulleted list following [8] insert after � � Generalization�: � InstanceSpecification and insert after � � Property�: � Slot Clause 14.4 � CMOF Constraints In the bulleted list following [10] insert after � � Generalization�: � InstanceSpecification and insert after � � Property�: � Slot
Actions taken:
January 26, 2012: received issue
April 6, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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: LinkSlots are owned by the AssociationInstance. Update diagram 15-1 to show this correctly.
Revised Text: see pages 44 of ptc/2014-09-35 for details
Actions taken:
February 23, 2012: received issue
April 6, 2015: closed 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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: The issue submitter raises a valid point, however this change has to be made carefully and with vendor involvement, since literally all existing tools provide private uuid mechanisms. This should be addressed by the next RTF. Disposition: Deferred
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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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

Discussion:

Agreed. The resolution of this issue is dependent on a resolution to 17274, which is  deferred to allow more time and vendor involvement. This issue is therefore deferred  as well.  Disposition: Deferred

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: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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

Discussion:

MOF requires substantial work to get all identifier right. This is true not only  URIExtents, but also for uuids of elements. Prerequisite is a merger of the four MOF  specification (MOF Core, SMOF, MOF Facility and MOF Version) into one  specification, and then apply a unified identification scheme. Therefore this resolution  needs to be deferred until then.  Disposition: Deferred

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
October 20, 2014: merged with issue 18661
October 20, 2014: closed issue; Duplicate or Merged

Discussion:

The offending text has been removed by resolving the ISO/IEC-PAS comments. See  issue 18661. The reconciliation of MOF Core, MOF Facility, MOF Version and SMOF  is highly desired but out of the resource limit of this RTF and shall be addressed in a  separate issue by a follow-on RTF.  Disposition: Merged with 18661

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
April 6, 2015: closed issue

Discussion:

Proposal is too imprecise to cause any direct action. However, the responses to all  the PAS Ballot Comments will in summary result in the requested document  improvements. No action for this particular issue required.  Disposition: Closed, no change

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: Starting with version 2.4, MOF shares the metamodel with UML (Superstructure). Therefore from version 2.4 on, MOF depends only on the corresponding UML Superstructure specification. Within the document, replace all mentioning of UML Infrastructure by UML Superstructure and add normative references to UML Superstructure as ISO and as OMG document to clause 3. Disposition: Merged with 18661
Revised Text:
Actions taken:
September 24, 2012: received issue
April 6, 2015: closed 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: Include an "Abbreviation" clause, and if appropriate a populated Definitions clause.
Revised Text:
Actions taken:
September 24, 2012: received issue
October 20, 2014: merged with issue 18661
April 6, 2015: closed issue

Discussion:

Agreed. Consider adding abbreviations. Move definition of NULL into definitions  clause as per issue GB11 (17641). Check if spec uses normative definitions from any  other OMG or ISO specs..  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Move the content of the second sentence to the (non-normative) Introduction.  Discussion:  The resolution to issue 17636 replaces Clause 6 with new introductory content, which  handles also the request of this issue.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Either drop this clause, or identify the clauses that constitute "Part 1".  Discussion:  Remove sub parts, and move any valuable intro material from the non-numbered  sub-part introductions somewhere else.  Disposition: Merged with issue 18661

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: see pages 65 - 83 of ptc/2014-09-35
Revised Text:
Actions taken:
September 24, 2012: received issue
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Delete the clause.  Discussion:  Move acknowledgements to informative annex. Fix the missing bullet after  Gentleware.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Delete the text from this location, possibly moving some of it to the Introduction.  Discussion:  Remove subpart, move any useful paragraphs somewhere else, maybe clause 6.  Duplicate to 17636.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Identify the document here and provide a full reference in Clause 3.  Discussion:  Change all normative references to UML infrastructure to UML superstructure, as  MOF shares the metamodel of UML Superstructure since version 2.4. Duplicate to  17633.  Disposition: Merged with issue 18661

Issue 17640: Section 8.4: Indicate clearly the clauses in which the differences are described (mof2core-rtf)

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

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

Resolution: Proposed Resolution by NB: Indicate clearly the clauses in which the differences are described. If the differences are described, consider moving the information to an informative annex. Discussion: Delete subclause 8.4. Disposition: Merged with issue 18661
Revised Text:
Actions taken:
September 24, 2012: received issue
April 6, 2015: closed issue

Discussion:

Indicate clearly the clauses in which the differences are described.  If the differences are described, consider moving the information to an informative annex.

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Move the definition to clause 3.  Discussion:  Move "Null" text to definitions clause. Duplicate to 17634.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  [no proposed resolution provided]  Discussion:  Remove sub-part structure. The penultimate paragraph might be normative if it is not  stated elsewhere. Duplicate to 17633.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Rewrite the introduction paragraph to contain only straight facts relevant to  construction of implementations or exploitation of implementations of this standard.  Discussion:  Change " An advantage of metaobjects generally is that they enable " to  "Metaobjects enable".  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change to "Information technology -- Object Management Group Meta Object  Facility (MOF) Core Version 2.4.1".  Discussion:  For the ISO PAS Document, change the title on the title page to:  "Information technology - Object Management Group Meta Object Facility (MOF)  Core:"  For the OMG Document, change the title on the title page to:  "Meta Object Facility (MOF) Core  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "ISO/IEC 19505-2:2012 Information technology -- Object Management Group  Unified Modeling Language (OMG UML) -- Part 2: Superstructure".  Discussion:  Agreed.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "ISO/IEC DIS 195059 Information technology -- Object Management Group --  MOF 2 XMI Version 2.4.1"..  Discussion:  Agreed. But use revised title of XMI specification.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

No change required. Title is " ISO/IEC 14769:2001 Information technology -- Open  Distributed Processing -- Type Repository Function�.  Disposition: Closed, no change

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  It should provide a clear focus as an ISO standard. Especially, relationship to other  ISO standards, such as ISO/IEC 19505 or 19502 &3.  Discussion:  Change to use formal references with dual format for specs that are both OMG and  ISO/IEC standards. Need to add clarification to ISO Foreword that these 2.4 versions  do not supersede 1.x versions.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To define conformance clearly or delete this clause.  Discussion:  Need explaining what is entailed for EMOF and CMOF compliance points. Add  MOF2 XMI and remove MOF2 IDL as normative references.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  The title should change to "Normative Reference�.  Discussion:  Agreed, change the title of Clause 3 to: �Normative References�  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To refer ISO/IEC 19505.  Discussion:  Change to use dual reference style. Duplicate to 17648.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Normative reference to OCL is there, should change to use dual style. QVT is in  scope, so add OMG reference to Bibliography. Remove all the informative references  to CORBA in example phrased throughout document. Remove all normative  references to MOF2 IDL and its use in conformance clause.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  The style of Reference should conform to the JTC1 style..  Discussion:  Will change to dual reference style with brackets. PAS submissions are not required  to conform fully to ISO JTC1 style. Duplicate to 17648.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Terms and concepts that were used in this document should be defined here.  Discussion:  Agreed. Accommodated by resolution to issue 17641.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences for reference of symbols used in this specification.  Discussion:  Deletion of this clause would cause undesired renumbering of all following clauses in  the document. Therefore, add at least one symbol definition.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To refer ISO/IEC 19505.  Discussion:  This is resolved by the resolution for issue 17636  Disposition: Merged with issue 18661

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: see pages 65 - 83 of ptc/2014-09-35
Revised Text:
Actions taken:
September 24, 2012: received issue
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To move to an informative ANNEX.  Discussion:  Change to use dual reference style. Duplicate to 17648.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete the last line..  Discussion:  Duplicate to 17637.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  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.  Discussion:  Delete 6.1, and have intro text from Subparts headings moved into clause 6  subsections, as in UML 2.4.1. � Resolved by issue 17636.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To merge into one clause.  Discussion:  Moving sub-part hanging paragraph text to clause 6 somewhere. Duplicate to 17636.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete subtitle "General Information.".  Discussion:  Change to use dual reference style. Duplicate to 17633 and 17642.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Disagree, ISO/IEC Directives part 2 subclause 5.2.4 shows an example considered  as �good� which uses the first subclause titled "General" just as done here.  Disposition: Closed, no change

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Designate the precise version of the referred standards.  Discussion:  Use dual reference style when referring to standards, and add an Abbreviation  subbclause for appropriate abbreviations. Change MOF2.0 UML2.0 to remove ".0";  remove use of MOF1..  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change a title to "MOF 2 Design Requirements." There must be some  statements to be ISO standards.. MOF1.4 had become ISO...  Discussion:  Consider title change to "goals" and adding explanation of how MOF 1.4 is not  superseded by MOF 2. Consider adding MOF and XMI specs for version 1 as  bibliography. Label the entire clause 7 as informative. Add remaining references, if  there are any, to bibliography.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To be consistent with each other.  Discussion:  Change Figure reference to use "7-1".  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Disagree, ISO/IEC Directives part 2 subclause 5.2.4 shows an example considered  as �good� which uses the first subclause titled "General" just as done here.  Disposition: Closed, no change

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To explain all terms for language formalism.  Discussion:  Consider adding terms to "Terms and Definitions" subclause, if they are not OED  terms. Duplicate to 17634.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes". Use ISO/IEC19502 for MOF 1.4.  Discussion:  Accomodated by resolution to issue 17640  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete subtitle "General.".  Discussion:  Accommodate by removing subparts and moving some of the text to clause 6.  Duplicate to 17636.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences for Common package.  Discussion:  Accommodate by removal of subpart opening text. MOF::Common is currently a  subclause of clause 10 (10.4) The resolution of this issue depends on resolution of  Issue 17680 which adds the descriptive paragraph.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 9-1.  Discussion:  Consider adding sentence introducing Figure 9-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To split it into two figures 9-1 as classes and 9-2 as relationship between packages.  Discussionion:  The purpose of the embedded package diagram in Figure 9-1 is to clarify the origin of  the shown classes. Therefore the diagram needs to remain as it is. The resolution of  issue 17671 adds an explanation about the purpose of the embedded package  diagram.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Duplicate to issue 17668.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Partially accommodated by issue 17668.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 10-1.  Discussion:  Agreed. Add explanatory text to figure 10-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To split it into two figures 10-1 as classes and 10-2 as relationship between  packages.  Discussion:  The purpose of the embedded package diagram in Figure 10-1 is to clarify the origin  of the shown classes. Therefore the diagram needs to remain as it is. The resolution  of issue 17675 adds an explanation about the purpose of the embedded package  diagram.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To renumber a second figure as 10-3.  Discussion:  Agreed. Correct figure numbering. Resolution included in resolution to issue 17665.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolutionissue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to issue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change a sub clause as 10.4 to a clause as 11 and renumber following clauses.  Discussion:  MOF provides three capabilities: Reflection, Identifiers and Extension. The clause  numbering follows this structure. Package MOF::Common provides facilities to  handle multi-valued entities, which are used by the Identifiers capability. Therefore it  is described as subclause within the Identifiers capability. The clause numbering  shall stay unmodified, the description of MOF::Common shall be expanded.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To split it into two figures 10-1 as classes and 10-2 as relationship between  packages.  Discussion:  The purpose of the embedded package diagram in Figure 10-2 (figure number  corrected from 10-1 to 10-2 by issue 17665) is to clarify the origin of the shown  classes. Therefore the diagram needs to remain as it is. The resolution of issue  17680 adds an explanation about the purpose of the embedded package diagram.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change a sub clause as 10.5 Reflective Collection and 10.6 Reflective Sequence  to a sub clause as 11.1 and 11.2.  Discussion:  Resolution for this issue included in resolution for issue 17680.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 11-1.  Discussion:  Agreed. Add explanatory text to figure 11-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete subtitle "General."  Discussion:  Fix while moving text to clause 6.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change to "CMOF Abstract Semantics."  Discussion:  Fix while moving text to clause 6.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change "introduction" to "general."  Discussion:  Agreed.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add "Common" as a fourth package.  Discussion:  Correct description of merged packages.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 12-1.  Discussion:  Agreed. Add explanatory text to figure 12-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To renumber a second figure as 12-3.  Discussion:  Agreed. Correct figure numbering. Resolution included in resolution to issue 17665.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 12-1.  Discussion:  Agreed. Add explanatory text to figure 12-1. Resolution included in resolution 17688.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To get rid of the color.  Discussion:  Agreed. Render MagicDraw generated figures without color.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To be consistent with UML 2.4.1 and OCL 2.4.1  Discussion:  The primary definitions of primitive types for MOF are in in package PrimitiveTypes  shared between UML 2 and MOF 2, however these definitions are compatible with  the equivalent definitions in XML Schema. Therefore we do not consider the  reference to the W3C specification of XML Schema as a normative reference. Add a  reference to XML Schema to the Bibliography and a citation to clause 12.4.  This is resolved by issue 18661.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 13-1 and 13-2.  Discussion:  Agreed. Add explanatory text to figure 13-1 and 13-2.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  Replace the text with precise one.  Discussion:  Reword this paragraph.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To describe adequately.  Discussion:  Argument is a data type supporting open reflective operations. As a data type, it has  no semantics of its own. Replace �None� with a clarifying sentence.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674..  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To use "Differences" rather than "Changes".  Discussion:  Accommodate by removal of the "changes from MOF 1.4 subclauses throughout. Will  move the MOF 1.4 migration clause 16 as normative annex. Add MOF 1.4 as  normative reference. Accommodated by resolution to Issue 17674..  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete this part.  Discussion:  Accommodate by removal of Subpart structure. Duplicate to 17638.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 14-1.  Discussion:  Agreed. Add explanatory text to figure 14-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To renumber a second figure as 14-2 and a third figure as 14-3.  Discussion:  Agreed. Correct figure numbering. Resolution included in resolution to issue 17665.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To refer an existing figure.  Discussion:  Agreed. After correcting the figure numbering in the whole document (resolution to  issue 17665) ensure the reference is then pointing to the right figure.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add "Common" as a fourth package.  Discussion:  Correct description of merged packages. Duplicate to issue 17687  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 14-1.  Discussion:  Agreed. Add explanatory text to figure 14-1. Duplicate to issue 17703.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To be consistent with each other.  Discussion:  Agreed. After correcting the figure numbering in the whole document (resolution to  issue 17665) ensure the reference is then pointing to the right figure.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add sentences to explain relationship to Figure 15-1.  Discussion:  Agreed. have leading paragraph before figure 15-1 refer to figure 15-1.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change to a note format defined in ISO/IEC Directive Part 2.  Discussion:  Agreed. Review clause content and change title to something more appropriate.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To add a caption.  Discussion:  Agreed. Add caption.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To get rid of the color.  Discussion:  Agreed. Render diagram without color.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To move to an annex or delete this clause.  Discussion:  Clause 16 defines the transition from MOF 1.4 to MOF 2.x. Since MOF 1.4 is  different from MOF 2.x, and also continues to be an ISO standard, a formal transition  mapping is adequate. We agree however to move this information to a normative  Annex. Accommodated by resolution to Issue 17674  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To change A, B, C to Annex A, Annex B, Annex C.  Discussion:  Accommodate by removal of Subpart structure. Rename to Annex A, Annex B and  Annex C. Duplicate to 17638.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To put enough description in Annex A or change to an informative annex.  Discussion:  Clarify that these are references to the machine readable file URLs which are  normative.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Proposed Resolution by NB:  To delete Annex B.  Discussion:  We do not agree to delete Annex B. Replace file references with proper OMG URLs.  Disposition: Merged with issue 18661

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
April 6, 2015: closed issue

Discussion:

Disagree. The copyright to all OMG specifications (including this one) belongs to the  organisations that authored the specification. These organisations are listed in this  informative annex. Each of these organisations has given OMG an irrevocable,  transferrable, nonexclusive worldwide licence to publish the specification and works  derived from it, under the terms listed in the annexe. OMG in turn uses this licence to  create a version of the specification that ISO may publish, and gives ISO a nonexclusive  licence to do so.  Since the ISO document formatting conventions do not allow for declarations of  copyright ownership near the front of the specification (as is normal industry  practice), all OMG PAS submissions (including this one) put this information in an  annex towards the end of the specification, as agreed with the ISO secretariat at the  time of OMG's first PAS submission in 1999.  The copyright ownership and usage licence of the specification are as listed in this  annex. Removing the annex would not change this, and would deprive users of easy  access to essential information about the copyright ownership and licencing of the  specification.  This does not affect ISO/IEC's copyright ownership of the material it adds to the  specification.  Disposition: Closed, no change

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: Resolve the ISO PAS comments sequentially throughout the document
Revised Text: see pages 65 - 83 of ptc/2014-09-35
Actions taken:
April 12, 2013: received issue
April 6, 2015: closed 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: Agreed. The resolution for issue 15608 removed all remaining references to Infrastructure and Superstructure (where applicable) and updated all affected diagrams. However the figures listed above were deemed valuable and have therefore been updated and not removed. Disposition: Merged with 15608
Revised Text:
Actions taken:
June 18, 2013: received issue
April 6, 2015: closed 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: Agreed. Correct the operation signature to return Boolean
Revised Text: Clause 10.5 � operation remove() Replace the signature: remove(object : Object) : Object by: remove(object : Object) : Boolean Perform the same change in the MOF model.
Actions taken:
July 10, 2013: received issue
April 6, 2015: closed issue

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

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
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

Issue 19131: Error in specified return value (mof2core-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
November 28, 2013: received issue

Issue 19239: Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag (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:

The simplification and alignment between UML and MOF in the 2.4 series is incomplete.  In particular, the extensions that MOF adds to UML are missing in UML.  The MOF extensions that are missing in UML mean that statements like the one below in UML 2.5, section 6.2 are technically incorrect:      Since version 2.4.1 a MOF 2.x metamodel, including the UML 2.x metamodel, is a valid UML 2.x model. This was a substantial simplification and alignment compared to earlier versions. It is expected that future versions of MOF and UML will continue to be aligned in this manner.      For example, UML has no mechanism to specify the information about MOF::Extension::Tag. Without this information, it is currently not possible to fully rely on the above statement to use UML as a language for representing models of UML itself or parts of it such as the PrimitiveTypes library.      One fairly simple option would be to define a MOF profile with stereotypes corresponding to the contents of the MOF-specific extensions of UML

Resolution:
Revised Text:
Actions taken:
February 14, 2014: received issue
March 3, 2014: moved to mof2core-rtf from mof2xmi-rtf

Issue 19613: MOF should publish a convenience document that pre-merges all the different packages (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 should publish a convenience document that pre-merges all the different packages

Resolution:
Revised Text:
Actions taken:
September 18, 2014: received issue

Issue 19759: The text is not clear (mof2core-rtf)

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

The portion of text ""An Extent is a context in which an Element in a set of Elements in a set can be identified"".  I think that this way is better: ""An Extent is a context in which an Element in a set of Elements can be identified""    That way, I can understanding. To more detail, in my language (portuguese), the Google shows a concise translation.

Resolution:
Revised Text:
Actions taken:
May 16, 2015: received issue

Issue 19861: Missing a right brace (mof2core-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
November 30, 2015: received issue

Issue 19871: Sentence fragment duplication (mof2core-rtf)

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

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

Resolution:
Revised Text:
Actions taken:
December 17, 2015: received issue

Issue 19872: Does MOF::Reflection::Object own "invoke" Operation ? (mof2core-rtf)

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

Regarding to spec:  �13.4 Object (from CMOF Reflection)  "CMOF Reflection adds the following extra operations.  invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]"      But this operation is present into https://www.omg.org/spec/MOF/20131001/MOF.xmi file for MOF::Reflection::Object :      <packagedElement xmi:type="uml:Class" name="Object" xmi:id="_MOF-Reflection-Object">    ...    <ownedOperation xmi:type="uml:Operation" name="invoke" visibility="public" xmi:id="_MOF-Reflection-Object-invoke">     ...    </ownedOperation>      Moreover it uses <type xmi:idref="_MOF-CMOFReflection-Argument"/> from CMOF.    Thanks

Resolution:
Revised Text:
Actions taken:
December 17, 2015: received issue

Discussion:

Issue 19873: <packagedElement> as root Model element ? (mof2core-rtf)

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

The file https://www.omg.org/spec/MOF/20131001/MOF.xmi starts with:      <xmi:XMI xmlns:mofext="https://www.omg.org/spec/MOF/20131001" xmlns:uml="https://www.omg.org/spec/UML/20131001" xmlns:xmi="https://www.omg.org/spec/XMI/20131001">    <packagedElement xmi:type="uml:Package" xmi:id="_MOF" name="MOF">      ...      Is it correct to have <packagedElement> as root Model element ?      Why isn't it :      <xmi:XMI xmlns:mofext="https://www.omg.org/spec/MOF/20131001" xmlns:uml="https://www.omg.org/spec/UML/20131001" xmlns:xmi="https://www.omg.org/spec/XMI/20131001">    <uml:Package xmi:id="_MOF" name="MOF">      ...    Thanks

Resolution:
Revised Text:
Actions taken:
December 17, 2015: received issue

Discussion: