I disagree with [7] (in Reflection Factory Constraints) - this is something we had a lot of discussion about
with Steve and Joaquin and it was agreed that Associations should not be required to be unique.

This is an inconsistency since the constraint is not documented as part of restrictions in CMOF or EMOF.

The EMOF model should contain a tag on EMOF:Element of XMI ContentType with value "any".

See the discussion and resolution of MOF 2 XMI FTF issue 6345 for background.

Add XMI tag contentType=”any” to Appendix A and in the metamodel.

Why is that an object in a useContainment Extent cannot have the extent as its container? (This is stated on page 22 of the Final Adopted Spec

No Data Available

According to page 17, the semantics of Reflection::Object require that all instances of MOF model elements must specialize EMOF::Object. My question is, does this specialization have to be explicit or implicit? That is, if I create a blank MOF Class and ask for its superclasses, will they include EMOF::Object? If I send it a "getMetaClass" message, for example, will it understand it, or do I have to explicitly add EMOF::Object to its superclass property?

No Data Available

ReflectiveCollection::addAll should take a ReflectiveCollection, not a ReflectiveSequence

change as suggested

EMOF:

• DataType.allowNull should be removed
• DataType.serializable should be removed. What are the use cases for
  it? It seems to me that all the values need to be serializable to allow
  interoperability

No Data Available

Summary:
Martin has proposed adding an iterator operation Iterator and removing addAll.
Iterator would return a ReflectiveIterator that can be used to iterate through all the elements of the collection. If the underlying collection changes while holding an iterator, the behavior of iterator is undefined.

AddAll is useful as an atomic operation. There would be limited value in a language independent iterator – it will tend to make for non-optimal language bindings

Issue: The MOF 2 Core specification adds elements to the meta-metamodel that
are not part of the UML 2 Core. For example, see the sections entitled
"EMOF Extensions to Basic" and "CMOF Extensions to Core::Constructs." The
MOF 2 Core's abstract syntax should be a subset of UML. (For detailed
explanation of why this is advisable, see ad/03-03-30). Note that this
subset principal allows for MOF to specify orthogonal "mix-in" elements,
such as packages for reflection and identity.

Recommendation: Either add the extra elements to the UML 2 Core or else
remove them from MOF.

No Data Available

Summary:
For interoperability with the XML relational databases, we need to be able to support nulls within a list

No Data Available

Summary:
The tag model is lacking a container for tags. Why not make tags NamedElements (need to check if that’s
good enough)?

No Data Available

On page 36:

“Identity extends Basic::Property with the ability to designate a property as an identifier for the containing object. Properties: isID: Boolean [0..1] True indicates this property can be used to uniquely identify an instance of the containing Class. Only one Property in a class may have isID==true.”

The restriction that only one Property in a class may have isID==true is debilitating. It is common for objects to be identified in the modeled application domain by a unique combination of a set of properties. For example, an object that represents an instance of an n-ary association in the modeled domain will, in general, be identified by a unique combination of n properties, each one of which is an identifier of a participating object in the association. Not being able to carry this natural condition into the MOF requires practitioners to devise a work-around, such as introducing a superfluous surrogate identifier, to be able to externally identify such objects.

It is requested that the MOF 2.0 Core specification be revised by the FTF to allow any number of sets of properties to be identifiers. Any client of an object needs to be able to select the identifier set most convenient for them, and different clients need to be able to accurately identify the object, regardless of how other clients may find it.

This issue is important to the Business Semantics of Business Rules submissions, which require domain identifiers for objects. Other MOF users will also benefit.

Introduction of the Identity package is a potentially powerful and badly needed improvement over MOF 1.x to enable the use of external identifiers for MOF objects, which will greatly facilitate accurate model interchange, reuse, aggregation, and transformation. The present limitation stunts this potential. Please take this modest extra step to assure the full potential of the Identity package can be realized.

No Data Available

The problem
-----------

