Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Open Issues

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

Issues Descriptions

Key Qualifiers Missing in MOF

  • Key: MOF26-18
  • Legacy Issue Number: 8695
  • Status: open  
  • Source: SAP SE ( Axel Uhl)
  • 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.

  • Reported: MOF 1.4 — Mon, 11 Apr 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF 2.0 Core: Exceptions missing for CMOF Reflective operations

  • Key: MOF26-19
  • Legacy Issue Number: 8268
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MOF 1.4 — Fri, 11 Feb 2005 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

CMOF should not itnore visibilities

  • Key: MOF26-16
  • Legacy Issue Number: 8997
  • Status: open  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • 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.

  • Reported: MOF 1.4 — Mon, 19 Sep 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

"exposedEnd" for any of the references in the MOF metamodel.

  • Key: MOF14-35
  • Legacy Issue Number: 4798
  • Status: open  
  • Source: Anonymous
  • Summary:

    If Attribute.isDerived was moved up to StructuralFeature, then you could model derived references. An example of such a derived reference in the MOF meta-model is Reference.exposedEnd, which is equivalent to ref.referencedEnd.otherEnd().

    Relatedly, the copy of ptc/2001-10-05 found on the RTF website doesn't include the "exposedEnd" for any of the references in the MOF metamodel.

  • Reported: MOF 1.4 — Fri, 21 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Generalization Proposal

  • Key: MOF14-34
  • Legacy Issue Number: 4720
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Here is a detailed proposal for adding association generalization to MOF
    1.5. This proposal does not address reference redefinition or overriding.
    I hope this proposal provides sufficient detail so that Steve Crawley can
    make changes to the specification. Please send your comments.

    Regards,
    Don

    Changes to Model

    Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]
    AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.

    Add a nonabstract association from AssociationEnd to AssociationEnd called
    RedefinesEnd. One end is called redefinedEnd, has a reference by the same
    name, and has multiplicity *. The other end is called redefiningEnd, has no
    reference, and has multiplicity *. This association is used to correlate an
    end with its corresponding end in a supertype association.

    Add new constraint: SupertypeEndsAreRedefined
    Evaluation policy: Deferred.
    Description: An end redefines each supertype's end.
    Context Association
    Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->
    forAll(ge : AssociationEnd |
    self.contents->select(sc |
    sc.oclIsTypeOf(AssociationEnd))->
    forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =
    ge)
    and se.otherEnd.redefinedEnd->exists(ore | ore =
    ge.otherEnd)))

    Add new constraint: RedefinedEndBelongsToSupertype
    Evaluation policy: Immediate.
    Description: Each redefinedEnd belongs to a supertype.
    Context AssociationEnd
    Inv: self.container.oclAsType(Association).supertypes.contents->
    includesAll(self.redefinedEnd)

    By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an
    immediate constraint, but it should be deferred. Otherwise, there is no
    valid way to create an Association.

    Changes to Abstract Mapping

    Add the following to Core Association Semantics.

    A link cannot be directly created for an Association with isAbstract set to
    true, but can be added indirectly as a link of a subtype association.

    Where a generalization exists between two associations, each link of the
    subtype association is logically a link of the supertype association - for
    each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or
    <b, a> depending on which subtype end redefines which supertype end).

    Removing a link from a Link_Set causes the logical link to be removed from
    each subtype association's Link_Set. Removing a link from a Link_Set also
    causes the logical link to be removed from each supertype association's
    Link_Set where the logical link is not otherwise present in the supertype
    Link_Set based on either having been put explicitly into the supertype
    Link_Set (where not abstract) or on being a link of some other subtype of
    the supertype. The net effect is that a Link_Set is a union of links put
    explicitly into the Link_Set with the Link_Sets of all subtypes.

    Changes to IDL Mapping

    In the template for associations, no add or modify operations are generated
    for an abstract association.

    In the template for references, no set, add, or modify operations are
    generated for an abstract association.

    Operations on RefObject for setting, adding, and modifying, and operations
    on RefAssociation for adding and modifying raise a new MofError, "Abstract
    Association", for creating a link of an abstract association.

    Changes to JMI

    In the template for associations, no add operation is generated for an
    abstract association.

    In the template for references, no set operation is generated for an
    abstract association. Also, the add and set operations on a reference
    collection throws a new JmiException, "AbstractAssociation", for an abstract
    association.

    For the reflective JMI interfaces, JmiException "AbstractAssociation" is
    thrown for refAddLink on an abstract association and for refSetValue on a
    reference on an abstract association.

  • Reported: MOF 1.4 — Fri, 30 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary constraint on import by nested packages

  • Key: MOF14-33
  • Legacy Issue Number: 4715
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 2.3.6.2 and Constraint [C-48] prevent a nested package from
    importing from anything else. This seems unnecessarily restrictive and makes
    the use practical of nested packages unlikely.

  • Reported: MOF 1.4 — Tue, 27 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong

  • Key: MOF14-31
  • Legacy Issue Number: 4664
  • Status: open  
  • Source: Anonymous
  • Summary:

    in section 5.8.12 "Reference Template", 1st para, it is stated: "The IDL generated for a Reference is declared within the scope of <ClassName>CLASS interface definition.", while the next para says: "The Reference Template defines the IDL generation rules for References. It declares operations on the INSTANCE interface to query and update links in the Association object for the current extent."

    I think, that all reference related IDL operations should go into the Instance interface, and not into the class proxy interface. This view is also compliant with 5.8.8 "Instance Template", that para states explicitly that the reference template is to be applied in the context of the instance template.

    Proposed Resolution:
    ====================
    Change the 1st para of 5.8.12 to "The IDL generated for a Reference is declared within the scope of <ClassName> interface definition.

  • Reported: MOF 1.4 — Tue, 6 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions needed for nested Packages and Classes

  • Key: MOF14-30
  • Legacy Issue Number: 4622
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In recent MOF RTF telcon discussions, we tentatively concluded that we need
    Constraints on the MOF Model to forbid 1) clustering of nested Packages,
    2) inheritance of nested Packages and 3) clustering of Classes.

    Additional Text:

    There are three arguments for the proposed restrictions. The first
    argument is that supporting inheritance / clustering in these cases adds
    to the complexity of MOF implementations. Since practical metamodels
    never seem to use these combinations of features, it is hard justify
    supporting them.

    The second argument is that clustering and inheritance of nested
    Packages is problematical. The elements of a nested Package are
    implicitly defined in the context of the nested Package's outer Package.
    A Constraint or Operation defined on / within a nested Package may
    reasonably refer to Associations or "all_of_*" collections in the
    enclosing context. When a nested Package is inherited or clustered
    outside of the context of its parent Package, the Constraint and
    Operation semantics may cease to be meaningful.

    The second argument does not apply to a nested Package that is
    inherited by another nested Package with the same outermost Package.
    However, we have not been able to identify a use case for this sort
    of thing. Hence the first argument applies.

    The third argument is that the MOF IDL mapping explicitly excludes all
    of these cases; see "Section 5.5 - Preconditions for IDL Generation".

  • Reported: MOF 1.4 — Thu, 18 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Looking up metaobject using MOFID

  • Key: MOF14-28
  • Legacy Issue Number: 4609
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    MOF should have a support for looking up metaobjects by MOFIDs (e.g. by adding getObjectByMOFID method to RefPackage interface).

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolveQualifiedName operation

  • Key: MOF14-27
  • Legacy Issue Number: 4607
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    I think it would be much more convenient to have resolveQualifiedName as a
    "classifier_level" operation on ModelElement instead of "instance_level"
    operation on Namespace. Now each time I want to resolve some object using
    its qualified name, I have to find all outermost packages (which is quite
    slow, because currently there is no better way of doing it than just iterate
    through all package instances and check whether they are outermost), then
    choose a package with a specified name and call resolveQualifiedName on that
    package passing rest of the qualified name as a parameter. This is much more
    complicated for users than it should be.

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecate object inheritance of class proxy interface

  • Key: MOF14-25
  • Legacy Issue Number: 4593
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF should deprecate the use of factory/finder operations on object
    instances (i.e. the fact that generated instances inherit not only from
    their model superclass but from their class proxy). The main reason for this
    is that it does not separate concerns (why should an instance know about
    creating other instances or finding the population of the class?) and is not
    consistent with JMI.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment of reflective interfaces with JMI

  • Key: MOF14-24
  • Legacy Issue Number: 4592
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF should consider aligning its reflective interfaces with JMI
    (specifically split some of RefObject into RefClass and common superclass
    RefFeatured). As well as the benefit of consistency it makes the interfaces
    more intuitive/comprehensible and typesafe.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigability of assoc. ends in MOF model

  • Key: MOF14-29
  • Legacy Issue Number: 4621
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    When I was looking at the current MOF 1.4 spec I could not find a place
    where is specified, which assoc. ends are navigable and which are not.
    There is an inconsistency between the UML picture of MOF metamodel and XMI
    (and IDL). Where the picture indicates that some ends (like
    RefersTo.referent) are not navigable, XMI says that they are navigable and
    also IDL contains getter method for these ends. So I guess the picture is
    wrong. This should be fixed, because it is in fact the only place where the
    users of the spec can see the navigability without looking at the
    hard-to-read XML file or generated IDL. It would be also helpful to add this
    also to the description of particular associations in section 3.5.

  • Reported: MOF 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove obsolete material

  • Key: MOF14-26
  • Legacy Issue Number: 4594
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The document needs a big revamp - e.g. a lot of the ancient pre-UML intro
    stuff. We
    should bear in mind that a lot of people will be coming to the spec/OMG
    cold as a result of JMI takeup and we should make the document as clean,
    lean
    and approachable as we can.
    It will be at least a year before MOF 2.0 reaches a stable/official state so
    I feel we should not wait.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tracking identity of replicated / interchanged metadata

  • Key: MOF14-23
  • Legacy Issue Number: 4586
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When metadata is copied from one repository to another, or saved as an
    XMI document, it can be necessary to know if the physically distinct
    copies of the metadata are logically the same or logically different.
    There need to be mechanisms for testing whether copies are logically the
    same or different that work in all cases, not just within the context of
    a single repository.

  • Reported: MOF 1.4 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity be optional for non-navigable association ends.

  • Key: MOF14-32
  • Legacy Issue Number: 4700
  • Status: open  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    If an association end is not navigable, specification of its
    Multiplicity should not be required. There is no practical use for this
    information and it does not make sense to require information that is not
    used.

    Proposed Resolution: Make Multiplicity optional in the MOF model.

  • Reported: MOF 1.4 — Mon, 12 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof-rtf issue: Association Generalization

  • Key: MOF14-22
  • Legacy Issue Number: 4584
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The MOF model should allow generalization of associations. It is often
    useful to have a more general root association and create several
    specializations for it (e.g. dependency and several kinds of dependencies as
    its subclasses).

  • Reported: MOF 1.4 — Mon, 1 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modeling OCL Helper Functions

  • Key: MOF14-21
  • Legacy Issue Number: 4569
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL).

    There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine.

    This applies not only to MOF but to other metamodels.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of constraints

  • Key: MOF14-20
  • Legacy Issue Number: 4568
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3].

    The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT