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

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