Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Open Issues

  • Acronym: MOF
  • Issues Count: 16
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

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

  • Key: MOF26-20
  • Legacy Issue Number: 19613
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: MOF 2.4 — Thu, 18 Sep 2014 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag

  • Key: MOF26-23
  • Legacy Issue Number: 19239
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • 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

  • Reported: MOF 2.4 — Fri, 14 Feb 2014 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Error in specified return value

  • Key: MOF26-22
  • Legacy Issue Number: 19131
  • Status: open  
  • Source: Student ( Jean-Luc Amitousa Mankoy)
  • 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.

  • Reported: MOF 2.4.1 — Thu, 28 Nov 2013 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF issue - MOF says nothing about the semantics of operation redefinition

  • Key: MOF26-21
  • Legacy Issue Number: 18811
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • 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.

  • Reported: MOF 2.4 — Wed, 10 Jul 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Does MOF::Reflection::Object own "invoke" Operation ?

  • Key: MOF26-3
  • Legacy Issue Number: 19872
  • Status: open  
  • Source: Anonymous
  • 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 http://www.omg.org/spec/MOF/20131001/MOF.xmi file for MOF::Reflection::Object :

    <packagedElement xmi:type="uml:Class" name="Object" xmi:id="_MOF-Reflection-Object">
    ...
    <ownedOperation xmi:type="uml:Operation" name="invoke" visibility="public" xmi:id="_MOF-Reflection-Object-invoke">
    ...
    </ownedOperation>

    Moreover it uses <type xmi:idref="_MOF-CMOFReflection-Argument"/> from CMOF.

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Sentence fragment duplication

  • Key: MOF26-2
  • Legacy Issue Number: 19871
  • Status: open  
  • Source: Anonymous
  • 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.

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-4
  • Legacy Issue Number: 19861
  • Status: open  
  • Source: Anonymous
  • Summary:

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

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-5
  • Legacy Issue Number: 19860
  • Status: open  
  • Source: Anonymous
  • Summary:

    The example given for transformation, i.e., "transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {" is lack of a right brace.

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

The text is not clear

  • Key: MOF26-6
  • Legacy Issue Number: 19759
  • Status: open  
  • Source: UFES ( Halysson Freitas)
  • 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.

  • Reported: MOF 2.4.1 — Sat, 16 May 2015 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF does not have the correct semantics for links in the presence of association specialization

  • Key: MOF26-13
  • Legacy Issue Number: 16270
  • Status: open  
  • Source: Anonymous
  • 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.

  • Reported: MOF 2.4 — Thu, 26 May 2011 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3.

  • Key: MOF26-7
  • Legacy Issue Number: 17632
  • Status: open  
  • Source: Anonymous
  • 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.

  • Reported: MOF 2.4 — Mon, 24 Sep 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 9.2 constraints

  • Key: MOF26-8
  • Legacy Issue Number: 17395
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • 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

  • Reported: MOF 2.4 — Thu, 24 May 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

URIExtent should provide the capability of accessing links as well as elements by URI

  • Key: MOF26-11
  • Legacy Issue Number: 17276
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • 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.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is an inconsistency in the current spec between link equality and link delete

  • Key: MOF26-9
  • Legacy Issue Number: 17275
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • 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.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

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

  • Key: MOF26-10
  • Legacy Issue Number: 17274
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

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

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

as root Model element ?

  • Key: MOF26-1
  • Legacy Issue Number: 19873
  • Status: open  
  • Source: Anonymous
  • Summary:

    The file http://www.omg.org/spec/MOF/20131001/MOF.xmi starts with:

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <packagedElement xmi:type="uml:Package" xmi:id="_MOF" name="MOF">
    ...

    Is it correct to have <packagedElement> as root Model element ?

    Why isn't it :

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <uml:Package xmi:id="_MOF" name="MOF">
    ...

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT