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

MOF 1.4 RTF — Open Issues

  • Key: MOF14
  • Issues Count: 58
Open Closed All
Issues not resolved

Issues Summary

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

Issues Descriptions

WG: Attribute accessors and mutators

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

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

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

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

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

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

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

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

mof rtf issue - coverage of RefXXX interfaces by MOF metamodel

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

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

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

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

mof rtf issue - setting UUIDs

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

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

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

Tags that parameterize a meta-model mapping

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

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

    Additional text:

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

What is a UML "profile"?

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

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

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

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

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

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

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

Generated operations returning attributes/references should not raise Cons

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

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

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

Semantics of Reference "set" onto an ordered Association.

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

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

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

ModelElement needs to have permanent, unique, unchanging, identifier

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

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

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

Provide tools to chapter 5 UML 1.3R9 draft

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

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

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

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

Should Reflective.DesignatorType be "string"?

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

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

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

Do non-public Attributes need initialising?

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

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

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

IDL for Reflective Package Interfaces can conflict

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

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

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

Specify the semantics of Constraint verification

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

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

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

Add appropriate Attribute default values to the MOF Model

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

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

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

MOF Model IDL versus OMG Style guidelines

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

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

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

Need for light-weight References

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

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

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

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

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

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

    Additional text:

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

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

Freezing mechanism for all models

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

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

    Additional text:

    Arguably this is an extension rather than an RTF issue.

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

Add support for Exception generalization

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

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

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

Validate the OCL constraints in the MOF specification

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

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

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

Add support for default values to MofAttribute

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

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

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

Define a MOF Class that is the supertype of all Classes

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

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

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

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

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

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

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

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

Association Generalization Proposal

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

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

    Regards,
    Don

    Changes to Model

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

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

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

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

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

    Changes to Abstract Mapping

    Add the following to Core Association Semantics.

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

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

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

    Changes to IDL Mapping

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

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

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

    Changes to JMI

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

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

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

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

Unnecessary constraint on import by nested packages

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

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

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

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

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

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

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

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

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

Restrictions needed for nested Packages and Classes

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

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

    Additional Text:

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

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

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

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

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

Looking up metaobject using MOFID

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

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

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

resolveQualifiedName operation

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

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

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

Deprecate object inheritance of class proxy interface

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

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

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

Alignment of reflective interfaces with JMI

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

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

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

Navigability of assoc. ends in MOF model

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

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

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

Remove obsolete material

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

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

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

Tracking identity of replicated / interchanged metadata

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

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

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

Multiplicity be optional for non-navigable association ends.

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

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

    Proposed Resolution: Make Multiplicity optional in the MOF model.

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

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

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

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

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

Specify XMI parameters for the MOF / XMI interchange format

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

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

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

Delete all non-MOF-specific terms from the Glossary

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

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

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

Add 'semantics' attribute to Operation.

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

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

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

The current MOF package level import is not sufficient

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

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

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

MOF-RTF issue: AttachesTo.modelElement - ordered

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

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

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

mof-rtf issue: Association Generalization

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

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

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

Modeling OCL Helper Functions

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

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

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

    This applies not only to MOF but to other metamodels.

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

The role name of the Namespace->ModelElement association end

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

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

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

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

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

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

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

Representation of constraints

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

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

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

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

predefined tag for marking attributes to act as qualifier in classifier

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

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

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

Disallow null instance values

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

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

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

MOF IDL rules to minimize network roundtrips

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

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

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

MOF 1.3 Why prevent nonpublic Associations?

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

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

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

    Recommendation: Delete C-37.

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

MOF 1.3 IDL template for clustering uses wrong name

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

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

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

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

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

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

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

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

MOF and IDL repository ids

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

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

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

Reflective interface for Package factory

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

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

    Discussion:

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

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

Minor changes to some Reflective operations

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

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

    Discussion:

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

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

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

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

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

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

MOF 1.3 Package should subtype Classifier

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

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

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

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