Issues for Mailing ist of the MOF2 IDL Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7591: Rule (11) and (12)
Issue 7639: section 7.3, p.44, example IDL
Issue 7640: section 6.3.3, p.31, example IDL
Issue 7653: Section: 8.2.2;8.2.6
Issue 7677: Rule (26):
Issue 7678: Rule (27)
Issue 7679: Section 7.6.3
Issue 7680: Section 7.4;
Issue 7681: Rule (38):
Issue 7682: Rule (35):
Issue 7750: Rule (26) p. 21
Issue 7751: Rule (27) p. 21
Issue 7752: Section 7.6.3 pp. 59,60
Issue 7753: Section 7.4 pp. 49,50
Issue 7754: Rule (38) p. 30
Issue 7755: factory create_<component_name> ();
Issue 8504: Remove FTF comments
Issue 8505: CMOF::Exception class is no longer in MOF2.0
Issue 9148: References to other specification documents are not up to date
Issue 9149: Not all assumptions of MOF2.0 Core do hold
Issue 9150: Subsection 6.2.1 (Mapping of Identifiers) should be independent of MOF1.4
Issue 9151: specification should throughout be discretely divided into EMOF and CMOF
Issue 9152: Align MOFObject to MOF2.0 Core
Issue 9153: Remove the Common suffix from the interface names in the common mapping
Issue 9154: Align Handling of Collections to MOF2.0 Core
Issue 9155: Example 4 is not totally consistent with rules (35) and (36).
Issue 9156: Numbering and references to examples are not consistent
Issue 9157: Some referenced sections do not exist
Issue 9158: Rule (50) is not applied in example (12).
Issue 9159: Clarify the Extents concept in the mapping
Issue 9160: RefCCMBaseObject and RefBaseObject
Issue 9161: names of the factory create operations
Issue 9162: Align CCM Reflection Mapping to MOF2.0 Core
Issue 9163: Align Base-IDL Reflection Mapping to MOF2.0 Core
Issue 9164: RefObject::ref_get (PropertyName) specified on page 67
Issue 9165: Align reflective argument passing in EMOF to CMOF
Issue 9166: Semantic of reflective operations should match MOF2.0 Core
Issue 9167: "set" operation for derived attributes
Issue 9168: Align mapping of tags to MOF2.0
Issue 9169: Mapping of subsetted properties do not need to change name of operation
Issue 9170: Editorial issue(s)
Issue 9175: Resolution of issue 9154 does not work for primitives

Issue 7591: Rule (11) and (12) (mof2idl-ftf)

In my opinion it has to be stated in Rule (11) and (12) that getter and setter operations are only generated for non-derived attributes.

 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.

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.

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.

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

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

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

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.

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.

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.

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?

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

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.

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?

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?

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.

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.

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.

Discussion:
The removal of the CMOF::Exception class has only little impact on the IDL mapping. We can easily remove rule (23) from the specification. Moreover, FTF Note 4 (p. 21) has already pointed out the problem in using this class in MOF.

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.

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:
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.

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.

Resolution:
Outline what format_1, format_2 and format_3 produce.
Format 1 text changed to
identifier format_1 ( <MOF model element identifier> ) returns an identifier for an IDL definition according to 5.7.1.2 of [1]. In format 1, the first letter of each word is converted into upper case, and all other letters remain the same as input. It is used to produce names of modules and interfaces.
Format 2 text changed to
identifier format_2 ( <MOF model element identifier> ) returns an identifier for an IDL definition according to 5.7.1.3 of [1]. In format 2, all letters in each word are converted to lower case and all words are separated by an underscore ("_"). It is used to produce names of attributes, operations and formal parameters and members of structured data types.
Format 3 text changed to
identifier format_3 ( <MOF model element identifier> ) returns an identifier for an IDL definition according to 5.7.1.4 of [1]. In format 3, all letters in each word are converted to upper case and all words are separated by an underscore ("_"). It is used to produce names of constants.
For the resolution of a name in the target IDL, basically the naming conventions of MOF1.4 are reused (interfaces, that are derived for a class, receive an identifier in format 1, operations in format 2 and so on). For details see the following sections.
was changed to
Table 1 on page 13 on page   Error! Bookmark not defined. shows some examples.
an tabular example was introduced.

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:
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.

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.

The MOFObject interface declaration on page 13 should now be:
abstract interface MOFObject{
	boolean equals( in MOFObject other_object)
	//the rest as before
}

done
The IDL for MOFObject in section 7.3 was changed from

abstract interface MOFObject {
     MofId get_mof_id () raises (MofError);
     boolean is_equal ( in MOFObject other_object )
				raises (MofError);
     void delete () raises (MofError);
     MofErrorBagIterator verify( in unsigned long depth )
				raises (MofError);

     void set_value_depth( in unsigned long depth )
				raises (MofError);
     unsigned long get_value_depth ()
				raises (MofError);

     void set_call_semantic( in boolean as_value )
				raises (MofError);
     boolean get_call_semantic ()
				raises (MofError);
  };
to
abstract interface MOFObject {
     MofId get_mof_id () raises (MofError);
     boolean equals ( in MOFObject other_object )
				raises (MofError);
     void delete () raises (MofError);
     boolean verify( in wstring ocl_expr )
				raises (MofError);
     void set_value_depth( in unsigned long depth )
				raises (MofError);
     unsigned long get_value_depth ()
				raises (MofError);
     void set_call_semantic( in boolean as_value )
				raises (MofError);
     boolean get_call_semantic ()
				raises (MofError);
  };

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.

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

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.

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.

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

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.

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

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.

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.

Discussion:
Since this is outside the scope of the MOF2.0 IDL mapping, we do not consider it in the IDL language binding. However, this is a possible extension to MOF2.0 and should be raised as an issue for the MOF2.0 Core specification.

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>).

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.

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.

This is a bug in the current spec.

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.

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

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.

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

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

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.

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.

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.

Discussion:
Basically, the types of the iterator interface need to be changed from MOFObject to CORBA::Any. Instead of this generic solution which enforces clients to always use the any type, we introduce separate iterators for MOFObject and the primitive types, such that clients do not need to work with CORBA::Any all the time.