1. OMG Mailing List
  2. MOF 2.6 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: mof2core-rtf
  • Issues Count: 36

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF26-35 org.omg.emof.oppositeRoleName MOF 2.5 open
MOF26-36 The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier MOF 2.5 open
MOF26-34 Conflicting statements about tag multiplicity MOF 2.5 open
MOF26-33 MOF Versioning & Development Lifecycle Spec (MOF VD) 2.0: How are VersionedExtents created? MOFVD 2.1 open
MOF26-32 MOF2 Versioning Issue: Include annotated examples from presentation MOFVD 2.0b1 open
MOF26-24 MOF Facility Object Lifecycle (FOL) 2.0: Is there a URIStor or not? MOFFOL 2.0b1 open
MOF26-25 MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram MOFFOL 2.0b1 open
MOF26-26 MOF Facility Object Lifecycle (MOF FOL) 2.0: inconsistency about Facility::getWorkspace() MOFFOL 2.0b1 open
MOF26-27 Section 7 of formal/2010-03-04 MOFFOL 2.0b1 open
MOF26-28 Issues on MOF Facility formal/10-03-04 MOFFOL 2.0b1 open
MOF26-30 Incomplete URIStore definition MOFFOL 2.0b1 open
MOF26-31 Migration of package relationships MOFFOL 2.0b1 open
MOF26-29 Need to specify URI structure MOFFOL 2.0b1 open
MOF26-20 MOF should publish a convenience document that pre-merges all the different packages MOF 2.4 open
MOF26-23 Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag MOF 2.4 open
MOF26-22 Error in specified return value MOF 2.4.1 open
MOF26-21 MOF issue - MOF says nothing about the semantics of operation redefinition MOF 2.4 open
MOF26-16 CMOF should not itnore visibilities MOF 1.4 open
MOF26-18 Key Qualifiers Missing in MOF MOF 1.4 open
MOF26-19 MOF 2.0 Core: Exceptions missing for CMOF Reflective operations MOF 1.4 open
MOF26-17 Section: 10.3 MOF 2.0 open
MOF26-6 The text is not clear MOF 2.4.1 open
MOF26-3 Does MOF::Reflection::Object own "invoke" Operation ? MOF 2.4 open
MOF26-2 Sentence fragment duplication MOF 2.4 open
MOF26-4 Missing a right brace MOF 2.4 open
MOF26-5 Missing a right brace MOF 2.4 open
MOF26-7 Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3. MOF 2.4 open
MOF26-8 Section 9.2 constraints MOF 2.4 open
MOF26-11 URIExtent should provide the capability of accessing links as well as elements by URI MOF 2.4 open
MOF26-9 There is an inconsistency in the current spec between link equality and link delete MOF 2.4 open
MOF26-10 There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects MOF 2.4 open
MOF26-13 MOF does not have the correct semantics for links in the presence of association specialization MOF 2.4 open
MOF26-15 Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties MOF 2.0 open
MOF26-14 There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15 MOF 2.0 open
MOF26-12 Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1 MOF 2.0 open
MOF26-1 as root Model element ? MOF 2.4 open

Issues Descriptions

org.omg.emof.oppositeRoleName

  • Key: MOF26-35
  • Status: open  
  • Source: Model Driven Solutions ( Ed Willink)
  • Summary:

    The oppositeRoleName tag was introduced to support inverse navigation by OCL expressions since an OCL navigation needs to know the name to be navigated. An OCL navigation also needs to know whether the far end is a collection or not, and, if it is a collection, whether it is ordered and/or has unique values.The vast majority of opposite end characteristics can be reconstructed by assuming [0..1] !ordered, unique. However for the UML 2.5 model, this erroneously characterizes one ordered collection as not-ordered, about 10 lower bounds as 0 rather than 1, and about 100 upper bounds as 1 rather than 2 or *.

    If EMOF is to be useable by OCL and related tools, additional
    org.omg.emof.oppositeLower
    org.omg.emof.oppositeUpper
    org.omg.emof.oppositeOrdered
    org.omg.emof.oppositeUnique

    tags are need to avoid corruption of metamodel relationships.

    (The discussion on Issue 12800 that introduced oppositeRoleName suggested that the above might be necessary. Experience has shown that they are necessary. For instance for QVTr, a QVTc middle metamodel is synthesized with unidirectional navigation to the user metamodels. These unidirectional relationships are navigated in reverse as part of the trace and must have correct multiplicities.)

  • Reported: MOF 2.5 — Tue, 17 May 2016 14:18 GMT
  • Updated: Sat, 28 Jan 2017 10:13 GMT

The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier

  • Key: MOF26-36
  • Status: open  
  • Source: Object Management Group ( Juergen Boldt)
  • Summary:

    The second sentence of Section 6.2 lacks needed Clause numbers and Annex letter identifier. The sentence currently reads:

    The OCL constraints limiting this metamodel to the MOF 2 - relevant subsets are defined in Clause for EMOF and Clause for CMOF. A reference to files with the OCL source code is provided in Annex.

    There should be a number after "Clause" both times it appears ("12" and "14", perhaps?) and a letter at the end following Annex ("B"?).

  • Reported: MOF 2.5 — Fri, 5 Aug 2016 21:11 GMT
  • Updated: Fri, 5 Aug 2016 21:16 GMT

Conflicting statements about tag multiplicity

  • Key: MOF26-34
  • Status: open   Implementation work Blocked
  • Source: gmail.com ( Florian Schneider)
  • Summary:

    The model in Figure 11.1 ("The Extension package") does not specify a multiplicity for the tag property of MOF::Reflection::Element

    That is in conflict with one sentence in Section 11.1
    "The MOF Extension capability provides a simple mechanism to associate a collection of name-value pairs with model elements in order to address this need."

    and in Section 11.2
    "A model element can be associated with many Tags"

    Just as a sidenote, the two sections have two other issues:
    1) 11.2 is stating that "A model element cannot have more than one tag with the same name." but there is no OCL constraint to formalize that
    2) The property owner:Element [0..1] mentioned in 11.2 is not mentioned on Figure 11.1

  • Reported: MOF 2.5 — Sat, 16 Apr 2016 18:08 GMT
  • Updated: Wed, 27 Apr 2016 14:17 GMT

MOF Versioning & Development Lifecycle Spec (MOF VD) 2.0: How are VersionedExtents created?

  • Key: MOF26-33
  • Legacy Issue Number: 18905
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The MOF Facilities Object Lifecycle (MOF FOL) 2.0 spec defines "factory" methods in MOFFOL::Facility::createExtent(…)

    This method can create either an Extent or a URIExtent.

    MOF VD defines VersionedExtent as a specialization of URIExtent and Extent.
    However MOF VD provides no operation for creating a VersionedExtent.
    Are are such entities to be created?

  • Reported: MOFVD 2.1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:44 GMT

MOF2 Versioning Issue: Include annotated examples from presentation

  • Key: MOF26-32
  • Legacy Issue Number: 9810
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The slides produced by Geoff Clemm for the submission presentation were very helpful and should be included in the specification itself along with a bit of detail as to how they relate to the metamodel

  • Reported: MOFVD 2.0b1 — Thu, 8 Jun 2006 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:44 GMT

MOF Facility Object Lifecycle (FOL) 2.0: Is there a URIStor or not?

  • Key: MOF26-24
  • Legacy Issue Number: 18903
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The figure in section 6.2 shows a URIStore class with two broken lines (associations? Generalizations? Something else?)
    There is no entry for URIStore in the spec but there is a reference to it in 6.2.1.3:

    Facility::createStore(name : String, contextURI : String[0..1], ….)

    The description of the contextURI parameter says:

    The URI to be used to address this Store. If specified, an instance of URIStore will be created.

    So, is there a URIStore metaclass in MOF FOL or not?

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram

  • Key: MOF26-25
  • Legacy Issue Number: 18902
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    MOF Facility Object Lifecycle (FOL) 2.0: 6.4.2 Session does not appear in any diagram

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF Facility Object Lifecycle (MOF FOL) 2.0: inconsistency about Facility::getWorkspace()

  • Key: MOF26-26
  • Legacy Issue Number: 18901
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The overview diagram in section 6.2 shows an operation:

    Facility::getWorkspace(id : String[0..1]) : Workspace

    However, section 6.2.1.3 describes an operation with a different signature:

    Facility::getWorkspace(id : String[0..1]) : Workspace[0..*]

    Which is it?

  • Reported: MOFFOL 2.0b1 — Wed, 11 Sep 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Section 7 of formal/2010-03-04

  • Key: MOF26-27
  • Legacy Issue Number: 15647
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    2. Section 7 should be applied to the other specifications not left in this specification

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Issues on MOF Facility formal/10-03-04

  • Key: MOF26-28
  • Legacy Issue Number: 15643
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    1. The figures should have numbers and captions

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Incomplete URIStore definition

  • Key: MOF26-30
  • Legacy Issue Number: 15642
  • Status: open  
  • Source: Anonymous
  • Summary:

    The diagram on p6 includes URIStore but with incomplete lines.

    There is no subsection for it in 6.2.

  • Reported: MOFFOL 2.0b1 — Sun, 26 Sep 2010 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Migration of package relationships

  • Key: MOF26-31
  • Legacy Issue Number: 6909
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Summary:
    At MOF 1.4, packages can be related through:

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

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

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

  • Reported: MOFFOL 2.0b1 — Thu, 15 Jan 2004 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

