Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — All Issues

  • Acronym: MOF
  • Issues Count: 454
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF2RDF11-3 The ontology (RDF files) should be revised to use the Commons ontologies MOF2RDF 1.0 open
MOF2RDF11-1 Not able to download documents MOF2RDF 1.0 open
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
MOF2RDF11-2 Normative Machine Readable Document links are broken MOF2RDF 1.0 open
MOF26-38 AnnexB: Links to Constraint OCL Files Crossed MOFVD 2.1 open
MOF2RDF-8 In Clause 10, the base URL is misspelled MOF2RDF 1.0b1 MOF2RDF 1.0 Resolved closed
MOF2RDF-7 References to, and explanation of Usage for Turtle and QVT MOF2RDF 1.0b1 MOF2RDF 1.0 Resolved closed
MOF2RDF-3 Phrase owl:allValuesFrom garbled MOF2RDF 1.0b1 MOF2RDF 1.0 Resolved closed
MOF2RDF-2 Insert missing word MOF2RDF 1.0b1 MOF2RDF 1.0 Resolved closed
MOF2RDF-1 Improve Formatting and Correct Captions MOF2RDF 1.0b1 MOF2RDF 1.0 Resolved closed
MOFM2T11-21 Typo MOFM2T 1.0 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
QVT14-25 QVTo : Confusing isVirtual definition for imperative operation calls MOF 1.2 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
QVT13-99 QVTo: Mapping Overloading MOF 1.2 QVT 1.3 Resolved closed
QVT13-93 QVTo: Mapping and other Identifiers MOF 1.2 QVT 1.3 Resolved closed
QVT13-78 QVTo: VariableInitExp wording for missing initializer MOF 1.2 QVT 1.3 Resolved closed
QVT13-97 QVTo: xselectOne, xcollectselectOne is Sequence of One not One MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-58 QVTo: access/extension default for ImportKind MOF 1.2 QVT 1.3 Resolved closed
QVT13-120 QVTo: object creation in helpers MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-61 QVTo: Calling the super implementation of an overriding operation MOF 1.2 QVT 1.3 Duplicate or Merged closed
QVT13-60 QVTo: non-mutating List operation example problem MOF 1.2 QVT 1.3 Resolved closed
QVT13-101 QVTc/QVTo/QVTr acronyms MOF 1.2 QVT 1.3 Resolved closed
QVT14-14 Rationalize title MOF 1.2 open
QVT14-15 Trace Record not suitable for Incremental Execution MOF 1.2 open
QVT14-20 QVTo: What are the operation overloading semantics? MOF 1.2 open
QVT14-18 QVTo: Enhance Status to support access to nested transformation trace data MOF 1.2 open
QVT14-19 QVTo: Eliminate deprecated Typedef class MOF 1.2 open
QVT14-22 QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL MOF 1.2 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
MOF2I2-58 Associations should not be required to be unique MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF24-66 MOF Figure 18 MOF 2.0 MOF 2.4 Resolved closed
MOF24-65 The 'isID' attribute in class MOF::CMOF::Property remains unclear MOF 2.0 MOF 2.4 Resolved closed
MOF24-64 chapter 10 rewrite MOF 2.0 MOF 2.4 Resolved closed
MOF24-63 diagrams mostly use unspecified «combine» MOF 2.0 MOF 2.4 Closed; No Change closed
MOF2I2-57 Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-56 object in a useContainment Extent MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-55 semantics of Reflection::Object MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-54 Correct addAll() input parameter type MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-53 Remove allowNull and serializable from EMOF DataType MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-52 ReflectiveSequence is not sufficient - add iterator, remove addAll MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-49 ad-03-04-07/Non-orthogonal additions to UML Core MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-51 ReflectiveSequence is not sufficient, need nulls within a list MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-50 No container for tags in tag model MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-47 MOF 2.0 Core 03-04-07, Chapter 5. Identifiers MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-46 MOF 2 Issue: Reflexion and Links MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-45 Navigating metalevels/instance relationships MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-48 MOF should include Profile package MOF2I 1.0 MOF2I 2.0b1 Resolved closed
MOF2I2-44 removing section 12.3 EMOF Merged Model ? MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-43 Question on M-Levels MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-42 Translation between EMOF and CMOF in MOF 2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF14-169 Abstract package MOF 1.3 MOF 1.4 Duplicate or Merged closed
MOF2I2-41 names of the factory create operations MOF2I 2.0b1 MOF2I 2.0 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-58 Absence of definitions of "XMI" and "MOF" MOF 2.4.1 MOF 2.4.2 Resolved 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
MOFM2T11-20 Annex A1 MOFM2T 1.0 MOFM2T 1.1 Closed; No Change closed
MOF24-55 Rule (11) and (12) MOF 2.0 MOF 2.4 Resolved closed
MOF14-168 MOF 1.3: are Associations contained in Packages or not? MOF 1.3 MOF 1.4 Resolved closed
MOF14-167 No reflective all_links() operation MOF 1.2 MOF 1.3 Resolved closed
MOF14-166 RefAssociation::link_exists() signature inconsistent MOF 1.2 MOF 1.3 Resolved closed
MOF14-165 Error in "args" parameter of RefObject::invoke_operation. MOF 1.2 MOF 1.3 Resolved closed
MOF14-164 Typos in Reflective::remove_value_at MOF 1.2 MOF 1.3 Resolved closed
MOF14-161 Exception to indicate no corresponding "specific" operation MOF 1.2 MOF 1.3 Resolved closed
MOF14-160 MissingParameter and TooManyParameters exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-163 Document how to "unset" using the RefObject interface MOF 1.2 MOF 1.3 Resolved closed
MOF14-162 RefObject::value() needs to raise NotSet MOF 1.2 MOF 1.3 Resolved closed
MOF14-157 Edit the MOF specification to improve clarity and readability MOF 1.2 MOF 1.3 Resolved closed
MOF14-156 Revise `container" operations on RefBaseObject MOF 1.2 MOF 1.3 Resolved closed
MOF14-159 Reflective::InvalidDesignator exception MOF 1.2 MOF 1.3 Resolved closed
MOF14-158 Support for IDL prefixes in MOF spec MOF 1.2 MOF 1.3 Resolved closed
MOF14-155 Add support for Package Consolidation / Clustering MOF 1.2 MOF 1.3 Resolved closed
MOF14-154 Document different meaning of "abstract" MOF 1.2 MOF 1.3 Resolved closed
MOF14-153 Update specification to track OCL syntax changes MOF 1.2 MOF 1.3 Resolved closed
MOF14-152 MOF names implicitly tied to implementation MOF 1.2 MOF 1.3 Resolved closed
MOF14-151 MOF RTF Issue: SMIF version of MOF MOF 1.2 MOF 1.3 Resolved closed
MOF14-150 New name clash issue from CORBA 2.3 spec MOF 1.2 MOF 1.3 Resolved closed
MOF14-149 Atomicity of updates MOF 1.2 MOF 1.3 Resolved closed
MOF14-148 exceptions for resolve_qualified_name() MOF 1.2 MOF 1.3 Resolved closed
MOF14-147 Need to specify when are side-effects allowed MOF 1.2 MOF 1.3 Resolved closed
MOF14-146 MOF Constraints are pure predicates MOF 1.2 MOF 1.3 Resolved closed
MOF14-145 MofAttribute values do not have aggregation==composite semantics MOF 1.2 MOF 1.3 Resolved closed
MOF14-144 Cardinality of "RefersTo" and "Exposes" associations MOF 1.2 MOF 1.3 Resolved closed
MOF14-143 Multiplicities on Attributes and References modelled incorrectly MOF 1.2 MOF 1.3 Resolved closed
MOF14-142 Navigability constraint expressed wrongly MOF 1.2 MOF 1.3 Resolved closed
MOF14-140 Navigability constraint expressed wrongly MOF 1.2 MOF 1.3 Resolved closed
MOF14-139 Multiplicities on Attributes and References modelled incorrectly MOF 1.2 MOF 1.3 Resolved closed
MOF14-141 Inconsistent multiplicity for TypeAlias MOF 1.2 MOF 1.3 Resolved closed
MOF14-138 Convenient way to discriminate instances of subclasses MOF 1.2 MOF 1.3 Resolved closed
MOF14-137 Should set_(nil) be legal? MOF 1.2 MOF 1.3 Resolved closed
MOF14-136 set_ needs StructuralError MOF 1.2 MOF 1.3 Resolved closed
MOF14-134 Exception for creating instances of imported supertypes? MOF 1.2 MOF 1.3 Resolved closed
MOF14-135 Description of with_ operations MOF 1.2 MOF 1.3 Resolved closed
MOF14-133 MOF RTF Issue: Behavior of M1 level interfaces vagualy specified MOF 1.2 MOF 1.3 Resolved closed
MOF14-132 MOF RTF Issue: aggregations crossing M1 and M2 package boundary MOF 1.2 MOF 1.3 Resolved closed
MOF14-129 Naming of Tags MOF 1.2 MOF 1.3 Resolved closed
MOF14-128 Identifier formating error in MOF generates IDL MOF 1.2 MOF 1.3 Resolved closed
MOF14-131 MOF RTF Issue: M1 life-cycle operations MOF 1.2 MOF 1.3 Resolved closed
MOF14-130 MOF RTF Issue: Library of collection types? MOF 1.2 MOF 1.3 Resolved closed
MOF14-127 IDL generation Association Template Syntax MOF 1.2 MOF 1.3 Resolved closed
MOF14-126 IDL Mapping/Identifier Naming MOF 1.2 MOF 1.3 Resolved closed
MOF14-125 IDL generation - IMPORT TEMPLATE clarification MOF 1.2 MOF 1.3 Resolved closed
MOF14-124 Illegal IDL redefinitions MOF 1.2 MOF 1.3 Resolved closed
MOF14-123 Incorrect ocl specification(s) MOF 1.2 MOF 1.3 Resolved closed
MOF14-122 Consider a better approach to generated exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-121 Single-valued parameters should not be defined with sequences MOF 1.2 MOF 1.3 Resolved closed
MOF14-120 Operations should return nil reference instead of raising NotSet MOF 1.2 MOF 1.3 Resolved closed
MOF14-119 ConstraintError exception needed in more IDL generation templates MOF 1.2 MOF 1.3 Resolved closed
MOF14-118 ConstrainViolation vs. ConstraintError confusion (editorial) MOF 1.2 MOF 1.3 Resolved closed
MOF14-117 Association IDL generation needs to consider AssociationEnd.isChangeable MOF 1.2 MOF 1.3 Resolved closed
MOF14-114 Generated location parameters need clear specification of base value MOF 1.2 MOF 1.3 Resolved closed
MOF14-113 Type of Facility.MofRepository.packageFactory incompatible with its purpos MOF 1.2 MOF 1.3 Deferred closed
MOF14-116 Association interface generation templates require exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-115 Description of meta-model as a single package is incorrect MOF 1.2 MOF 1.3 Resolved closed
MOF14-112 Editorial; change MOF Type to MOF Class MOF 1.2 MOF 1.3 Resolved closed
MOF14-111 RefObject::create_instance and abstract types MOF 1.2 MOF 1.3 Resolved closed
MOF14-110 MOF IDL Mapping with parameters MOF 1.2 MOF 1.3 Resolved closed
MOF14-109 MOF IDL /MODL - Type Hierarchy error MOF 1.2 MOF 1.3 Resolved closed
MOF14-108 MOF IDL mapping-types of parameters with multiplicities MOF 1.2 MOF 1.3 Resolved closed
MOF14-107 IDL Mapping--#includes for inheritted Packages MOF 1.2 MOF 1.3 Resolved closed
MOF14-106 Type Hierarchy Error in IDL MOF 1.2 MOF 1.3 Resolved closed
MOF14-105 MOF-IDL needs to be re-generated MOF 1.2 MOF 1.3 Resolved closed
MOF14-104 Type Create template, order of parameters MOF 1.2 MOF 1.3 Resolved closed
MOF14-101 Similar to issue 940 MOF 1.2 MOF 1.3 Resolved closed
MOF14-100 package create template: names of parameters need to be formated MOF 1.2 MOF 1.3 Resolved closed
MOF14-103 Similar o issue 941 MOF 1.2 MOF 1.3 Resolved closed
MOF14-102 $issue.summary MOF 1.2 MOF 1.3 Resolved closed
MOF14-99 package create template: ConstraintError MOF 1.2 MOF 1.3 Resolved closed
MOF14-98 Package create template: StructuralError needs to be raised MOF 1.2 MOF 1.3 Resolved closed
MOF14-97 Package create template MOF 1.2 MOF 1.3 Resolved closed
MOF14-94 Typos in MOF 1.1 document (1) MOF 1.2 MOF 1.3 Resolved closed
MOF14-93 IDL Generation Issue - factory operation parameters for multivalued attrib MOF 1.2 MOF 1.3 Resolved closed
MOF14-96 Typos in MOF 1.1 document (3) MOF 1.2 MOF 1.3 Resolved closed
MOF14-95 Typos in MOF 1.1 document (2) MOF 1.2 MOF 1.3 Resolved closed
MOF14-92 External Types as DataTypes Limits Modeling MOF 1.2 MOF 1.3 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
MOF14-87 Is the multiplicity of Model::Tag::values correct? MOF 1.2 MOF 1.4 Resolved closed
MOF14-86 Reflective typos MOF 1.2 MOF 1.4 Resolved closed
MOF14-84 Data types available to metamodels is restricted MOF 1.2 MOF 1.4 Resolved closed
MOF14-91 Missing exception for all_*_links operation MOF 1.2 MOF 1.4 Resolved closed
MOF14-90 Constraints on Associations. MOF 1.2 MOF 1.4 Resolved closed
MOF14-89 Section 5-54 of Meta Object Facility (MOF) Specification MOF 1.2 MOF 1.4 Resolved closed
MOF14-88 MOF is using CORBA string for its string data types MOF 1.2 MOF 1.4 Resolved closed
MOF14-85 Specify behaviour of RefObject.is_instance_of(null,...) MOF 1.2 MOF 1.4 Resolved closed
MOFM2T11-13 Wrong concrete syntax (in EBNF) MOFM2T 1.0 open
MOFM2T11-12 Useful only as a proof of concept, hard to maintain for big projects MOFM2T 1.0 open
MOFM2T11-9 Provide a way for users to get the iteration count in a for loop MOFM2T 1.0 open
MOFM2T11-8 Example ambiguity MOFM2T 1.0 open
MOFM2T11-18 Inconsistency in metamodel Message MOFM2T 1.0 open
MOFM2T11-17 Section: 7.2, 7.3, A3 OCLExpression MOFM2T 1.0 open
MOFM2T11-16 Ambiguity detected in Invocation rule Message MOFM2T 1.0 open
MOFM2T11-14 Section: 8.2 MOFM2T 1.0 open
MOFM2T11-19 Issue: Typos in examples MOFM2T 1.0b1 open
MOFM2T11-15 Specification error in concrete syntax MOFM2T 1.0 open
MOFM2T-7 In chapter '7 Overview': MOFM2T 1.0b1 MOFM2T 1.0 Resolved closed
MOFM2T11-10 Wrong relation in input model MOFM2T 1.0 open
MOFM2T11-11 abstract metaclasses should be italic MOFM2T 1.0 open
MOFM2T11-2 set of problems with the currently described operations MOFM2T 1.0 open
MOFM2T11-1 Missing reference MOFM2T 1.0 open
MOFM2T11-5 File unique id is not useable MOFM2T 1.0 open
MOFM2T11-4 current version of the specification doesn't allow for any "post-processing" of the generated text. MOFM2T 1.0 open
MOFM2T11-3 Section: 7.3, 8.1, 8.1.17 MOFM2T 1.0 open
MOFM2T11-7 Add an attribute to the files block for users to specify generated file's encoding MOFM2T 1.0 open
MOFM2T11-6 Typos/issues in the examples MOFM2T 1.0 open
MOFM2T-9 Whitespace handling rules unclear MOFM2T 1.0b1 MOFM2T 1.0 Resolved closed
MOFM2T-8 Issue: Grammar error: MOFM2T 1.0b1 MOFM2T 1.0 Resolved closed
MOFVD2-2 Sections 5.3 and 5.5 MOFVD 2.0b1 MOFVD 2.0 Resolved closed
MOFVD2-3 Section: section 5.5 MOFVD 2.0b1 MOFVD 2.0 Resolved closed
MOF14-81 WG: Attribute accessors and mutators MOF 1.2 open
MOF14-83 mof rtf issue - coverage of RefXXX interfaces by MOF metamodel MOF 1.2 open
MOF14-82 mof rtf issue - setting UUIDs MOF 1.2 open
MOF14-66 Tags that parameterize a meta-model mapping MOF 1.2 open
MOF14-65 What is a UML "profile"? MOF 1.2 open
MOF14-62 MOF RTF Isue: Conflict between "Facility" and "Package Object " MOF 1.2 open
MOF14-61 Generated operations returning attributes/references should not raise Cons MOF 1.2 open
MOF14-64 Semantics of Reference "set" onto an ordered Association. MOF 1.2 open
MOF14-63 ModelElement needs to have permanent, unique, unchanging, identifier MOF 1.2 open
MOF14-78 Provide tools to chapter 5 UML 1.3R9 draft MOF 1.2 open
MOF14-77 Should Reflective.DesignatorType be "string"? MOF 1.2 open
MOF14-80 Do non-public Attributes need initialising? MOF 1.2 open
MOF14-79 IDL for Reflective Package Interfaces can conflict MOF 1.2 open
MOF14-72 Specify the semantics of Constraint verification MOF 1.2 open
MOF14-71 Add appropriate Attribute default values to the MOF Model MOF 1.2 open
MOF14-76 MOF Model IDL versus OMG Style guidelines MOF 1.2 open
MOF14-75 Need for light-weight References MOF 1.2 open
MOF14-74 Add a new technical overview chapter between chapters 2 and 3" MOF 1.2 open
MOF14-73 Freezing mechanism for all models MOF 1.2 open
MOF14-69 Add support for Exception generalization MOF 1.2 open
MOF14-67 Validate the OCL constraints in the MOF specification MOF 1.2 open
MOF14-68 Add support for default values to MofAttribute MOF 1.2 open
MOF14-70 Define a MOF Class that is the supertype of all Classes MOF 1.2 open
MOF14-36 Collections of imported DataTypes can cause name clashes MOF 1.3 MOF 1.4 Resolved closed
MOF14-35 "exposedEnd" for any of the references in the MOF metamodel. MOF 1.4 open
MOF14-34 Association Generalization Proposal MOF 1.4 open
MOF14-33 Unnecessary constraint on import by nested packages MOF 1.4 open
MOF14-31 Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong MOF 1.4 open
MOF14-30 Restrictions needed for nested Packages and Classes MOF 1.4 open
MOF14-28 Looking up metaobject using MOFID MOF 1.4 open
MOF14-27 resolveQualifiedName operation MOF 1.4 open
MOF14-25 Deprecate object inheritance of class proxy interface MOF 1.4 open
MOF14-24 Alignment of reflective interfaces with JMI MOF 1.4 open
MOF14-29 Navigability of assoc. ends in MOF model MOF 1.4 open
MOF14-26 Remove obsolete material MOF 1.4 open
MOF14-23 Tracking identity of replicated / interchanged metadata MOF 1.4 open
MOF14-32 Multiplicity be optional for non-navigable association ends. MOF 1.4 open
MOF14-47 MOF RTF Issue: typos in Reflective.idl MOF 1.3 MOF 1.4 Resolved closed
MOF14-46 "*" not needed on DataType name MOF 1.3 MOF 1.4 Resolved closed
MOF14-50 MODL Appendix needs updating MOF 1.3 MOF 1.4 Resolved closed
MOF14-49 Model::Contains::container return type wrong MOF 1.3 MOF 1.4 Resolved closed
MOF14-45 Can MOF Class contain a Constant? MOF 1.3 MOF 1.4 Resolved closed
MOF14-44 MOF 1.3 Why have rule against abstract packages? MOF 1.3 MOF 1.4 Resolved closed
MOF14-38 Operation Model::Tag::add_elements_before should not appear in the IDL MOF 1.3 MOF 1.4 Resolved closed
MOF14-37 Reflective IDL fix for CORBA 2.3 MOF 1.3 MOF 1.4 Resolved closed
MOF14-42 Incorrect return type for Assoc query operation MOF 1.3 MOF 1.4 Resolved closed
MOF14-41 "*" prefix on Simple Type Names (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-43 MOF 1.3 Incorrect attribute order in diagrams MOF 1.3 MOF 1.4 Resolved closed
MOF14-48 MofErrors for refQueryLink and refModifyLink MOF 1.3 MOF 1.4 Resolved closed
MOF14-39 Can MOF Package contain a Constant? (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-40 Package Contains Association (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-10 The Metadata architecture needs to move away from the 4 levels and labels MOF 1.3 open
MOF14-9 Specify XMI parameters for the MOF / XMI interchange format MOF 1.3 open
MOF14-19 Delete all non-MOF-specific terms from the Glossary MOF 1.3 open
MOF14-18 Add 'semantics' attribute to Operation. MOF 1.3 open
MOF14-16 The current MOF package level import is not sufficient MOF 1.3 open
MOF14-15 MOF-RTF issue: AttachesTo.modelElement - ordered MOF 1.3 open
MOF14-22 mof-rtf issue: Association Generalization MOF 1.4 open
MOF14-21 Modeling OCL Helper Functions MOF 1.4 open
MOF14-13 The role name of the Namespace->ModelElement association end MOF 1.3 open
MOF14-12 role is named 'containedElement' while the reference is named 'contents' MOF 1.3 open
MOF14-20 Representation of constraints MOF 1.4 open
MOF14-11 predefined tag for marking attributes to act as qualifier in classifier MOF 1.3 open
MOF14-17 Disallow null instance values MOF 1.3 open
MOF14-14 MOF IDL rules to minimize network roundtrips MOF 1.3 open
MOF14-60 Clarify whether null instances are currently valid MOF values MOF 1.3 MOF 1.4 Resolved closed
MOF14-59 IDL mapping Tag for specifying IDL #pragma versions MOF 1.3 MOF 1.4 Resolved closed
MOF14-58 ::Model::Package::internalize/externalize in MOF 1.4 MOF 1.3 MOF 1.4 Resolved closed
MOF14-57 Move the 'verify' operation to RefBaseObject MOF 1.3 MOF 1.4 Resolved closed
MOF14-56 Primitive data types usage in the MOF Model. MOF 1.3 MOF 1.4 Resolved closed
MOF14-55 Error in MOF 1.3 XMI - ViolationType MOF 1.3 MOF 1.4 Resolved closed
MOF14-53 predefined tag for marking attributes needed MOF 1.3 MOF 1.4 Resolved closed
MOF14-52 MOF IDL change MOF 1.3 MOF 1.4 Resolved closed
MOF14-54 MofError when Operation impl violates structural constraints MOF 1.3 MOF 1.4 Resolved closed
MOF14-51 MOF Unbounded should have type long MOF 1.3 MOF 1.4 Resolved closed
MOF14-5 MOF 1.3 Why prevent nonpublic Associations? MOF 1.3 open
MOF14-4 MOF 1.3 IDL template for clustering uses wrong name MOF 1.3 open
MOF14-2 Template should suppress add for [x..x] Attributes MOF 1.3 open
MOF14-1 MOF and IDL repository ids MOF 1.3 open
MOF14-8 Reflective interface for Package factory MOF 1.3 open
MOF14-7 Minor changes to some Reflective operations MOF 1.3 open
MOF14-3 MOF specifies no interfaces for actually (de-)serializing a model MOF 1.3 open
MOF14-6 MOF 1.3 Package should subtype Classifier MOF 1.3 open
MOF2I2-39 Editorial issue(s) MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-40 Resolution of issue 9154 does not work for primitives MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-35 Semantic of reflective operations should match MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-34 Align reflective argument passing in EMOF to CMOF MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-38 Mapping of subsetted properties do not need to change name of operation MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-37 Align mapping of tags to MOF2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-36 "set" operation for derived attributes MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-33 RefObject::ref_get (PropertyName) specified on page 67 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-32 Align Base-IDL Reflection Mapping to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-31 Align CCM Reflection Mapping to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-30 RefCCMBaseObject and RefBaseObject MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-29 Clarify the Extents concept in the mapping MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-28 Rule (50) is not applied in example (12). MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-27 Some referenced sections do not exist MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-26 Numbering and references to examples are not consistent MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-23 Remove the Common suffix from the interface names in the common mapping MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-25 Example 4 is not totally consistent with rules (35) and (36). MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-24 Align Handling of Collections to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-20 Subsection 6.2.1 (Mapping of Identifiers) should be independent of MOF1.4 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-19 Not all assumptions of MOF2.0 Core do hold MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-22 Align MOFObject to MOF2.0 Core MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-21 specification should throughout be discretely divided into EMOF and CMOF MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-18 References to other specification documents are not up to date MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-17 CMOF::Exception class is no longer in MOF2.0 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-16 Remove FTF comments MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-15 factory create_ (); MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-14 Rule (38) p. 30 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-8 Rule (38): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-10 Rule (26) p. 21 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-9 Rule (35): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-13 Section 7.4 pp. 49,50 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-12 Section 7.6.3 pp. 59,60 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-11 Rule (27) p. 21 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-7 Section 7.4; MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-6 Section 7.6.3 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-3 Section: 8.2.2;8.2.6 MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-5 Rule (27) MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-4 Rule (26): MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-2 section 6.3.3, p.31, example IDL MOF2I 2.0b1 MOF2I 2.0 Resolved closed
MOF2I2-1 section 7.3, p.44, example IDL MOF2I 2.0b1 MOF2I 2.0 Resolved closed

Issues Descriptions

The ontology (RDF files) should be revised to use the Commons ontologies

  • Status: open  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. Kendall)
  • Summary:

    Currently, the MOF2RDF ontologies do not include copyrights or metadata that would indicate licensing. Additional metadata would also assist users in understanding how to use the content of these ontologies. Ontology-level and element level metadata, similar to what has been done for other OMG standard ontologies, would be helpful and provide missing governance details.

  • Reported: MOF2RDF 1.0 — Tue, 4 Jun 2024 18:23 GMT
  • Updated: Tue, 4 Jun 2024 18:23 GMT

Not able to download documents

  • Status: open  
  • Source: Statnett SF ( Svein Olsen)
  • Summary:

    Hi,
    I am able to download the Specification, but not any of the Normative Machine Readable Documents. I assume they are collected in a zip file, but non of the item it pointing to this zip file.

    Best regards,
    ¨Svein

  • Reported: MOF2RDF 1.0 — Sat, 18 Jul 2020 18:02 GMT
  • Updated: Thu, 7 Dec 2023 16:37 GMT

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


In Clause 10, the base URL is misspelled

  • Key: MOF2RDF-8
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    In Clause 10, the base URL of all displayed OWL code is spelled "exampe.com", which should be "example.com". The same misspelling is present in the machine-readable files. The URLs shall be corrected and the machine-readable files re-issued. This will also change the front page of the specification.

    While at it, Annex B (List of Machine-Readable Files) shall be deleted. This function is handled by the OMG Specification Catalog.

  • Reported: MOF2RDF 1.0b1 — Tue, 12 Nov 2019 22:38 GMT
  • Disposition: Resolved — MOF2RDF 1.0
  • Disposition Summary:

    In Clause 10, the base URL is misspelled

    Indeed, "example.com" is misspelled as "exampe.com" throughout the whole Clause 10. While technically not worn, it looks unprofessional.

    Correct all occurrences of "exampe.com" throughout Clause 10, correct also the machine readable files and re-release the whole set.

    Delete Annex B, its function has been taken-over by the specification catalog.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

References to, and explanation of Usage for Turtle and QVT

  • Key: MOF2RDF-7
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    The specification uses OWL Turtle Syntax and the QVT Graphical Syntax in normative clauses, therefore references to these specifications in Clause 3.1 (Normative References) are required.

    In this context, the introductory paragraphs of Clauses 8 and 9 should be reworded to eliminate the explicit mentioning of XSLT and RDFXML. For the mapping specification it is irrelevant with which technology the definitions were produced. Regarding RDFXML, while it might be a transitional representation of the OWL output, it should be removed from the text since this transitional form never shows up in the specification.

  • Reported: MOF2RDF 1.0b1 — Tue, 12 Nov 2019 22:33 GMT
  • Disposition: Resolved — MOF2RDF 1.0
  • Disposition Summary:

    References to, and explanation of Usage for Turtle and QVT

    RDF/XML is not used in this specification, all OWL code is in RDF Turtle syntax, therefore swap the RDF 1.1 Turtle reference in, replacing RDF/XML.

    The QVT graphical notation for transformations is used in the code displays, therefore a normative reference for QVT shall be added.

    As a consequence, the lead-in paragraphs for Clause 8 and Clause 9 shall be changed accordingly.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Phrase owl:allValuesFrom garbled

  • Key: MOF2RDF-3
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    In Clause 9.2.5 after the code display for "ClassA3 / attr3" change the phrase "owl:allVal esFrom" to "owl:allValuesFrom"

  • Reported: MOF2RDF 1.0b1 — Mon, 11 Nov 2019 16:47 GMT
  • Disposition: Resolved — MOF2RDF 1.0
  • Disposition Summary:

    Phrase owl:allValuesFrom garbled

    In Clause 9.2.5, subsection "Properties typed by Flat Literal Type", after the code display for ClassA3 - attr3, the phrase "owl:allValuesFrom" is misspelled.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Insert missing word

  • Key: MOF2RDF-2
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    In the first sentence after the code display, insert the word "link" after "This represents the sequence number of the current"

  • Reported: MOF2RDF 1.0b1 — Mon, 11 Nov 2019 16:42 GMT
  • Disposition: Resolved — MOF2RDF 1.0
  • Disposition Summary:

    *Insert missing word *

    Insert the missing word "link" into the description.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Improve Formatting and Correct Captions

  • Key: MOF2RDF-1
  • Status: closed  
  • Source: 88solutions ( Mr. Manfred R. Koethe)
  • Summary:

    Improve the document formatting so that captions are not flowing to the next page following a figure or code display.

    Correct the following captions:
    Clause 8.2.2: "Class" => "Stereotype"
    Clause 8.2.6: "Association" => "AssociationClass"

    In Clause 9.2.5, subsection "Properties typed by Structure or Class Types", reword the second paragraph following the code display (without changing its meaning) so that it does not overflow into the page margin.

  • Reported: MOF2RDF 1.0b1 — Mon, 11 Nov 2019 16:37 GMT
  • Disposition: Resolved — MOF2RDF 1.0
  • Disposition Summary:

    Improve Formatting and Correct Captions

    Group code displays with corresponding captions to ensure code displays and captions appear always on the same page.

    Correct caption text for 8.2.2 Stereotype and 8.2.6 AssociationClass

    Reword second paragraph in clause 9.2.5, subsection "Properties typed by Structured or Class Types" to avoid overflow into page margin.

  • Updated: Mon, 30 Mar 2020 19:49 GMT

Typo

  • Status: open  
  • Source: none ( Franz)
  • Summary:

    Typo in the EBNF `OclExpessionCS` instead of `OclExpressionCS`

  • Reported: MOFM2T 1.0 — Fri, 18 Oct 2019 14:22 GMT
  • Updated: Tue, 22 Oct 2019 19:49 GMT

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

QVTo : Confusing isVirtual definition for imperative operation calls

  • Key: QVT14-25
  • Status: open  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The ImperativeCallExp::isVirtual attribute is defined as follows: "Unless isVirtual is true, this invocation is virtual." This is extremely counter-intuitive and apparently stems from a careless renaming. As a result, virtual call semantics are disabled by default, because the default value 'true' implies that an operation is "statically called". The default should be virtual call semantics, so the description should be turned around.

  • Reported: MOF 1.2 — Thu, 11 Feb 2016 13:01 GMT
  • Updated: Wed, 13 Apr 2016 08:20 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

QVTo: Mapping Overloading

  • Key: QVT13-99
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

    It probably has another provided by name collision. This is unspecified.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 19:34 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    What are the QVTo mapping overloading semantics?

    QVTo has one form of mapping overloading provided by disjuncts. This is poorly specified.

    It probably has another provided by name collision. This is unspecified.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Mapping and other Identifiers

  • Key: QVT13-93
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The <rulerefs> between mappings has no defined semantics.

    Presumably:

    <package-name>*::<transformation-name>::<context-type>::<mapping-name>

    allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 12:29 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Undefined rulerefs

    The <rulerefs> between mappings has no defined semantics.

    Presumably:

    <package-name>*::<transformation-name>::<context-type>::<mapping-name>

    allowing <package-name>*::<transformation-name> to be omitted defauklting to the current transdformation, and, preserving the current example semantics, resolving an omitted <context-type> by serching all mapping names in the transformation.

    Issue Links

    Discussion

    Since <mapping_id> needs definition, we can take the opportunity to rename the strange <rulerefs>.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: VariableInitExp wording for missing initializer

  • Key: QVT13-78
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    8.2.2.10 VariableInitExp says

    A variable may not declare an initialization value.

    when surely it means

    A variable may omit an initialization value.

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 11:32 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Unfortunate VariableInitExp wording for missing initializer

    8.2.2.10 VariableInitExp says

    A variable may not declare an initialization value.

    when surely it means

    A variable may omit an initialization value.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: xselectOne, xcollectselectOne is Sequence of One not One

  • Key: QVT13-97
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The return type of xselectOne, xcollectselectOne returns a SEquence rather than an optional value.

  • Reported: MOF 1.2 — Tue, 6 Oct 2015 18:42 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    xselectOne, xcollectselectOne is Sequence of One not One

    The return type of xselectOne, xcollectselectOne returns a Sequence rather than an optional value.

    Discussion

    QVT13-34 revealed numerous errors in the pseudocode. This error is just one of many fixed by its resolution.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: access/extension default for ImportKind

  • Key: QVT13-58
  • Legacy Issue Number: 19816
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

    The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

    Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

    Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

  • Reported: MOF 1.2 — Thu, 9 Jul 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Unspecified handling of imports without access/extends

    For imported compilation units, the specification should clearly state what happens if there is no corresponding ModuleImport for any of the modules included inside the imported unit.

    The Eclipse QVTo implementation applies extends semantics by default. A very bad idea, because it leads to undesired extensions and overridings (especially in case of multiple modules per unit).

    Using access as a default is a much better idea, but maybe clutters the namespaces at AST level with needless module imports.

    Therefore applying neither access nor extends could be another good idea, but lacks a helpful default behavior.

    Discussion

    Following some off-JIRA correspondence, the original issue is clearer and simpler.

    The 8.2.1.4 words say that ImportKind has only two possibilities. But the words and model omit a [1] multiplicity or defaultValue so that null is a third possibility. The grammar also permits a missing ImportKind.

    So as suggested we could introduce a third null semantics, or define one of access/extends as the default.

    I see no benefit in a third semantics.

    "extends" is a very serious mutating activity, not a default.

    "access" is harmless and non-mutating. Hardly AST clutter. If the user didn't want the names the user should not have specified an import.

    Let "access" be the default.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: object creation in helpers

  • Key: QVT13-120
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The prohibition on creation or update of instances in helpers has no justification. Why?

  • Reported: MOF 1.2 — Tue, 13 Oct 2015 09:58 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Allow object creation in helpers

    The prohibition on creation or update of instances in helpers has no justification. Why?

    Discussion

    This came up while clarifying wording for QVT13-33.

    The prohibition is presumably intended to ensure that all object creation has a corresponding trace record. A good idea but beyond the pragmatic integrity of QVTo. Untraced objects can be created in mappings anyway, so prohibiting their creation in helpers is just an unhelpful restriction on programming flexibility.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: Calling the super implementation of an overriding operation

  • Key: QVT13-61
  • Legacy Issue Number: 19823
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

  • Reported: MOF 1.2 — Mon, 3 Aug 2015 04:00 GMT
  • Disposition: Duplicate or Merged — QVT 1.3
  • Disposition Summary:

    Calling the super implementation of an overriding operation

    There is currently no way for an overriding operation to call its overridden super implementation. ImperativeOCL should provide something similar to the 'super' reference which is available in Java.

    Discussion

    QVT13-93 clarifies the concept of a mapping identifier. An arbitrary mapping may therefore be called:

    self.map My::Tx::Your::Type::doIt(withSomething);

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTo: non-mutating List operation example problem

  • Key: QVT13-60
  • Legacy Issue Number: 19810
  • Status: closed  
  • Source: Heinz Nixdorf Institute, University of Paderborn ( Christopher Gerking)
  • Summary:

    The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

    helper Package::computeCandidates(inout list:List) : List

    { if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }

    Therefore the snippet should rather use List::add.

  • Reported: MOF 1.2 — Thu, 25 Jun 2015 04:00 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    Incorrect use of side-effect free append in example

    The following helper from the specification is a NOP, because List::append has no side effect in QVT 1.2.

    helper Package::computeCandidates(inout list:List) : List

    { if (self.nothingToAdd()) return list; list.append(self.retrieveCandidates()); return list; }

    Therefore the snippet should rather use List::add.

    Discussion

    Yes

  • Updated: Tue, 29 Mar 2016 15:09 GMT

QVTc/QVTo/QVTr acronyms

  • Key: QVT13-101
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

    Suggest that the QVT specification at least define them and perhaps use them a little too.

  • Reported: MOF 1.2 — Wed, 7 Oct 2015 11:51 GMT
  • Disposition: Resolved — QVT 1.3
  • Disposition Summary:

    QVTc/QVTo/QVTr acronyms

    The full names of the QVT languages are a bit cumbersome and so QVTc/QVTo/QVTr are often found in non-OMG usage.

    Suggest that the QVT specification at least define them and perhaps use them a little too.

  • Updated: Tue, 29 Mar 2016 15:09 GMT

Rationalize title

  • Key: QVT14-14
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Pete Rivett, private email, requests removal of "2.0" from the "MOF 2.0 QVT 1.3" title.

    Two versions numbers are certainly confusing.

    But Isn't the "MOF" redundant too?

  • Reported: MOF 1.2 — Tue, 10 Nov 2015 17:02 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

Trace Record not suitable for Incremental Execution

  • Key: QVT14-15
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The glossary definition of Incremental Update strongly suggests that the trace necessary to execute a transformation is also suitable for incremental execution. This is a total falacy.

    Incremental execution of a Rule R with an input s must occur if any relevant property of s changes, which includes any property navigable from s. e.g. s.a.b.c.name. Therefore the trace for incremental execution must identify the identity and value of all accessed property values so that any change can influence re-execution.

    Since accessed values may be produced by another mapping, the trace must also record the identity and value of all assigned property values too.

    This affects all of QVTc, QVTr, and QVTo.

    For QVTo, a re-execution must repeat the accidental ordering of Set elements. Does the specification define an order or just require implementation magic? Is this then a determinstic form of asOrderedSet()?

  • Reported: MOF 1.2 — Wed, 28 Oct 2015 19:10 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: What are the operation overloading semantics?

  • Key: QVT14-20
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Does QVTo support operation overloading in a similar way to Java?

    How are conflicting contextual operations resolved when access semantics are used for import?

    How are conflicting contextual operations resolved when extension semantics are used for import?

    Is the resolution at run-time different to that at compile-time?

  • Reported: MOF 1.2 — Fri, 23 Oct 2015 09:21 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Enhance Status to support access to nested transformation trace data

  • Key: QVT14-18
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Transformation::transform()/parallelTransform() support a nested invocation but the returned Status content is very limited.

    Suggest 1: Reify TraceData/TraceRecord so that arbitrary OCL queries can be executed.

    Suggest 2: Add a getTraceData() to Status and 'this'.

    Suggest 3: Add an optional Status first argument to all resolve() methods to enable use on an invoked Transformation.

    NB. Since a transformation invocation involves cloning, resolve() should hide the clones so that the caller sees only a single object space.

    Suggest 4: TraceData/TraceRecord/Status/Transformation/Model should be / share share an abstraction with QVTc/QVTr.

  • Reported: MOF 1.2 — Wed, 14 Oct 2015 08:46 GMT
  • Updated: Tue, 22 Dec 2015 15:31 GMT

QVTo: Eliminate deprecated Typedef class


QVTo: Rework ImperativeOCL to compose rather than delegate EssentialOCL

  • Key: QVT14-22
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Issue 13082 - http://solitaire.omg.org/browse/QVT13-8 identifies the unsound relationship between ImperativeOCL and EssentialOCL.

    It offered a simple textual fix which was exploited to resolve the original issue.

    It also suggests a harder rework to establish modeling integrity. This issue forks off the rework not resolved by the original issue.

    (B) - (Major rework.) Rework the abstract syntax to reuse OCL
    expressions by composition rather than by inheritance.
    Imperative expressions ( => rename to 'statements' ) then may
    contain sub-statements and OCL expressions; OCL expressions
    are reused unchanged from the OCL spec (no imperative
    sub-expressions, no side-effects).
    These issues have been discussed on the MoDELS 2008 OCL Workshop,
    more details can be found at
    http://www.fots.ua.ac.be/events/ocl2008/PDF/OCL2008_9.pdf

    (Since this is a breaking structural change, it is unlikely to happen before QVT 2.0)

  • Reported: MOF 1.2 — Mon, 5 Oct 2015 17:40 GMT
  • Updated: Tue, 22 Dec 2015 15:31 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

Associations should not be required to be unique

  • Key: MOF2I2-58
  • Legacy Issue Number: 6903
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    I disagree with [7] (in Reflection Factory Constraints) - this is something we had a lot of discussion about
    with Steve and Joaquin and it was agreed that Associations should not be required to be unique.

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    This is an inconsistency since the constraint is not documented as part of restrictions in CMOF or EMOF.

  • Updated: Sun, 8 Mar 2015 22:12 GMT

MOF Figure 18

  • Key: MOF24-66
  • Legacy Issue Number: 7564
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I'm confused by something in MOF Figure 18. I see that this is a "semantic domain model," and i know i'm not clear on what that means. But i feel my question makes sense absent a clear understanding of what the MOF specification means by 'semantic domain model.' This diagram is apparently the extension of "the UML 2 Instances model" mentioned at 15.1. I'll assume 'Instances model' means the Infrastructure package, Instances. And, indeed, the drawing there is (mostly) reproduced in Figure 18. My question is about the extensions shown. I'll pick one such extension to make the question concrete. The drawing shows a class, Instance, a subclass of InstanceSpecification. The Infrastructure specification is clear: an instance and an instance specification specifying that instance are not in the same model. My question: Does the term 'instance' have a different meaning in MOF than in the Infrastructure, or are the objects of the class, Instance, not instances, or what?

  • Reported: MOF 2.0 — Tue, 6 Jul 2004 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:10 GMT

The 'isID' attribute in class MOF::CMOF::Property remains unclear

  • Key: MOF24-65
  • Legacy Issue Number: 6920
  • Status: closed  
  • Source: Fraunhofer FOKUS, Germany ( Michael Soden)
  • Summary:

    The 'isID' attribute in class MOF::CMOF::Property remains unclear for constructed types like e.g. collections.

    Proposed resolution: Detail specifcation of the 'isID' attribute with respect to other than primitive and class types. Suggestions: (1) identity is established for more complex types if identity 'isID' or "natural" identity (i.e. creation based identity) is given recursively for all referenced instances, or (2) if e.g. a collection has itself identity, then identity is established if the collections are the same

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

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:10 GMT

chapter 10 rewrite

  • Key: MOF24-64
  • Legacy Issue Number: 6695
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The submitters decided to put off to the FTF the chapter 10 rewrite, to correct text that refers to capabilities removed from the final submission.

    Proposed resolution: This reporter will prepare a proposed rewrite

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

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:10 GMT

diagrams mostly use unspecified «combine»

  • Key: MOF24-63
  • Legacy Issue Number: 6694
  • Status: closed  
  • Source: XTG, LLC ( Joaquin Miller)
  • Summary:

    The diagrams mostly use «combine», but what that means is not specified. The defined package merge types are define and extend.

  • Reported: MOF 2.0 — Thu, 11 Dec 2003 05:00 GMT
  • Disposition: Closed; No Change — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:10 GMT

Issue for EMOF in UML 2 Infrastructure/MOF 2 FTF

  • Key: MOF2I2-57
  • Legacy Issue Number: 7548
  • Status: closed  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    The EMOF model should contain a tag on EMOF:Element of XMI ContentType with value "any".

    See the discussion and resolution of MOF 2 XMI FTF issue 6345 for background.

  • Reported: MOF2I 1.0 — Fri, 11 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    Add XMI tag contentType=”any” to Appendix A and in the metamodel.

  • Updated: Sun, 8 Mar 2015 22:09 GMT

object in a useContainment Extent

  • Key: MOF2I2-56
  • Legacy Issue Number: 7454
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    Why is that an object in a useContainment Extent cannot have the extent as its container? (This is stated on page 22 of the Final Adopted Spec

  • Reported: MOF2I 1.0 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

semantics of Reflection::Object

  • Key: MOF2I2-55
  • Legacy Issue Number: 7453
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    According to page 17, the semantics of Reflection::Object require that all instances of MOF model elements must specialize EMOF::Object. My question is, does this specialization have to be explicit or implicit? That is, if I create a blank MOF Class and ask for its superclasses, will they include EMOF::Object? If I send it a "getMetaClass" message, for example, will it understand it, or do I have to explicitly add EMOF::Object to its superclass property?

  • Reported: MOF2I 1.0 — Wed, 9 Jun 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Correct addAll() input parameter type

  • Key: MOF2I2-54
  • Legacy Issue Number: 6910
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    ReflectiveCollection::addAll should take a ReflectiveCollection, not a ReflectiveSequence

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    change as suggested

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Remove allowNull and serializable from EMOF DataType

  • Key: MOF2I2-53
  • Legacy Issue Number: 6908
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    EMOF:

    • DataType.allowNull should be removed
    • DataType.serializable should be removed. What are the use cases for
      it? It seems to me that all the values need to be serializable to allow
      interoperability
  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ReflectiveSequence is not sufficient - add iterator, remove addAll

  • Key: MOF2I2-52
  • Legacy Issue Number: 6907
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    Summary:
    Martin has proposed adding an iterator operation Iterator and removing addAll.
    Iterator would return a ReflectiveIterator that can be used to iterate through all the elements of the collection. If the underlying collection changes while holding an iterator, the behavior of iterator is undefined.

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    AddAll is useful as an atomic operation. There would be limited value in a language independent iterator – it will tend to make for non-optimal language bindings

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ad-03-04-07/Non-orthogonal additions to UML Core

  • Key: MOF2I2-49
  • Legacy Issue Number: 6494
  • Status: closed  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    Issue: The MOF 2 Core specification adds elements to the meta-metamodel that
    are not part of the UML 2 Core. For example, see the sections entitled
    "EMOF Extensions to Basic" and "CMOF Extensions to Core::Constructs." The
    MOF 2 Core's abstract syntax should be a subset of UML. (For detailed
    explanation of why this is advisable, see ad/03-03-30). Note that this
    subset principal allows for MOF to specify orthogonal "mix-in" elements,
    such as packages for reflection and identity.

    Recommendation: Either add the extra elements to the UML 2 Core or else
    remove them from MOF.

  • Reported: MOF2I 1.0 — Fri, 7 Nov 2003 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

ReflectiveSequence is not sufficient, need nulls within a list

  • Key: MOF2I2-51
  • Legacy Issue Number: 6906
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    Summary:
    For interoperability with the XML relational databases, we need to be able to support nulls within a list

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

No container for tags in tag model

  • Key: MOF2I2-50
  • Legacy Issue Number: 6905
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Summary:
    The tag model is lacking a container for tags. Why not make tags NamedElements (need to check if that’s
    good enough)?

  • Reported: MOF2I 1.0 — Thu, 15 Jan 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF 2.0 Core 03-04-07, Chapter 5. Identifiers

  • Key: MOF2I2-47
  • Legacy Issue Number: 6390
  • Status: closed  
  • Source: Hendryx & Associates ( Stan Hendryx)
  • Summary:

    On page 36:

    “Identity extends Basic::Property with the ability to designate a property as an identifier for the containing object. Properties: isID: Boolean [0..1] True indicates this property can be used to uniquely identify an instance of the containing Class. Only one Property in a class may have isID==true.”

    The restriction that only one Property in a class may have isID==true is debilitating. It is common for objects to be identified in the modeled application domain by a unique combination of a set of properties. For example, an object that represents an instance of an n-ary association in the modeled domain will, in general, be identified by a unique combination of n properties, each one of which is an identifier of a participating object in the association. Not being able to carry this natural condition into the MOF requires practitioners to devise a work-around, such as introducing a superfluous surrogate identifier, to be able to externally identify such objects.

    It is requested that the MOF 2.0 Core specification be revised by the FTF to allow any number of sets of properties to be identifiers. Any client of an object needs to be able to select the identifier set most convenient for them, and different clients need to be able to accurately identify the object, regardless of how other clients may find it.

    This issue is important to the Business Semantics of Business Rules submissions, which require domain identifiers for objects. Other MOF users will also benefit.

    Introduction of the Identity package is a potentially powerful and badly needed improvement over MOF 1.x to enable the use of external identifiers for MOF objects, which will greatly facilitate accurate model interchange, reuse, aggregation, and transformation. The present limitation stunts this potential. Please take this modest extra step to assure the full potential of the Identity package can be realized.

  • Reported: MOF2I 1.0 — Fri, 24 Oct 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF 2 Issue: Reflexion and Links

  • Key: MOF2I2-46
  • Legacy Issue Number: 5996
  • Status: closed  
  • Source: MEGA International ( Mr. Antoine Lonjon)
  • Summary:

    The problem
    -----------

    In the reflexion package of MOF2, the proposal for links assumes that
    AssociationEnds are ordered.
    There is an implicit mapping between firstObject and secondObject roles and
    AssociationEnds is based on this assumption:
    FirstObject maps to the first associationEnd
    SecondObject maps to the second associationEnd

    This leads to the following Operation to create links in the Factory Class:

    createLink(association: Association, firstObject : Object, secondObject :
    Object): Link

    At first glance, this solution provides an easy way to identify the link
    members in parameters of link operations. However, the AssociationEnd is
    difficult to read. It is closer to relational concepts than to
    object/association principles.
    One will always have to guess which is the first or second object.
    The modeler who has created the association might remember the order. But
    the user using the association will probably be lost.

    Example:
    Country:Class - resident:AssociationEnd (First) - Citizenship:Association

    • country:AssociationEnd (Second) - Country:Class

    createLink("Citizenhip": Association, "Thomas": Object : "France" :
    Object)

    Proposal
    --------
    The idea is to benefit from the semantic carried by AssociationEnds
    themselves:
    A link defines members. Each member references a participant object
    according to a role defined by the AssociationEnd.
    Thanks to opposite association of AssociationEnds (aka Property), it is
    possible to identify one end from another. This means that if we create
    links from an AssociationEnd viewpoint, there is no need to order
    AssociationEnd.
    The proposal is to order the creation parameters as follow: sourceObject,
    oppositeRole, oppositeObject.
    Of course, this approach only works for binary associations. But the focus
    of AssociationEnd is the first step to take into account nary associations.

    This also highlight that what matters most in Association semantic is the
    role name of AssociationEnds.
    It is usually much more difficult to have a meaningful name for association.
    This is why we can often see names such as "has for ..." which do not carry
    much information about the association.

    All operations on links are redefined as follow:

    createLink (sourceObject : Object, oppositeRole : Property, oppositeObject :
    Object)
    Example:
    createLink("Thomas:Object","country:Role","France:Object")
    equivalent to:
    createLink("France:Object","resident:Role","Thomas:Object")

    linkedObjects (sourceObject : Object, oppositeRole : Property) :
    Object[0..*]

    LinkExists (sourceObject : Object, oppositeRole : Property, oppositeObject :
    Object) : Boolean

    Proposal Comments
    -----------------
    A better proposal would not use the opposite role but the role attached to
    the object participation to the association.

    createLink("resident:Property","Thomas:Object","France:Object")

    But experience shows that this is two much unsual for modelers. This would
    however be the right path for the introduction of nary associations.

  • Reported: MOF2I 1.0 — Fri, 11 Jul 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

Navigating metalevels/instance relationships

  • Key: MOF2I2-45
  • Legacy Issue Number: 5948
  • Status: closed  
  • Source: Queensland University of Technology ( Jim Steel)
  • Summary:

    Hi, this question from Mike Lawley @ DSTC (I have CC'd him),
    >
    > How does one navigate metalevels in MOF2? "Object" has the operation
    > "getMetaClass(): Class", but how can I explicitly model (via
    > a reference/
    > association) that MyObj is an instance of MyClass.
    >
    > Note, I can see exactly how to do this in CMOF for Links –
    > there is an "instance" association between Link and
    > Association in Fig 8-8.
    >
    > Incidentally, is this list the right forum for questions
    > about the submission, or should it be addressed to a mof-rtf
    > list or similar?

  • Reported: MOF2I 1.0 — Tue, 10 Jun 2003 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

MOF should include Profile package

  • Key: MOF2I2-48
  • Legacy Issue Number: 6408
  • Status: closed  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The Infrastructure library contains a Core model package and a Profile package.
    The former is reused in MOG, but the latter is not part of MOF.
    This means that MOF QVT submissions cannot build on the Profiles concept for marking (meta) models and they cannot define mappings for profiled meta models.
    MDA style mappings from PIM to PSM or between PSMs requires support for mapping between profiled models in many UML modeling tools that implement PSMs as profiles.
    If MOF QVT cannot deal with mappings to and between profiled models, these tools will require another solution.

  • Reported: MOF2I 1.0 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0b1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:09 GMT

removing section 12.3 EMOF Merged Model ?

  • Key: MOF2I2-44
  • Legacy Issue Number: 7957
  • Status: closed  
  • Source: International Business Machines ( Mr. Jim Amsden)
  • Summary:

    Issue 6494 resolution calls for removing section 12.3 EMOF Merged Model. Removing this section would require readers to understand and mentally perform a package merge in order to see the complete EMOF model. It would also make it necessary for EMOF implementers to have an implementation of Constructs and package merge in order to implement EMOF. Retaining section 12.3 provide all the information required to fully understand and implement EMOF without requiring the reader or implementer to know anything about package merge.

  • Reported: MOF2I 2.0b1 — Wed, 1 Dec 2004 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:06 GMT

Question on M-Levels

  • Key: MOF2I2-43
  • Legacy Issue Number: 7749
  • Status: closed  
  • Source: SAP SE ( Axel Uhl)
  • Summary:

    section 7.2 of the MOF 2.0 specification (similar to previous versions of the MOF spec) still contains this bold sentence: "The MOF 1.4 Reflection interfaces allow traversal across any number of metalayers recursively." I'm wondering how I would create a MOF-based system with more than three layers that really "live" inside a MOF-based repository. Let's take a look at UML, for example. If we forget for a while that UML 2.0 and MOF 2.0 share a common core, I could consider the UML metamodel as just another modeling language defined using MOF.

    Now the UML metamodel defines zillions of classes, all of them being instances of MOF::Class. One of them happens to be UML::Class, a classifying model element which allows me to create model elements in the UML modeling languages that themselves conceptually act as meta-objects that I may wish to instantiate.

    However, apart from the "shared core trick," the MOF doesn't have any knowledge about the MOF::Class object UML::Class being special, and in particular being a classifying meta-object.

    The sentence from 7.2 suggests that I can have the following:

    myDog.getClass() == Dog
    Dog.getClass() == UML::Class
    UML::Class.getClass() == MOF::Class

    However, creation of a model element with the reflective capabilities as found in the MOF 2.0 specification seems to allow me only to create the UML::Class instance named "Dog" as I can use UML::Class as an argument to Factory::createObject(...). The resulting object, however, is no longer an instance of MOF::Class and can therefore not be used for a factory call in order to create an instance.

    Currently available language bindings for MOF 1.4 as I understand them correspondingly don't allow for this flexible multi-layering idea. Take JMI, for example. While the standard defines how to derive the class proxy for UML::Class, I cannot simply instantiate the UML::Class instance Dog because it's not a MOF::Class instance.

    Would I have to import the MOF core into my metamodel and have UML::Class specialize MOF::Class? (Tricky enough, MOF 2.0 doesn't even have to create a specialization relation because the two are identical. But I think you get the picture; I could have chosen to use my own metamodel, different from UML, but still introducing a classifying class.) If this was the case, then probably there would be something missing from the language bindings and reflective capabilities. For the JMI example, I'd then expect to be able to obtain a class proxy for an instance of my UML::Class so that I can create instances of that particular UML class, e.g., the "myDog" instance used in the example above.

    Any ideas?

  • Reported: MOF2I 2.0b1 — Thu, 9 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:06 GMT

Translation between EMOF and CMOF in MOF 2.0

  • Key: MOF2I2-42
  • Legacy Issue Number: 7647
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I am reading the "Meta Object Facility (MOF) 2.0 Core Specification"
    document ptc/03-10-04. In the section about EMOF, there is the statement
    "The value of Essential MOF is that it provides a straightforward
    framework for mapping MOF models to
    implementations such as JMI and XMI for simple metamodels." From that
    statement, I inferred that the reason that EMOF exists is largely to
    define XMI 2.0 and (hypothetically) JMI 2.0. In particular, it seemed
    from reading the EMOF introduction that the XMI 2.0 and JMI 2.0
    specifications would depend only on EMOF (and NOT depend on CMOF).

    However, when I read the XMI 2.0 spec., it specifically provides
    mappings for features in CMOF that aren't in EMOF, so
    implementing/understanding EMOF is not enough to implement/understand
    XMI 2.0. There is no JMI 2.0 specification yet, but it seems likely that
    the case would be the same as with XMI 2.0. Therefore, it is not clear
    to me what the purpose of EMOF is. When is using EMOF more appropriate
    than using CMOF?

    Are there any examples of complete EMOF models? In particular, does
    anybody have the EMOF model defined as an instance of itself, as an XMI
    document? I could only find the EMOF model defined as an instance of
    CMOF. And finally, is it possible to represent the (merged) CMOF model
    as an instance of the EMOF model (useful for bootstrapping)?

    Finally, is there a well-defined mapping between EMOF and CMOF? That is,
    how can I convert an instance of the EMOF model to an instance of the
    CMOF model, and vice versa?

  • Reported: MOF2I 2.0b1 — Fri, 13 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 22:06 GMT

Abstract package

  • Key: MOF14-169
  • Legacy Issue Number: 4202
  • Status: closed  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    MOF-RTF issue: Abstract Package

    In MOF 1.3 there is a constraint which says that Package cannot have
    isAbstract attribute set to true.
    However, it does make sense to have abstract packages in MOF.
    One example of an abstract package could be a package containing some basic
    set of primitive datatypes which I would like to reuse in my models. There
    is no reason to instantiate this kind of package - the result of
    instantiation of this package would be nothing more than an empty package
    proxy object.

  • Reported: MOF 1.3 — Fri, 16 Feb 2001 05:00 GMT
  • Disposition: Duplicate or Merged — MOF 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:39 GMT

names of the factory create operations

  • Key: MOF2I2-41
  • Legacy Issue Number: 9161
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The names of the factory create operations for home interfaces in subsection 7.5.2.2 are not consistent with rules (35) and (36). Rules (35) and (36) state that the name of the factory create operations end with format_2 (<class identifier>).

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 18:08 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

Absence of definitions of "XMI" and "MOF"

  • Key: MOF24-58
  • Legacy Issue Number: 19198
  • Status: closed  
  • Source: cebe IT & KM ( Mr. Claude Baudoin)
  • Summary:

    The document, which is about a mapping of MOF to XMI, does not define the initialisms MOF or XMI anywhere in the documents, either in Chapter 1 (Scope) or in a glossary, which does not exist in this document.

    Chapter 1 starts with "XMI is a widely used interchange format..." and ends with "MOF is the foundation technology for describing metamodels..." but there is no mention of what the terms actually stand for, a significant omission in a formal document.

    One may also question the use of "MOF 2 XMI" in the title. While "MOF2XMI" may be a common way to create a meta-abbreviation for a relationship between two concepts denoted by abbreviations, there is little justification to eschew the grammatically correct "MOF-to-XMI Mapping" (with hyphens or spaces) in the document title. Using the numeral "2" is actually ambiguous – does it mean "to" or does it refer to a version 2 of MOF?

    Overall, this issue is more about casual editing than about correctness, but I believe it makes the specification weaker, editorially, than the usual OMG standard of documentation.

  • Reported: MOF 2.4.1 — Tue, 28 Jan 2014 05:00 GMT
  • Disposition: Resolved — MOF 2.4.2
  • Disposition Summary:

    Make the change as suggested

  • Updated: Fri, 6 Mar 2015 23:16 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

Annex A1

  • Legacy Issue Number: 11604
  • Status: closed  
  • Source: CrimsonLogic India Pvt. Ltd. ( M. Jayaprakash)
  • Summary:

    The sample input model diagram on page 26 (Annex A, Example 1 – RDBMS model to Oracle DDL) is inaccurate. The 'refersTo' relation from the Department_fky entity should point to the Department_pky entity and not to the Employee_pky entity. Also, the 'foreignKey' relation from the Employee entity should point towards the Department_fky entity and not as shown.

  • Reported: MOFM2T 1.0 — Fri, 12 Oct 2007 04:00 GMT
  • Disposition: Closed; No Change — MOFM2T 1.1
  • Disposition Summary:

    issue withdrawn by submitter, closed

  • Updated: Fri, 6 Mar 2015 22:56 GMT

Rule (11) and (12)

  • Key: MOF24-55
  • Legacy Issue Number: 7591
  • Status: closed  
  • Source: Humboldt-Universitaet ( Mario Winkler)
  • Summary:

    In my opinion it has to be stated in Rule (11) and (12) that getter and setter operations are only generated for non-derived attributes.

  • Reported: MOF 2.0 — Thu, 15 Jul 2004 04:00 GMT
  • Disposition: Resolved — MOF 2.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 22:55 GMT

MOF 1.3: are Associations contained in Packages or not?

  • Key: MOF14-168
  • Legacy Issue Number: 3527
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 3.3.4 of MOF 1.3 gives a table that shows allowed containments.
    According to this table, Associations cannot be contained in anything.

    Sections 5.2.1 and 5.2.2 give examples where an Association (A) is
    contained in a Package (P1).

    These seem inconsistent.

  • Reported: MOF 1.3 — Mon, 3 Apr 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    duplicate of issue 3131

  • Updated: Fri, 6 Mar 2015 21:38 GMT

No reflective all_links() operation

  • Key: MOF14-167
  • Legacy Issue Number: 2197
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There should be a RefAssociation operation corresponding
    to "specific" all_<association_name>_links() operations.

    Additional text:

    The following operation signature is proposed:

    LinkSet all_links();

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

RefAssociation::link_exists() signature inconsistent

  • Key: MOF14-166
  • Legacy Issue Number: 2196
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The link_exists() declaration in section 5.3.7 is incorrect.
    It should match the one in the appendix.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Error in "args" parameter of RefObject::invoke_operation.

  • Key: MOF14-165
  • Legacy Issue Number: 2195
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ValueTypeList argument should be an "inout" instead of
    an "in" parameter. Otherwise, a client cannot see values passed
    back using "out" or "inout" parameters in a specific operation.

    Additional text:

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Typos in Reflective::remove_value_at

  • Key: MOF14-164
  • Legacy Issue Number: 2194
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are typos in Section 5 and the Appendix in the IDL for
    the RefObject::remove_value_at() operation. (The second parameter name
    is "posotion" and the InvalidValue exception cannot be raised.)

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Exception to indicate no corresponding "specific" operation

  • Key: MOF14-161
  • Legacy Issue Number: 2191
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue 968 states that there is a need for a new exception
    called (say) "AbstractType" which is raised by create_instance() when
    it is invoked for an abstract Class. This exception would only be
    raised by the create_instance() operation when when there is no
    corresponding "specific" operation. There are many other operations
    in which this general condition can occur. Section 5.4.2, states that
    the CORBA system Exception NO_IMPLEMENT should be raised in the case
    where modify or delete operations are not available. This needs to be
    handled more consistently.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MissingParameter and TooManyParameters exceptions

  • Key: MOF14-160
  • Legacy Issue Number: 2190
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Neither MissingParameter nor TooManyParameters indicate the
    number of parameters that were expected. The designator member of the
    MissingParameter exception (i.e. the parameter that is really missing)
    cannot be reliably determined.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Document how to "unset" using the RefObject interface

  • Key: MOF14-163
  • Legacy Issue Number: 2193
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In cases where there "specific" interfaces unset operation,
    the unset operation can be called using the RefObject::set_value()
    operation, where the ValueType parameter of set_value() is a CORBA
    Any of kind tk_null. This needs to be stated in the spec.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

RefObject::value() needs to raise NotSet

  • Key: MOF14-162
  • Legacy Issue Number: 2192
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In cases with a multiplicity of [0..1], the NotSet exception
    can be thrown, so the value() method should be defined to raise the
    NotSet exception.

    Additional text:

    Proposed fix - redefine the value() to have the following signature.

    ValueType value (in DesignatorType feature)
    raises (InvalidDesignator,
    NotSet,
    SemanticError);

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Edit the MOF specification to improve clarity and readability

  • Key: MOF14-157
  • Legacy Issue Number: 2185
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: he entire specification is in need of revision to improve its
    readability, structure and technical consistency and clarity. This
    requires a lot of copy editting work for the RTF!

    Additional text:

    For example, the semantics section should be repartitioned into
    sections on `semantic constraints on the MOF Model meta-models",
    `structural semantics of models" and `operational semantics of
    mapped interfaces".

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Revise `container" operations on RefBaseObject

  • Key: MOF14-156
  • Legacy Issue Number: 2180
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We now need to have two operations on RefBaseObject to return
    the `composite" container and the `static" scope (i.e. the extent). The
    operation signatures should be similar, with distinctive names.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Reflective::InvalidDesignator exception

  • Key: MOF14-159
  • Legacy Issue Number: 2189
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL should contain constant declarations for the
    possible values of the "element_kind" field of the exception.
    Since more than one element kind might be expected in some cases
    (e.g. RefObject::set_value() applies to attributes AND references)
    perhaps, the field should be multi-valued.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Support for IDL prefixes in MOF spec

  • Key: MOF14-158
  • Legacy Issue Number: 2187
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When the MOF is used to generate meta-models for other
    OMG specifications, it is necessary to include a "#prefix "org.omg""
    in the generated IDL. The MOF Model and IDL mapping do not currently
    support this.

    Additional text:

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add support for Package Consolidation / Clustering

  • Key: MOF14-155
  • Legacy Issue Number: 2176
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Package Clustering is a new composition mechanism that is
    proposed as a way to deal with anomolies that can arise when one
    Package imports another.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Document different meaning of "abstract"

  • Key: MOF14-154
  • Legacy Issue Number: 2175
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF uses "abstract Class" in the same sense as UML, and
    also Java and other object oriented programming languages. However,
    defining a Class as "abstract" (as per the Object-by-Value extensions)
    does not make any statements about the way that subtype instances are
    transmitted; i.e. a MOF abstract Class does not correspond to a CORBA
    2.3 IDL "abstract interface".

    Additional text:

    The MOF spec should note the different meanings of "abstract" both
    in the Model chapter and in the Glossary.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Update specification to track OCL syntax changes

  • Key: MOF14-153
  • Legacy Issue Number: 2172
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF specification currently uses a version of the OCL that
    predates the final UML submission. It is understood that the OCL syntax
    was changed in the final UML submission. The MOF spec should be updated
    if necessary to track these changes.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MOF names implicitly tied to implementation

  • Key: MOF14-152
  • Legacy Issue Number: 2025
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The relationship between MOF names and
    generated interfaces places implicit restrictions on
    valid MOF names. For example, IDL keywords and namespaces
    may conflict with otherwise valid MOF names. MOF should allow
    flexibility in the generation rules for IDL, C++, Java, etc.
    to prevent restrictions from these externals reducing the
    set of valid MOF names. In UML, names such as "Class" and
    AssociationClass cause conflicts when IDL is generated.
    Namespaces in MOF metamodels may be useful when generating
    IDL to prevent name collisions between constructs in different
    MOF spaces.

  • Reported: MOF 1.2 — Wed, 30 Sep 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MOF RTF Issue: SMIF version of MOF

  • Key: MOF14-151
  • Legacy Issue Number: 1998
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: MOF RTF Issue: SMIF version of MOF
    Severity: Critical

    1) The MOF RTF must produce a normative representation in Rose (or equivalent)
    and SMIF form in the event that a SMIF submission is adopted.
    2) In the event that XMI is adopted as the SMIF technology, the normative XMI
    form of MOF is a generated XMI document and DTD.

  • Reported: MOF 1.2 — Tue, 29 Sep 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

New name clash issue from CORBA 2.3 spec

  • Key: MOF14-150
  • Legacy Issue Number: 1900
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The ORB revision task force is proposing a change to the
    CORBA IDL spec that forbids the redefinition of an identifier in
    the immediate scope of an interface or module. This impacts on
    MOF IDL generation.

  • Reported: MOF 1.2 — Mon, 31 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Atomicity of updates

  • Key: MOF14-149
  • Legacy Issue Number: 1803
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I don"t think that the MOF spec currently spells out the
    requirements (and non-requirements) for atomicity of update operations.
    I think it should.

  • Reported: MOF 1.2 — Thu, 13 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

exceptions for resolve_qualified_name()

  • Key: MOF14-148
  • Legacy Issue Number: 1779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I think we should reconsider the exception(s) raised by
    NameSpace::resolve_qualified_name(). Firstly, it is not necessary
    to return the resolved part and the name that gave problems as two
    parameters. Secondly, the exception does not cover the case where
    one of the ModelElements on the path was not a Namespace.

  • Reported: MOF 1.2 — Thu, 6 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need to specify when are side-effects allowed

  • Key: MOF14-147
  • Legacy Issue Number: 1778
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF was designed under the assumption that ordinary
    (i.e. non-derived) M1-level attribute values and links only change
    when the client expects them to. Unfortunately, the spec
    does not address this issue. In particular, it does not say
    what mapped IDL operations are allowed to change things by
    side-effect.

  • Reported: MOF 1.2 — Thu, 6 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MOF Constraints are pure predicates

  • Key: MOF14-146
  • Legacy Issue Number: 1775
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Modify the description of MOF Constraint in section 3 to make it
    clear that MOF Constraints should be interpreted as pure predicates
    that specify a "validity" condition on a collection of meta-objects
    They do not in any way require or allow modification of the default
    behavioral semantics of a server. Evaluation of constraints must
    be side-effect free.

  • Reported: MOF 1.2 — Wed, 5 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

MofAttribute values do not have aggregation==composite semantics

  • Key: MOF14-145
  • Legacy Issue Number: 1770
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The spec should make it clear that the values of a MofAttribute are NOT
    intended to have aggregation semantics. For example, an instance of a
    Class should be allowed to refer to itself as an attribute, or to share
    an (object) attribute with other instances. This applies to MofAttributes
    whose type is a Class or a DataType (where its typecode is any kind of
    object reference type).

  • Reported: MOF 1.2 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Cardinality of "RefersTo" and "Exposes" associations

  • Key: MOF14-144
  • Legacy Issue Number: 1749
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The cardinalities of the "referent" end of "RefersTo" and the
    "referrer" end of "Exposes" are both specified as [0..1] throughout the
    MOF specification. This means that a given AssociationEnd can be
    navigable from >>at most<< one Class (and its subclasses). I can"t
    think of a good reason for making this restriction, and I can"t recall
    it being discussed. The UML spec (ad/97-08-09) contains a diagram (figure
    5 on page 7) that purports to be a projection of the MOF model. This shows
    the cardinality of "referent" as [0..*]. If nothing else, there is a
    document alignment issue here.

  • Reported: MOF 1.2 — Wed, 29 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Multiplicities on Attributes and References modelled incorrectly

  • Key: MOF14-143
  • Legacy Issue Number: 1716
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current Model defines a "multiplicity" attribute on StructuralFeature
    which is then inherited by MofAttribute and Reference. There is also
    a Constraint that says that the multiplicity of a Reference must be
    the same as the multiplicity of the corresponding AssociationEnd.
    This modeling is incorrect, as it makes it duplicates information.
    In particular, the ReferenceClass::create_reference() operation requires
    an extra multiplicity parameter.

    What is really going here is that the multiplicity of a Reference is
    implied by the multiplicity of the corresponding AssociationEnd.

  • Reported: MOF 1.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    duplicate iswue....closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Navigability constraint expressed wrongly

  • Key: MOF14-142
  • Legacy Issue Number: 1715
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "is_navigable" attribute on AssociationEnd is intended to allow
    a modeler to prevent the creation of References for the end. Unfortunately
    the Constraint that expresses this is on the AssociationEnd and the
    "is_navigable" attribute rather than on Reference. This means that
    the existence of References constrains the value of "is_navigable"
    rather than the other way around.

  • Reported: MOF 1.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, no action required

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Navigability constraint expressed wrongly

  • Key: MOF14-140
  • Legacy Issue Number: 1712
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The "is_navigable" attribute on AssociationEnd is intended to allow
    a modeler to prevent the creation of References for the end. Unfortunately
    the Constraint that expresses this is on the AssociationEnd and the
    "is_navigable" attribute rather than on Reference. This means that
    the existence of References constrains the value of "is_navigable"
    rather than the other way around.

  • Reported: MOF 1.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Multiplicities on Attributes and References modelled incorrectly

  • Key: MOF14-139
  • Legacy Issue Number: 1711
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current Model defines a "multiplicity" attribute on StructuralFeature
    which is then inherited by MofAttribute and Reference. There is also
    a Constraint that says that the multiplicity of a Reference must be
    the same as the multiplicity of the corresponding AssociationEnd.
    This modeling is incorrect, as it makes it duplicates information.
    In particular, the ReferenceClass::create_reference() operation requires
    an extra multiplicity parameter.

  • Reported: MOF 1.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Inconsistent multiplicity for TypeAlias

  • Key: MOF14-141
  • Legacy Issue Number: 1714
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The section 3 definition for TypeAlias defines its "multiplicity"
    attribute as having exactly one value. The appendices (ammended
    by the addenda) show the "multiplicity" attribute as optional.
    I think that the section 3 gives the correct definition in this
    case.

  • Reported: MOF 1.2 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Convenient way to discriminate instances of subclasses

  • Key: MOF14-138
  • Legacy Issue Number: 1683
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Reflective layer needs to provide an easy, universal
    way to identify the "most derived" class of a meta-object. At the
    moment, an application needs to make a sequence of "narrow" calls.
    In some situations, this is unavoidably network intensive.

  • Reported: MOF 1.2 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Should set_(nil) be legal?

  • Key: MOF14-137
  • Legacy Issue Number: 1518
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This relates to the previous issue. Should it be legal to
    call a set_<referencename>(in <ReferenceType> new_value> operation
    (see 7.3.8) with a nil object reference as the new_value?

  • Reported: MOF 1.2 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

set_ needs StructuralError

  • Key: MOF14-136
  • Legacy Issue Number: 1517
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The set_<referencename> defined in the Reference Template
    (7.3.8) needs to be changed to allow StructuralError to be raised
    in some cases where upper = 1.

  • Reported: MOF 1.2 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Exception for creating instances of imported supertypes?

  • Key: MOF14-134
  • Legacy Issue Number: 1513
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: What exception should Reflective::RefObject::create_instance()
    raise if it is unable to create an instance of a supertype where the
    supertype is imported from another Package?

  • Reported: MOF 1.2 — Tue, 9 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Description of with_ operations

  • Key: MOF14-135
  • Legacy Issue Number: 1516
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of the with_<associationname> operations
    in the IDL mapping needs to give more details of the results returned.

  • Reported: MOF 1.2 — Wed, 10 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

MOF RTF Issue: Behavior of M1 level interfaces vagualy specified

  • Key: MOF14-133
  • Legacy Issue Number: 1502
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current MOF spec is too vague in its specification
    of the behavior of the M1-level interfaces, both in the Reflective
    and IDL mapping sections. It is also rather disorganised with the
    text structure of Sections 5 through 7 reflecting authorship rather
    than relatedness of content. If left uncorrected, these problems
    are likely to lead to divergent implementations and interoperability
    problems.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

MOF RTF Issue: aggregations crossing M1 and M2 package boundary

  • Key: MOF14-132
  • Legacy Issue Number: 1501
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current MOF spec allows Associations to be defined such
    that a Class in one Package to be "composed of" a Class in another
    Package. Similar "compositions" at the M1 level; i.e. can occur
    across "package object" boundaries. We propose to restrict such
    compositions since we believe that they make implementation of
    object life-cycle operations problematical in a federated environment.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Naming of Tags

  • Key: MOF14-129
  • Legacy Issue Number: 1497
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Model allows Tags to be attached to any model element.
    This provides a mechanism for extending the MOF Model with extra
    meta-meta-information that (for example) could pertain to model server
    code generation. Tags are currently unrestricted name value pairs.
    However, in order to ensure interoperability of Tags, there needs to
    be agreement on their "meaning". The first step to ensuring this is
    to define conventions for Tag names. These should allow tag names
    that 1) apply to all kinds of meta-model, 2) are defined for specific
    families of meta-models (e.g. when the MOF Model is re-used in another
    OMG spec), 3) are defined by a vendors product line, or 4) are defined
    by the end user.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Identifier formating error in MOF generates IDL

  • Key: MOF14-128
  • Legacy Issue Number: 1496
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL identifiers for the all_*_links attributes in the
    association interfaces were incorrectly generated. For example, in
    the interface Model::Generalizes, the attribute all_Generalizes_links
    should be all_generalizes_links. The error applies to all Association
    IDL, and appears both in the main text (chapter 3) and the appendices.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    close issue, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

