Meta Object Facility Avatar
  1. OMG Specification

Meta Object Facility — Closed Issues

  • Acronym: MOF
  • Issues Count: 35
  • 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-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-87 Is the multiplicity of Model::Tag::values correct? MOF 1.2 MOF 1.4 Resolved closed
MOF14-86 Reflective typos MOF 1.2 MOF 1.4 Resolved closed
MOF14-84 Data types available to metamodels is restricted MOF 1.2 MOF 1.4 Resolved closed
MOF14-91 Missing exception for all_*_links operation MOF 1.2 MOF 1.4 Resolved closed
MOF14-90 Constraints on Associations. MOF 1.2 MOF 1.4 Resolved closed
MOF14-89 Section 5-54 of Meta Object Facility (MOF) Specification MOF 1.2 MOF 1.4 Resolved closed
MOF14-88 MOF is using CORBA string for its string data types MOF 1.2 MOF 1.4 Resolved closed
MOF14-85 Specify behaviour of RefObject.is_instance_of(null,...) MOF 1.2 MOF 1.4 Resolved closed
MOF14-36 Collections of imported DataTypes can cause name clashes MOF 1.3 MOF 1.4 Resolved closed
MOF14-47 MOF RTF Issue: typos in Reflective.idl MOF 1.3 MOF 1.4 Resolved closed
MOF14-46 "*" not needed on DataType name MOF 1.3 MOF 1.4 Resolved closed
MOF14-50 MODL Appendix needs updating MOF 1.3 MOF 1.4 Resolved closed
MOF14-49 Model::Contains::container return type wrong MOF 1.3 MOF 1.4 Resolved closed
MOF14-45 Can MOF Class contain a Constant? MOF 1.3 MOF 1.4 Resolved closed
MOF14-44 MOF 1.3 Why have rule against abstract packages? MOF 1.3 MOF 1.4 Resolved closed
MOF14-38 Operation Model::Tag::add_elements_before should not appear in the IDL MOF 1.3 MOF 1.4 Resolved closed
MOF14-37 Reflective IDL fix for CORBA 2.3 MOF 1.3 MOF 1.4 Resolved closed
MOF14-42 Incorrect return type for Assoc query operation MOF 1.3 MOF 1.4 Resolved closed
MOF14-41 "*" prefix on Simple Type Names (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-43 MOF 1.3 Incorrect attribute order in diagrams MOF 1.3 MOF 1.4 Resolved closed
MOF14-48 MofErrors for refQueryLink and refModifyLink MOF 1.3 MOF 1.4 Resolved closed
MOF14-39 Can MOF Package contain a Constant? (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-40 Package Contains Association (mof-rtf) MOF 1.3 MOF 1.4 Resolved closed
MOF14-60 Clarify whether null instances are currently valid MOF values MOF 1.3 MOF 1.4 Resolved closed
MOF14-59 IDL mapping Tag for specifying IDL #pragma versions MOF 1.3 MOF 1.4 Resolved closed
MOF14-58 ::Model::Package::internalize/externalize in MOF 1.4 MOF 1.3 MOF 1.4 Resolved closed
MOF14-57 Move the 'verify' operation to RefBaseObject MOF 1.3 MOF 1.4 Resolved closed
MOF14-56 Primitive data types usage in the MOF Model. MOF 1.3 MOF 1.4 Resolved closed
MOF14-55 Error in MOF 1.3 XMI - ViolationType MOF 1.3 MOF 1.4 Resolved closed
MOF14-53 predefined tag for marking attributes needed MOF 1.3 MOF 1.4 Resolved closed
MOF14-52 MOF IDL change MOF 1.3 MOF 1.4 Resolved closed
MOF14-54 MofError when Operation impl violates structural constraints MOF 1.3 MOF 1.4 Resolved closed
MOF14-51 MOF Unbounded should have type long MOF 1.3 MOF 1.4 Resolved closed

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 ( Mr. Steve Cook)
  • Summary:

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

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

    These seem inconsistent.

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

    duplicate of issue 3131

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

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

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

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

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

    see below

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

Reflective typos

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

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

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

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

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

Data types available to metamodels is restricted

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

    Summary: Data types available to metamodels is restricted.

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

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

    see above

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

Missing exception for all_*_links operation

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

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

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

    see above

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

Constraints on Associations.

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

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

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

    see above

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

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

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

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

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

    No Data Available

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

MOF is using CORBA string for its string data types

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

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

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

    close with no further action

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

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

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

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

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

    see below

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

Collections of imported DataTypes can cause name clashes

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

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

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

    see above

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

MOF RTF Issue: typos in Reflective.idl

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

    We've spotted two minor typos in the Reflective.idl in Appendix B.2 of
    the MOF 1.3 spec.

    1) The constant called "WRONG_DESIGNATOR_DESIGNMATOR_VIOLATION"
    should be renamed to "WRONG_DESIGNATOR_VIOLATION".

    [The constant is described correctly in section 5.4.6 on page 5-31]

    2) The "ref_unset_value()" operation in "RefObject" is missing
    a parameter. It should be declared as:

    void ref_unset_value(in DesignatorType feature) raises (MofError);

    [The operation is described correctly in section 6.2.3 on page 6-13]

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

    Make the changes as suggested

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