Need to specify URI structure

  • Key: MOF26-29
  • Legacy Issue Number: 6904
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: MOFFOL 2.0b1 — Thu, 15 Jan 2004 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:43 GMT

MOF should publish a convenience document that pre-merges all the different packages

  • Key: MOF26-20
  • Legacy Issue Number: 19613
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    MOF should publish a convenience document that pre-merges all the different packages

  • Reported: MOF 2.4 — Thu, 18 Sep 2014 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Incomplete simplification & alignment between UML & MOF in 2.4: MOF::Extension::Tag

  • Key: MOF26-23
  • Legacy Issue Number: 19239
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The simplification and alignment between UML and MOF in the 2.4 series is incomplete.
    In particular, the extensions that MOF adds to UML are missing in UML.
    The MOF extensions that are missing in UML mean that statements like the one below in UML 2.5, section 6.2 are technically incorrect:

    Since version 2.4.1 a MOF 2.x metamodel, including the UML 2.x metamodel, is a valid UML 2.x model. This was a substantial simplification and alignment compared to earlier versions. It is expected that future versions of MOF and UML will continue to be aligned in this manner.

    For example, UML has no mechanism to specify the information about MOF::Extension::Tag. Without this information, it is currently not possible to fully rely on the above statement to use UML as a language for representing models of UML itself or parts of it such as the PrimitiveTypes library.

    One fairly simple option would be to define a MOF profile with stereotypes corresponding to the contents of the MOF-specific extensions of UML

  • Reported: MOF 2.4 — Fri, 14 Feb 2014 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Error in specified return value

  • Key: MOF26-22
  • Legacy Issue Number: 19131
  • Status: open  
  • Source: Student ( Jean-Luc Amitousa Mankoy)
  • Summary:

    The uml diagram in chapter 10.4 MOF:Common specifie that ReflexiveCollection remove method return a Boolean. Just after, when describing this method (chapter 10.5) it is set to Object.

  • Reported: MOF 2.4.1 — Thu, 28 Nov 2013 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF issue - MOF says nothing about the semantics of operation redefinition

  • Key: MOF26-21
  • Legacy Issue Number: 18811
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML uses operation redefinition quite extensively, but MOF says nothing about what this means, and UML itself leaves it rather open – see for example issues 17924 and 15499. UML 2.5 beta leaves it even more open than 2.4.1, which means that MOF needs to be specific for UML to be well-defined.

    My suggestion is that MOF requires parameters in redefined operations to have the same number, type, multiplicity, uniqueness and ordering as the parameters in the operation being redefined.

  • Reported: MOF 2.4 — Wed, 10 Jul 2013 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

