MOF to IDL Mapping Avatar
  1. OMG Specification

MOF to IDL Mapping — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF2I2-58 Associations should not be required to be unique MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-57 Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-56 object in a useContainment Extent MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-55 semantics of Reflection::Object MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-54 Correct addAll() input parameter type MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-53 Remove allowNull and serializable from EMOF DataType MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-52 ReflectiveSequence is not sufficient - add iterator, remove addAll MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-49 ad-03-04-07/Non-orthogonal additions to UML Core MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-51 ReflectiveSequence is not sufficient, need nulls within a list MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-50 No container for tags in tag model MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-47 MOF 2.0 Core 03-04-07, Chapter 5. Identifiers MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-46 MOF 2 Issue: Reflexion and Links MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-45 Navigating metalevels/instance relationships MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-48 MOF should include Profile package MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-44 removing section 12.3 EMOF Merged Model ? MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-43 Question on M-Levels MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-42 Translation between EMOF and CMOF in MOF 2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-41 names of the factory create operations MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-39 Editorial issue(s) MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-40 Resolution of issue 9154 does not work for primitives MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-35 Semantic of reflective operations should match MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-34 Align reflective argument passing in EMOF to CMOF MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-38 Mapping of subsetted properties do not need to change name of operation MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-37 Align mapping of tags to MOF2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-36 "set" operation for derived attributes MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-33 RefObject::ref_get (PropertyName) specified on page 67 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-32 Align Base-IDL Reflection Mapping to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-31 Align CCM Reflection Mapping to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-30 RefCCMBaseObject and RefBaseObject MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-29 Clarify the Extents concept in the mapping MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-28 Rule (50) is not applied in example (12). MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-27 Some referenced sections do not exist MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-26 Numbering and references to examples are not consistent MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-23 Remove the Common suffix from the interface names in the common mapping MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-25 Example 4 is not totally consistent with rules (35) and (36). MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-24 Align Handling of Collections to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-20 Subsection 6.2.1 (Mapping of Identifiers) should be independent of MOF1.4 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-19 Not all assumptions of MOF2.0 Core do hold MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-22 Align MOFObject to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-21 specification should throughout be discretely divided into EMOF and CMOF MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-18 References to other specification documents are not up to date MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-17 CMOF::Exception class is no longer in MOF2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-16 Remove FTF comments MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-15 factory create_ (); MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-14 Rule (38) p. 30 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-8 Rule (38): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-10 Rule (26) p. 21 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-9 Rule (35): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-13 Section 7.4 pp. 49,50 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-12 Section 7.6.3 pp. 59,60 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-11 Rule (27) p. 21 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-7 Section 7.4; MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-6 Section 7.6.3 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-3 Section: 8.2.2;8.2.6 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-5 Rule (27) MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-4 Rule (26): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-2 section 6.3.3, p.31, example IDL MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-1 section 7.3, p.44, example IDL MOF2I 2.0b1 MOF2I 2.0 Resolved closed

Issues Descriptions

