MOF to IDL Mapping Avatar
  1. OMG Specification

MOF to IDL Mapping — Closed Issues

  • Acronym: MOF2I
  • Issues Count: 14
  • 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

Associations should not be required to be unique

  • Key: MOF2I2-58
  • Legacy Issue Number: 6903
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    I disagree with [7] (in Reflection Factory Constraints) - this is something we had a lot of discussion about
    with Steve and Joaquin and it was agreed that Associations should not be required to be unique.

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    This is an inconsistency since the constraint is not documented as part of restrictions in CMOF or EMOF.

  • Updated: Sun, 8 Mar 2015 22:12 GMT

semantics of Reflection::Object

  • Key: MOF2I2-55
  • Legacy Issue Number: 7453
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    According to page 17, the semantics of Reflection::Object require that all instances of MOF model elements must specialize EMOF::Object. My question is, does this specialization have to be explicit or implicit? That is, if I create a blank MOF Class and ask for its superclasses, will they include EMOF::Object? If I send it a "getMetaClass" message, for example, will it understand it, or do I have to explicitly add EMOF::Object to its superclass property?

  • Reported: MOF2I 1.0 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

object in a useContainment Extent

  • Key: MOF2I2-56
  • Legacy Issue Number: 7454
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    Why is that an object in a useContainment Extent cannot have the extent as its container? (This is stated on page 22 of the Final Adopted Spec

  • Reported: MOF2I 1.0 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF

  • Key: MOF2I2-57
  • Legacy Issue Number: 7548
  • Status: closed  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    The EMOF model should contain a tag on EMOF:Element of XMI ContentType with value "any".

    See the discussion and resolution of MOF 2 XMI FTF issue 6345 for background.

  • Reported: MOF2I 1.0 — Fri, 11 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    Add XMI tag contentType=”any” to Appendix A and in the metamodel.

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Remove allowNull and serializable from EMOF DataType

  • Key: MOF2I2-53
  • Legacy Issue Number: 6908
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    EMOF:

    • DataType.allowNull should be removed
    • DataType.serializable should be removed. What are the use cases for
      it? It seems to me that all the values need to be serializable to allow
      interoperability
  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Correct addAll() input parameter type

  • Key: MOF2I2-54
  • Legacy Issue Number: 6910
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    ReflectiveCollection::addAll should take a ReflectiveCollection, not a ReflectiveSequence

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    change as suggested

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ad-03-04-07/Non-orthogonal additions to UML Core

  • Key: MOF2I2-49
  • Legacy Issue Number: 6494
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The MOF 2 Core specification adds elements to the meta-metamodel that
    are not part of the UML 2 Core. For example, see the sections entitled
    "EMOF Extensions to Basic" and "CMOF Extensions to Core::Constructs." The
    MOF 2 Core's abstract syntax should be a subset of UML. (For detailed
    explanation of why this is advisable, see ad/03-03-30). Note that this
    subset principal allows for MOF to specify orthogonal "mix-in" elements,
    such as packages for reflection and identity.

    Recommendation: Either add the extra elements to the UML 2 Core or else
    remove them from MOF.

  • Reported: MOF2I 1.0 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ReflectiveSequence is not sufficient - add iterator, remove addAll

  • Key: MOF2I2-52
  • Legacy Issue Number: 6907
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    Summary:
    Martin has proposed adding an iterator operation Iterator and removing addAll.
    Iterator would return a ReflectiveIterator that can be used to iterate through all the elements of the collection. If the underlying collection changes while holding an iterator, the behavior of iterator is undefined.

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    AddAll is useful as an atomic operation. There would be limited value in a language independent iterator – it will tend to make for non-optimal language bindings

  • Updated: Sun, 8 Mar 2015 22:09 GMT

