Issue 9154: Align Handling of Collections to MOF2.0 Core                                                                                                                                                            (mof2idl-ftf)
Source: Fraunhofer FOKUS (Mr. Michael Soden, soden@ikv.de soden@fokus.fraunhofer.de)
Nature: Uncategorized Issue
Severity: 
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
Resolution: 
Revised Text: Remove Rule(3) and instead introduce a reflective iterator interface one in the MOF package having the same functionality as the one in rule (3), but works with the ReflectiveCollection and ReflectiveSequence interfaces rather than the type specific collections.
interface ReflectiveIterator : MOFObject{
	// all operations as in rule (3)
	is_at_end() : boolean //used before calling next() or get_value() to avoid MofError
}
defined in section 6.2.2 (Globals) and old definition deleted from section 6.2.4 (Mapping of Collections)
Declare interfaces for ReflectiveCollection and ReflectiveSequence:
interface ReflectiveCollection : MOFObject{
	// all the standard operations in MOF2.0 Core
	get_iterator(): ReflectiveIterator // returns the appropriate iterator
}
defined in section 6.2.2 (Globals)
interface ReflectiveSequence : MOFObject{
// all the standard operations in MOF2.0 Core, suffixing the overloaded add and remove      operations with "_at"
}
defined in section 6.2.2 (Globals)
Delete rules (4) and (5) and modify the rules dealing with collection parameters and return values of to indicate that they return either ReflectiveCollection or ReflectiveSequence as prescribed in MOF2.0 Core. The interface IteratorBase is not needed. The client can always narrow the contents of such collections to the expected types or reflective objects (in the case of reflection).
Done
All examples related to this change should be modified.
Example (5) on page 27 was changed to
module MyPackage {
	typedef sequence < A > ASet;
	abstract interface B {
			ReflectiveCollection get_b_attrib ( );
			// modification is done by iterator operations
	};
};
Example (6) on page 28 was changed to
module MyPackage {
		valuetype BState : truncatable MOFState supports B {
				public ReflectiveCollection b_attrib; //holds AState objects
		};
	};
The complete reflective IDL was also changed
Rules (15) changed from 
	For an attribute with multiplicity upper>1, two operations to set and get the attribute value are declared - taking into account Rule (2), Rule (3) and Rule (11).
The operation to get the value of the attribute has the name concatenate ( "get_", format_2 ( <attribute identifier> ) ). The return type is of the IDL collection type generated for the attribute's type in the model according to Rule (3) (abstract iterator interface). The MOFObject::set_call_semantic operation is used by the client to decide, whether the operation shall return the collection by value (if as_value is true) or as reference (if as_value is false).
	
to
For an attribute with multiplicity upper>1, two operations to set and get the attribute value are declared - taking into account Rule (7).
	
The operation to get the value of the attribute has the name concatenate ( "get_", format_2 ( <attribute identifier> ) ). The return type is either ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).	The operation to set the value has the name concatenate ( "set_", format_2 ( <attribute identifier> ) ). The operation has one in-parameter of type ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).

Rules (16) changed from
The operation to set the value has the name concatenate ( "set_", format_2 ( <attribute identifier> ) ). The operation has one in-parameter of the IDL collection type generated for the attribute's type in the model according to Rule (3).
Furthermore, we extend the definition of Rule (13) for the case, that the multiplicity has an upper bound > 1, the IDL valuetype generated according to Rule (9) is extended by a private state member with the name format_2 ( <attribute identifier> ). The type of the member is the IDL collection type generated for the attribute type in the model following Rule (4).
to
Furthermore, we extend the definition of Rule (9) for the case, that the multiplicity has an upper bound > 1, the IDL valuetype generated according to Rule (5) is extended by a private state member with the name format_2 ( <attribute identifier> ). The type of the member is either ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).

Actions taken:
November 15, 2005: received issue
March 8, 2006: closed issue
Discussion: 
After having experimented with larger metamodels for the MOF2.0-IDL mapping, it turned out that the generated IDL is by far to large to be manageable. This is an outcome of the type specific iterator interfaces for everything that has a multiplicity upper > 1. In practice, a repository client can live with a generic collection type (he simply needs to narrow to the specific type), since it is the responsibility of the CORBA server to deliver the most specific type inside the Object reference (IOR). Thereby, the narrow would not result in any remote call and hence performance loss.
End of Annotations:=====
MG Issue No: [Temp7]
Title:	Align Handling of Collections to MOF2.0 Core.
Source:
Michael Soden, soden@ikv.de
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.

