OMG Specification

Meta Object Facility — All Issues

Acronym: MOF
Issues Count: 330
Description: All Issues

Issues Summary

Key	Issue	Reported	Fixed	Disposition	Status
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
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-59	no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema	XMI 2.0	MOF 2.0	Transfered	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
MOF24-44	Rule 1 references 2:ContentElements which is undefined	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-43	Rule 4i in 5.2 has the following with only 2 options	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-46	Use of "xmi:" and //xmiPrefix// is inconsistent.	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-45	1b has been deleted, but it is still referenced from 2g, 2l and 3	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-48	When 2n is used with 2j it is supposed to match the last part of schema production	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-47	There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-50	The example in Issue 9645 doesn't seem like a particularly good one	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-49	There was an error in the example in Issue 9626	XMI 2.4	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
MOF24-42	Relations	UML 2.0	MOF 2.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
MOF24-53	MOF 2.4 references missing	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-52	Issue 9673 contained "file:Co.xml" which is an invalid absolute URI	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-51	Resolution text to issue 9650 not consistent	XMI 2.4	MOF 2.4	Resolved	closed
MOF24-54	The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense	XMI 2.4	MOF 2.4	Resolved	closed
MOFM2T-7	In chapter '7 Overview':	MOFM2T 1.0b1	MOFM2T 1.0	Resolved	closed
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-36	Collections of imported DataTypes can cause name clashes	MOF 1.3	MOF 1.4	Resolved	closed
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-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
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

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

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

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

Key: MOF24-59
Legacy Issue Number: 7605
Status: closed
Source: ISIS ( Matt Emerson)
Summary:
There is no documented standard serializiation of MOF 1.4 as an XMI 2.0 schema. OMG has published a document for MOF 1.3 as an XMI 2.0 document and MOF 1.4 and an XMI 1.2 DTD, but not MOF 1.4 as an XMI 2.0 schema. This is despite the fact that XMI 2.0 was designed around MOF 1.4. As far as I know, OMG has not released a single full XMI 2.0 schema example. Do any exist?
Reported: XMI 2.0 — Tue, 27 Jul 2004 04:00 GMT
Disposition: Transfered — MOF 2.0
Disposition Summary:
This is requesting that an XMI-compliant XML Schema be provided for MOF itself, as an example of a metamodel. This is an issue for MOF not XMI.

Revised Text:
- none -
Disposition: Transferred to MOF RTF
Updated: Sun, 8 Mar 2015 15:36 GMT

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

Key: MOFM2T11-20
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

Rule 1 references 2:ContentElements which is undefined

Key: MOF24-44
Legacy Issue Number: 15609
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
This is intended to represent arbitrary XML elements which might be unrelated to XMI.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Use a comment rather than a numbered clause
Updated: Fri, 6 Mar 2015 20:58 GMT

Rule 4i in 5.2 has the following with only 2 options

Key: MOF24-43
Legacy Issue Number: 15454
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
2. Rule 4i in 5.2 has the following with only 2 options:

("type=’xsd:IDREFS’ use=’optional’/>"

"type=’xsd:IDREF’ use=’required’/>"

Why not separate the use from the type and allow all 4 combinations e.g. for an optional single-valued attribute? Or a required multivalued one?
Reported: XMI 2.4 — Wed, 8 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Allow all 4 options
Updated: Fri, 6 Mar 2015 20:58 GMT

Use of "xmi:" and //xmiPrefix// is inconsistent.

Key: MOF24-46
Legacy Issue Number: 15611
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Use of "xmi:" and //xmiPrefix// is inconsistent. 2e and 2f use the latter

even though 1f clearly specifies that xmi is the prefix. "xmi:" should

be used directly in 2e and 2f.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
resolved
Updated: Fri, 6 Mar 2015 20:58 GMT

1b has been deleted, but it is still referenced from 2g, 2l and 3

Key: MOF24-45
Legacy Issue Number: 15610
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
1b has been deleted, but it is still referenced from 2g, 2l and 3. I think

those should actually be:

2g:TypeAttribute ::= "xmi:type='" 2k:QName "'"

2l:LinkAttribute ::= "xmi:idref='" //refId// "'" | 2m:Link

3:Extension ::= "<xmi:extension xmi:type='xmi:Extension'"

(" extension='" // extender // "'")?

(" extenderID='" // extenderID // "'")?

">"

// Extension elements //

"</xmi:extension>"
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Take the recommendation from the issue which corrects the resolution of issue 8438.
Updated: Fri, 6 Mar 2015 20:58 GMT

When 2n is used with 2j it is supposed to match the last part of schema production

Key: MOF24-48
Legacy Issue Number: 15614
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
When 2n is used with 2j it is supposed to match the last part of schema production

rule 4i:

(Qname ? "type='xsd:anyURI' use='optional'/>"))

Is that even valid XML schema? It only allows a single anyURI so 2j

doesn't comply with it. However the description of 4i doesn't mention

it, nor does section 4.8.5 - Reference representation.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Issue 15453 identifies the same problem and removes the option to use a URI in 2j.

Revised Text:
Actions taken:
September 21, 2010: received issue
Proposed Disposition: Duplicate of 15453
Updated: Fri, 6 Mar 2015 20:58 GMT

There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*

Key: MOF24-47
Legacy Issue Number: 15612
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
There is a missing colon in 2d. The last line should be (2h:FeatureAttrib)*
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
As per the issue
Updated: Fri, 6 Mar 2015 20:58 GMT

The example in Issue 9645 doesn't seem like a particularly good one

Key: MOF24-50
Legacy Issue Number: 15617
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
The example in Issue 9645 doesn't seem like a particularly good one. I would expect the URI for UseCase to be something like:

http://www.omg.org/spec/UML/20100901/uml.xml#UseCase
Reported: XMI 2.4 — Wed, 6 Oct 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Make the fix suggested in the issue
Updated: Fri, 6 Mar 2015 20:58 GMT

There was an error in the example in Issue 9626

Key: MOF24-49
Legacy Issue Number: 15616
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
There was an error in the example in Issue 9626:

Operation is a subclass of Element, not ModelElement. ModelElements no longer exist.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Make the fix suggested in the 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

Relations

Key: MOF24-42
Legacy Issue Number: 8751
Status: closed
Source: gmx.net ( Markus Brigl)
Summary:
All relations should be descended somehow from Relation, or DirectedRelation if that applies. Then all the diagrams could be traversed with the DirectedRelationship API as generic graphs. For example, the arcs on behavioral models should be descended from directed relations.
Reported: UML 2.0 — Sun, 1 May 2005 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
It is not clear that all connections between elements in the UML2 model are a kind of Relationship or DirectedRelationship. A better way to achieve generic traversal is to use MOF reflection to navigate metaclass containment associations. Tools would be free to merge MOF2 Reflection into UML2 compliance levels to provide this capability. If this change were to be made it could have a significant impact on existing implementations and, therefore, is outside the scope of an RTF

Disposition: Closed, no change
Updated: Fri, 6 Mar 2015 20:58 GMT

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

MOF 2.4 references missing

Key: MOF24-53
Legacy Issue Number: 15620
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
The version of MOF serialized is referenced in the Scope, Section1 - but should also be in Normative References. Both need updating to reference MOF 2.4.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Add the reference in Normative References, but avoid duplicating it in Scope. Also re-introduce useful text for the Scope, based on wording from the XMI 1.3 formal document
Updated: Fri, 6 Mar 2015 20:58 GMT

Issue 9673 contained "file:Co.xml" which is an invalid absolute URI

Key: MOF24-52
Legacy Issue Number: 15619
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
Issue 9673 contained "file:Co.xml" which is an invalid absolute URI as it doesn't contain the appropriate initial slashes.

(See section 5.2 of http://www.ietf.org/rfc/rfc2396.txt part (3) for a comment on why relative URIs with a scheme aren't correct.) [PJR] OK
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Remove the file: from the example.
Updated: Fri, 6 Mar 2015 20:58 GMT

Resolution text to issue 9650 not consistent

Key: MOF24-51
Legacy Issue Number: 15618
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
The resolution to Issue 9650 is supposed to be removing all traces of xmi:version. However, the final replacement paragraph contains the text "The xmi:version attribute is used to denote the start of XMI information"

which clearly is not consistent with that aim.

The resolution should also mention updates to the XMI document production rules 1c and 1d.
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Correct the inadvertent retention of the original text mentioning xmi:versio and remove production rules 1c and 1d completely
Updated: Fri, 6 Mar 2015 20:58 GMT

The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense

Key: MOF24-54
Legacy Issue Number: 15621
Status: closed
Source: Adaptive ( Mr. Pete Rivett)
Summary:
The replacement text from Issue 15307 for "If true, serialize...is as follows:" doesn't makes sense within the context of table 4.1 as it doesn't proceed to give an ordering. It only makes sense within the revised text section of the resolution itself.

The text from the following addition to 5.2.1 needs to be included or reference made to it
Reported: XMI 2.4 — Tue, 21 Sep 2010 04:00 GMT
Disposition: Resolved — MOF 2.4
Disposition Summary:
Make the fix
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

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

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

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

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

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

Issues Summary

Issues Descriptions

In Clause 10, the base URL is misspelled

References to, and explanation of Usage for Turtle and QVT

Phrase owl:allValuesFrom garbled

Insert missing word

Improve Formatting and Correct Captions

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

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

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

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

Resolve MOF 2 PAS National Body Ballot Comments

Annex C page 77

Section 15.3 page 55

Subpart V Annexes page 71

Section 16 page 67

Section 15.8 page 62

Annex B page 75

Annex A page 73

Section 15.8 page 62

Section 15.4 page 58

Section 14.5.2 page 53, Note

Section 14.5 page 53

Section 14.1 page 49, Figure 14-1

Subpart IV: Abstract Semantics page 47

Section 13.7 page 45, Paragraph Changes from MOF 1.4

Section 14.3 page 50

Section 14.2 page 49

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

Section 13.6 page 45, Paragraph Changes from MOF 1.4

Section 13.3 page 43, Paragraph Semantics

Section 13.2 page 43, Paragraph Changes from MOF 1.4

Section 13.2 page 43, Paragraph Semantics

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

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

Section 13.5 page 44, Paragraph Changes from MOF 1.4

Section 13.4 page 44, Paragraph Changes from MOF 1.4

Section 13.3 page 43, Paragraph Changes from MOF 1.4

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

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

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

Subpart II The MOF Model General Page 29

Section 11.1, Page 27

Section 12.1, Page 31, 2nd Paragraph

Section 12.1 Page 31

Subpart II The MOF Model, Page 29

Sections 10.5, 10.6 Page 23, 24

Section 10, Page 23, Figure 10-1

Section 10, Page 23

Section 10.3, page 23, paragraph Changes from MOF 1.4

Section 10.1 page 21

Section 9.3, page 18, paragraph Changes from MOF 1.4

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

Section 10.2 Page 22, Paragraph Changes from MOF 1.4

Section 9.2: Page 17, Paragraph Changes from MOF 1.4

Section 9.1, page 15, Figure 9-1

Figure 9-1

Section 9 Reflection: add sentences for Common package

Section 10.1 page 21, figure 10-1

Subpart II Capabilities General (PP.13)

Setion 8.4 Change from MOF1.4

Section 8: explain all terms for language formalism

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

Section 7: Designate the precise version of the referred standards

Section 8: Delete 81. General". It is also a Hanging Paragraph

Section 7.4 Reuse of Common packages

Clause 7 and sbuclause7.1 forms a Hanging Paragraph

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

Section 4 terms & Definitions: Nothing defined

delete subtitle General Information.

Section 6 subpart 1:

Section 6.4 Clause Acknowledgements is informative - move to an informative ANNEX

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

Section 6: Clause Additional Information is not needed

Section 6.4: delete last line

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

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

Section 2 Conformance: Definition of conformance is insufficient

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

The style of Reference should conform to the JTC1 style.

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

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

Clause 7 and sbuclause7.1 forms a Hanging Paragraph

delete subtitle General Information.

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

Section 6: Clause Additional Information is not needed

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

Section 8.5, Subpart II

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

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