Issues for MOF 2.0/UML 2.0 Infrastructure 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 5948: Navigating metalevels/instance relationships
Issue 5996: MOF 2 Issue: Reflexion and Links
Issue 6390: MOF 2.0 Core 03-04-07, Chapter 5. Identifiers
Issue 6408: MOF should include Profile package
Issue 6494: ad-03-04-07/Non-orthogonal additions to UML Core
Issue 6694: diagrams mostly use unspecified «combine»
Issue 6695: chapter 10 rewrite
Issue 6903: Associations should not be required to be unique
Issue 6904: Need to specify URI structure
Issue 6905: No container for tags in tag model
Issue 6906: ReflectiveSequence is not sufficient, need nulls within a list
Issue 6907: ReflectiveSequence is not sufficient - add iterator, remove addAll
Issue 6908: Remove allowNull and serializable from EMOF DataType
Issue 6909: Migration of package relationships
Issue 6910: Correct addAll() input parameter type
Issue 6920: The 'isID' attribute in class MOF::CMOF::Property remains unclear
Issue 7453: semantics of Reflection::Object
Issue 7454: object in a useContainment Extent
Issue 7548: Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF
Issue 7564: MOF Figure 18
Issue 7647: Translation between EMOF and CMOF in MOF 2.0
Issue 7749: Question on M-Levels
Issue 7957: removing section 12.3 EMOF Merged Model ?

Issue 5948: Navigating metalevels/instance relationships (mu2i-ftf)

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?

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.

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.

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.

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.

The diagrams mostly use «combine», but what that means is not specified. The defined package merge types are define and extend.

The submitters decided to put off to the FTF the chapter 10 rewrite, to correct text that refers to capabilities removed from the final submission. 

Proposed resolution: This reporter will prepare a proposed rewrite

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.

Summary: 
isID semantics - the 'may be used' is too weak. I think myself and Joaquin have made the point that we
need to specify the URI structure to get interoperability (and I don't mean the W3C standard - I mean how to construct
the URI from the objects/extents/properties/containers being identified).

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

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

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.

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

Summary:
At MOF 1.4, packages can be related through: 
- import 
- nesting 
- inheritance 
- clustering 
We haven't really addressed this aspect of migration which should be added to Chapter 9. 
Personally I think there's little value in MOF 1.4 nesting and inheritance relationships and they're infrequently used in real metamodels (if people know what they're doing - occasionally people nest packages in UML Profile for MOF without realizing the implications).

In UML2 though we do still have a nesting relationship between packages so should consider the implications in terms of MOF constraints and extents.

Conversely we no longer have clustering (the most useful relationship in MOF 1.4) though we do have merging (with 2 flavors): we need to consider the runtime implications of instantiating a package that merges other packages. Is it the same as clustering?

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

The 'isID' attribute in class MOF::CMOF::Property remains unclear for constructed types like e.g. collections. 

Proposed resolution: Detail specifcation of the 'isID' attribute with respect to other than primitive and class types. Suggestions: (1) identity is established for more complex types if identity 'isID' or "natural" identity (i.e. creation based identity) is given recursively for all referenced instances, or (2) if e.g. a collection has itself identity, then identity is established if the collections are the same 

 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?

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

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.

I'm confused by something in MOF Figure 18. I see that this is a "semantic domain model," and i know i'm not clear on what that means. But i feel my question makes sense absent a clear understanding of what the MOF specification means by 'semantic domain model.' This diagram is apparently the extension of "the UML 2 Instances model" mentioned at 15.1. I'll assume 'Instances model' means the Infrastructure package, Instances. And, indeed, the drawing there is (mostly) reproduced in Figure 18. My question is about the extensions shown. I'll pick one such extension to make the question concrete. The drawing shows a class, Instance, a subclass of InstanceSpecification. The Infrastructure specification is clear: an instance and an instance specification specifying that instance are not in the same model. My question: Does the term 'instance' have a different meaning in MOF than in the Infrastructure, or are the objects of the class, Instance, not instances, or what? 

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?

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?

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.