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

All Issues

  • All Issues
  • Name: mof2core-rtf
  • Issues Count: 173

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF26-41 merging the UML package does not merge the elements of UML MOF 2.5.1 open
MOF26-40 CMOF constraint OCL for ownedEnd is too restrictive MOF 2.5 open
MOF26-39 Wrong import of the MOF::Common package by the MOF::Reflection package: it's actually the opposite. MOF 2.5.1 open
MOF26-38 AnnexB: Links to Constraint OCL Files Crossed MOFVD 2.1 open
MOF26-37 Typographical error MOF 2.5.1 open
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-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-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-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-20 MOF should publish a convenience document that pre-merges all the different packages MOF 2.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-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-17 Section: 10.3 MOF 2.0 open
MOF26-16 CMOF should not itnore visibilities MOF 1.4 open
MOF26-21 MOF issue - MOF says nothing about the semantics of operation redefinition MOF 2.4 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-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-7 Section 2: Add references to MOF 2 XMI and MOF 3 IDL to clause 3. 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-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-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
MOF24-167 Section 12.2, page 32: add sentences to explain relationship to Figure 12-1 through 12-4. MOF 2.0 MOF 2.4 Resolved closed
MOF24-166 Section 8.4: Indicate clearly the clauses in which the differences are described MOF 2.0 MOF 2.4 Resolved closed
MOF24-165 the return type of the remove() operation is inconsistent with the description MOF 2.4.1 MOF 2.4.2 Resolved closed
MOF24-164 References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 . MOF 2.0 MOF 2.4 Resolved closed
MOF24-163 Resolve MOF 2 PAS National Body Ballot Comments MOF 2.0 MOF 2.4 Resolved closed
MOF24-162 Annex C page 77 MOF 2.0 MOF 2.4 Resolved closed
MOF24-154 Section 15.3 page 55 MOF 2.0 MOF 2.4 Resolved closed
MOF24-159 Subpart V Annexes page 71 MOF 2.0 MOF 2.4 Resolved closed
MOF24-158 Section 16 page 67 MOF 2.0 MOF 2.4 Resolved closed
MOF24-157 Section 15.8 page 62 MOF 2.0 MOF 2.4 Resolved closed
MOF24-161 Annex B page 75 MOF 2.0 MOF 2.4 Resolved closed
MOF24-160 Annex A page 73 MOF 2.0 MOF 2.4 Resolved closed
MOF24-156 Section 15.8 page 62 MOF 2.0 MOF 2.4 Resolved closed
MOF24-155 Section 15.4 page 58 MOF 2.0 MOF 2.4 Resolved closed
MOF24-153 Section 14.5.2 page 53, Note MOF 2.0 MOF 2.4 Resolved closed
MOF24-152 Section 14.5 page 53 MOF 2.0 MOF 2.4 Resolved closed
MOF24-148 Section 14.1 page 49, Figure 14-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-147 Subpart IV: Abstract Semantics page 47 MOF 2.0 MOF 2.4 Resolved closed
MOF24-146 Section 13.7 page 45, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-151 Section 14.3 page 50 MOF 2.0 MOF 2.4 Resolved closed
MOF24-150 Section 14.2 page 49 MOF 2.0 MOF 2.4 Resolved closed
MOF24-149 Sections 14.1, 14.2, 14.5 pages 49, 50, 53, Figure 14-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-145 Section 13.6 page 45, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-141 Section 13.3 page 43, Paragraph Semantics MOF 2.0 MOF 2.4 Resolved closed
MOF24-140 Section 13.2 page 43, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-139 Section 13.2 page 43, Paragraph Semantics MOF 2.0 MOF 2.4 Resolved closed
MOF24-138 Section 13.1 page 41: add sentences to explain relationship to Figure 13-1 and 13-2. MOF 2.0 MOF 2.4 Resolved closed
MOF24-137 12.4 page 35: Be consistent with UML 2.4.1 and OCL 2.4.1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-144 Section 13.5 page 44, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-143 Section 13.4 page 44, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-142 Section 13.3 page 43, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-136 Section 12.2 page 33, 34, Figure 12-1, 12-2, 12-3, 12-4, get rid of volour in diagrams MOF 2.0 MOF 2.4 Resolved closed
MOF24-135 Section 12.2, Page 32, 33, Figure 12-1: There are two figures in Page 32 and 33 as same number as 12-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-134 Section 12.1 page 32: add sentences to explain relationship to Figure 12-1. MOF 2.0 MOF 2.4 Resolved closed
MOF24-130 Subpart II The MOF Model General Page 29 MOF 2.0 MOF 2.4 Resolved closed
MOF24-129 Section 11.1, Page 27 MOF 2.0 MOF 2.4 Resolved closed
MOF24-133 Section 12.1, Page 31, 2nd Paragraph MOF 2.0 MOF 2.4 Resolved closed
MOF24-132 Section 12.1 Page 31 MOF 2.0 MOF 2.4 Resolved closed
MOF24-131 Subpart II The MOF Model, Page 29 MOF 2.0 MOF 2.4 Resolved closed
MOF24-128 Sections 10.5, 10.6 Page 23, 24 MOF 2.0 MOF 2.4 Resolved closed
MOF24-127 Section 10, Page 23, Figure 10-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-126 Section 10, Page 23 MOF 2.0 MOF 2.4 Resolved closed
MOF24-125 Section 10.3, page 23, paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-121 Section 10.1 page 21 MOF 2.0 MOF 2.4 Resolved closed
MOF24-120 Section 9.3, page 18, paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-124 Section 10.1 page 21, figure 10-1: There are two diagrams in one Figure 10-1. MOF 2.0 MOF 2.4 Resolved closed
MOF24-123 Section 10.2 Page 22, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-119 Section 9.2: Page 17, Paragraph Changes from MOF 1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-118 Section 9.1, page 15, Figure 9-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-117 Figure 9-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-116 Section 9 Reflection: add sentences for Common package MOF 2.0 MOF 2.4 Resolved closed
MOF24-122 Section 10.1 page 21, figure 10-1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-115 Subpart II Capabilities General (PP.13) MOF 2.0 MOF 2.4 Resolved closed
MOF24-114 Setion 8.4 Change from MOF1.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-113 Section 8: explain all terms for language formalism MOF 2.0 MOF 2.4 Resolved closed
MOF24-110 Section 7.2 Subclause title “MOF 2 Design Rationale” is not suitable for goals for this specification. MOF 2.0 MOF 2.4 Resolved closed
MOF24-109 Section 7: Designate the precise version of the referred standards MOF 2.0 MOF 2.4 Resolved closed
MOF24-112 Section 8: Delete “81. General". It is also a “Hanging Paragraph” MOF 2.0 MOF 2.4 Resolved closed
MOF24-111 Section 7.4 Reuse of Common packages MOF 2.0 MOF 2.4 Resolved closed
MOF24-108 Clause 7 and sbuclause7.1 forms a “Hanging Paragraph” MOF 2.0 MOF 2.4 Resolved closed
MOF24-101 Section 5: There is no reference of other specifications as UML MOF 2.0 MOF 2.4 Resolved closed
MOF24-100 Section 4 terms & Definitions: Nothing defined MOF 2.0 MOF 2.4 Resolved closed
MOF24-107 delete subtitle “General Information.” MOF 2.0 MOF 2.4 Resolved closed
MOF24-106 Section 6 subpart 1: MOF 2.0 MOF 2.4 Resolved closed
MOF24-103 Section 6.4 Clause “Acknowledgements” is informative - move to an informative ANNEX MOF 2.0 MOF 2.4 Resolved closed
MOF24-102 Section 6.2 Technical Specification: Use ISO Number for MOF1.4 -- MOF1.4 (ISO/IEC 1502) MOF 2.0 MOF 2.4 Resolved closed
MOF24-105 Section 6: Clause “Additional Information” is not needed MOF 2.0 MOF 2.4 Resolved closed
MOF24-104 Section 6.4: delete last line MOF 2.0 MOF 2.4 Resolved closed
MOF24-91 Foreword, page vii: Title of ISO/IEC 19505-2:2011 is different MOF 2.0 MOF 2.4 Resolved closed
MOF24-96 Section 3 References: The title should change to "Normative Reference". MOF 2.0 MOF 2.4 Resolved closed
MOF24-95 Section 2 Conformance: Definition of conformance is insufficient MOF 2.0 MOF 2.4 Resolved closed
MOF24-94 Section 1: The scope seems to be focused on OMG standards only, not for ISO standards MOF 2.0 MOF 2.4 Resolved closed
MOF24-99 The style of Reference should conform to the JTC1 style. MOF 2.0 MOF 2.4 Resolved closed
MOF24-93 Foreword, page vii: Title of ISO/IEC 14769 is different MOF 2.0 MOF 2.4 Resolved closed
MOF24-92 Foreword, page vii: Title of ISO/IEC DIS 19509 is different MOF 2.0 MOF 2.4 Resolved closed
MOF24-98 Section 3: add references to CORBA, QVT and OCL MOF 2.0 MOF 2.4 Resolved closed
MOF24-97 Section 3: To refer ISO/IEC 19505. MOF 2.0 MOF 2.4 Resolved closed
MOF24-86 Section 8.2: Identify the document here and provide a full reference in Clause 3. MOF 2.0 MOF 2.4 Resolved closed
MOF24-85 Subpart 1: Delete the text from this location, possibly moving some of it to the Introduction MOF 2.0 MOF 2.4 Resolved closed
MOF24-84 Section 6.4: Delete the clause. MOF 2.0 MOF 2.4 Resolved closed
MOF24-83 Section 6.3: Either drop this clause, or identify the clauses that constitute "Part 1". MOF 2.0 MOF 2.4 Resolved closed
MOF24-82 Section 6.2: Move the content of the second sentence to the (non-normative) Introduction. MOF 2.0 MOF 2.4 Resolved closed
MOF24-90 Title: Category "Object Management Group" is not adequate for standards MOF 2.0 MOF 2.4 Resolved closed
MOF24-89 Section 9.1 Value judgements, such as “An advantage of ...” are not appropriate in the normative text of a standard MOF 2.0 MOF 2.4 Resolved closed
MOF24-88 Section 8.5, Subpart II” MOF 2.0 MOF 2.4 Resolved closed
MOF24-87 Section 8.5: Move the definition to clause 3 MOF 2.0 MOF 2.4 Resolved closed
MOF24-78 Semantics and ownership of link slots needs clarification MOF 2.4.1 MOF 2.4.2 Resolved closed
MOF24-77 Invalid restrictions on concrete metaclasses allowed in EMOF and CMOF MOF 2.4.1 MOF 2.4.2 Resolved closed
MOF24-81 Section 4: Include an “Abbreviation” clause, and if appropriate a populated Definitions clause MOF 2.0 MOF 2.4 Resolved closed
MOF24-80 Section 3: Include a reference to either or both parts of ISO/IEC 19505:2012, as appropriate. MOF 2.0 MOF 2.4 Resolved closed
MOF24-79 General comment: The text should be reviewed for clarity before it progresses to IS. MOF 2.0 MOF 2.4 Resolved closed
MOF24-75 Because MOF merges UML, UML as an instance of MOF is ill-formed MOF 2.0 MOF 2.4 Resolved closed
MOF24-74 MOF 2.4 issue: duplicated paragraph in section 3 MOF 2.0 MOF 2.4 Resolved closed
MOF24-73 Revise conventions to avoid unnecessary duplication of descriptions for operations MOF 2.0 MOF 2.4 Resolved closed
MOF24-72 linksOfType needs includeSubtypes parameter MOF 2.0 MOF 2.4 Resolved closed
MOF24-76 EnumerationLiterals in the XMI MOF 2.0 MOF 2.4 Resolved closed
MOF24-71 Bad description of set() MOF 2.0 MOF 2.4 Resolved closed
MOF24-70 MOF 2 should merge UML 2 (merged) as opposed to Kernel MOF 2.0 MOF 2.4 Resolved closed
MOF24-69 Primitive type values cannot be tested for equality using Reflection MOF 2.0 MOF 2.4 Resolved closed
MOF24-68 MOF 2.0 9.1 Confusing instance superclass statement MOF 2.0 MOF 2.4 Resolved closed
MOF24-67 MOF semantics chapter says nothing about ordering of links when association ends are marked “ordered”. MOF 2.0 MOF 2.4 Resolved closed
MOF24-62 Section 9.2: reconciliation with MOF Lifecycle should happen MOF 2.0 MOF 2.4 Duplicate or Merged closed
MOF24-61 MOF 2.4 issue: Part III contains the word Gagagaga MOF 2.0 MOF 2.4 Duplicate or Merged closed
MOF24-60 Multiple classifiers for an instance in MOF and RDF as defined in ODM MOF 2.0 MOF 2.4 Resolved closed
MOF24-59 no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema XMI 2.0 MOF 2.0 Transfered closed
MOF24-57 No unambiguous way in MOF 2.4 to serialize UML 2.4's StructuredActivityNode MOF 2.0 MOF 2.4 Resolved closed
MOF24-56 Problems in MOF operations delete(), invoke() and isInstanceOfType() operations MOF 2.0 MOF 2.4 Resolved closed
MOF24-31 MOF 2.0 9.1 Contradictory isSet default value semantics MOF 2.0 MOF 2.4 Resolved closed
MOF24-30 Outdated descriptions MOF 2.0 MOF 2.4 Resolved closed
MOF24-27 Section 9.1: paragraph needs clarification MOF 2.0 MOF 2.4 Resolved closed
MOF24-26 Capturing Unnavigable Opposite Property Role Names MOF 2.0 MOF 2.4 Resolved closed
MOF24-23 Wrong URLs MOF 2.0 MOF 2.4 Resolved closed
MOF24-29 We urgently need simple and clear rules we can follow to determine, for each file associated to a given specification MOF 2.0 MOF 2.4 Resolved closed
MOF24-28 Annex A refers to non-existing CMOF file MOF 2.0 MOF 2.4 Resolved closed
MOF24-21 Issue for MOF 2 spec (ptc/04-10-15) MOF 2.0 MOF 2.4 Resolved closed
MOF24-20 Container and owningProperty MOF 1.4 MOF 2.4 Resolved closed
MOF24-25 MOF 2.1 should be based on UML 2.1 Infrastructure MOF 2.0 MOF 2.4 Resolved closed
MOF24-24 FormalNumber: formal/02-04-03 section 3.6.2 MOF 1.4 MOF 2.4 Resolved closed
MOF24-19 MOF 2.0 Core: Inconsistency about use of defaults MOF 1.4 MOF 2.4 Resolved closed
MOF24-18 MOF 2 Core: undefined behavior of convertToString MOF 1.4 MOF 2.4 Resolved closed
MOF24-22 Remove Annex B MOF 2.0 MOF 2.4 Resolved closed
MOF24-34 Update and formalize the constraints that MOF applies to UML models MOF 2.0 MOF 2.4 Resolved closed
MOF24-33 Use UML models ‘as is’ for metamodels MOF 2.0 MOF 2.4 Resolved closed
MOF24-32 Remove isId and uri MOF 2.0 MOF 2.4 Resolved closed
MOF24-36 Fix resolution to issue 15398 from MOF2.4 ballot 2 MOF 2.0 MOF 2.4 Resolved closed
MOF24-35 Remove the distinction between isSet and the default value MOF 2.0 MOF 2.4 Resolved closed
MOF24-40 Delete incompletely specified MOF operation Object::verify() in 15.4 and in diagrams in clause 13 MOF 2.0 MOF 2.4 Resolved closed
MOF24-39 Delete unenforceable MOF constraint 12.4 [7] MOF 2.0 MOF 2.4 Resolved closed
MOF24-37 Delete the redundant package MOF::CMOFExtension described in clause 14.4 MOF 2.0 MOF 2.4 Resolved closed
MOF24-38 Fix resolution to issue 6905 from MOF2.4 ballot 1 MOF 2.0 MOF 2.4 Resolved closed
MOF24-41 Move operations from 9.1 Element to 9.3 Object: equals, get/set/unset/isSet MOF 2.0 MOF 2.4 Resolved closed
MOF24-42 Relations UML 2.0 MOF 2.4 Resolved closed