CMOF should not itnore visibilities

  • Key: MOF26-16
  • Legacy Issue Number: 8997
  • Status: open  
  • Source: International Business Machines ( Jim Amsden)
  • Summary:

    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.

  • Reported: MOF 1.4 — Mon, 19 Sep 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Key Qualifiers Missing in MOF

  • Key: MOF26-18
  • Legacy Issue Number: 8695
  • Status: open  
  • Source: SAP SE ( Axel Uhl)
  • Summary:

    MOF has always lacked the capabilities to navigate an association
    qualified by the values of properties of the end to which to navigate.
    This has been a feature in UML since at least UML 1.3. When implementing
    MOF, this leads to the unpleasant effect that in order to pick elements
    from a collection returned from navigating a to-many association
    requires iterating over all elements returned and filtering for the ones
    meeting the desired criteria. The way MOF works, this makes it
    impossible to provide an efficient implementation that yet is
    standard-compliant.

    Key qualifiers address exactly this issue. However, when the UML was
    split into infrastructure and superstructure, this valuable UML feature
    was placed into the superstructure, thus not being accessible by the MOF
    specification. MOF itself doesn't provide its own approach to qualified
    navigation either.

    A concrete example of why the current situation is less than optimal is
    the UML with its association between Namespace and NamedElement, using
    role names "ownedMember" and "namespace." When navigating to a member of
    a namespace with a particular name, one has to enumerate all elements
    owned by that namespace and compare its name with the name looked for.
    The effort scales with the number of elements contained by that
    namespace, and there is no way for a repository to provide an efficient
    implementation for that in a standard-compliant way.

    A fix for this problem would be to move the association from
    UML::Classes::AssociationClasses::Property to itself with properties
    named "qualifier" and "associationEnd" to
    InfrastructureLibrary::Core::Basic and connect it to
    InfrastructureLibrary::Core::Basic::Property instead. With this, MOF2
    could use this useful feature, and a language binding for MOF2 could use
    this to offer qualified navigation. Repository implementations may
    provide a naive implementation at least, whereas advanced repositories
    may use the opportunity to maintain internal index structures that
    facilitate performant qualified access.

    I don't know whether this changes anything in the way an issue is
    handled by the OMG, but I've already talked to several vendors, current
    MOF implementors and active OMG contributors (also see Cc list), and
    there is wide consensus that this would be a very helpful change.

  • Reported: MOF 1.4 — Mon, 11 Apr 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF 2.0 Core: Exceptions missing for CMOF Reflective operations

  • Key: MOF26-19
  • Legacy Issue Number: 8268
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

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

  • Reported: MOF 1.4 — Fri, 11 Feb 2005 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section: 10.3

  • Key: MOF26-17
  • Legacy Issue Number: 9018
  • Status: open  
  • Source: TCS ( Asha Rajbhoj)
  • Summary:

    As per MOF specification only one property can be id. isID defines Id property for Class. Query is... 1) IF I have a Class say "Class1" which has property say "prop1" which is defined as Id. And there is "Class2" which inherits from "Class1" Then 1)Does "Class2" also inherit Id of "Class1"? 2)Can "Class2" has its owned id property? like overiding id property etc? Basically in specification there is no mention of relationship between inheritance of Classes and there id properties. 2) Also we see a single id property is too restrictive. In fact for the UML Meta model's Classes we could not define any single property as a identifying property. Is there any plan to make multiple properties as identifier in MOF?

  • Reported: MOF 2.0 — Tue, 27 Sep 2005 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

The text is not clear

  • Key: MOF26-6
  • Legacy Issue Number: 19759
  • Status: open  
  • Source: UFES ( Halysson Freitas)
  • Summary:

    The portion of text ""An Extent is a context in which an Element in a set of Elements in a set can be identified"".
    I think that this way is better: ""An Extent is a context in which an Element in a set of Elements can be identified""

    That way, I can understanding. To more detail, in my language (portuguese), the Google shows a concise translation.

  • Reported: MOF 2.4.1 — Sat, 16 May 2015 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Does MOF::Reflection::Object own "invoke" Operation ?

  • Key: MOF26-3
  • Legacy Issue Number: 19872
  • Status: open  
  • Source: Anonymous
  • Summary:

    Regarding to spec:
    §13.4 Object (from CMOF Reflection)
    "CMOF Reflection adds the following extra operations.
    invoke(op:Operation, arguments : Argument[0..*]) : Object[0..*]"

    But this operation is present into http://www.omg.org/spec/MOF/20131001/MOF.xmi file for MOF::Reflection::Object :

    <packagedElement xmi:type="uml:Class" name="Object" xmi:id="_MOF-Reflection-Object">
    ...
    <ownedOperation xmi:type="uml:Operation" name="invoke" visibility="public" xmi:id="_MOF-Reflection-Object-invoke">
    ...
    </ownedOperation>

    Moreover it uses <type xmi:idref="_MOF-CMOFReflection-Argument"/> from CMOF.

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Sentence fragment duplication

  • Key: MOF26-2
  • Legacy Issue Number: 19871
  • Status: open  
  • Source: Anonymous
  • Summary:

    The text "An Extent is a context in which an Element in a set of Elements in a set can be identified." contains sentence fragment duplication.

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-4
  • Legacy Issue Number: 19861
  • Status: open  
  • Source: Anonymous
  • Summary:

    The where clause is lack of a right brace for the Outer relation definition.

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Missing a right brace

  • Key: MOF26-5
  • Legacy Issue Number: 19860
  • Status: open  
  • Source: Anonymous
  • Summary:

    The example given for transformation, i.e., "transformation umlRdbms (uml : SimpleUML, rdbms : SimpleRDBMS) {" is lack of a right brace.

  • Reported: MOF 2.4 — Mon, 30 Nov 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3.

  • Key: MOF26-7
  • Legacy Issue Number: 17632
  • Status: open  
  • Source: Anonymous
  • Summary:

    Clause 2 specifies a requirement that compliant products shall support certain technology mappings, but there is no reference either here or in Clause 3, Normative references, to sources of specifications of those mappings.

  • Reported: MOF 2.4 — Mon, 24 Sep 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Section 9.2 constraints

  • Key: MOF26-8
  • Legacy Issue Number: 17395
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 9.2 contains a set of constraints – these should be rationalized with the ‘main” constraints in 12.4 (CMOF) and 14.3 (CMOF). A lot of them are in fact redundant (e.g. UML constraints) or not needed

  • Reported: MOF 2.4 — Thu, 24 May 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