Associations should not be required to be unique

  • Key: MOF2I2-58
  • Legacy Issue Number: 6903
  • Status: closed  
  • Source: Adaptive ( Mr. 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

Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF

  • Key: MOF2I2-57
  • Legacy Issue Number: 7548
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • 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

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

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

Correct addAll() input parameter type

  • Key: MOF2I2-54
  • Legacy Issue Number: 6910
  • Status: closed  
  • Source: Adaptive ( Mr. 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

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

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

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, 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

No container for tags in tag model

  • Key: MOF2I2-50
  • Legacy Issue Number: 6905
  • Status: closed  
  • Source: Adaptive ( Mr. 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

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

MOF 2 Issue: Reflexion and Links

  • Key: MOF2I2-46
  • Legacy Issue Number: 5996
  • Status: closed  
  • Source: MEGA International ( Mr. 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

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

removing section 12.3 EMOF Merged Model ?

  • Key: MOF2I2-44
  • Legacy Issue Number: 7957
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Issue 6494 resolution calls for removing section 12.3 EMOF Merged Model. Removing this section would require readers to understand and mentally perform a package merge in order to see the complete EMOF model. It would also make it necessary for EMOF implementers to have an implementation of Constructs and package merge in order to implement EMOF. Retaining section 12.3 provide all the information required to fully understand and implement EMOF without requiring the reader or implementer to know anything about package merge.

  • Reported: MOF2I 2.0b1 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Question on M-Levels

  • Key: MOF2I2-43
  • Legacy Issue Number: 7749
  • Status: closed  
  • Source: SAP SE ( Axel Uhl)
  • Summary:

    section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF.

    Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate.

    However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object.

    The sentence from 7.2 suggests that I can have the following:

    myDog.getClass() == Dog
    Dog.getClass() == UML::Class
    UML::Class.getClass() == MOF::Class

    However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance.

    Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance.

    Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above.

    Any ideas?

  • Reported: MOF2I 2.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Translation between EMOF and CMOF in MOF 2.0

  • Key: MOF2I2-42
  • Legacy Issue Number: 7647
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the "Meta Object Facility (MOF) 2.0 Core Specification"
    document ptc/03-10-04. In the section about EMOF, there is the statement
    "The value of Essential MOF is that it provides a straightforward
    framework for mapping MOF models to
    implementations such as JMI and XMI for simple metamodels." From that
    statement, I inferred that the reason that EMOF exists is largely to
    define XMI 2.0 and (hypothetically) JMI 2.0. In particular, it seemed
    from reading the EMOF introduction that the XMI 2.0 and JMI 2.0
    specifications would depend only on EMOF (and NOT depend on CMOF).

    However, when I read the XMI 2.0 spec., it specifically provides
    mappings for features in CMOF that aren't in EMOF, so
    implementing/understanding EMOF is not enough to implement/understand
    XMI 2.0. There is no JMI 2.0 specification yet, but it seems likely that
    the case would be the same as with XMI 2.0. Therefore, it is not clear
    to me what the purpose of EMOF is. When is using EMOF more appropriate
    than using CMOF?

    Are there any examples of complete EMOF models? In particular, does
    anybody have the EMOF model defined as an instance of itself, as an XMI
    document? I could only find the EMOF model defined as an instance of
    CMOF. And finally, is it possible to represent the (merged) CMOF model
    as an instance of the EMOF model (useful for bootstrapping)?

    Finally, is there a well-defined mapping between EMOF and CMOF? That is,
    how can I convert an instance of the EMOF model to an instance of the
    CMOF model, and vice versa?

  • Reported: MOF2I 2.0b1 — Fri, 13 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

names of the factory create operations

  • Key: MOF2I2-41
  • Legacy Issue Number: 9161
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The names of the factory create operations for home interfaces in subsection 7.5.2.2 are not consistent with rules (35) and (36). Rules (35) and (36) state that the name of the factory create operations end with format_2 (<class identifier>).

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:08 GMT

Editorial issue(s)

  • Key: MOF2I2-39
  • Legacy Issue Number: 9170
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The grammatical errors in the document should be corrected. Also review comments were taken into account and can now be deleted from the final document.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Resolution of issue 9154 does not work for primitives

  • Key: MOF2I2-40
  • Legacy Issue Number: 9175
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The resolution of issue 9154 cannot work for primitive types, since all of
    the operations in the reflective interfaces are typed to MOFObject (and
    primitive types are no MOFObjects).

    Discussion:
    This problem was already known and mentioned by Pete Rivett during the
    ballot 2 vote. However - unfortunately - the wrong text went into the
    resolution due to a misunderstanding. This resolution resolves this bug,
    which otherwise would definitely restrict the implementability of the spec.

  • Reported: MOF2I 2.0b1 — Thu, 24 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Semantic of reflective operations should match MOF2.0 Core

  • Key: MOF2I2-35
  • Legacy Issue Number: 9166
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Most of the reflective operations as well as the derived operations in section 7.6 need to refer to the computational semantic defined in MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align reflective argument passing in EMOF to CMOF

  • Key: MOF2I2-34
  • Legacy Issue Number: 9165
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Just as in CMOF, a RefArgument class should be introduced in EMOF in order to handle reflective argument passing the better way.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Mapping of subsetted properties do not need to change name of operation

  • Key: MOF2I2-38
  • Legacy Issue Number: 9169
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The mapping of subsetted properties does not have to change the name of the generated operations for this property. Only the implemented semantic should changed and reflect that of MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align mapping of tags to MOF2.0

  • Key: MOF2I2-37
  • Legacy Issue Number: 9168
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The mapping of tags should state explicitly where the information modeled in a tag lands in the mapped IDL

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

"set" operation for derived attributes

  • Key: MOF2I2-36
  • Legacy Issue Number: 9167
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    This issue is a follow up of issue 7591. For UML2 compliance, a "set" operation is needed for derived attributes.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

RefObject::ref_get (PropertyName) specified on page 67

  • Key: MOF2I2-33
  • Legacy Issue Number: 9164
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Title: Arguments to ref_get, ref_set and ref_is_set operations do not match with MOF2.0 Reflection specification.
    Source:
    Michael Soden, soden@ikv.de
    Summary:
    The RefObject::ref_get (PropertyName) specified on page 67 does not conform to the get(Property) defined in MOF2.0 Reflection.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align Base-IDL Reflection Mapping to MOF2.0 Core

  • Key: MOF2I2-32
  • Legacy Issue Number: 9163
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Rule (46) states that a factory interface is created for each package. A factory should be created only for the root package, just as home interfaces are created only for root package components.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align CCM Reflection Mapping to MOF2.0 Core

  • Key: MOF2I2-31
  • Legacy Issue Number: 9162
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    I suggest the introduction of a RefCCMPackage for CCMreflection Mapping. It is more natural and intuitive for package components to provide RefCCMPackage facets rather than RefCCMBaseObject. The RefCCMPackage should inherit from the RefCCMBaseObject. This could also ease the migration of reflective clients from CCM to Base-IDL Repository
    Moreover rule (42) and example (10) use the word support to describe the relationship between concrete home interfaces and RefCCMHome. A home rather inherits from another home.
    Section 8.3.2 uses a RefComponent type not explained anywhere. This should be RefCCMObject, since this guarantees that the concrete object in it is a component.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

RefCCMBaseObject and RefBaseObject

  • Key: MOF2I2-30
  • Legacy Issue Number: 9160
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    RefCCMBaseObject and RefBaseObject should contain a ref_get_label() operation.
    Source:
    Michael Soden, soden@ikv.de
    Summary:
    Unfortunately the MOF2.0 Core like MOF1.4 fails explicitly model a property as the label of an instance of a class. It provides the isID flag but this cannot always be used to display class instances reflectively. For example, when modeling a "Library", a "Book" would have a "bookID" and "title". While the "bookID" may be flagged with isID=true, this may not be user friendly for a reflective client displaying a book.
    Therefore I suggest the introduction of a ref_label() operation in the RefCCMBaseObject and RefBaseObject interfaces as well as a standard optional Tag whose value should denote the property to use as a label. The modeler can attach such a tag to a class so that the ref_label() method can be implemented accordingly in the class' derived interface.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    closed no chage

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Clarify the Extents concept in the mapping

  • Key: MOF2I2-29
  • Legacy Issue Number: 9159
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The Note in Section 7.1 on Extents deferred the clarification of the concept and mapping of extents to the FTF of the finalization process. We need some clarifications here.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (50) is not applied in example (12).

  • Key: MOF2I2-28
  • Legacy Issue Number: 9158
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The interface declarations for A, B and C in example (12) on page 35 do not contain the operations derived according to rule (50).

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Some referenced sections do not exist

  • Key: MOF2I2-27
  • Legacy Issue Number: 9157
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Rule (46) on page 33 references section 8.2.5 which does not exist in the document.
    Rule (40) on page 30 references section 8.3.6 which does not exist in the document.
    The "Semantics" of the MOFObject::get_mof_id operation on page 45 references section 9.1 which does not exist in the document.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Numbering and references to examples are not consistent

  • Key: MOF2I2-26
  • Legacy Issue Number: 9156
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Example 8 is missing and example 10 references example 10 rather than example 4.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Remove the Common suffix from the interface names in the common mapping

  • Key: MOF2I2-23
  • Legacy Issue Number: 9153
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Since clients will in most cases deal directly with the abstract interfaces from the common mapping, it is more natural to name these interfaces using format_1(<class name>). As a consequence, we need to rename the Base-IDL and Component identifiers by adding a suffix.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Example 4 is not totally consistent with rules (35) and (36).

  • Key: MOF2I2-25
  • Legacy Issue Number: 9155
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Example 4 on page 26 still contains the create_<component_name> factory operation which is no more generated according to issue 7682.
    Moreover, the factory operation create_and_init_b(in long a_attrib, in ACommon b_attrib); in the home declaration home BHome manages B, the a_attrib parameter is not needed.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align Handling of Collections to MOF2.0 Core

  • Key: MOF2I2-24
  • Legacy Issue Number: 9154
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The handling of collections is not aligned to MOF2.0 Core reflection. Although extensions may be available specific for IDL, the standard operations and interfaces must conform to the MOF2.0 collection handling. Therefore, we introduce corresponding ReflectiveCollection and ReflectiveSequence interfaces with the same operations. In turn all type specific iterators are dropped and replaced by generic reflective interfaces. However, we would like to keep the iterator interfaces as an IDL extension for convenience

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Subsection 6.2.1 (Mapping of Identifiers) should be independent of MOF1.4

  • Key: MOF2I2-20
  • Legacy Issue Number: 9150
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    In subsection 6.2.1 the current specification ptc/05-03-05 makes references to the MOF1.4 Specification, ptc/01-10-04 forcing the reader to refer to that document. I think the specification should rather just mention that mapping of identifiers has been carried over from MOF1.4 and outline the mapping rules in detail here again.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Not all assumptions of MOF2.0 Core do hold

  • Key: MOF2I2-19
  • Legacy Issue Number: 9149
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification ptc/05-03-05 makes assumptions of the MOF2.0 Core specification which do not longer holder in ptc/04-10-15. It would be better to refer to the applicable MOF2.0 Core specification and only add text or diagrams that help to clarify some unobvious concepts in MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Align MOFObject to MOF2.0 Core

  • Key: MOF2I2-22
  • Legacy Issue Number: 9152
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The Object metaclass defines the base for all classes in a MOF metamodel. The same role is played by the MOFObject interface which was introduced to have a common base type in IDL for all kinds of derived interfaces. The is_equals() operation in the MOFObject interface should be renamed to equals() to match the equals operation in MOF2.0.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

specification should throughout be discretely divided into EMOF and CMOF

  • Key: MOF2I2-21
  • Legacy Issue Number: 9151
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Since there are two compliance points, EMOF and CMOF, and the mapping is divided into Common, CCM and Base-IDL mapping, the sections and subsections in the document should discretely reflect this consistently.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

References to other specification documents are not up to date

  • Key: MOF2I2-18
  • Legacy Issue Number: 9148
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Throughout the current specification ptc/05-03-05, references are made to other specifications which are not up to date. References to submission documents should be updated to their respective adopted documents and the affected sections should be corrected too. The specification should avoid making references directly to UML Specifications but rather to the MOF2.0 Core specification which in turn makes the appropriate references to UML.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

CMOF::Exception class is no longer in MOF2.0

  • Key: MOF2I2-17
  • Legacy Issue Number: 8505
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification assumes the existence of a CMOF::Exception class
    which was in the MOF2.0 Core submission document but removed during
    finalization. Rule (23) on page 21 still refers to this class.

  • Reported: MOF2I 2.0b1 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Remove FTF comments

  • Key: MOF2I2-16
  • Legacy Issue Number: 8504
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification document ptc/04-07-01 still contains the
    submission notes for the FTF provided as guidance by the submitters. We need
    to remove them from the specification document.

  • Reported: MOF2I 2.0b1 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

factory create_ ();

  • Key: MOF2I2-15
  • Legacy Issue Number: 7755
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The first factory operation described for homes

    factory create_<component_name> ();

    has the same signature as the create() method generated from
    the 'implied IDL' *HomeImplicit interface. The implied IDL
    *Home interface inherits from *HomeImplicit, so it seems
    we already have an operation in the equivalent home interface
    that is doing the same thing as the declared factory operation.

  • Reported: MOF2I 2.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (38) p. 30

  • Key: MOF2I2-14
  • Legacy Issue Number: 7754
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The CCM component mapping for an Association has the suffix
    "Component", unlike any of the the other component mappings
    in the document. That's a little puzzling. Also, no details
    are given about the corresponding home mapping. How is its
    type name derived? Does it have the same factory operations as
    the other CCM home mappings in the document?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (38):

  • Key: MOF2I2-8
  • Legacy Issue Number: 7681
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The CCM mapping for an Association specifies the
    suffix "Component" for the derived component.
    None of the other derived components in the CCM
    mapping have this suffix, and it also disagrees
    with some example IDL in the document.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (26) p. 21

  • Key: MOF2I2-10
  • Legacy Issue Number: 7750
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Although I see the member types for the *Link struct
    specified, I don't see anything about the member names.
    Are they specified somewhere else? How are they to be
    derived?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (35):

  • Key: MOF2I2-9
  • Legacy Issue Number: 7682
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The home factory operation 'create_<class identifier>'
    has the same signature as the 'create' operation
    defined by the CCM spec in the implied-IDL
    <class identifier>HomeImplicit interface, and for
    this reason it seems redundant.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Section 7.4 pp. 49,50

  • Key: MOF2I2-13
  • Legacy Issue Number: 7753
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The type of MofError::error_kind and MofERror::error_description
    (section 6.2.10 p. 20 & section 7.4 p. 50) are both wstring,
    but there is also a list of IDL string constants (section 7.4
    p. 49). How are the constants to be used? Are they to be passed
    as one of MofError's wstring members? If so, how come the type
    mismatch?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Section 7.6.3 pp. 59,60

  • Key: MOF2I2-12
  • Legacy Issue Number: 7752
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    With regard to the operations 'create_link_in_<association_name>'
    and 'remove_link', the Exception paragraphs contain information
    only about the case where association ends are defined as
    derived unions. It's not clear what the behavior is otherwise.

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (27) p. 21

  • Key: MOF2I2-11
  • Legacy Issue Number: 7751
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Same as above, for members of the valuetype *State,
    mapped from an Association

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Section 7.4;

  • Key: MOF2I2-7
  • Legacy Issue Number: 7680
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    MofError's error_kind and error_description
    members are wstrings, yet the string constants
    defined in this section (and which are I
    assume intended for use as values for one or
    both of these members) are strings.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Section 7.6.3

  • Key: MOF2I2-6
  • Legacy Issue Number: 7679
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The wording causes confusion about what the exception
    behavior is if the association ends are not derived
    unions

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Section: 8.2.2;8.2.6

  • Key: MOF2I2-3
  • Legacy Issue Number: 7653
  • Status: closed  
  • Source: Humboldt-Universitaet ( Mario Winkler)
  • Summary:

    In Rule (9) it is stated that the created valuetype which inherits from the abstract valuetype MOFState is truncatable. But according to the CORBA Specification it is not allowed to declare a valuetype as truncatable if it is derived from an abstract valuetype. The base type has to be non-abstract.

  • Reported: MOF2I 2.0b1 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (27)

  • Key: MOF2I2-5
  • Legacy Issue Number: 7678
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I assume that the identifiers for the members of
    the <association_name>State valuetype will be the
    type name in format_2, but it should probably be
    stated explicitly

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

Rule (26):

  • Key: MOF2I2-4
  • Legacy Issue Number: 7677
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I assume the <association_name>Link struct member
    names will be in correspoding format_2, but it
    should probably be stated explicitly.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

section 6.3.3, p.31, example IDL

  • Key: MOF2I2-2
  • Legacy Issue Number: 7640
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    section 6.3.3, p.31, example IDL
    The operations shown in the example for mapping of
    associations don't seem to gibe with the operations
    described section 7.6.3, pp.59-61.

    The CCM version of the mapping has components supporting abstract
    interfaces. There is some discussion where I work about whether
    or not this will have dire consequences. Such a case was throwing
    an error in our IDL compiler - someone must have thought it was
    a no-no. For the record, it seems ok to me for components to do
    this, but I wanted to get some more input on the matter. I guess
    it boils down to the question of whether it would ever be
    necessary to narrow to a component's supported interface, or to
    pass one over the wire as a CORBA::Object.

  • Reported: MOF2I 2.0b1 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT

section 7.3, p.44, example IDL

  • Key: MOF2I2-1
  • Legacy Issue Number: 7639
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    forward declared exception (MofError)

    For now I have instead forward declared MOFObject so I can
    fully define MofError before the full definition of MOFObject.

    abstract valuetype (MOFState) has a state member

    For now I have removed the 'abstract' qualifier.

  • Reported: MOF2I 2.0b1 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:52 GMT