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.

No Data Available

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.

duplicate of issue 3131

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

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.

see below

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

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

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.

see above

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.

see above

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.

see above

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?

No Data Available

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

close with no further action

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

see below

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.

see above

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]

Make the changes as suggested

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.

see above

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.

see above

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

see above

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.

Change constraint [C-15] as recommended

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.

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

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.

see above

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

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

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.

duplicate close issue

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.

close no action

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.

see above

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.

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

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.

see above

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

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

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.

see above

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.

see above

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.

see above

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.

see above

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.

see above

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.

No Data Available

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.

close, no action

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.

see above

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

see above

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.

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