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 set_<referencename> needs StructuralError Should set_<referencename>(nil) be legal? _var & _out types problems (01) Spec does not mention the existance of an Any_out class
Issue 1517: set_<referencename> needs StructuralError Should set_<referencename>(nil) be legal? _var & _out types problems (01) Spec does not mention the existance of an Any_out class
Issue 1518: Should set_<referencename>(nil) be legal? _var & _out types problems (01) Spec does not mention the existance of an Any_out class
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 Typographical errors in PL/I Mapping Specification
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 subj