Issue 9151: specification should throughout be discretely divided into EMOF and CMOF                                                                                                                                (mof2idl-ftf)
Source: Fraunhofer FOKUS (Mr. Michael Soden, soden@ikv.de soden@fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity: 
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.
Resolution: 
Revised Text: 
Actions taken:
November 15, 2005: received issue
March 8, 2006: closed issue
Discussion: 
Resolution:
Section 6 should therefore have the following structure (starting from subsection 6.2):
Subsection 6.2: General Mapping Rules
		6.2.1 Mapping of Identifiers (same as before)
		6.2.2 Globals (same as before)
		6.2.3 Mapping of the PrimitiveType Package (same as before)
		6.2.4 Mapping of Collections (MultiplicityElement) (same as before)
Subsection 6.3: EMOF Mapping Rules
		6.3.1 EMOF Common Mapping
			subsections for mapping of the various modeling constructs
		6.3.2 EMOF CCM Mapping
			subsections for mapping of the various modeling constructs
		6.3.3 EMOF Base-IDL Mapping
subsections for mapping of the various modeling constructs
Subsection 6.4: CMOF Mapping Rules
		6.4.1 CMOF Common Mapping
			subsections for mapping of the various modeling constructs
		6.4.2 CMOF CCM Mapping
			subsections for mapping of the various modeling constructs
		6.4.3 CMOF Base-IDL Mapping
			subsections for mapping of the various modeling constructs
Section 7 should also be aligned in this manner.
Subsection 8.1: EMOF Reflective
		8.1.1 EMOF Base-IDL Reflective
8.1.2 EMOF CCM Reflective
Subsection 8.2: EMOF Reflective
		8.2.1 EMOF Base-IDL Reflective
8.2.2 EMOF CCM Reflective
Done. References to other appropriate sections were included in sections which do not introduce any new mapping rules
introduced in section 6.2:	
The general mapping rules apply to both EMOF and CMOF mappings. They concerntrate on aspects that are specific to neither EMOF and CMOF such as formatting of identifiers, global interfaces and mapping of primitive types.
In section 6.2.8
We refer to the type of an operation or attribute as the type that is derived for that element (common interface, primitive type, or data types). Moreover, we do not distinguish navigable association ends and attributes of type class (cp. to UML2 Infrastructure and see discussion in 5.2.11 and Navigability and owned Properties).
was modified to
We refer to the type of an operation or attribute as the type that is derived for that element (common interface, primitive type, or data types).
In section 6.4
Apart from the component mapping, this section provides the opportunity of a true Base-IDL mapping to cope with non-component environments and MOF1.4 clients. It must be stressed, that this mapping is an alternative mapping to CCM - since several names and interfaces collide with definitions for the CCM - and we do not believe that the equivalent IDL suffices usability needs. Moreover, the submitters prefer the CCM mapping approach.

modified to

Apart from the component mapping, this section provides the opportunity of a true Base-IDL mapping to cope with non-component environments and MOF1.4 clients. It must be stressed, that this mapping is an alternative mapping to CCM - since several names and interfaces collide with definitions for the CCM.


End of Annotations:=====
MG Issue No: [Temp4]
Title:	The specification should throughout be discretely divided into EMOF and CMOF.
Source:
Michael Soden, soden@ikv.de
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.

Discussion:

Resolution:
Section 6 should therefore have the following structure (starting from subsection 6.2):
Subsection 6.2: General Mapping Rules
		6.2.1 Mapping of Identifiers (same as before)
		6.2.2 Globals (same as before)
		6.2.3 Mapping of the PrimitiveType Package (same as before)
		6.2.4 Mapping of Collections (MultiplicityElement) (same as before)
Subsection 6.3: EMOF Mapping Rules
		6.3.1 EMOF Common Mapping
			subsections for mapping of the various modeling constructs
		6.3.2 EMOF CCM Mapping
			subsections for mapping of the various modeling constructs
		6.3.3 EMOF Base-IDL Mapping
subsections for mapping of the various modeling constructs
Subsection 6.4: CMOF Mapping Rules
		6.4.1 CMOF Common Mapping
			subsections for mapping of the various modeling constructs
		6.4.2 CMOF CCM Mapping
			subsections for mapping of the various modeling constructs
		6.4.3 CMOF Base-IDL Mapping
			subsections for mapping of the various modeling constructs
Section 7 should also be aligned in this manner.
Subsection 8.1: EMOF Reflective
		8.1.1 EMOF Base-IDL Reflective
8.1.2 EMOF CCM Reflective
Subsection 8.2: EMOF Reflective
		8.2.1 EMOF Base-IDL Reflective
8.2.2 EMOF CCM Reflective
Done. References to other appropriate sections were included in sections which do not introduce any new mapping rules
introduced in section 6.2:	
The general mapping rules apply to both EMOF and CMOF mappings. They concerntrate on aspects that are specific to neither EMOF and CMOF such as formatting of identifiers, global interfaces and mapping of primitive types.
In section 6.2.8
We refer to the type of an operation or attribute as the type that is derived for that element (common interface, primitive type, or data types). Moreover, we do not distinguish navigable association ends and attributes of type class (cp. to UML2 Infrastructure and see discussion in 5.2.11 and Navigability and owned Properties).
was modified to
We refer to the type of an operation or attribute as the type that is derived for that element (common interface, primitive type, or data types).
In section 6.4
Apart from the component mapping, this section provides the opportunity of a true Base-IDL mapping to cope with non-component environments and MOF1.4 clients. It must be stressed, that this mapping is an alternative mapping to CCM - since several names and interfaces collide with definitions for the CCM - and we do not believe that the equivalent IDL suffices usability needs. Moreover, the submitters prefer the CCM mapping approach.

modified to

Apart from the component mapping, this section provides the opportunity of a true Base-IDL mapping to cope with non-component environments and MOF1.4 clients. It must be stressed, that this mapping is an alternative mapping to CCM - since several names and interfaces collide with definitions for the CCM.



Disposition:	open