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 7605: no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema
Issue 8267: MOF 2 Core: undefined behavior of convertToString
Issue 8269: MOF 2.0 Core: Inconsistency about use of defaults
Issue 8751: Relations
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 13127: Section 9.1: paragraph needs clarification
Issue 13444: Annex A refers to non-existing CMOF file
Issue 15118: We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification
Issue 15143: Outdated descriptions
Issue 15271: MOF 2.0 9.1 Contradictory isSet default value semantics
Issue 15397: Remove isId and uri
Issue 15398: Use UML models ‘as is’ for metamodels
Issue 15820: Update and formalize the constraints that MOF applies to UML models
Issue 15821: Remove the distinction between isSet and the default value
Issue 15824: Fix resolution to issue 15398 from MOF2.4 ballot 2
Issue 15826: Delete the redundant package MOF::CMOFExtension described in clause 14.4
Issue 15827: Fix resolution to issue 6905 from MOF2.4 ballot 1
Issue 15830: Delete unenforceable MOF constraint 12.4 [7]
Issue 15831: Delete incompletely specified MOF operation Object::verify() in 15.4 and in diagrams in clause 13
Issue 15832: Move operations from 9.1 Element to 9.3 Object: equals, get/set/unset/isSet
Issue 15859: Problems in MOF operations delete(), invoke() and isInstanceOfType() operations
Issue 16329: No unambiguous way in MOF 2.4 to serialize UML 2.4's StructuredActivityNode

Issue 7605: no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema (mof2core-rtf)

There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist? 

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

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

This is outside the scope of the RTF and is being addressed by the SMOF RFP 

Disposition:	Closed, no change

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 was raised on MOF 1.4 (which is formal 02-04-03) and no longer applies

Disposition:	Closed, no change

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

The following paragrph is not stated clearly and can cause an improper interpretation of the MOF object model: Class Element is the superclass of all model elements in MOF, and is the superclass of all instances of MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Element, MOF supports any number of meta layers as described in Chapter 7, “MOF Architecture.” A better way to say it may be: Class Element is the superclass of all classes defined in MOF, and is a superclass of the metaclass of all MOF model elements. Each element can access its metaClass in order to obtain a Class that provides a reflective description of that element. By having both MOF and instances of MOF be rooted in class Element, MOF supports any number of meta layers as described in Chapter 7, “MOF Architecture.” 

Annex A (which is normative), refers to the availability of the XMI for CMOF in the OMG document ptc/04-10-17. However, this document is not available at the OMG web site (at least not as a publicly available, searchable document). The annex being normative and the spec being publicly available, it would follow that a referenced ptc document would be publicly available. Without an available normative XMI for CMOF, it is not possible to produce a conforming implementation of it. I tried the MOF2.cmof file in the non-normative zip file (document 03-04-08). However, this file is not usable, as it has several errors and missing information.

"We urgently need simple and clear rules we can follow to determine, for
each file associated to a given specification, the following:


the value of the cmof:Package or cmof:Profile uri property per clause 10.2
of the MOF2 Core specification.


the XMI namespace URI and the correspondence between an XMI namespace and
anything that is a kind of cmof package, including a profile.


the values of the CMOF tags: org.omg.xmi.nsPrefix and org.omg.xmi.nsURI


Based on the UML 2.3 files, it seemed that the OMG document number - e.g.,
ptc/2009-09-01 for UML 2.3 or ptc/2010-03-01 for SysML 1.2 would have been
sufficient to set unique URIs for each identifiable file document. If this
is incorrect, then we need clear direction for how to do this."

Any rules for these values are a matter of (OMG) policy not for the specifications. The MOF 2 Facility specification provides a basic scheme for use of Package::uri in constructing URLs.

Disposition:	Closed, no change

The document still contains large chunks of introductory material that date from the original MOF 2.0 submission and no longer apply. They should be deleted or updated as appropriate.

 

The statement under Element::isSet


"If the Property has multiplicity upper bound of 1, isSet() returns true if
the value of the Property is different than the
default value of that property."


is inconsistent with the statement half a page later on semantics


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


the implementation description strongly implies that it is the second
statement that is correct.


        Regards
                        
                Ed Willink

With the conclusion of Ballot 10 of the UML 2.4 RTF, Package:uri and Property:isId have been added to UML so there is no need to add them in MOF.

Proposed resolution:

            Update Figure 10.1 to remove Package and Property.

            Remove sections 10.2 Package and 10.3 Property and ‘shuffle up’ the remaining sections in Chapter 10.

            Add the following constraint, formerly in section 10.3, to sections 12.4 and 14.3:

Property.isID can only be true for one Property of a Class.

Requiring a format conversion to make a UML model into a MOF metamodel has proved a significant impediment and time-waster: especially since no UML tools directly support Infrastructure as originally envisioned.

There is no reason why MOF could not use suitably constrained UML models directly, especially as UML 2.4 has now added Property::isId and Package::uri – the only structural differences in MOF.

 

Proposed resolution (outline):

General:

            Change section 3 introduction and reference to refer to UML 2.4 Superstructure instead of Infrastructure 

            Update Annex A to use UML 2.4 URIs

For CMOF:

Update section 14 to explain the above

Update Figure 14.1 to show CMOF merging UML Kernel instead of Constructs

Update Figure 14.2 to show the same elements but as defined in UML Kernel 

Update section 14.3 CMOF Constraints with the following constraints, and include OCL for these and the original constraints:

-          A CMOF metamodel may not include instances of the following UML metaclasses:

o   InstanceValue

o   InstanceSpecification

o   Slot

o   Interface

o   AssociationClass

o   GeneralizationSet

-          The following properties must be empty

o   Class::nestedClassifier

o   Property::qualifier

-          The value of Property::defaultValue and Parameter::defaultValue must be of kind LiteralSpecification

-          The value of MultiplicityElement::lowerValue and upperValue must be of kind LiteralInteger and LiteralUnlimitedNatural respectively

-          Dependencies (and subclasses) will be ignored

            

For EMOF:

Update section 12 to explain the above

Update Figure 12.1 to show CMOF merging UML Kernel instead of Basic

Update Figure 12.2 to show the same elements but as defined in UML Kernel 

Update section 12.4 EMOF Constraints with the following additional constraints (to those listed for CMOF above), and include OCL for these and the original constraints:

-          An EMOF metamodel may not include instances of the following UML metaclasses:

o   Association

o   Constraint

o   DataType (only instances of PrimitiveType and Enumeration)

o   Expression

o   OpaqueExpression

o   ElementImport

o   PackageImport

o   PackageMerge

-          The following properties must be empty

o   Parameter::defaultValue

o   Parameter::direction

o   Property::subsettedProperty

o   Property::redefinedProperty

At the moment the constraints do not reflect the more rigorous process that was deployed when creating the MOF metamodel for UML 2.4.

The MOF spec has been inconsistent about whether isSet is true if the value is explicitly assigned the default value.

Since XMI has no means to serialize otherwise, then it should be true.

This is related to XMI issue 14628.

MOF::Reflection must merge UML::Classes::Kernel instead of importing it because it defines MOF::Reflection::Element as an increment of UML::Classes::Kernel::Element
MOF::Identifiers does not need to import PrimitiveTypes since MOF::Common already does and that non-conflicting visible elements are imported transitively
MOF::Extension needs to import UML::Classes::Kernel, it does not need to import PrimitiveTypes since Kernel does this already via the merge of Core::Constructs, which imports PrimitiveTypes
MOF::CMOFReflection must merge MOF::Reflection because it uses MOF::Reflection::Object and also defines MOF::CMOFReflection::Element and MOF::CMOF::Reflection::Factory as increments of the classes in MOF::Reflection

Delete the redundant package MOF::CMOFExtension described in clause 14.4

Change the Element/Tag owner composite association to a composite association that symmetrically subsets the Element owner/ownedElement derived composite association from UML.

Delete unenforceable MOF constraint 12.4 [7]

Delete incompletely specified MOF operation Object::verify() in 15.4 and in diagrams in clause 13

As currently specified in 9.1, it makes sense to have these operations available in Object, not Element.
Pete concurred with me on making this change in MOF2.4; he said that these operations may have been shuffled at the last minute during MOF2.0 finalization.

13.3 describes an operation Object::delete() that does not appear in figure 13.2.
The operation isInstanceOfType() makes sense for an Element but not for an Object where it is misspelled.
The operation invoke() should be defined only on Object and should return set of Objects instead of a set of Elements.


Resolution:


in 13.3, delete the following operations:
        delete()
        isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean 


replace: 
        invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*]
with:
        invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]


in the metamodel, add:
        MOF::CMOFReflection::Object::invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]


in 13.4, delete the operation:
        invoke(op:Operation, arguments : Argument[0..*]) : Element[0..*]


in 13.4, rename the operation:
        instanceOfType(type: Class, includeSubtypes: Boolean): Boolean
to:
        isInstanceOfType(type : Class, includeSubtypes : Boolean) : Boolean


Update the diagrams & metamodel accordingly

We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time. 
MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
Does XMI support that?

So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.  
	
fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.
	
Any suggestions? Don't you think we should fix that somehow

Resolution:
The problem is that the combination of the UML, MOF and XMI specs taken together do not provide an adequate specification of how to serialize StructuredActivityNodes, which leads to ambiguity.
Currently, the ownership of StructuredActivityNode by Activity is derived, and is a subset of Activity::node and Activity::group.  This leads to the question of whether a StructuredActivityNode should be serialized as a node, as a group, or both.  This has obvious impacts on model interchange, and also impacts fUML.
The solution is to make the ownership of StructuredActivityNode by Activity non-derived, and then fix the MOF semantics and XMI serialization rules to ensure that a StructuredActivityNode is serialized in a structuredNode element, and not in a node or a group element.
This resolution fixes the MOF part; there are two counterpart issues corresponding to the UML and XMI parts.
MOF 2.4 currently states that an Element may only have a single slot that refers to its container.  In the MOF semantics, it states for ClassInstance “At most one slot for an isComposite property may have a value. (This needs more work if the owner reference is not navigable)”.  In fact this ought to say “At most one owning slot, i.e. a slot whose property is opposite an isComposite property, may have a value”. The semantics also specifies Object::owningProperty(), unambiguously declaring that an object only has one owning slot at a time.
The issue is that there is no correct specification of which property provides the owning slot where there is redefinition.  In the case of StructuredActivityNode::activity, it redefines ActivityNode::activity and ActivityGroup::inactivity.  MOF needs to be clear that in such a case it is the slot for the redefining property that is the actual owning slot.  Armed with that information, the XMI spec can then say that the correct element to serialize is the one opposite the actual owning slot.
The semantics correctly states for ObjectInstance “the stored StructuralFeatures  … exclude Properties that have been redefined”.  However the main problem is in the definition of Instance::propertySlot(), which is supposed to return the slot corresponding to a particular property.  This in turn calls a function called originalDefinition() which incorrectly climbs up the chain of redefinitions and subsettings to find the highest property in the chain.  This is wrong on two counts: firstly it is the wrong algorithm in principle, because it conflicts with “excluding properties that have been redefined”, and secondly it is wrong to assume that there is only one redefinition/subsetting chain, because in general there are several.
The function originalDefinition is misnamed as well as being ill-conceived.  Instead, we need a function applicableDefinition that determines, for a given instance and a given property, which slot is applicable. 
The semantic function allSlottableProperties is incorrect; it misunderstands and reverses the role of redefinition, it confuses subsetting and redefinition, and it has an incorrect “not” in its attempt to exclude association-owned ends.
The semantic function owningProperty is incorrect because it does not take into account the effect of redefinition.
The semantic function allProperties is extensively used but has no definition.
Note: there are many other syntactic inconsistencies in the semantic definition of MOF 2.4, such as the inconsistent use of body conditions vs postconditions, the inconsistent use of operation names vs result, and the omission of operation call brackets.  This urgent resolution does not attempt to fix those issues.