In the reflexion package of MOF2, the proposal for links assumes that
AssociationEnds are ordered.
There is an implicit mapping between firstObject and secondObject roles and
AssociationEnds is based on this assumption:
FirstObject maps to the first associationEnd
SecondObject maps to the second associationEnd

This leads to the following Operation to create links in the Factory Class:

createLink(association: Association, firstObject : Object, secondObject :
Object): Link

At first glance, this solution provides an easy way to identify the link
members in parameters of link operations. However, the AssociationEnd is
difficult to read. It is closer to relational concepts than to
object/association principles.
One will always have to guess which is the first or second object.
The modeler who has created the association might remember the order. But
the user using the association will probably be lost.

Example:
Country:Class - resident:AssociationEnd (First) - Citizenship:Association

• country:AssociationEnd (Second) - Country:Class

createLink("Citizenhip": Association, "Thomas": Object : "France" :
Object)

Proposal
--------
The idea is to benefit from the semantic carried by AssociationEnds
themselves:
A link defines members. Each member references a participant object
according to a role defined by the AssociationEnd.
Thanks to opposite association of AssociationEnds (aka Property), it is
possible to identify one end from another. This means that if we create
links from an AssociationEnd viewpoint, there is no need to order
AssociationEnd.
The proposal is to order the creation parameters as follow: sourceObject,
oppositeRole, oppositeObject.
Of course, this approach only works for binary associations. But the focus
of AssociationEnd is the first step to take into account nary associations.

This also highlight that what matters most in Association semantic is the
role name of AssociationEnds.
It is usually much more difficult to have a meaningful name for association.
This is why we can often see names such as "has for ..." which do not carry
much information about the association.

All operations on links are redefined as follow:

createLink (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object)
Example:
createLink("Thomas:Object","country:Role","France:Object")
equivalent to:
createLink("France:Object","resident:Role","Thomas:Object")

linkedObjects (sourceObject : Object, oppositeRole : Property) :
Object[0..*]

LinkExists (sourceObject : Object, oppositeRole : Property, oppositeObject :
Object) : Boolean

Proposal Comments
-----------------
A better proposal would not use the opposite role but the role attached to
the object participation to the association.

createLink("resident:Property","Thomas:Object","France:Object")

But experience shows that this is two much unsual for modelers. This would
however be the right path for the introduction of nary associations.

No Data Available

Hi, this question from Mike Lawley @ DSTC (I have CC'd him),
>
> How does one navigate metalevels in MOF2? "Object" has the operation
> "getMetaClass(): Class", but how can I explicitly model (via
> a reference/
> association) that MyObj is an instance of MyClass.
>
> Note, I can see exactly how to do this in CMOF for Links –
> there is an "instance" association between Link and
> Association in Fig 8-8.
>
> Incidentally, is this list the right forum for questions
> about the submission, or should it be addressed to a mof-rtf
> list or similar?

No Data Available

The Infrastructure library contains a Core model package and a Profile package.
The former is reused in MOG, but the latter is not part of MOF.
This means that MOF QVT submissions cannot build on the Profiles concept for marking (meta) models and they cannot define mappings for profiled meta models.
MDA style mappings from PIM to PSM or between PSMs requires support for mapping between profiled models in many UML modeling tools that implement PSMs as profiles.
If MOF QVT cannot deal with mappings to and between profiled models, these tools will require another solution.

No Data Available

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.

No Data Available

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?

No Data Available

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?

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

Title: Arguments to ref_get, ref_set and ref_is_set operations do not match with MOF2.0 Reflection specification.
Source:
Michael Soden, [email protected]
Summary:
The RefObject::ref_get (PropertyName) specified on page 67 does not conform to the get(Property) defined in MOF2.0 Reflection.

No Data Available

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.

No Data Available

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.

No Data Available

RefCCMBaseObject and RefBaseObject should contain a ref_get_label() operation.
Source:
Michael Soden, [email protected]
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.

closed no chage

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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?

No Data Available

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.

No Data Available

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?

No Data Available

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.

No Data Available

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?

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

No Data Available

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.

No Data Available

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.

No Data Available