MOF RTF Issue: M1 life-cycle operations

  • Key: MOF14-131
  • Legacy Issue Number: 1500
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current MOF spec has no support for object life-cycle
    operations at the M1 level; i.e. in the interfaces generated by the
    IDL mapping. While this can "fixed" by vendor specific extensions,
    this raises interoperability problems. As an alternative, I propose
    that we amend the spec to provide a standard solution.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

MOF RTF Issue: Library of collection types?

  • Key: MOF14-130
  • Legacy Issue Number: 1498
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF IDL mapping requires typedefs to be defined
    for Attributes, Operations and Associations, depending on the
    multiplicity settings. The current mapping specifies that the
    typedefs required are inserted into the generated IDL. In the
    case of multiplicities of the CORBA base data types, the typedefs
    are inserted at the start of the module for the outermost package
    (see 7.3.1). The proposal is that instead of this, the typedefs
    should be defined in a separate standard module; e.g. Reflective
    or a new one.

  • Reported: MOF 1.2 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, issue closed

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDL generation Association Template Syntax

  • Key: MOF14-127
  • Legacy Issue Number: 1308
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.3.5, p. 7-15. Association Template syntax errors:

    • Following declaration is missing terminating ";"
    • // if associationend1 has max multiplicity > 1
    • <AssociationEnd1Type><CollectionKind> with_
      <associationend2_name> (in <AssociationEnd2Type> <associationend2_name>
      )
    • Following declaration fragment missing underscore after
      "add_before":
    • // if associationend1 has a max multiplicity of > 1 and
      is_ordered
    • void add_before <associationend1_name> (
  • Reported: MOF 1.2 — Tue, 5 May 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDL Mapping/Identifier Naming

  • Key: MOF14-126
  • Legacy Issue Number: 1307
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.2.1, ppf 7-2. There is a section on name mangling which
    describes how a MOF name is mapped to an IDL name. The mapping
    definition provided has the following problems:

    • There can be any number of MOF names which map to a single
      identifier in IDL. A legal configuration of names in a MOF namespace
      may result in name conflicts when mapped to IDL. Section 7.4, p 7-33
      states that the "IDL mapping may not produce valid CORBA IDL if
      ...preconditions on the input model is not satisfied:... the names
      within a NameSpace must be unique after application of the Format1 and
      Format2 name rewriting algorithms."
    • The name mangling is not based on any standard, but rather
      "stylistic conventions".
    • It is unnatural for a user to see different names in his MOF/UML
      model than in the corresponding IDL.
    • The IDL for MOF does not even follow the guidelines (see format
      for constants, ppf A-2, format for exceptions throughout document)
    • Some forms of identifier are not covered, such as enumeration
      value, structs, unions, discriminators.
    • Will need to add arcane mangling rules for object by value and
      other OMG specifications which extend IDL.
  • Reported: MOF 1.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

IDL generation - IMPORT TEMPLATE clarification

  • Key: MOF14-125
  • Legacy Issue Number: 1306
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.3.1, Page 7-8. and Section 7.3.14, page 7-32. The Package
    Template includes two references to "IMPORT TEMPLATE", each with a
    different semantic/IDL expansion. For clarity, the two usages of
    IMPORT TEMPLATE should be distinguished, have separate names, and
    separate descriptions.

  • Reported: MOF 1.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Illegal IDL redefinitions

  • Key: MOF14-124
  • Legacy Issue Number: 1305
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: * Package Template attribute "enclosing_package_ref", if packages
    are nested. (Section 7.3.1, page 7-8)

    • Type Template attribute "enclosing_package_ref", for any
      subtype. (Section 7.3.4, page 7-12).
  • Reported: MOF 1.2 — Mon, 4 May 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Incorrect ocl specification(s)

  • Key: MOF14-123
  • Legacy Issue Number: 1141
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Incorrect ocl specification of
    Each ocl statement defining a constraint on the element
    types allowed to be contained by subtypes of Namespace is
    mis-specified. For instance, the following statement
    intended to constrain DataType instances to only
    containing instances of either TypeAlias or Tag. However,
    as specified, the intersection of sets is between
    instances (contents) and types (the defined set).

  • Reported: MOF 1.2 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Consider a better approach to generated exceptions

  • Key: MOF14-122
  • Legacy Issue Number: 1085
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Thought should be given to revamping the Exceptions
    generated in MOF"s IDL generation. Here are the
    issues/forces:

    The MOF has made a distinction between some constraints,
    which have been promoted to model features – like
    multiplicity constraints, isRoot, isLeaf, etc. – and the
    constraints defined by Constraint type. In the future,
    other constraints, such as ranges on attributes, may be
    likewise promoted. Yet in implementation, constraints can
    be handled uniformly. Having to generate different
    exceptions, based on these distinctions, makes
    implementation less streamlined.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, close issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Single-valued parameters should not be defined with sequences

  • Key: MOF14-121
  • Legacy Issue Number: 1084
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: If attributes with a datatype as their type are constrained
    in the Model to disallow the cardinality of [0..1], as
    recommended in a separate issue, then the handling of
    parameters with cardinality defined as [0..1] can be
    simplified, as compared to the recommendation in issue #940.

    This constraint allows parameters with cardinality to be
    treated as optional, single-valued parameters, instead of as
    sets. The difference for clients and implementations is
    significant.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Operations should return nil reference instead of raising NotSet

  • Key: MOF14-120
  • Legacy Issue Number: 1083
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently, the Attribute Template and Reference Template of
    the Section on IDL mapping require the Exception NotSet to
    be returned in response to the invocation of the "read"
    operation generated for attributes and references with a
    cardinality of [0..1]. Since the lower bound is zero,
    having the attribute or reference "not set" is a normal
    occurrence.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ConstraintError exception needed in more IDL generation templates

  • Key: MOF14-119
  • Legacy Issue Number: 1081
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7 underspecifies the use of ConstraintError in the
    raises clause of generated operations. It is only specified
    in the Type Create Template. However, it should be
    specified as part of the Package Create Template, the
    Association Template, the Attribute Template, the Reference
    Template, and the Operation Template. Its appearance
    depends on the constrained elements of constraint objects
    in the source model of IDL generation.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

ConstrainViolation vs. ConstraintError confusion (editorial)

  • Key: MOF14-118
  • Legacy Issue Number: 1080
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Paragraph 5.3.3 calls ConstraintViolation an exception,
    although it is a structure. Also, paragraph 7.3.5 shows the
    Type Create template as potentially generating an operation
    which raises a Reflective::ConstraintViolation, but since
    it is a struct, this would generate illegal code.
    References to ConstraintViolation as an exception should
    instead refer to the exception "wrapper", ConstraintError.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Association IDL generation needs to consider AssociationEnd.isChangeable

  • Key: MOF14-117
  • Legacy Issue Number: 1079
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Association Template for IDL generation should consider
    the isChangeable attribute value of the AssociationEnd
    objects. For instance, the derived Association DependsOn
    should have no generated operations which could change the
    links. Adding a dependency through the association makes no
    sense. Since both association ends of that association are
    defined with isChangeable=false, the IDL generation rules
    should provide only query capabilities for that association.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Generated location parameters need clear specification of base value

  • Key: MOF14-114
  • Legacy Issue Number: 1076
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For the Reflective interface operations requiring a
    positional parameter (add_value_at, modify_value_at,
    remove_value_at), the base (the lowest legal value) is never
    specified. CORBA 2.1 does not either; Section 3.8.4 states:
    "The implementation of array indices is language mapping
    specific"

    The MOF Standard should state the index base (presumably
    either 0 or 1). It should not be left as a
    language-specific issue, since languages differ (C++ and
    java arrays are zero-based; Smalltalk collections are
    one-based).

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Type of Facility.MofRepository.packageFactory incompatible with its purpos

  • Key: MOF14-113
  • Legacy Issue Number: 1075
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Facility.MofRepository.packageFactory is of type
    Reflective.RefPackage. Its purpose is to provide the object
    needed to instantiate a ModelPackage – the set of
    class-proxy and package-proxy objects needed to create and
    manage Mof models. It is expected to return a an object of
    type Model.ModelPackageFactory. However,
    Model.ModelPackageFactory does not derive from
    Reflective.RefPackage. So this attribute cannot provide its
    described capability.

    Suggest changing the type of this attribute to
    Model.ModelPackageFactory. The MofRepository package is
    specific to the Mof, and does not require defining this
    factory object in any generic manner.

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Deferred — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Association interface generation templates require exceptions

  • Key: MOF14-116
  • Legacy Issue Number: 1078
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For IDL generation, the Association Template needs
    exceptions in the raises clause of some operations. Compare
    to the generic equivalent, RefAssociation. For instance,
    what if a null is passed in for a query or update?

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Description of meta-model as a single package is incorrect

  • Key: MOF14-115
  • Legacy Issue Number: 1077
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 6.3, Rules of ModelElement Containment, states that
    a "metamodel is defined by a Package object...". In The
    section on Repository naming "Element, Model, and Repository
    Naming" the text states: "A metamodel name is the name of
    its top-level Package..." In other places I believe the
    document also either states or implies that a Model is
    defined by a single package (and its contents).

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    nothing to do...close issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Editorial; change MOF Type to MOF Class

  • Key: MOF14-112
  • Legacy Issue Number: 969
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are many examples in the later sections of the spec (5 onwards)
    where the MOF Model element "Class" is refered to by its old name of "Type".
    There needs to be a systematic scan of the spec to find and correct all
    occurences of this mistake.

  • Reported: MOF 1.2 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved, to be implemented

  • Updated: Fri, 6 Mar 2015 21:34 GMT

RefObject::create_instance and abstract types

  • Key: MOF14-111
  • Legacy Issue Number: 968
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue relates to the Reflective interfaces. The create_instance
    on Reflective::RefObject (5.2.2) is the generic "factory" for instances of
    types. The operation description states that an exception is raised if
    it is invoked for an abstract Class. However, it doesn"t state which
    exception this should be. This needs to be fixed.

  • Reported: MOF 1.2 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:34 GMT

MOF IDL Mapping with parameters

  • Key: MOF14-110
  • Legacy Issue Number: 967
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Specification defines the Operation Template
    > such that each parameter is defined by its name and
    > type. This mapping ignores a parameter"s multiplicity
    > attribute. I believe the mapping should define the
    > parameter"s type corresponding to the multiplicity,
    > which is what the mapping already does for the
    > operation"s result parameter.

  • Reported: MOF 1.2 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    This is a duplicate of Issue #965.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

MOF IDL /MODL - Type Hierarchy error

  • Key: MOF14-109
  • Legacy Issue Number: 966
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: While the MOF Spec text and diagrams define an AssociationEnd
    as derived from TypedElement, The IDL and MODL define it as
    derived from ModelElement.

    Clearly it must be derived from TypedElement.

  • Reported: MOF 1.2 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    This is a duplicate of Issue #949.

  • Updated: Fri, 6 Mar 2015 21:34 GMT

MOF IDL mapping-types of parameters with multiplicities

  • Key: MOF14-108
  • Legacy Issue Number: 965
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Specification defines the Operation Template
    such that each parameter is defined by its name and
    type. This mapping ignores a parameter"s multiplicity
    attribute. I believe the mapping should define the
    parameter"s type corresponding to the multiplicity,
    which is what the mapping already does for the
    operation"s result parameter.

  • Reported: MOF 1.2 — Wed, 18 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:34 GMT

IDL Mapping--#includes for inheritted Packages

  • Key: MOF14-107
  • Legacy Issue Number: 957
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When one MOF Package is declared as inheriting from another Package, the
    IDL for the former needs a #include statement to access the interfaces
    of the latter. This is currently not mentioned in the mapping rules,
    but without it IDL does not compile.

  • Reported: MOF 1.2 — Tue, 10 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Type Hierarchy Error in IDL

  • Key: MOF14-106
  • Legacy Issue Number: 949
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: While the MOF Spec text and diagrams define an AssociationEnd
    as derived from TypedElement, The IDL and MODL define it as
    derived from ModelElement.

  • Reported: MOF 1.2 — Mon, 16 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

MOF-IDL needs to be re-generated

  • Key: MOF14-105
  • Legacy Issue Number: 948
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It will be necessary to re-generate the MOF IDL. Fortunately,
    > since the MOF Model is relatively simple, most of the changes
    > will have low impact; e.g. added exceptions and changed
    > parameter names. The bag attribute of Tag is the only
    > non-derived
    > attribute with multiplicity other than [1..1], and its type
    > is incorrect.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Type Create template, order of parameters

  • Key: MOF14-104
  • Legacy Issue Number: 947
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the text describing Type Create template, the order of the
    > parameters should be defined as a depth-first traversal of
    > the supertypes, followed by the contained Attributes [in
    > containment order naturally ...]

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue, resolved

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Similar to issue 940

  • Key: MOF14-101
  • Legacy Issue Number: 944
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Similar to 1) for the Type Create template.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

package create template: names of parameters need to be formated

  • Key: MOF14-100
  • Legacy Issue Number: 943
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Package Create template, the names of the parameters
    > need to be formed by concatenating the format2 names for the
    > attribute and its enclosing scopes. For example:
    >
    > "package1_type2_attribute3"
    >
    > This name mangling is necessary to avoid name collision when
    > there are two or more classifier level attributes with the
    > same name.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Similar o issue 941

  • Key: MOF14-103
  • Legacy Issue Number: 946
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 6) Similar to 2941 for the Type Create template.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

${issue.summary}

  • Key: MOF14-102
  • Legacy Issue Number: 945
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

package create template: ConstraintError

  • Key: MOF14-99
  • Legacy Issue Number: 942
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Package Create template, if any of the Attributes or
    > their types are constrained, then the raises clause should
    > include ConstraintError.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    rsolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package create template: StructuralError needs to be raised

  • Key: MOF14-98
  • Legacy Issue Number: 941
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Package Create template, the operation needs to raise
    > StructuralError if any of the attribute parameters has a
    > collection type.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    ressolved, close issue

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Package create template

  • Key: MOF14-97
  • Legacy Issue Number: 940
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the Package Create template, the type of any parameter
    > corresponding to an attribute with mult.lower != 0 or
    > mult.upper != 0 needs to be the appropriate collection type.

  • Reported: MOF 1.2 — Tue, 17 Feb 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Typos in MOF 1.1 document (1)

  • Key: MOF14-94
  • Legacy Issue Number: 786
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 3-6: in AssociationEnd AggregationKind should be AggregationType

  • Reported: MOF 1.2 — Wed, 26 Nov 1997 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, already implemented

  • Updated: Fri, 6 Mar 2015 21:34 GMT

IDL Generation Issue - factory operation parameters for multivalued attrib

  • Key: MOF14-93
  • Legacy Issue Number: 785
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Multivalued, read-only attributes can never be given more than a single value

  • Reported: MOF 1.2 — Tue, 2 Dec 1997 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    resolved and closed

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Typos in MOF 1.1 document (3)

  • Key: MOF14-96
  • Legacy Issue Number: 788
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 3-8: in Parameter DirectionKind should be DirectionType

  • Reported: MOF 1.2 — Wed, 26 Nov 1997 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    close - already implemented

  • Updated: Fri, 6 Mar 2015 21:34 GMT

Typos in MOF 1.1 document (2)

  • Key: MOF14-95
  • Legacy Issue Number: 787
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Figure 3-8: in Constraint EvaluationKind should be EvaluationType

  • Reported: MOF 1.2 — Wed, 26 Nov 1997 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    close, already implemented

  • Updated: Fri, 6 Mar 2015 21:34 GMT

External Types as DataTypes Limits Modeling

  • Key: MOF14-92
  • Legacy Issue Number: 784
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Because typedefs and external types are represented as instances of DataType, it is not possible to inherit from, or define an association with, an external type, such as CORBA::InterfaceDef

  • Reported: MOF 1.2 — Wed, 3 Dec 1997 05:00 GMT
  • Disposition: Resolved — MOF 1.3
  • Disposition Summary:

    closed, to be implemented

  • Updated: Fri, 6 Mar 2015 21:34 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

Is the multiplicity of Model::Tag::values correct?

  • Key: MOF14-87
  • Legacy Issue Number: 2465
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A Tag has an attribute called "values" with type "any" and multiplicity
    of [0..*] / ordered == false / unique == false. On thinking about this
    (while specifying some Tags for the IDL mapping), I"ve concluded that
    the multiplicity is probably wrong. It would be better if it was either
    [1..1] or [0..*] / ordered == true / unique == false.

  • Reported: MOF 1.2 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see below

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

Reflective typos

  • Key: MOF14-86
  • Legacy Issue Number: 2210
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Two minor typos. First, the title for section 5.3.5 should
    read "Reflective::RefBaseObject" not "Reflective::RefObject". Second,
    in 5.3.6, the IDL for the "remove_value_at" operation should not have
    an "existing_value" argument. [The IDL in the appendix is correct, as
    are the templates for the "specific" equivalents.]

  • Reported: MOF 1.2 — Fri, 13 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Close with no further action. These typos were fixed in MOF 1.3.

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

Data types available to metamodels is restricted

  • Key: MOF14-84
  • Legacy Issue Number: 2198
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Data types available to metamodels is restricted.

    Additional text: Metamodels need to define and support a variety of datatypes
    beyond what is available though typecodes. This will be essential for the CWM
    submissions. Suggested solution: allow metamodels for data types.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Missing exception for all_*_links operation

  • Key: MOF14-91
  • Legacy Issue Number: 2882
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Association template in 5.8.10 of MOF 1.3 states that the
    all_<association_name>_links() operation should raise MofError.
    The corresponding operations in the IDL for the MOF Model does not
    raise the exception, either in chapter 3 or the IDL appendix.

  • Reported: MOF 1.2 — Wed, 8 Sep 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Constraints on Associations.

  • Key: MOF14-90
  • Legacy Issue Number: 2881
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL mapping template for Associations in 5.8.10 of MOF 1.3
    does not produce constraint string declarations for Constraints
    contained by Associations.

  • Reported: MOF 1.2 — Wed, 8 Sep 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Section 5-54 of Meta Object Facility (MOF) Specification

  • Key: MOF14-89
  • Legacy Issue Number: 2877
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Class Proxy template specifies that the types of
    all_of_type_<class_name> and all_of_class_<class_name> are to
    be <ClassName>Set. Yet Section B the MOF interfaces are defined to use
    <ClassName>UList for the types of all_of_type and all_of_class.
    Which return type is correct?

  • Reported: MOF 1.2 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    No Data Available

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

MOF is using CORBA string for its string data types

  • Key: MOF14-88
  • Legacy Issue Number: 2495
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: MOF is using CORBA string for its string data types. It should use a wide string. UNICODE is needed to support widespread interoperability.

  • Reported: MOF 1.2 — Mon, 1 Mar 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    close with no further action

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

Specify behaviour of RefObject.is_instance_of(null,...)

  • Key: MOF14-85
  • Legacy Issue Number: 2205
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear what should happen if "is_instance_of" is
    invoked with a null "obj_type" argument. Should it return false?
    Should it raise the CORBA BAD_PARAM system exception? Should it
    raise Reflective::InvalidDesignator? [In the latter case, the
    exception should be added to the operation signature.]

  • Reported: MOF 1.2 — Thu, 12 Nov 1998 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see below

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

Wrong concrete syntax (in EBNF)

  • Legacy Issue Number: 19668
  • Status: open  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The concrete syntax as expressed in this chapter is full of errors

    1) It is a pity that it is not using the same EBNF idiom as other OMG specifications that were written before (e.g. IDL)

    2) It is a pity that the idiom selected is not consistantly applied (e.g. [...] or (...)? to describe an option - both are used sometimes even in the same rule)

    3) there are many literals that are missing their enclosing <> (e.g. extend_decl instead of <extend_decl>)

    4) there are some missing text separators (' here)

    5) and some typos such as Expession instead of Expression

    6) many (11) missing definitions

    7) the formatting of the whole section is weird, all in courier font, weird spacing... (a raw cut and paste?)

  • Reported: MOFM2T 1.0 — Fri, 28 Nov 2014 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Useful only as a proof of concept, hard to maintain for big projects

  • Legacy Issue Number: 18994
  • Status: open  
  • Source: Rila ( Rusi Popov)
  • Summary:

    Dear colleagues,

    I have more than 13 years experience in MDD, MDA and code generation. Specifically the solution I built and use since more than 12 years is based on MOF 1.3/1.4, UML 1.3, XMI 1.1/1.2 using the NetBeans MetaData Repository as the only free and working standard implementation and able to be integrated with other tools.

    The problem: My experience shows that a code generation (M2T) framework should:

    • provide powerful text parsing and formatting features.
      For example: page 4 shows an example to generate a Java class with some attributes, just putting their names in the output. In practice:
      • the names of the classes and attributes rarely would be formatted as of the Java naming conventions (and in PIM they should not obey them)
      • the common java conventions state that for each attribute set/get methods might be generated in the format: get<attribute name with first capital letter> (OK, the toUpperFirst() function could help here)
      • the common Database conventions map the class attributes to fields where the separate words in the attribute name are all in upper case and separated by '_' i.e. the testAttribute is mapped to TEST_ATTRIBUTE column in the DB. The same is for class names and table names. Does M2T allow easily implementing this feature and easily maintaining it, considering the fact that in a real project it will be used many hundreds of times? I do not see features to create common functions / methods (other than macro with no result)
    • the structure of the models or metamodels to traverse is complex in MOF 1.4 & UML 1.3, it is incredibly more complex in MOF 2+ UML 2+. In such situations the procedural approach becomes complex and hard to maintain. In addition those structures are object-oriented i.e. use inheritance and polymorphic behaviour. Thus, the object-oriented approach to creating the template language would be more-appropriate to support object-oriented structures matching the structure of the metamodel.
    • the template language should allow extracting common logic / procedures (macros) and functions outside the templates and sharing the same logic in many templates. The best place would be a structure of classes, corresponding to the metamodel to process.
    • the template language should allow using control structures outside the templates themselves and initiate/apply them on model objects or results of queries on the model (i.e. collections of objects).
    • it seems to me that a more imperative approach to applying the templates than just using the types of the templates parameters would be easier to understand and maintain. Again, in a real case there are tens of templates nesting in each other, so maintaining implicitly their dependencies might be a real obstacle.
    • honestly, I think that it is too easy to implement some logic in an M2T template and then copy it hundred of times, which would make the support a real nightmare.

    About the normative example on page 27-:

    • the sample model to generate the DB description shows the primary and foreign keys as separate instances:
      • this is obviously a PSM, but the real benefits of MDA are gained when starting from PIM (there are no PK and FKs) and the generation of the intermediate PSM is a really rare practice. Many tools use the PIM and generate the code, scripts, DB schemas, deployment descriptors, etc. out of it. This both imposes more requirements on the M2T features (as of above) and just narrows the area of M2T application in its current state.
      • the example is deceptive, because it assumes that the class and attribute names will be the same as the table and field names. In real practice (see above) there are different naming conventions and in addition some DBs (like Oracle) impose maximum name length restrictions. In a complex model there may be overlapping names of FK constraints, sequence names, field names when reducing / abbreviating them from the human-readable PIM.
      • example 3 on page 30 demonstrates the weaknesses in the generation of the set/get method names - try the Java code conventions.
      • example 1 and 3 are deceptive because they just generate attributes, but do not show the complexity of associations support methods - try the generation of associations support methods for the cases of uni-directional and bi-directional associations in 1:1, 1:M and M:N multiplicity (not mentioning their composition and aggregation kinds). In the real case example I am working with there are 8 templates to generate such.
  • Reported: MOFM2T 1.0 — Tue, 8 Oct 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide a way for users to get the iteration count in a for loop

  • Key: MOFM2T11-9
  • Legacy Issue Number: 14557
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MTL Currently specifies a "for-each" kind of loop, with no possibility for the user to know the index of the current iteration in the list of values they're iterating over.

    It would be nice to have access to an implicit variable within for loops to get this index. Something like

    [for (value : String | Sequence

    {'a', 'b', 'c'}

    )/]
    [i/] = [value/]
    [/for]

    would then generate text :

    1 = a
    2 = b
    3 = c

    I named this implicit variable "i" in this example, it could be named "iterationCount" or "iterationIndex" if we want to avoid conflicts... Yet I'd rather it be named "i" myself.

  • Reported: MOFM2T 1.0 — Tue, 13 Oct 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Example ambiguity

  • Key: MOFM2T11-8
  • Legacy Issue Number: 14438
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    Section 8.1.5 describes initSections and tells us that

    ---------8<---------
    An InitSection contains a set of variable initializations to be used in the body of its owning block.
    --------->8---------

    Yet example A.3 sports something like this :

    ---------8<---------
    [template public class_header(c : Class)

    { int count = -1; }

    ]
    [...]
    [for(a : Attribute) | c.attribute)

    { count = count + 1; }

    ]
    #define [a.name/]_BIT [count/]
    [/for]
    --------->8---------

    First of all, "int count = 1" is syntactically wrong and should be "count : Integer = -1"; but I've raised this in a separate issue not accepted yet so I don't have its number). The real problem here is that this example initializes a variable "count" in the template's init section, then tries to -modify this variable in the init section of a for.

    That just cannot be with the specification as it is now : the second init section should be "count : Integer = count +1" to be syntactically correct, and this doesn't mean "increment the value of 'count'" but "create variable 'count' with value 'count + 1' so we actually create a second variable that hides the first. Furthermore, as this second variable is declared on a for, and initSection's variables are only meant to be useable in the 'for' body, this second "count" variable will only last for an iteration. This means that every iteration, we create a new variable 'count' of value '0' (since the first 'count' variable is '-1').

    There is nothing in MOFM2T that's been specified as something that allows for the modification of a variable. We can only initialize them. Modifying variables requires the introduction of a non-generating block. Side-effect free blocks where we could do things without generating text.

    The next version should revise the A.3 example so as not to be misleading about the signification of InitSections. It should also introduce a new block dedicated to logic.

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistency in metamodel Message

  • Legacy Issue Number: 12186
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Title: Inconsistency in metamodel Message: The Mof2Text metamodel cannot attach static text to a body section. --------- ---------------------- | Block | 1 ---------> 0..* | TemplateExpression | --------- body ---------------------- --------- ---------------------- ----------------- | Block | -------|> | TemplateExpression | --------|> | OclExpression | --------- ---------------------- ----------------- The problem can be reproduced with the following example (extracted from Example 1. Page 25): [template public TableToDDL(t: Table)] CREATE TABLE [t.name/] ( [for (c:Column|t.column) separator(',')] [c.name/] [c.type/] [/for] ); [KeyToDDL(t.key)/] [ForeignKeyToDDL(t.foreignKey)/] [/template] The template body contains a ForBlock, a TemplateExpression ([t.name/]) and two TemplateInvocation (KeyToDDL and ForeignKeyToDDL). It seems that there are no ways to attach the static text portions "CREATE TABLE", "(" and ");" to the model. The OCL specification contains a StringLiteralExp class that could be used to attach this kind of static literal text. But for that to work, StringLiteralExp instances should be attachable somewhere, for instance, in the Block's body. In that case, perhaps that 'body' property could change its type from TemplateExpression to the more general OCLExpression, in order to allow StringLiteralExp's to be directly added to 'body', although this could be too much a general solution and would possibly require further testing. Solution: The metamodel could be change as follows: --------- ----------------- | Block | 1 ---------> 0..* | OclExpression | --------- body -----------------

  • Reported: MOFM2T 1.0 — Wed, 16 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.2, 7.3, A3 OCLExpression

  • Legacy Issue Number: 12184
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Title: OCLExpression doesn't support the plus operator for string concatenations Message: The OCL specification defines (see 7.4: Basic Values and Types, page 10) the number of operations on the predefined types. The string type supports the concat, substring and size operations, but the plus operator is only used in integer types. The Mof2Text specification uses the plus operator to concatenate strings, and it's an error. Here there are some examples: 1. 7.2 Traceability --> [trace (c.id + '_definition') ] 2. 7.3 Directing Output to Files --> [file ('file:\\' + c.name + '.java', false, c.id + 'impl')] 3. A.3 Example 3 --> [file (c.name + '.cpp', false)] [trace (c.id + '.header')]

  • Reported: MOFM2T 1.0 — Wed, 16 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ambiguity detected in Invocation rule Message

  • Legacy Issue Number: 12176
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    The Mof2Text concrete syntax contain the following rules (see p. 22): <OclExpressionCS> ::= ( <PropertyCallExpCS> | <VariableExpCS> | <LiteralExpCS> | <LetExpCS> | <OclMessageExpCS> | <ifExp> | <invocation> ) <invocation> ::= ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] <actualarglist> ::= ( <OclExpressionCS> ( ',' <OclExpressionCS> )* )? <before> ::= 'before' '(' <OclExpressionCS> ')' <separator> ::= 'separator' '(' <OclExpressionCS> ')' <after> ::= 'after' '(' <OclExpressionCS> ')' The OCL concrete syntax contain the following rules (see OCL Specificacion. Pages 64, 72, 80 and 81) OclExpressionCS ::= PropertyCallExpCS | VariableExpCS | LiteralExpCS | LetExpCS | OclMessageExpCS | IfExpCS PropertyCallExpCS ::= ModelPropertyCallExpCS | LoopExpCS ModelPropertyCallExpCS ::= OperationCallExpCS | AttributeCallExpCS | NavigationCallExpCS OperationCallExpCS ::= OclExpressionCS[1] simpleNameCS OclExpressionCS[2] | OclExpressionCS '->' simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS '(' argumentsCS? ')' | simpleNameCS '(' argumentsCS? ')' | OclExpressionCS '.' simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | simpleNameCS isMarkedPreCS '(' argumentsCS? ')' | pathNameCS '(' argumentsCS? ')' | simpleNameCS OclExpressionCS argumentsCS[1] ::= OclExpressionCS ( ‘,’ argumentsCS[2] )? The conflict appears when the before, separator and after rules are all empty at the same time in the <invocation> MOF2Text rule. In that case the resolution proceeds as follows: OclExpressionCS ::= invocation ::= PathNameCS '(' actualarglist ')' OclExpressionCS ::= PropertyCallExpCS ::= ModelPropertyCallExpCS ::= OperationCallCS ::= pathNameCS '(' argumentsCS? ')' Solution: The best solution I have found to avoid this conflict involves the introduction of a new keyword, 'invoke'. The invocation rule could be updated as follows: <invocation> ::= invoke ( <PathNameCS> '(' <actualarglist> ')' | 'super' ) [ <before> ] [ <separator> ] [ <after> ] This way we can distinguish easily between the two cases. TemplateInvocation, MacroInvocation and QueryInvocation would then always resolve unambiguously into this last rule.

  • Reported: MOFM2T 1.0 — Tue, 15 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 8.2

  • Legacy Issue Number: 11964
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    Grammar errors in section '8.2 concrete syxtax: syntax: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> ('/elseif') ? It should be: ::= 'elseif' '(' <OclExpressionCS> ')' <production_code> '/elseif' syntax: ::= '[else]' <production> ('[/else]')? It should be: ::= '[else]' <production> '[/else]'

  • Reported: MOFM2T 1.0 — Wed, 2 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Typos in examples

  • Legacy Issue Number: 11093
  • Status: open  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Issue: Typos in examples:
    In Annex A, A.1 Example 1:
    In the example fragment
    [template public SchemaToDDL (s: Schema)]
    [for (t:Table | s.table)]
    TableToDDL(t)
    [/for]
    [/template]

  • Reported: MOFM2T 1.0b1 — Fri, 8 Jun 2007 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification error in concrete syntax

  • Legacy Issue Number: 12174
  • Status: open  
  • Source: OpenCanarias ( Nuria Tejera)
  • Summary:

    I've detected an error in the module rule of the concrete syntax section (8.2). This rule has an inconsistency with respect to the metamodel specified in section 8.1. The syntax is: <module_decl> ::= '[module' <PathNameCS> ‘(‘ <PathNameCS> ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> [extends_decl] ---------- -------------- | Module | 0..* ---------> 1..* | TypedModel | ---------- -------------- So a Module can contain one or more TypedModels, but the grammar does not seem to provide ways to attach more than one. Solution: The module rule could be changed as follows: <module_decl> := '[module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl] '/]' | 'module' <PathNameCS> ‘(‘ <PathNameCS> ( ‘,’ <PathNameCS>)* ‘)’ [extends_decl]

  • Reported: MOFM2T 1.0 — Mon, 14 Jan 2008 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

In chapter '7 Overview':

  • Key: MOFM2T-7
  • Legacy Issue Number: 11094
  • Status: closed  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Examples have incorrectly escaped template invocations
    E.g.
    [attributeToJava(c.attribute)]
    [operationToJava(allOperations(c))]
    // Constructor
    [c.name/]()
    {
    }
    }
    [/template]

    template invocations are not escaped properly.
    They should be [TableToDDL(t)/],[attributeToJava(c.attribute)/] and
    [operationToJava(allOperations(c))/] respectively.

  • Reported: MOFM2T 1.0b1 — Fri, 8 Jun 2007 04:00 GMT
  • Disposition: Resolved — MOFM2T 1.0
  • Disposition Summary:

    Replace with the text below,
    [attributeToJava(c.attribute)/]
    [operationToJava(allOperations(c))/]
    // Constructor
    [c.name/]()
    {
    }
    }
    [/template]

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

Wrong relation in input model

  • Legacy Issue Number: 16349
  • Status: open  
  • Source: Cassiopae ( Franck Michaux)
  • Summary:

    The class Department_fky has wrong relations, should be between class Employee and class Department_pky.

    [Employee : Table]

    {foreignKey}

    V
    [Department_fky : ForeignKey]

    {refersTo}

    v
    [Department_pky : Key]
    ^

    {key}

    [Department : Table]

  • Reported: MOFM2T 1.0 — Mon, 27 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

abstract metaclasses should be italic

  • Legacy Issue Number: 17267
  • Status: open  
  • Source: Vienna University of Economics and Business ( Bernhard Hoisl)
  • Summary:

    In the metamodel diagram in Section 8.1 NamedElement and ModuleElement should be written in italic letters because they are abstract metaclasses.

  • Reported: MOFM2T 1.0 — Thu, 22 Mar 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

set of problems with the currently described operations

  • Key: MOFM2T11-2
  • Legacy Issue Number: 13845
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    There are a set of problems with the currently described operations within the MOF Models to Text Transformation Language specification for the addition of new operations to extends the OCL standard library. Specifically, redundant, misleading or plain missing operations. >From now on I'll refer as "OCL specification" the following document : Object Constraint Language specification version 2.0 formal/06-05-01 . Likewise, "MTL specification" will refer to the following : MOF Models to Text Transformation Language version 1.0 formal/2008-01-16. I'll describe the aforementionned issues in three parts from now : A - Redundant operations "toUpper()" and "toLower()" operations are both specified for the String type in section 8.3.1 . Both of these are already defined in the OCL specification in section A.2.1.3 Table A.1 . They should then be removed from the MTL specification. B - Misleading operations Early adopters and testers of our implementation have confirmed that the "strtok(String, Integer) : String" as described in the MTL specification at section 8.3.1 isn't useable as is. Specifically, the integer flag makes it awkard to use : cannot be entirely used in a loop as they need to have the flag at "0" for the first call ... and plain weird to use in any other place, yet again because of this flag. Replacing this operation with a Java-like "tokenise" with no integer flag and returning the whole set of tokens would be easier to consume in a loop or use in templates/queries. C - Missing operations This is a different matter. The following list will consist on the one hand of things we found plain missing from the MTL specification and, on the other hand, of repetitive tasks our early adopters and testers have reported as bothersome to write in OCL and hindering the readability of scripts as a whole. First of all, the MTL specification describes a "substitute(String, String)" operation that can be used to "Substitute substring r in self by substring t and returns the resulting string.". From this we can say that three operations are missing from the spec (more details in the full list at the end of this report) : 1) substituteAll( String substring, String replacement ) : String 2) replace( String substring, String replacement ) : String 3) replaceAll( String substring, String replacement ) : String Further usage from these adopter and testers have shown that some usual operations are impossible (or plain bothersome) to write in OCL. These include (again, detailed description in the full list below) : String operations 4) startsWith( String substring ) : Boolean 5) endsWith( String substring ) : Boolean 6) trim( ) : String OclAny operations 7) ancestors( ) : Sequence(T) 8) ancestors( OclAny type ) : Sequence(T) 9) siblings( ) : Sequence(T) 10) siblings( OclAny type ) : Sequence(T) 11) descendants( ) : Sequence(T) 12) descendants( OclAny type ) : Sequence(T) Likewise, the "toString()" operation described in the MTL specification on both Real and Integer types isn't sufficient for a text generation language this same toString operation should be added to the standard type OclAny so that the user can obtain the String representation of each and every element. To sum this up, here is the full list of operations we would like to add to (or alter within) the MTL specification: C.1 - String operations C.1.a - modifications operation "strtok( String s1, Integer flag ) : String Breaks the string self into a sequence of tokens each of which is delimited by any character in string s1. The parameter flag should be 0 when strtok is called for the first time, 1 subsequently." should be altered to be "strtok( String s1, Integer flag ) : Sequence(T) Returns a sequence containing all parts of self split around delimiters defined by the characters in String delim." C.1.b - additions 1) endsWith( String substring ) : Boolean Returns true if self ends with the substring substring, false otherwise. 2) startsWith( String substring ) : Boolean Returns true if self starts with the substring substring, false otherwise. 3) substituteAll( String substring, String replacement ) : String Substitutes all substrings substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are not treated as regular expressions. 4) replace( String substring, String replacement ) : String Substitutes the first occurence of substring substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are treated as regular expressions. 5) replaceAll( String substring, String replacement ) : String Substitutes all substrings substring in self by substring replacement and returns the resulting string. If there is no occurrence of the substring, The original string is returned. substring and replacement are treated as regular expressions. 6) trim( ) : String Removes all leading and trailing spaces of self. C.2 - OclAny operations C.2.a - additions 7) ancestors( ) : Sequence(T) Returns all super-elements of self. 8) ancestors( OclAny type ) : Sequence(T) Returns all super-elements of self which type is equal to type. 9) siblings( ) : Sequence(T) Returns all siblings of self. 10) siblings( OclAny type ) : Sequence(T) Returns all siblings of self which type is equal to type. 11) descendants( ) : Sequence(T) Returns all direct and indirect children of self. 12) descendants( OclAny type ) : Sequence(T) Returns all direct and indirect children of self which type is equal to type. 13) toString( ) : String Returns the String representation of self.

  • Reported: MOFM2T 1.0 — Mon, 30 Mar 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing reference


