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

The Metadata architecture needs to move away from the 4 levels and labels

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

    The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'.

  • Reported: MOF 1.3 — Fri, 8 Dec 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the MOF / XMI interchange format

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

    The MOF spec standardises an XMI-generated interchange format for MOF
    meta-models. The MOF spec includes the "input" MOF meta-model for the
    Model. It should also include a formal statement of the other XMI
    "parameters" used to generate the meta-model interchange format.

  • Reported: MOF 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete all non-MOF-specific terms from the Glossary

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

    Delete all non-MOF-specific terms from the Glossary. People have trouble enough with MOF terms and it's sensible to have one place to collect them all, without clogging them up with a load of irrelevant UML terms (e.g. action sequence). Plus it create a management issue of having to keep up with UML (which it has failed to already - not even including something as fundamental as 'Profile').

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add 'semantics' attribute to Operation.

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

    At the moment MOF has no way to describe the behavior of an operation. A new attribute, 'semantics', String (0..1) should be added to Operation. A more sophisticated alternative would be to include a 'language' attribute also, as for Constraint. This would be somewhat restrictive in permitting only one coding of the semantics (e.g. not both OCL and Java). Better would be to use just one multivalued attribute of type StructuredDataType 'Expression'. This would be as in UML and have StructureFields 'language' (String 0..1) and 'body' (String 1..1). It begs the question as to whether this datatype should then be used in Constraint instead of the current 'language' and 'expression' attributes.

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The current MOF package level import is not sufficient

  • Key: MOF14-16
  • Legacy Issue Number: 4383
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current MOF package level import is not sufficient. For instance, if a
    user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can
    only indicate "Datatypes" in MOF now. What is needed is that the user can
    say "Datatypes::Boolean" as a dependency. It would be counter-productive to
    create 12 subpackages of Datatypes and put each datatype in its own Package,
    just because it would let people reuse individual datatypes (without
    changing the MOF import rule).

  • Reported: MOF 1.3 — Wed, 20 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF-RTF issue: AttachesTo.modelElement - ordered

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

    The modelElement end of AttachesTo association should be ordered. It does
    make sense to have one tag attached to several model elements in a specified
    order. (E.g. tag decorating a set of class attributes which create a unique
    identifier of instances of this class)

  • Reported: MOF 1.3 — Wed, 11 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The role name of the Namespace->ModelElement association end

  • Key: MOF14-13
  • Legacy Issue Number: 4238
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Title: The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

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

role is named 'containedElement' while the reference is named 'contents'

  • Key: MOF14-12
  • Legacy Issue Number: 4232
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

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

predefined tag for marking attributes to act as qualifier in classifier

  • Key: MOF14-11
  • Legacy Issue Number: 4231
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need a predefined tag for marking attributes that will 'act as a
    qualifier' in a classifier.
    In a metamodelling tool it may be useful to derive automatically an object
    identifier from one
    or more relevant attributes of the classifier (for instance a 'name'
    attribute).
    Note: The attribute 'acting as a qualifier' is owned by the classifier not
    by an association.
    Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to
    any attribute
    of a classifier.

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

