Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Closed Issues

  • Acronym: MOF
  • Issues Count: 76
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
MOF14-167 No reflective all_links() operation MOF 1.2 MOF 1.3 Resolved closed
MOF14-166 RefAssociation::link_exists() signature inconsistent MOF 1.2 MOF 1.3 Resolved closed
MOF14-165 Error in "args" parameter of RefObject::invoke_operation. MOF 1.2 MOF 1.3 Resolved closed
MOF14-164 Typos in Reflective::remove_value_at MOF 1.2 MOF 1.3 Resolved closed
MOF14-161 Exception to indicate no corresponding "specific" operation MOF 1.2 MOF 1.3 Resolved closed
MOF14-160 MissingParameter and TooManyParameters exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-163 Document how to "unset" using the RefObject interface MOF 1.2 MOF 1.3 Resolved closed
MOF14-162 RefObject::value() needs to raise NotSet MOF 1.2 MOF 1.3 Resolved closed
MOF14-157 Edit the MOF specification to improve clarity and readability MOF 1.2 MOF 1.3 Resolved closed
MOF14-156 Revise `container" operations on RefBaseObject MOF 1.2 MOF 1.3 Resolved closed
MOF14-159 Reflective::InvalidDesignator exception MOF 1.2 MOF 1.3 Resolved closed
MOF14-158 Support for IDL prefixes in MOF spec MOF 1.2 MOF 1.3 Resolved closed
MOF14-155 Add support for Package Consolidation / Clustering MOF 1.2 MOF 1.3 Resolved closed
MOF14-154 Document different meaning of "abstract" MOF 1.2 MOF 1.3 Resolved closed
MOF14-153 Update specification to track OCL syntax changes MOF 1.2 MOF 1.3 Resolved closed
MOF14-152 MOF names implicitly tied to implementation MOF 1.2 MOF 1.3 Resolved closed
MOF14-151 MOF RTF Issue: SMIF version of MOF MOF 1.2 MOF 1.3 Resolved closed
MOF14-150 New name clash issue from CORBA 2.3 spec MOF 1.2 MOF 1.3 Resolved closed
MOF14-149 Atomicity of updates MOF 1.2 MOF 1.3 Resolved closed
MOF14-148 exceptions for resolve_qualified_name() MOF 1.2 MOF 1.3 Resolved closed
MOF14-147 Need to specify when are side-effects allowed MOF 1.2 MOF 1.3 Resolved closed
MOF14-146 MOF Constraints are pure predicates MOF 1.2 MOF 1.3 Resolved closed
MOF14-145 MofAttribute values do not have aggregation==composite semantics MOF 1.2 MOF 1.3 Resolved closed
MOF14-144 Cardinality of "RefersTo" and "Exposes" associations MOF 1.2 MOF 1.3 Resolved closed
MOF14-143 Multiplicities on Attributes and References modelled incorrectly MOF 1.2 MOF 1.3 Resolved closed
MOF14-142 Navigability constraint expressed wrongly MOF 1.2 MOF 1.3 Resolved closed
MOF14-140 Navigability constraint expressed wrongly MOF 1.2 MOF 1.3 Resolved closed
MOF14-139 Multiplicities on Attributes and References modelled incorrectly MOF 1.2 MOF 1.3 Resolved closed
MOF14-141 Inconsistent multiplicity for TypeAlias MOF 1.2 MOF 1.3 Resolved closed
MOF14-138 Convenient way to discriminate instances of subclasses MOF 1.2 MOF 1.3 Resolved closed
MOF14-137 Should set_(nil) be legal? MOF 1.2 MOF 1.3 Resolved closed
MOF14-136 set_ needs StructuralError MOF 1.2 MOF 1.3 Resolved closed
MOF14-134 Exception for creating instances of imported supertypes? MOF 1.2 MOF 1.3 Resolved closed
MOF14-135 Description of with_ operations MOF 1.2 MOF 1.3 Resolved closed
MOF14-133 MOF RTF Issue: Behavior of M1 level interfaces vagualy specified MOF 1.2 MOF 1.3 Resolved closed
MOF14-132 MOF RTF Issue: aggregations crossing M1 and M2 package boundary MOF 1.2 MOF 1.3 Resolved closed
MOF14-129 Naming of Tags MOF 1.2 MOF 1.3 Resolved closed
MOF14-128 Identifier formating error in MOF generates IDL MOF 1.2 MOF 1.3 Resolved closed
MOF14-131 MOF RTF Issue: M1 life-cycle operations MOF 1.2 MOF 1.3 Resolved closed
MOF14-130 MOF RTF Issue: Library of collection types? MOF 1.2 MOF 1.3 Resolved closed
MOF14-127 IDL generation Association Template Syntax MOF 1.2 MOF 1.3 Resolved closed
MOF14-126 IDL Mapping/Identifier Naming MOF 1.2 MOF 1.3 Resolved closed
MOF14-125 IDL generation - IMPORT TEMPLATE clarification MOF 1.2 MOF 1.3 Resolved closed
MOF14-124 Illegal IDL redefinitions MOF 1.2 MOF 1.3 Resolved closed
MOF14-123 Incorrect ocl specification(s) MOF 1.2 MOF 1.3 Resolved closed
MOF14-122 Consider a better approach to generated exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-121 Single-valued parameters should not be defined with sequences MOF 1.2 MOF 1.3 Resolved closed
MOF14-120 Operations should return nil reference instead of raising NotSet MOF 1.2 MOF 1.3 Resolved closed
MOF14-119 ConstraintError exception needed in more IDL generation templates MOF 1.2 MOF 1.3 Resolved closed
MOF14-118 ConstrainViolation vs. ConstraintError confusion (editorial) MOF 1.2 MOF 1.3 Resolved closed
MOF14-117 Association IDL generation needs to consider AssociationEnd.isChangeable MOF 1.2 MOF 1.3 Resolved closed
MOF14-114 Generated location parameters need clear specification of base value MOF 1.2 MOF 1.3 Resolved closed
MOF14-113 Type of Facility.MofRepository.packageFactory incompatible with its purpos MOF 1.2 MOF 1.3 Deferred closed
MOF14-116 Association interface generation templates require exceptions MOF 1.2 MOF 1.3 Resolved closed
MOF14-115 Description of meta-model as a single package is incorrect MOF 1.2 MOF 1.3 Resolved closed
MOF14-112 Editorial; change MOF Type to MOF Class MOF 1.2 MOF 1.3 Resolved closed
MOF14-111 RefObject::create_instance and abstract types MOF 1.2 MOF 1.3 Resolved closed
MOF14-110 MOF IDL Mapping with parameters MOF 1.2 MOF 1.3 Resolved closed
MOF14-109 MOF IDL /MODL - Type Hierarchy error MOF 1.2 MOF 1.3 Resolved closed
MOF14-108 MOF IDL mapping-types of parameters with multiplicities MOF 1.2 MOF 1.3 Resolved closed
MOF14-107 IDL Mapping--#includes for inheritted Packages MOF 1.2 MOF 1.3 Resolved closed
MOF14-106 Type Hierarchy Error in IDL MOF 1.2 MOF 1.3 Resolved closed
MOF14-105 MOF-IDL needs to be re-generated MOF 1.2 MOF 1.3 Resolved closed
MOF14-104 Type Create template, order of parameters MOF 1.2 MOF 1.3 Resolved closed
MOF14-101 Similar to issue 940 MOF 1.2 MOF 1.3 Resolved closed
MOF14-100 package create template: names of parameters need to be formated MOF 1.2 MOF 1.3 Resolved closed
MOF14-103 Similar o issue 941 MOF 1.2 MOF 1.3 Resolved closed
MOF14-102 $issue.summary MOF 1.2 MOF 1.3 Resolved closed
MOF14-99 package create template: ConstraintError MOF 1.2 MOF 1.3 Resolved closed
MOF14-98 Package create template: StructuralError needs to be raised MOF 1.2 MOF 1.3 Resolved closed
MOF14-97 Package create template MOF 1.2 MOF 1.3 Resolved closed
MOF14-94 Typos in MOF 1.1 document (1) MOF 1.2 MOF 1.3 Resolved closed
MOF14-93 IDL Generation Issue - factory operation parameters for multivalued attrib MOF 1.2 MOF 1.3 Resolved closed
MOF14-96 Typos in MOF 1.1 document (3) MOF 1.2 MOF 1.3 Resolved closed
MOF14-95 Typos in MOF 1.1 document (2) MOF 1.2 MOF 1.3 Resolved closed
MOF14-92 External Types as DataTypes Limits Modeling MOF 1.2 MOF 1.3 Resolved closed

Issues Descriptions

No reflective all_links() operation

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

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

    Additional text:

    The following operation signature is proposed:

    LinkSet all_links();

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

    closed resolved

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

RefAssociation::link_exists() signature inconsistent

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

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

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

    closed resolved

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

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

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

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

    Additional text:

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

    closed resolved

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

Typos in Reflective::remove_value_at

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

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

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

    closed, resolved

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

Exception to indicate no corresponding "specific" operation

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

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

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

    closed, resolved

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

MissingParameter and TooManyParameters exceptions

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

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

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

    closed, resolved

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

Document how to "unset" using the RefObject interface

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

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

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

    closed, resolved

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

RefObject::value() needs to raise NotSet

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

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

    Additional text:

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

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

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

    closed resolved

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

Edit the MOF specification to improve clarity and readability

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

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

    Additional text:

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

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

    closed, resolved

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

Revise `container" operations on RefBaseObject

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

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

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

    closed issue

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

Reflective::InvalidDesignator exception

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

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

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

    resolved, closed

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

Support for IDL prefixes in MOF spec

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

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

    Additional text:

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

    closed, resolved

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

Add support for Package Consolidation / Clustering

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

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

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

    resolved and closed

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

Document different meaning of "abstract"

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

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

    Additional text:

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

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

    resolved and closed

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

Update specification to track OCL syntax changes

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

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

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

    resolved, issue closed

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

MOF names implicitly tied to implementation

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

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

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

    resolved and closed

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

MOF RTF Issue: SMIF version of MOF

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

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

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

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

    resolved and closed

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

New name clash issue from CORBA 2.3 spec

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

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

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

    resolved and closed

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

Atomicity of updates

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

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

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

    resolved and closed

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

exceptions for resolve_qualified_name()

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

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

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

    resolved, issue closed

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

Need to specify when are side-effects allowed

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

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

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

    resolved and closed

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

MOF Constraints are pure predicates

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

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

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

    resolved and closed

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

MofAttribute values do not have aggregation==composite semantics

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

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

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

    resolved and closed

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

Cardinality of "RefersTo" and "Exposes" associations

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

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

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

    resolved and closed

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

Multiplicities on Attributes and References modelled incorrectly

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

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

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

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

    duplicate iswue....closed

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

Navigability constraint expressed wrongly

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

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

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

    closed, no action required

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

Navigability constraint expressed wrongly

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

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

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

    resolved and closed

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

Multiplicities on Attributes and References modelled incorrectly

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

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

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

    resolved and closed

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

Inconsistent multiplicity for TypeAlias

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

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

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

    resolved and closed

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

Convenient way to discriminate instances of subclasses

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

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

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

    resolved

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

Should set_(nil) be legal?

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

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

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

    resolved

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

set_ needs StructuralError

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

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

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

    resolved

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

Exception for creating instances of imported supertypes?

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

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

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

    resolved and closed

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

Description of with_ operations

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

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

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

    resolved and closed

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

MOF RTF Issue: Behavior of M1 level interfaces vagualy specified

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

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

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

    resolved and closed

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

MOF RTF Issue: aggregations crossing M1 and M2 package boundary

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

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

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

    resolved and closed

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

Naming of Tags

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

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

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

    closed issue, resolved

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

Identifier formating error in MOF generates IDL

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

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

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

    close issue, resolved

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

MOF RTF Issue: M1 life-cycle operations

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

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

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

    resolved, issue closed

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

MOF RTF Issue: Library of collection types?

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

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

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

    resolved, issue closed

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

IDL generation Association Template Syntax

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

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

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

    closed issue

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

IDL Mapping/Identifier Naming

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

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

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

    closed issue

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

IDL generation - IMPORT TEMPLATE clarification

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

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

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

    closed issue

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

Illegal IDL redefinitions

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

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

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

    resolved, close issue

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

Incorrect ocl specification(s)

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

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

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

    resolved, close issue

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

Consider a better approach to generated exceptions

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

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

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

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

    resolved, close issue

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

Single-valued parameters should not be defined with sequences

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

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

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

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

    closed issue

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

Operations should return nil reference instead of raising NotSet

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

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

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

    closed issue, resolved

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

ConstraintError exception needed in more IDL generation templates

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

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

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

    closed, resolved

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

ConstrainViolation vs. ConstraintError confusion (editorial)

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

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

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

    closed, resolved

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

Association IDL generation needs to consider AssociationEnd.isChangeable

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

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

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

    closed, resolved

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

Generated location parameters need clear specification of base value

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

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

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

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

    resolved

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

Type of Facility.MofRepository.packageFactory incompatible with its purpos

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

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

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

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

    resolved

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

Association interface generation templates require exceptions

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

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

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

    closed issue

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

Description of meta-model as a single package is incorrect

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

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

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

    nothing to do...close issue

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

Editorial; change MOF Type to MOF Class

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

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

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

    resolved, to be implemented

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

RefObject::create_instance and abstract types

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

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

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

    resolved

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

MOF IDL Mapping with parameters

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

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

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

    This is a duplicate of Issue #965.

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

MOF IDL /MODL - Type Hierarchy error

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

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

    Clearly it must be derived from TypedElement.

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

    This is a duplicate of Issue #949.

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

MOF IDL mapping-types of parameters with multiplicities

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

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

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

    resolved

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

IDL Mapping--#includes for inheritted Packages

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

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

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

    resolved

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

Type Hierarchy Error in IDL

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

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

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

    resolved and closed

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

MOF-IDL needs to be re-generated

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

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

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

    resolved and closed

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

Type Create template, order of parameters

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

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

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

    closed issue, resolved

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

Similar to issue 940

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

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

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

    closed issue

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

package create template: names of parameters need to be formated

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

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

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

    resolved and closed

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

Similar o issue 941

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

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

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

    closed issue

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

${issue.summary}

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

    closed issue

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

package create template: ConstraintError

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

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

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

    rsolved, close issue

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

Package create template: StructuralError needs to be raised

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

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

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

    ressolved, close issue

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

Package create template

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

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

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

    resolved and closed

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

Typos in MOF 1.1 document (1)

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

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

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

    closed, already implemented

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

IDL Generation Issue - factory operation parameters for multivalued attrib

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

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

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

    resolved and closed

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

Typos in MOF 1.1 document (3)

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

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

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

    close - already implemented

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

Typos in MOF 1.1 document (2)

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

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

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

    close, already implemented

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

External Types as DataTypes Limits Modeling

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

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

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

    closed, to be implemented

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