Revised text:
In Section 15.2, under ClassInstance:
Replace:
2. At most one Slot for an isComposite property may have a value. (This needs more work if the owner reference is not navigable).
by:
2. At most one owning Slot, i.e. a Slot whose property is opposite an isComposite property, may have a value.
In Section 15.8, Additional Operations:
Replace the following definition:
[1] This gives all of the properties in the namespace of the class (including inherited) that require a slot: it excludes properties owned by Associations, derived properties and those that subset or redefine another property (in which case that property will provide the slot and the redefinition will just restrict the values)
Class::allSlottableProperties(): Set(Property);
allSlottableProperties = member->select(p| p.oclIsKindOf(Property) and
not (self.allParents() includes p.namespace)
-- excludes foreign association ends
not(p.isDerived) and
isEmpty(p.redefinedProperty) and
isEmpty(p.subsettedProperty) )

Replace it by:
[1] This gives all of the owned properties of the class (including inherited) that require a slot: it excludes derived properties and those that are redefined in the same classproperties.
Class::allSlottableProperties(): Set(Property);
allSlottableProperties = self.allNonDerivedProperties ()->reject( p | 
    (self.allNonDerivedProperties()->select(r |
              r.allRedefinedProperties()->intersection(self.allProperties())->includes(p))
[2] All the non-derived owned properties (including inherited) of a class.
Class::allNonDerivedProperties(): Set(Property);
allNonDerivedProperties = self.allProperties() -> select( p | not(p.isDerived))
[3
[2] All the non-redefined properties (including inherited) of a class.
Class::allProperties(): Set(Property);
allProperties = member->select(p |  p.oclIsKindOf(Property) and p.owner = self)n |  

[4                                  n.oclIsKindOf(Property))->collect( p |
                                              p.oclAsType(Property))

[3] All of the properties directly or indirectly redefined by a property.
Property::allRedefinedProperties() : Set(Property)
allRedefinedProperties = 
    if
       self.redefinedProperty->isEmpty
    then 
       Set{}
    else 
       self.redefinedProperty->union(
              self.redefinedProperty->collect(r | r.allRedefinedProperties())()))
      

Replace the following definition:
[2] This returns the slot corresponding to the supplied property. For redefining properties it will be the redefined one.
Note that derived properties will only have slots if the redefine a non-derived one so the result may be null.
Instance::propertySlot(Property p): Slot
propertySlot = self.slot->select(definingFeature = p.originalDefinition))
Replace it by:
[54] This returns the slot corresponding to the supplied property. For redefined properties it will be the slot corresponding to the redefining one.
Note that derived properties will only have slots if they are redefined by a non-derived one so the result may be null.
ObjectInstance::propertySlot(Property p): Slot
propertySlot = 
  if 
    self.oclIsKindOf(ClassInstance)
  then 
    self.slot->any(definingFeature =
                                    p.applicableDefinition(self.oclAsType(ClassInstance).classifier))
  else
     self.slot->any(definingFeature =  p)
Replace the following definition:
[3] This returns the original definition of a Property through any number of redefinitions and subsetting.
Property::originalDefinition(): Property
post: (isEmpty(redefinedProperty) and isEmpty(subsettedProperty) and result = self) or
(notEmpty(redefinedProperty) and result = redefinedProperty.originalDefinition()) or
(notEmpty(subsettedProperty) and result = subsettedProperty.originalDefinition())
Replace it by:
[65] This returns the property that defines the slot that will carry the data for the requesting property in an instance of the class c.
Property::applicableDefinition(Class c): Property
applicableDefinition = c.allSlottableProperties().any(p | 
       p.allRedefinedProperties()->includes(self))

Replace the following definition:

[4] This returns the single Property that represents the current owner of the Object based on current instance values; may be null for top level objects

Object::owningProperty(): Property
post: result = self.allProperties->select(op| op.opposite <> null and op.opposite.isComposite and self.get(op)<> null)
Replace it by:
[76] This returns the single Property with a slot that represents the current owner of the Object based on current instance values; may be null for top level objects.

Object::owningProperty(): Property modeled as ClassInstance::owningProperty(): Property
owningProperty = self.classifier.allSlottableProperties()->select(op | 
    op.opposite <> null and op.opposite.isComposite and self.get(op)<> null)

Add the following definition:

[7] All the non-redefined properties of an object.

Object::allProperties(): Set(Property) modeled as ClassInstance:: allProperties (): Set(Property)
allProperties = self.classifier.allProperties()
Renumber all of the remaining definitions to follow on from [8].