"*" not needed on DataType name

  • Key: MOF14-46
  • Legacy Issue Number: 3529
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification, section 3.4.7, says a DataType that does not
    require an IDL declaration must have a "name" that starts with a "*"
    character. This is an unnecessary restriction which has been generally
    ignored. MOF Model does not start DataType names with a "*" (see Appendix A
    XML defining any, boolean, string, and unsigned long). Similarly, the UML
    metamodel and others ignore this unnecessary restriction.

    The restriction is particularly inappropriate because it restricts
    ModelElement names based on the IDL mapping. IDL rules should not restrict
    ModelElement names, first because a Tag can be used to select an alternate
    IDL name, and second because a DataType mapped directly to a predefined IDL
    type does not cause an IDL declaration to be generated (so the DataType name
    is irrelevant to IDL generation).

    Recommendation: remove the restriction that a DataType not requiring an IDL
    declaration have a "name" starting with a "*" character.

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

    see above

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

MODL Appendix needs updating

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

    In MOF 1.3 RTF, it was agreed (with some reluctance on my part) that the
    spelling of the model element names in the XMI version of the MOF Model
    was definitive. This means that the MODL definition of the Model package
    in the Appendix is out of date.

    In addition, DSTC has made a number of changes to the MODL language
    syntax that mean that the version in the MOF 1.3 spec no longer
    compiles.

    Finally, the URL for the specification of the MODL language is stale.

  • Reported: MOF 1.3 — Wed, 17 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Model::Contains::container return type wrong

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

    The "Contains" Association is defined with the "container" end having
    type "Namespace" and multiplicity [0..1]. According to the MOF to IDL
    mapping (see 5.8.10 <association_end1_name>) this means that the
    Model::Contains::container() operation should return a "NamespaceBag".

    However, the IDL in both Chapter 3 and Appendix C incorrectly declares
    Model::Contains::container() as returning a "Namespace".

  • Reported: MOF 1.3 — Fri, 12 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Can MOF Class contain a Constant?

  • Key: MOF14-45
  • Legacy Issue Number: 3528
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification shows in table 3-4 that a Class can contain a
    Constant. But constraint [C-15] ClassContainmentRules does not allow a
    Class to contain a Constant. The table and the constraint need to say the
    same thing. Since MOF's Model.ModelElement contains Constants, it is clear
    that the table is correct.

    Recommendation: add Constant to ClassContainmentRules.

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

    Change constraint [C-15] as recommended

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

MOF 1.3 Why have rule against abstract packages?

  • Key: MOF14-44
  • Legacy Issue Number: 3446
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, constraint C-44, which prevents a package
    being abstract, does not appear to serve any useful purpose. It does
    prevent definition of general, abstract metamodels that must be subclassed
    with more specific metamodels in order to be deployed. A MOF package
    defines a type of a package extent, and such types support polymorphism
    through package inheritance. The concept of abstract packages is as useful
    to metamodeling as the concept of abstract classes is to object modeling.

    Recommendation: Delete C-44.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    This is a duplicate of issue 4202. Close with no further action.

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

Operation Model::Tag::add_elements_before should not appear in the IDL

  • Key: MOF14-38
  • Legacy Issue Number: 3094
  • Status: closed  
  • Source: Object Radiance ( GK Khalsa)
  • Summary:

    The MOF specification defines the AttachesTo association as ordered on
    the Tag end (given a ModelElement, its tags are ordered). The IDL for
    for AttachesTo interface is consistent with this definition. However,
    the IDL definition of the Tag interface provides an add_elements_before
    operation, which is inconsistent with the Association definition in the
    metamodel. Presumably, that operation is included in error, and should
    be removed.

  • Reported: MOF 1.3 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Reflective IDL fix for CORBA 2.3

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

    The Reflective module contains the following IDL type alias:

    typedef any ValueType;

    Unfortunately, CORBA 2.3 has added a new IDL keyword "valuetype". Hence a
    CORBA 2.3 compliant compiler will give syntax errors for the Reflective IDL.

    Possible solutions include:

    1) Replace "ValueType" with "_ValueType" throughout the
    Reflective module.

    2) Change "ValueType" to another name; e.g. "CorbaValueType".

    3) Remove the typedef, and replace all instances with "any".

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

    Adopt approach 1 to minimize impact on interoperability. Flag this to be fixed properly in MOF 2.0.

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

