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

MOF 1.4 RTF — All Issues

  • Key: MOF14
  • Issues Count: 169
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF14-169 Abstract package MOF 1.3 MOF 1.4 Duplicate or Merged 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-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-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-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-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-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-141 Inconsistent multiplicity for TypeAlias 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-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-135 Description of with_ operations 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-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-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-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-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-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-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-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-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-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-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-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-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-92 External Types as DataTypes Limits Modeling MOF 1.2 MOF 1.3 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-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-85 Specify behaviour of RefObject.is_instance_of(null,...) MOF 1.2 MOF 1.4 Resolved closed
MOF14-84 Data types available to metamodels is restricted MOF 1.2 MOF 1.4 Resolved closed
MOF14-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-54 MofError when Operation impl violates structural constraints 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-51 MOF Unbounded should have type long 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-48 MofErrors for refQueryLink and refModifyLink 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-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-43 MOF 1.3 Incorrect attribute order in diagrams 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-40 Package Contains Association (mof-rtf) 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-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-36 Collections of imported DataTypes can cause name clashes MOF 1.3 MOF 1.4 Resolved closed
MOF14-35 "exposedEnd" for any of the references in the MOF metamodel. MOF 1.4 open
MOF14-34 Association Generalization Proposal MOF 1.4 open
MOF14-33 Unnecessary constraint on import by nested packages MOF 1.4 open
MOF14-32 Multiplicity be optional for non-navigable association ends. MOF 1.4 open
MOF14-31 Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong MOF 1.4 open
MOF14-30 Restrictions needed for nested Packages and Classes MOF 1.4 open
MOF14-29 Navigability of assoc. ends in MOF model MOF 1.4 open
MOF14-28 Looking up metaobject using MOFID MOF 1.4 open
MOF14-27 resolveQualifiedName operation MOF 1.4 open
MOF14-26 Remove obsolete material MOF 1.4 open
MOF14-25 Deprecate object inheritance of class proxy interface MOF 1.4 open
MOF14-24 Alignment of reflective interfaces with JMI MOF 1.4 open
MOF14-23 Tracking identity of replicated / interchanged metadata MOF 1.4 open
MOF14-22 mof-rtf issue: Association Generalization MOF 1.4 open
MOF14-21 Modeling OCL Helper Functions MOF 1.4 open
MOF14-20 Representation of constraints MOF 1.4 open
MOF14-19 Delete all non-MOF-specific terms from the Glossary MOF 1.3 open
MOF14-18 Add 'semantics' attribute to Operation. MOF 1.3 open
MOF14-17 Disallow null instance values MOF 1.3 open
MOF14-16 The current MOF package level import is not sufficient MOF 1.3 open
MOF14-15 MOF-RTF issue: AttachesTo.modelElement - ordered MOF 1.3 open
MOF14-14 MOF IDL rules to minimize network roundtrips MOF 1.3 open
MOF14-13 The role name of the Namespace->ModelElement association end MOF 1.3 open
MOF14-12 role is named 'containedElement' while the reference is named 'contents' MOF 1.3 open
MOF14-11 predefined tag for marking attributes to act as qualifier in classifier MOF 1.3 open
MOF14-10 The Metadata architecture needs to move away from the 4 levels and labels MOF 1.3 open
MOF14-9 Specify XMI parameters for the MOF / XMI interchange format MOF 1.3 open
MOF14-8 Reflective interface for Package factory MOF 1.3 open
MOF14-7 Minor changes to some Reflective operations MOF 1.3 open
MOF14-6 MOF 1.3 Package should subtype Classifier MOF 1.3 open
MOF14-5 MOF 1.3 Why prevent nonpublic Associations? MOF 1.3 open
MOF14-4 MOF 1.3 IDL template for clustering uses wrong name MOF 1.3 open
MOF14-3 MOF specifies no interfaces for actually (de-)serializing a model MOF 1.3 open
MOF14-2 Template should suppress add for [x..x] Attributes MOF 1.3 open
MOF14-1 MOF and IDL repository ids MOF 1.3 open
MOF14-83 mof rtf issue - coverage of RefXXX interfaces by MOF metamodel MOF 1.2 open
MOF14-82 mof rtf issue - setting UUIDs MOF 1.2 open
MOF14-81 WG: Attribute accessors and mutators MOF 1.2 open
MOF14-80 Do non-public Attributes need initialising? MOF 1.2 open
MOF14-79 IDL for Reflective Package Interfaces can conflict MOF 1.2 open
MOF14-78 Provide tools to chapter 5 UML 1.3R9 draft MOF 1.2 open
MOF14-77 Should Reflective.DesignatorType be "string"? MOF 1.2 open
MOF14-76 MOF Model IDL versus OMG Style guidelines MOF 1.2 open
MOF14-75 Need for light-weight References MOF 1.2 open
MOF14-74 Add a new technical overview chapter between chapters 2 and 3" MOF 1.2 open
MOF14-73 Freezing mechanism for all models MOF 1.2 open
MOF14-72 Specify the semantics of Constraint verification MOF 1.2 open
MOF14-71 Add appropriate Attribute default values to the MOF Model MOF 1.2 open
MOF14-70 Define a MOF Class that is the supertype of all Classes MOF 1.2 open
MOF14-69 Add support for Exception generalization MOF 1.2 open
MOF14-68 Add support for default values to MofAttribute MOF 1.2 open
MOF14-67 Validate the OCL constraints in the MOF specification MOF 1.2 open
MOF14-66 Tags that parameterize a meta-model mapping MOF 1.2 open
MOF14-65 What is a UML "profile"? MOF 1.2 open
MOF14-64 Semantics of Reference "set" onto an ordered Association. MOF 1.2 open
MOF14-63 ModelElement needs to have permanent, unique, unchanging, identifier MOF 1.2 open
MOF14-62 MOF RTF Isue: Conflict between "Facility" and "Package Object " MOF 1.2 open
MOF14-61 Generated operations returning attributes/references should not raise Cons MOF 1.2 open

Issues Descriptions

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

MOF 1.3: are Associations contained in Packages or not?

  • Key: MOF14-168
  • Legacy Issue Number: 3527
  • Status: closed  
  • Source: Model Driven Solutions ( 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

MOF Unbounded should have type long

  • Key: MOF14-51
  • Legacy Issue Number: 4175
  • Status: closed  
  • Source: Escape Velocity ( 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

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

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

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: Escape Velocity ( 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

Can MOF Class contain a Constant?

  • Key: MOF14-45
  • Legacy Issue Number: 3528
  • Status: closed  
  • Source: Escape Velocity ( 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: Escape Velocity ( 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

MOF 1.3 Incorrect attribute order in diagrams

  • Key: MOF14-43
  • Legacy Issue Number: 3444
  • Status: closed  
  • Source: Escape Velocity ( 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

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: Escape Velocity ( 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

Package Contains Association (mof-rtf)

  • Key: MOF14-40
  • Legacy Issue Number: 3131
  • Status: closed  
  • Source: Escape Velocity ( 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

Can MOF Package contain a Constant? (mof-rtf)

  • Key: MOF14-39
  • Legacy Issue Number: 3130
  • Status: closed  
  • Source: Escape Velocity ( 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

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

Collections of imported DataTypes can cause name clashes

  • Key: MOF14-36
  • Legacy Issue Number: 2922
  • Status: closed  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    If a Package declares a DataType with a given name and imports
    another Package that also declares a DataType with the same name
    the IDL templates can generate uncompilable IDL for the collections
    typedefs if both are required.

  • Reported: MOF 1.3 — Tue, 5 Oct 1999 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

"exposedEnd" for any of the references in the MOF metamodel.

  • Key: MOF14-35
  • Legacy Issue Number: 4798
  • Status: open  
  • Source: Anonymous
  • Summary:

    If Attribute.isDerived was moved up to StructuralFeature, then you could model derived references. An example of such a derived reference in the MOF meta-model is Reference.exposedEnd, which is equivalent to ref.referencedEnd.otherEnd().

    Relatedly, the copy of ptc/2001-10-05 found on the RTF website doesn't include the "exposedEnd" for any of the references in the MOF metamodel.

  • Reported: MOF 1.4 — Fri, 21 Dec 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Association Generalization Proposal

  • Key: MOF14-34
  • Legacy Issue Number: 4720
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    Here is a detailed proposal for adding association generalization to MOF
    1.5. This proposal does not address reference redefinition or overriding.
    I hope this proposal provides sufficient detail so that Steve Crawley can
    make changes to the specification. Please send your comments.

    Regards,
    Don

    Changes to Model

    Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]
    AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.

    Add a nonabstract association from AssociationEnd to AssociationEnd called
    RedefinesEnd. One end is called redefinedEnd, has a reference by the same
    name, and has multiplicity *. The other end is called redefiningEnd, has no
    reference, and has multiplicity *. This association is used to correlate an
    end with its corresponding end in a supertype association.

    Add new constraint: SupertypeEndsAreRedefined
    Evaluation policy: Deferred.
    Description: An end redefines each supertype's end.
    Context Association
    Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->
    forAll(ge : AssociationEnd |
    self.contents->select(sc |
    sc.oclIsTypeOf(AssociationEnd))->
    forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =
    ge)
    and se.otherEnd.redefinedEnd->exists(ore | ore =
    ge.otherEnd)))

    Add new constraint: RedefinedEndBelongsToSupertype
    Evaluation policy: Immediate.
    Description: Each redefinedEnd belongs to a supertype.
    Context AssociationEnd
    Inv: self.container.oclAsType(Association).supertypes.contents->
    includesAll(self.redefinedEnd)

    By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an
    immediate constraint, but it should be deferred. Otherwise, there is no
    valid way to create an Association.

    Changes to Abstract Mapping

    Add the following to Core Association Semantics.

    A link cannot be directly created for an Association with isAbstract set to
    true, but can be added indirectly as a link of a subtype association.

    Where a generalization exists between two associations, each link of the
    subtype association is logically a link of the supertype association - for
    each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or
    <b, a> depending on which subtype end redefines which supertype end).

    Removing a link from a Link_Set causes the logical link to be removed from
    each subtype association's Link_Set. Removing a link from a Link_Set also
    causes the logical link to be removed from each supertype association's
    Link_Set where the logical link is not otherwise present in the supertype
    Link_Set based on either having been put explicitly into the supertype
    Link_Set (where not abstract) or on being a link of some other subtype of
    the supertype. The net effect is that a Link_Set is a union of links put
    explicitly into the Link_Set with the Link_Sets of all subtypes.

    Changes to IDL Mapping

    In the template for associations, no add or modify operations are generated
    for an abstract association.

    In the template for references, no set, add, or modify operations are
    generated for an abstract association.

    Operations on RefObject for setting, adding, and modifying, and operations
    on RefAssociation for adding and modifying raise a new MofError, "Abstract
    Association", for creating a link of an abstract association.

    Changes to JMI

    In the template for associations, no add operation is generated for an
    abstract association.

    In the template for references, no set operation is generated for an
    abstract association. Also, the add and set operations on a reference
    collection throws a new JmiException, "AbstractAssociation", for an abstract
    association.

    For the reflective JMI interfaces, JmiException "AbstractAssociation" is
    thrown for refAddLink on an abstract association and for refSetValue on a
    reference on an abstract association.

  • Reported: MOF 1.4 — Fri, 30 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Unnecessary constraint on import by nested packages

  • Key: MOF14-33
  • Legacy Issue Number: 4715
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Section 2.3.6.2 and Constraint [C-48] prevent a nested package from
    importing from anything else. This seems unnecessarily restrictive and makes
    the use practical of nested packages unlikely.

  • Reported: MOF 1.4 — Tue, 27 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Multiplicity be optional for non-navigable association ends.

  • Key: MOF14-32
  • Legacy Issue Number: 4700
  • Status: open  
  • Source: International Business Machines ( Stephen Brodsky)
  • Summary:

    If an association end is not navigable, specification of its
    Multiplicity should not be required. There is no practical use for this
    information and it does not make sense to require information that is not
    used.

    Proposed Resolution: Make Multiplicity optional in the MOF model.

  • Reported: MOF 1.4 — Mon, 12 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong

  • Key: MOF14-31
  • Legacy Issue Number: 4664
  • Status: open  
  • Source: Anonymous
  • Summary:

    in section 5.8.12 "Reference Template", 1st para, it is stated: "The IDL generated for a Reference is declared within the scope of <ClassName>CLASS interface definition.", while the next para says: "The Reference Template defines the IDL generation rules for References. It declares operations on the INSTANCE interface to query and update links in the Association object for the current extent."

    I think, that all reference related IDL operations should go into the Instance interface, and not into the class proxy interface. This view is also compliant with 5.8.8 "Instance Template", that para states explicitly that the reference template is to be applied in the context of the instance template.

    Proposed Resolution:
    ====================
    Change the 1st para of 5.8.12 to "The IDL generated for a Reference is declared within the scope of <ClassName> interface definition.

  • Reported: MOF 1.4 — Tue, 6 Nov 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Restrictions needed for nested Packages and Classes

  • Key: MOF14-30
  • Legacy Issue Number: 4622
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    In recent MOF RTF telcon discussions, we tentatively concluded that we need
    Constraints on the MOF Model to forbid 1) clustering of nested Packages,
    2) inheritance of nested Packages and 3) clustering of Classes.

    Additional Text:

    There are three arguments for the proposed restrictions. The first
    argument is that supporting inheritance / clustering in these cases adds
    to the complexity of MOF implementations. Since practical metamodels
    never seem to use these combinations of features, it is hard justify
    supporting them.

    The second argument is that clustering and inheritance of nested
    Packages is problematical. The elements of a nested Package are
    implicitly defined in the context of the nested Package's outer Package.
    A Constraint or Operation defined on / within a nested Package may
    reasonably refer to Associations or "all_of_*" collections in the
    enclosing context. When a nested Package is inherited or clustered
    outside of the context of its parent Package, the Constraint and
    Operation semantics may cease to be meaningful.

    The second argument does not apply to a nested Package that is
    inherited by another nested Package with the same outermost Package.
    However, we have not been able to identify a use case for this sort
    of thing. Hence the first argument applies.

    The third argument is that the MOF IDL mapping explicitly excludes all
    of these cases; see "Section 5.5 - Preconditions for IDL Generation".

  • Reported: MOF 1.4 — Thu, 18 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Navigability of assoc. ends in MOF model

  • Key: MOF14-29
  • Legacy Issue Number: 4621
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    When I was looking at the current MOF 1.4 spec I could not find a place
    where is specified, which assoc. ends are navigable and which are not.
    There is an inconsistency between the UML picture of MOF metamodel and XMI
    (and IDL). Where the picture indicates that some ends (like
    RefersTo.referent) are not navigable, XMI says that they are navigable and
    also IDL contains getter method for these ends. So I guess the picture is
    wrong. This should be fixed, because it is in fact the only place where the
    users of the spec can see the navigability without looking at the
    hard-to-read XML file or generated IDL. It would be also helpful to add this
    also to the description of particular associations in section 3.5.

  • Reported: MOF 1.4 — Wed, 17 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Looking up metaobject using MOFID

  • Key: MOF14-28
  • Legacy Issue Number: 4609
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    MOF should have a support for looking up metaobjects by MOFIDs (e.g. by adding getObjectByMOFID method to RefPackage interface).

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

resolveQualifiedName operation

  • Key: MOF14-27
  • Legacy Issue Number: 4607
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    I think it would be much more convenient to have resolveQualifiedName as a
    "classifier_level" operation on ModelElement instead of "instance_level"
    operation on Namespace. Now each time I want to resolve some object using
    its qualified name, I have to find all outermost packages (which is quite
    slow, because currently there is no better way of doing it than just iterate
    through all package instances and check whether they are outermost), then
    choose a package with a specified name and call resolveQualifiedName on that
    package passing rest of the qualified name as a parameter. This is much more
    complicated for users than it should be.

  • Reported: MOF 1.4 — Mon, 8 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove obsolete material

  • Key: MOF14-26
  • Legacy Issue Number: 4594
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The document needs a big revamp - e.g. a lot of the ancient pre-UML intro
    stuff. We
    should bear in mind that a lot of people will be coming to the spec/OMG
    cold as a result of JMI takeup and we should make the document as clean,
    lean
    and approachable as we can.
    It will be at least a year before MOF 2.0 reaches a stable/official state so
    I feel we should not wait.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Deprecate object inheritance of class proxy interface

  • Key: MOF14-25
  • Legacy Issue Number: 4593
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    MOF should deprecate the use of factory/finder operations on object
    instances (i.e. the fact that generated instances inherit not only from
    their model superclass but from their class proxy). The main reason for this
    is that it does not separate concerns (why should an instance know about
    creating other instances or finding the population of the class?) and is not
    consistent with JMI.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Alignment of reflective interfaces with JMI

  • Key: MOF14-24
  • Legacy Issue Number: 4592
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    MOF should consider aligning its reflective interfaces with JMI
    (specifically split some of RefObject into RefClass and common superclass
    RefFeatured). As well as the benefit of consistency it makes the interfaces
    more intuitive/comprehensible and typesafe.

  • Reported: MOF 1.4 — Thu, 4 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Tracking identity of replicated / interchanged metadata

  • Key: MOF14-23
  • Legacy Issue Number: 4586
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    When metadata is copied from one repository to another, or saved as an
    XMI document, it can be necessary to know if the physically distinct
    copies of the metadata are logically the same or logically different.
    There need to be mechanisms for testing whether copies are logically the
    same or different that work in all cases, not just within the context of
    a single repository.

  • Reported: MOF 1.4 — Wed, 3 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof-rtf issue: Association Generalization

  • Key: MOF14-22
  • Legacy Issue Number: 4584
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The MOF model should allow generalization of associations. It is often
    useful to have a more general root association and create several
    specializations for it (e.g. dependency and several kinds of dependencies as
    its subclasses).

  • Reported: MOF 1.4 — Mon, 1 Oct 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Modeling OCL Helper Functions

  • Key: MOF14-21
  • Legacy Issue Number: 4569
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL).

    There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine.

    This applies not only to MOF but to other metamodels.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Representation of constraints

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

    The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3].

    The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.

  • Reported: MOF 1.4 — Sun, 16 Sep 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Delete all non-MOF-specific terms from the Glossary

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

    Delete all non-MOF-specific terms from the Glossary. People have trouble enough with MOF terms and it's sensible to have one place to collect them all, without clogging them up with a load of irrelevant UML terms (e.g. action sequence). Plus it create a management issue of having to keep up with UML (which it has failed to already - not even including something as fundamental as 'Profile').

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add 'semantics' attribute to Operation.

  • Key: MOF14-18
  • Legacy Issue Number: 4483
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    At the moment MOF has no way to describe the behavior of an operation. A new attribute, 'semantics', String (0..1) should be added to Operation. A more sophisticated alternative would be to include a 'language' attribute also, as for Constraint. This would be somewhat restrictive in permitting only one coding of the semantics (e.g. not both OCL and Java). Better would be to use just one multivalued attribute of type StructuredDataType 'Expression'. This would be as in UML and have StructureFields 'language' (String 0..1) and 'body' (String 1..1). It begs the question as to whether this datatype should then be used in Constraint instead of the current 'language' and 'expression' attributes.

  • Reported: MOF 1.3 — Sun, 12 Aug 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Disallow null instance values

  • Key: MOF14-17
  • Legacy Issue Number: 4419
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    It can be argued that there is no need to allow null as a valid value
    for a Class instance. The possibility of null means that mapped APIs
    need to be more complicated; e.g. the IDL "unset_*" operations. This
    issue proposes that 'null' should be disallowed, making Class instances
    consistent with DataType instances. The IDL mapping could also be
    simplified.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The current MOF package level import is not sufficient

  • Key: MOF14-16
  • Legacy Issue Number: 4383
  • Status: open  
  • Source: gmail.com ( Guus Ramackers)
  • Summary:

    The current MOF package level import is not sufficient. For instance, if a
    user wants to reuse "Boolean" from UML 1.4 Datatypes package, then she can
    only indicate "Datatypes" in MOF now. What is needed is that the user can
    say "Datatypes::Boolean" as a dependency. It would be counter-productive to
    create 12 subpackages of Datatypes and put each datatype in its own Package,
    just because it would let people reuse individual datatypes (without
    changing the MOF import rule).

  • Reported: MOF 1.3 — Wed, 20 Jun 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF-RTF issue: AttachesTo.modelElement - ordered

  • Key: MOF14-15
  • Legacy Issue Number: 4267
  • Status: open  
  • Source: GoodData Corporation ( Martin Matula)
  • Summary:

    The modelElement end of AttachesTo association should be ordered. It does
    make sense to have one tag attached to several model elements in a specified
    order. (E.g. tag decorating a set of class attributes which create a unique
    identifier of instances of this class)

  • Reported: MOF 1.3 — Wed, 11 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF IDL rules to minimize network roundtrips

  • Key: MOF14-14
  • Legacy Issue Number: 4255
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    Various people have complained that retrieving meta-data (typically
    features of Classes) using the IDL produced by the MOF IDL mapping
    involves too many round-trips. This is preventing people from using
    MOF generated IDL in projects. This issue calls for a solution (or
    solutions) to this problem.

  • Reported: MOF 1.3 — Fri, 6 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The role name of the Namespace->ModelElement association end

  • Key: MOF14-13
  • Legacy Issue Number: 4238
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Title: The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Tue, 27 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

role is named 'containedElement' while the reference is named 'contents'

  • Key: MOF14-12
  • Legacy Issue Number: 4232
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    The role name of the Namespace->ModelElement association end should
    be the same
    than the corresponding reference name.
    This role is named 'containedElement' while the reference is named
    'contents'.
    Even if this is legal, we should avoid this in the MOF model because it's
    error prone (in particular
    when we use the UML class diagram notation as a convenience for specifying
    MOF compliant
    metamodels).

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

predefined tag for marking attributes to act as qualifier in classifier

  • Key: MOF14-11
  • Legacy Issue Number: 4231
  • Status: open  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

    Need a predefined tag for marking attributes that will 'act as a
    qualifier' in a classifier.
    In a metamodelling tool it may be useful to derive automatically an object
    identifier from one
    or more relevant attributes of the classifier (for instance a 'name'
    attribute).
    Note: The attribute 'acting as a qualifier' is owned by the classifier not
    by an association.
    Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to
    any attribute
    of a classifier.

  • Reported: MOF 1.3 — Wed, 21 Mar 2001 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Metadata architecture needs to move away from the 4 levels and labels

  • Key: MOF14-10
  • Legacy Issue Number: 4111
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    The Metadata architecture needs to move away from the 4 levels and labels: and refer to them as an example for straightforward cases such as database modeling. Other non 4-layer examples are also needed. While the MOF spec does point out that "M1-level and M2-level are relative labels", in practice the labels are applied quite rigidly and this positively causes confusion, sterile arguments, and in some cases harm to specifications as people grapple with whether a class belongs to M1 or M2 and if the former then it should be excluded "since the RFP asks for a M2 model". An example of the problems can be found in section 13.2 of the SPE joint submission (adtf/00-00-05) though they (wrongly IMHO) think the solution is in UML not MOF. This will not change the MOF spec but how it is applied and models developed hence the severity of 'significant'.

  • Reported: MOF 1.3 — Fri, 8 Dec 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specify XMI parameters for the MOF / XMI interchange format

  • Key: MOF14-9
  • Legacy Issue Number: 3897
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The MOF spec standardises an XMI-generated interchange format for MOF
    meta-models. The MOF spec includes the "input" MOF meta-model for the
    Model. It should also include a formal statement of the other XMI
    "parameters" used to generate the meta-model interchange format.

  • Reported: MOF 1.3 — Fri, 22 Sep 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reflective interface for Package factory

  • Key: MOF14-8
  • Legacy Issue Number: 3745
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    There is no reflective version of the Package factory interface. In
    retrospect, an abstract interface would be useful for generic package
    creation using Package specific factory objects, and a concrete interface
    would be useful for a "universal" Package factory object.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Minor changes to some Reflective operations

  • Key: MOF14-7
  • Legacy Issue Number: 3744
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The RefAssociation ops that are parameterised by Link would be easier to
    use if parameterized by two RefObjects. The RefObject ops for
    add/modify/removing
    ele,emts of Attribute/Reference collections should be renamed; i.e. add_value
    becomes add_member. Other minor tweaks would make the interfaces easier to
    use.

    Discussion:

    This topic was discussed by MOF RTF 1.3, but never raised as a formal issue.
    The previous outcome was to defer this to the MOF 2.0 RFP.

  • Reported: MOF 1.3 — Mon, 17 Jul 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Package should subtype Classifier

  • Key: MOF14-6
  • Legacy Issue Number: 3448
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, a Package is not a subtype of Classifier. But
    an M2 package does have M1 instances (package extent objects), and the M2
    Package defines the type of those M1 objects. Therefore, a Package really
    is a Classifier. It is a type. It can be thought of as a component type,
    and in that sense a Package should be able to contain behavioral features.
    Also, an attribute type that is a Package should be treated as a pointer to
    a package extent object.

    Recommendation: make Package a subtype of Classifier, or fold Classifier
    into GeneralizableElement.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 Why prevent nonpublic Associations?

  • Key: MOF14-5
  • Legacy Issue Number: 3447
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, constraint C-37 requires Associations to be
    public. Support for nonpublic Associations is a valuable capability that
    should not be forbidden. In particular, when there are references on all
    navigable ends of an Association, the M1 Association object is fully
    redundant in the capabilities it provides. Making the Association private
    or protected eliminates the need to support redundant public interfaces for
    capabilities available most conveniently through references. The
    association is an important part of the model in that it defines the
    semantics and behavior of the references, but no public Association
    interface is needed. The IDL and other interfaces generated from metamodels
    is already too large. Constraint C-37 simply makes it larger than it needs
    to be.

    Note that the CWM submitters to OMG desire to use nonpublic associations
    extensively in CWM's 26 metamodels.

    Recommendation: Delete C-37.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF 1.3 IDL template for clustering uses wrong name

  • Key: MOF14-4
  • Legacy Issue Number: 3445
  • Status: open  
  • Source: Escape Velocity ( Don Baisley)
  • Summary:

    In the MOF 1.3 specification, section 5.8.4, the use of
    "<clustered_package_name>_ref" (both in the template and as a subheading) is
    incorrect. It should be "<import_name>_ref". The Import name provides the
    alias for a clustered package within a clustering package. The Package name
    is used to identify the type of the M1 package object, not the IDL attribute
    name.

    Recommendation: change "<clustered_package_name>_ref" to
    "<import_name>_ref".

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF specifies no interfaces for actually (de-)serializing a model

  • Key: MOF14-3
  • Legacy Issue Number: 3411
  • Status: open  
  • Source: Adaptive ( Pete Rivett)
  • Summary:

    MOF specifies no interfaces for actually (de-)serializing a model (to, for example, a XMI stream). Without such an interface it is not possible to guarantee that 2 XMI tools/repositories can communicate with each other, regardless of how completely they support MOF/XMI. Since the OMG is meant to be about interoperability this is a critical omission.
    It would make sense for MOF to make use of the Streamable interface defined as part of the Externalization service.
    And for the capability to be defined against Namespace to allow reasonable flexibility of granularity.
    Obviously XMI is only one possible format for the stream: the XMI specification should also be extended to fit into the detailed specification adopted for streaming MOF-compliant metamodels.

  • Reported: MOF 1.3 — Mon, 13 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Template should suppress add for [x..x] Attributes

  • Key: MOF14-2
  • Legacy Issue Number: 3112
  • Status: open  
  • Source: DSTC ( Stephen Crawley)
  • Summary:

    The Attribute template suppresses the "remove" operations for multi-valued
    Attributes whose lower and upper bounds are the same. [This makes sense
    because removing an element would always trigger an underflow error.] However,
    similar logic has not been applied to the "add" operation. We should consider
    suppressing "add" operations for multi-valued Attributes whose lower and upper
    bounds are the same, since the operation must always trigger an overflow error
    in this case.

  • Reported: MOF 1.3 — Mon, 13 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

MOF and IDL repository ids

  • Key: MOF14-1
  • Legacy Issue Number: 3043
  • Status: open  
  • Source: David Frankel Consulting ( David Frankel)
  • Summary:

    The AB is insisting that altered IDL types (including types that reference
    > altered IDL types) be versioned by specifying a new repository id. This
    > presents special issues for generated IDL when a source model is revised
    > and the IDL regenerated.
    >
    > Recommendation
    >
    > For generated IDL the safest thing is probably to generate a new UUID-based
    > repository id for all generated IDL interfaces and generated IDL structs,
    > valuetypes, etc.

  • Reported: MOF 1.3 — Sat, 20 Nov 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

mof rtf issue - coverage of RefXXX interfaces by MOF metamodel

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

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

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

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

mof rtf issue - setting UUIDs

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

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

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

WG: Attribute accessors and mutators

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

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

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

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

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

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

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

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

Do non-public Attributes need initialising?

  • Key: MOF14-80
  • Legacy Issue Number: 2839
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not clearly stated in Section 5.8.9 whether or not a Class"e
    "create_<classname>" operation should have parameters to provide initial
    values for Attributes whose visibility is "protected_vis" or "private_vis".
    The same applies for 5.8.3 for classifier-level Attributes in the Package
    factory interface.

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

IDL for Reflective Package Interfaces can conflict

  • Key: MOF14-79
  • Legacy Issue Number: 2527
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The IDL for the Reflective Package interfaces can conflict with IDL generated according to the MOF Model to IDL mapping rules. For example, when generating IDL for the UML metamodel, the UML class called Instance causes generation of an operation called create_instance which conflicts with the Reflective create_instance. The reflective interfaces should be changed to avoid such conflicts.

  • Reported: MOF 1.2 — Thu, 11 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Provide tools to chapter 5 UML 1.3R9 draft

  • Key: MOF14-78
  • Legacy Issue Number: 2449
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I would like to suggest that the UML model interface defined by Chapter 5 of the
    UML1.3R9 draft provide tools the ability to register for notification of changes to the
    model contents in a manner consistent with the Observer pattern.

    This would provide a better mechanism for tool integration around a common
    model respository, allowing each tool in a tool suite containing tools developed
    by different vendors to present its own up to date "view" of the underlying model in
    a simple fashion.

  • Reported: MOF 1.2 — Thu, 11 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Should Reflective.DesignatorType be "string"?

  • Key: MOF14-77
  • Legacy Issue Number: 2224
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The Reflective interfaces currently use object references to
    "designate" the feature (etc) to which a reflective operation applies.
    In practice, I am finding that this is inconvenient for clients of the
    API and potentially difficult for implementations. I suggest that we
    reconsider the alternative; i.e. designating features using CORBA
    strings.

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

MOF Model IDL versus OMG Style guidelines

  • Key: MOF14-76
  • Legacy Issue Number: 2188
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been pointed out to me that the MOF IDL doesn"t
    conform with the OMG style guidelines and conventions in two
    respects. First, there is no "#pragma prefix "org.omg"" in any of
    the core IDL files. Second, there is a convention that the
    outermost module names for OMG specs have a standard prefix
    depending on its "positioning" in the OMA; e.g. Cos, Cf or
    whatever.

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

Need for light-weight References

  • Key: MOF14-75
  • Legacy Issue Number: 2186
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: A requirement possibly exists for a light-weight version of
    References (or something like them), which at the M1 level does not
    require the existence of Attribute instance objects and the associated
    heavy weight querying mechanisms.

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

Add a new technical overview chapter between chapters 2 and 3"

  • Key: MOF14-74
  • Legacy Issue Number: 2183
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF specification needs a technical overview before chapter
    3 to help the reader put the details in the rest of the MOF specification
    into a perspective.

    Additional text:

    I am in the process of drafting a possible overview chapter.

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

Freezing mechanism for all models

  • Key: MOF14-73
  • Legacy Issue Number: 2182
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The MOF Model currently has a mechanism for freezing meta-models.
    It is underspecified, but the intent is that under certain conditions you
    can atomically freeze a valid meta-model. This issue proposes that this
    mechanism be re-specified so that it is available for all models.

    Additional text:

    Arguably this is an extension rather than an RTF issue.

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

Specify the semantics of Constraint verification

  • Key: MOF14-72
  • Legacy Issue Number: 2181
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: We need a thorough specification of the semantics of Constraint
    verification. This should cover the following:
    1) What happens; e.g. is the verification allowed to give up on the
    first error?
    2) When evaluation of deferrable Contraints can occur; i.e. where could
    the ConstraintError exceptions be raised?
    3) How evaluation of deferred Constraints is triggered.

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

Add appropriate Attribute default values to the MOF Model

  • Key: MOF14-71
  • Legacy Issue Number: 2179
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Assuming that we add the capability of defining defaults for
    Attributes [see previous issue], there are a number of Attributes in
    the MOF Model that could / should have default values; for example
    "visibility" should default to "public", and "is_root"/"is_leaf" should
    default to "dont_care".

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

Define a MOF Class that is the supertype of all Classes

  • Key: MOF14-70
  • Legacy Issue Number: 2178
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Define a MOF Class that is the supertype of all Classes.
    It could be represented as a single-valued subclass of Model::Class.

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

Add support for Exception generalization

  • Key: MOF14-69
  • Legacy Issue Number: 2177
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: UML currently supports Exception hierarchies, as do many
    object orient programming languages. MOF"s lack of support for this
    is perceived to be a limitation and an impediment to its use as a
    middleware independent meta-data framework.

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

Add support for default values to MofAttribute

  • Key: MOF14-68
  • Legacy Issue Number: 2174
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It has been suggested that Model should be extended to allow
    attributes to specified to have default values. Default values can be
    defined in the MOF Model by adding an attribute of type "any" to
    MofAttribute. [Default expressions are too hard.]

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

Validate the OCL constraints in the MOF specification

  • Key: MOF14-67
  • Legacy Issue Number: 2173
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Take steps to validate as much as possible of the OCL in the
    MOF specification. Ideally, they should all be compiled and "executed"
    to ensure that they behave as expected. This should be feasible at least
    for the OCL constraints in the Model package.

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

Tags that parameterize a meta-model mapping

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

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

    Additional text:

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

What is a UML "profile"?

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

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

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

Semantics of Reference "set" onto an ordered Association.

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

    Summary: The description of the semantics of Reference operations
    in section 6.2.2.1 needs to be extended to cover the multi-value
    update operations; i.e. "set" and "unset" when the referenced
    AssociationEnd is multi-valued. In particular, the semantics when
    either of the AssociationEnds is ordered need to be spelled out.

  • Reported: MOF 1.2 — Thu, 13 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

ModelElement needs to have permanent, unique, unchanging, identifier

  • Key: MOF14-63
  • Legacy Issue Number: 1540
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: ModelElement needs to have a permanent, unique, unchanging,
    non-redundant (within the transitive closure of a "large" namespace)
    (meta)identifier in addition to or as a replacement for qualifiedName
    as a local (meta)attribute.

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

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

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

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

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

Generated operations returning attributes/references should not raise Cons

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

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

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