Issue 9149: Not all assumptions of MOF2.0 Core do hold                                                                                                                                                              (mof2idl-ftf)
Source: Fraunhofer FOKUS (Mr. Michael Soden, soden@ikv.de soden@fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity: 
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.


Resolution: 
Revised Text: 
Actions taken:
November 15, 2005: received issue
March 8, 2006: closed issue
Discussion: 
Resolution:
The first paragraph of chapter 5 (methodology) on page 3 was modified from
This chapter describes the submitters' approach for the MOF 2.0 IDL language mapping and assumptions about the MOF model. Due to the fact that the mapping is strongly dependent on the MOF 2.0 Core and other currently ongoing RFP processes (such as MOF2.0 QVT RFP [4] MOF2.0 Versioning and Development Lifecycle RFP [5]…), this specification follows its own approach for the definition of the language mapping and outlines the vision, how this language mapping will fit in emerging standards and OMG's MDA (for a detailed specification refer to chapters 6 and 7).
to
This chapter describes the submitters' approach for the MOF 2.0 IDL language mapping. Due to the fact that the mapping is strongly dependent on the MOF 2.0 Core and other currently ongoing RFP processes (such as MOF2.0 QVT RFP [4] MOF2.0 Versioning and Development Lifecycle RFP [5] etc), recent results of these specifications could not be reflected in this mapping..
Delete subsection 5.2 (Assumptions of MOF2.0 Core), page 3 and adjust the numbering of the following subsections.
Subsection 5.2 (Assumptions of MOF2.0 Core), page 3 was deleted.
The first paragraph of subsection 5.3.2 on page 3 was altered.
Modify subsection 5.3.2 (MOF Model), page 5 the following way: Instead of explaining what is already explained in ptc/04-10-15, the complete EMOF and CMOF Models' overview class diagrams lacking in ptc/04-10-15 should be shown here, so that the reader must not put this together himself to get the big picture.
Title of subsection 5.3.2 was from "MOF Model" to "The MOF Model", its text modified from
The core-mapping is a revised version of the current IDL mapping introducing abstract interfaces and valuetypes. It is based on the elements imported from UML 2 InfrastructureLibrary (from U2P adopted document [9]) Core packages combined into the EMOF and CMOF packages (cp. [8]).
The EMOF and CMOF packages are constructed by the deep-copy merge algorithm described in [8], section 9 (PackageMerge::define). The resulting modeling elements are listed below. A proposed mapping onto IDL elements is provided later in this specification in chapters 6 and 7.
 To
The MOF Model as described in [6] is devided into EMOF and CMOF packages constructed by means of package merge. The resulting EMOF model is shown below for convenience. For CMOF, refer to [6]. A proposed mapping onto IDL elements is provided later in this specification in chapters 6 and 7.
NOTE: The EMOF class diagrams is included for convenience here. In case of any inconsistencies with the MOF2.0 Core Specification, see chapter 3, page 1 for the valid normative reference.
and the class diagram for EMOF was introduced.

End of Annotations:=====
MG Issue No: [Temp2]
Title:	Not all assumptions of MOF2.0 Core do hold.
Source:
Michael Soden, soden@ikv.de
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.

Discussion:

Resolution:
The first paragraph of chapter 5 (methodology) on page 3 was modified from
This chapter describes the submitters. approach for the MOF 2.0 IDL language mapping and assumptions about the MOF model. Due to the fact that the mapping is strongly dependent on the MOF 2.0 Core and other currently ongoing RFP processes (such as MOF2.0 QVT RFP [4] MOF2.0 Versioning and Development Lifecycle RFP [5].), this specification follows its own approach for the definition of the language mapping and outlines the vision, how this language mapping will fit in emerging standards and OMG.s MDA (for a detailed specification refer to chapters 6 and 7).
to
This chapter describes the submitters. approach for the MOF 2.0 IDL language mapping. Due to the fact that the mapping is strongly dependent on the MOF 2.0 Core and other currently ongoing RFP processes (such as MOF2.0 QVT RFP [4] MOF2.0 Versioning and Development Lifecycle RFP [5] etc), recent results of these specifications could not be reflected in this mapping..
Delete subsection 5.2 (Assumptions of MOF2.0 Core), page 3 and adjust the numbering of the following subsections.
Subsection 5.2 (Assumptions of MOF2.0 Core), page 3 was deleted.
The first paragraph of subsection 5.3.2 on page 3 was altered.
Modify subsection 5.3.2 (MOF Model), page 5 the following way: Instead of explaining what is already explained in ptc/04-10-15, the complete EMOF and CMOF Models. overview class diagrams lacking in ptc/04-10-15 should be shown here, so that the reader must not put this together himself to get the big picture.
Title of subsection 5.3.2 was from .MOF Model. to .The MOF Model., its text modified from
The core-mapping is a revised version of the current IDL mapping introducing abstract interfaces and valuetypes. It is based on the elements imported from UML 2 InfrastructureLibrary (from U2P adopted document [9]) Core packages combined into the EMOF and CMOF packages (cp. [8]).
The EMOF and CMOF packages are constructed by the deep-copy merge algorithm described in [8], section 9 (PackageMerge::define). The resulting modeling elements are listed below. A proposed mapping onto IDL elements is provided later in this specification in chapters 6 and 7.
 To
The MOF Model as described in [6] is devided into EMOF and CMOF packages constructed by means of package merge. The resulting EMOF model is shown below for convenience. For CMOF, refer to [6]. A proposed mapping onto IDL elements is provided later in this specification in chapters 6 and 7.
NOTE: The EMOF class diagrams is included for convenience here. In case of any inconsistencies with the MOF2.0 Core Specification, see chapter 3, page 1 for the valid normative reference.
and the class diagram for EMOF was introduced.

Disposition:	open