Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Closed Issues

  • Acronym: MOF
  • Issues Count: 4
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

the return type of the remove() operation is inconsistent with the description

  • Key: MOF24-165
  • Legacy Issue Number: 18808
  • Status: closed  
  • Source: gmail.com ( Xavier Courangon)
  • 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.

  • Reported: MOF 2.4.1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Agreed. Correct the operation signature to return Boolean

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Semantics and ownership of link slots needs clarification

  • Key: MOF24-78
  • Legacy Issue Number: 17169
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • 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?

  • Reported: MOF 2.4.1 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    LinkSlots are owned by the AssociationInstance. Update diagram 15-1 to show this
    correctly.

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Invalid restrictions on concrete metaclasses allowed in EMOF and CMOF

  • Key: MOF24-77
  • Legacy Issue Number: 17049
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • 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

  • Reported: MOF 2.4.1 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Accept the proposal

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Absence of definitions of "XMI" and "MOF"

  • Key: MOF24-58
  • Legacy Issue Number: 19198
  • Status: closed  
  • Source: Object Management Group ( Claude Baudoin)
  • Summary:

    The document, which is about a mapping of MOF to XMI, does not define the initialisms MOF or XMI anywhere in the documents, either in Chapter 1 (Scope) or in a glossary, which does not exist in this document.

    Chapter 1 starts with "XMI is a widely used interchange format..." and ends with "MOF is the foundation technology for describing metamodels..." but there is no mention of what the terms actually stand for, a significant omission in a formal document.

    One may also question the use of "MOF 2 XMI" in the title. While "MOF2XMI" may be a common way to create a meta-abbreviation for a relationship between two concepts denoted by abbreviations, there is little justification to eschew the grammatically correct "MOF-to-XMI Mapping" (with hyphens or spaces) in the document title. Using the numeral "2" is actually ambiguous – does it mean "to" or does it refer to a version 2 of MOF?

    Overall, this issue is more about casual editing than about correctness, but I believe it makes the specification weaker, editorially, than the usual OMG standard of documentation.

  • Reported: MOF 2.4.1 — Tue, 28 Jan 2014 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Make the change as suggested

  • Updated: Fri, 6 Mar 2015 23:16 GMT