MOF to IDL Mapping Avatar
  1. OMG Specification

MOF to IDL Mapping — All Issues

  • Acronym: MOF2I
  • Issues Count: 44
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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

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