Incorrect return type for Assoc query operation

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

    The description of the single ended Association query operation has
    (I think) the wrong return type for an "optional" association end.
    The operation can return either zero or one instances. This could
    be expressed as either the base type or a "bag" collection. The
    former is easier to use, and what the spec used to prescribe in MOF 1.1.
    However, the text of the template description [section 5-10-8 on page
    5-62] currently prescribes the latter.

    I think this is just a typo in MOF 1.3. However, it could be that the
    change was deliberate, and I've forgotten why we decided to make it.

    At any rate, the 1.3 mapping description now inconsistent with the IDL
    for the MOF Model in Appendix B. Examine the IDL interface for the
    "contains" Association. The "container" end has multiplicity [0..1]
    yet the "container(ModelElement)" operation returns a Namespace, not
    a NamespaceBag as the text of the mapping spec requires.

  • Reported: MOF 1.3 — Mon, 28 Feb 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    duplicate close issue

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

"*" prefix on Simple Type Names (mof-rtf)

  • Key: MOF14-41
  • Legacy Issue Number: 3133
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    Based on the rule in the MOF 1.3 Specification in 3.4.7 that a DataType not
    requiring an IDL declaration must have a name starting with a "*", the
    DataType names "any", "boolean", "string", and "unsigned long" in the XML
    rendition of Model should be "*any", "*boolean", "*string", and "*unsigned
    long" respectively.

  • Reported: MOF 1.3 — Fri, 17 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    close no action

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

MOF 1.3 Incorrect attribute order in diagrams

  • Key: MOF14-43
  • Legacy Issue Number: 3444
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    In the MOF 1.3 Specification, the order of attributes shown in some of the
    diagrams and their descriptions is inconsistent with the order given in the
    XML and IDL. Particularly, GeneralizableElement and AssociationEnd show
    attributes out of order. The diagrams, explanative text, XML and IDL should
    all show features in the same order because order is relevant when
    determining the order of parameters passed to a create operation. A diagram
    showing attributes out of order can lead one to pass creation arguments in
    the wrong order.

    Recommendation: fix the order in the diagrams and explanations.

  • Reported: MOF 1.3 — Wed, 22 Mar 2000 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MofErrors for refQueryLink and refModifyLink

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

    The description of refQueryLink and refModifyLink in 6.2.4 does not
    record the fact that they can raise MofError(Not Navigable). See
    5.8.10 etc.

  • Reported: MOF 1.3 — Wed, 10 May 2000 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    Correct the descriptions of refQuery and refModifyLink to match the IDL mapping

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

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

  • Key: MOF14-39
  • Legacy Issue Number: 3130
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification shows in table 3-4 that a Package can contain a
    Constant. But constraint [C-43] PackageContainmentRules does not allow a
    Package to contain a Constant. The table and the constraint need to say the
    same thing.

  • Reported: MOF 1.3 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Package Contains Association (mof-rtf)

  • Key: MOF14-40
  • Legacy Issue Number: 3131
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    There is a typo in table 3-4 of the MOF 1.3 Specification indicating that a
    Package cannot contain an Association.

  • Reported: MOF 1.3 — Thu, 16 Dec 1999 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    This is clearly a typo in the table, which currently doesn't allow anything to contain an Associatio

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

Clarify whether null instances are currently valid MOF values

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

    The JMI expert group has identified an anomaly in the MOF spec with respect
    to null instances of Classes. According to the IDL mapping, a null
    instance is a valid value for an Attribute or a Parameter; e.g. paragraph
    2 of section 5.3.4. On the other hand, the Abstract mapping (Chapter 4)
    does not mention null at all. JMI needs to know if null is a valid value
    for a Class instance, in the general case.

  • Reported: MOF 1.3 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

IDL mapping Tag for specifying IDL #pragma versions

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

    There is currently no standard way to direct the MOF IDL mapping to
    output a #pragma version for a declaration. This is needed when a
    standard meta-model is changed in a way that gives IDL interfaces, etc
    with the same name but different signatures.

  • Reported: MOF 1.3 — Sat, 21 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

::Model::Package::internalize/externalize in MOF 1.4

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

    The Package class has two operations "internalize" and "externalize" that
    are supposed to be hooks for importing and exporting metadata. They are
    defined in MOF 1.3 with Parameters whose type is a CORBA Any and that
    represents some kind of input / output stream. This won't work in MOF
    1.4 because "Any" is not a supported data type.

  • Reported: MOF 1.3 — Thu, 5 Jul 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Move the 'verify' operation to RefBaseObject

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

    Meta-modelling the 'verify' Operation on Model::ModelElement is going to be
    problematical in MOF 1.4 because one of its Parameters contains a CORBA any.
    We could solve this by moving the operation onto the (IDL) RefBaseObject
    interface. This would have the additional benefit of providing an API
    for invoking constraint validation on any meta-object.

  • Reported: MOF 1.3 — Thu, 21 Jun 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Primitive data types usage in the MOF Model.

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

    In MOF 1.3, the Model contains references to the following primitive (IDL)
    data types: boolean, long, unsigned long, any, string and TypeCode. Some
    of these are 'typedef'd.

    In MOF 1.4, the status of the primitive types is as follows:

    boolean – required
    long – 32 bit signed integers – required (for MultiplicityType)
    unsigned long – 32 bit unsigned integers – not required
    (its use in MOF 1.3 was a typo ... )
    any – maybe required for Constant, Constraint and Tag.
    TypeCode – not required
    string – required, but see below.

    There are a couple of loose ends though:

    1) The "any" type would need to be a 5th standard PrimitiveType. It has
    been suggested that we can use a string type to represent the 'value'
    field of Constant, the 'values' field of Tag and the 'expression' field
    of Constraint. Tags and Constraints are straightforward, but using
    a string to represent a Constant value would entail defining standard
    concrete (string) syntaxes for the kinds of values allowed for Constants.

    Proposal: Replace all occurrences of 'any' in the MOF Model with a 16 bit
    UTF string type.

    Proposal: Adopt the IDL syntax for integer, floating point and wide string
    literals with minor modifications as required. (It would be a good idea
    to use an encoding that works with 8 bit character sets ... )

    2) In MOF 1.3, "string" is used for various things such as NameType,
    AnnotationType, DependencyKind and FormatType along with the type
    of 'tagId'. Note that this is an 8 bit string type. Apparently
    this causes problems for some meta-modellers. At any rate, now
    would be a good time to start supporting international character
    sets in meta-models.

    Proposal: Change all 'string' types in the MOF Model to a 16 bit UTF
    string type.

    Proposal: Remove all cosmetic typedefs.

  • Reported: MOF 1.3 — Tue, 19 Jun 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

Error in MOF 1.3 XMI - ViolationType

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

    The XMI document for MOF 1.3 gets the type of the 'values_in_error'
    field of 'ViolationType' wrong. It says that the type is an IDL
    interface type called ::Reflective::NamedObjectList. In fact the
    type's name is ::Reflective::NamedValueList, and it is a typedef
    of a sequence of a struct ... not an interface.

  • Reported: MOF 1.3 — Fri, 18 May 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    No Data Available

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

predefined tag for marking attributes needed

  • Key: MOF14-53
  • Legacy Issue Number: 4237
  • Status: closed  
  • Source: France Telecom R&D ( Mariano Belaunde)
  • Summary:

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

  • Reported: MOF 1.3 — Tue, 27 Mar 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    close, no action

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

MOF IDL change

  • Key: MOF14-52
  • Legacy Issue Number: 4211
  • Status: closed  
  • Source: ETA Sistemi Srl ( Davide Mora)
  • Summary:

    i suggest to change the IDL from:

    typedef any ValueType; typedef sequence < ValueType > ValueTypeList;

    to:

    typedef any AnyType; typedef sequence < AnyType > AnyTypeList;

    because "valuetype" it's a reserved word for the newest versions of IDL and cause an error.

    There is also "strange character" in the following const:

    const string INVALID_DELETION_VIOLATION = (character)org.omg.mof:reflective.invalid_deletion(character);

    the "(character)" have to be replaced with '"'.

    I suggest also to split the .txt in 2 files .idl, or explain in the download page how the .txt have to be splitted.

  • Reported: MOF 1.3 — Mon, 26 Feb 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MofError when Operation impl violates structural constraints

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

    The description of the behaviour of an Operation does not say what ought
    to happen if an Operation's implementation returns parameters or results
    that violate multiplicity constraints. Similarly, for Exception parameters.
    This affects sections 5.8.13 and 6.2.3 ("refInvokeOperation").

  • Reported: MOF 1.3 — Tue, 8 May 2001 04:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    see above

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

MOF Unbounded should have type long

  • Key: MOF14-51
  • Legacy Issue Number: 4175
  • Status: closed  
  • Source: Google ( Don Baisley)
  • Summary:

    The MOF 1.3 Specification defines the constant UNBOUNDED
    like this:

    const unsigned long UNBOUNDED = -1;

    The type should be long, not unsigned long. The value is used
    for MultiplicityType.upper which has type long. Also, the
    constant has a signed value.

  • Reported: MOF 1.3 — Fri, 26 Jan 2001 05:00 GMT
  • Disposition: Resolved — MOF 1.4
  • Disposition Summary:

    The IDL clearly contains a typo. Fix it so that UNBOUNDED is signed

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