Issues for MOF 2.6 Revision Task Force

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

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

Jira Issues

Issue 8268: MOF 2.0 Core: Exceptions missing for CMOF Reflective operations Jira Issue MOF24-1
Issue 8695: Key Qualifiers Missing in MOF Jira Issue MOF24-2
Issue 8997: CMOF should not itnore visibilities Jira Issue MOF24-3
Issue 9018: Section: 10.3 Jira Issue MOF24-4
Issue 15825: Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1 Jira Issue MOF24-5
Issue 15828: There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15 Jira Issue MOF24-6
Issue 15833: Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties Jira Issue MOF24-7
Issue 16270: MOF does not have the correct semantics for links in the presence of association specialization Jira Issue MOF24-8
Issue 17274: There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects Jira Issue MOF24-9
Issue 17275: There is an inconsistency in the current spec between link equality and link delete Jira Issue MOF24-10
Issue 17276: URIExtent should provide the capability of accessing links as well as elements by URI Jira Issue MOF24-11
Issue 17395: Section 9.2 constraints Jira Issue MOF24-12
Issue 17632: Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3. Jira Issue MOF24-13
Issue 18811: MOF issue - MOF says nothing about the semantics of operation redefinition Jira Issue MOF24-14
Issue 19131: Error in specified return value Jira Issue MOF24-15
Issue 19239: Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag Jira Issue MOF24-16
Issue 19613: MOF should publish a convenience document that pre-merges all the different packages Jira Issue MOF24-17
Issue 19759: The text is not clear Jira Issue MOF25-18
Issue 19861: Missing a right brace Jira Issue MOF25-20
Issue 19871: Sentence fragment duplication Jira Issue MOF25-21
Issue 19872: Does MOF::Reflection::Object own "invoke" Operation ? Jira Issue MOF25-22
Issue 19873: <packagedElement> as root Model element ? Jira Issue MOF25-23

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

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

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

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.  

Disposition:	Deferred to UML 2.4 RTF

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.   

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?   

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

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

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

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

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

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.               

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

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.  

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

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.  

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

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

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.

UML uses operation redefinition quite extensively, but MOF says nothing about what this means, and UML itself leaves it rather open � see for example issues 17924 and 15499.  UML 2.5 beta leaves it even more open than 2.4.1, which means that MOF needs to be specific for UML to be well-defined.         My suggestion is that MOF requires parameters in redefined operations to have the same number, type, multiplicity, uniqueness and ordering as the parameters in the operation being redefined.  

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

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

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

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.

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

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.

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

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