Issues for MOF 2.0 Core revision Task Force

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

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

Issue 8267: MOF 2 Core: undefined behavior of convertToString
Issue 8268: MOF 2.0 Core: Exceptions missing for CMOF Reflective operations
Issue 8269: MOF 2.0 Core: Inconsistency about use of defaults
Issue 8751: Relations
Issue 8997: CMOF should not itnore visibilities
Issue 9147: Container and owningProperty
Issue 9360: Issue for MOF 2 spec (ptc/04-10-15)
Issue 9466: Multiple classifiers for an instance in MOF and RDF as defined in ODM
Issue 9802: Remove Annex B
Issue 10968: Wrong URLs
Issue 11157: FormalNumber: formal/02-04-03 section 3.6.2
Issue 12175: MOF 2.1 should be based on UML 2.1 Infrastructure
Issue 12800: Capturing Unnavigable Opposite Property Role Names

Issue 8267: MOF 2 Core: undefined behavior of convertToString (mof2core-rtf)

Section 9.1 of ptc/04-10-15 defines operation convertToString that takes an Object parameter and converts to a string representation for a supplied DataType.
However no exception is defined for when the supplied Object is an instance of a ModelElement and not a DataType.

In ptc/04-10-15, Chapter 9 (EMOF Reflection) has some limited exceptions defined but Chapter 13 (CMOF Reflection) has none

In ptc/04-10-05, section 9.1, the documentation for isSet() states that it "returns true if the value of the Property is different than the default value of that property. "
However later on in the section under Semantics, it states:
 
If a single-valued property has a default:

....

 - If the value of that property is later explicitly set, even to the default value, isSet=true, 

Thus there is an inconsistency as to the value if isSet() in the case where the property has been explicitly set to a value that happens to be the same as its default.

All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations. 

It is not clear that all connections between elements in the UML2 model are a kind of
Relationship or DirectedRelationship. A better way to achieve generic traversal is to use
MOF reflection to navigate metaclass containment associations. Tools would be free to
merge MOF2 Reflection into UML2 compliance levels to provide this capability.
If this change were to be made it could have a significant impact on existing
implementations and, therefore, is outside the scope of an RTF

Constraint [7] in section 14.3 of the MOF2 specification says that visibilities will be ignored, everything is assumed to be public, and name classes are possible and should be avoided. This constraint also appears in section 12.4 EMOF Constraints, constraint [4]. This is necessary for EMOF because it does not support package import or visibility. However, CMOF, which is based on InfrastructureLibrary Constructs does support both package import, namespace visibility, and visibility kind. It is not clear why CMOF would define visibility and then introduce a rule to ignore it. Perhaps this rule should be relaxed. 

On an Object, container() is defined as
result = self.get(self.owningProperty())
where owningProperty() is defined as
result = self.allProperties->select(op| op.isComposite and self.get(op)
<> null)


If I read this correctly, the container of an object is the value of a
property on that object such that isComposite on the property is true
and the value of the property on the object is not null.


How is that not backwards? The value of an object's composite properties
are the objects it *contains*. Don't we want (op|
op.opposite.isComposite and self.get(op) <> null)?

There are some shortcomings in the discussion of the isSet() and unset() operations of the Element class.  In particular, there is no mention of optional properties in the Semantics section of the Element description.

Is is intended that optional properties be covered by the semantics inSingle-valued properties?  If so, how, if at all, does the fact that a property is optional interact with the default for the property?  For example, I assume that notwithstanding the spec language:

If a single-valued property has a default: 
 • It is set to that default value when the element is created. isSet=false 

that an optional property will NOT, in fact, be set, and that isSet would be false. 

This is a question involving ODM as well as MOF XMI and Life-cycle.

 

In ODM we have RDF and OWL defined as MOF meta models, the assumption being, of course, that you can have MOF instances of RDF graphs.  But can you?  In RDF & OWL an instance (at any M level) can have (and frequently does have) multiple types – it is classified by more than one class.  While this is perfectly legal in UML and even in the MOF meta model, I don’t think the concept is supported in XMI or the current life-cycle.  So, can you actually represent RDF in MOF?  If not, the ODM models are not valid – I hope I am wrong about this.

The ability for an instance to be classified by more than one class is a major advantage of RDF and of ontology languages, the C++ heritage in MOF of an instance statically being a member of a single class puts MOF at a disadvantage in relation to these other technologies.  It makes it very difficult to represent different aspects of an instance, as can be seen from the package merge complexities - which would not have been required is we had multiple classification in MOF.  

If this is actually a semantic mis-match between MOF and ODM, is may make more sense to add the capability to MOF since the MOF meta model does not preclude this capability – it is only a restriction of the MOF-PSM (XMI).

Annex B does not have any content - it just announces an intention - so is certainly not Normative as claimed. In fact even the announced intention is wrong: the current intention is for a group of all the main vendors (and others) to create a Java Interface for MOF 2 and submit it to OMG (not JCP) via the RFC process.
 
In fact the Annex really does not belong in the Core specification at all: there is no equivalent Annex for the IDL binding, for example.
 
Proposed resolution
Remove Annex B.

All the URL's mentioned below  appear really stange. My impression was that all such URI's should have a prefix http://schema.omg.org/. Clearly those are random URI's that will never ever exist on the OMG server and need fixing. See omg/02-03-02 to get guidance on what URLs already do or will soon (within the next two months) exist on the OMG server.

Juergen, you need to file this as an issue for the MOF RTF.

Jishnu.

LONJON Antoine wrote: 
Hi Jim,
 
Since Barbara Price has left, uou seem to be the person to contact regarding the MOF specification.
The CMofXMI.xsd has references to imported files that are not available on the OMG web site.
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/cmofextension" schemaLocation="cmofextension.xsd"/>
    <xsd:import namespace="http:///org/omg/uml2/infrastructure/elements" schemaLocation="elements.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/behavioralfeatures" schemaLocation="behavioralfeatures.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/expressions" schemaLocation="expressions.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/redefinitions" schemaLocation="redefinitions.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/constraints" schemaLocation="constraints.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/visibilities" schemaLocation="visibilities.xsd"/>
    <xsd:import namespace="http:///org/omg/uml2/infrastructure/super" schemaLocation="super.xsd"/>
    <xsd:import
        namespace="http:///org/omg/uml2/infrastructure/namespaces" schemaLocation="namespaces.xsd"/>

Do you know where these files are available. I think they should also be posted on the OMG published XSD files in the appropriate directory that Linda is currently creating.

In the specification [The “lower” bound of a MultiplicityType to be “Unbounded.” [C-54]] [The “upper” bound of a MultiplicityType cannot be less than 1. [C-56]] and it should be [The “upper” bound of a MultiplicityType to be “Unbounded.” [C-54]] [The “lower” bound of a MultiplicityType cannot be less than 1. [C-56]]

This will not result in significant changes to the spec itself (beyond replacing UML 2.0 with UML 2.1) but will have a significant change on the XMI due to the nature of the changes in UML

EMOF does not support identification of the opposite role name
for a non-navigable association, however QVT requires such role
names to be used. OCL defines an implicit role name, but UML
graphics supports arbitrary names.


At the EclipseCon OMG symposium in February, it seemed appropriate
to resolve the limitation in the following way.


An opposite role name may be denoted by a Comment Comment with the
inner Comment defining a formal function for the outer Comment.
Thus in:


<ownedAttribute name="forward" ...>
  <ownedComment body="backward">
    <ownedComment body="http://schema.omg.org/spec/MOF/2.0/emof.xml#Property.oppositeRoleName"/>
  </ownedComment>
</ownedAttribute>


"backward" is defined as the oppositeRoleName of "forward".


This practice makes the missing information available, and avoids
any changes to the MOF meta-model and so avoids introducing any
additional Property instances that might bloat existing usage.


It would be helpful if a future MOF version, or an addendum to existing
versions, endorse this practice.


An equivalent Ecore EAnnotation and cross-conversion was introduced
via https://bugs.eclipse.org/bugs/show_bug.cgi?id=229998 and forms
part of EMF 2.4.0 that accompanies Eclipse 3.4 (Ganymede).