Discussion:
After having experimented with larger metamodels for the MOF2.0-IDL mapping, it turned out that the generated IDL is by far to large to be manageable. This is an outcome of the type specific iterator interfaces for everything that has a multiplicity upper > 1. In practice, a repository client can live with a generic collection type (he simply needs to narrow to the specific type), since it is the responsibility of the CORBA server to deliver the most specific type inside the Object reference (IOR). Thereby, the narrow would not result in any remote call and hence performance loss.
Resolution:
Remove Rule(3) and instead introduce a reflective iterator interface one in the MOF package having the same functionality as the one in rule (3), but works with the ReflectiveCollection and ReflectiveSequence interfaces rather than the type specific collections.
interface ReflectiveIterator : MOFObject{
	// all operations as in rule (3)
	is_at_end() : boolean //used before calling next() or get_value() to avoid MofError
}
defined in section 6.2.2 (Globals) and old definition deleted from section 6.2.4 (Mapping of Collections)
Declare interfaces for ReflectiveCollection and ReflectiveSequence:
interface ReflectiveCollection : MOFObject{
	// all the standard operations in MOF2.0 Core
	get_iterator(): ReflectiveIterator // returns the appropriate iterator
}
defined in section 6.2.2 (Globals)
interface ReflectiveSequence : MOFObject{
// all the standard operations in MOF2.0 Core, suffixing the overloaded add and remove      operations with ._at.
}
defined in section 6.2.2 (Globals)
Delete rules (4) and (5) and modify the rules dealing with collection parameters and return values of to indicate that they return either ReflectiveCollection or ReflectiveSequence as prescribed in MOF2.0 Core. The interface IteratorBase is not needed. The client can always narrow the contents of such collections to the expected types or reflective objects (in the case of reflection).
Done
All examples related to this change should be modified.
Example (5) on page 27 was changed to
module MyPackage {
	typedef sequence < A > ASet;
	abstract interface B {
			ReflectiveCollection get_b_attrib ( );
			// modification is done by iterator operations
	};
};
Example (6) on page 28 was changed to
module MyPackage {
		valuetype BState : truncatable MOFState supports B {
				public ReflectiveCollection b_attrib; //holds AState objects
		};
	};
The complete reflective IDL was also changed
Rules (15) changed from 
	For an attribute with multiplicity upper>1, two operations to set and get the attribute value are declared - taking into account Rule (2), Rule (3) and Rule (11).
The operation to get the value of the attribute has the name concatenate ( "get_", format_2 ( <attribute identifier> ) ). The return type is of the IDL collection type generated for the attribute.s type in the model according to Rule (3) (abstract iterator interface). The MOFObject::set_call_semantic operation is used by the client to decide, whether the operation shall return the collection by value (if as_value is true) or as reference (if as_value is false).
	
to
For an attribute with multiplicity upper>1, two operations to set and get the attribute value are declared - taking into account Rule (7).
	
The operation to get the value of the attribute has the name concatenate ( "get_", format_2 ( <attribute identifier> ) ). The return type is either ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).	The operation to set the value has the name concatenate ( "set_", format_2 ( <attribute identifier> ) ). The operation has one in-parameter of type ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).

Rules (16) changed from
The operation to set the value has the name concatenate ( "set_", format_2 ( <attribute identifier> ) ). The operation has one in-parameter of the IDL collection type generated for the attribute.s type in the model according to Rule (3).
Furthermore, we extend the definition of Rule (13) for the case, that the multiplicity has an upper bound > 1, the IDL valuetype generated according to Rule (9) is extended by a private state member with the name format_2 ( <attribute identifier> ). The type of the member is the IDL collection type generated for the attribute type in the model following Rule (4).
to
Furthermore, we extend the definition of Rule (9) for the case, that the multiplicity has an upper bound > 1, the IDL valuetype generated according to Rule (5) is extended by a private state member with the name format_2 ( <attribute identifier> ). The type of the member is either ReflectiveCollection or ReflectiveSequence (depending on the orderedness of the property).

Disposition:	open