File unique id is not useable

  • Key: MOFM2T11-5
  • Legacy Issue Number: 14434
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    In section 7.3, the file block of the MOF model to text transformation language is detailed. This section introduces the "uniqId" attribute of the file blocks which is meant to allow a tool to find back a generated file even if the object from which it's been generated changed significantly since the last generation.

    Though this is a good thing in theory, such an ID cannot be implemented whatever the programming language chosen. Or rather, it cannot be implemented in a satisfying way. Let's assume we have this file block :
    [file ('c:/'.concat(class.name).concat('.c'), false, class.id)]

    So a file "class.c" will be generated at the root of disk c. Now I change my module so that now, the file block resembles this :
    [file ('d:/generated/'.concat(class.name).concat('.c'), false, class.id)]

    The class itself hasn't changed one bit; so both the file name (class.c) and its id (class.id) remain constant. How can the tool find back that a file has already been generated for such an ID?

    The tool itself cannot keep a reference to all files it has generated along with their IDs and locations; the possibility that we're generating files under version control and that others can generate the same on their own machines forbids this. The solution would then be to save the file along with its ID, thus breaking the WYSIWYG assumption of the specification as unwanted information would show up in the generated file.

    And even like that, the tool would need to lookup throughout the whole file system of the target in order to try and find a file which ID is the same as what we need to generate. With the current computers, that could mean searching within terabytes of data in order to find a file that might not even exist in the first place, and that for each [file] block of a generation module.

    I believe this unique ID is a good idea in theory, yet seeing as this idea cannot be implemented as more than an idea, I think all references to an ID should be removed from 7.3 (description of the file block), 8.1 (metamodel), 8.1.17 (file block's attributes) and 8.2 (concrete syntax).

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

current version of the specification doesn't allow for any "post-processing" of the generated text.

  • Key: MOFM2T11-4
  • Legacy Issue Number: 14031
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    The current version of the specification doesn't allow for any "post-processing" of the generated text. I can see two potential needs of post-processing : 1) template level. As well as users can specify guards and overrides, They should be offered the possibility to specify a "post" action in the form of a template or operation call that would be executed on the whole generated text (except for those nested within [file] blocks, see point 2)). For example, I could be defining a template that generates the text pertaining to the body of a Java Class. I might want to trim this text from all surrounding whitespaces before generating and returning it. This would make something like (on UML Class) : [template public classBody(clazz : Class) post (trim())] ... [/template] Such a feature would allow for more readable templates as the user wouldn't be forced to trim() everywhere this template is used. 2) file level. Users might want to call something as a post-processing of a file generation. The most obvious example is the call for a code formatter after a code generation. As above, this would give something like : [file ('Class.java', false) post (format())/] ... [/file]

  • Reported: MOFM2T 1.0 — Thu, 25 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 7.3, 8.1, 8.1.17

  • Key: MOFM2T11-3
  • Legacy Issue Number: 13997
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MTL defines an "open mode" to define how file blocks should behave : whether they append to existing files or overwrite them is defined this way. These two modes are not sufficient : users might want to generate files only when they don't exist. This can be either the very first transformation they execute (thus the file doesn't exist and need be created) or a latter generation when the user has deleted (inadvertently or on purpose) the target file. This is useful for configuration files that do not accept comments (thus rendering protected blocks unusable as these need a marker). An example of such a file is java's MANIFEST.MF file which format is extremely rigid.

  • Reported: MOFM2T 1.0 — Wed, 17 Jun 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add an attribute to the files block for users to specify generated file's encoding

  • Key: MOFM2T11-7
  • Legacy Issue Number: 14437
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    MOFM2T aims at being a standard for code generation, and as such it will be used to generate/override files that are under a version control management system. Files can then be generated indiscriminately under windows, linux or mac ... or the three at once for 'big' development teams.

    The generated file's encoding then becomes an issue : we cannot always generate files with the default system's encoding : windows' CP1252 as no equivalent in unices, and unix' UTF-8 might cause problems in windows if windows developpers re-generated files that have been first generated under an unix system.

    File encoding should be an optional attribute of the file blocks; so someone could write
    [file ('class.java', false, 'UTF-16')] or [file ('class.java', false, 'ISO-8859-1')] to tell that the target file should be encoded in such or such way.

    Note : this goes along with a previously raised issue in which I asked that the file's unique ID be removed. we'll need to find how to describe the encoding if the unique ID is not removed (as that would make file blocks with two optionnal expressions as their last parameter).

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos/issues in the examples

  • Key: MOFM2T11-6
  • Legacy Issue Number: 14436
  • Status: open  
  • Source: Obeo ( Laurent Goubet)
  • Summary:

    Some of the examples given in the specification assume that there is a "+" operator defined between Strings. This is not true in OCL, and there is none defined in the MOFM2T specification itself.

    page 9, section 7.2 :
    [trace(c.id()+ '_definition') ]
    should be
    [trace(c.id().concat('_definition')) ]

    page 9, section 7.3 :
    [file (‘file:\\’+c.name+’.java’, false, c.id + ‘impl’)]
    should be
    [file (‘file:\\’.concat(c.name).concat(’.java’), false, c.id.concat(‘impl’))]

    Furthermore, the description of this examples tells readers that a file named "cust.sql"; this is wrong. the text below the example of 7.3 should be :

    ---------8<---------
    Suppose the above specification was run on a class named ‘cust,’ it would produce Java code in cust.java file and a log
    entry ‘processing cust’ in log.log file. Suppose after generation, the storage specification was added in the protected area
    of file cust.java. Even if the classname is changed later, say to ‘customer,’ a tool will be able to retain the storage
    specification in the new file customer.java as the file block takes unique id as a parameter that hasn’t changed (for ‘cust’
    object). The uri ‘stdout’ denotes the stdout output stream.
    --------->8---------

    Page 30, Annex A.3
    Counting the "+"<=>"concat" error only once, this example sports no less than 9 syntax errors. Replace all text with :

    ---------8<---------
    [module class_header_gen ( UML ) /]

    [template public class_header(c : Class)

    { Integer count = -1; }

    ]
    [file (c.name.concat('.cpp'), false)]
    [trace(c.id().concat('_header'))]
    // Bit vector #defines
    [for(a : Attribute | c.attribute)

    { Integer count = count + 1; }

    ]
    #define [a.name/]_BIT [count/]
    [/for]
    class [c.name/] [for(c:Class | c.super) before(':') separator(',')] [c.name/] [/for]
    {
    bool bitVector [‘[‘.concat(c.attribute->size()).concat(’]’)/];
    // Attribute declarations
    [for (a : Attribute | c.attribute)]
    [a.type.name/] [if(isComplexType(a.type))]*[/if] [a.name/];
    [/for]
    // Constructor
    [c.name/]()
    {
    // initialize bit vector
    for (int i = 0; i < [c.attribute->size()/]; i++)

    { bitVector[‘[i]’] = 0; }

    [protected ('user_code')]
    // your code here
    [/protected]
    }
    // Attribute set/get/isSpecified methods
    [for (a : Attribute | c.attribute)]
    void Set[a.name/] ([a.type.name/] [if(isComplexType(a.type))] * [/if] p[a.name/])

    { bitVector[’[‘.concat(a.name).concat(’_BIT]’)] = 1; [a.name/] = p[a.name/]; }

    [a.type.name/] Get[a.name/] ()

    {return [a.name/];}

    bool isSpecified[a.name/]()

    {return bitVector[’[‘.concat(a.name).concat(’_BIT]’)];}

    [/for]
    // Method declarations
    [for (o : Operation | c.operation) ]
    [o.type.name/] [o.name/] ([for(p:Parameter | o.parameter) separator(',')] [p.type/] [p.name/] [/for]);
    [/for]
    }
    [/trace]
    [/file]
    [/template]
    --------->8---------

    Another solution to fix these errors would be to rely on the 2.1 version of the OCL specification which will introduce a '+' operator for Strings; or to add this operator in the MOFM2T specification.

  • Reported: MOFM2T 1.0 — Mon, 28 Sep 2009 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Whitespace handling rules unclear

  • Key: MOFM2T-9
  • Legacy Issue Number: 11279
  • Status: closed  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Whitespace handling rules are not clear:
    1. Is whitespace preceding multi-line block expressions (such as for, if, etc) included in the text output? Examples
    given in the appendix do not seem to include it.
    2. Whitespace handling rule 3 says: "Indentation of the text produced for the invoked template starts at the indentation at the point of the template invocation." Should this be the case even for an embedded template invocation, i.e. a template
    invocation that is surrounded by other expressions on the same line?
    E.g.
    [template printClass(c:Class)]
    class [c.name/] implements [printInterfaceName(c.implementsInterface) sep(',')]
    [/template]
    [template printInterfaceName(i:Interface)]
    [i.name/]
    [/template]
    Here printInterface is invoked iteratively for each interface implemented by the class.
    One would expect following kind of output from this:
    class myClass implements myIntf1, myIntf2, myIntf3,...

    But the rule seems to say that the output of each template invocation starts at the same indentation level.
    This is probably not the intended behaviour, atleast for embedded template invocations (like the one above).

  • Reported: MOFM2T 1.0b1 — Mon, 13 Aug 2007 04:00 GMT
  • Disposition: Resolved — MOFM2T 1.0
  • Disposition Summary:

    Replace existing text in the section discussing whitespace handling with the text given
    below,
    Text production rules will be easier to specify by viewing the body of a template (or a
    block expression) as follows:
    <block-body> ::= <body-element>*
    <body-element> ::= <literalString> | <whitespace> | <expression> | <BOL-indicator>
    <whitespace> ::= space | tab | newline
    <expression> ::= <stand-alone-block-expression> | <embedded-block-expression> |
    <stand-alone-template-invocation> | <embedded-template-invocation> |
    <other-expression>
    <BOL-indicator> ::= ‘^’
    <stand-alone-block-expression> is a block expression (single or multi-line) that is not
    surrounded by other body elements on the lines where the block head and the tail occur.
    <embedded-block-expression> is a block expression that is surrounded by other nonwhitespace
    body elements on the lines where block head or tail occur.
    <stand-alone-template-invocation> is a template invocation expression that stands on a
    line all by itself.
    <embedded-template-invocation> is a template invocation that is surrounded by other
    body elements on the same line.
    <other-expression> refers to all expressions other than the block and template invocation
    expressions.
    Text production rules:

    • All body elements produce text
    • The text output of a block-body is the sequential concatenation of the text outputs of
      its body elements
    • Rules for identifying starting and ending of block body:
      o template: body starts at the beginning of the next line after the template head,
      and ends on the last character (excluding the new line) of the line previous to
      the template tail.
      o multi-line-block: body starts at the beginning of the next line after the block
      head, and ends on the last character (excluding the new line) of the line
      previous to the block tail.
      o single-line-block: body starts after the closing bracket of the block head and
      ends before the starting bracket of the block tail.
    • Text outputs of different body elements:
      o A literal string is output as is.
      o A whitespace character is output as is. The text produced by the execution of <other-expression> is output as is.
      o The text produced by the execution of <embedded-block-expression> is
      output as is.
      o The text produced by the execution of <embedded-template-invocation> is
      output as is.
      o <stand-alone-block-expression> needs special handling:
      .. Ignore the whitespace characters occurring before the beginning of the
      head.
      .. In the case of a multi-line 'for block', when a separator character is not
      specified, use 'new line' as the default separator between the outputs
      produced by successive iterations.
      o <stand-alone-template-invocation> needs special handling:
      .. Add the whitespace preceding the invocation expression before each
      line of the text produced by the invoked template.
      .. In the case of an iterative template invocation (e.g. when the argument
      is a collection), if a separator character is not specified, use 'new line'
      as the default separator between the outputs produced by successive
      iterations.
      <BOL-indicator> is a special character (‘^’) that marks the beginning of a line – i.e. on
      the line on which this character appears, the whitespace preceding the character should be
      excluded from the text output.
      In code-explicit mode, all whitespace must be explicitly specified.
      Move this section after the section describing concrete syntax.
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue: Grammar error:

  • Key: MOFM2T-8
  • Legacy Issue Number: 11095
  • Status: closed  
  • Source: TCS ( Sreedhar Reddy)
  • Summary:

    Grammar error in section '8.2 concrete syntax':
    <elseif> ::= '[elseif]' '(' <OclExpressionCS> ')' <production> ('[/elseif]')?

    It should be:
    <elseif> ::= '[elseif' '(' <OclExpressionCS> ')' ']' <production> '[/elseif]'

  • Reported: MOFM2T 1.0b1 — Fri, 8 Jun 2007 04:00 GMT
  • Disposition: Resolved — MOFM2T 1.0
  • Disposition Summary:

    Replace the following text in section '8.2 concrete syntax':
    <elseif> ::= '[elseif]' '(' <OclExpressionCS> ')' <production>
    ('[/elseif]')?
    With the text below,
    <elseif> ::= '[elseif' '(' <OclExpressionCS> ')' ']' <production>
    ('[/elseif]')?

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

Sections 5.3 and 5.5

  • Key: MOFVD2-2
  • Legacy Issue Number: 8999
  • Status: closed  
  • Source: Tata Consultancy Services Limited ( Suresh Babu Datla)
  • Summary:

    The "MOF2.0 Core Specification" states that a package may contain other packages, which may in turn contain other Packages. But the "MOF2 Versioning Final Adopted Specification" doesn't mention about the versioning semantics related to containment of packages. Following are few concerns: If 'checkIn()' operation of a VersionedExtent object is called and if this VersionedExtent object contains other VersionedExtents, then should new versions be created even for the contained VersionedExtents ? If 'delete()' operation of a Version object is called and if this Version object contains other Versions, then should the deletion be performed even for the contained Versions ?

  • Reported: MOFVD 2.0b1 — Tue, 13 Sep 2005 04:00 GMT
  • Disposition: Resolved — MOFVD 2.0
  • Disposition Summary:

    see above, closed, no change

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

Section: section 5.5

  • Key: MOFVD2-3
  • Legacy Issue Number: 9021
  • Status: closed  
  • Source: Tata Consultancy Services Limited ( Suresh Babu Datla)
  • Summary:

    From the MOF versioning specification its not clear , how to determine whether Extent is changed or not. In order to version an extent, first there is need to determine whether extent is changed or not. Is addition/modification/deletion of objects/slots/links considered as a change for an Extent? Can links go beyond extent? Can there be inter-versionedExtent links? If yes, then which extent 'owns' such links? and which extent is considered as changed? Is there any relationship with navigation of association, for determining which extent is changed?

  • Reported: MOFVD 2.0b1 — Wed, 28 Sep 2005 04:00 GMT
  • Disposition: Resolved — MOFVD 2.0
  • Disposition Summary:

    see above, closed, no change

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

WG: Attribute accessors and mutators

  • Key: MOF14-81
  • Legacy Issue Number: 2876
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: 1) Should the describe() and modify() operation available be on instance and
    class level interfaces? For class level attributes it is not necessarly
    needed because they probably will not be read and modified very often in a
    group.

    2) The property set should be defined in a value-struct. Which attributes
    should the instance level value-struct contain? class level and instance
    level attributes. I would prefer only to have instance level attributes in
    the instance level modify() and describe() operations because of (hopefully)
    the separation of instance and class level interfaces (no inheritance
    anymore!).

    3) Should the value-struct also contain multi-valued attributes. I would
    prefer, not to include multi-valued attributes in the value-struct because
    of the modify() operation.

    4) How about read-only attributes. If the same value-struct is used for
    describe() and modify(), should the read-only attributes be included in the
    value-struct and ignored in the modify() operation?

    5) To define the value-struct as a NamedValue sequence with the values of
    the type any (as available in the Reflective interface) is not optimal
    because this operation is untyped and requires the use of the any type. The
    value-struct should be typed.

    6) In our work we have defined the value-struct, modify() and describe()
    operations as model-specific operations (this is fully MOF-compliant). This
    allows us to customize the value-struct as needed. However, because probably
    everybody has the same requirements there should be a way in the MOF-spec to
    defined such constructs in a standard way.

  • Reported: MOF 1.2 — Thu, 9 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - coverage of RefXXX interfaces by MOF metamodel

  • Key: MOF14-83
  • Legacy Issue Number: 2925
  • Status: open  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    This issue is to ensure that the MOF metamodel contains sufficient information
    to hold information available through the RefObject and related interfaces.
    Examples include the metaObject-instances relationship.

    XMI documents using the MOF DTD should include sufficient information to be used
    as backup/restore and initialization of a MOF-compatible system. The MOF
    interfaces should be complete enough to enable this capability.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - setting UUIDs

  • Key: MOF14-82
  • Legacy Issue Number: 2923
  • Status: open  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    The MOF interfaces need to provide an API to set uuids. A convention for
    denoting uuids for metamodel objects defined by OMG standards would be
    beneficial. For example, the uuids of the UML Class, Attribute, and Operation
    constructs could be set following this convention by the UML RTF.

  • Reported: MOF 1.2 — Wed, 22 Sep 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tags that parameterize a meta-model mapping

  • Key: MOF14-66
  • Legacy Issue Number: 2165
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Summary: If we allow Tags to parameterize a meta-model (e.g. IDL) mapping
    as proposed for issue 1307 (for example), there needs to be a reliable
    way for a client of the mapped interfaces to find that Tags that were
    in force. Without this, it cannot reflectively work out what the mapped
    interfaces do.

    Additional text:

  • Reported: MOF 1.2 — Wed, 4 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is a UML "profile"?

  • Key: MOF14-65
  • Legacy Issue Number: 2046
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The concept of profile may need to be escalated to the MOF level (for
    example as a subset of metadata constructs packaged together with
    appropriate classifiers, tags, constraints etc. -). I agree that
    creating new metamodels for each minor extension is not a tractable
    solution to the problem - especially if it means tool vendor cost of
    supporting it is too much.

  • Reported: MOF 1.2 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF RTF Isue: Conflict between "Facility" and "Package Object "

  • Key: MOF14-62
  • Legacy Issue Number: 1505
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a major conflict between the "Facility" Package
    described in Section 4 and the M1-level object model expressed in
    Section 7. Section 4 defines a concept of a "model repository",
    embodied by the Facility::ModelRepository class, as the boundary for
    M1-level associations and classifier level state. Indeed, this seems
    to be the main purpose of Facility::ModelRepository instances. On the
    other hand, the IDL mapping in Section 7 defines the M1-level
    <package-name>Package interface with the primary purpose of providing
    this boundary. [Section 5 is ambiguous.] This overlap in purpose and
    functionality is causing confusion, and is obscuring the need for
    standardisation of something to provide a container and a directory
    for a set of (possibly unrelated) models and meta-models.

  • Reported: MOF 1.2 — Fri, 5 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Generated operations returning attributes/references should not raise Cons

  • Key: MOF14-61
  • Legacy Issue Number: 1082
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The generated IDL for the MOF includes ConstraintError in
    the raises clause of operations generated via the Attribute
    Template and Reference Template, although these templates do
    not include spcification of that exception (identified in a
    separate issue). When that specification is updated, it
    should specify that the generated "read" operations do not
    raise this exception. The current IDL has ConstraintError
    in the raises clause of the following operations, which do
    not change the state of the model:

  • Reported: MOF 1.2 — Wed, 18 Mar 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Reference "set" onto an ordered Association.

  • Key: MOF14-64
  • Legacy Issue Number: 1804
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The description of the semantics of Reference operations
    in section 6.2.2.1 needs to be extended to cover the multi-value
    update operations; i.e. "set" and "unset" when the referenced
    AssociationEnd is multi-valued. In particular, the semantics when
    either of the AssociationEnds is ordered need to be spelled out.

  • Reported: MOF 1.2 — Thu, 13 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ModelElement needs to have permanent, unique, unchanging, identifier

  • Key: MOF14-63
  • Legacy Issue Number: 1540
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ModelElement needs to have a permanent, unique, unchanging,
    non-redundant (within the transitive closure of a "large" namespace)
    (meta)identifier in addition to or as a replacement for qualifiedName
    as a local (meta)attribute.

  • Reported: MOF 1.2 — Wed, 24 Jun 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide tools to chapter 5 UML 1.3R9 draft

  • Key: MOF14-78
  • Legacy Issue Number: 2449
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I would like to suggest that the UML model interface defined by Chapter 5 of the
    UML1.3R9 draft provide tools the ability to register for notification of changes to the
    model contents in a manner consistent with the Observer pattern.

    This would provide a better mechanism for tool integration around a common
    model respository, allowing each tool in a tool suite containing tools developed
    by different vendors to present its own up to date "view" of the underlying model in
    a simple fashion.

  • Reported: MOF 1.2 — Thu, 11 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Reflective.DesignatorType be "string"?

  • Key: MOF14-77
  • Legacy Issue Number: 2224
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Reflective interfaces currently use object references to
    "designate" the feature (etc) to which a reflective operation applies.
    In practice, I am finding that this is inconvenient for clients of the
    API and potentially difficult for implementations. I suggest that we
    reconsider the alternative; i.e. designating features using CORBA
    strings.

  • Reported: MOF 1.2 — Thu, 19 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Do non-public Attributes need initialising?

  • Key: MOF14-80
  • Legacy Issue Number: 2839
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e
    "create_<classname>" operation should have parameters to provide initial
    values for Attributes whose visibility is "protected_vis" or "private_vis".
    The same applies for 5.8.3 for classifier-level Attributes in the Package
    factory interface.

  • Reported: MOF 1.2 — Thu, 12 Aug 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

IDL for Reflective Package Interfaces can conflict

  • Key: MOF14-79
  • Legacy Issue Number: 2527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for the Reflective Package interfaces can conflict with IDL generated according to the MOF Model to IDL mapping rules. For example, when generating IDL for the UML metamodel, the UML class called Instance causes generation of an operation called create_instance which conflicts with the Reflective create_instance. The reflective interfaces should be changed to avoid such conflicts.

  • Reported: MOF 1.2 — Thu, 11 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify the semantics of Constraint verification

  • Key: MOF14-72
  • Legacy Issue Number: 2181
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We need a thorough specification of the semantics of Constraint
    verification. This should cover the following:
    1) What happens; e.g. is the verification allowed to give up on the
    first error?
    2) When evaluation of deferrable Contraints can occur; i.e. where could
    the ConstraintError exceptions be raised?
    3) How evaluation of deferred Constraints is triggered.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add appropriate Attribute default values to the MOF Model

  • Key: MOF14-71
  • Legacy Issue Number: 2179
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Assuming that we add the capability of defining defaults for
    Attributes [see previous issue], there are a number of Attributes in
    the MOF Model that could / should have default values; for example
    "visibility" should default to "public", and "is_root"/"is_leaf" should
    default to "dont_care".

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF Model IDL versus OMG Style guidelines

  • Key: MOF14-76
  • Legacy Issue Number: 2188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that the MOF IDL doesn"t
    conform with the OMG style guidelines and conventions in two
    respects. First, there is no "#pragma prefix "org.omg"" in any of
    the core IDL files. Second, there is a convention that the
    outermost module names for OMG specs have a standard prefix
    depending on its "positioning" in the OMA; e.g. Cos, Cf or
    whatever.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need for light-weight References

  • Key: MOF14-75
  • Legacy Issue Number: 2186
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A requirement possibly exists for a light-weight version of
    References (or something like them), which at the M1 level does not
    require the existence of Attribute instance objects and the associated
    heavy weight querying mechanisms.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add a new technical overview chapter between chapters 2 and 3"

  • Key: MOF14-74
  • Legacy Issue Number: 2183
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF specification needs a technical overview before chapter
    3 to help the reader put the details in the rest of the MOF specification
    into a perspective.

    Additional text:

    I am in the process of drafting a possible overview chapter.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Freezing mechanism for all models

  • Key: MOF14-73
  • Legacy Issue Number: 2182
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Model currently has a mechanism for freezing meta-models.
    It is underspecified, but the intent is that under certain conditions you
    can atomically freeze a valid meta-model. This issue proposes that this
    mechanism be re-specified so that it is available for all models.

    Additional text:

    Arguably this is an extension rather than an RTF issue.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for Exception generalization

  • Key: MOF14-69
  • Legacy Issue Number: 2177
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: UML currently supports Exception hierarchies, as do many
    object orient programming languages. MOF"s lack of support for this
    is perceived to be a limitation and an impediment to its use as a
    middleware independent meta-data framework.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validate the OCL constraints in the MOF specification

  • Key: MOF14-67
  • Legacy Issue Number: 2173
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Take steps to validate as much as possible of the OCL in the
    MOF specification. Ideally, they should all be compiled and "executed"
    to ensure that they behave as expected. This should be feasible at least
    for the OCL constraints in the Model package.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add support for default values to MofAttribute

  • Key: MOF14-68
  • Legacy Issue Number: 2174
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been suggested that Model should be extended to allow
    attributes to specified to have default values. Default values can be
    defined in the MOF Model by adding an attribute of type "any" to
    MofAttribute. [Default expressions are too hard.]

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Define a MOF Class that is the supertype of all Classes

  • Key: MOF14-70
  • Legacy Issue Number: 2178
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define a MOF Class that is the supertype of all Classes.
    It could be represented as a single-valued subclass of Model::Class.

  • Reported: MOF 1.2 — Fri, 6 Nov 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Collections of imported DataTypes can cause name clashes

  • Key: MOF14-36
  • Legacy Issue Number: 2922
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    If a Package declares a DataType with a given name and imports
    another Package that also declares a DataType with the same name
    the IDL templates can generate uncompilable IDL for the collections
    typedefs if both are required.

  • Reported: MOF 1.3 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