Issues Descriptions

merging the UML package does not merge the elements of UML

  • Key: MOF26-41
  • Status: open   Implementation work Blocked
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    MOF merges the UML package into its Reflection package. The UML contains many packages, such as CommonStructure. The package merge defines that such packages are deep copied into the resulting package. All the packages of the UML are also imported into the UML package. Package merge just copies these import relationships. It doesn't merge the imported elements: UML 2.5: Imported elements are not merged (unless there is also a PackageMerge to the Package owning the imported element).

    In effect, it means that MOF contains two unrelated element definitions: CommonStructure::Element and Reflection::Element. In fact all MOF elements are not merged with their UML counterparts.

    In UML 2.4 all the packages were merged into the UML package. Therefore, all elements were directly contained in this package. Therefore, it was sufficient to merge it.

    A possible solution: Create in MOF a package structure mirroring the UML packages.

  • Reported: MOF 2.5.1 — Fri, 7 Oct 2022 12:10 GMT
  • Updated: Thu, 27 Oct 2022 16:53 GMT

CMOF constraint OCL for ownedEnd is too restrictive

  • Key: MOF26-40
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The OCL is as follows. The restriction that ownedEnd->size() < 2 is not justified by the text of the constraint nor the specification, which refer only to memberEnds and size being limited to 2.
    In fact associations which own both their ends are a frequently used and useful (e.g. to link 2 independnetly developed (meta)models.
    The constraint should be ownedEnd->size() <= 2.

    >>>>>>>>>>>>>>
    – 14.3 [1] The multiplicity of Association::memberEnd is limited to 2 rather than 2..* (i.e., n-ary Associations are not supported);
    – unlike EMOF, CMOF associations can have navigable association-owned ends.
    – see also: https://sites.google.com/site/metamodelingantipatterns/catalog/mof/association-does-not-have-two-member-ends

    context Association
    inv CMOF_14_3_1: memberEnd->size() = 2 and ownedEnd->size() < 2

    <<<<<<<<<<<<<<<

  • Reported: MOF 2.5 — Tue, 3 May 2022 15:29 GMT
  • Updated: Tue, 3 May 2022 16:56 GMT

Wrong import of the MOF::Common package by the MOF::Reflection package: it's actually the opposite.

  • Key: MOF26-39
  • Status: open  
  • Source: None (independent IT engineer) ( Vincent Guyon)
  • Summary:

    No import of the MOF::Common package is required by the MOF::Reflection package.
    It's actually the opposite because the MOF::Common::ReflectiveCollection class inherits from the MOF::Reflective::Object (cf. Figure 10.2 on page 19).
    The problem is also present in the MOF/20131001/MOF.xmi (ptc/14-08-10) document.

    Another problem in the document: the 10.4 sub-chapter describing the MOF::Common package should not be a sub-chapter of the MOF::Identifiers main chapter (chapter 10), but in a specific main chapter for itself (chapter 11).

  • Reported: MOF 2.5.1 — Sun, 17 Apr 2022 11:40 GMT
  • Updated: Thu, 21 Apr 2022 16:11 GMT

AnnexB: Links to Constraint OCL Files Crossed


Typographical error

  • Key: MOF26-37
  • Status: open  
  • Source: Private individual ( Daniel Flaum)
  • Summary:

    The word 'metamodel' is misspelled as 'meatmodel' in the lower-most paragraph of page 1. The sentence which contains it is:

    "The lightweight subset representing the MOF meatmodel is specified by specifying constraints against the UML metamodel."

  • Reported: MOF 2.5.1 — Tue, 1 Oct 2019 19:11 GMT
  • Updated: Tue, 8 Oct 2019 17:44 GMT

org.omg.emof.oppositeRoleName

  • Key: MOF26-35
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward 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 ( Mr. 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 ( Dr. Nicolas F. 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 ( Mr. 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

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 ( Mr. 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 ( Mr. 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 Facility Object Lifecycle (MOF FOL) 2.0: inconsistency about Facility::getWorkspace()

  • Key: MOF26-26
  • Legacy Issue Number: 18901
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. 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 ( Mr. 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 ( Mr. 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

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

  • Key: MOF26-24
  • Legacy Issue Number: 18903
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. 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 ( Dr. Nicolas F. 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 should publish a convenience document that pre-merges all the different packages

  • Key: MOF26-20
  • Legacy Issue Number: 19613
  • Status: open  
  • Source: Adaptive ( Mr. 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

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

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

  • Key: MOF26-23
  • Legacy Issue Number: 19239
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. 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

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

CMOF should not itnore visibilities

  • Key: MOF26-16
  • Legacy Issue Number: 8997
  • Status: open  
  • Source: International Business Machines ( Mr. 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

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

  • Key: MOF26-21
  • Legacy Issue Number: 18811
  • Status: open  
  • Source: Model Driven Solutions ( Mr. 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

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

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 ( Dr. Nicolas F. 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

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

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

Section 9.2 constraints

  • Key: MOF26-8
  • Legacy Issue Number: 17395
  • Status: open  
  • Source: Adaptive ( Mr. 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 ( Mr. 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 no artifact corresponding to the CMOF Abstract Semantics package described in clause 15

  • Key: MOF26-14
  • Legacy Issue Number: 15828
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. 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 ( Dr. Nicolas F. 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

Section 12.2, page 32: add sentences to explain relationship to Figure 12-1 through 12-4.

  • Key: MOF24-167
  • Legacy Issue Number: 17690
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 12-1 through 12-4. Because there is no sentence as explaining Figure 12-1 through 12-4. Add sentences to explain relationship to Figure 12-1 through 12-4.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 23:32 GMT

Section 8.4: Indicate clearly the clauses in which the differences are described

  • Key: MOF24-166
  • Legacy Issue Number: 17640
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The first sentence implies that certain changes are specified in this clause, but there is no specification. However, unless the current document is intended as a delta document with respect to some earlier standard, which does not appear to be the case, then identifying such changes in the body of the standard is not appropriate. Indicate clearly the clauses in which the differences are described. If the differences are described, consider moving the information to an informative annex.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Proposed Resolution by NB:
    Indicate clearly the clauses in which the differences are described. If the differences
    are described, consider moving the information to an informative annex.
    Discussion:
    Delete subclause 8.4.
    Disposition: Merged with issue 18661

  • Updated: Mon, 20 Apr 2015 23:32 GMT

the return type of the remove() operation is inconsistent with the description

  • Key: MOF24-165
  • Legacy Issue Number: 18808
  • Status: closed  
  • Source: gmail.com ( Xavier Courangon)
  • Summary:

    "remove(object: Object): Object
    Removes the specified object from the collection. Returns true if the object was removed."

    Maybe the operation should return a Boolean.

  • Reported: MOF 2.4.1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Agreed. Correct the operation signature to return Boolean

  • Updated: Mon, 20 Apr 2015 17:34 GMT

References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 .

  • Key: MOF24-164
  • Legacy Issue Number: 18782
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    References in MOF Core to Infrastructure/Superstructure are obsolete, as are Figures 7.1, 12.1, 14.1 .

  • Reported: MOF 2.0 — Tue, 18 Jun 2013 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Agreed. The resolution for issue 15608 removed all remaining references to
    Infrastructure and Superstructure (where applicable) and updated all affected
    diagrams. However the figures listed above were deemed valuable and have
    therefore been updated and not removed.
    Disposition: Merged with 15608

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Resolve MOF 2 PAS National Body Ballot Comments

  • Key: MOF24-163
  • Legacy Issue Number: 18661
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    This is a condensed issue covering the individual comments recorded in the consecutive issues 17631 to 17717, which shall be resolved as Duplicate/Merged with this issue, which was created to make the document revision process more manageable.

  • Reported: MOF 2.0 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Resolve the ISO PAS comments sequentially throughout the document

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Annex C page 77

  • Key: MOF24-162
  • Legacy Issue Number: 17717
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex C is only described as an agreement for OMG. Delete Annex C.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 15.3 page 55

  • Key: MOF24-154
  • Legacy Issue Number: 17709
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 15-1. Because there is no sentence as explaining Figure 15-1. Add sentences to explain relationship to Figure 15-1.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart V Annexes page 71

  • Key: MOF24-159
  • Legacy Issue Number: 17714
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annexes should be referred as Annex A,B,C. Change A, B, C to Annex A, Annex B, Annex C.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 16 page 67

  • Key: MOF24-158
  • Legacy Issue Number: 17713
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Issue as “migration from MOF, v1.4” is not needed because it is informative. Move to an annex or delete this clause.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 15.8 page 62

  • Key: MOF24-157
  • Legacy Issue Number: 17712
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This diagram uses a color. Get rid of the color.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Annex B page 75

  • Key: MOF24-161
  • Legacy Issue Number: 17716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex B is not needed because it is not relevant to this standard. Delete Annex B.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Annex A page 73

  • Key: MOF24-160
  • Legacy Issue Number: 17715
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Annex A is not adequate as normative. Because it refers external documents that are not standardized. Put enough description in Annex A or change to an informative annex.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 15.8 page 62

  • Key: MOF24-156
  • Legacy Issue Number: 17711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Caption is missing for a diagram in this sub clause. Add a caption.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 15.4 page 58

  • Key: MOF24-155
  • Legacy Issue Number: 17710
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Title “Notes” is not suitable for clauses. Change to a note format defined in ISO/IEC Directive Part 2.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 14.5.2 page 53, Note

  • Key: MOF24-153
  • Legacy Issue Number: 17708
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In this the last line, there is "Figure 11.1". However, the figure label is "Figure 11-1". Be consistent with each other.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 14.5 page 53

  • Key: MOF24-152
  • Legacy Issue Number: 17707
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 14.1 page 49, Figure 14-1

  • Key: MOF24-148
  • Legacy Issue Number: 17703
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 14-1. Because there is no sentence as explaining Figure 14-1. Add sentences to explain relationship to Figure 14-1.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart IV: Abstract Semantics page 47

  • Key: MOF24-147
  • Legacy Issue Number: 17702
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Sentences of this part header are not needed. Delete this part.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.7 page 45, Paragraph Changes from MOF 1.4

  • Key: MOF24-146
  • Legacy Issue Number: 17701
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
    MOF1.4 --> ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 14.3 page 50

  • Key: MOF24-151
  • Legacy Issue Number: 17706
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 14-1. Add “Common” as a fourth package.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 14.2 page 49

  • Key: MOF24-150
  • Legacy Issue Number: 17705
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In this the first line, there is "Figure 14.2". However, there is no figure labeled "Figure 14.2". Refer an existing figure.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Sections 14.1, 14.2, 14.5 pages 49, 50, 53, Figure 14-1

  • Key: MOF24-149
  • Legacy Issue Number: 17704
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are three figures in Page 49, 50 and 53 as same number as 14-1. Renumber a second figure as 14-2 and a third figure as 14-3.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.6 page 45, Paragraph Changes from MOF 1.4

  • Key: MOF24-145
  • Legacy Issue Number: 17700
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
    MOF1.4 --> ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.3 page 43, Paragraph Semantics

  • Key: MOF24-141
  • Legacy Issue Number: 17696
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This designates "None". This prescription is insufficient. Describe adequately.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.2 page 43, Paragraph Changes from MOF 1.4

  • Key: MOF24-140
  • Legacy Issue Number: 17695
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

    MOF1.4 ?ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.2 page 43, Paragraph Semantics

  • Key: MOF24-139
  • Legacy Issue Number: 17694
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The sentence should define a grammatical prescription. However this definition is constraint and insufficient. Replace the text with precise one.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.1 page 41: add sentences to explain relationship to Figure 13-1 and 13-2.

  • Key: MOF24-138
  • Legacy Issue Number: 17693
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub-clause and figures as Figure 13-1 and 13-2. Because there is no sentence as explaining Figure 13-1 and 13-2. Add sentences to explain relationship to Figure 13-1 and 13-2.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

12.4 page 35: Be consistent with UML 2.4.1 and OCL 2.4.1

  • Key: MOF24-137
  • Legacy Issue Number: 17692
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are references to W3C documents in the Term [5]. These are normative reference. Besides, this definition style is different from UML 2.4.1 and OCL 2.4.1. Be consistent with UML 2.4.1 and OCL 2.4.1

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.5 page 44, Paragraph Changes from MOF 1.4

  • Key: MOF24-144
  • Legacy Issue Number: 17699
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
    MOF1.4 --> ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.4 page 44, Paragraph Changes from MOF 1.4

  • Key: MOF24-143
  • Legacy Issue Number: 17698
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
    MOF1.4 --> ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 13.3 page 43, Paragraph Changes from MOF 1.4

  • Key: MOF24-142
  • Legacy Issue Number: 17697
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. To use “Differences” rather than “Changes”
    MOF1.4 --> ISO/IEC19502

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 12.2 page 33, 34, Figure 12-1, 12-2, 12-3, 12-4, get rid of volour in diagrams

  • Key: MOF24-136
  • Legacy Issue Number: 17691
  • Status: closed  
  • Source: Anonymous
  • Summary:

    These diagrams as Figure 12-1, 12-2, 12-3 and 12-4 are filled with color. However, these colors are meaningless. Get rid of the color.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 12.2, Page 32, 33, Figure 12-1: There are two figures in Page 32 and 33 as same number as 12-1

  • Key: MOF24-135
  • Legacy Issue Number: 17689
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are two figures in Page 32 and 33 as same number as 12-1. Renumber a second figure as 12-3 and following figures in order.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 12.1 page 32: add sentences to explain relationship to Figure 12-1.

  • Key: MOF24-134
  • Legacy Issue Number: 17688
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 12-1. Because there is no sentence as explaining Figure 12-1. Add sentences to explain relationship to Figure 12-1.

  • Reported: MOF 2.0 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart II The MOF Model General Page 29

  • Key: MOF24-130
  • Legacy Issue Number: 17684
  • Status: closed  
  • Source: Anonymous
  • Summary:

    No need subtitle as “General.” Because title “The MOF Model” is enough to understand the meaning of this part. Delete subtitle “General.”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 11.1, Page 27

  • Key: MOF24-129
  • Legacy Issue Number: 17683
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 11-1. Because there is no sentence as explaining Figure 11-11. Add sentences to explain relationship to Figure 11-1.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 12.1, Page 31, 2nd Paragraph

  • Key: MOF24-133
  • Legacy Issue Number: 17687
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Three packages as Reflection, Identifiers and Extension are merged. However, four packages are merged in Figure 12-1. Add “Common” as a fourth package.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 12.1 Page 31

  • Key: MOF24-132
  • Legacy Issue Number: 17686
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This clause “introduction” explains an overview of EMOF model. However, there are many sub clauses “general” as explaining overviews. Change “introduction” to “general.”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart II The MOF Model, Page 29

  • Key: MOF24-131
  • Legacy Issue Number: 17685
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to identify a clause for MOF Model’s requirements and use UML 2 Infrastructure. Change to “CMOF Abstract Semantics.”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:
  • Updated: Mon, 20 Apr 2015 17:34 GMT

Sections 10.5, 10.6 Page 23, 24

  • Key: MOF24-128
  • Legacy Issue Number: 17682
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Reflective Collection and Reflective Sequence are defined in Common package. However, they are described as a part of Identifiers Package. Change a sub clause as 10.5 Reflective Collection and 10.6 Reflective Sequence to a sub clause as 11.1 and 11.2.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10, Page 23, Figure 10-1

  • Key: MOF24-127
  • Legacy Issue Number: 17681
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are two diagrams in one Figure 10-1. Split it into two figures 10-3 as classes and 10-4 as relationship between packages.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10, Page 23

  • Key: MOF24-126
  • Legacy Issue Number: 17680
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Sub clause MOF::Common describes for Common Package. However, other descriptions for packages are described in clauses. Change a sub clause as 10.4 to a clause as 11 and renumber following clauses.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10.3, page 23, paragraph Changes from MOF 1.4

  • Key: MOF24-125
  • Legacy Issue Number: 17679
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10.1 page 21

  • Key: MOF24-121
  • Legacy Issue Number: 17675
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 10-1. Because there is no sentence as explaining Figure 10-1. Add sentences to explain relationship to Figure 10-1

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9.3, page 18, paragraph Changes from MOF 1.4

  • Key: MOF24-120
  • Legacy Issue Number: 17674
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10.1 page 21, figure 10-1: There are two diagrams in one Figure 10-1.

  • Key: MOF24-124
  • Legacy Issue Number: 17678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Split it into two figures 10-1 as classes and 10-2 as relationship between packages.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10.2 Page 22, Paragraph Changes from MOF 1.4

  • Key: MOF24-123
  • Legacy Issue Number: 17677
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9.2: Page 17, Paragraph Changes from MOF 1.4

  • Key: MOF24-119
  • Legacy Issue Number: 17673
  • Status: closed  
  • Source: Anonymous
  • Summary:

    “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9.1, page 15, Figure 9-1

  • Key: MOF24-118
  • Legacy Issue Number: 17672
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are two diagrams in one Figure 9-1. Split it into two figures 9-1 as classes and 9-2 as relationship between packages.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Figure 9-1

  • Key: MOF24-117
  • Legacy Issue Number: 17671
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is hard to understand relationship between this sub clause and Figure 9-1. Because there is no sentence as explaining Figure 9-1.Add sentences to explain relationship to Figure 9-1.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9 Reflection: add sentences for Common package

  • Key: MOF24-116
  • Legacy Issue Number: 17670
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Four packages are described in this part rather than three as Reflection, Identifiers and Extension.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 10.1 page 21, figure 10-1

  • Key: MOF24-122
  • Legacy Issue Number: 17676
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are two figures in Page 21 and 23 as same number as 10-1. Renumber a second figure as 10-3.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart II Capabilities General (PP.13)

  • Key: MOF24-115
  • Legacy Issue Number: 17669
  • Status: closed  
  • Source: Anonymous
  • Summary:

    No need subtitle as “General.” Because title “Capabilities” is enough to understand the meaning of this part. Delete subtitle “General.”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Setion 8.4 Change from MOF1.4

  • Key: MOF24-114
  • Legacy Issue Number: 17668
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF 1.4 and 2.4.1 are independent specifications. “Changes” is not suitable to explain differences between MOF 1.4 and 2.4.1. Use “Differences” rather than “Changes”.
    Use ISO/IEC19502 for MOF 1.4

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 8: explain all terms for language formalism

  • Key: MOF24-113
  • Legacy Issue Number: 17667
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are unexplained terms for language formalism as Properties, Operations, Constrains, Semantics, Rationale, and so on.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 7.2 Subclause title “MOF 2 Design Rationale” is not suitable for goals for this specification.

  • Key: MOF24-110
  • Legacy Issue Number: 17664
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To change a title to “MOF 2 Design Requirements.” There must be some statements to be ISO standards.. MOF1.4 had become ISO.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 7: Designate the precise version of the referred standards

  • Key: MOF24-109
  • Legacy Issue Number: 17663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are descriptions of "UML2.0", "MOF2.0". And, "UML2", "MOF2", within this standard (for example Section 8 and etc.). These designations are ambiguous.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 8: Delete “81. General". It is also a “Hanging Paragraph”

  • Key: MOF24-112
  • Legacy Issue Number: 17666
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 7.4 Reuse of Common packages

  • Key: MOF24-111
  • Legacy Issue Number: 17665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In this the last line, there is "Figure 7.1". However, the figure label is "Figure 7-1". Make it consistent

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Clause 7 and sbuclause7.1 forms a “Hanging Paragraph”

  • Key: MOF24-108
  • Legacy Issue Number: 17662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Delete the title “7.1 General”.
    Then Re-numbering must be needed.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 5: There is no reference of other specifications as UML

  • Key: MOF24-101
  • Legacy Issue Number: 17655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no reference of other specifications as UML. However, many symbols of UML are used. To add sentences for reference of symbols used in this specification

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 4 terms & Definitions: Nothing defined

  • Key: MOF24-100
  • Legacy Issue Number: 17654
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Terms and concepts that were used in this document should be defined here.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

delete subtitle “General Information.”

  • Key: MOF24-107
  • Legacy Issue Number: 17661
  • Status: closed  
  • Source: Anonymous
  • Summary:

    No need subtitle as “General Information.” Because title “Introduction” is enough to understand the meaning of this part.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6 subpart 1:

  • Key: MOF24-106
  • Legacy Issue Number: 17660
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are two clauses as “Introduction.” It made a “Hanging Paragraph”. Merge into one clause

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.4 Clause “Acknowledgements” is informative - move to an informative ANNEX

  • Key: MOF24-103
  • Legacy Issue Number: 17657
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Section 6.4 Clause “Acknowledgements” is informative - move to an informative ANNEX

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    see pages 65 - 83 of ptc/2014-09-35

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.2 Technical Specification: Use ISO Number for MOF1.4 -- MOF1.4 (ISO/IEC 1502)

  • Key: MOF24-102
  • Legacy Issue Number: 17656
  • Status: closed  
  • Source: Anonymous
  • Summary:

    MOF1.4 (ISO/IEC 1502)

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6: Clause “Additional Information” is not needed

  • Key: MOF24-105
  • Legacy Issue Number: 17659
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Move to an informative ANNEX or delete this clause. Is it allowed to show the mailing List as an ISO standard.. The contact must be a NB.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.4: delete last line

  • Key: MOF24-104
  • Legacy Issue Number: 17658
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the last line of this section, a description: "U2P, UU and 3C team" is meaningless.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Foreword, page vii: Title of ISO/IEC 19505-2:2011 is different

  • Key: MOF24-91
  • Legacy Issue Number: 17645
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To use “ISO/IEC 19505-2:2012 Information technology – Object Management Group Unified Modeling Language (OMG UML) – Part 2: Superstructure”.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 3 References: The title should change to "Normative Reference".

  • Key: MOF24-96
  • Legacy Issue Number: 17650
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The title "Reference" is insufficient. The title should be "Normative Reference".

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 2 Conformance: Definition of conformance is insufficient

  • Key: MOF24-95
  • Legacy Issue Number: 17649
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To define conformance clearly or delete this clause.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 1: The scope seems to be focused on OMG standards only, not for ISO standards

  • Key: MOF24-94
  • Legacy Issue Number: 17648
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It should provide a clear focus as an ISO standard. Especially, relationship to other ISO standards, such as ISO/IEC 19505 or 19502 &3

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

The style of Reference should conform to the JTC1 style.

  • Key: MOF24-99
  • Legacy Issue Number: 17653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The style of Reference does not conform to the JTC1 style.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Foreword, page vii: Title of ISO/IEC 14769 is different

  • Key: MOF24-93
  • Legacy Issue Number: 17647
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Information technology – Open Distributed Processing – Type Repository Function”.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Foreword, page vii: Title of ISO/IEC DIS 19509 is different

  • Key: MOF24-92
  • Legacy Issue Number: 17646
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To use “ISO/IEC DIS 195059 Information technology – Object Management Group – MOF 2 XMI Version 2.4.1”.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 3: add references to CORBA, QVT and OCL

  • Key: MOF24-98
  • Legacy Issue Number: 17652
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This specification refers to CORBA, QVT and OCL.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 3: To refer ISO/IEC 19505.

  • Key: MOF24-97
  • Legacy Issue Number: 17651
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is a JTC1 standard of UML 2.4.1.However, an OMG document is referenced

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 8.2: Identify the document here and provide a full reference in Clause 3.

  • Key: MOF24-86
  • Legacy Issue Number: 17639
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The first sentence appears to make a normative reference to a “UML Infrastructure document”, but there is no specific identification of such a document.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Subpart 1: Delete the text from this location, possibly moving some of it to the Introduction

  • Key: MOF24-85
  • Legacy Issue Number: 17638
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This unnumbered clause, lying between 6.4 and 7, contains only historical background and motivational material. As such it has no place in the normative body of an International Standard. It should be deleted.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.4: Delete the clause.

  • Key: MOF24-84
  • Legacy Issue Number: 17637
  • Status: closed  
  • Source: Anonymous
  • Summary:

    It is not usual in ISO or IEC standards to acknowledge contributors to the document. It is not obvious that in all cases the terms used uniquely identify a specific organisation.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    see pages 65 - 83 of ptc/2014-09-35

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.3: Either drop this clause, or identify the clauses that constitute "Part 1".

  • Key: MOF24-83
  • Legacy Issue Number: 17636
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The first sentence refers to “Part 1”, which suggests that this is a multi-part standard, which is not the case. Assuming that the reference is intended to be to some subdivision of the text of the current document, there is no hint either here of in the Table of Contents as to what constitutes “Part 1”

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 6.2: Move the content of the second sentence to the (non-normative) Introduction.

  • Key: MOF24-82
  • Legacy Issue Number: 17635
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The second sentence would be better placed in the Introduction, as it is essentially commentary rather than specification.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Title: Category "Object Management Group" is not adequate for standards

  • Key: MOF24-90
  • Legacy Issue Number: 17644
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To change to “Information technology – Object Management Group Meta Object Facility (MOF) Core Version 2.4.1”.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9.1 Value judgements, such as “An advantage of ...” are not appropriate in the normative text of a standard

  • Key: MOF24-89
  • Legacy Issue Number: 17643
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Value judgements, such as “An advantage of ...” are not appropriate in the normative text of a standard. Rewrite the introduction paragraph to contain only straight facts relevant to construction of implementations or exploitation of implementations of this standard

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 8.5, Subpart II”

  • Key: MOF24-88
  • Legacy Issue Number: 17642
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This unnumbered clause, lying between 8.5 and 9, contains material that should be in a numbered clause, as it appears to be essential normative text. However, some of the text might be more appropriate to the Introduction or a description of MOF concepts.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 8.5: Move the definition to clause 3

  • Key: MOF24-87
  • Legacy Issue Number: 17641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This clause is essentially a definition of “Null” with some supporting information.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Semantics and ownership of link slots needs clarification

  • Key: MOF24-78
  • Legacy Issue Number: 17169
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Who owns LinkSlots? When an association end is owned by a Classifier, are there two slots for its instances (one for the link and one for the element) or only one?
    In the abstract semantics there is a concept called LinkSlot, which is shown as weakly aggregated (white diamond) by AssociationInstance. White diamond has not meaning in this context. Is it possible that a LinkSlot may be owned either by the link or by the adjacent instance, depending on “navigability”?
    The following sentence appears to be key: “Where the feature is a navigable end, then the ClassInstance Slot is consistent with the Link slot.” The reference to "navigable" is surely incorrect. What does "consistent" mean?

  • Reported: MOF 2.4.1 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    LinkSlots are owned by the AssociationInstance. Update diagram 15-1 to show this
    correctly.

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Invalid restrictions on concrete metaclasses allowed in EMOF and CMOF

  • Key: MOF24-77
  • Legacy Issue Number: 17049
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Per UML2.4.1, a

    In 12.4, constraint [8] currently reads:

    An EMOF metamodel is restricted to use the following concrete metaclasses from UML’s Kernel:
    • Class
    • Comment
    • DataType
    • Enumeration
    • EnumerationLiteral
    • Generalization
    • InstanceValue
    • LiteralBoolean
    • LiteralInteger
    • LiteralNull
    • LiteralReal
    • LiteralString
    • LiteralUnlimitedNatural
    • Operation
    • Package
    • Parameter
    • PrimitiveType
    • Property

    The list includes InstanceValue but incorrectly omits InstanceSpecification.

    InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification;
    see UML2.4.1, 7.3.23:

    • instance: InstanceSpecification [1]
    The instance that is the specified value.

    Since the list includes Class and a Class can have Property features, an InstanceSpecification that is the value of an InstanceValue in EMOF may have to specify values for the instantiated Class' Property features. Therefore, the list should also include UML2.4.1's Slot as well.

    The list should be corrected as follows:

    • Class
    • Comment
    • DataType
    • Enumeration
    • EnumerationLiteral
    • Generalization
    • InstanceSpecification
    • InstanceValue
    • LiteralBoolean
    • LiteralInteger
    • LiteralNull
    • LiteralReal
    • LiteralString
    • LiteralUnlimitedNatural
    • Operation
    • Package
    • Parameter
    • PrimitiveType
    • Property

    In 14.4, constraint [10] currently reads:

    A CMOF metamodel is restricted to use the following concrete metaclasses from UML’s Kernel:
    • Association
    • Class
    • Comment
    • Constraint
    • DataType
    • ElementImport
    • Enumeration
    • EnumerationLiteral
    • Generalization
    • InstanceValue
    • LiteralBoolean
    • LiteralInteger
    • LiteralNull
    • LiteralReal
    • LiteralString
    • LiteralUnlimitedNatural
    • OpaqueExpression
    • Operation
    • Package
    • PackageImport
    • PackageMerge
    • Parameter
    • PrimitiveType
    • Property

    The list includes InstanceValue but incorrectly omits InstanceSpecification.

    InstanceSpecification must be included in the list because an InstanceValue requires an InstanceSpecification;
    see UML2.4.1, 7.3.23:

    • instance: InstanceSpecification [1]
    The instance that is the specified value.

    Since the list includes Class and DataType, both of which can have Property features, an InstanceSpecification that is the value of an InstanceValue in CMOF may have to specify values for the instantiated Class' or DataType's Property features. Therefore, the list should also include UML2.4.1's Slot as well.

    The list should be corrected as follows:

    • Association
    • Class
    • Comment
    • Constraint
    • DataType
    • ElementImport
    • Enumeration
    • EnumerationLiteral
    • Generalization
    • InstanceSpecification
    • InstanceValue
    • LiteralBoolean
    • LiteralInteger
    • LiteralNull
    • LiteralReal
    • LiteralString
    • LiteralUnlimitedNatural
    • OpaqueExpression
    • Operation
    • Package
    • PackageImport
    • PackageMerge
    • Parameter
    • PrimitiveType
    • Property
    • Slot

  • Reported: MOF 2.4.1 — Thu, 26 Jan 2012 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Accept the proposal

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 4: Include an “Abbreviation” clause, and if appropriate a populated Definitions clause

  • Key: MOF24-81
  • Legacy Issue Number: 17634
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Whilst the statement that the document contains no formal definitions taken from other documents may well be true, it is not particularly useful. It may also be true that no terms are used in this document with meanings that cannot be found in common dictionaries. If this is the case, then a statement to that effect would be more useful than the existing statement. Otherwise definitions of terms that are used with special meanings must be included here. There are a number of abbreviations, e.g. EMOF and CMOF in 8.1, that are used in the body of the document without explanation. They should be expanded or otherwise explained here.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Include an "Abbreviation" clause, and if appropriate a populated Definitions clause.

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 3: Include a reference to either or both parts of ISO/IEC 19505:2012, as appropriate.

  • Key: MOF24-80
  • Legacy Issue Number: 17633
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The final line of the clause identified UML 2.4.1 as a required specification, but does not give any indication of the source of the specification. The Introduction refers in non-normative text to ISO/IEC 19505 as a specification of UML 2.4.1

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Starting with version 2.4, MOF shares the metamodel with UML (Superstructure).
    Therefore from version 2.4 on, MOF depends only on the corresponding UML
    Superstructure specification. Within the document, replace all mentioning of UML
    Infrastructure by UML Superstructure and add normative references to UML
    Superstructure as ISO and as OMG document to clause 3.
    Disposition: Merged with 18661

  • Updated: Mon, 20 Apr 2015 17:34 GMT

General comment: The text should be reviewed for clarity before it progresses to IS.

  • Key: MOF24-79
  • Legacy Issue Number: 17631
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The technical intent of the document is reasonably clear, and it appears to have been used for several effective implementations. The presentation of the material in the document is a long way from the ISO/IEC format, which is permitted for the first version of a standard introduced by the JTC1 PAS process, but there are a number of places where small changes would bring it closer to what users of ISO/IEC standards usually expect. There are also a number of places where the text is unclear or does not make obvious sense.

  • Reported: MOF 2.0 — Mon, 24 Sep 2012 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Because MOF merges UML, UML as an instance of MOF is ill-formed

  • Key: MOF24-75
  • Legacy Issue Number: 16489
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In MOF 2.4, Reflection::Element merges UML::Element. Then it is stated that Reflection::Element is an implicit superclass of all metaclasses defined using MOF. Hence UML::Element is a subclass of Reflection::Element which merges UML::Element. Reflection::Element has all of the properties of UML::Element (e.g. ownedComment) and so UML::Element may not validly have these properties.

    The solution is for MOF not to merge any part of UML, because there is no need to do so. MOF should simply refer to UML for its definitions.

  • Reported: MOF 2.0 — Wed, 10 Aug 2011 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    The fact that MOF merges UML is actually correct, and requires no changes. The
    important “fine print” detail is that PackageMerge is not inheritance. With
    PackageMerge, matching elements in the mergingPackage and the
    receivingPackage are merged into a single element without changing the position of
    that resulting element in the type hierarchy. This means in case of UML::Element
    versus Reflection::Element that UML::Element is augmented with the reflective
    capabilities defined in Reflection::Element without changing its position in the type
    hierarchy of the UML metamodel. In particular, UML::Element is not a subclass of
    Reflection::Element. If seen in the context of MOF, it remains unchanged the
    superclass of all UML metaclasses, but augmented with the MOF capabilities.
    Since version 2.4, MOF is based on a constrained-down UML metamodel. The only
    way to add the additional capabilities of MOF without altering the type hierarchy is
    PackageMerge, therefore MOF needs to merge UML.
    To provide absolute clarity, the clause describing the Package composition of MOF
    shall be improved.

  • Updated: Mon, 20 Apr 2015 17:34 GMT

MOF 2.4 issue: duplicated paragraph in section 3

  • Key: MOF24-74
  • Legacy Issue Number: 16393
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    In MOF 2.4, section 3, Normative References, there is a single paragraph which is repeated. Both paragraphs refer to the UML Superstructure 2.4, but they refer to it with different document numbers – the first is 2010-08-02 and the second is 2010-11-14. The second would be correct for 2.4, although needs to be revised again for 2.4.1.

  • Reported: MOF 2.0 — Mon, 25 Jul 2011 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661.
    Disposition: Merged with 18661

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Revise conventions to avoid unnecessary duplication of descriptions for operations

  • Key: MOF24-73
  • Legacy Issue Number: 15829
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Revise the conventions used in the MOF specification document to avoid unnecessary duplication of descriptions for inherited operations.
    in particular, the add/addAll/remove operations in 10.7 ReflectiveSequence are unnecessary duplicate descriptions of the add/addAll/remove operations inherited from 10.6 ReflectiveCollection

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Compared to the UML2 specifications, documenting inherited operations is unusual. More importantly, the MOF2.0 Core specification document lacks a clause documenting the specification and diagram formats used; however, this issue is beyond the scope of the MOF2.4 RTF.
    Disposition: Deferred

  • Updated: Mon, 20 Apr 2015 17:34 GMT

linksOfType needs includeSubtypes parameter

  • Key: MOF24-72
  • Legacy Issue Number: 15661
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In 13.6, elementsOfType has a parameter includeSubtypes, but linksOfType does not. There is no reason for this disparity – Associations can be generalized.

  • Reported: MOF 2.0 — Tue, 28 Sep 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Clause 13.7 – operation linksOfType()
    Replace the signature:
    linksOfType(type : Association) : Link[0..*]
    by:
    linksOfType(type : Association, includesSubtypes : Boolean) : Link[0..*]
    Perform the same change in the MOF model.
    Replace the explanatory sentence following signature by the following text:
    This returns those links in the extent that are instances of the supplied Association,
    or of any of its specializations if includesSubtypes is true.
    [ the diagram will be updated by resolution of 15608 ]

  • Updated: Mon, 20 Apr 2015 17:34 GMT

EnumerationLiterals in the XMI

  • Key: MOF24-76
  • Legacy Issue Number: 16585
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

    Even if not derived it would be the inverse of the owning composition so should not be serialized.

  • Reported: MOF 2.0 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    This issue is outdated.
    Disposition: Closed - No Change

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Bad description of set()

  • Key: MOF24-71
  • Legacy Issue Number: 15646
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    In section 9.1 the description of the exceptions refer to ‘element’ instead of ‘object’ as the parameter.

    And the whole section needs clarification of null e.g. does C.isInstance(null) = true for any class or datatype?

  • Reported: MOF 2.0 — Mon, 27 Sep 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Agreed. Correct the operation signature to return Boolean.
    C.isInstance(null) should return false at all time. Null is not a valid classifier and
    violates the constrains of UML::Type on which MOF::Reflection::Type is based.

  • Updated: Mon, 20 Apr 2015 17:34 GMT

MOF 2 should merge UML 2 (merged) as opposed to Kernel

  • Key: MOF24-70
  • Legacy Issue Number: 15608
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF 2 should merge UML 2 (merged) as opposed to Kernel and use the automated constraints from UML 2.4 production.

    Since UML2 now has a normative merged metamodel it makes sense to reference this – especially since Kernel will be disappearing at UML 2.5.

    The UML 2.4 team has produced a more complete set of executable constraints for valid MOF 2.4 metamodels which should be incorporated.

  • Reported: MOF 2.0 — Tue, 21 Sep 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    This is part of a larger effort to do the final steps of MOF – UML harmonization.
    Change the MOF Model to merge UML (from 2.5) instead of UML::Kernel.
    Revise the whole MOF Core specification document to change any remaining
    references to Basic, Infrastructure, Kernel, etc. to the corresponding references
    based on UML 2.5. This effort includes replacement of diagrams where necessary

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Primitive type values cannot be tested for equality using Reflection

  • Key: MOF24-69
  • Legacy Issue Number: 15442
  • Status: closed  
  • Source: gmail.com ( Dmitry Semikin)
  • Summary:

    Reflection package of the MOF defines operation

    MOF::Element.equals(element:Object):Boolean

    for testing equality of model elements. Description of this function (on page 16) tells, that "For instances of DataType, returns true if the object has the same value as this Element instance."

    But instances of particular DataTypes (e.g. Integer, Bolean etc.) are just values (actually, I did not found, where exactly in MOF or UML Infrastructure specification, but somewhere I saw a definition of PrimitiveTypes like "instances of primitive types are identified only by their values"). So they are not Element-s (as I understand, they are Object-s, so each of primitive type, i.e. Integer, Boolean, String, UnlimitedNatural, can be considered as derived from Object, although they are not defined in such a way in MOF specification).

    As so, instances of primitive type has no operation "equals" (which is quite OK, as they should have no operations - for this reasons they are PrimitiveTypes). So we cannot call "equals" operation as member of e.g. Integer Object. So, we cannot compare two integer objects.

    Being more specific, let's cosider example (it is invalid call...):

    some_property.get(lower).equals(MOF::Factory.CreateFromString(integer, "1"))

    this test for equality (if lower bound of "some_property" equals to 1) is invalid, as "get" operation returns just number (value, instance of Integer), and it has not operation "equals".

    Note: in example above "some_property" is instance of MOF::Property, which represents some property of some class, and "lower" is either instance of MOF::Property, which represents lower bound of "some_proerty". "integer" is an instance of MOF::PrimitiveType meta-metaclass, which represents MOF::Integer meta-primitive-type.

    Actually, currently I have no Proposal for solution of this inconsistency, so this message is just report about it.

  • Reported: MOF 2.0 — Fri, 3 Sep 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    closed no change

  • Updated: Mon, 20 Apr 2015 17:34 GMT

MOF 2.0 9.1 Confusing instance superclass statement

  • Key: MOF24-68
  • Legacy Issue Number: 15272
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The statement in clause 9.1 semantics

    "Class Element is the superclass of all model elements in MOF, and is the
    superclass of all instances of MOF model elements."

    is confusing since instances do not normally have superclasses.

    The statement could be interpreted to mean that every class always has
    Element as a superclass including user-defined classes. But this would then
    make it impossible to model lightweight application classes supporting
    solely the required functionality.

    Surely it is every M2 (and M3 and ...) class that has Element as a
    superclass?

    At M1 the superclasses are as modelled by the user.

    This is significant for OCL since OCL inserts at least OclAny as the top
    type at M1 in order to support some reflective behaviour. If Element really
    is an M1 superclass, then OCL should align. If Element is not an M1
    superclass, OCL should provide its reflection in OclAny.

  • Reported: MOF 2.0 — Wed, 2 Jun 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    closed no change

  • Updated: Mon, 20 Apr 2015 17:34 GMT

MOF semantics chapter says nothing about ordering of links when association ends are marked “ordered”.

  • Key: MOF24-67
  • Legacy Issue Number: 14553
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    MOF semantics chapter says nothing about ordering of links when association ends are marked “ordered”. In fact the MOF semantics chapter seems to add no value and perhaps it should be deleted from the spec altogether.

  • Reported: MOF 2.0 — Fri, 9 Oct 2009 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Adopt the explanation of “ordered” from UML 2.5 - Association

  • Updated: Mon, 20 Apr 2015 17:34 GMT

Section 9.2: reconciliation with MOF Lifecycle should happen

  • Key: MOF24-62
  • Legacy Issue Number: 17394
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 9.2 factory starts: “Note – This section will need to be reconciled with the work underway in MOF lifecycle RFP.” Since the latter is now formal, this reconciliation should happen.

  • Reported: MOF 2.0 — Thu, 24 May 2012 04:00 GMT
  • Disposition: Duplicate or Merged — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:36 GMT

MOF 2.4 issue: Part III contains the word Gagagaga

  • Key: MOF24-61
  • Legacy Issue Number: 16394
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The page of the MOF 2.4 spec headed Part III – The MOF Model has the meaningless word Gagagaga at the end of it.

  • Reported: MOF 2.0 — Mon, 25 Jul 2011 04:00 GMT
  • Disposition: Duplicate or Merged — MOF 2.4
  • Disposition Summary:

    This has been corrected by resolving the ISO/IEC-PAS comments. See issue 18661.

  • Updated: Sun, 8 Mar 2015 15:36 GMT

Multiple classifiers for an instance in MOF and RDF as defined in ODM

  • Key: MOF24-60
  • Legacy Issue Number: 9466
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

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

  • Reported: MOF 2.0 — Wed, 22 Mar 2006 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:36 GMT

no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema

  • Key: MOF24-59
  • Legacy Issue Number: 7605
  • Status: closed  
  • Source: ISIS ( Matt Emerson)
  • Summary:

    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?

  • Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
  • Disposition: Transfered — MOF 2.0
  • Disposition Summary:

    This is requesting that an XMI-compliant XML Schema be provided for MOF itself, as an example of a metamodel. This is an issue for MOF not XMI.

    Revised Text:

    • none -

    Disposition: Transferred to MOF RTF

  • Updated: Sun, 8 Mar 2015 15:36 GMT

No unambiguous way in MOF 2.4 to serialize UML 2.4's StructuredActivityNode

  • Key: MOF24-57
  • Legacy Issue Number: 16329
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    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

  • Reported: MOF 2.0 — Fri, 10 Jun 2011 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    resolved as an urgent issue

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Problems in MOF operations delete(), invoke() and isInstanceOfType() operations

  • Key: MOF24-56
  • Legacy Issue Number: 15859
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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

  • Reported: MOF 2.0 — Thu, 2 Dec 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    It is unclear from the MOF2.0 Core specification where the Object::delete() operation is to be defined; it could be in MOF::Reflection::Object or in MOF::CMOFReflection::Object. It is also unclear whether each specialization of Object should have a delete operation – e.g., there is no delete() for MOF::Common::ReflectiveCollection. With so many important details under-specified, it is better to remove this operation than to leave it.
    Since the resolution to issue 15825 for Object::getType() is deferred, it does not make sense to have Object::isInstanceOfType() either, this operation should be deleted and only defined for Element as described in the summary.
    In 13.3, invoke() returns a collection of Elements but in 13.4, it returns a collection of Objects. Clearly an operation could return any kind of Object; the return type should be Object, not Element. Since MOF::Common::ReflectiveCollection provides the capability for representing a collection of Objects, it is not necessary for invoke() to return yet another collection of Objects, a single Object suffice; if the actual return is in fact a collection of Objects, then the return can be a single ReflectiveCollection object. Therefore, the multiplicity on the return parameter should be changed from 0..* to 0..1

  • Updated: Fri, 6 Mar 2015 23:15 GMT

MOF 2.0 9.1 Contradictory isSet default value semantics

  • Key: MOF24-31
  • Legacy Issue Number: 15271
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    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

  • Reported: MOF 2.0 — Wed, 2 Jun 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    duplicate of issue 15821

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Outdated descriptions

  • Key: MOF24-30
  • Legacy Issue Number: 15143
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 2.0 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 9.1: paragraph needs clarification

  • Key: MOF24-27
  • Legacy Issue Number: 13127
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Cory Casanave)
  • Summary:

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

  • Reported: MOF 2.0 — Wed, 26 Nov 2008 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Further description would be useful than suggested in the issue

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Capturing Unnavigable Opposite Property Role Names

  • Key: MOF24-26
  • Legacy Issue Number: 12800
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

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

  • Reported: MOF 2.0 — Sun, 31 Aug 2008 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    The use of ‘non-navigable’ is out-dated: the issue is where Property::opposite is empty and there is nothing to hang the name on.

    Further email exchanges on the RTF list discussed using an EMOF Tag instead of a Comment. So the proposed resolution is to introduce an EMOF Tag named “org.omg.emof.oppositeRoleName” that can be applied only to a Property whose “opposite” Property is empty. The “value” of this Tag specifies a role name that expressions (such as OCL expressions and QVT expressions) can use to traverse in the opposite direction of the Property.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong URLs

  • Key: MOF24-23
  • Legacy Issue Number: 10968
  • Status: closed  
  • Source: Thematix Partners LLC ( Jishnu Mukerji [X] (Inactive))
  • Summary:

    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.

  • Reported: MOF 2.0 — Mon, 23 Apr 2007 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    The published document formal/06-01-01 contained proper URLs in Annex A, which did indeed use schema.omg.org. However there was a typo in that ‘orb’ was used instead of ‘org’.
    However the recommended structure of the URLs has now changed so MOF 2.1 should move to the new structure, since the files need to change significantly due to move to UML 2.1 as the basis of the metametamodel.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: MOF24-29
  • Legacy Issue Number: 15118
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

  • Reported: MOF 2.0 — Fri, 5 Mar 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Annex A refers to non-existing CMOF file

  • Key: MOF24-28
  • Legacy Issue Number: 13444
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    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.

  • Reported: MOF 2.0 — Wed, 4 Feb 2009 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    The lack of this document was caused by structural problems in the UML 2.0 metamodel on which MOF 2.0 was based – which meant that UML 2.0 itself had no XMI file.
    The normative XMI file will be produced for this revision of MOF and referenced from Annex A.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue for MOF 2 spec (ptc/04-10-15)

  • Key: MOF24-21
  • Legacy Issue Number: 9360
  • Status: closed  
  • Source: Adaptive ( Mr. Gene Mutschler)
  • Summary:

    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.

  • Reported: MOF 2.0 — Thu, 9 Feb 2006 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Disposition: See issue 8269 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Container and owningProperty

  • Key: MOF24-20
  • Legacy Issue Number: 9147
  • Status: closed  
  • Source: Honeywell ( David Oglesby)
  • Summary:

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

  • Reported: MOF 1.4 — Thu, 10 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 2.1 should be based on UML 2.1 Infrastructure

  • Key: MOF24-25
  • Legacy Issue Number: 12175
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: MOF 2.0 — Mon, 14 Jan 2008 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    MOF should be aligned with an appropriate version of UML and XMI – probably UML 2.4. This will change the XMI but have virtually no impact on the specification document.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FormalNumber: formal/02-04-03 section 3.6.2

  • Key: MOF24-24
  • Legacy Issue Number: 11157
  • Status: closed  
  • Source: VBA ( Tomasz Biegacz)
  • Summary:

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

  • Reported: MOF 1.4 — Wed, 18 Jul 2007 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 2.0 Core: Inconsistency about use of defaults

  • Key: MOF24-19
  • Legacy Issue Number: 8269
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 1.4 — Fri, 11 Feb 2005 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    It’s important to note that Property::default is used only for initial assignment on element creation, not as the value returned in absence of an explicit value.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 2 Core: undefined behavior of convertToString

  • Key: MOF24-18
  • Legacy Issue Number: 8267
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 1.4 — Fri, 11 Feb 2005 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove Annex B

  • Key: MOF24-22
  • Legacy Issue Number: 9802
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 2.0 — Mon, 5 Jun 2006 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Entirely remove Annex B and update contents page

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Update and formalize the constraints that MOF applies to UML models

  • Key: MOF24-34
  • Legacy Issue Number: 15820
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

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

  • Reported: MOF 2.0 — Wed, 17 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use UML models ‘as is’ for metamodels

  • Key: MOF24-33
  • Legacy Issue Number: 15398
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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

  • Reported: MOF 2.0 — Sat, 7 Aug 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    As per the proposed resolution.
    In addition, for CMOF, Feature::isStatic must be ‘false’

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove isId and uri

  • Key: MOF24-32
  • Legacy Issue Number: 15397
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 2.0 — Sat, 7 Aug 2010 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fix resolution to issue 15398 from MOF2.4 ballot 2

  • Key: MOF24-36
  • Legacy Issue Number: 15824
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Apply the changes to the MOF2.4 metamodel as described in the summary.
    Additionally:

    • MOF::Reflection must import MOF::Common since operations defined in MOF::Reflection depend on types defined in MOF::Common
    • MOF::CMOFReflection does not need to import MOF::Common since it merges MOF::Reflection, which imports MOF::Common
    • MOF::CMOF does not need to merge UML::Classes::Kernel per resolution 15398 because MOF::CMOF merges MOF::CMOFReflection, which merges MOF::Reflection, which merges UML::Classes::Kernel
    • MOF::EMOF does not need to merge UML::Classes::Kernel per resolution 15398 because MOF::EMOF merges MOF::Reflection, which merges UML::Classes::Kernel
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove the distinction between isSet and the default value

  • Key: MOF24-35
  • Legacy Issue Number: 15821
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: MOF 2.0 — Wed, 17 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    This is addressed in the wording introduced in issue 15832 in this ballot.
    This supersedes the resolution to 8269.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: MOF24-40
  • Legacy Issue Number: 15831
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Since the contents of the ReflectiveCollection result is left unspecified, this operation is unimplementable

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete unenforceable MOF constraint 12.4 [7]

  • Key: MOF24-39
  • Legacy Issue Number: 15830
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    Delete unenforceable MOF constraint 12.4 [7]

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Since constraint [7] in clause 12.4 refers to an undefined operation MOF::Object.isInstance() and since the only reasonable interpretation of this constraint is that of a tautology, the constraint provides no practical value to the MOF2 Core specification

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: MOF24-37
  • Legacy Issue Number: 15826
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Every element shown in figure 14.3 (MOF::CMOFExtension) is a matching increment to a corresponding element shown in figure 11.1 (MOF::Extension). As far as these figures are concerned, the MOF::CMOFExtension package provides no additional capability beyond what MOF::Extension already provides. This would be sufficient to warrant deleting the MOF::CMOFExtension package. However, the resolution to issue 15827 involves adding a second association between Element and Tag that can only be expressed within CMOF because it involves a navigable owned association end, a capability that is specifically prohibited for EMOF per the resolution to issue 15820.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Fix resolution to issue 6905 from MOF2.4 ballot 1

  • Key: MOF24-38
  • Legacy Issue Number: 15827
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

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

  • Reported: MOF 2.0 — Mon, 22 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    The resolution to issue 6905 added a property: Tag::owner : Element[0..1]
    When EMOF or CMOF would be merged, this property would conflict with UML::Element::/owner : Element[0..1] property (see figure 7.3 in UML2.4 superstructure)
    The fix involves the following:

    • change the name of ownership property from owner to tagOwner
    • symmetrically subset the association end properties of the association UML::A_ownedElement_owner
    • make the composite association end, ownedTag, navigable and owned by the association; this is essential to avoid an incompatible API change to UML::Classes::Kernel::Element. However, because navigable owned association ends are not allowed in EMOF, it is necessary to add the ownedTag/tagOwner association in MOF::CMOFExtension instead of MOF::Extension.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Move operations from 9.1 Element to 9.3 Object: equals, get/set/unset/isSet

  • Key: MOF24-41
  • Legacy Issue Number: 15832
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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.

  • Reported: MOF 2.0 — Tue, 23 Nov 2010 05:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    Move the operations in the metamodel & the specification as indicated in the summary.
    The specification of get/set operations should be in terms of ReflectiveCollection instead of ReflectiveSequence since the characteristics of a property with upper bound greater than 1 could be that of a sequence, bag, set or ordered set as specified in UML2.4 (see Superstructure clause 7.3.45, table “Collection types for properties”). Adding support for all of the collection types in UML is a separate issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relations

  • Key: MOF24-42
  • Legacy Issue Number: 8751
  • Status: closed  
  • Source: gmx.net ( Markus Brigl)
  • Summary:

    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.

  • Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    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

    Disposition: Closed, no change

  • Updated: Fri, 6 Mar 2015 20:58 GMT