Disallow null instance values

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

    It can be argued that there is no need to allow null as a valid value
    for a Class instance. The possibility of null means that mapped APIs
    need to be more complicated; e.g. the IDL "unset_*" operations. This
    issue proposes that 'null' should be disallowed, making Class instances
    consistent with DataType instances. The IDL mapping could also be
    simplified.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF IDL rules to minimize network roundtrips

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

    Various people have complained that retrieving meta-data (typically
    features of Classes) using the IDL produced by the MOF IDL mapping
    involves too many round-trips. This is preventing people from using
    MOF generated IDL in projects. This issue calls for a solution (or
    solutions) to this problem.

  • Reported: MOF 1.3 — Fri, 6 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Why prevent nonpublic Associations?

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

    In the MOF 1.3 Specification, constraint C-37 requires Associations to be
    public. Support for nonpublic Associations is a valuable capability that
    should not be forbidden. In particular, when there are references on all
    navigable ends of an Association, the M1 Association object is fully
    redundant in the capabilities it provides. Making the Association private
    or protected eliminates the need to support redundant public interfaces for
    capabilities available most conveniently through references. The
    association is an important part of the model in that it defines the
    semantics and behavior of the references, but no public Association
    interface is needed. The IDL and other interfaces generated from metamodels
    is already too large. Constraint C-37 simply makes it larger than it needs
    to be.

    Note that the CWM submitters to OMG desire to use nonpublic associations
    extensively in CWM's 26 metamodels.

    Recommendation: Delete C-37.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 IDL template for clustering uses wrong name

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

    In the MOF 1.3 specification, section 5.8.4, the use of
    "<clustered_package_name>_ref" (both in the template and as a subheading) is
    incorrect. It should be "<import_name>_ref". The Import name provides the
    alias for a clustered package within a clustering package. The Package name
    is used to identify the type of the M1 package object, not the IDL attribute
    name.

    Recommendation: change "<clustered_package_name>_ref" to
    "<import_name>_ref".

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Template should suppress add for [x..x] Attributes

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

    The Attribute template suppresses the "remove" operations for multi-valued
    Attributes whose lower and upper bounds are the same. [This makes sense
    because removing an element would always trigger an underflow error.] However,
    similar logic has not been applied to the "add" operation. We should consider
    suppressing "add" operations for multi-valued Attributes whose lower and upper
    bounds are the same, since the operation must always trigger an overflow error
    in this case.

  • Reported: MOF 1.3 — Mon, 13 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF and IDL repository ids

  • Key: MOF14-1
  • Legacy Issue Number: 3043
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The AB is insisting that altered IDL types (including types that reference
    > altered IDL types) be versioned by specifying a new repository id. This
    > presents special issues for generated IDL when a source model is revised
    > and the IDL regenerated.
    >
    > Recommendation
    >
    > For generated IDL the safest thing is probably to generate a new UUID-based
    > repository id for all generated IDL interfaces and generated IDL structs,
    > valuetypes, etc.

  • Reported: MOF 1.3 — Sat, 20 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reflective interface for Package factory

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

    There is no reflective version of the Package factory interface. In
    retrospect, an abstract interface would be useful for generic package
    creation using Package specific factory objects, and a concrete interface
    would be useful for a "universal" Package factory object.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor changes to some Reflective operations

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

    The RefAssociation ops that are parameterised by Link would be easier to
    use if parameterized by two RefObjects. The RefObject ops for
    add/modify/removing
    ele,emts of Attribute/Reference collections should be renamed; i.e. add_value
    becomes add_member. Other minor tweaks would make the interfaces easier to
    use.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF specifies no interfaces for actually (de-)serializing a model

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

    MOF specifies no interfaces for actually (de-)serializing a model (to, for example, a XMI stream). Without such an interface it is not possible to guarantee that 2 XMI tools/repositories can communicate with each other, regardless of how completely they support MOF/XMI. Since the OMG is meant to be about interoperability this is a critical omission.
    It would make sense for MOF to make use of the Streamable interface defined as part of the Externalization service.
    And for the capability to be defined against Namespace to allow reasonable flexibility of granularity.
    Obviously XMI is only one possible format for the stream: the XMI specification should also be extended to fit into the detailed specification adopted for streaming MOF-compliant metamodels.

  • Reported: MOF 1.3 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Package should subtype Classifier

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

    In the MOF 1.3 Specification, a Package is not a subtype of Classifier. But
    an M2 package does have M1 instances (package extent objects), and the M2
    Package defines the type of those M1 objects. Therefore, a Package really
    is a Classifier. It is a type. It can be thought of as a component type,
    and in that sense a Package should be able to contain behavioral features.
    Also, an attribute type that is a Package should be treated as a pointer to
    a package extent object.

    Recommendation: make Package a subtype of Classifier, or fold Classifier
    into GeneralizableElement.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT