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

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.

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

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.

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

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)

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

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.