Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Open Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
QVT14-25 QVTo : Confusing isVirtual definition for imperative operation calls MOF 1.2 open
QVT14-14 Rationalize title MOF 1.2 open
QVT14-15 Trace Record not suitable for Incremental Execution MOF 1.2 open
QVT14-20 QVTo: What are the operation overloading semantics? MOF 1.2 open
QVT14-18 QVTo: Enhance Status to support access to nested transformation trace data MOF 1.2 open
QVT14-19 QVTo: Eliminate deprecated Typedef class MOF 1.2 open
QVT14-22 QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL MOF 1.2 open
MOF14-81 WG: Attribute accessors and mutators MOF 1.2 open
MOF14-83 mof rtf issue - coverage of RefXXX interfaces by MOF metamodel MOF 1.2 open
MOF14-82 mof rtf issue - setting UUIDs MOF 1.2 open
MOF14-66 Tags that parameterize a meta-model mapping MOF 1.2 open
MOF14-65 What is a UML "profile"? MOF 1.2 open
MOF14-62 MOF RTF Isue: Conflict between "Facility" and "Package Object " MOF 1.2 open
MOF14-61 Generated operations returning attributes/references should not raise Cons MOF 1.2 open
MOF14-64 Semantics of Reference "set" onto an ordered Association. MOF 1.2 open
MOF14-63 ModelElement needs to have permanent, unique, unchanging, identifier MOF 1.2 open
MOF14-78 Provide tools to chapter 5 UML 1.3R9 draft MOF 1.2 open
MOF14-77 Should Reflective.DesignatorType be "string"? MOF 1.2 open
MOF14-80 Do non-public Attributes need initialising? MOF 1.2 open
MOF14-79 IDL for Reflective Package Interfaces can conflict MOF 1.2 open
MOF14-72 Specify the semantics of Constraint verification MOF 1.2 open
MOF14-71 Add appropriate Attribute default values to the MOF Model MOF 1.2 open
MOF14-76 MOF Model IDL versus OMG Style guidelines MOF 1.2 open
MOF14-75 Need for light-weight References MOF 1.2 open
MOF14-74 Add a new technical overview chapter between chapters 2 and 3" MOF 1.2 open
MOF14-73 Freezing mechanism for all models MOF 1.2 open
MOF14-69 Add support for Exception generalization MOF 1.2 open
MOF14-67 Validate the OCL constraints in the MOF specification MOF 1.2 open
MOF14-68 Add support for default values to MofAttribute MOF 1.2 open
MOF14-70 Define a MOF Class that is the supertype of all Classes MOF 1.2 open

Issues Descriptions

QVTo : Confusing isVirtual definition for imperative operation calls

  • Key: QVT14-25
  • Status: open  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The ImperativeCallExp::isVirtual attribute is defined as follows: "Unless isVirtual is true, this invocation is virtual." This is extremely counter-intuitive and apparently stems from a careless renaming. As a result, virtual call semantics are disabled by default, because the default value 'true' implies that an operation is "statically called". The default should be virtual call semantics, so the description should be turned around.

  • Reported: MOF 1.2 — Thu, 11 Feb 2016 13:01 GMT
  • Updated: Wed, 13 Apr 2016 08:20 GMT

Rationalize title

  • Key: QVT14-14
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.

    Two versions numbers are certainly confusing.

    But Isn't the "MOF" redundant too?

  • Reported: MOF 1.2 — Tue, 10 Nov 2015 17:02 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Trace Record not suitable for Incremental Execution

  • Key: QVT14-15
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.

    Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.

    Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.

    This affects all of QVTc, QVTr, and QVTo.

    For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?

  • Reported: MOF 1.2 — Wed, 28 Oct 2015 19:10 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: What are the operation overloading semantics?

  • Key: QVT14-20
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Does QVTo support operation overloading in a similar way to Java?

    How are conflicting contextual operations resolved when access semantics are used for import?

    How are conflicting contextual operations resolved when extension semantics are used for import?

    Is the resolution at run-time different to that at compile-time?

  • Reported: MOF 1.2 — Fri, 23 Oct 2015 09:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Enhance Status to support access to nested transformation trace data

  • Key: QVT14-18
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.

    Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.

    Suggest 2: Add a getTraceData() to Status and 'this'.

    Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.

    NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.

    Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.

  • Reported: MOF 1.2 — Wed, 14 Oct 2015 08:46 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Eliminate deprecated Typedef class


QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL

  • Key: QVT14-22
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.

    It offered a simple textual fix which was exploited to resolve the original issue.

    It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.

    (B) - (Major rework.) Rework the abstract syntax to reuse OCL
    expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may
    contain sub-statements and OCL expressions; OCL expressions
    are reused unchanged from the OCL spec (no imperative
    sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop,
    more details can be found at
    http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

    (Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 17:40 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

WG: Attribute accessors and mutators

  • Key: MOF14-81
  • Legacy Issue Number: 2876
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Should the describe() and modify() operation available be on instance and
    class level interfaces? For class level attributes it is not necessarly
    needed because they probably will not be read and modified very often in a
    group.

    2) The property set should be defined in a value-struct. Which attributes
    should the instance level value-struct contain? class level and instance
    level attributes. I would prefer only to have instance level attributes in
    the instance level modify() and describe() operations because of (hopefully)
    the separation of instance and class level interfaces (no inheritance
    anymore!).

    3) Should the value-struct also contain multi-valued attributes. I would
    prefer, not to include multi-valued attributes in the value-struct because
    of the modify() operation.

    4) How about read-only attributes. If the same value-struct is used for
    describe() and modify(), should the read-only attributes be included in the
    value-struct and ignored in the modify() operation?

    5) To define the value-struct as a NamedValue sequence with the values of
    the type any (as available in the Reflective interface) is not optimal
    because this operation is untyped and requires the use of the any type. The
    value-struct should be typed.

    6) In our work we have defined the value-struct, modify() and describe()
    operations as model-specific operations (this is fully MOF-compliant). This
    allows us to customize the value-struct as needed. However, because probably
    everybody has the same requirements there should be a way in the MOF-spec to
    defined such constructs in a standard way.

  • Reported: MOF 1.2 — Thu, 9 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - coverage of RefXXX interfaces by MOF metamodel

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

    This issue is to ensure that the MOF metamodel contains sufficient information
    to hold information available through the RefObject and related interfaces.
    Examples include the metaObject-instances relationship.

    XMI documents using the MOF DTD should include sufficient information to be used
    as backup/restore and initialization of a MOF-compatible system. The MOF
    interfaces should be complete enough to enable this capability.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - setting UUIDs

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

    The MOF interfaces need to provide an API to set uuids. A convention for
    denoting uuids for metamodel objects defined by OMG standards would be
    beneficial. For example, the uuids of the UML Class, Attribute, and Operation
    constructs could be set following this convention by the UML RTF.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tags that parameterize a meta-model mapping

  • Key: MOF14-66
  • Legacy Issue Number: 2165
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Summary: If we allow Tags to parameterize a meta-model (e.g. IDL) mapping
    as proposed for issue 1307 (for example), there needs to be a reliable
    way for a client of the mapped interfaces to find that Tags that were
    in force. Without this, it cannot reflectively work out what the mapped
    interfaces do.

    Additional text:

  • Reported: MOF 1.2 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is a UML "profile"?

  • Key: MOF14-65
  • Legacy Issue Number: 2046
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The concept of profile may need to be escalated to the MOF level (for
    example as a subset of metadata constructs packaged together with
    appropriate classifiers, tags, constraints etc. -). I agree that
    creating new metamodels for each minor extension is not a tractable
    solution to the problem - especially if it means tool vendor cost of
    supporting it is too much.

  • Reported: MOF 1.2 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF RTF Isue: Conflict between "Facility" and "Package Object "

  • Key: MOF14-62
  • Legacy Issue Number: 1505
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a major conflict between the "Facility" Package
    described in Section 4 and the M1-level object model expressed in
    Section 7. Section 4 defines a concept of a "model repository",
    embodied by the Facility::ModelRepository class, as the boundary for
    M1-level associations and classifier level state. Indeed, this seems
    to be the main purpose of Facility::ModelRepository instances. On the
    other hand, the IDL mapping in Section 7 defines the M1-level
    <package-name>Package interface with the primary purpose of providing
    this boundary. [Section 5 is ambiguous.] This overlap in purpose and
    functionality is causing confusion, and is obscuring the need for
    standardisation of something to provide a container and a directory
    for a set of (possibly unrelated) models and meta-models.

  • Reported: MOF 1.2 — Fri, 5 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generated operations returning attributes/references should not raise Cons

  • Key: MOF14-61
  • Legacy Issue Number: 1082
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The generated IDL for the MOF includes ConstraintError in
    the raises clause of operations generated via the Attribute
    Template and Reference Template, although these templates do
    not include spcification of that exception (identified in a
    separate issue). When that specification is updated, it
    should specify that the generated "read" operations do not
    raise this exception. The current IDL has ConstraintError
    in the raises clause of the following operations, which do
    not change the state of the model:

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Reference "set" onto an ordered Association.

  • Key: MOF14-64
  • Legacy Issue Number: 1804
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The description of the semantics of Reference operations
    in section 6.2.2.1 needs to be extended to cover the multi-value
    update operations; i.e. "set" and "unset" when the referenced
    AssociationEnd is multi-valued. In particular, the semantics when
    either of the AssociationEnds is ordered need to be spelled out.

  • Reported: MOF 1.2 — Thu, 13 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ModelElement needs to have permanent, unique, unchanging, identifier

  • Key: MOF14-63
  • Legacy Issue Number: 1540
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ModelElement needs to have a permanent, unique, unchanging,
    non-redundant (within the transitive closure of a "large" namespace)
    (meta)identifier in addition to or as a replacement for qualifiedName
    as a local (meta)attribute.

  • Reported: MOF 1.2 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide tools to chapter 5 UML 1.3R9 draft

  • Key: MOF14-78
  • Legacy Issue Number: 2449
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I would like to suggest that the UML model interface defined by Chapter 5 of the
    UML1.3R9 draft provide tools the ability to register for notification of changes to the
    model contents in a manner consistent with the Observer pattern.

    This would provide a better mechanism for tool integration around a common
    model respository, allowing each tool in a tool suite containing tools developed
    by different vendors to present its own up to date "view" of the underlying model in
    a simple fashion.

  • Reported: MOF 1.2 — Thu, 11 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Reflective.DesignatorType be "string"?

  • Key: MOF14-77
  • Legacy Issue Number: 2224
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Reflective interfaces currently use object references to
    "designate" the feature (etc) to which a reflective operation applies.
    In practice, I am finding that this is inconvenient for clients of the
    API and potentially difficult for implementations. I suggest that we
    reconsider the alternative; i.e. designating features using CORBA
    strings.

  • Reported: MOF 1.2 — Thu, 19 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do non-public Attributes need initialising?

  • Key: MOF14-80
  • Legacy Issue Number: 2839
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e
    "create_<classname>" operation should have parameters to provide initial
    values for Attributes whose visibility is "protected_vis" or "private_vis".
    The same applies for 5.8.3 for classifier-level Attributes in the Package
    factory interface.

  • Reported: MOF 1.2 — Thu, 12 Aug 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL for Reflective Package Interfaces can conflict

  • Key: MOF14-79
  • Legacy Issue Number: 2527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for the Reflective Package interfaces can conflict with IDL generated according to the MOF Model to IDL mapping rules. For example, when generating IDL for the UML metamodel, the UML class called Instance causes generation of an operation called create_instance which conflicts with the Reflective create_instance. The reflective interfaces should be changed to avoid such conflicts.

  • Reported: MOF 1.2 — Thu, 11 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify the semantics of Constraint verification

  • Key: MOF14-72
  • Legacy Issue Number: 2181
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We need a thorough specification of the semantics of Constraint
    verification. This should cover the following:
    1) What happens; e.g. is the verification allowed to give up on the
    first error?
    2) When evaluation of deferrable Contraints can occur; i.e. where could
    the ConstraintError exceptions be raised?
    3) How evaluation of deferred Constraints is triggered.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add appropriate Attribute default values to the MOF Model

  • Key: MOF14-71
  • Legacy Issue Number: 2179
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Assuming that we add the capability of defining defaults for
    Attributes [see previous issue], there are a number of Attributes in
    the MOF Model that could / should have default values; for example
    "visibility" should default to "public", and "is_root"/"is_leaf" should
    default to "dont_care".

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF Model IDL versus OMG Style guidelines

  • Key: MOF14-76
  • Legacy Issue Number: 2188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that the MOF IDL doesn"t
    conform with the OMG style guidelines and conventions in two
    respects. First, there is no "#pragma prefix "org.omg"" in any of
    the core IDL files. Second, there is a convention that the
    outermost module names for OMG specs have a standard prefix
    depending on its "positioning" in the OMA; e.g. Cos, Cf or
    whatever.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for light-weight References

  • Key: MOF14-75
  • Legacy Issue Number: 2186
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A requirement possibly exists for a light-weight version of
    References (or something like them), which at the M1 level does not
    require the existence of Attribute instance objects and the associated
    heavy weight querying mechanisms.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add a new technical overview chapter between chapters 2 and 3"

  • Key: MOF14-74
  • Legacy Issue Number: 2183
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF specification needs a technical overview before chapter
    3 to help the reader put the details in the rest of the MOF specification
    into a perspective.

    Additional text:

    I am in the process of drafting a possible overview chapter.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Freezing mechanism for all models

  • Key: MOF14-73
  • Legacy Issue Number: 2182
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Model currently has a mechanism for freezing meta-models.
    It is underspecified, but the intent is that under certain conditions you
    can atomically freeze a valid meta-model. This issue proposes that this
    mechanism be re-specified so that it is available for all models.

    Additional text:

    Arguably this is an extension rather than an RTF issue.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for Exception generalization

  • Key: MOF14-69
  • Legacy Issue Number: 2177
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: UML currently supports Exception hierarchies, as do many
    object orient programming languages. MOF"s lack of support for this
    is perceived to be a limitation and an impediment to its use as a
    middleware independent meta-data framework.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validate the OCL constraints in the MOF specification

  • Key: MOF14-67
  • Legacy Issue Number: 2173
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Take steps to validate as much as possible of the OCL in the
    MOF specification. Ideally, they should all be compiled and "executed"
    to ensure that they behave as expected. This should be feasible at least
    for the OCL constraints in the Model package.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for default values to MofAttribute

  • Key: MOF14-68
  • Legacy Issue Number: 2174
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been suggested that Model should be extended to allow
    attributes to specified to have default values. Default values can be
    defined in the MOF Model by adding an attribute of type "any" to
    MofAttribute. [Default expressions are too hard.]

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define a MOF Class that is the supertype of all Classes

  • Key: MOF14-70
  • Legacy Issue Number: 2178
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define a MOF Class that is the supertype of all Classes.
    It could be represented as a single-valued subclass of Model::Class.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT