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

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

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

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

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

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

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

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

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

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

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

Additional text:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Additional text:

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

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

Additional text:

Arguably this is an extension rather than an RTF issue.

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

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

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

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

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

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

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

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

Regards,
Don

Changes to Model

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

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

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

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

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

Changes to Abstract Mapping

Add the following to Core Association Semantics.

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

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

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

Changes to IDL Mapping

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

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

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

Changes to JMI

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

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

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

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

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

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

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

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

Additional Text:

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

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

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

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

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