Clause 8 should alter MOF 2.4.1’s containment constraints that an object may only have one container, so that they do not apply in an SMOF context. In particular, in MOF 12.5, several constraints under Property::isComposite== true need to be reworded

SMOF, when merged into MOF, needs to modify MOF’s constraints about an object having just one container.

SMOF Compatibility and Incompatibility are kinds of Constraint. As such they must have a specification, which is a kind of ValueSpecification.

I believe that Incompatibility leaves no more to be said: two types are Incompatible if they are related by an Incompatibility, regardless of what the specification evaluates to. So what should the specification be?

Compatibility says (9.1.2.2) that two compatible classes may co-exist “as long as the constraint’s specification evaluates to true”. If the constraint is to be OCL, this implies some binding to define the evaluation context for the constraint. What, for example, is self bound to? According to 10.1.9, the constraint is evaluated “in the context of the first constrained element”.

I think this is inconsistent with 9.1.2.2. This gives a direction to Compatibility: the instance is first classified by the “target class”, and second classified by the “source class”. 9.1.2.2 says the source type is constrainedType->at(1) and the target type is constrainedType->at(2). Since the compatibility constraint must be evaluated against the instance as classified by the target class, then the type of self must be the target class, which makes 10.1.9 wrong. Looking at an example: Person is compatible with LicensedDriver if age >= 17. The instance must first be classified as Person, and secondly by LicensedDriver. So Person is the target type (according to 9.1.2.2) and LicensedDriver is the source type. Then the constraint self.age >= 17 will make sense if an appropriate OCL binding is defined (which implies a modification to the OCL spec, which we need anyway).

I actually think that the target type ought to be constrainedType->at(1) and the source type constrainedType->at(2), to emphasize that the instance has the target type before the source type.

Anyway, the wording of Compatibility semantics should say type, not class.

This issue is resolved by the resolution to issue 17163.
Revised Text:
None.
Disposition: Closed – Duplicate / Merged – see issue 17163

Reclassify should throw an exception if oldMetaClass contains any metaclass that does not currently directly classify the object.

agreed

The Metamodel Effect subsections (11.2.1, 11.2.2, 11.2.3, 11.2.4) currently show relevant portions of the SMOF metamodel diagrams. Instead of showing the SMOF metamodel diagrams, these subsections should show the meaning of each SMOF Profile stereotype in terms of the set of corresponding instances of the SMOF Metamodel classes / associations.

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Semantically, AspectOf (Section 11.2.1) corresponds to an SMOF::Compatibility, which is a kind of SMOF::Constraint. However, the profile also allows using a UML::Constraint to specify the compatibility constraint. It is unclear whether the intent of the profile is that it's the combination of the AspectOf-stereotyped Generalization + the Constraint applied to that AspectOf-stereotyped Generalization that corresponds to a single SMOF::Constraint

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

SMOF says it gives support to "semantic structures", in particular citing "structural rigidity of object-oriented programming systems" (Section 1, 7.1), including "type / classification systems" as a problem area, but in contrast to typical "semantic" languages, SMOF assumes types are disjoint unless otherwise stated (see Section 9.1.2.1, Incompatibility, Semantics, first paragraph, last sentence), and even prevents reclassification between general and special types by default (see use case in four earlier issues starting with AspectOf, and the immediately previous issue). Typical "semantic" applications will be forced to define compatibility over most types in their models. Perhaps this burden could be reduced by compatiblity between types as the default, or maybe a batch compatibility declaration at the level of packages.

Resolved by resolution to issue 17150: Metaclasses are considered compatible by default.
Revised Text:
None. Resolution provided by resolution to issue 17150.
Disposition: Closed – Duplicate / Merged – see issue 17163

The default restriction against reclassification between generalizations (see Section 9.1.2.3, Semantics, first sentence, and the four earlier issues starting with AspectOf) is not aligned with typical OO programming languages, which allow runtime instances to be bound to variables typed by a superclass of the class from which instances are created. These programming capabilities enable an class instance to be viewed as an instance of one of the superclasses, but this common programming use case requires a special declaration in SMOF.

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 11.2.1 (AspectOf), Description, fourth paragraph (the starting "Applying AspectOf to a Generalization") is "exactly equivalent", but should say "semantically equivalent". Aspect is not exactly equivalent to the CompatibleWith pattern given, or you could just use the CompatibleWith pattern as stated and it would be understood the same way by the modeler. Other uses of the same CompatibleWith pattern are not aspects, see Issue 17149 (AspectOf encourages misuse in common use case).

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 11.2.1 (AspectOf), Description, third to last paragraph (the one starting "When the subtype/aspect is added"), oclIsKindOf() is always true for the superclass and subclass, should be oclIsTypeOf().

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

The EquivalentClass and IncompatibleWith stereotypes are redundant with the EquivalentClass and ComplementOf stereotypes in the UML Profile for OWL, see the Ontology Definition Metamodel.

The FTF membership agrees that the Stereotypes in the ODM Profile are semantically similar, however decided that SMOF shall not have a Profile and provide these semantics in the metamodel by SMOF Language Tags on Constraint. See resolution to issue 17163.
Revised Text:
None.
Disposition: Closed – Duplicate / Merged – see issue 17163

MOF is a subset /constrained version of UML now, as I understand it, but SMOF is not. MOF subsetting UML had many benefits, why not SMOF?

The constraint mechanism in SEMOF::Reflection needs to be revised to make SMOF a subset of UML. The classes SEMOF::Refelction::Compatibility and SEMOF::Reflection::Incompatibility shall be removed and replaced by a constraint carrying an OpaqueExpression with language = “SMOF” and the body holding the values “equivalent” and “disjoint”.
As a consequence of this change, regular UML tooling is sufficient to create and maintain SMOF metamodels, therefore the SMOF Profile is no longer needed and shall be removed.
SMOF reuses and completes the latent support for multiple classification and reclassification existing in UML. However, a more detailed description of the semantics and side effects of multiple and/or dynamic classification is needed.

In Figure 3 (SMOF Classification Constraints), Incompatibility::constrainedType does not need to be ordered, incompatibility is symmetric.

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

Compatiblity::isRequired = true is redundant with Generalization (both declare all instances of one type are instances of another), why is isRequired needed? It would be simpler to enable Generalization to be used without modifying it's end types (Pete claims it doesn't even currently require such modification, even though most implementation modify the specialized type).

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

The profile uses very different language from the metamodel extensions to describe what presumably is the same semantics. For example, the semantics of Compatibility constraint specifications is much more spelled out in the metamodel extensions than that the profile, (and also see the previous issue). It would help prevent misinterpretation and improve consistency if the same text is used in both sections as much as possible.

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 11.2.2 (CompatibleWith) Description, third paragraph, first sentence mentions adding or removing the client classifier, but not the supplier classifier, which isn't the same as Section 9.1.2.2 (Compatibility), Semantics, first, which doesn't distinguish between the constrained types.

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 11.2.2 (CompatibleWith) Description, third paragraph, first sentence refers to a "subject classifier", what is a subject classifier?

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Figure 6 (SMOF Profile) uses Dependency as base, but the metamodel extensions in Chapter 9 use Constraint. Why not use Constraint in the profile?

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed. [See also resolution to issue 17163]
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 9.1.2.2 (Compatibility), Semantics, first paragraph, last sentence, should clarify that disallowing multiple classification does not prevent multiple classification due to generalization. Otherwise instances can't be created for types that have generalizations

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 9.1.2.2 (Compatibility), Semantics, explains how to capture equivalance, and it would be good also to explain that isRequired=true with a constraint spec that always evaluates to true is the same as generalization between the source and the target.

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 9.1.2.2 (Compatibility), Semantics, should clarify whether
instances can be taken into account when evaluating the constraint
specification (compare to the AspectOf, Attributes, isRequired, next to
last paragraph in the description). If they can, the last sentence
presumably should replace evaluates to true" with "evaluates to true for
all possible instances of either type". My understanding is the
Compatible constraint specification must evaluate to true for an
instance to be classified under both types, so if the constraint spec
can account for instances, then all instances (past, present, and
future) of both types must satisfy the constraint spec for the types to
be equivalent.

Explicit Compatibility has been removed from the metamodel and semantics.
Revised Text:
Resolution for this issue is included in the resolution for issue 17163.
Disposition: Closed – Duplicate / Merged – see issue 17163

Section 9.1.2.2 (Compatibility), Attributes, says if isRequired=true, and the constraint spec evaluated to true, instances of the source will be classified as instances of the target. Will the instances be unclassified from the target when they are unclassified from the source? If not, this construct won't emulate generalization, and can't capture type equivalance (see last sentence of Semantics), wasn't that the intention?

Resolution:
Compatibility has been removed from SMOF; see 17150.
Revised Text:
None.
Disposition: Closed – No Change

The last three issues indicate modelers shouldn't be forced to define compatibility for types related by generalization. Such reclassifications are so common as knowledge about instances changes that the modeler would need to apply compatibility to all generalizations in their models. Perhaps this could be addressed by assuming unrequired compatibility between types and their generalizations. Another option might be to batch declare compatibility for generalization at the level of packages.

This issue highly overlaps with issue 17150, therefore the resolution for issue 17150 will resolve the problems reported in both , issue 17150 and 17152.
Revised Text:
None. Resolved by resolution to issue 17150.
Disposition: Closed – Duplicate / Merged – see issue 17163

Figure 6 (SMOF Profile) has private visibility on the properties. Is that intended?

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed.
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

SMOF needs to clarify the algebraic properties of Compatibility and Incompatibility, as follows:

1. Is Compatibility transitive? I.e. if X C Y and Y C Z, is it valid to multiply classify an object by X and Z without Y being present?

2. How does Compatibility interact with subtyping? If X C Y, does that mean that subtypes of X are also compatible with Y? How about X being compatible with subtypes of Y?

3. How does Incompatibility interact with subtyping? Same questions as (2).

Compatibility has been removed, see the resolution to 17150. This resolves parts (1) and (2) above. Incompatibility is replaced by disjoint (see 17163).

Section 9.1.2.3 (Element, as extended), Semantics, first sentence, says reclassification is constrained by Compatibility elements, but this would mean an instances of a type cannot be reclassified as one of its subtypes without using compatibility, see AspectOf example in the previous issue. This is such a typical use case that it would be significant burden to require modelers to explicitly define compatibility for it.

Metaclasses will be considered compatible by default and without need for specific marking, unless explicitly marked disjoint. There will no longer be any Compatibility elements. This will also resolve issue 17152. The required model changes are addressed by the resolution to issue 17163, which becomes a prerequisite to this resolution

Section (11.2.1) AspectOf, Description, is too strong an interpretation of reclassification to subtypes, and encourages modelers to use aspects when that is not what they mean. For example, if Mammal generalizes Dog, some instances of Mammal might be dogs, but the modeler doesn't know it yet. When it becomes known that a particular instance of Mammal is a dog, it can be reclassified under Dog. This doesn't make Dog an aspect of Mammals. To support this example, modelers would likely think they need to apply the AspectOf stereotype to the generalization between Mammal and Dog, which won't make sense. This construct needs to be rethought in context of other use cases and perhaps additional stereotypes for more cases.

The FTF members agreed on removing the SMOF Profile entirely since starting with UML 2.4.1, MOF and UML are based on the same metamodel. Therefore compliant UML tools can be used to create MOF models and a separate SMOF Profile is no longer needed.
Revised Text:
The SMOF Profile (section 11) is removed from the specification; therefore no text change is needed.
Disposition: Closed – Duplicate / Merged – see issue 17163

It is unclear what what relationship to deduce between a pair classifiers where neither "CompatibleWith" nor "IncompatibleWith" has been asserted between them. Is the default assumption that they are compatible, not compatible, or that there is no information?

The description of "CompatibleWith" (11.2.2) says:

" ... if AspectOf or CompatibleWith does not exist between two classes (or their supertypes) an instance may not be explicitly classified by both classes ..."

What is the meaning of "may" in that sentence? If the intended meaning is "shall", then it's clear that in the absence of CompatibleWith between two classes, those two classes are not compatible. However, if the intended meaning is indeed "may/might", then the the sentence does nothing to remove the ambiguity.

It is also unclear what behaviour is intended if both CompatibleWith and IncompatibleWith exist between the same pair of classifiers. Presumably this is an error, but how exactly shall a compliant implementation behave under these circumstances?

The semantic issue regarding Compatibility is addressed by the resolution to issue 17150; the issue raised against the Profile (clause 11) has no effect, as the Profile has been removed from the specification.
Revised Text:
No change.
Disposition: Closed – Duplicate / Merged – see issue 17163

Some spelling mistakes in the beta specification:

"clientt" (p 32, section 11.2.2, "Where CompatibleWith exists between two classes it is then permissible to add or remove the clientt ... ")

"sever" (p 9, section 7.4, "Note that there are sever subclasses of ...")

Fix spelling mistakes.
Since clause 11 will be removed from the specification, the misspelling of “clientt” needs no correction

Section 7.1 includes this sentence:

"In reality, objects are subject to constant variations without changing their identity or their fundamental type, they undergo changes in classifications and assumed roles."

The term "fundamental type" doesn't seem to have a formal definition in either MOF or SMOF, so it's not clear what the term means in this context. Please further clarify the implicit distinction being made here between "type" and "fundamental type" (or remove the term).

Remove the words “or their fundamental type”.

I could not get the UML Profile XMI to load, and it has MagicDraw specifics.

The profile XMI also has a stereotype called Constraint which had no base class and was not in the spec – so it should be deleted.

Create a correct profile XMI

SMOF should be updated to 2.4 before finalization to be consistent with UML, MOF and XMI.

The primary change needed to update to 2.4 is to change the way that SMOF merges the MOF packages to incorporate the fact that MOF 2.4 is based on UML::Classes::Kernel, from Superstructure, instead of Infrastructure packages used to define earlier revisions of MOF.
Various cross-references need to be changed. While we are at it, let’s use the latest available version of OCL

In clause 12 of SMOF, the namespaces (such as xmlns:xmi=http://www.omg.org/spec/XMI/20100101) do not refer to any actual published specification. Furthermore, the xmlns:uml namespace inconsistently refers to the XMI spec.

Correct the namespaces to refer to valid specifications.