"exposedEnd" for any of the references in the MOF metamodel.

  • Key: MOF14-35
  • Legacy Issue Number: 4798
  • Status: open  
  • Source: Anonymous
  • Summary:

    If Attribute.isDerived was moved up to StructuralFeature, then you could model derived references. An example of such a derived reference in the MOF meta-model is Reference.exposedEnd, which is equivalent to ref.referencedEnd.otherEnd().

    Relatedly, the copy of ptc/2001-10-05 found on the RTF website doesn't include the "exposedEnd" for any of the references in the MOF metamodel.

  • Reported: MOF 1.4 — Fri, 21 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Generalization Proposal

  • Key: MOF14-34
  • Legacy Issue Number: 4720
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    Here is a detailed proposal for adding association generalization to MOF
    1.5. This proposal does not address reference redefinition or overriding.
    I hope this proposal provides sufficient detail so that Steve Crawley can
    make changes to the specification. Please send your comments.

    Regards,
    Don

    Changes to Model

    Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]
    AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.

    Add a nonabstract association from AssociationEnd to AssociationEnd called
    RedefinesEnd. One end is called redefinedEnd, has a reference by the same
    name, and has multiplicity *. The other end is called redefiningEnd, has no
    reference, and has multiplicity *. This association is used to correlate an
    end with its corresponding end in a supertype association.

    Add new constraint: SupertypeEndsAreRedefined
    Evaluation policy: Deferred.
    Description: An end redefines each supertype's end.
    Context Association
    Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->
    forAll(ge : AssociationEnd |
    self.contents->select(sc |
    sc.oclIsTypeOf(AssociationEnd))->
    forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =
    ge)
    and se.otherEnd.redefinedEnd->exists(ore | ore =
    ge.otherEnd)))

    Add new constraint: RedefinedEndBelongsToSupertype
    Evaluation policy: Immediate.
    Description: Each redefinedEnd belongs to a supertype.
    Context AssociationEnd
    Inv: self.container.oclAsType(Association).supertypes.contents->
    includesAll(self.redefinedEnd)

    By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an
    immediate constraint, but it should be deferred. Otherwise, there is no
    valid way to create an Association.

    Changes to Abstract Mapping

    Add the following to Core Association Semantics.

    A link cannot be directly created for an Association with isAbstract set to
    true, but can be added indirectly as a link of a subtype association.

    Where a generalization exists between two associations, each link of the
    subtype association is logically a link of the supertype association - for
    each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or
    <b, a> depending on which subtype end redefines which supertype end).

    Removing a link from a Link_Set causes the logical link to be removed from
    each subtype association's Link_Set. Removing a link from a Link_Set also
    causes the logical link to be removed from each supertype association's
    Link_Set where the logical link is not otherwise present in the supertype
    Link_Set based on either having been put explicitly into the supertype
    Link_Set (where not abstract) or on being a link of some other subtype of
    the supertype. The net effect is that a Link_Set is a union of links put
    explicitly into the Link_Set with the Link_Sets of all subtypes.

    Changes to IDL Mapping

    In the template for associations, no add or modify operations are generated
    for an abstract association.

    In the template for references, no set, add, or modify operations are
    generated for an abstract association.

    Operations on RefObject for setting, adding, and modifying, and operations
    on RefAssociation for adding and modifying raise a new MofError, "Abstract
    Association", for creating a link of an abstract association.

    Changes to JMI

    In the template for associations, no add operation is generated for an
    abstract association.

    In the template for references, no set operation is generated for an
    abstract association. Also, the add and set operations on a reference
    collection throws a new JmiException, "AbstractAssociation", for an abstract
    association.

    For the reflective JMI interfaces, JmiException "AbstractAssociation" is
    thrown for refAddLink on an abstract association and for refSetValue on a
    reference on an abstract association.

  • Reported: MOF 1.4 — Fri, 30 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary constraint on import by nested packages

  • Key: MOF14-33
  • Legacy Issue Number: 4715
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Section 2.3.6.2 and Constraint [C-48] prevent a nested package from
    importing from anything else. This seems unnecessarily restrictive and makes
    the use practical of nested packages unlikely.

  • Reported: MOF 1.4 — Tue, 27 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong

  • Key: MOF14-31
  • Legacy Issue Number: 4664
  • Status: open  
  • Source: Anonymous
  • Summary:

    in section 5.8.12 "Reference Template", 1st para, it is stated: "The IDL generated for a Reference is declared within the scope of <ClassName>CLASS interface definition.", while the next para says: "The Reference Template defines the IDL generation rules for References. It declares operations on the INSTANCE interface to query and update links in the Association object for the current extent."

    I think, that all reference related IDL operations should go into the Instance interface, and not into the class proxy interface. This view is also compliant with 5.8.8 "Instance Template", that para states explicitly that the reference template is to be applied in the context of the instance template.

    Proposed Resolution:
    ====================
    Change the 1st para of 5.8.12 to "The IDL generated for a Reference is declared within the scope of <ClassName> interface definition.

  • Reported: MOF 1.4 — Tue, 6 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions needed for nested Packages and Classes

  • Key: MOF14-30
  • Legacy Issue Number: 4622
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In recent MOF RTF telcon discussions, we tentatively concluded that we need
    Constraints on the MOF Model to forbid 1) clustering of nested Packages,
    2) inheritance of nested Packages and 3) clustering of Classes.

    Additional Text:

    There are three arguments for the proposed restrictions. The first
    argument is that supporting inheritance / clustering in these cases adds
    to the complexity of MOF implementations. Since practical metamodels
    never seem to use these combinations of features, it is hard justify
    supporting them.

    The second argument is that clustering and inheritance of nested
    Packages is problematical. The elements of a nested Package are
    implicitly defined in the context of the nested Package's outer Package.
    A Constraint or Operation defined on / within a nested Package may
    reasonably refer to Associations or "all_of_*" collections in the
    enclosing context. When a nested Package is inherited or clustered
    outside of the context of its parent Package, the Constraint and
    Operation semantics may cease to be meaningful.

    The second argument does not apply to a nested Package that is
    inherited by another nested Package with the same outermost Package.
    However, we have not been able to identify a use case for this sort
    of thing. Hence the first argument applies.

    The third argument is that the MOF IDL mapping explicitly excludes all
    of these cases; see "Section 5.5 - Preconditions for IDL Generation".

  • Reported: MOF 1.4 — Thu, 18 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Looking up metaobject using MOFID

  • Key: MOF14-28
  • Legacy Issue Number: 4609
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    MOF should have a support for looking up metaobjects by MOFIDs (e.g. by adding getObjectByMOFID method to RefPackage interface).

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolveQualifiedName operation

  • Key: MOF14-27
  • Legacy Issue Number: 4607
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    I think it would be much more convenient to have resolveQualifiedName as a
    "classifier_level" operation on ModelElement instead of "instance_level"
    operation on Namespace. Now each time I want to resolve some object using
    its qualified name, I have to find all outermost packages (which is quite
    slow, because currently there is no better way of doing it than just iterate
    through all package instances and check whether they are outermost), then
    choose a package with a specified name and call resolveQualifiedName on that
    package passing rest of the qualified name as a parameter. This is much more
    complicated for users than it should be.

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecate object inheritance of class proxy interface

  • Key: MOF14-25
  • Legacy Issue Number: 4593
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF should deprecate the use of factory/finder operations on object
    instances (i.e. the fact that generated instances inherit not only from
    their model superclass but from their class proxy). The main reason for this
    is that it does not separate concerns (why should an instance know about
    creating other instances or finding the population of the class?) and is not
    consistent with JMI.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment of reflective interfaces with JMI

  • Key: MOF14-24
  • Legacy Issue Number: 4592
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF should consider aligning its reflective interfaces with JMI
    (specifically split some of RefObject into RefClass and common superclass
    RefFeatured). As well as the benefit of consistency it makes the interfaces
    more intuitive/comprehensible and typesafe.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigability of assoc. ends in MOF model

  • Key: MOF14-29
  • Legacy Issue Number: 4621
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    When I was looking at the current MOF 1.4 spec I could not find a place
    where is specified, which assoc. ends are navigable and which are not.
    There is an inconsistency between the UML picture of MOF metamodel and XMI
    (and IDL). Where the picture indicates that some ends (like
    RefersTo.referent) are not navigable, XMI says that they are navigable and
    also IDL contains getter method for these ends. So I guess the picture is
    wrong. This should be fixed, because it is in fact the only place where the
    users of the spec can see the navigability without looking at the
    hard-to-read XML file or generated IDL. It would be also helpful to add this
    also to the description of particular associations in section 3.5.

  • Reported: MOF 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove obsolete material

  • Key: MOF14-26
  • Legacy Issue Number: 4594
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The document needs a big revamp - e.g. a lot of the ancient pre-UML intro
    stuff. We
    should bear in mind that a lot of people will be coming to the spec/OMG
    cold as a result of JMI takeup and we should make the document as clean,
    lean
    and approachable as we can.
    It will be at least a year before MOF 2.0 reaches a stable/official state so
    I feel we should not wait.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tracking identity of replicated / interchanged metadata

  • Key: MOF14-23
  • Legacy Issue Number: 4586
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When metadata is copied from one repository to another, or saved as an
    XMI document, it can be necessary to know if the physically distinct
    copies of the metadata are logically the same or logically different.
    There need to be mechanisms for testing whether copies are logically the
    same or different that work in all cases, not just within the context of
    a single repository.

  • Reported: MOF 1.4 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity be optional for non-navigable association ends.

  • Key: MOF14-32
  • Legacy Issue Number: 4700
  • Status: open  
  • Source: International Business Machines ( Dr. Stephen Brodsky, Ph.D)
  • Summary:

    If an association end is not navigable, specification of its
    Multiplicity should not be required. There is no practical use for this
    information and it does not make sense to require information that is not
    used.

    Proposed Resolution: Make Multiplicity optional in the MOF model.

  • Reported: MOF 1.4 — Mon, 12 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF RTF Issue: typos in Reflective.idl

  • Key: MOF14-47
  • Legacy Issue Number: 3533
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    We've spotted two minor typos in the Reflective.idl in Appendix B.2 of
    the MOF 1.3 spec.

    1) The constant called "WRONG_DESIGNATOR_DESIGNMATOR_VIOLATION"
    should be renamed to "WRONG_DESIGNATOR_VIOLATION".

    [The constant is described correctly in section 5.4.6 on page 5-31]

    2) The "ref_unset_value()" operation in "RefObject" is missing
    a parameter. It should be declared as:

    void ref_unset_value(in DesignatorType feature) raises (MofError);

    [The operation is described correctly in section 6.2.3 on page 6-13]

  • Reported: MOF 1.3 — Fri, 7 Apr 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Make the changes as suggested

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

"*" not needed on DataType name

  • Key: MOF14-46
  • Legacy Issue Number: 3529
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification, section 3.4.7, says a DataType that does not
    require an IDL declaration must have a "name" that starts with a "*"
    character. This is an unnecessary restriction which has been generally
    ignored. MOF Model does not start DataType names with a "*" (see Appendix A
    XML defining any, boolean, string, and unsigned long). Similarly, the UML
    metamodel and others ignore this unnecessary restriction.

    The restriction is particularly inappropriate because it restricts
    ModelElement names based on the IDL mapping. IDL rules should not restrict
    ModelElement names, first because a Tag can be used to select an alternate
    IDL name, and second because a DataType mapped directly to a predefined IDL
    type does not cause an IDL declaration to be generated (so the DataType name
    is irrelevant to IDL generation).

    Recommendation: remove the restriction that a DataType not requiring an IDL
    declaration have a "name" starting with a "*" character.

  • Reported: MOF 1.3 — Tue, 4 Apr 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MODL Appendix needs updating

  • Key: MOF14-50
  • Legacy Issue Number: 4154
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In MOF 1.3 RTF, it was agreed (with some reluctance on my part) that the
    spelling of the model element names in the XMI version of the MOF Model
    was definitive. This means that the MODL definition of the Model package
    in the Appendix is out of date.

    In addition, DSTC has made a number of changes to the MODL language
    syntax that mean that the version in the MOF 1.3 spec no longer
    compiles.

    Finally, the URL for the specification of the MODL language is stale.

  • Reported: MOF 1.3 — Wed, 17 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Model::Contains::container return type wrong

  • Key: MOF14-49
  • Legacy Issue Number: 4133
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The "Contains" Association is defined with the "container" end having
    type "Namespace" and multiplicity [0..1]. According to the MOF to IDL
    mapping (see 5.8.10 <association_end1_name>) this means that the
    Model::Contains::container() operation should return a "NamespaceBag".

    However, the IDL in both Chapter 3 and Appendix C incorrectly declares
    Model::Contains::container() as returning a "Namespace".

  • Reported: MOF 1.3 — Fri, 12 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Can MOF Class contain a Constant?

  • Key: MOF14-45
  • Legacy Issue Number: 3528
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification shows in table 3-4 that a Class can contain a
    Constant. But constraint [C-15] ClassContainmentRules does not allow a
    Class to contain a Constant. The table and the constraint need to say the
    same thing. Since MOF's Model.ModelElement contains Constants, it is clear
    that the table is correct.

    Recommendation: add Constant to ClassContainmentRules.

  • Reported: MOF 1.3 — Tue, 4 Apr 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Change constraint [C-15] as recommended

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

MOF 1.3 Why have rule against abstract packages?

  • Key: MOF14-44
  • Legacy Issue Number: 3446
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, constraint C-44, which prevents a package
    being abstract, does not appear to serve any useful purpose. It does
    prevent definition of general, abstract metamodels that must be subclassed
    with more specific metamodels in order to be deployed. A MOF package
    defines a type of a package extent, and such types support polymorphism
    through package inheritance. The concept of abstract packages is as useful
    to metamodeling as the concept of abstract classes is to object modeling.

    Recommendation: Delete C-44.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    This is a duplicate of issue 4202. Close with no further action.

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

Operation Model::Tag::add_elements_before should not appear in the IDL

  • Key: MOF14-38
  • Legacy Issue Number: 3094
  • Status: closed  
  • Source: Object Radiance ( GK Khalsa)
  • Summary:

    The MOF specification defines the AttachesTo association as ordered on
    the Tag end (given a ModelElement, its tags are ordered). The IDL for
    for AttachesTo interface is consistent with this definition. However,
    the IDL definition of the Tag interface provides an add_elements_before
    operation, which is inconsistent with the Association definition in the
    metamodel. Presumably, that operation is included in error, and should
    be removed.

  • Reported: MOF 1.3 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Reflective IDL fix for CORBA 2.3

  • Key: MOF14-37
  • Legacy Issue Number: 2971
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The Reflective module contains the following IDL type alias:

    typedef any ValueType;

    Unfortunately, CORBA 2.3 has added a new IDL keyword "valuetype". Hence a
    CORBA 2.3 compliant compiler will give syntax errors for the Reflective IDL.

    Possible solutions include:

    1) Replace "ValueType" with "_ValueType" throughout the
    Reflective module.

    2) Change "ValueType" to another name; e.g. "CorbaValueType".

    3) Remove the typedef, and replace all instances with "any".

  • Reported: MOF 1.3 — Thu, 14 Oct 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Adopt approach 1 to minimize impact on interoperability. Flag this to be fixed properly in MOF 2.0.

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

Incorrect return type for Assoc query operation

  • Key: MOF14-42
  • Legacy Issue Number: 3379
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The description of the single ended Association query operation has
    (I think) the wrong return type for an "optional" association end.
    The operation can return either zero or one instances. This could
    be expressed as either the base type or a "bag" collection. The
    former is easier to use, and what the spec used to prescribe in MOF 1.1.
    However, the text of the template description [section 5-10-8 on page
    5-62] currently prescribes the latter.

    I think this is just a typo in MOF 1.3. However, it could be that the
    change was deliberate, and I've forgotten why we decided to make it.

    At any rate, the 1.3 mapping description now inconsistent with the IDL
    for the MOF Model in Appendix B. Examine the IDL interface for the
    "contains" Association. The "container" end has multiplicity [0..1]
    yet the "container(ModelElement)" operation returns a Namespace, not
    a NamespaceBag as the text of the mapping spec requires.

  • Reported: MOF 1.3 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    duplicate close issue

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

"*" prefix on Simple Type Names (mof-rtf)

  • Key: MOF14-41
  • Legacy Issue Number: 3133
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Based on the rule in the MOF 1.3 Specification in 3.4.7 that a DataType not
    requiring an IDL declaration must have a name starting with a "*", the
    DataType names "any", "boolean", "string", and "unsigned long" in the XML
    rendition of Model should be "*any", "*boolean", "*string", and "*unsigned
    long" respectively.

  • Reported: MOF 1.3 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    close no action

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

MOF 1.3 Incorrect attribute order in diagrams

  • Key: MOF14-43
  • Legacy Issue Number: 3444
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, the order of attributes shown in some of the
    diagrams and their descriptions is inconsistent with the order given in the
    XML and IDL. Particularly, GeneralizableElement and AssociationEnd show
    attributes out of order. The diagrams, explanative text, XML and IDL should
    all show features in the same order because order is relevant when
    determining the order of parameters passed to a create operation. A diagram
    showing attributes out of order can lead one to pass creation arguments in
    the wrong order.

    Recommendation: fix the order in the diagrams and explanations.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MofErrors for refQueryLink and refModifyLink

  • Key: MOF14-48
  • Legacy Issue Number: 3606
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The description of refQueryLink and refModifyLink in 6.2.4 does not
    record the fact that they can raise MofError(Not Navigable). See
    5.8.10 etc.

  • Reported: MOF 1.3 — Wed, 10 May 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Correct the descriptions of refQuery and refModifyLink to match the IDL mapping

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

Can MOF Package contain a Constant? (mof-rtf)

  • Key: MOF14-39
  • Legacy Issue Number: 3130
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification shows in table 3-4 that a Package can contain a
    Constant. But constraint [C-43] PackageContainmentRules does not allow a
    Package to contain a Constant. The table and the constraint need to say the
    same thing.

  • Reported: MOF 1.3 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Package Contains Association (mof-rtf)

  • Key: MOF14-40
  • Legacy Issue Number: 3131
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    There is a typo in table 3-4 of the MOF 1.3 Specification indicating that a
    Package cannot contain an Association.

  • Reported: MOF 1.3 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    This is clearly a typo in the table, which currently doesn't allow anything to contain an Associatio

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

The Metadata architecture needs to move away from the 4 levels and labels

  • Key: MOF14-10
  • Legacy Issue Number: 4111
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'.

  • Reported: MOF 1.3 — Fri, 8 Dec 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the MOF / XMI interchange format

  • Key: MOF14-9
  • Legacy Issue Number: 3897
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The MOF spec standardises an XMI-generated interchange format for MOF
    meta-models. The MOF spec includes the "input" MOF meta-model for the
    Model. It should also include a formal statement of the other XMI
    "parameters" used to generate the meta-model interchange format.

  • Reported: MOF 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete all non-MOF-specific terms from the Glossary

  • Key: MOF14-19
  • Legacy Issue Number: 4484
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Delete all non-MOF-specific terms from the Glossary. People have trouble enough with MOF terms and it's sensible to have one place to collect them all, without clogging them up with a load of irrelevant UML terms (e.g. action sequence). Plus it create a management issue of having to keep up with UML (which it has failed to already - not even including something as fundamental as 'Profile').

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add 'semantics' attribute to Operation.

  • Key: MOF14-18
  • Legacy Issue Number: 4483
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    At the moment MOF has no way to describe the behavior of an operation. A new attribute, 'semantics', String (0..1) should be added to Operation. A more sophisticated alternative would be to include a 'language' attribute also, as for Constraint. This would be somewhat restrictive in permitting only one coding of the semantics (e.g. not both OCL and Java). Better would be to use just one multivalued attribute of type StructuredDataType 'Expression'. This would be as in UML and have StructureFields 'language' (String 0..1) and 'body' (String 1..1). It begs the question as to whether this datatype should then be used in Constraint instead of the current 'language' and 'expression' attributes.

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The current MOF package level import is not sufficient

  • Key: MOF14-16
  • Legacy Issue Number: 4383
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current MOF package level import is not sufficient. For instance, if a
    user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can
    only indicate "Datatypes" in MOF now. What is needed is that the user can
    say "Datatypes::Boolean" as a dependency. It would be counter-productive to
    create 12 subpackages of Datatypes and put each datatype in its own Package,
    just because it would let people reuse individual datatypes (without
    changing the MOF import rule).

  • Reported: MOF 1.3 — Wed, 20 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF-RTF issue: AttachesTo.modelElement - ordered

  • Key: MOF14-15
  • Legacy Issue Number: 4267
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The modelElement end of AttachesTo association should be ordered. It does
    make sense to have one tag attached to several model elements in a specified
    order. (E.g. tag decorating a set of class attributes which create a unique
    identifier of instances of this class)

  • Reported: MOF 1.3 — Wed, 11 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof-rtf issue: Association Generalization

  • Key: MOF14-22
  • Legacy Issue Number: 4584
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The MOF model should allow generalization of associations. It is often
    useful to have a more general root association and create several
    specializations for it (e.g. dependency and several kinds of dependencies as
    its subclasses).

  • Reported: MOF 1.4 — Mon, 1 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modeling OCL Helper Functions

  • Key: MOF14-21
  • Legacy Issue Number: 4569
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL).

    There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine.

    This applies not only to MOF but to other metamodels.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The role name of the Namespace->ModelElement association end

  • Key: MOF14-13
  • Legacy Issue Number: 4238
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Title: The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Tue, 27 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

role is named 'containedElement' while the reference is named 'contents'

  • Key: MOF14-12
  • Legacy Issue Number: 4232
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of constraints

  • Key: MOF14-20
  • Legacy Issue Number: 4568
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3].

    The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

predefined tag for marking attributes to act as qualifier in classifier

  • Key: MOF14-11
  • Legacy Issue Number: 4231
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need a predefined tag for marking attributes that will 'act as a
    qualifier' in a classifier.
    In a metamodelling tool it may be useful to derive automatically an object
    identifier from one
    or more relevant attributes of the classifier (for instance a 'name'
    attribute).
    Note: The attribute 'acting as a qualifier' is owned by the classifier not
    by an association.
    Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to
    any attribute
    of a classifier.

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Disallow null instance values

  • Key: MOF14-17
  • Legacy Issue Number: 4419
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It can be argued that there is no need to allow null as a valid value
    for a Class instance. The possibility of null means that mapped APIs
    need to be more complicated; e.g. the IDL "unset_*" operations. This
    issue proposes that 'null' should be disallowed, making Class instances
    consistent with DataType instances. The IDL mapping could also be
    simplified.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF IDL rules to minimize network roundtrips

  • Key: MOF14-14
  • Legacy Issue Number: 4255
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Various people have complained that retrieving meta-data (typically
    features of Classes) using the IDL produced by the MOF IDL mapping
    involves too many round-trips. This is preventing people from using
    MOF generated IDL in projects. This issue calls for a solution (or
    solutions) to this problem.

  • Reported: MOF 1.3 — Fri, 6 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify whether null instances are currently valid MOF values

  • Key: MOF14-60
  • Legacy Issue Number: 4418
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The JMI expert group has identified an anomaly in the MOF spec with respect
    to null instances of Classes. According to the IDL mapping, a null
    instance is a valid value for an Attribute or a Parameter; e.g. paragraph
    2 of section 5.3.4. On the other hand, the Abstract mapping (Chapter 4)
    does not mention null at all. JMI needs to know if null is a valid value
    for a Class instance, in the general case.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

IDL mapping Tag for specifying IDL #pragma versions

  • Key: MOF14-59
  • Legacy Issue Number: 4413
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is currently no standard way to direct the MOF IDL mapping to
    output a #pragma version for a declaration. This is needed when a
    standard meta-model is changed in a way that gives IDL interfaces, etc
    with the same name but different signatures.

  • Reported: MOF 1.3 — Sat, 21 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