URIExtent should provide the capability of accessing links as well as elements by URI

  • Key: MOF26-11
  • Legacy Issue Number: 17276
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    URIExtent should provide the capability of accessing links as well as elements by URI. This will enable SMOF multiply-classified links to be serialized with their uuids.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is an inconsistency in the current spec between link equality and link delete

  • Key: MOF26-9
  • Legacy Issue Number: 17275
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is an inconsistency in the current spec between link equality and link delete. Link equality only checks for the end values and the association, whereas link delete says: “This may leave the same elements associated by other links for this Association”, implying more than one distinguishable link per pair of elements. This should be resolved according to the fact that in OCL and UML collections resulting from navigating associations can be bags, i.e. contain the same element more than once. Links must be distinguishable individually, not simply by equality of their ends. This will imply that links have some identity criteria: uuids would seem to fit the bill perfectly.

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects

  • Key: MOF26-10
  • Legacy Issue Number: 17274
  • Status: open  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    There is no reflective access to uuids, and no mechanism is defined to assign uuids to objects

  • Reported: MOF 2.4 — Fri, 23 Mar 2012 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

MOF does not have the correct semantics for links in the presence of association specialization

  • Key: MOF26-13
  • Legacy Issue Number: 16270
  • Status: open  
  • Source: Anonymous
  • Summary:

    In MOF 2.4, CMOF reflection allows you to create a link as an instance of a single association and to test two links for equality. However, MOF 2.4 seems to be silent on the semantics of association generalization.

    According to the UML spec, if I have two associations A1 and A2, where A2 specializes A1, and I create a link between two objects o1 and o2 as an instance of A2, a link of A2 is also a link of A1. From 7.3.20 Generalization: “Each instance of the specific classifier is also an indirect instance of the general classifier.”

    However, CMOF semantics defines link equality so it requires association equality as well. This appears to conflict with UML semantics.

    Does this matter? Well, the UML metamodel does have association generalizations in it, where needed to make property redefinition syntactically valid. For such association generalizations, if we accept the MOF semantics, then they must be purely a syntactic convenience, i.e. they do not imply the link classification that the UML spec says that they imply.

    But there is a problem. Let’s look more closely at association specialization in the UML metamodel. In Fig 13.13 of UML 2.4 there is a property Interval::min that is redefined as TimeInterval::min. The opposites of these properties are also redefined and are association-owned, so the associations specialize in order to maintain well-formedness. I can confirm this is true in the UML metamodel. If I set TimeInterval::min to a particular value, then I am instantiating A_min_timeInterval. Because of the MOF semantics, I am not instantiating A_min_interval. That gives anomalies. If I were given an instance x that I knew to be at least an Interval, and used CMOF reflection linkedElements(A_min_interval, x, true) to find the linked elements, I will not find its min value in the case where x is actually a TimeInterval. I count that as a bug.

    In summary, the CMOF API that allows links to be explicitly manipulated and navigated should be defined so that a link of a sub-association is also a link of its super-associations.

  • Reported: MOF 2.4 — Thu, 26 May 2011 04:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties

  • Key: MOF26-15
  • Legacy Issue Number: 15833
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Provide support in MOF::Common for reflective collections according to UML2.4's collection types for properties, i.e., set, ordered set, bag and sequence

  • Reported: MOF 2.0 — Tue, 23 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

  • Key: MOF26-14
  • Legacy Issue Number: 15828
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    There is no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1

  • Key: MOF26-12
  • Legacy Issue Number: 15825
  • Status: open  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Add a new clause 9.4 for MOF::Reflection::Type per figure 9.1

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT

as root Model element ?

  • Key: MOF26-1
  • Legacy Issue Number: 19873
  • Status: open  
  • Source: Anonymous
  • Summary:

    The file http://www.omg.org/spec/MOF/20131001/MOF.xmi starts with:

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <packagedElement xmi:type="uml:Package" xmi:id="_MOF" name="MOF">
    ...

    Is it correct to have <packagedElement> as root Model element ?

    Why isn't it :

    <xmi:XMI xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmlns:uml="http://www.omg.org/spec/UML/20131001" xmlns:xmi="http://www.omg.org/spec/XMI/20131001">
    <uml:Package xmi:id="_MOF" name="MOF">
    ...

    Thanks

  • Reported: MOF 2.4 — Thu, 17 Dec 2015 05:00 GMT
  • Updated: Tue, 29 Mar 2016 15:41 GMT