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

closed resolved

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

closed resolved

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:

closed resolved

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

closed, resolved

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.

closed, resolved

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.

closed, resolved

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.

closed, resolved

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

closed resolved

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

closed, resolved

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.

closed issue

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.

resolved, closed

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:

closed, resolved

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.

resolved and closed

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.

resolved and closed

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.

resolved, issue closed

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.

resolved and closed

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.

resolved and closed

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.

resolved and closed

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.

resolved and closed

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.

resolved, issue closed

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.

resolved and closed

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.

resolved and closed

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

resolved and closed

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.

resolved and closed

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.

duplicate iswue....closed

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.

closed, no action required

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.

resolved and closed

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.

resolved and closed

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.

resolved and closed

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.

resolved

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?

resolved

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.

resolved

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?

resolved and closed

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

resolved and closed

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.

resolved and closed

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.

resolved and closed

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.

closed issue, resolved

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.

close issue, resolved

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.

resolved, issue closed

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.

resolved, issue closed

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

closed issue

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.

closed issue

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.

closed issue

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

resolved, close issue

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

resolved, close issue

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.

resolved, close issue

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.

closed issue

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.

closed issue, resolved

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.

closed, resolved

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.

closed, resolved

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.

closed, resolved

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

resolved

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.

resolved

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?

closed issue

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

nothing to do...close issue

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.

resolved, to be implemented

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.

resolved

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.

This is a duplicate of Issue #965.

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.

This is a duplicate of Issue #949.

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.

resolved

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.

resolved

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.

resolved and closed

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.

resolved and closed

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

closed issue, resolved

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

closed issue

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.

resolved and closed

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

closed issue

closed issue

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

rsolved, close issue

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

ressolved, close issue

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.

resolved and closed

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

closed, already implemented

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

resolved and closed

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

close - already implemented

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

close, already implemented

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

closed, to be implemented