::Model::Package::internalize/externalize in MOF 1.4

  • Key: MOF14-58
  • Legacy Issue Number: 4396
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The Package class has two operations "internalize" and "externalize" that
    are supposed to be hooks for importing and exporting metadata. They are
    defined in MOF 1.3 with Parameters whose type is a CORBA Any and that
    represents some kind of input / output stream. This won't work in MOF
    1.4 because "Any" is not a supported data type.

  • Reported: MOF 1.3 — Thu, 5 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Move the 'verify' operation to RefBaseObject

  • Key: MOF14-57
  • Legacy Issue Number: 4384
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Meta-modelling the 'verify' Operation on Model::ModelElement is going to be
    problematical in MOF 1.4 because one of its Parameters contains a CORBA any.
    We could solve this by moving the operation onto the (IDL) RefBaseObject
    interface. This would have the additional benefit of providing an API
    for invoking constraint validation on any meta-object.

  • Reported: MOF 1.3 — Thu, 21 Jun 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Primitive data types usage in the MOF Model.

  • Key: MOF14-56
  • Legacy Issue Number: 4351
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In MOF 1.3, the Model contains references to the following primitive (IDL)
    data types: boolean, long, unsigned long, any, string and TypeCode. Some
    of these are 'typedef'd.

    In MOF 1.4, the status of the primitive types is as follows:

    boolean – required
    long – 32 bit signed integers – required (for MultiplicityType)
    unsigned long – 32 bit unsigned integers – not required
    (its use in MOF 1.3 was a typo ... )
    any – maybe required for Constant, Constraint and Tag.
    TypeCode – not required
    string – required, but see below.

    There are a couple of loose ends though:

    1) The "any" type would need to be a 5th standard PrimitiveType. It has
    been suggested that we can use a string type to represent the 'value'
    field of Constant, the 'values' field of Tag and the 'expression' field
    of Constraint. Tags and Constraints are straightforward, but using
    a string to represent a Constant value would entail defining standard
    concrete (string) syntaxes for the kinds of values allowed for Constants.

    Proposal: Replace all occurrences of 'any' in the MOF Model with a 16 bit
    UTF string type.

    Proposal: Adopt the IDL syntax for integer, floating point and wide string
    literals with minor modifications as required. (It would be a good idea
    to use an encoding that works with 8 bit character sets ... )

    2) In MOF 1.3, "string" is used for various things such as NameType,
    AnnotationType, DependencyKind and FormatType along with the type
    of 'tagId'. Note that this is an 8 bit string type. Apparently
    this causes problems for some meta-modellers. At any rate, now
    would be a good time to start supporting international character
    sets in meta-models.

    Proposal: Change all 'string' types in the MOF Model to a 16 bit UTF
    string type.

    Proposal: Remove all cosmetic typedefs.

  • Reported: MOF 1.3 — Tue, 19 Jun 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Error in MOF 1.3 XMI - ViolationType

  • Key: MOF14-55
  • Legacy Issue Number: 4313
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The XMI document for MOF 1.3 gets the type of the 'values_in_error'
    field of 'ViolationType' wrong. It says that the type is an IDL
    interface type called ::Reflective::NamedObjectList. In fact the
    type's name is ::Reflective::NamedValueList, and it is a typedef
    of a sequence of a struct ... not an interface.

  • Reported: MOF 1.3 — Fri, 18 May 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    No Data Available

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

predefined tag for marking attributes needed

  • Key: MOF14-53
  • Legacy Issue Number: 4237
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need a predefined tag for marking attributes that will 'act as a
    qualifier' in a classifier.
    In a metamodelling tool it may be useful to derive automatically an object
    identifier from one
    or more relevant attributes of the classifier (for instance a 'name'
    attribute).
    Note: The attribute 'acting as a qualifier' is owned by the classifier not
    by an association.
    Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to
    any attribute
    of a classifier.

  • Reported: MOF 1.3 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    close, no action

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

MOF IDL change

  • Key: MOF14-52
  • Legacy Issue Number: 4211
  • Status: closed  
  • Source: ETA Sistemi Srl ( Davide Mora)
  • Summary:

    i suggest to change the IDL from:

    typedef any ValueType; typedef sequence < ValueType > ValueTypeList;

    to:

    typedef any AnyType; typedef sequence < AnyType > AnyTypeList;

    because "valuetype" it's a reserved word for the newest versions of IDL and cause an error.

    There is also "strange character" in the following const:

    const string INVALID_DELETION_VIOLATION = (character)org.omg.mof:reflective.invalid_deletion(character);

    the "(character)" have to be replaced with '"'.

    I suggest also to split the .txt in 2 files .idl, or explain in the download page how the .txt have to be splitted.

  • Reported: MOF 1.3 — Mon, 26 Feb 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MofError when Operation impl violates structural constraints

  • Key: MOF14-54
  • Legacy Issue Number: 4295
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The description of the behaviour of an Operation does not say what ought
    to happen if an Operation's implementation returns parameters or results
    that violate multiplicity constraints. Similarly, for Exception parameters.
    This affects sections 5.8.13 and 6.2.3 ("refInvokeOperation").

  • Reported: MOF 1.3 — Tue, 8 May 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MOF Unbounded should have type long

  • Key: MOF14-51
  • Legacy Issue Number: 4175
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification defines the constant UNBOUNDED
    like this:

    const unsigned long UNBOUNDED = -1;

    The type should be long, not unsigned long. The value is used
    for MultiplicityType.upper which has type long. Also, the
    constant has a signed value.

  • Reported: MOF 1.3 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    The IDL clearly contains a typo. Fix it so that UNBOUNDED is signed

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

MOF 1.3 Why prevent nonpublic Associations?

  • Key: MOF14-5
  • Legacy Issue Number: 3447
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, constraint C-37 requires Associations to be
    public. Support for nonpublic Associations is a valuable capability that
    should not be forbidden. In particular, when there are references on all
    navigable ends of an Association, the M1 Association object is fully
    redundant in the capabilities it provides. Making the Association private
    or protected eliminates the need to support redundant public interfaces for
    capabilities available most conveniently through references. The
    association is an important part of the model in that it defines the
    semantics and behavior of the references, but no public Association
    interface is needed. The IDL and other interfaces generated from metamodels
    is already too large. Constraint C-37 simply makes it larger than it needs
    to be.

    Note that the CWM submitters to OMG desire to use nonpublic associations
    extensively in CWM's 26 metamodels.

    Recommendation: Delete C-37.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 IDL template for clustering uses wrong name

  • Key: MOF14-4
  • Legacy Issue Number: 3445
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 specification, section 5.8.4, the use of
    "<clustered_package_name>_ref" (both in the template and as a subheading) is
    incorrect. It should be "<import_name>_ref". The Import name provides the
    alias for a clustered package within a clustering package. The Package name
    is used to identify the type of the M1 package object, not the IDL attribute
    name.

    Recommendation: change "<clustered_package_name>_ref" to
    "<import_name>_ref".

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Template should suppress add for [x..x] Attributes

  • Key: MOF14-2
  • Legacy Issue Number: 3112
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The Attribute template suppresses the "remove" operations for multi-valued
    Attributes whose lower and upper bounds are the same. [This makes sense
    because removing an element would always trigger an underflow error.] However,
    similar logic has not been applied to the "add" operation. We should consider
    suppressing "add" operations for multi-valued Attributes whose lower and upper
    bounds are the same, since the operation must always trigger an overflow error
    in this case.

  • Reported: MOF 1.3 — Mon, 13 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF and IDL repository ids

  • Key: MOF14-1
  • Legacy Issue Number: 3043
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The AB is insisting that altered IDL types (including types that reference
    > altered IDL types) be versioned by specifying a new repository id. This
    > presents special issues for generated IDL when a source model is revised
    > and the IDL regenerated.
    >
    > Recommendation
    >
    > For generated IDL the safest thing is probably to generate a new UUID-based
    > repository id for all generated IDL interfaces and generated IDL structs,
    > valuetypes, etc.

  • Reported: MOF 1.3 — Sat, 20 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reflective interface for Package factory

  • Key: MOF14-8
  • Legacy Issue Number: 3745
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is no reflective version of the Package factory interface. In
    retrospect, an abstract interface would be useful for generic package
    creation using Package specific factory objects, and a concrete interface
    would be useful for a "universal" Package factory object.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor changes to some Reflective operations

  • Key: MOF14-7
  • Legacy Issue Number: 3744
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The RefAssociation ops that are parameterised by Link would be easier to
    use if parameterized by two RefObjects. The RefObject ops for
    add/modify/removing
    ele,emts of Attribute/Reference collections should be renamed; i.e. add_value
    becomes add_member. Other minor tweaks would make the interfaces easier to
    use.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF specifies no interfaces for actually (de-)serializing a model

  • Key: MOF14-3
  • Legacy Issue Number: 3411
  • Status: open  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    MOF specifies no interfaces for actually (de-)serializing a model (to, for example, a XMI stream). Without such an interface it is not possible to guarantee that 2 XMI tools/repositories can communicate with each other, regardless of how completely they support MOF/XMI. Since the OMG is meant to be about interoperability this is a critical omission.
    It would make sense for MOF to make use of the Streamable interface defined as part of the Externalization service.
    And for the capability to be defined against Namespace to allow reasonable flexibility of granularity.
    Obviously XMI is only one possible format for the stream: the XMI specification should also be extended to fit into the detailed specification adopted for streaming MOF-compliant metamodels.

  • Reported: MOF 1.3 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Package should subtype Classifier

  • Key: MOF14-6
  • Legacy Issue Number: 3448
  • Status: open  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, a Package is not a subtype of Classifier. But
    an M2 package does have M1 instances (package extent objects), and the M2
    Package defines the type of those M1 objects. Therefore, a Package really
    is a Classifier. It is a type. It can be thought of as a component type,
    and in that sense a Package should be able to contain behavioral features.
    Also, an attribute type that is a Package should be treated as a pointer to
    a package extent object.

    Recommendation: make Package a subtype of Classifier, or fold Classifier
    into GeneralizableElement.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Editorial issue(s)

  • Key: MOF2I2-39
  • Legacy Issue Number: 9170
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The grammatical errors in the document should be corrected. Also review comments were taken into account and can now be deleted from the final document.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Resolution of issue 9154 does not work for primitives

  • Key: MOF2I2-40
  • Legacy Issue Number: 9175
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The resolution of issue 9154 cannot work for primitive types, since all of
    the operations in the reflective interfaces are typed to MOFObject (and
    primitive types are no MOFObjects).

    Discussion:
    This problem was already known and mentioned by Pete Rivett during the
    ballot 2 vote. However - unfortunately - the wrong text went into the
    resolution due to a misunderstanding. This resolution resolves this bug,
    which otherwise would definitely restrict the implementability of the spec.

  • Reported: MOF2I 2.0b1 — Thu, 24 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Semantic of reflective operations should match MOF2.0 Core

  • Key: MOF2I2-35
  • Legacy Issue Number: 9166
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Most of the reflective operations as well as the derived operations in section 7.6 need to refer to the computational semantic defined in MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align reflective argument passing in EMOF to CMOF

  • Key: MOF2I2-34
  • Legacy Issue Number: 9165
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Just as in CMOF, a RefArgument class should be introduced in EMOF in order to handle reflective argument passing the better way.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Mapping of subsetted properties do not need to change name of operation

  • Key: MOF2I2-38
  • Legacy Issue Number: 9169
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The mapping of subsetted properties does not have to change the name of the generated operations for this property. Only the implemented semantic should changed and reflect that of MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align mapping of tags to MOF2.0

  • Key: MOF2I2-37
  • Legacy Issue Number: 9168
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The mapping of tags should state explicitly where the information modeled in a tag lands in the mapped IDL

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

"set" operation for derived attributes

  • Key: MOF2I2-36
  • Legacy Issue Number: 9167
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    This issue is a follow up of issue 7591. For UML2 compliance, a "set" operation is needed for derived attributes.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

RefObject::ref_get (PropertyName) specified on page 67

  • Key: MOF2I2-33
  • Legacy Issue Number: 9164
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Title: Arguments to ref_get, ref_set and ref_is_set operations do not match with MOF2.0 Reflection specification.
    Source:
    Michael Soden, soden@ikv.de
    Summary:
    The RefObject::ref_get (PropertyName) specified on page 67 does not conform to the get(Property) defined in MOF2.0 Reflection.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align Base-IDL Reflection Mapping to MOF2.0 Core

  • Key: MOF2I2-32
  • Legacy Issue Number: 9163
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Rule (46) states that a factory interface is created for each package. A factory should be created only for the root package, just as home interfaces are created only for root package components.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align CCM Reflection Mapping to MOF2.0 Core

  • Key: MOF2I2-31
  • Legacy Issue Number: 9162
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    I suggest the introduction of a RefCCMPackage for CCMreflection Mapping. It is more natural and intuitive for package components to provide RefCCMPackage facets rather than RefCCMBaseObject. The RefCCMPackage should inherit from the RefCCMBaseObject. This could also ease the migration of reflective clients from CCM to Base-IDL Repository
    Moreover rule (42) and example (10) use the word support to describe the relationship between concrete home interfaces and RefCCMHome. A home rather inherits from another home.
    Section 8.3.2 uses a RefComponent type not explained anywhere. This should be RefCCMObject, since this guarantees that the concrete object in it is a component.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

RefCCMBaseObject and RefBaseObject

  • Key: MOF2I2-30
  • Legacy Issue Number: 9160
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    RefCCMBaseObject and RefBaseObject should contain a ref_get_label() operation.
    Source:
    Michael Soden, soden@ikv.de
    Summary:
    Unfortunately the MOF2.0 Core like MOF1.4 fails explicitly model a property as the label of an instance of a class. It provides the isID flag but this cannot always be used to display class instances reflectively. For example, when modeling a "Library", a "Book" would have a "bookID" and "title". While the "bookID" may be flagged with isID=true, this may not be user friendly for a reflective client displaying a book.
    Therefore I suggest the introduction of a ref_label() operation in the RefCCMBaseObject and RefBaseObject interfaces as well as a standard optional Tag whose value should denote the property to use as a label. The modeler can attach such a tag to a class so that the ref_label() method can be implemented accordingly in the class' derived interface.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    closed no chage

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

Clarify the Extents concept in the mapping

  • Key: MOF2I2-29
  • Legacy Issue Number: 9159
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The Note in Section 7.1 on Extents deferred the clarification of the concept and mapping of extents to the FTF of the finalization process. We need some clarifications here.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (50) is not applied in example (12).

  • Key: MOF2I2-28
  • Legacy Issue Number: 9158
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The interface declarations for A, B and C in example (12) on page 35 do not contain the operations derived according to rule (50).

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Some referenced sections do not exist

  • Key: MOF2I2-27
  • Legacy Issue Number: 9157
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Rule (46) on page 33 references section 8.2.5 which does not exist in the document.
    Rule (40) on page 30 references section 8.3.6 which does not exist in the document.
    The "Semantics" of the MOFObject::get_mof_id operation on page 45 references section 9.1 which does not exist in the document.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Numbering and references to examples are not consistent

  • Key: MOF2I2-26
  • Legacy Issue Number: 9156
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Example 8 is missing and example 10 references example 10 rather than example 4.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Remove the Common suffix from the interface names in the common mapping

  • Key: MOF2I2-23
  • Legacy Issue Number: 9153
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Since clients will in most cases deal directly with the abstract interfaces from the common mapping, it is more natural to name these interfaces using format_1(<class name>). As a consequence, we need to rename the Base-IDL and Component identifiers by adding a suffix.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Example 4 is not totally consistent with rules (35) and (36).

  • Key: MOF2I2-25
  • Legacy Issue Number: 9155
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Example 4 on page 26 still contains the create_<component_name> factory operation which is no more generated according to issue 7682.
    Moreover, the factory operation create_and_init_b(in long a_attrib, in ACommon b_attrib); in the home declaration home BHome manages B, the a_attrib parameter is not needed.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align Handling of Collections to MOF2.0 Core

  • Key: MOF2I2-24
  • Legacy Issue Number: 9154
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The handling of collections is not aligned to MOF2.0 Core reflection. Although extensions may be available specific for IDL, the standard operations and interfaces must conform to the MOF2.0 collection handling. Therefore, we introduce corresponding ReflectiveCollection and ReflectiveSequence interfaces with the same operations. In turn all type specific iterators are dropped and replaced by generic reflective interfaces. However, we would like to keep the iterator interfaces as an IDL extension for convenience

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Subsection 6.2.1 (Mapping of Identifiers) should be independent of MOF1.4

  • Key: MOF2I2-20
  • Legacy Issue Number: 9150
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    In subsection 6.2.1 the current specification ptc/05-03-05 makes references to the MOF1.4 Specification, ptc/01-10-04 forcing the reader to refer to that document. I think the specification should rather just mention that mapping of identifiers has been carried over from MOF1.4 and outline the mapping rules in detail here again.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Not all assumptions of MOF2.0 Core do hold

  • Key: MOF2I2-19
  • Legacy Issue Number: 9149
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification ptc/05-03-05 makes assumptions of the MOF2.0 Core specification which do not longer holder in ptc/04-10-15. It would be better to refer to the applicable MOF2.0 Core specification and only add text or diagrams that help to clarify some unobvious concepts in MOF2.0 Core.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Align MOFObject to MOF2.0 Core

  • Key: MOF2I2-22
  • Legacy Issue Number: 9152
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The Object metaclass defines the base for all classes in a MOF metamodel. The same role is played by the MOFObject interface which was introduced to have a common base type in IDL for all kinds of derived interfaces. The is_equals() operation in the MOFObject interface should be renamed to equals() to match the equals operation in MOF2.0.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

specification should throughout be discretely divided into EMOF and CMOF

  • Key: MOF2I2-21
  • Legacy Issue Number: 9151
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Since there are two compliance points, EMOF and CMOF, and the mapping is divided into Common, CCM and Base-IDL mapping, the sections and subsections in the document should discretely reflect this consistently.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

References to other specification documents are not up to date

  • Key: MOF2I2-18
  • Legacy Issue Number: 9148
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    Throughout the current specification ptc/05-03-05, references are made to other specifications which are not up to date. References to submission documents should be updated to their respective adopted documents and the affected sections should be corrected too. The specification should avoid making references directly to UML Specifications but rather to the MOF2.0 Core specification which in turn makes the appropriate references to UML.

  • Reported: MOF2I 2.0b1 — Tue, 15 Nov 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

CMOF::Exception class is no longer in MOF2.0

  • Key: MOF2I2-17
  • Legacy Issue Number: 8505
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification assumes the existence of a CMOF::Exception class
    which was in the MOF2.0 Core submission document but removed during
    finalization. Rule (23) on page 21 still refers to this class.

  • Reported: MOF2I 2.0b1 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Remove FTF comments

  • Key: MOF2I2-16
  • Legacy Issue Number: 8504
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Michael Soden)
  • Summary:

    The current specification document ptc/04-07-01 still contains the
    submission notes for the FTF provided as guidance by the submitters. We need
    to remove them from the specification document.

  • Reported: MOF2I 2.0b1 — Mon, 7 Mar 2005 05:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

factory create_ ();

  • Key: MOF2I2-15
  • Legacy Issue Number: 7755
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The first factory operation described for homes

    factory create_<component_name> ();

    has the same signature as the create() method generated from
    the 'implied IDL' *HomeImplicit interface. The implied IDL
    *Home interface inherits from *HomeImplicit, so it seems
    we already have an operation in the equivalent home interface
    that is doing the same thing as the declared factory operation.

  • Reported: MOF2I 2.0b1 — Tue, 31 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (38) p. 30

  • Key: MOF2I2-14
  • Legacy Issue Number: 7754
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The CCM component mapping for an Association has the suffix
    "Component", unlike any of the the other component mappings
    in the document. That's a little puzzling. Also, no details
    are given about the corresponding home mapping. How is its
    type name derived? Does it have the same factory operations as
    the other CCM home mappings in the document?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (38):

  • Key: MOF2I2-8
  • Legacy Issue Number: 7681
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The CCM mapping for an Association specifies the
    suffix "Component" for the derived component.
    None of the other derived components in the CCM
    mapping have this suffix, and it also disagrees
    with some example IDL in the document.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (26) p. 21

  • Key: MOF2I2-10
  • Legacy Issue Number: 7750
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Although I see the member types for the *Link struct
    specified, I don't see anything about the member names.
    Are they specified somewhere else? How are they to be
    derived?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (35):

  • Key: MOF2I2-9
  • Legacy Issue Number: 7682
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The home factory operation 'create_<class identifier>'
    has the same signature as the 'create' operation
    defined by the CCM spec in the implied-IDL
    <class identifier>HomeImplicit interface, and for
    this reason it seems redundant.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Section 7.4 pp. 49,50

  • Key: MOF2I2-13
  • Legacy Issue Number: 7753
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The type of MofError::error_kind and MofERror::error_description
    (section 6.2.10 p. 20 & section 7.4 p. 50) are both wstring,
    but there is also a list of IDL string constants (section 7.4
    p. 49). How are the constants to be used? Are they to be passed
    as one of MofError's wstring members? If so, how come the type
    mismatch?

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Section 7.6.3 pp. 59,60

  • Key: MOF2I2-12
  • Legacy Issue Number: 7752
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    With regard to the operations 'create_link_in_<association_name>'
    and 'remove_link', the Exception paragraphs contain information
    only about the case where association ends are defined as
    derived unions. It's not clear what the behavior is otherwise.

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (27) p. 21

  • Key: MOF2I2-11
  • Legacy Issue Number: 7751
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Same as above, for members of the valuetype *State,
    mapped from an Association

  • Reported: MOF2I 2.0b1 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Section 7.4;

  • Key: MOF2I2-7
  • Legacy Issue Number: 7680
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    MofError's error_kind and error_description
    members are wstrings, yet the string constants
    defined in this section (and which are I
    assume intended for use as values for one or
    both of these members) are strings.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Section 7.6.3

  • Key: MOF2I2-6
  • Legacy Issue Number: 7679
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The wording causes confusion about what the exception
    behavior is if the association ends are not derived
    unions

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Section: 8.2.2;8.2.6

  • Key: MOF2I2-3
  • Legacy Issue Number: 7653
  • Status: closed  
  • Source: Humboldt-Universitaet ( Mario Winkler)
  • Summary:

    In Rule (9) it is stated that the created valuetype which inherits from the abstract valuetype MOFState is truncatable. But according to the CORBA Specification it is not allowed to declare a valuetype as truncatable if it is derived from an abstract valuetype. The base type has to be non-abstract.

  • Reported: MOF2I 2.0b1 — Wed, 1 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (27)

  • Key: MOF2I2-5
  • Legacy Issue Number: 7678
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I assume that the identifiers for the members of
    the <association_name>State valuetype will be the
    type name in format_2, but it should probably be
    stated explicitly

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

Rule (26):

  • Key: MOF2I2-4
  • Legacy Issue Number: 7677
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I assume the <association_name>Link struct member
    names will be in correspoding format_2, but it
    should probably be stated explicitly.

  • Reported: MOF2I 2.0b1 — Mon, 6 Sep 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

section 6.3.3, p.31, example IDL

  • Key: MOF2I2-2
  • Legacy Issue Number: 7640
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    section 6.3.3, p.31, example IDL
    The operations shown in the example for mapping of
    associations don't seem to gibe with the operations
    described section 7.6.3, pp.59-61.

    The CCM version of the mapping has components supporting abstract
    interfaces. There is some discussion where I work about whether
    or not this will have dire consequences. Such a case was throwing
    an error in our IDL compiler - someone must have thought it was
    a no-no. For the record, it seems ok to me for components to do
    this, but I wanted to get some more input on the matter. I guess
    it boils down to the question of whether it would ever be
    necessary to narrow to a component's supported interface, or to
    pass one over the wire as a CORBA::Object.

  • Reported: MOF2I 2.0b1 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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

section 7.3, p.44, example IDL

  • Key: MOF2I2-1
  • Legacy Issue Number: 7639
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    forward declared exception (MofError)

    For now I have instead forward declared MOFObject so I can
    fully define MofError before the full definition of MOFObject.

    abstract valuetype (MOFState) has a state member

    For now I have removed the 'abstract' qualifier.

  • Reported: MOF2I 2.0b1 — Thu, 19 Aug 2004 04:00 GMT
  • Disposition: Resolved — MOF2I 2.0
  • Disposition Summary:

    No Data Available

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