${taskforce.name} Avatar
  1. OMG Task Force

2nd SMOF FTF — Closed Issues

  • Key: SMOF_
  • Issues Count: 29
Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
SMOF_-31 reclassify should check its arguments SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-30 Clause 8 should alter MOF’s containment constraints SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-29 SMOF Issue: Compatibility and Incompatibility constraint semantics SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-28 Metamodel Effect subsections should use instances SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-27 AspectOf extending Generalization with Constraint unclear SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-26 AspectOf equivalence SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-25 oclIsKindOf / ocIsTypeOf SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-24 EquivalentClass and IncompatibleWith stereotypes redundant with ODM SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-23 SMOF cumbersome for semantic applications SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-22 Compatibility complicates common programming use case SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-21 Compatiblity::isRequired = true redundant with Generalization SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-20 SMOF not a subset of UML SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-19 Incompatibility::constrainedType does not need to be ordered SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-18 Profile and metamodel extension text alignment SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-17 Profile compatibility semantics different from metamodel extension SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-16 Subject classifier SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-15 Profile using Constraint, why not? SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-14 When compatibility is the same as generalization SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-13 Compatiblity constraints and instances SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-12 Required semantics when source instances unclassified SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-11 Default compatibility for generalization SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-10 Compatibility semantics clarification for generalization SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-9 Extended element semantics complicates common use case SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-8 AspectOf encourages misuse in common use case SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-7 Property visibility in profile SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-6 Issue with SMOF semantics SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-5 CompatibleWith/IncompatibleWith and the Law of the Excluded Middle SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-4 Two spelling mistakes SMOF 1.0b2 SMOF 1.0 Resolved closed
SMOF_-3 What is the definition of "fundamental type"? SMOF 1.0b2 SMOF 1.0 Resolved closed

Issues Descriptions

reclassify should check its arguments

  • Key: SMOF_-31
  • Legacy Issue Number: 17506
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Wed, 18 Jul 2012 04:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    agreed

  • Updated: Sat, 7 Mar 2015 08:57 GMT

Clause 8 should alter MOF’s containment constraints

  • Key: SMOF_-30
  • Legacy Issue Number: 17505
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    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

  • Reported: SMOF 1.0b2 — Wed, 18 Jul 2012 04:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:57 GMT

SMOF Issue: Compatibility and Incompatibility constraint semantics

  • Key: SMOF_-29
  • Legacy Issue Number: 17281
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:57 GMT

Metamodel Effect subsections should use instances

  • Key: SMOF_-28
  • Legacy Issue Number: 17280
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:57 GMT

AspectOf extending Generalization with Constraint unclear

  • Key: SMOF_-27
  • Legacy Issue Number: 17279
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    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

  • Reported: SMOF 1.0b2 — Wed, 28 Mar 2012 04:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:57 GMT

AspectOf equivalence

  • Key: SMOF_-26
  • Legacy Issue Number: 17171
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

oclIsKindOf / ocIsTypeOf

  • Key: SMOF_-25
  • Legacy Issue Number: 17170
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

EquivalentClass and IncompatibleWith stereotypes redundant with ODM

  • Key: SMOF_-24
  • Legacy Issue Number: 17167
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SMOF cumbersome for semantic applications

  • Key: SMOF_-23
  • Legacy Issue Number: 17166
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Compatibility complicates common programming use case

  • Key: SMOF_-22
  • Legacy Issue Number: 17165
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Compatiblity::isRequired = true redundant with Generalization

  • Key: SMOF_-21
  • Legacy Issue Number: 17164
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

SMOF not a subset of UML

  • Key: SMOF_-20
  • Legacy Issue Number: 17163
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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?

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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.

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Incompatibility::constrainedType does not need to be ordered

  • Key: SMOF_-19
  • Legacy Issue Number: 17162
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Profile and metamodel extension text alignment

  • Key: SMOF_-18
  • Legacy Issue Number: 17159
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Profile compatibility semantics different from metamodel extension

  • Key: SMOF_-17
  • Legacy Issue Number: 17158
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Subject classifier

  • Key: SMOF_-16
  • Legacy Issue Number: 17157
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Profile using Constraint, why not?

  • Key: SMOF_-15
  • Legacy Issue Number: 17156
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

When compatibility is the same as generalization

  • Key: SMOF_-14
  • Legacy Issue Number: 17155
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Compatiblity constraints and instances

  • Key: SMOF_-13
  • Legacy Issue Number: 17154
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Required semantics when source instances unclassified

  • Key: SMOF_-12
  • Legacy Issue Number: 17153
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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?

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Default compatibility for generalization

  • Key: SMOF_-11
  • Legacy Issue Number: 17152
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Compatibility semantics clarification for generalization

  • Key: SMOF_-10
  • Legacy Issue Number: 17151
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Extended element semantics complicates common use case

  • Key: SMOF_-9
  • Legacy Issue Number: 17150
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

AspectOf encourages misuse in common use case

  • Key: SMOF_-8
  • Legacy Issue Number: 17149
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    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.

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Property visibility in profile

  • Key: SMOF_-7
  • Legacy Issue Number: 17148
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Wed, 22 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Issue with SMOF semantics

  • Key: SMOF_-6
  • Legacy Issue Number: 17132
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Fri, 17 Feb 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

CompatibleWith/IncompatibleWith and the Law of the Excluded Middle

  • Key: SMOF_-5
  • Legacy Issue Number: 17036
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

    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?

  • Reported: SMOF 1.0b2 — Mon, 23 Jan 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

Two spelling mistakes

  • Key: SMOF_-4
  • Legacy Issue Number: 17035
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Mon, 23 Jan 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

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

  • Updated: Sat, 7 Mar 2015 08:56 GMT

What is the definition of "fundamental type"?

  • Key: SMOF_-3
  • Legacy Issue Number: 17034
  • Status: closed  
  • Source: Object Management Group ( Andrew Watson)
  • Summary:

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

  • Reported: SMOF 1.0b2 — Mon, 23 Jan 2012 05:00 GMT
  • Disposition: Resolved — SMOF 1.0
  • Disposition Summary:

    Remove the words “or their fundamental type”.

  • Updated: Sat, 7 Mar 2015 08:56 GMT