No container for tags in tag model

  • Key: MOF2I2-50
  • Legacy Issue Number: 6905
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    Summary:
    The tag model is lacking a container for tags. Why not make tags NamedElements (need to check if that’s
    good enough)?

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ReflectiveSequence is not sufficient, need nulls within a list

  • Key: MOF2I2-51
  • Legacy Issue Number: 6906
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    Summary:
    For interoperability with the XML relational databases, we need to be able to support nulls within a list

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF 2 Issue: Reflexion and Links

  • Key: MOF2I2-46
  • Legacy Issue Number: 5996
  • Status: closed  
  • Source: MEGA International ( Antoine Lonjon)
  • Summary:

    The problem
    -----------

    In the reflexion package of MOF2, the proposal for links assumes that
    AssociationEnds are ordered.
    There is an implicit mapping between firstObject and secondObject roles and
    AssociationEnds is based on this assumption:
    FirstObject maps to the first associationEnd
    SecondObject maps to the second associationEnd

    This leads to the following Operation to create links in the Factory Class:

    createLink(association: Association, firstObject : Object, secondObject :
    Object): Link

    At first glance, this solution provides an easy way to identify the link
    members in parameters of link operations. However, the AssociationEnd is
    difficult to read. It is closer to relational concepts than to
    object/association principles.
    One will always have to guess which is the first or second object.
    The modeler who has created the association might remember the order. But
    the user using the association will probably be lost.

    Example:
    Country:Class - resident:AssociationEnd (First) - Citizenship:Association

    • country:AssociationEnd (Second) - Country:Class

    createLink("Citizenhip": Association, "Thomas": Object : "France" :
    Object)

    Proposal
    --------
    The idea is to benefit from the semantic carried by AssociationEnds
    themselves:
    A link defines members. Each member references a participant object
    according to a role defined by the AssociationEnd.
    Thanks to opposite association of AssociationEnds (aka Property), it is
    possible to identify one end from another. This means that if we create
    links from an AssociationEnd viewpoint, there is no need to order
    AssociationEnd.
    The proposal is to order the creation parameters as follow: sourceObject,
    oppositeRole, oppositeObject.
    Of course, this approach only works for binary associations. But the focus
    of AssociationEnd is the first step to take into account nary associations.

    This also highlight that what matters most in Association semantic is the
    role name of AssociationEnds.
    It is usually much more difficult to have a meaningful name for association.
    This is why we can often see names such as "has for ..." which do not carry
    much information about the association.

    All operations on links are redefined as follow:

    createLink (sourceObject : Object, oppositeRole : Property, oppositeObject :
    Object)
    Example:
    createLink("Thomas:Object","country:Role","France:Object")
    equivalent to:
    createLink("France:Object","resident:Role","Thomas:Object")

    linkedObjects (sourceObject : Object, oppositeRole : Property) :
    Object[0..*]

    LinkExists (sourceObject : Object, oppositeRole : Property, oppositeObject :
    Object) : Boolean

    Proposal Comments
    -----------------
    A better proposal would not use the opposite role but the role attached to
    the object participation to the association.

    createLink("resident:Property","Thomas:Object","France:Object")

    But experience shows that this is two much unsual for modelers. This would
    however be the right path for the introduction of nary associations.

  • Reported: MOF2I 1.0 — Fri, 11 Jul 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF 2.0 Core 03-04-07, Chapter 5. Identifiers

  • Key: MOF2I2-47
  • Legacy Issue Number: 6390
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    On page 36:

    “Identity extends Basic::Property with the ability to designate a property as an identifier for the containing object. Properties: isID: Boolean [0..1] True indicates this property can be used to uniquely identify an instance of the containing Class. Only one Property in a class may have isID==true.”

    The restriction that only one Property in a class may have isID==true is debilitating. It is common for objects to be identified in the modeled application domain by a unique combination of a set of properties. For example, an object that represents an instance of an n-ary association in the modeled domain will, in general, be identified by a unique combination of n properties, each one of which is an identifier of a participating object in the association. Not being able to carry this natural condition into the MOF requires practitioners to devise a work-around, such as introducing a superfluous surrogate identifier, to be able to externally identify such objects.

    It is requested that the MOF 2.0 Core specification be revised by the FTF to allow any number of sets of properties to be identifiers. Any client of an object needs to be able to select the identifier set most convenient for them, and different clients need to be able to accurately identify the object, regardless of how other clients may find it.

    This issue is important to the Business Semantics of Business Rules submissions, which require domain identifiers for objects. Other MOF users will also benefit.

    Introduction of the Identity package is a potentially powerful and badly needed improvement over MOF 1.x to enable the use of external identifiers for MOF objects, which will greatly facilitate accurate model interchange, reuse, aggregation, and transformation. The present limitation stunts this potential. Please take this modest extra step to assure the full potential of the Identity package can be realized.

  • Reported: MOF2I 1.0 — Fri, 24 Oct 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Navigating metalevels/instance relationships

  • Key: MOF2I2-45
  • Legacy Issue Number: 5948
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    Hi, this question from Mike Lawley @ DSTC (I have CC'd him),
    >
    > How does one navigate metalevels in MOF2? "Object" has the operation
    > "getMetaClass(): Class", but how can I explicitly model (via
    > a reference/
    > association) that MyObj is an instance of MyClass.
    >
    > Note, I can see exactly how to do this in CMOF for Links –
    > there is an "instance" association between Link and
    > Association in Fig 8-8.
    >
    > Incidentally, is this list the right forum for questions
    > about the submission, or should it be addressed to a mof-rtf
    > list or similar?

  • Reported: MOF2I 1.0 — Tue, 10 Jun 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF should include Profile package

  • Key: MOF2I2-48
  • Legacy Issue Number: 6408
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The Infrastructure library contains a Core model package and a Profile package.
    The former is reused in MOG, but the latter is not part of MOF.
    This means that MOF QVT submissions cannot build on the Profiles concept for marking (meta) models and they cannot define mappings for profiled meta models.
    MDA style mappings from PIM to PSM or between PSMs requires support for mapping between profiled models in many UML modeling tools that implement PSMs as profiles.
    If MOF QVT cannot deal with mappings to and between profiled models, these tools will require another solution.

  • Reported: MOF2I 1.0 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT