Issues for Meta-Object Facility Revision Task Force discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 784: External Types as DataTypes Limits Modeling
Issue 785: IDL Generation Issue - factory operation parameters for multivalued attrib
Issue 786: Typos in MOF 1.1 document (1)
Issue 787: Typos in MOF 1.1 document (2)
Issue 788: Typos in MOF 1.1 document (3)
Issue 940: Package create template
Issue 941: Package create template: StructuralError needs to be raised
Issue 942: package create template: ConstraintError
Issue 943: package create template: names of parameters need to be formated
Issue 944: Similar to issue 940
Issue 945:
Issue 946: Similar o issue 941
Issue 947: Type Create template, order of parameters
Issue 948: MOF-IDL needs to be re-generated
Issue 949: Type Hierarchy Error in IDL
Issue 957: IDL Mapping--#includes for inheritted Packages
Issue 965: MOF IDL mapping-types of parameters with multiplicities
Issue 966: MOF IDL /MODL - Type Hierarchy error
Issue 967: MOF IDL Mapping with parameters
Issue 968: RefObject::create_instance and abstract types
Issue 969: Editorial; change MOF Type to MOF Class
Issue 1075: Type of Facility.MofRepository.packageFactory incompatible with its purpos
Issue 1076: Generated location parameters need clear specification of base value
Issue 1077: Description of meta-model as a single package is incorrect
Issue 1078: Association interface generation templates require exceptions
Issue 1079: Association IDL generation needs to consider AssociationEnd.isChangeable
Issue 1080: ConstrainViolation vs. ConstraintError confusion (editorial)
Issue 1081: ConstraintError exception needed in more IDL generation templates
Issue 1082: Generated operations returning attributes/references should not raise Cons
Issue 1083: Operations should return nil reference instead of raising NotSet
Issue 1084: Single-valued parameters should not be defined with sequences
Issue 1085: Consider a better approach to generated exceptions
Issue 1141: Incorrect ocl specification(s)
Issue 1305: Illegal IDL redefinitions
Issue 1306: IDL generation - IMPORT TEMPLATE clarification
Issue 1307: IDL Mapping/Identifier Naming
Issue 1308: IDL generation Association Template Syntax
Issue 1496: Identifier formating error in MOF generates IDL
Issue 1497: Naming of Tags
Issue 1498: MOF RTF Issue: Library of collection types?
Issue 1500: MOF RTF Issue: M1 life-cycle operations
Issue 1501: MOF RTF Issue: aggregations crossing M1 and M2 package boundary
Issue 1502: MOF RTF Issue: Behavior of M1 level interfaces vagualy specified
Issue 1505: MOF RTF Isue: Conflict between "Facility" and "Package Object "
Issue 1513: Exception for creating instances of imported supertypes?
Issue 1516: Description of with_<associationed> operations
Issue 1517: set_<referencename> needs StructuralError
Issue 1518: Should set_<referencename>(nil) be legal?
Issue 1540: ModelElement needs to have permanent, unique, unchanging, identifier
Issue 1683: Convenient way to discriminate instances of subclasses
Issue 1711: Multiplicities on Attributes and References modelled incorrectly
Issue 1712: Navigability constraint expressed wrongly
Issue 1714: Inconsistent multiplicity for TypeAlias
Issue 1715: Navigability constraint expressed wrongly
Issue 1716: Multiplicities on Attributes and References modelled incorrectly
Issue 1749: Cardinality of "RefersTo" and "Exposes" associations
Issue 1770: MofAttribute values do not have aggregation==composite semantics
Issue 1775: MOF Constraints are pure predicates
Issue 1778: Need to specify when are side-effects allowed
Issue 1779: exceptions for resolve_qualified_name()
Issue 1803: Atomicity of updates
Issue 1804: Semantics of Reference "set" onto an ordered Association.
Issue 1900: New name clash issue from CORBA 2.3 spec
Issue 1998: MOF RTF Issue: SMIF version of MOF
Issue 2025: MOF names implicitly tied to implementation
Issue 2046: What is a UML "profile"?
Issue 2165: Tags that parameterize a meta-model mapping
Issue 2172: Update specification to track OCL syntax changes
Issue 2173: Validate the OCL constraints in the MOF specification
Issue 2174: Add support for default values to MofAttribute
Issue 2175: Document different meaning of "abstract"
Issue 2176: Add support for Package Consolidation / Clustering
Issue 2177: Add support for Exception generalization
Issue 2178: Define a MOF Class that is the supertype of all Classes
Issue 2179: Add appropriate Attribute default values to the MOF Model
Issue 2180: Revise `container" operations on RefBaseObject
Issue 2181: Specify the semantics of Constraint verification
Issue 2182: Freezing mechanism for all models
Issue 2183: Add a new technical overview chapter between chapters 2 and 3"
Issue 2185: Edit the MOF specification to improve clarity and readability
Issue 2186: Need for light-weight References
Issue 2187: Support for IDL prefixes in MOF spec
Issue 2188: MOF Model IDL versus OMG Style guidelines
Issue 2189: Reflective::InvalidDesignator exception
Issue 2190: MissingParameter and TooManyParameters exceptions
Issue 2191: Exception to indicate no corresponding "specific" operation
Issue 2192: RefObject::value() needs to raise NotSet
Issue 2193: Document how to "unset" using the RefObject interface
Issue 2194: Typos in Reflective::remove_value_at
Issue 2195: Error in "args" parameter of RefObject::invoke_operation.
Issue 2196: RefAssociation::link_exists() signature inconsistent
Issue 2197: No reflective all_links() operation
Issue 2198: Data types available to metamodels is restricted
Issue 2205: Specify behaviour of RefObject.is_instance_of(null,...)
Issue 2210: Reflective typos
Issue 2224: Should Reflective.DesignatorType be "string"?
Issue 2449: Provide tools to chapter 5 UML 1.3R9 draft
Issue 2465: Is the multiplicity of Model::Tag::values correct?
Issue 2495: MOF is using CORBA string for its string data types
Issue 2527: IDL for Reflective Package Interfaces can conflict
Issue 2839: Do non-public Attributes need initialising?
Issue 2876: WG: Attribute accessors and mutators
Issue 2877: Section 5-54 of Meta Object Facility (MOF) Specification
Issue 2881: Constraints on Associations.
Issue 2882: Missing exception for all_*_links operation
Issue 2922: Collections of imported DataTypes can cause name clashes
Issue 2923: mof rtf issue - setting UUIDs
Issue 2925: mof rtf issue - coverage of RefXXX interfaces by MOF metamodel
Issue 2971: Reflective IDL fix for CORBA 2.3
Issue 3043: MOF and IDL repository ids
Issue 3094: Operation Model::Tag::add_elements_before should not appear in the IDL
Issue 3112: Template should suppress add for [x..x] Attributes
Issue 3130: Can MOF Package contain a Constant? (mof-rtf)
Issue 3131: Package Contains Association (mof-rtf)
Issue 3133: "*" prefix on Simple Type Names (mof-rtf)
Issue 3379: Incorrect return type for Assoc query operation
Issue 3411: MOF specifies no interfaces for actually (de-)serializing a model
Issue 3444: MOF 1.3 Incorrect attribute order in diagrams
Issue 3445: MOF 1.3 IDL template for clustering uses wrong name
Issue 3446: MOF 1.3 Why have rule against abstract packages?
Issue 3447: MOF 1.3 Why prevent nonpublic Associations?
Issue 3448: MOF 1.3 Package should subtype Classifier
Issue 3527: MOF 1.3: are Associations contained in Packages or not?
Issue 3528: Can MOF Class contain a Constant?
Issue 3529: "*" not needed on DataType name
Issue 3533: MOF RTF Issue: typos in Reflective.idl
Issue 3606: MofErrors for refQueryLink and refModifyLink
Issue 3744: Minor changes to some Reflective operations
Issue 3745: Reflective interface for Package factory
Issue 3897: Specify XMI parameters for the MOF / XMI interchange format
Issue 4111: The Metadata architecture needs to move away from the 4 levels and labels
Issue 4133: Model::Contains::container return type wrong
Issue 4154: MODL Appendix needs updating
Issue 4175: MOF Unbounded should have type long
Issue 4202: Abstract package
Issue 4211: MOF IDL change
Issue 4231: predefined tag for marking attributes to act as qualifier in classifier
Issue 4232: role is named 'containedElement' while the reference is named 'contents'
Issue 4237: predefined tag for marking attributes needed
Issue 4238: The role name of the Namespace->ModelElement association end
Issue 4255: MOF IDL rules to minimize network roundtrips
Issue 4267: MOF-RTF issue: AttachesTo.modelElement - ordered
Issue 4295: MofError when Operation impl violates structural constraints
Issue 4313: Error in MOF 1.3 XMI - ViolationType
Issue 4351: Primitive data types usage in the MOF Model.
Issue 4383: The current MOF package level import is not sufficient
Issue 4384: Move the 'verify' operation to RefBaseObject
Issue 4396: ::Model::Package::internalize/externalize in MOF 1.4
Issue 4413: IDL mapping Tag for specifying IDL #pragma versions
Issue 4418: Clarify whether null instances are currently valid MOF values
Issue 4419: Disallow null instance values
Issue 4483: Add 'semantics' attribute to Operation.
Issue 4484: Delete all non-MOF-specific terms from the Glossary
Issue 4568: Representation of constraints
Issue 4569: Modeling OCL Helper Functions
Issue 4584: mof-rtf issue: Association Generalization
Issue 4586: Tracking identity of replicated / interchanged metadata
Issue 4592: Alignment of reflective interfaces with JMI
Issue 4593: Deprecate object inheritance of class proxy interface
Issue 4594: Remove obsolete material
Issue 4607: resolveQualifiedName operation
Issue 4609: Looking up metaobject using MOFID
Issue 4621: Navigability of assoc. ends in MOF model
Issue 4622: Restrictions needed for nested Packages and Classes
Issue 4664: Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong
Issue 4700: Multiplicity be optional for non-navigable association ends.
Issue 4715: Unnecessary constraint on import by nested packages
Issue 4720: Association Generalization Proposal
Issue 4798: "exposedEnd" for any of the references in the MOF metamodel.

Issue 784: External Types as DataTypes Limits Modeling (mof-rtf)

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

Discussion: The manner in which MOF provides for representation of external
types (types not defined within a MOF Model) is through the DataType class. For models
translated into IDL, only IDL external types (interfaces) are interesting. Since each
DataType object identifies its type through a TypeCode, the external type can be represent-ed
as either an object reference or type alias TypeCode. However, in so doing, the external
type can only be treated in MOF models as a DataType, so instances of MofClass cannot
inherit from them, and associations cannot be defined between a MofClass and an external
type. This restriction makes it impossible to define a MofClass which derives from the Life
Cycle Service interface CosLifeCycle::LifeCycleObject, for instance. The best solution re-quires
some research. Perhaps an ExternalClass type should be added to the MOF Model,
derived from MofClass, with a TypeCode attribute. Then additional constraints could in-sure
that object reference and type aliases which resolve to object references could only be
used in ExternalClass, and that ExternalClass could use no other TypeCode kinds.
DSTC Response (kerry@dstc.edu.au).
There are 3 possible solutions.
1. Do nothing. Any interface produced by the MOF's IDL generation can be further extend-ed
by inheritance, if desired. If only a few interfaces require such extension, then this is the
simplest route for the implementer. However, if every interface needs to be extended e.g. to
incorporate COS LifeCycle or other CORBAservices, it would be inconvenient to do it this
way (possible but inconvenient). If we take this solution, we should document it in a FAQ.
2. Relax the constraint that prevents Class being Generalised by DataType. Since any ex-ternal object type can be introduced into a MOF model as a DataType, allowing a Class to
inherit from such DataTypes would achieve the desired inheritance. Naturally, there would
have to be an associated constraint that the DataType was an object-type and not (say) an
integer. There might be some minor impact on the Namespaces (to be further investigated).
The disadvantage of this approach is that the Generalises association is about concept gen-eralisation
(a first class issue), rather than inheritance of the generated IDL (a second
class issue).
3. Add a new ModelElement to the MOF Model called (say) "Interface" which models any
CORBA object . Add a new Association called (say) "Extends". The Extends Association
would relate a Class with the legacy Interface that it was extending.
Orlando RTF Resolution.
Add a new ModelElement to the MOF Model called (say) "Interface" which models any
CORBA object . Add a new Association called (say) "Extends". The Extends Association
would relate a Class with the legacy Interface that it was extending.
DSTC Response (crawley@dstc.edu.au).
This could be made to work. We are in danger of moving down the "slippery slope" of mod-elling
CORBA IDL in the core MOF, and by implication subsuming the function of the
CORBA Interface Repository. Is this activity within the scope of what the MOF-RTF
should be doing? If we go down this road here/now, we risk making the current problems
CORBA has with interface versioning a LOT worse.
So far, MOF has carefully avoided the need to duplicate or replace existing IFR function-ality
by using CORBA TypeCodes to represent "ordinary" CORBA data and object types.
In the case of the object types, the TypeCode contains a RepositoryId for the interface that
can be used to retrieve the interface definition from a CORBA IFR.

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

 received issue

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

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

Response: This was a mistake in the final submission that was corrected in the errata doc-ument
that accompanied the submission when the OMG adoption vote was taken. So, it has
already been corrected.
Resolved.
Implementation: Nothing required. Done [KR].

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

Response: This was a mistake in the final submission that was corrected in the errata doc-ument
that accompanied the submission when the OMG adoption vote was taken. So, it has
already been corrected.
Resolved.
Implementation: Nothing required. Done [KR].

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.
 

Response. This is the same problem as #785. Section 7.3.2 should be revised to make it clear
that the appropriate CollectionKind should be used for multi-valued parameter types.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Text added to Section 5.8.3, “Package Factory Template,” on
page 5-48. Done [KR].

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

Response: The template in Section 7.3.2 should require the generated interface to have a
StructuralError exception when any of the attribute parameters could be multivalued (or
otherwise has the potential to be malformed as described in Section 5.3.3).
Proposed resolution: package create operations to raise "rolled up" ConstraintError ex-ception
as per resolution to #1085.
Implementation: As per resolution to Section , “Issue 1085: Consider a better ap-proach
to generated exceptions (mof-rtf), Section 5.8.3, “Package
Factory Template,” on page 5-48 is now raising MofError, which
includes structural errors, so no additional changes required. Done
[KR].

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

Response: The template in Section 7.3.2 should require the generated interface to have a
ConstraintError exception when any of the parameter types have a Constraint constraining
them.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. Package create op-erations
to raise "rolled up" ConstraintError exception as per resolution to #1085

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.
 

Response: This was agreed by the submitters but was not properly documented in Section
7.3.2. To prevent name collisions in inner name spaces, the names of the parameters must
be "fully qualified" by the "path" from the package being created. Note that there is no need
for the package name itself to be included in the "path" name, as names in that scope must
be unique. Although this sounds complex, it is quite intuitive in practice, and an example
will make it easy for the reader to understand.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Added text to Section 5.8.3, “Package Factory Template,” on
page 5-48. Done [KR].
Implementation: Fixed typo in template subsection of Section 5.8.3, “Package Facto-ry
Template,” on page 5-48: "<attribute_name>" becomes
"<qualified_attribute_name>". Done. [SC}

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

Response: Similar issue to #940 with same solution applied to Section 7.3.5.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: This is exactly the same issue as “Issue 785: IDL Generation Issue
- factory operation parameters for multivalued attribu (mof-rtf)”, so
no further action required. Done [KR].

This is a duplicate of issue #941.

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

Response. Similar to issue #941 with same solution applied to Section 7.3.5.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Fixed as a consequential change in “Issue 1085: Consider a better
approach to generated exceptions (mof-rtf)” so no further action re-quired.
Done [KR].

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

Response. This applied to both Classes and Packages. Sections 7.3.2 and 7.3.5 should be
revised to explain that the attributes are ordered according to the following rules:
1. attributes of a supertype Class/Package come before attributes of the subtype Class/
Package
2. the supertype Class/Package are processed in their order of containment
3. if a supertype Class/Package is inherited twice, then its attributes are included only on
the first occurrence and are subsequently suppressed.
Again, this is more intuitive than it sounds, and an example will be useful here to illustrate
this.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Added a description of the ordering to Section 5.8.3, “Package Fac-tory
Template,” on page 5-48 and Section 5.8.9, “Class Create
Template,” on page 5-58. Done [KR].
Implementation: Descriptions further ammended to take Package clusters into ac-count.
Done. [SC]

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. 
 

Response: Any changes to the IDL generation templates will affect the IDL for the MOF
itself (as it is generated according to the template rules). Therefore, as a final step in the
RTF process, the MOF IDL must be regenerated and updated both in the main document
and in Appendix A.
Furthermore, other OMG specifications which are using the MOF should be advised (e.g.
via submitters or RTF) and new IDL generated for these specifications.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: We are manually updating the MODL and IDL as we implement the
resolution of issues. The intention is that, when our IDL generators
are reimplemented, we can cross-check their output.

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.
 
 

Response: AssociationEnd should derived from TypedElement. The MODL in Appendix B
should be revised, the MOF IDL regenerated and reincorporated. This should affect the
IDL in Section 3.7.16 and Appendix A.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Fixed the IDL so that AssociationEndClass inherits from TypedEle-mentClass
and AssociationEnd inherits from TypedElement instead
of ModelElementClass and ModelElement in Section 3.4.17,
“AssociationEnd,” on page 3-53 and Appendix B.1 “MOF IDL
Summary”. The current version of the MODL in Appendix C.1
“MODL Description of the MOF” appears to correctly inherit from
TypedElement, so no change needed. Done [KR].

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.
 
 

Response: Clearly an IDL compiler must have all the relevant definitions at its disposal.
However, the need for #include statements depends on how the complete collection of IDL
has been divided up (or merged together) into one or more files. So, we can resolve this in
two alternative ways:
1. The IDL generation rules must specify the file structure for the generated IDL and the
#includes required within those files.
2. The IDL generation rules state that no prescription is to be made about the file structure,
but that an implementer must ensure that appropriate #include's are generated to reflect
the file structure that they select. This is our preferred option, and we propose adding such
text to a new small Section 7.2.4 "Storage of Generated IDL".
Discussion: We believe this issue affects other OMG specifications, e.g. CORBA and
BOCA. We should try to seek a consistent solution with the relevant people. Dan Franz is
currently preparing a new OMG style guide, and should be involved in this discussion.
Discussion: As far as we can determine, the official line is that IDL file names and #include
structure are not standardised. There is a recommendation that all IDL files include #ifndef
"guards".
Resolution. The MOF-RTF meeting in Manchester favoured the second option (that the file
boundaries are an implementation issue). The IDL generation rules should state that they
do not prescribe the IDL file structure (or names), but that an implementor should ensure
that appropriate "#include" directives are generated to reflect the file structure used. To
be implemented.
Implementation: Added new section Section 5.7.4, “File Organization and #include
statements,” on page 5-44 to explain that file organisation is the re-sponsibility
of the implementer. Removed generation rules for "#in-clude"
statements from (now deleted) “Import Template” and
discussion of these from Section 5.8.2, “Package Module Tem-plate,”
on page 5-46. Removed the "#include" and "#ifndef" etc
statements from Appendix “MOF IDL Summary”; there were no
occurrences of "#statements" in other sections of the spec. Done
[KR].

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.
 

Response. Similar to earlier issues with the same solution of making it clear that the appro-priate
CollectionKind suffix must be used in the type names of multi-valued parameters in
Section 7.3.9.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Added text to Section 5.8.13, “Operation Template,” on page 5-91.
I believe the IDL in the document is already correct. Done [KR].

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. 
 

 close issue -- duplicate

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.
 

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.

Response: Add a new exception called (say) "AbstractType" which is raised by
create_instance when it is invoked for an abstract Class. This change affects Section 5.3.6
and Appendix A.
It should be called "AbstractClass" to be consistent with Issue #969.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Superseded by the new overall approach to exceptions arising from
“Issue 1085: Consider a better approach to generated exceptions
(mof-rtf)”. AbstractClass is now a reflective error kind for
MofError; see Section 5.4.6, “Reflective Errors,” on page 5-30.
Done [SC]

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.
 
 

Response: A number of concepts changed their names during the final days of writing the
submission in order to better align with UML. "Type" should be (intelligently) replaced by
"Class" as appropriate from Section 5 onwards. There are probably some other similar in-consistencies
arising from the addition of the "Mof" prefix on "MofAttribute" and "MofEx-ception".
There are no technical implications in this issue, just editorial ones.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Actually the problem is not confined to the later sections of the document. It is all pervasive.
Implementation: Creates a huge number of minor changes throughout Chapter 3,
“MOF Model and Interfaces”, Chapter 6, “The Reflective Mod-ule”,
Chapter 5, “MOF to IDL Mapping” and Appendix C.1
“MODL Description of the MOF”. To do a proper cleanup, we re-ally
need to change the IDL usages of "type" when "class" is really
intended. Someone else really needs to check what has been done.
[KR]

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.
 
 

Discussion on this topic is anticipated to result in additional larger RTF issues in the area
of MofRepository. No further progress on this issue, pending the resolution of these other
issues.
This topic is linked to #Issue1505
Implementation: See resolution of “Issue 1505: MOF RTF Isue: Conflict between
'Facility" and 'Package Object " (mof-rtf)”. Done [KR].

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

Response: Section 5.2.2 and 5.2.3 and 5.3.6 and 7.3.7 should all specify the base of the po-sitional
parameters to be 0. Also, Section 5 uses a "long" to represent positional parame-ters
while Section 7 uses an "unsigned long". Since negative numbers are meaningless as
positions, we should revise Section 5 (and hence Appendix A) to use "unsigned long".
The choice between 0 and 1 is somewhat arbitrary. We propose 0 since we believe that most
CORBA implementations are written in C, C++, and Java which have 0-based arrays.
Does anyone know of this issue arising in other OMG specifications? If so, how was it re-solved?
Resolution. It turns out that this is a non-issue, as the MOF spec already defines the base
of positional parameters to be 0 (see Section 5.4.2). However, the other sections should be
revised to include this information and a reference to the defining section. To be imple-mented.
Implementation: The operations add_value_at, modify_value_at, and
remove_value_at in Section 6.2.3, “Reflective::RefObject,” on
page 6-10 have been updated to have their position parameter be
"unsigned long" instead of "long" and to note that 0 is the first posi-tion.
The IDL for the same operations was updated in “Interface”
on page 6-23 and Appendix B.2 “MOF IDL Summary”to reflect the
use of "unsigned long" for position parameters. Done [KR].

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

Response: The facts of the matter are:
1. Containment. Every MOF object (apart from the root of the MOF repository) is con-tained
within some other MOF object in a strict tree structure. This ensures that related
"chunks" of the MOF can be copied, moved, and deleted by copying, moving or deleting the
root of that sub-tree.
2. Relationship between metamodel and Package. A metamodel is represented by a Pack-age.
The concepts and relationships of that meta-model are represented by the various
ModelElements contained within that Package or reachable from that Package by inherit-ance/
import . Conversely, every Package is a representation of some metamodel.
3. Package naming. Section 6.7.1 defines a recommended naming convention to ensure
global uniqueness of metamodel/Package names. However, some large meta-models are
represented by a number of Packages, either by the nesting of Packages or by cross-linking
between Packages, and it might not be clear which of these Packagesshould be the "entry-point"
to the metamodel.
Section 6.3 should be reworded to make points 1 and 2 clearer. When Packages are nested,
the outermost Package should be identified as the "entry point" to the meta-model. If there
is a set of inter-linked Packages (without an outer containing Package), this means there
is a corresponding set of inter-linked metamodels, each of which is entitled to its own glo-bal
name designating a separate entrypoint. This should be added to Section 6.7.1.
Proposed resolutions:
1. Adopt Package clustering / consolidation proposal (see #Issue2176). This provides a
new mechanism for assembling free-standing Packages.
2. In sections 6.3 and 6.7.1, document that a meta-model is denoted by a closure of a
single Package as described above.
Implementation: 1) Nothing to do here. Done. [SC]

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?
 

Response: Section 7.3.6 should be revised to raise the StructuralError exception on the op-eration
"exists" and the operations "with_*" so that null object-reference parameter values
can be reported as ObjectInvalid (see Section 5.3.3). There is no need to add this exception
to the other query operations on this interface ecause they don't have any parameters that
could be structurally malformed. There is also no need to add this exception to the update
operations on this interface as they already can raise StructuralError.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: Since the resolution of “Issue 1085: Consider a better approach to
generated exceptions (mof-rtf)” has replaced StructuralError with
MofError, the template in Section 5.8.10, “Association Template,”
on page 5-60 and Appendix B.1 “MOF IDL Summary” and
throughout Section 3.5, “MOF Model Associations,” on page 3-71
have been updated so that the "exists" and "with_*" operations now
raise Reflective::MofError. Done [KR]

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.
 
 

Response: There are two separate issues here.
1. If an AssociationEnd has is_changeable=false, then:
1a. What operations should be present in the Association template (Section 7.3.6)?
1b. What operations should be present in a Reference template for this AssociationEnd
or the other AssociationEnd (Section 7.3.8)?
2. Should derived Associations be update-able? Or should derived Associations be readon-ly?
Or should we allow them to be defined explicitly as readonly or not?
The semantics of is_changeable are somewhat difficult to understand (especially the way
in which non-change-ability of one AssociationEnd seems to impact on the other Associa-tionEnd).
We note that this approach was taken to maximise alignment with UML, but it
does complicate the MOF semantics.
Obviously, one option would be a clearer expression of the is_changeable semantics and
the consequent IDL generation rules (including the generation rules for factory IDL).
An alternative is to remove the concept of "is_changeable" from AssociationEnd and re-place
it with an is_changeable attribute on Association. An Association with
"is_changeable=false" would not generate any update operations for the Association or
any Reference to its AssociationEnds. The only way that the links of the Association could
be set/updated would be through the use of Operations on that Association. This would also
enable derived Associations to be either readonly or not, depending on whether or not the
mechanism for the derivation was information-losing (this is the old view-update problem).
Possible courses of action on IDL issue:
1. Obtain a clearer expression of the intended M1 level semantics of is_changeable on
AssociationEnds [action: UNISYS]. The appropriate options for the IDL genera-tion
rules (including the generation rules for factory IDL) will then be apparent.
2. Move is_changeable from AssociationEnd to Association. An Association with
is_changeable==false would not have any update operations for the Association or
for any References to its AssociationEnds. The only way that the links of the Asso-ciation
could be created or updated would be through the use of Operations.
Possible courses of action on updateable derived Associations:
1. Require derived Associations to have is_changeable==false.
2. Allow the designer to specify updateable derived Associations if he believes that
they are implementable given the intended derivation rules. (Note that these rules
are not currently specifiable in the metamodel.)
1/12 : Washington1.If the Association_End called X has isChangeable==False, then the modify_X
operation is the Association will be suppressed. If there is a reference coming from
the other End, then the set_ReferenceName operation will be suppressed on the oth-er
End
3. Derived Associations are READ ONLY and don’t have add, remove and modify op-erations
suppressed.
4. Any references used in the Association will also have add, remove and modify op-erations
suppressed.
[Potential UML alignment issue - check the consistency rules in UML AssociationSeman-tics.]
Following discussions with the UML RTF, the following points of agreement have been
established. Consider the example of two Classes Man and Woman with an Assocation
called Married with AssociationEnd husband (of type Man) and AssociationEnd wife (of
type Woman).
If AssociationEnd husband has is_changeable set to false, then it should not be possible us-ing
the association object to add/remove husband-wife pairs nor to do a modify_husband
operation (i.e. change the husband of a given wife). It is OK to do a modify_wife operation
(i.e. change the wife of a given husband).
Further it was agreed that the issue of changeability of the AssociationEnds and whether
the Association is derived were orthogonal issues. It will still be possible to update derived
associations (provided their AssociationEnds are changeable).
Implementation: Added the requirement that both association ends must be change-able
for the generation of the add operation, the add_before opera-tion(
both templates), and the remove operation in Section 5.8.10,
“Association Template,” on page 5-60. Added the requirement that
the generation of the modify_<associationend1> operation requires
associationend1 to be changeable and that the generation of the
modify_<associationend2> operation requires associationend2 to
be changeable in Section 5.8.10, “Association Template,” on
page 5-60. Modified the texual description of the templates corre-spondingly
in Section 5.8.10, “Association Template,” on
page 5-60. Done [KR]. Text rewritten as part of resolution of
#1502. Done. [SC]
Implementation: There are consequential changes required to the MOF spec. The
DependsOn Association has two roles, dependent and provider,
both of which are not changeable. The add, modify_dependent,
modify_provider, and remove operations have been suppressed in
the DependsOn interface in Appendix B.1 “MOF IDL Summary”
and in Section 3.5.9, “DependsOn,” on page 3-83. Done [KR]
Implementation: Note the Reference required_elts in ModelElement is related to the
DependsOn Association, but does not require any consequential
changes as the update operations for References are always sup-pressed
(note that there is currently a contraint that forces a Refer-ence
to have the same changeability as its referencedEnd. Nothing
to do [KR].Implementation: Added text to Section 5.3.3, “Association Access and Update Se-mantics
for the IDL Mapping,” on page 5-11 to point out that an
non-changeable end in a non-derived Association is brain-dead.
Done [SC]

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.
 

Response: Yes, this should be fixed as suggested in Sections 5.3.3 and 7.3.5.
Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented.
Implementation: The resolution of “Issue 1085: Consider a better approach to gen-erated
exceptions (mof-rtf)” resulted in rewriting of all of the refer-enced
material, eliminated ConstraintViolation in the process.
Done. [SC]

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.
 

Response: Analysis of Constraints to determine precisely when they may or may not trigger
exceptions is currently impossible, since Constraints may be expressed in any "language".
Even if we prescribed a fixed language, it would be a "technically challenging" problem.
Proposed resolutions:
1. The proposed solution to #1085 effectively removes this as an IDL mapping issue,
since just about all mapped operations can now raise the "rolled up" ConstraintError
exception.
2. When the text describing Constraint validation is added, make sure that it specifies
when validation can occur.
3. Cross reference the M1 level operation semantic specifications to the Constraint
validation specifications.
Implementation: 1. The resolution of “Issue 1085: Consider a better approach to gen-erated
exceptions (mof-rtf)” has resulted in all operations in the
generated IDL being able to raise MofError which replaces theCon-straintError
exception. Done. [SC]
Implementation: 2. All constraints have a defined evaluation policy. Done. [SC]
Implementation: 3. All Classes and DataTypes with constraints cross-reference the
constrint specifications, and pick up the constraint descriptions and
names using frame cros-refs. IDL and MODL updated in Chapter 3,
“MOF Model and Interfaces”, Appendix B “MOF IDL Summary”
and Appendix C “MODL Description of the MOF”. Done. [SC]

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:
 

Response: The situation is more complex than it seems. What should we do if we discover
that the current value of an Attribute or Reference violates the applicable Constraints? Do
we raise the ConstraintError exception, or just return the value and not warn the user thatthe value is violating the model's constraints?
Deferred pending specification of Constraint verification. (#1085).
Implementation: This issue is mostly superceded by the overhaul of the exceptions in
which ConstraintError is rolled into MofError; see “Issue 1085:
Consider a better approach to generated exceptions (mof-rtf)”.
Implementation: However, we should not rule out constraint errors occuring in At-tribute
/ Reference read operations. In particular, when the At-tribute
or referenced Association is derived. This is discussed in
Section 4.11.5, “Access operations should avoid raising Constraint
exceptions,” on page 4-23. Done [SC]

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.

Response. There are four ways to handle 0..1 cardinalities.
1. We can treat them the same as 0..N cardinalities and not have special rules about "op-tional
attributes" and hence the NotSet exception would no longer be required.
2. We can treat 0..1 as being the special case of "optional". In which case, we have to have
some way to indicate a non-existent value. In the fuller text of this issue, it was suggested
that a null object-reference could be used to indicate the absence of an object-valued at-tribute
value. There are two problems with that approach. Firstly, it doesn't work with
data-valued optional attributes. Secondly, we believe that a null reference is still a valid
value for an object-valued attribute, and hence there is a semantic difference between a
null value and having no value. Therefore, if 0..1 is to be treated as the special "optional"
case, we believe the NotSet exception should be retained. That is, leave the specification
unchanged.
3. Continue to support the special case of "optional" for Attributes (since we can't solve the
problem for data types in general) and retain the NotSet exception. However, References
must always be non-null object references and hence a null reference could be used to sig-nal
"absence" allowing us to eliminate the NotSet exception for References. The disadvan-tage of this approach is that Attributes and References would be treated differently, which
violates our general approach of treating them similarly.
The other point worth noting is that it is rather futile to create an optional object-valued
attribute in circumstances where value=null and absence are not distinguished concepts.
One might as well create a single-valued object-valued attribute, and avoid the whole issue
of optionality.
Orlando RTF meeting resolutions [from the minutes]:
(a) Special handling of singleton type relationships
Recommendation: For relationships with a multiplicity of at most 1 (0..1 or 1..1),
always generate a collection interface as well as a get / set interface. [Strongly urge
always using the collection interface unless you are certain that the multiplicity will
never be greater than 1]
(b) Handling null-values
[NOTE: CORBA understands NULL for object references only, no where else!]
Recommendation: Add attribute "isNull" for all objects (Feature class may be a
good place) that indicates whether an object currently has a value of NULL.
[NOTE: there are IDL generation issues here, specifically we need setNull / isNull
methods]
DSTC Response (crawley@dstc.edu.au):
Resolution a) as minuted seems very strange. Currently we have:
If cardinality == [0..1]
<AttributeType <AttributeName () raises NotSet, SemanticError;
void set_<AttributeName (in <AttributeType new_value) raises SemanticError;
void unset_<AttributeName () raises SemanticError;
If cardinality == [1..1]
<AttributeType <AttributeName () raises SemanticError;
void set_<AttributeName (in <AttributeType new_value) raises SemanticError;
The suggested resolution seems to be to support BOTH single-valued and collection valued
get and set:
If cardinality == [0..1]
<AttributeType <AttributeName () raises NotSet, SemanticError;
<AttributeTypeSet <AttributeName_collection () raises SemanticError;
void set_<AttributeName (in <AttributeType new_value) raises SemanticError;
void set_<AttributeName_collection (in <AttributeTypeSet new_values)
raises StructuralError, SemanticError;
void unset_<AttributeName () raises SemanticError;
If cardinality == [1..1]
<AttributeType <AttributeName () raises SemanticError;
<AttributeTypeSet <AttributeName_collection () raises SemanticError;
void set_<AttributeName (in <AttributeType new_value) raises SemanticError;
void set_<AttributeName_collection (in <AttributeType new_value)
raises StructuralError, SemanticError;
Why would we want to add two extra operations for each [0..1] or [1..1] attribute that do
essentially the same thing as existing operations?? If we are going to make a change here,
it needs to be approach 1) or 2) / 3) ... NOT a strange hybrid! Also, the comment about using the collection interface unless you know that the upper
bound is 1 is weird too. A programmer who is using the interfaces generated by the IDL
mapping should ALWAYS know what the allowable upper bound is!!
Resolution b) [as minuted] doesn't make any sense either.
• It doesn't make sense to add an operation to a M2-level object (e.g. the Feature
class) that does a query on a M1-level object. This is simply meaningless.
• An "is_null" operation is unnecessary if you are also going to treat the [0..1] case
the same as [0..N]. If there is no value, the get operation will return an empty se-quence,
and this can trivially be tested.
• An "is_null" operation is pointless is you are going to continue with [0..1] defining
a get operation that returns a single value. That operation must be able to raise
NotSet, so the client code will have to catch it ... irrespective of any previous calls
to is_null!
• There is no need for a new "set_null" operation. The existing "unset" operation
does this.
Proposed resolution - close with no action. After long discussions with the originator, it
was agreed that the requested change causes more problems than it solves.
Implementation: Nothing to do. Done [KR].

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. 
 

Response: The current specification treats 0..1 cardinalities as the special "optional" case
for Attributes, but does not do so for Parameters. Currently, 0..1 cardinality Parameters
are treated as 0..N cardinality Parameters (i.e. as sequences). We don't believe the current
specification is broken. We agree that working with such parameters as sequences might
be inconvenient and we wouldn't encourage people to define metamodels using optional
parameters (since CORBA has no direct support for optional parameters), but we see no
reason to actually disallow it if people are determined to do it.
The alternative would be to define 0..1 cardinality Parameters as unions (one branch with-out a value and one branch with the value). This is intellectually cleaner, but working with
the implementation of unions is probably as inconvenient as working with the implementa-tion
of sequences.
All in all, it ain't broken, so don't fix it.
The issue of whether this is really an issue is still an issue :-)
Proposed resolution - close with no action.
Implementation: Nothing to do. Done [KR].

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.
 

Response: The surface problem is that a large number of operations in the mapped IDL can
potentially raise one or more of StructuralError, ConstraintError and SemanticError. In
target languages in which declared exceptions must be caught, having lots of unrelated ex-ceptions
make life difficult for the client application programmer. This is exacerbated by
the fact that the IDL mapping has to be cautious; i.e. include a "raises" if there is any pos-sibility
that some implementation might need to raise the exception.
The ideal solution is to handle this using generalization of Exceptions. However, this can-not
be mapped to IDL at this time ... at least not in a way that helps solve this particular
problem!
Proposed resolutions:
1. Roll StructuralError, ConstraintError and SemanticError exceptions into one ex-ception
with a signature along the following lines:
exception ConstraintError {
string error_kind;
Designator element_in_error; // Designator == RefObject
Values values_in_error; // Values == sequence <any>
string error_description;
}; The error kind strings for (old style) structural errors are defined as constants in
the Reflective IDL. The error kind strings for (old style) constraint errors are de-fined
as constants in the mapped IDL. The error kind strings for (old style) semantic
errors are user/implementation defined.
2. Define a convention for user/implementation defined error strings that avoids col-lision
with current or future instances of constraint or structural error strings.
Implementation: Section 5.4, “Exception Framework,” on page 5-24 and
Appendix B.2 “MOF IDL Summary” have been rewritten to roll
StructuralError, ConstraintError, Semantic Error and most Reflec-tive
errors into a single MofError exception. This creates conse-quential
changes throughout Section 6.2, “The Reflective
Interfaces,” on page 6-3. Done [KR, SC]
Implementation: The IDL templates in Chapter 5, “MOF to IDL Mapping” have been
revised throughout, and this has consequential effects on the gener-ated
IDL that appears throughout Chapter , “MOF Model and In-terfaces”,
Chapter , “Facility Package” and Appendix “MOF IDL
Summary”. Done [KR]
Implementation: The ConstraintViolation structure is now needed only by the verify
operation on ModelElement and hence can be moved to the MODL
in Appendix “MODL Description of the MOF” where it has been
revised to have the same content as MofError. This causes conse-quential
implications on the generated IDL for ModelElementClass
and ModelElement interfaces in Appendix B.1 “MOF IDL Summa-ry”
and the Interface presented in Section 3.4.1, “ModelElement,”
on page 3-14. Done [KR]
Implementation: Another consequence is that Section 5.8.11, “Attribute Template,”
on page 5-70 contained templates that differed only in terms of the
exceptions raised. Having merged these exceptions into MofError,
some of the templates are now duplicates, which had to be merged.
The text in that section had to be substantially rewritten to reflect the
changes in the set of templates; some subsections were added to or-ganise
the volume of text. Done [KR]
Implementation: In the process of doing the above, I noticed that the generated IDL
in Appendix B.1 “MOF IDL Summary” was not consistent with the
Attribute Template rules as regards the naming of the
"before_value" parameter in the add_*_before operations (it was
incorrectly shown as "before"). These were corrected in
Appendix B.1 “MOF IDL Summary” and correspondingly in
Section 3.4.2, “Namespace,” on page 3-22, Section 3.4.3, “Gener-alizableElement,”
on page 3-26, Section 3.4.14, “Operation,” on
page 3-47, and Section 3.4.23, “Tag,” on page 3-68. Done [KR]Implementation: Convention for error_kinds defined in Section 5.4.1, “Error_kind
string values.,” on page 5-25 [SC].
Implementation: Proposal to further "roll-up" Reflective errors, change MofError to
use a property list rather than a sequence of Any for other info, and
generally tighten up the spec of the parameters and usage. See "Ex-ceptions"
document. Done for Section 5.4, “Exception Frame-work,”
on page 5-24, Section 5.8, “IDL Mapping Templates,” on
page 5-44, and Section 6.2, “The Reflective Interfaces,” on
page 6-3. [SC]
Implementation: Updated the constraint constant decls in the Model IDL, throughout.
[SC]
Implementation: Made sure that Model::verify and the data types that it uses are cor-rectly
defined in Section 3.4.1, “ModelElement,” on page 3-14,
Appendix B.1 “MOF IDL Summary”, Appendix B.2 “MOF IDL
Summary” and Appendix C.1 “MODL Description of the MOF”.
Done. [SC]

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

Discussion: Agreed. The fuller text of the issue (see here above) provides the revised OCL
for the various affected instances.
Proposed resolution: accept corrections as supplied
Implementation: Corrections implemented. Done. [SC]

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

Discussion: After careful thought, we have concluded that there is no acceptable way to
name-mangle the "enclosing_package_ref" attributes to avoid this problem. Furthermore,
the proposal for Package clustering / consolidations ( Issue 2176) means that a "top-level"
Package instance can now be inside the extent of another Package instance. This cannot be
expressed statically in the IDL.
Proposed resolution:
1. Remove these attributes be removed from the templates.
2. Add note that the client can use RefBaseObject::repository_container() (or what-ever
its new name is) to obtain the instance for the enclosing extent.
Implementation: The enclosing_package_ref attribute has been removed from the
IDL templates and corresponding text in Section 5.8.2, “Package
Module Template,” on page 5-46 and Section 5.8.6, “Class Tem-plate,”
on page 5-54 and Section 5.8.10, “Association Template,”
on page 5-60. The immediate_containing_package and
outermost_containing_package operations have been added in
Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and
Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and in the
RefBaseObject interface in Appendix B.2 “MOF IDL Summary”.
Done [KR]
Implementation: Deleted repository_container operation from RefBaseObject inter-face.
Done. [SC]

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.
 

Discussion: Yes, this should be fixed. It's an editorial problem rather than a technical prob-lem.
Proposed resolution: Accept the suggested fixes.
Implementation: Following the removal of the generation of "#include" statements as
part of the resolution of “Issue 957: IDL Mapping--#includes for in-heritted
Packages (mof-rtf)”, the IMPORT TEMPLATE is only used
in place in the PACKAGE TEMPLATE.. Revised Appendix B.1
“MOF IDL Summary” and Appendix B.2 “MOF IDL Summary” to
remove all the ’#’-material. Done [KR].
Implementation: Rolled single use of IMPORT TEMPLATE into the PACKAGE
TEMPLATE, after splitting the latter into separate PACKAGE
MODULE and PACKAGE templates. Done. [SC]

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.
 

Discussion: Some name-mangling is inevitable, because any name in MOF (e.g. "thing"
might have to be used to form a number of differerent names in IDL (e.g. ThingSet, Thing-Bag,
ThingList). Immediately, the problem arises of whether there is already something
called "ThingSet" etc.
The other problem is that alignment with UML prevents putting MOF restrictions on names
that cannot easily map to IDL (e.g. names containing spaces) or names that are also IDL
reserved words. The problem is made doubly-difficult by the presence of concurrent RFPs
that are likely to extend the list of reserved words.
The issue of the reformating the names into format1 and format2 was based on the ORBOS
style guide (the only "standard" available to us within the OMG at the time of the submis-sion)
and perhaps might be revised in the light of the new style guide being prepared by
Dan Franz. This approach was taken to produce a more "CORBA-natural" look-n-feel to
the generated interfaces. Clearly, not everyone agrees with what is "natural" and perhaps
we need a wider survey of CORBA programmers to gain a better understanding of what is
"natural".
The comments about some forms of identifier not being covered are correct as far as the
ORBOS style guide is concerned, but this is already explicitly noted in the MOF spec and
extensions to cover these types are given.
If the IDL for MOF does not follow the formatting guidelines, then we should revise it so it
does. This suggests that there is a difference between the MOF specifications and the MOF
prototypes that were used to generate the IDL for the MOF spec.
It would be possible to resolve the name-mangling problems by having a rule that if a gen-erated
name would clash with an existing name (or IDL reserved word), then the generated
name had some suffix (e.g. "_") repeatedly added until no clash would occur. We would
generate some horrible names but they would be unique. However, to make this work, we
would need an ordering rule over generation so we would know what names were gener-ated
first (and hence what names were already in use).
Orlando MOF-RTF resolution:
We came up with three new proposals in the session.
Proposal #1 add a set of aliases [multiplicity *, ordered] to ModelElement by either (a)
extending the metamodel with an ?aliases? association from ModelElement, OR (b) using
ALIAS tagged-value pair to hold aliases.
Proposal #2 continue with existing IDL generation patterns, respecting the aliasing of pro-posal
#1. When a generator identifies a conflict
with a name, it should try the aliases that are associated with the ModelElement, in sequen-tial
order, until there is no conflict.
Proposal #3 We strongly urge IDL generators to leave behind a comment at any point in
the IDL where aliasing (or name-mangling) has occurred, indicating the element?s origi-nal
in the model, perhaps with a rationale for the name change.
DSTC Response (crawley@dstc.edu.au)
With the current MOF specification, if some choice of a ModelElement name leads to a
name clash in the mapped IDL, the modeller always has the option of changing ModelEle-ment
names. IMO it is unreasonable for the modeller to expect to choose ModelElement
names without considring the consequences in the generated IDL. From this point of view,
aliasing is an unnecessary and possibly harmful complexity. However, if we are going to add extra MOF functionality to support aliasing ... with the
extra complexity that this entails ...
Proposal #1 is a good idea, but needs more thought. Alternative a) is incomplete. What is
the type/class of the other end of the "Aliases" association? Alternative b) is not a good
idea. For aliasing to be acceptable, the MOF IDL mapping must continue to give equiva-lent
IDL for equivalent meta-models. Unfortunately the way that the Tag model element
has been defined it is not clear whether they should be used to change the meaning of a
meta-model rather than extending the meaning. Aliases certainly DO change the meaning!
At any rate, if aliases become a fundamental part of the MOF, they deserve to be a part of
the meta-meta-model, not an "afterthought" handled by an ill-defined extension mecha-nism.
I'd favour a very simple approach of adding extra attributes to ModelElement; for example
attribute optional string preferred_name;
which might give a single name to be used in place of the ModelElement name in all cases,
or
attribute ulist [0..*] of string alternative_names;
which might give a set of alternatives to be used if the primary ModelElement name gives
a name clash. (More about this below)
Proposal #2 is nice in theory, but in practice it makes IDL generation a lot harder. Cur-rently,
an IDL generator can simply generate according to the templates, and throw the
IDL at a standard IDL compiler to validate it. Any name clashes are the modeller's prob-lem.
With proposal #2, the IDL generator needs to know that IDL it would generate con-tains
a name-clash. This entails building a symbol table for the IDL as it is generated, AND
generating it in a particular order to get the substitutions to work correctly.
Proposal #3 needs to be tempered with reality. Just about every identifier in the generated
IDL is going to have been subjected to some form of name mangling. Generating masses
of comments about name mangling etc is going to make the IDL unreadable. In practice,
the name mangling rules used by the IDL mapping produces IDL that is highly readable
and not needing comments.
(New) Proposed resolutions:
1. Define a Tag name or names for Tags that allows a user to supply a substitute name
for a given Model element in the IDL mapping. The simplest viable alternative is to
supply a name that replaces the ME name prior to any name formatting and man-gling.
Another alternative is to do pattern matching and replacement after name
mangling based regular expressions supplied in a Tag for a model element.
2. Include recommendation that these Tags should be contained by the Package de-noting
the meta-model.
3. Rule that the wider issue of name mangling in MOF is beyond the scope of the RTF.
Implementation: Added text for 1 and 2 in Section 5.6.2, “Tags for providing substi-tute
identifiers,” on page 5-36. Added additional bullet to
Section 5.5, “Preconditions for IDL Generation,” on page 5-33 to
deal with the fact that the MOF Model does not require model ele-ment
names to be legal IDL identifiers! Similar fix made to “Rules
for Splitting MOF Model::ModelElement Names into "Words"” on
page 5-39. [SC] Implementation: Updated Chapter 3 definitions of MofException -> Exception and
MofAttribute -> Attribute, using the "Alternative Name" Tag. Up-dated
MODL. Done. [SC]
Implementation: Documented that at most one instance of this Tag is allowed per
ModelElement: Section 5.6.2, “Tags for providing substitute identi-fiers,”
on page 5-36. Done. [SC]

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

1 Discussion. Editorial problem to be fixed as indicated.
2 Proposed resolution: accept corrections as supplied.
Implementation: 1. Fixed as a byproduct of adding a raises clause to all with_* op-erations
in the resolution of “Issue 1078: Association interface gen-eration
templates require exceptions (mof-rtf)”. Done [KR].
Implementation: 2. Added the underscore to the add_before_* template in
Section 5.8.10, “Association Template,” on page 5-60. Done [KR].

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.
 

1 Discussion: These errors are the result of a bug in the prototype IDL generator
used to prepare the MOF spec, and (as with other issues) can be fixed by redoing the IDL
generation. [No changes to the IDL mapping (chapter 7) are required.]The above problem
was corrected in the Errata version of the submissionm, ad/97-10-02 and ad/97-10-03. Al-so,
UML IDL generation was not affected.
Implementation: Nothing to do. Done [KR].

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.
 

1 Additional Text:
2 There are many possible conventions for tag name format. For example:
3 Java-like:
4 "org.omg.MOF.some_tag"
"org.omg.BOCA.some_other_tag"
"com.rational.rose.screen_position"
"au.edu.dstc.elvin_event_type"
5 Domain name : tag name:6 "omg.org:MOF.some_tag"
"omg.org:BOCA.some_other_tag"
"rational.com:rose.screen_position"
"dstc.edu.au:elvin_event_type"
7 Etcetera
8 Proposed resolution: accept in principle pending concrete proposal.
Implementation: Added text to Section 3.4.23, “Tag,” on page 3-68 to recommend
that Tags be named in the Java-style (using the reversed Internet do-main
name as a prefix). Done. [SC]

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.
 

1 Additional Text:
2 The aim of this proposal is to reduce the footprint of the generated IDL for MOF
meta-models.
3 On the plus side, if a repository supports many Packages, the corresponding IDL
only needs one copy of any base-type multiplicity typedef. [Currently, you could get dis-tinct
typedefs in each generated module; e.g. for the boolean data type you could have
Foo::BooleanUlist and Bar::BooleanUList.]
4 On the down side, this means that the IDL footprint now has to include typedefs for
multiplicities of all base types. [Currently, no typedef is generated for a multiplicity that is
not used.]
5 Whether or not this proposed change will change the runtime (i.e. code size) foot-print
for a model client or server depends on the quality of each ORB implementation.
However, it should be easier for an IDL compiler to optimize the code footprint if the com-mon
typedefs are separated out.
6 Status: no progress. The impact of this proposal needs more analysis.
7 Washington: If the typeDefs are factored out into a common module, then fully
qualified names need to be used.
8 RESOLUTION : Factor out the multiplicities into Reflective.IDL Implementation: Removed the generation of collection kinds for built-in types from
Section 5.8.2, “Package Module Template,” on page 5-46 and add-ed
the collection kinds for built-in types (short, long, unsigned short,
unsigned long, float, double, boolean, char, string, octet, any, Type-Code,
Object) to Section 6.3.2, “Data Types,” on page 6-34 and
correspondingly in Appendix B.2 “MOF IDL Summary”. The text
on generating collections of CORBA built-in types in Section , “Lit-eral
String Values,” on page 5-42 has been revised to reflect the ex-istence
of these pre-defined collection types. Note the list of built-in
types was taken from Table 5-11, “Base Names for Built-in CORBA
Types,” on page 43, but it was noticed that this table omitted
"string" so "string" was added to the table. Since usages of these
collections must now be full-qualified, there were consequential ed-its
required in the TagClass and Tag interfaces in Section 3.4.23,
“Tag,” on page 3-68 and also in Appendix B.1 “MOF IDL Summa-ry”.
[KR]
Implementation: The above resolution has been reversed following "RTF member
pushback".
Implementation: Removed declarations of built-in type collections from Section B.2,
“Reflective IDL,” on page B-36 [SJM].
Implementation: The other changes to Section , “Literal String Values,” on
page 5-42, and Section 5.8.2, “Package Module Template,” on
page 5-46 and to the IDL have been reversed. Done. (sigh) [SC]

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.
 

1 Additional Text:
2 So far, DSTC have thought of two possible solutions.
• Change Reflective::RefObject and Reflective::RefPackage interfaces to inherit
from COSLifecycle. If COSLifecycle is inappropriate, add the necessary lifecycle
operations into the Reflective objects directly.
• Define some Tags that allow a meta-modeller to indicate which Operations in the meta-model provide the semantics of 'move', 'copy' and 'delete'. To assist interop-erability,
the operations would need to conform to an agreed signature template; e.g.
the 'delete' operation might take no parameters, and the 'copy' operation might take
a 'boolean' argument and return an object.
Note: if we add life-cycle operations at the M1 level, this may impact on the M2 level spec;
i.e. we may need to change or remove the 'copyElement' and 'removeElement' operations
on ModelElement (see 3.7.1)
Status: no progress. This proposal requires careful analysis.
Washington: Resolution: Add the life cycle operations Copy, Delete and Move to Ref-BaseObject
. Include signatures that accommodate deep copies to handle aggregation and
association semantics.
With the resolution to issue 784, these interfaces could be integrated with COS::lifeCycle
by using resolution #784 which accomodates existing interfaces in a MOF based metamod-el.
Also look at Internalize and Externalize for RefBaseObject.
Action : Unisys - to make a proposal for these operations before next meeting.
Following further discussion, it was agreed to experiment with adding delete to Ref-BaseObject,
but no decision has been taken on copy/move/internalise/externalise.
Implementation: Added the ref_delete operation to RefBaseObject in Section 6.2.2,
“Reflective::RefBaseObject,” on page 6-5. Created a new Invalid-Deletion
error kind for MofError exception in Section 5.4.6, “Re-flective
Errors,” on page 5-30. Added the ref_delete operation to
the IDL in Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5
and Appendix B.2 “MOF IDL Summary”. [KR] Reviewed and re-vised
to include description of rules relating to nested Package.
Done [SC].
Implementation: As a consequence of adding delete, we can get rid of the
remove_element operation from ModelElement in Section 3.4.1,
“ModelElement,” on page 3-14 and Appendix C.1 “MODL De-scription
of the MOF” and Appendix B.1 “MOF IDL Summary”.
Done [KR]
Implementation: Text describing Attribute and Association lifecycle issues added to
Section 5.3.2, “Lifecycle Semantics for the IDL Mapping,” on
page 5-7, “Link lifecycle semantics” on page 5-10 and “Life-cycle
Semantics for Attributes” on page 5-20. Done. [SC]

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.
 

Proposed resolutions:
1. This issue only applies to Associations / AssociationEnds with aggregation ==
composite case (and the similar case for Attributes: see Issue 1770).
2. This is valid at the M2 level, assuming that the proposed "Package cluster / consol-idation"
resolution to Issue 2176 is adopted.
3. At the M1 level, if we replace "package boundary" with "package extent" and define
the extent of a clustered package to be the cluster, then composite aggregations can
be legal if-and-only-if they don't cross an outermost extent boundary. [The same
rule that applies to composite Attributes.]
Implementation: Definitions of extents appear in Section 4.6, “Extents,” on page 4-9.
Composite aggregations crossing extent boundaries forbidden at
the M1 level by Section 4.9.2, “The Composition Closure Rule,” on
page 4-19.
Implementation: Aggregation semantics of Attributes and Associations discussed in
Section 4.8, “Aggregation Semantics,” on page 4-16 and
Section 5.3, “Computational Semantics for the IDL Mapping,” on
page 5-6. Done [SC].

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.

Here are some examples:
• As described in 5.3.3, some operations can potentially cause more than one viola-tion
of structural constraints. For example, if you have an "attribute set of [0..2]
char foo" whose value is "['a', 'b']" and you invoke "add_foo('a')". The spec does
not say if an implementation has to return BOTH "overflow" and "duplicate" in the
'violations' parameter of StructuralError.
• In section 5.5.3 it was intended that an implemention be allowed to return a nil ob-ject
reference as the 'element_designator' in a StructuralException if no M2 objects
are available. [This is in line with "Reflective::RefBaseObject::meta_object"]
• Sections 5.2 and 5.4 should spell out precisely which exceptions (and for Struc-turalError,
violation_kinds) should be raised under which circumstances.
• The operations whose signatures are defined by the IDL mappings in Section 7
should be more fully described. They should be cross referenced to the correspond-ing
Reflective operations in 5.2 / 5.4 and semantic specs in Section 6.
• We should reorganize the text so that related text in Sections 5 and 6 are in the same
place. For example, details of semantics of M1 level operations are now spread
through 5.2, 5.4 and 6.2.
Status: no progress. Substantial editorial work is required
Washington : Good Suggestion, Prioritize the editorial fixes after all significant technical
issues (eg:IDL generationa are resolved)
Implementation: Specific and reflective operation specifications completely rewritten
in much greater detail. The new specs document exceptional condi-tions
for each operation, and define the specific / reflective ana-logues.
Done. [SC]
Implementation: (Some section introductions need rewriting - editorial.) [SC]

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.
 

Discussion - crawley@dstc.edu.au: In recent between DSTC and UNISYS, these points
have become clearer:
1. The Facility section tries to address the problem of clustering Packages. This prob-lem
is really a core meta-modelling issue rather than a "repository" issue. UNISYS
agree with this analysis, and DSTC and UNISYS have jointly developed the "Pack-age
Clustering" Model extension (see issue 2176) to address this aspect.
2. The Facility "package" can also be understood as a design pattern that uses the
MOF meta-modelling constructs to extend the interfaces of M1 level instances of a
Package in a meta-model. For example, ModelRepository adds hierarchical nam-ing
of Model::Package instances and some convenience functions, and MofPack-age
adds support for external Tags.
3. The Facility section was not intended to define a MOF repository architecture.
4. UNISYS have (I believe) agreed that Facility can be an optional compliance point.
Proposed partial resolution:
1. The Facilities chapter should be made an optional conformance point.
2. The use of MofRepository as Package clustering mechanism should be deprecated
in favour of the proposed Model extension for Package consolidation.
3. MofRepository instances should contain (freezable) TagSets rather than Tags, and
a mechanism should be implemented that allows a client to find the relevant Tags
starting from an M1 level RefPackage instance.
4. The Facilities chapter should be updated to make it clearer what its purpose is. It
is important to separate the "design pattern" from the "application" of that pattern
to extend the functionality of the MOF Model.
Further discussion - crawley@dsct.edu.au:
1. Does the MOF specification need to address conventional repository issues? For
example, should it define interfaces that provide a "top level" naming structure for
models and meta-models? Should it specify / discuss how to implement different re-pository
architectures; e.g. "open", "closed" and "single model".
2. While it is appropriate using modelling to specify extensions to the functionality of
Package instances, is it appropriate to use the MOF Model to IDL mapping to im-plement
them?:
• Pro: the Facility approach allows you to implement required "repository"
extensions without changing the base meta-model. Using the MOF Model
mappings to generate the interfaces and implementation avoids the need to
hand write IDL, MDL, Java classes and so on.
• Con: the Facility approach gives bloated IDL. For example, the IDL for Fa-cility
contains 6 interfaces, where only one would be required to implement
the same functionality extensions directly in IDL.
1. Is the Facility pattern the best way to extend functionality? Would alternative mod-elling
patterns would give better interfaces? For example, if we defined Facility as a subtype package of Model and MofRepository as a subtype class of Package, we
wouldn't need to have the "kludge" of a MofRepository object with a Model::Mod-elPackage
object as an attribute.
One way to "address" the repository architectures and interfaces requirements is to rule
them out of scope for the RTF. We should then consider issuing a new RFP to address these
issues.
Washington - A proposal to support COS::Naming and JNDI for name service is being re-searched
to address some the issues identified. Proposal to be made before March meeting.
Post-Washington discussion: In view of resourcing this RTF, it was decided to defer this
issue to MOF2. The existing Facility material will be removed to avoid people implement-ing
it now and then objecting if we try to do something different in MOF2.
Pre San Jose - The AB has (informally) intervened to point out that an RTF is not allowed
to make major changes a CORBA spec. Dropping the Facility Package would be consid-ered
by the AB to be a major change.
The RTF has therefore reversed its decision to drop the Facility Package chapter. Instead
it has decided to add a BIG NOTE saying that it recommends that the material be replaced
at the earliest opportunity. Other references to the Facility Chapter have (already) been
eliminated.
It is sincerely hoped that MOF implementors will take the hint and not spend time trying to
implement the current Facility Chapter material.
Implementation: Moved Facility Package chapter to make it Chapter 7. Reinstated
Facility to the definition of the first MOF compliance point. Added
notes to say what the RTF recommends. [SC 24/9/99]
Implementation: Deleted a paragraph describing the Facility Package from
Section 3.3, “The Structure of the MOF Model,” on page 3-10. Re-moved
mention of the Facility Package from first paragraph in
Appendix “MOF IDL Summary”. Removed the Facility IDL section
from Appendix “MOF IDL Summary”. Removed mention of the Fa-cility
Package from first paragraph of Appendix “MODL Descrip-tion
of the MOF”. Removed the Facility MODL section from
Appendix “MODL Description of the MOF”. [KR]
Implementation: Removed the reference to the Facility Package in the is_singleton
attribute in Section 3.4.6, “Class,” on page 3-33. Done [SC] The problem of the Facility chapter not being "fit for purpose" remains.  The revised MOF RTF 1.3 report says we intend to address this issue urgently. 

"A Strawman Proposal for  MOF 1.4 Repository Framework" by Steve C is 15 page document proposing a solution.  PLEASE READ IT! 

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?
 

Discussion: This issue highlights an anomaly in the mapped IDL when a Class is defined
as a subtype of an imported Class. The M1 level interfaces for the subtype Class inherit a
factory operation for the supertype Class that can't be implemented for an independent
Package instance.
Possible solutions:
1. Remove the create anomoly by forbidding generalization of imported Classes.
Problem: this is too important / useful a meta-modelling capability to lose.
2. Restructure the mapped IDL so that the anomalous operation is not inheritted. For
example, move the classes factory operation into the Package interface for the en-closing
Package. [If we move the IDL operations for classifier-level Attributes and
Operations into the Class instance interface, we can get rid to the the Class proxy
interface entirely!] Problem: this change has substantial impact on current MOF
implementations.
3. Define that the anomalous inheritted factory always returns nil or raises an excep-tion.
Problem: we don't need to go this far. In particular, if the imported Class and
the subtype Class are within the same extent, the create operation is implementable.
4. Define the behaviour of the inheritted factory operation to be valid when the Pack-age
extent includes proxies for both subtype and supertype Classes, and to raise an
exception othewise.
Proposed resolutions:
1. Add an extent-based restriction on creation of instances with an imported super-type.
Applies to instances of both the Class and its imported supertype Class.
2. Raise a new kind of structural ConstraintError when the above rule is violated.
Implementation: The supertype closure rule is defined in “The Supertype Closure
Rule” on page 5-22, and there is a new error kind "Supertype Clo-sure";
see Section 5.4.2, “Structural Errors,” on page 5-26. The
specific and reflective versions of the create operation updated to
track this. Done. [SC]

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

Discussion:
In the case where multiplicity.upper == 1, the result will be either an object reference for
an object of the 'other' association end's type, or a nil object reference. A nil object refer-ence
can be returned in both the [0..1] case, and in the [1..1] case if the package object has
not been validated.
In the case where multiplicity.upper > 1, the result will be a sequence of (possibly zero)
non-nil object references, where thesequence will contain no more than multiplicity.upper
elements, but could contain less than multiplicity.lower if the package object has not been
validated.
[Aside: in the case where multiplicity.upper == 1, it is no problem for with_* to return a
nil object reference, since it is impossible to create a link involving nil. This contrasts with
multi-valued attributes or parameters where nil object references are legal.]
Proposed resolution: update descriptions as above.
Resolution: If the multiplicity is 1..1, then an object reference is returned. If for any reason
there is no reference to return, the Underflow error kind of MofError is raised. For all oth-er
multiplicities, the result will be a sequence (possibly zero) non-nil object references,
where the sequence will contain no more than multiplicity.upper elements, but could con-tain
less than multiplicity.lower (but does not raise the Underflow exception).
Implementation: This is now documented in Section 5.8.10, “Association Template,”
on page 5-60. Note that these operations have been renamed as part
of the resolution of “Issue 1715: Navigability constraint expressed
wrongly (mof-rtf)”. Done [SC]

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.
 
 

The case where "upper == 1" is the following:
association A {
role set [X..Y] of Type1 role1; // any consistent X and Y
role set [Z..1] of Type2 role2; // Z == 0 or 1
}
type Type1 {
...
known my_ref projects role1 of A;
}
type Type2 { ... }
When you use set_my_ref() to create / modify a link, it may be necessary to raise Structural-Error
in the following circumstances:
• X != 0 may need to signal underflow; e.g. if t1.my_ref() has a value t2, this means
there must have been a <t1, t2>. Replacing this with <t1, t3can cause the number
of T1's related to t2 to drop below X.
• Y != '*' may need to signal overflow; e.g. whether or not t1.my_ref() has a value,
adding <t1, t2> can cause the number of T1's related to t2 to exceed Y.
It seems that the only case where StructuralError can never be raised is when X == 0 AND
Y == *.
Proposed resolution:
1. The IDL mapping problem is fixed by the proposed solution to issue 1085; i.e. the
"rolled up" ConstraintError.
2. The semantics described above need to be documented.
Implementation: The set_<reference> templates in Section 5.8.12, “Reference Tem-plate,”
on page 5-81 all raise MofError (which subsumes Struc-turalError)
as a by-product of resolving “Issue 1085: Consider a
better approach to generated exceptions (mof-rtf)”. Added text to
Section 5.8.10, “Association Template,” on page 5-60 to make it ex-plicit
that multi-valued References must be given the correct number
of values. Done [KR].

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?
 

Discussion: If this is legal then the semantics should be spelled out. We should alsodecide
if this makes the unset_<reference_name operation redundant.
If this is illegal, then operation needs to be able to raise StructuralError in all cases to in-dicate
an invalid link.
In favour of making set_<referefencename>(nil) legal is that it is legal in the attribute
case. On the other hand, setting a reference to nil is semantically different to setting an at-tribute
to nil: this is another example of the "nil != not present" issue.
FONT COLOR="#FF0000"Proposed resolution: This should raise StructuralError. Am-mend
the text of 7.3.8 to make this clear.
Implementation: As a byproduct of the resolution of “Issue 1085: Consider a better
approach to generated exceptions (mof-rtf)”, the set_<reference>
operations already return MofError (which subsumes StructuralEr-ror).
Added text to Section 5.8.12, “Reference Template,” on
page 5-81 requiring that the new value(s) supplied must be non-null
references. Done [KR].

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.  
 

This means that a model element in a metamodel will be identified by an id that will not
change from one release to another if a concept does not change (even if the name of one
of the enclosing packages chages)and the id will change if the meaning changes (e.g a local
meta attribute is deleted or gets a new data type, a local meta-relationship is deleted), even
if the name does not change.
Discussion (crawley@dstc.edu.au):
I agree that there is a need for something like this. For example, without it, it is hard to
implement a reliable, efficient caching mechanisms. [This is biting me at the moment ...]
However, I think that such a facility needs to apply to all MOF meta-models not just to the
MOF meta-meta-model. Assuming this is so, the correct place to put such functionality is in Reflective::RefObject or maybe Reflective::RefBaseObject.
We also need to precisely specify the domain(s) of the identifiers uniqueness, and/or decide
what should not be specified:
• Temporal: should identifiers last forever, or can the be recycled i.e. used on a new
object? If an object that has been deleted is "returned from the dead" (e.g. restored
from a backup) should it have its original identifier or a new one?
• Logical: should the domain in which object identifiers are required to be unique be
a) the "package instance", b) the "repository", c) the MOF server, d) a federation
of MOF servers, e) all MOF servers, or f) something else.
• Physical: should logical copies of the same meta-object have different identifiers?
I'm particularly concerned that any identifier scheme works (has acceptable semantics,
and has a reasonable implemention without "magic") in centralized, federated and discon-nected
meta-data repository scenarios.
I think this presupposes an analysis of the requirements; i.e. what do people want to be able
to use these identifiers for?
Discussion (Sridhar.Iyengar2@unisys.com):
Agree that the identity solution needs to apply to all MOF compliant meta models and that
the Reflective interfaces are an appropriate mechanism to expose these interfaces
In general - I think reusing Ids (from dead objects) is a problematic one.
In general copies should have their own identity, with potentially optional associations to
'originator'
Logical - I need think this thru - Feel it should at least be a federation of MOF servers. I
dont know any easy way of enforcing 'all MOF servers'
Discussion (crawley@dstc.edu.au):
I discussed this further with various people around the time of the Seattle meeting, and
came to the conclusion that different people have up to three (and maybe more) kinds of
unique identifiers in mind:
1. Identifiers that can be compared to test for object identity of (mutable) MOF meta-objects.
2. Identifiers that can be compared to test for value equivalence of (immutable) MOF
meta-objects.
3. Identifiers that can be compared to test if two distinct meta-objects denote "corre-sponding"
meta-objects in a model / meta-model, where details of the concept's rep-resentations
may differ. For example, they might be used to relate objects that
"correspond" after a round-trip model exchange, or objects in different models that
denote the same "concept".
Of these, we can currently only implement the first kind of identifier. The other two require
additional mechanisms that the MOF does not currently provide.
Proposed resolution:
1. Add a new operation to RefBaseObject to return a meta-object's identifier.
2. Define the external representation of identifiers as based on human readable
strings, using a prefix to distinguish formats. 3. Require identifiers to be unique in time across all domains with actual or possible
connectivity. Suggest DCE UUIDs as the preferred identifier mechanism.
4. Define binding between object and identifier as being one-to-one and immutable
through the lifetime of the object. In other words, no reuse of identifiers after object
deletion, and no changing of an object's identifier while the object exists ... in any
form.
5. State that a MOF implementation is non-compliant if its identifiers are locally
unique but are non-unique in the context of actual interoperation. Ditto for a MOF
implementation that does not implement binding rules in the context of actual inter-operation.
6. Rule other kinds of unique identifier out of scope for the MOF RTF.
Implementation: Added a description of the mof_id operation to Section 6.2.2, “Re-flective::
RefBaseObject,” on page 6-5 with the description of it be-ing
unique and immutable. Also added the mof_id operation to the
IDL in Section 6.2.2, “Reflective::RefBaseObject,” on page 6-5 and
Appendix B.2 “MOF IDL Summary”. [KR]
Implementation: Added text on semantics, including text on ensuring uniqueness and
on conformance to Section 6.2.2, “Reflective::RefBaseObject,” on
page 6-5. [SC]
Implementation: Removed the Section "Requirements to Support Object Identity"
from Appendix “MOF Implementation Requirements” as there now
is a system of MOF object identification. Done. [KR] This issue was closed following MOF RTF 1.3.  However, an AB member (Jeff Mishinsky?) suggested that the RTF ought to standardise a preferred format for MOF id strings, rather than just describing the properties that MOF ids must have. 

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.
 

Discussion: (crawley@dstc.edu.au) I now think that this is unnecessary.
Proposed resolution: close with no action.
Implementation: Nothing to do. Done [KR].

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. The correct way to model this is to define separate
'multiplicity' attributes on MofAttribute and Reference. The 'multiplicity' attribute on Mo-fAttribute
is a "real" one. The 'multiplicity' attribute on Reference is a derived one.
This issue illustrates a shortcoming in the MOF Model; i.e. that there is no way to "over-ride"
derived with non-derived or vice-versa.
Proposed resolutions: Add text to section 3 to document the anomolous extra attribute.
Implementation: Added text and a note explaining this to Section 3.4.12, “Refer-ence,”
on page 3-44. Done [KR].

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.
 
 

Status: Resolved, to be implemented.
Washington:
If isNavigable is set to false, then it is not possible to naviagate from otherEnd to thisEnd.
This will suppress one of the with Operation in Association Interface and the ability to cre-ate
references in the other end.
This raises the issue that the 'WITH' operation of the Association Interface may be mis-named
because the current operation name is based on input parameter not the result.
Make WITH and MODIFY consistent.
If an AssociationEnd called X has isNavigable set to false, then the with_X operation will
be suppressed in the association interface AND no references may be created on the class
at that AssociationEnd.
Issue : Potential UML alignment issue
Following discussions with the UML RTF, the following points of agreement have been
established. Consider the example of two Classes Man and Woman with an Assocation
called Married with AssociationEnd husband (of type Man) and AssociationEnd wife (of
type Woman).
If the husband AssociationEnd is not navigable, then it is not possible to navigate from a
wife to her husband(s), but it is possible to navigate from a husband to his wife(s). There-fore,
it is not possible to create a Reference for which husband is the referencedEnd (e.g. it
is not possible to create a my_husbands Reference in the Woman class). Also, any opera-tion
that must lookup the husbands of a wife must be suppressed. That is, the operations
"with_wife" and "modify_husband" must be suppressed. It was also agreed that the
"with_wife" operation is poorly named, and that calling it "husband" would be more logi-cal.
That means, that if the "husband" AssociationEnd is not navigable, the "husband" and
"modify_husband" operations are suppressed.
Implementation: Replaced all the "with_<end1>" operations by "<end2>" opera-tions
in Section 5.8.10, “Association Template,” on page 5-60, and
reordered them so that the "<end1>" operation will appear before
the "<end2>" operation. Updated the text describing this genera-tion
in Section 5.8.10, “Association Template,” on page 5-60. Re-vised
the following interfaces in Appendix B.1 “MOF IDL
Summary”: AttachesTo, DependsOn, Contains, Generalizes, Alias-es,
Constrains, CanRaise, Exposes, RefersTo, IsOfType. Propagat-ed
these changes through to Section 3.5.1, “Contains,” on
page 3-71, Section 3.5.2, “Generalizes,” on page 3-73,
Section 3.5.3, “RefersTo,” on page 3-74, Section 3.5.4, “Exposes,”
on page 3-76, Section 3.5.5, “IsOfType,” on page 3-78,
Section 3.5.6, “CanRaise,” on page 3-79, Section 3.5.7, “Aliases,”
on page 3-80, Section 3.5.8, “Constrains,” on page 3-81,
Section 3.5.9, “DependsOn,” on page 3-83, Section 3.5.10, “At-tachesTo,”
on page 3-85. Done [KR] Implementation: Revised the IDL generation rules in Section 5.8.10, “Association
Template so that <associationend> operations (formerly "with_*"
operations) and modify_<associationend> operations are only gen-erated
if the association end is navigable. Done [KR]
Implementation: There are no non-navigable association ends in the MOF model, so
there are no changes required to the IDL in the MOF spec. [SC]
Implementation: Revised the constraint on AssociationEnd to be a constraint on Ref-erence
instead. See “ReferencedEndMustBeNavigable” on
page 3-108. Done. [SC]
Implementation: If association modify operations are suppressed for non-navigable
ends, Don says that association add_before ops should be too. His
reasoning is that you have to navigate (index?) the before end. Im-plemented
this in Section 5.8.10, “Association Template,” on
page 5-60, and Section 6.2.4, “Reflective::RefAssociation,” on
page 6-25. Also rewrote the description of isNavigable in
Section 3.4.17, “AssociationEnd,” on page 3-53, and Section 4.7.4,
“AssociationEnd Navigability,” on page 4-16. [SC]
Implementation: Documented what is happening with the UML diagrams where our
convention is that an association with an arrowhead indicates that
there is a reference: Section 3.2.7, “UML Diagrams,” on
page 3-10. Also that all ends are navigable: “References” on
page 3-5. Done. [SC]

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.
 

Proposed resolution. Correct the MODL and IDL in the appendices so that the TypeAlias's
multiplicity attribute is non-optional.
Implementation: Superceded by “Internal 1: Drop the multiplicity attribute on Ty-peAlias
(mof-rtf)”. Done [SC]

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.
 

This is a duplicate of #Issue1712
Implementation: No action required on this duplicate. Done [KR].

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.
 

This is a duplicate of #Issue1711
Implementation: No action required (duplicate). Done [KR].

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.
 
 

Proposed resolution: Correct all relevant parts of the MOF spec to make the cardinality of
the 'referent' end [0..*].
Implementation: Changed the multiplicity for referent and referrer in the MODL in
Appendix C.1 “MODL Description of the MOF”. Changed the mul-tiplicity
for referent to be (0..*; not ordered; unique) in both the de-scription
and the IDL in Section 3.5.3, “RefersTo,” on page 3-74
and the RefersTo interface in Appendix B.1 “MOF IDL Summary”.
Same changes made to referrer in Section 3.5.4, “Exposes,” on
page 3-76 and the Exposes interface in Section B.1, “MOF Model
IDL,” on page B-1. There do not appear to be any References in the
MOF Model to either the referent or referrer AssociationEnds, so
there are no consequential changes required. Done [KR].

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

Discussion: a resolution needs to reconcile the following:
• The UML model of Attributes (apparently) makes attribute values components of
class instance.
• The CORBA IDL model of attributes makes the attribute value holders the class in-stance
components.
• For MOF Attribute values that may be "ordinary" CORBA object references, (i.e.
those defined using DataTypes), we cannot implement MOF composition seman-tics.
• There is a requirement for a light-weight (i.e. minimal runtime cost) way of attach-ing
Class instances to other Class instances. The non-composite Attribute seman-tics
currently provide this.
Alternatives:
1. Status quo. MOF Attributes have no composition semantics. The Class instance is
a composition of holders rather than of values.
2. UML approach. All MOF Attributes are composites. CORBA data types, but how
do we support composite semantics for "ordinary" CORBA objects?
3. Hybrid approach. MOF Attributes whose types are specified as Classes are com-posites
are those whose types are specified as DataTypes are not.
4. Attribute Aggregation. Add an "aggregation" attribute to Attribute with the same
semantics as the AssociationEnd "aggregation" attribute. This requires a change to
the MOF Model that diverges further from the UML metamodel.
Assuming that we allow do Attributes to have composite aggregation semantics, how do we
implement it efficiently? It cannot be done by looking at all instances of all Classes that
have Attributes with an appropriate Class. The only scalable algorithm is as follows:
// Return true iff it is legal to assign `obj' to an attribute
// of `container'
boolean is_composition_legal(Object obj, Object container) {
if (obj.my_container() != null)
return false;
while (container != null) {
if (container.my_container() != obj)
return false;
container = container.my_container();
}
return false;
}
There are two problems with the above:
1. It assumes that you can find the container of any object. This is currently "magic".
To fix this we need to add a "my_container()" operation to RefObject.
2. The cost of the test is O(N) where N is the depth of containment of the container.
On the other hand, if we add a "my_container()" operation to RefObject, we make it possi-ble
to implement composite aggregation on Associations more efficiently. (Currently, it
may be necessary to check multiple composite Associations.)
Proposed resolutions: 1. Support the following Attribute type / aggregation semantic combinations:
• Class: either "composite" or "none",
• CORBA datatype: "composite" only with all embedded interface types
"none", "ordinary" CORBA interfaces: "none" only.
1. Model the choice of aggregation semantics for Class valued Attributes using
DataTypes.
2. Add an operation to RefObject to return an object's container. For example:
RefObject container(in nos_levels);
When called with nos_levels == 1 returns the container (or nil), with nos_level ==
2 returns the container's container (or nil) and so on. When called with nos_levels
== -1, returns the outermost container (or nil).
For consistency with immediate_containing_package and
outermost_containing_package, two new operations immediate_container and
outermost_container are proposed for the RefObject interface. Note that these op-erations
are about "logical" containment of RefObjects through M1-associations
and not the physical containment of RefObjects within a given RefPackage. Thus
these new operations will always return RefObject. For consistency, it raises NotSet
if there is no container object.
Implementation: Added text and IDL for the immediate_composite and
outermost_composite operations in Section 6.2.3, “Reflec-tive::
RefObject,” on page 6-10 and in the RefObject interface in
Appendix B.2 “MOF IDL Summary”. [KR] Rewritten. [SC]
Implementation: Documented that if the appropriate composite attribute is class-lev-el,
then the result will be the class proxy. [SC]
Implementation: It has been agreed that embedded Class references are pure object
references without any containment semantics. Documented in “In-stance
object lifecycle semantics” on page 5-9. Done [SC]

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.
 
 

Proposed resolution:
1. Add text to state that Constraints should not be used to over-ride inate behavior of
the M1 level semantic model.
2. Add text to state that evaluation of Constraints as part of immediate or deferred val-idation
should have not any side-effects on any state (visible or hidden). In other
words, the order and timing of Constraint evaluation has no effect apart from de-termining
which constraint error exceptions get raised.
Implementation: Covered 1) in a rewrite of Section 3.4.21, “Constraint,” on
page 3-64. Covered 2) in Section 4.11.4, “Constraint evaluation
should not have side-effects,” on page 4-23. Done. [SC]

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.
 
 

1. Add text to define "visible state" (object identity, non-derived attribute values and
links) and "hidden state" (other state).
2. Add text to specify which mapped operations can alter which kinds of state. For ex-ample,
setting a non-derived attribute cannot have side-effects on any other visible
state.
Implementation: Added above as subsections of Section 4.11, “A Style Guide for
Metadata Computational Semantics,” on page 4-21. Done. [SC]

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.
 
 

Discussion: (crawley@dstc.edu.au)
In the absence of better ideas, I suggest that we follow the pattern of the CosNaming::Not-Found
exception with the tightened up semantics defined by the DSTC et al extended name
service submission. (We can't directly reuse the CosNaming exception because the base
types are wrong for our purposes.)
Status: no progress
Washington - Resolved : Exceptions parallel to how COS::Naming does will be considered.
Reviewed the new Interoperable Naming spec and determined that there are 4 possible
kinds of failure. In keeping with the philosophy of not creating too many exceptions, these
can all be returned by the existing exception NameNotResolved with different parameteri-sation.
Implementation: Revised Section 3.7, “MOF Model Exceptions,” on page 3-92 so
that the NameNotResolved exception now has two parameters: ex-planation
(string) and restOfName (ordered not-unique 0..* of
NameType). The explanation can be "InvalidName", "Missing-Name",
"NotNameSpace" or "CannotProceed" and the first name of
restOfName is the name that could not be resolved satisfactorily.
Revised Section 3.4.2, “Namespace,” on page 3-22 to update the
IDL for the NameNotResolved exception. Revised the MODL in
Appendix C.1 “MODL Description of the MOF”for NameNotRe-solved
and the IDL in Appendix B.1 “MOF IDL Summary”. Done.
[KR]

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.
 

Without this detail in the specification, a client cannot make any assumptions about the
state of a MOF model after a ConstraintError exception has been raised. This is particu-larly significant for those operations on References that make changes to multiple links.
Proposed resolution:
1. Document that all operations should be atomic. If they return normally, all neces-sary
state changes are made. If they raise any exception, no state changes are made.
2. Document that this is orthogonal to the issues of persistence and transactions / roll-back
involving multiple operations.
Implementation: Added Section 5.3.7, “Atomicity Semantics for the IDL Mapping,”
on page 5-22 to address this. Done. [SC]

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.
 

 resolved, to be implemented

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.
 

The latest draft revision of the CORBA chapter 3 spec says:
"The name of an interface or a module may not be redefined within the immediate scope of
the interface of the module. For example:
module M {
typedef short M; // Error: M is the name of the module
// in the scope of which the typedef is.
interface I {
void i (in short j); // Error: i clashes with the interface
name I
};
};"
This change was forced into the IDL spec by name mangling problems in the C++ lan-guage
mapping.
I think that we have two alternative ways to track this change in the MOF:
1. Change the M2 level scoping rules so that this above restriction applies to all MOF
meta-models.
2. Add an extra bullet point to 7.4 to make the above restriction a preconditions for
successful IDL generation.
Option 2) is prefereable because it leaves open the possibility that the IDL and / or C++
mapping specs may be revised to fix the problem properly. [Don't hold your breath though
... ]. Also, there are apparently a number of other cases where name mangling in CORBA
language mappings gives rise to uncompilable code from valid IDL. If we word the text cor-rectly,
we can cover all of these cases as well.
Proposed resolution: Update the "preconditions for IDL generation" section to cover these
cases
Washington : Resolved, to be implemented using option 2.
Implementation: Added text to advise against using names that would violate this new
IDL constraint in Section 5.5, “Preconditions for IDL Generation,”
on page 5-33. Done [KR].

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.
 

Discussion: (crawley@dstc.edu.au)
I agree that it is the MOF RTF's long-term responsibility to maintain the normative version
MOF Model, and by implication, the XMI DTD for the MOF Model as well.
However, I would take issue with Stephen's insistence that the MOF RTF supply the MOF
Model "in Rose (or equivalent)". In my opinion, the most appropriate way to supply the
MOF Model in machine readable form is as MOF meta-objects, or as an XML document
produced by applying the XMI Stream Production rules to those objects. Rose is not an ap-propriate
interchange format for MOF meta-models even in the short term because it does
not encode all of the information equired to generate valid XMI DTDs.
Status: no progress.
Resolution : MOF Spec will take ownership of MOF DTD after XMI is adopted. This may
be beyond the timeframe of this RTF. As a consequence of this we will provide OMG doc-uments
corresponding to proposed XMI DTDs (ad/98-10-06) as well as Rose Models.
Resolved: To be implemented by the MOF RTF
Implementation: Added Don’s XMI generation as Appendix A. Done. [SC]
Implementation: Updated with new versions of the XML & DTD. Done. [SC 24/9/99]

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.
 
 

Discussion: (crawley@dstc.edu.au)
This issue is substantially the same as issue 1307, though it is not clear to me what Steve
means by "Namespaces in MOF metamodels may be useful ...".
Proposed resolution: See issue 1307. The proposed resolution to issue 1307 is to use Tags
attached to model elements to allow the meta-modeller to supply substitute names to a map-ping.
The Tag names would include the name of the mapping which would use the substi-tution.
Discussion (mof-rtf Burlingame ): An alternative to tag is to offer an attribute in ModelEle-ment
which is a sequence of (language : string, name : string) pairs and two operations
set_Alternate_name (name : string) and get_alternateName (language: string)
Resolution : The tagging mechanism to be implemented. Preconditions for IDL generation
will be enforced. Note that specific tools can use tagging to prevent potential conflicts
Implementation: Resolved as a byproduct of “Issue 1307: IDL Mapping/Identifier
Naming (mof-rtf)”. Nothing more to do. Done. [KR]

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.
 

One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of
additional Constraints on the Package, that might (for example) disallow the use of certain
model elements or combinations that are allowed in the base Package. If so, expressing this
using the MOF Model might require changes. For example, constraint [35] says that the
'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's
container.
Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined.
This is part of the broader discussion of heavy weight extension mechanisms part of MOF
2.0 and UML 2.0
Implementation: Nothing to do. Done [KR]. One possible interpretation is that a "profile" of a meta-model (aka a Package) is a set of additional Constraints on the Package, that might (for example) disallow the use of certain model elements or combinations that are allowed in the base Package. If so, expressing this using the MOF Model might require changes. For example, constraint [35] says that the 'constrainedElement' of a Constraint must be part of the "extended contents" of the Con-straint's container. Status: Outside the scope of the RTF. UML and MOF profiles need to be precisely defined. This is part of the broader discussion of heavy weight extension mechanisms part of MOF 2.0 and UML 2.0 Implementation. 

This is supposedly being addressed in either UML 1.4 or the UML 2.0 Infrastructure RFP. 

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:
 
 

Discussion: The least impact fix is to change the text to match the IDL / MODL.
Proposed resolution: Change the text to match the IDL / MODL.
Implementation: Revised the text and IDL in Section 3.4.2, “Namespace,” on
page 3-22 to say that an exception is raised. Done [KR]
Implementation: Also revised text and IDL for lookup_element_extended in
Section 3.4.3, “GeneralizableElement,” on page 3-26. Done[SC]

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 : To be implemented, time permitting for this revision .
Implementation: All OCL rules in Chapter 3 updated to conform with the OCL spec
as of UML V1.3 alpha 5. Done. [SC]

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.
 
 

This issue has been reopened to remind the RTF that the OCL in the MOF spec still needs to be checked by an OCL compiler / evaluator if one becomes available. 

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

The following alternatives are available for default constructors in the specific interfaces:
1. If an Attribute has a default value, the corresponding specific create operation has
no initialiser parameter for that attribute.
2. When necessary, provide two constructor / factory operations in the specific inter-faces,
one with initialisers for attributes with defaults, one without.
3. No support for default initialisation in specific factory operation. The client must
use the Reflective operation to get default constructor behaviour.
In the Reflective interface, there are various options. For example:
1. Parameters are positional, with nil Any values as position holders and trailing pa-rameters
possibly omitted.
2. Parameters are Designator / Value pairs, supplied in any order. This requires an
operation signature change.
Discussion: (crawley@dstc.edu.au)
Of the alternatives available, I prefer alternative 2 for specific interfaces and alternative 1
for reflective interfaces. However, I would prefer to treat this as out of scope of the RTF,
since there is no pressing need for default values
MOF RTF Burlingame - Deferred to MOF 2.0. This is an extension to the MOF and a po-tentially
useful one. The following alternatives are available for default constructors in the specific interfaces: 

If an Attribute has a default value, the corresponding specific create operation has no initialiser parameter for that attribute. 
When necessary, provide two constructor / factory operations in the specific inter-faces, one with initialisers for attributes with defaults, one without. 
No support for default initialisation in specific factory operation. The client must use the Reflective operation to get default constructor behaviour. 
In the Reflective interface, there are various options. For example: 
Parameters are positional, with nil Any values as position holders and trailing pa-rameters possibly omitted. 
Parameters are Designator / Value pairs, supplied in any order. This requires an operation signature change 

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.
 
 
 
 

Proposed resolution: since nobody seems interested in fixing it, just document the discrep-ancy
as above.
Implementation: Added this statement to the introductory Section 2.3.1, “Classes,”
on page 2-6 and also in Section 3.2.1, “Classes,” on page 3-3. Done
[KR].

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.
 
 
 

A number of restrictions apply to instances of Classes that are defined in different Package
instances. For example, a Class instance from one Package instance may not contain a
Class instance from another Package instance. The restrictions (see issue 1513) are required
to avoid anomalies in the M1 level semantics, and to make federation feasible. These issues
arise because we cannot assume that an M1 level server implementation for an imported
Package has any knowledge that it has been imported.
Unless we do something about it, these restrictions make various constructs involving im-ported
elements impossible to use. For example, if a Package P1 defines a Class C1 with
a composite Attribute where the Attribute's type is a Class C2 imported from P2, it will be
impossible to create instances of C1 that do not break the composition restriction.
The solution to this to add a new Package composition mechanism that "consolidates" a
group of Packages into a "cluster". (The terms consolidate and cluster are provisional.) A
Package can consolidating a number of other Packages. The effect of doing this is similar
to nesting the Packages, with the following important distinctions:
• A Package may be a member of many M2 level cluster Packages.
• A Package placed in a cluster can generalize and be generalized by other Packag-es.
At the M1 level, creating an instance of a cluster Package automatically creates a single
instance of each Package in the cluster. However, this does not prevent the creation of in-dependent instances of those Packages. The dependent and independent instances will have
the same interfaces; e.g. the same mapped IDL. The difference between the two cases is that
a cluster Package instance and its dependent Package instances all belong to the same
package extent. This means that the extent-based restrictions work differently. Thus if we
make Packages P1 and P2 members of a Package cluster PC, we can now create instances
of C1 and C2 that belong to the same extent, and hence we assign to the composite at-tribute.
Proposed resolutions:
1. Add a definition of extents, and rework / rename the type closure rule based on this
rule.
2. Extend MOF Model to allow definition of consolidation Packages. The low impact
approach is to add a boolean attribute to Import and renaming it to (say) External.
3. Decide once and for all on the terms we are going to use to describe this mecha-nism.
Burlingame - Discussion : Research Subsystems in UML and see if these concepts are re-lated.
Implementation: The preferred term is "cluster" / "clustering". Added boolean at-tribute
’is_clustered’ to Import model element and in IDL and
MODL. Ammended the Package and PackageFactory templates.
[SC]
Implementation: Added an OCL rule to take account of clustering. [SC]
Implementation: Added some extra text explaining Package composition:
Section 4.5, “Package Composition,” on page 4-7. Added extra text
explaining the M1 level interactions of generalization and clustering
to Section 4.6, “Extents,” on page 4-9 and Section 5.2.1, “Meta Ob-ject
Type Overview,” on page 5-2. [SC]
Implementation: Ammended description of refImmediatePackage to account for the
aggregate nature of Package extent relationships: Section 6.2.2,
“Reflective::RefBaseObject,” on page 6-5. Done. [SC]

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.
 
 

We need to decide if this is within the scope of the MOF RTF.
We can modify the MOF Model so that Exception inherits from GeneralizableElement.
However, we should not to alter the Model - IDL mapping at this time. Instead, add a new
precondition for IDL generation that Exceptions do not inherit.
Exception hierarchies are not currently supported by CORBA IDL, and none of the cur-rently
implementable alternatives for mapping to "flat" exceptions are appealing. Steve Vi-nowski
has suggested a clever way to use OBV value types to simulate exception
hierarchies in IDL, but this depends on OBV implementations being available.
Status: Deferred to MOF 2.0
Implementation: Nothing to do. Done [KR] We can modify the MOF Model so that Exception inherits from GeneralizableElement. However, we should not to alter the Model - IDL mapping at this time. Instead, add a new precondition for IDL generation that Exceptions do not inherit. Exception hierarchies are not currently supported by CORBA IDL, and none of the currently implementable alternatives for mapping to "flat" exceptions are appealing. Steve Vinowski has suggested a clever way to use OBV value types to simulate exception hierarchies in IDL, but this depends on OBV implementations being available. 

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

This would allow us to specify some useful "generic" Packages. For example:
package Extension {
class ExtensionTag {
attribute string tag_name;
attibute any tag_value;
reference to the_element of TagAttachesTo tagged_element;
};
association TagAttachesTo {
ExtensionTag the_tag;
UniversalClass the_element; // need the universal supertype here
};
};
The above approach could be used to make the MOF Model tagging mechanism apply to
all meta-models.
Status: no decisions made. This would allow us to specify some useful "generic" Packages. For example: 

package Extension { 
class ExtensionTag { 
attribute string tag_name; 
attribute any tag_value; 
reference to the_element of TagAttachesTo tagged_element;
}; 
association TagAttachesTo { 
ExtensionTag the_tag; 
UniversalClass the_element; // need it here
};
};
The above approach could be used to make the MOF Model tagging mechanism apply to all meta-models.

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

See also Issue 2174

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.
 
 

Discussion : Burlingame - Please clarify why we need this.
Implementation: Already resolved by a combination of “Issue 1305: Illegal IDL re-definitions
(mof-rtf)” and “Issue 1770: MofAttribute values do not
have aggregation==composite semantics (mof-rtf)”. Done [KR].

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. 
 
 

The specification should cover:
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 can the Constrain-tError
exceptions be raised?
3. How evaluation of deferred Constraints is triggered. One possibility is to tie this to
one or more Operations in a meta-model. If so, how do we meta-model this?
It is assumed that we want verification semantics that work for Constraints on all meta-models,
not just for Constraints on MOF Model.
Cross reference Issue 1082
Status: Beyond RTF scope - except for specific clarifications. Deferred to MOF 2.0; Desir-able
feature..
Implementation: A description of what is not currently specified is in Section , “Con-sistency
Checking Mechanisms,” on page 2-18. Also mentioned in
Section 4.6, “Extents,” on page 4-9. Done. [SC] The specification should cover: 

What happens; e.g. is the verification allowed to give up on the first error? 
When evaluation of deferrable Contraints can occur; i.e. where can the Constrain-tError exceptions be raised? 
How evaluation of deferred Constraints is triggered. One possibility is to tie this to one or more Operations in a meta-model. If so, how do we meta-model this? 
It is assumed that we want verification semantics that work for Constraints on all meta-models, not just for Constraints on MOF Model. See also Issue 1082

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.
 
  
 
 

Arguably this is a MOF extension rather than an RTF issue. Arguably this is an extension rather than an RTF issue. 

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

Status: Specific text changes will be considered if provided in time.
[KR] Many things need doing. The constraints are inconsistent throughout the document.
All the operation names in "Mof Model and Interfaces" and the Reflective interface are in
different format to the MODL etc.
Implementation: Constraints fixed up. Documentation of Reflective and Templates
completely reorganized. Added new introductory chapter before the
big Model chapter. Done. [SC]

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.
 
 

Possible solutions:
1. No change. Is the requirement met by allowing Class values Attributes with aggre-gation==
none/composite semantics? How about Attributes that have an aggrega-tion
attribute?
2. Define the Association with visibility==private. This "works" for the IDL mapping,
because no IDL would get generated. However in Java for example, declaring the
corresponding Association class as "private" does not eliminate the need for it. So
unless a (hypothetical) mapping to Java did something odd-ball for Associations
with visibility==private, the heavy-weight query mechanisms may still be used; e.g.
in Constraint evaluation.
3. Add a "is_hidden" Attribute to Association that allows the modeller to specify that
querying interfaces are not required. [A server may choose to build references on
top of queries, but that is an implementation issue.] Possible solutions: 

No change. 
Redefine the Model constraints and the IDL mapping such that an Association with visibility==private or protected can be referenced, but that it will have no Association IDL. 
Add a "is_hidden" Attribute to Association that allows the modeller to specify that querying interfaces are not required. [A server may choose to build references on top of queries, but that is an implementation issue.] 
Define a Tag (e.g. "org.omg.mof.idl_lightweight" or "org.omg.mof.idl_suppress") that tells the IDL mapping to leave out the Association's IDL interface. 
The first (non-)solution is not acceptable. This issue perceived to be a serious problem. 
The second solution "works" in the context of the IDL mapping. However, consider a mapping to Java ... where a visibility is orthogonal to suppression of implementation machinery.  The danger is that by co-opting Model::Association::visibility to mean that an interface is to be suppressed in the IDL context, we risk causing future problems in other contexts. 

The third solution involves an unnecessary change to the MOF Model. 

The fourth solution doesn't seem to have any significant disadvantages.  It might also be worth generalizing this to allow suppressing of IDL elements for Classes, Attributes, Operations and so on.  For instance, by suppressing an Attribute, you might remove individual set/get operations, limiting access / update to a (hypothetical) "get_all_attributes" or via "ref_*" operations. 

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:
 
 

This is an important problem that needs to be fixed, but is fortunately also easy to fix.
Burlingame - Needs more discussion as to why this is desirable
Proposed resolution
1. Define a standard Tag name that can be used to set the prefix on the outermost
Package of a meta-model.
2. Ammend the IDL mapping to respect the prefix Tag.
To be implemented
Implementation: Text defining the tag has been added to “Tags for specifying IDL
#pragma prefix”. Done. [SC]

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.

Discussion
The #pragma prefix for the Mof Model should be set using the mechanism defined as a re-sult
of the previous issue. For Reflective, it should simply be edited into the IDL.
Dan Franz has confirm that the module name prefix for MOF should be Cf. He has also
stated that there is no requirement on the MOF RTF to rename the MOF modules, since
the MOF specification predates the style guide.
Changing the module names could be done by changing the top-level Package names; e.g.
Model - CfModel, Reflective - CfReflective. If we are going to do this, I propose that we
think about choosing some package names that are more appropriate. They need to be
clearly MOF associated, and also they need to more accurately indicate their purpose. For
example, Model - CfMetaModels and Reflective - CfMetaObjects.
Clearly, changing the core MOF Package names at this stage will have significant impact
on existing MOF code bases. This must be taken into account. On the other hand, fixing the
prefixes will probably cause minimal problems at this stage.
Status: no decisions , Deferred to MOF 2.0
Implementation: Nothing to do. Done [KR] The #pragma prefix for the Mof Model should be set using the mechanism defined as a re-sult of the previous issue. For Reflective, it should simply be edited into the IDL. Dan Franz has confirm that the module name prefix for MOF should be Cf. He has also stated that there is no requirement on the MOF RTF to rename the MOF modules, since the MOF specification predates the style guide. 

Changing the module names could be done by changing the top-level Package names; e.g. Model - CfModel, Reflective - CfReflective. If we are going to do this, I propose that we think about choosing some package names that are more appropriate. They need to be clearly MOF associated, and also they need to more accurately indicate their purpose. For example, Model - CfMetaModels and Reflective - CfMetaObjects. 

Clearly, changing the core MOF Package names at this stage will have significant impact on existing MOF code bases. This must be taken into account. On the other hand, fixing the prefixes will probably cause minimal problems at this stage. 

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.
 
 
 

Discusssion : Please provide specific context (Section number, page) for us analyze the
problem
[DK] Proposal is to revise the InvalidDesignator exception as follows:
exception InvalidDesignator {
DesignatorType designator;
StringSet element_kinds;
};A predefined set of possible string values that the 'element_kind' members could be as-signed
needs to be defined in Reflective.idl like this:
const string PACKAGE_KIND = "Package";
const string TYPE_KIND = "Type";
const string ASSOCIATION_KIND = "Association";
and so on for each of the concrete MOFclasses.
Implementation: Revised the InvalidDesignator exception in Section 5.4.6, “Reflec-tive
Errors,” on page 5-30 to return multiple element_kinds and to
define the string values that can be returned. Note that the possible
kinds have been determined by analysing the operations that can
raise InvalidDesignator (and also InvalidValue which also has an
element_kind field). The corresponding changes have been made in
Appendix B.2 “MOF IDL Summary”. Done [KR].
Implementation: Definition of is_instance_of now says that MofError("Invalid Des-ignator",
"Wrong Designator Kind") get raised. Done. [SC]

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.  
 
 

Discusssion : Please provide specific context (Section number, page) for us analyze the
problem
Implementation: Merged MissingParameter and TooManyParameters into a single
WrongNumberParameters exception with a field
expected_number_parameters indicating the number of parameters
expected in Section 5.4.6, “Reflective Errors,” on page 5-30 and
Section 6.2.3, “Reflective::RefObject,” on page 6-10 and
Appendix B.2 “MOF IDL Summary”. Done [KR]
Implementation: Definitions of create_instance and invoke_operation now say that
MofError("Wrong Number of Params", "Wrong Type") get raised.
Done. [SC]

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.
 
 
 

Discussion : Good Idea, Can you make a concrete proposal for us to look at.
For RefObject:
If all_objects is called for an abstract Class with include_subtypes false, should this oper-ation
fail, as it is meaningless? Probably should raise AbstractClass exception (which al-ready
exists as a result of another issue).
E.g. if an attribute is readonly, all of the set_value, add_value should fail.
If an attribute is 0..1 or 1..1, then the add_value, etc operations should fail
If an attribute is not ordered, then the add_before and add_at etc should fail
If we introduce an unset_value operation (as part of another issue), then that operation
should fail if the value is singleton.
For RefAssociation:
If we decide to make derived Associations readonly (another issue), then all of the add_link
etc operations of a readonly association should fail.
If there is no ordering, then the add_link_before should fail.
There appears to be a need for Reflective exceptions:
* ReadOnly to be raised if anyone tries to set/add/modify/remove readonly values
* NotCollection to be raised if anyone tries to add/modify/remove single or optional values
(i.e. anything with multiplicity.upper = 1)
* NotOrdered to be raised if anyone tries to do *_before and *_at operations on
non-ordered collections
* CannotUnset to be raised if anyone tries to unset things that are not unset-able
All of the above would have a DesignatorType field for the meta-information that tells us
that they did an illegal action.
If we do all of this, then parts of Section 6.2.1, “Reflective Argument Encoding Patterns.,” on page 6-3 will need to be revised to remove the text about raising
NOT_IMPLEMENTED.
Implementation: These conditions are variously signalled using MofError("Wrong
Multiplicity", "Not Changeable") as indicated in the revised de-scriptions
in Section 6.2, “The Reflective Interfaces,” on page 6-3.
Section 6.2.1, “Reflective Argument Encoding Patterns.,” on
page 6-3 has been rewritten, and NO_IMPLEMENT is not men-tioned.
Implementation: RefObject::all_objects(false) is described as returning an empty set
rather than raising an exception if the Class is abstract. Done. [SC]

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

The question here is how do we want the "value" operation of the RefObject interface to
behave for different multiplicities. For a single X value, the returned-any contains an X. For
a 0..1 X value, we can either 1) if value-exists return an X, else raise NotSet, or 2) always
return a sequence with 0 or 1 Xs as appropriate. Only the second option is currently possible
(as the "value" operation does not raise NotSet). Similarly, if a value has 0..N multiplicity,
what should be done if there are 0 elements. Should we 1) raise NotSet or 2) return an 0-
length sequence? Semantically, is a 0-lenth sequence different to a NotSet sequence?
Implementation: Ref_value() changed to be analogous to the specific version; i.e it
raises NotSet in the [0..1] case and returns an empty sequence in the
[0..n>1] case; see Section 6.2.3, “Reflective::RefObject,” on
page 6-10. Done. [SC]

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.
 
 

Alternatively, have an "unset_value" in RefObject which raises MofError when the lower
multiplicity is >1. This may be easier for users than building an any with tk_null inside.
Implementation: Ref_unset_value() operation added; .see Section 6.2.3, “Reflec-tive::
RefObject,” on page 6-10. Done. [SC]

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

The remove_value_at operation is differently defined in several places in the document. It
should be:
void remove_value_at (in DesignatorType feature,
in unsigned long position)
raises (InvalidDesignator,
BadPosition
MofError);
Implementation: This revised definition of remove_value_at has been placed in
Section 6.2.3, “Reflective::RefObject,” on page 6-10 and
Appendix B.2 “MOF IDL Summary”.
Implementation: There are places in the document in which InvalidPosition (which is
not declared) is being raised instead of BadPosition. Replaced In-validPosition
with BadPosition in the add_value_at,
modify_value_at, and remove_value_at operations in Section 6.2.3,
“Reflective::RefObject,” on page 6-10. Done [KR] Implementation: Rewrote text in Section 6.2.3, “Reflective::RefObject,” on
page 6-10. Done. [SC].

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:
 

Implementation: Changed the "args" parameter to be "inout" instead of "in" in
Section 6.2.3, “Reflective::RefObject,” on page 6-10 and in the
RefObject interface in Appendix B.2 “MOF IDL Summary”. Done.
[KR]
Implementation: Rewrote text that covers encoding of all Parameters including the
return value to remove ambiguities; see Section 6.2.3, “Reflec-tive::
RefObject,” on page 6-10 . Done [SC].

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

Implementation: Renamed exists in RefAssociation to be link_exists in Section , “In-terface,”
on page 6-23 and Section 6.2.4, “Reflective::RefAssocia-tion,”
on page 6-25. No changes required in Annex A as it was
correct there. Done [KR]

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

Discussion : GK - Please check these based on our experience.
Implementation: Add the operation "LinkSet all_links ();" to Section , “Interface,” on
page 6-23 and Section 6.2.4, “Reflective::RefAssociation,” on
page 6-25 and Appendix B.2 “MOF IDL Summary”. Added the def-inition
"typedef sequence <Link> LinkSet;" to Section 6.3.2, “Data
Types,” on page 6-34 and Appendix B.2 “MOF IDL Summary”.
Done [KR].

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.
 
 

Discussion: (crawley@dstc.edu.au)
Stephen Brodsky's suggested solution "addresses" the easy part of the problem. In fact, the
MOF already allows you to express arbitrary data type systems in a way that should sup-port
CMW.
The hard problem of supporting arbitrary data types in the MOF is how to do it so that the
data types can be used at the M2 level. I've been scratching my head over this particular
problem for more than 2 years now. Unless you make some serious restrictions, the prob-lem
is (I believe) intractable!
Proposed resolution: The easy problem probably doesn't need addressing at all. The hard
problem should be addressed in a separate MOF-related RFP, if at all. Schedule a specific teleconference for this issue
Implementation: Nothing to do. Done [KR] This is a short term resolution to this issue so that JMI can share the MOF 1.4 meta-model.  The key 
points are: 

Change the way that meta-models are represented to be based on explicit modelling rather than TypeCodes and Anys 
Remove support for data types that are CORBA centric; e.g. Any, TypeCode, union, "external IDL types" 
Make support for unsigned types, long double, character types, 8-bit strings "CORBA specific". 
It is anticipated that MOF 2.0 RFP submissions will provide a more comprehensive solution to MOF data typing.

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

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

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

We've already decided that the MOF 1.4 IDL will not be upwards compatible with the MOF 1.3 IDL.  So adding new operations and (slightly) changing the signatures of existing ones should not be an obstacle. 

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

This issue has been addressed by the resolutions to Issues 2198 and 4351.  All string types in the MOF Model are now wide-strings

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

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?
 

The template is correct, and the class proxy IDL in Section 3.4.* and  Appendix B is incorrect.  The spec says that there is no meaningful ordering on the "all_of_*" collections.  Therefore the IDL should use the typedef for sets rather than those for unique lists / ordered sets. 
Note: this doesn't change the effective signature of the interfaces in question because <ClassName>UList and <ClassName>Set are both aliases for "sequence < <ClassName> >". 

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.

This is indeed a "hole" in the IDL mapping, albeit a minor one, and easy to fix. For scoping reasons, the constraints need to go into the <AssociationName> interface. 

Note: this does not effect the MOF Model IDL, since the MOF Model has no constraints on any of its associations.  For meta-models that do have constraints on associations, this simply adds some IDL constant declarations which should not affect signatures. 

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.
 

The Association template is correct and the IDL is incorrect.  As the template says, "the operations signature raises MofError to allow Constraint error and Semantic error conditions to be signalled." 

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.

Solve this problem by changing the IDL mapping so that the FooBag, FooSet, FooList and FooUList typedefs appear after the declaration of Foo, whether or not they are used locally.  Collection typedefs for the types defined in PrimitiveTypes and CorbaIdlTypes are added to the respective IDL models. 

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.

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

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.

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.

Resolution: 
The operation is indeed erroneous and should be deleted.  The view from a Tag to the ModelElements is not ordered.  (The ordering is on the view from a ModelElement to its Tags.) 

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

The OCL for Constraint [C-43] is incorrect.  A Package can contain a Constant.  The IDL mapping supports this, and the MOF Model already has a Constant declared in a Package (Model::Unbounded). 

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 Association.  Fix it

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.

We are going to remove the restriction that is being violated here,rendering the issue moot.  See Issue 3529 

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.

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

Resolution: 
Check Chapter 3 to ensure that the order of attributes, operations and other elements shown in the diagrams and as implied by the subsection headings is the same as defined in the IDL and XMI. 

Note: this does not change the meaning of the specification since the order shown in the element order in the diagrams and the text is already explicitly stated to be non-normative.  However, these changes should make the specification easier to read. 

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

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.

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

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.

This issue is the same as Issue 3131 which has been resolved

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.

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.

While some of the listed reasons for dropping this restriction are spurious (e.g. the fact that some MOF implementation ignored it), 
others are not.  However, it is true that this restriction is IDL-centric, and that it is unnecessary.  Therefore, this restriction is being removed. 

Note that the revised text for this issue will overlap the changes needed to resolve Issue #2198. 

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]

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.

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.

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. 

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.

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

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

Review section 2.2 and subsections. 

Develop appropriate introductory MOF material for separate publication; e.g. on the OMG website. 

The description of the MOF meta-data architecture in section 2.2 and subsections could do with some rewording and rearrangement to the points mentioned in the issue clearer. 

However, the root problem is that people do not read the MOF spec. What is needed is some (OMG endorsed) introductory or tutorial material on meta-modelling and the MOF. The MOF RTF is best placed to take on the task of developing this material in the first instance. 

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

The proposed resolution to this issue is to change the IDL templates to match the Model IDL. 

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.

Resolution: 
Since the Appendix containing the MODL for Model is non-normative, this issue can be addressed as an editorial action. 

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.

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.

This issue is duplicated by Issue 3446 

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. 

Get rid of ValueType altogether and replace its use in the Reflective IDL with 'any'.  Rename ValueTypeList to be AnyList.  This is consistent with our purging of cosmetic typedefs from the MOF Model. 

The second part of this issue is something for the OMG staff to deal with. 

 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.

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

This has been agreed in principle.  However, the RTF needs to determine the impact of this change and similar tidying up / regularisation of names in the MOF Model before proceeding to change the Model, and hence the IDL and generated DTDs and XMI documents.  DSTC expressed concern that the impact of this change could be significant. 

 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.

This is an exact duplicate of Issue 4231 which has a resolution. 

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

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.

This issue was raised at the Irving MOF-RTF meeting by (I believe)
Dave Frankel.  The proposal from that meeting was:

"Consider integrating XMI and MOF such that the interface allows
packaging up the features needed and the corresponding values as an XMI
document. This has the advantage customizing the set of features
returned.

Alternately extend the reflective interfaces to return get_all_features. 
Or get_requested_features(featurelist, featurevaluelist)"

I would add a third alternative, which is to define an IDL mapping
Tag that tells the mapping to generate a 'meta-model specific' 
get_all_features (or equivalent) operation for the interface(s) for
a tagged Class.

Also, I think we should consider adopting all three approaches. 
This issue was raised at the Irving MOF-RTF meeting by (I believe) Dave Frankel. The proposal from that meeting was: "Consider integrating XMI and MOF such that the interface allows packaging up the features needed and the corresponding values as an XMI document. This has the advantage customizing the set of features returned. Alternately extend the reflective interfaces to return get_all_features. Or get_requested_features(featurelist, featurevaluelist)" 

I would add a third alternative, which is to define an IDL mapping Tag that tells the mapping to generate a 'meta-model specific' get_all_features (or equivalent) operation for the interface(s) for a tagged Class. 

Also, I think we should consider adopting all three approaches. 

It looks like Issue 2876 is talking about this problem, as is Issue 3411. 

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)

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

The current text does not say whether any checking should be done, and
if it is done, what flavours of MofError should be thrown.  This needs
to be tied down.

My recommendation is to make the checking mandatory.  IMO, it would be a
Bad Thing to return parameter collections to the client that don't
match the multiplicity "contract".  

My recommendation is to use the standard 'reason' strings for Underflow,
Overflow, Duplicate and Invalid Object.  IMO, they adequately cover the
situation(s).  (Another alternative would be to invent new reason
strings that indicate that the fault is in the server implementation not
the client's usage.  But I think this is overkill, because the MofError
error description field could be used to make this distinction.)Underflow,  Overflow, Duplicate and Invalid Object should not be used since this tends to imply that the error condition is the caller's fault. 
This would be rather confusing.  Instead, a "semantic" MofError should be raised.  There is not need to specify an error code, but we will make the checking mandatory. 

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.

'ViolationType' is no longer a type in the MOF Model.  Issue 4384's resolution makes it a regular IDL type. 

Close with no further action. 

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.

All uses of 'any' have been replaced with String (e.g. attributes of Constant, Tag and Constraint) or removed from the MOF Model (e.g. the 'verify', 'internalize' and 'externalize' Operations). 

All Strings in the MOF Model are now 16-bit. 

All cosmetic typedefs in the MOF Model (e.g. NameType, AnnotationType, LiteralType, DependencyKind, FormatType) have now been removed or replaced  with the aliased type. 

Values of Constants are encoded as Strings as per Corrigenda #6 to the  2198 resolution. 



Remove the 5 typedefs listed above from Section 3.6. 

Replace all uses of these typedefs in Chapters 3, 5 and 6, and in the IDL. 

Change all uses of "string" in the Chapter 3 IDL to "wstring". 

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

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.

Remove the 'verify' Operation and associated DataTypes from the MOF Model. Add a refVerifyConstraints operation to Reflective::RefBaseObject to allow IDL clients to trigger Constraint evaluation. 

Note: the ModelElement 'verify' Operation in MOF 1.3 tries to be a bit more sophisticated by returning 'published' when the Constraints can be determined to be true for evermore.  But this is unimplementable unless there is some pervasive meta-data freezing mechanism.  The RTF has decided not to address freezing right now, so the new version of this operation has been simplified. 

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.

Remove these operations for now.  In the longer term they could be added as  operations in the Reflective layer; e.g. as a resolution to 3411. 

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.

An IDL specific Tag is the most appropriate way to deal with this.  A
resolution is urgently required because the IDL generated from the MOF
1.4 version of the Model requires #pragma version directives to indicate
incompatible API changes.
Add a new tag type for the IDL mapping that causes #pragma version directives to be output for selected IDL declarations correspond to a tagged model element. 

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.

[Steve Crawley]  The concept of a null instance in MOF has been disputed.
The MOF 1.3 IDL mapping is
clear about this.  This (to me) implies that null instances are valid
values across the entire MOF framework.  In my opinion, the anomaly is
best corrected by amending Chapter 4 to state that null is a valid
instance value, and make consequent changes.  [The alternative of saying
that the null instance is only legal in IDL-based repository would be
bad for interoperability.]

Note: This approach says nothing about whether a null Attribute or
Parameter value is meaningful in any given metamodel.  It is up to the
metamodeller to decide this.  If necessary, Constraints can be added to
Attributes, Parameters and so on to disallow meaningless nulls.

Note: It is currently explicitly illegal to use a null instance value in
Association links and References.  This would not change.
The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDLmapping.  However, we will note metamodellers should not rely on this since some mappings may not support null instance values. 

Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo. 

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.

[Steve Crawley]  We need to carefully consider the impact of this
proposed change.  I strongly recommend that we don't try to do this 
in MOF 1.4

In normal programming languages where attributes are used to represent
relationships between objects, a null value is typically used to signify
the absence of a relationship.  In MOF, the absence of a relationship
can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or
Association.  However, there are other possible uses of null where there
is no straight-forward alternative.

We also need to consider the impact on the IDL mapping, specifically
in how Class instances are created.  Consider the following:

  class C {
    attribute C another_one;
  };

If null is not a legal value for a 'C' instance, what do you pass as the
initial value for 'another_one' when creating the first ever instance of
'C'?  Maybe the answer is that 'another_one' >>must<< be declared as
[0..1] Attribute for the metamodel to be practical.  Or maybe each
mapping needs to find a solution; e.g. by deferring checking of some
structural constraint ... like the IDL mapping currently does for
Association underflow.

Note: It is currently explicitly illegal to use a null instance value in
Association links and References.  This would not change.
 [Steve Crawley] We need to carefully consider the impact of this proposed change. I strongly recommend that we don't try to do this in MOF 1.4 In normal programming languages where attributes are used to represent relationships between objects, a null value is typically used to signify the absence of a relationship. In MOF, the absence of a relationship can be modelled in other ways; e.g. using a [0..1] (optional) Attribute or Association. However, there are other possible uses of null where there is no straight-forward alternative. We also need to consider the impact on the IDL mapping, specifically in how Class instances are created. Consider the following: class C { attribute C another_one; }; If null is not a legal value for a 'C' instance, what do you pass as the initial value for 'another_one' when creating the first ever instance of 'C'? Maybe the answer is that 'another_one' >>must<< be declared as [0..1] Attribute for the metamodel to be practical. Or maybe each mapping needs to find a solution; e.g. by deferring checking of some structural constraint ... like the IDL mapping currently does for Association underflow. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. 

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. 

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

The MOF XMI file uses 'OCL' for the language of the constraints, whereas the last paragraph of section 3.9.2.1 says that 'MOF-OCL' should be used [due to the minor variations from UML's OCL which are enumerated in 3.9.3]. 

The description of the Constraint class in 3.4.27 should refer to how constraints are expressed for the MOF Model itself in 3.9.3 (using MOF-OCL). Though it should not be mandatory to use MOF-OCL, user-defined metamodels have the same requirements for constraint expression as the MOF Model and so the variant and usage of OCL is just as appropriate and necessary. Indeed it would be a lot more sensible to pull 3.9.3 out into a separate section since it applies to constraints in any MOF metamodel not just the MOF Model. NB This also needs to be reflected in the UML Profile for MOF.

Many metamodels including the MOF Model (see 3.9.6) have 'OCL Helper' operations which are purely for the purpose of factoring the OCL constraints, and are not intended to be part of the 'external' model (e.g. to be represented in IDL). 

There seems to be no way of representing these in the MOF Model: and indeed the OCL Helper functions in MOF Specification do not appear in the XMI file, making it somewhat incomplete as a normative definition and meaning that many of the OCL constraints could not be executed by an OCL engine. 

This applies not only to MOF but to other metamodels. 

The MOF model should allow generalization of associations. It is often
useful to have a more general root association and create several
specializations for it (e.g. dependency and several kinds of dependencies as
its subclasses).

When metadata is copied from one repository to another, or saved as an
XMI document, it can be necessary to know if the physically distinct
copies of the metadata are logically the same or logically different.
There need to be mechanisms for testing whether copies are logically the
same or different that work in all cases, not just within the context of
a single repository.

MOF should consider aligning its reflective interfaces with JMI
(specifically split some of RefObject into RefClass and common superclass
RefFeatured). As well as the benefit of consistency it makes the interfaces
more intuitive/comprehensible and typesafe.

MOF should deprecate the use of factory/finder operations on object
instances (i.e. the fact that generated instances inherit not only from
their model superclass but from their class proxy). The main reason for this
is that it does not separate concerns (why should an instance know about
creating other instances or finding the population of the class?) and is not
consistent with JMI.

The document needs a big revamp - e.g. a lot of the ancient pre-UML intro
stuff. We
should bear in mind that a lot of people will be coming to the spec/OMG
cold as a result of JMI takeup and we should make the document as clean,
lean
and approachable as we can.
It will be at least a year before MOF 2.0 reaches a stable/official state so
I feel we should not wait.

I think it would be much more convenient to have resolveQualifiedName as a
"classifier_level" operation on ModelElement instead of "instance_level"
operation on Namespace. Now each time I want to resolve some object using
its qualified name, I have to find all outermost packages (which is quite
slow, because currently there is no better way of doing it than just iterate
through all package instances and check whether they are outermost), then
choose a package with a specified name and call resolveQualifiedName on that
package passing rest of the qualified name as a parameter. This is much more
complicated for users than it should be.

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

When I was looking at the current MOF 1.4 spec I could not find a place
where is specified, which assoc. ends are navigable and which are not.
There is an inconsistency between the UML picture of MOF metamodel and XMI
(and IDL). Where the picture indicates that some ends (like
RefersTo.referent) are not navigable, XMI says that they are navigable and
also IDL contains getter method for these ends. So I guess the picture is
wrong. This should be fixed, because it is in fact the only place where the
users of the spec can see the navigability without looking at the
hard-to-read XML file or generated IDL. It would be also helpful to add this
also to the description of particular associations in section 3.5.

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

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.

If an association end is not navigable, specification of its
Multiplicity should not be required.  There is no practical use for this
information and it does not make sense to require information that is not
used.

Proposed Resolution:  Make Multiplicity optional in the MOF model.

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.

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.

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.