Issues for Meta-Object Facility Revision Task Force discussion list

To comment on any of these issues, send email to [email protected]. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to [email protected].

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

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

Jira Issues

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

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: closed, to be implemented
Revised Text: RESOLUTION 1/12/99: Option 3 has the limitation of 'pollutes' the metamodel with extra-neous IDL generation properties. Approach 2 allows integration of existing CORBA IDL and hence Interfaces better with the MOF. Implementation: Following email discussions ... added "Note" in Section , �Class Generalization,� on page 2-8 refers to use of a Tag to specify IDL inheritance. Added text to define Tags in Section 5.6.3, �Tags for specifying IDL inheritance,� on page 5-37. Done. [SC] Implementation: Ammended template sections to call up these tags; see sections 5.8.4, 5.8.6, 5.8.7 and 5.8.10. Added a note to Section 5.2.2, �The Meta Object Interface Hierarchy,� on page 5-4 to mention the effect of the Tags on the inheritance graph. Done. [SC]
Actions taken:
December 3, 1997: received issue
July 23, 1999: closed issue

Discussion:

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 ([email protected]).  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 ([email protected]).  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.

Issue 785: IDL Generation Issue - factory operation parameters for multivalued attrib (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: resolved and closed
Revised Text: Response: Section 7.3.5 should show the parameter type name as having a CollectionKind suffix (Set, Bag, List, UList) when the attribute is multi-valued. This was agreed by the sub-mitters but not properly documented in the submission. Resolution. The MOF-RTF meeting in Manchester agreed to the above. To be implemented. Implementation: Text added to Section 5.8.9, �Class Create Template,� on page 5-58. Consequentially the values parameter in the create_tag operation must have type AnyBag instead of "any" in TagClass in Appendix B.1 �MOF IDL Summary� and this must be reflected in the text and IDL in Section 3.4.23, �Tag,� on page 3-68. Done [KR].
Actions taken:
December 2, 1997: received issue
July 23, 1999: closed issue

Discussion:

 received issue

Issue 786: Typos in MOF 1.1 document (1) (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: closed, already implemented
Revised Text:
Actions taken:
November 26, 1997: received issue
July 23, 1999: closed issue

Discussion:

Issue 787: Typos in MOF 1.1 document (2) (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: close, already implemented
Revised Text:
Actions taken:
November 26, 1997: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 788: Typos in MOF 1.1 document (3) (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: close - already implemented
Revised Text:
Actions taken:
November 26, 1997: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 940: Package create template (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 941: Package create template: StructuralError needs to be raised (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: ressolved, close issue
Revised Text:
Actions taken:
February 17, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 942: package create template: ConstraintError (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: rsolved, close issue
Revised Text: 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 constraint errors, so no additional work required. Done [KR].
Actions taken:
February 17, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 943: package create template: names of parameters need to be formated (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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}

Issue 944: Similar to issue 940 (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: closed issue
Revised Text: resolved, to be implemented
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 945: (mof-rtf)

Click here for this issue's archive.
Nature:
Severity:
Summary:

Resolution: closed issue
Revised Text:
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

This is a duplicate of issue #941.

Issue 946: Similar o issue 941 (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: closed issue
Revised Text: resolved, to be implemented
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 947: Type Create template, order of parameters (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: closed issue, resolved
Revised Text:
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 948: MOF-IDL needs to be re-generated (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Significant
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
February 17, 1998: received issue
July 23, 1999: closed issue

Discussion:

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.

Issue 949: Type Hierarchy Error in IDL (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
February 16, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 957: IDL Mapping--#includes for inheritted Packages (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
February 10, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 965: MOF IDL mapping-types of parameters with multiplicities (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
February 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 966: MOF IDL /MODL - Type Hierarchy error (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: This is a duplicate of Issue #949.
Revised Text:
Actions taken:
February 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

 close issue -- duplicate

Issue 967: MOF IDL Mapping with parameters (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: This is a duplicate of Issue #965.
Revised Text:
Actions taken:
February 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

Issue 968: RefObject::create_instance and abstract types (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
February 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 969: Editorial; change MOF Type to MOF Class (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved, to be implemented
Revised Text:
Actions taken:
February 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1075: Type of Facility.MofRepository.packageFactory incompatible with its purpos (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: deferred, pending issue1505

Discussion:

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

Issue 1076: Generated location parameters need clear specification of base value (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 1077: Description of meta-model as a single package is incorrect (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: nothing to do...close issue
Revised Text:
Actions taken:
March 18, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1078: Association interface generation templates require exceptions (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution: closed issue
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1079: Association IDL generation needs to consider AssociationEnd.isChangeable (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1080: ConstrainViolation vs. ConstraintError confusion (editorial) (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1081: ConstraintError exception needed in more IDL generation templates (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1082: Generated operations returning attributes/references should not raise Cons (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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:

Resolution:
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: deferred, pending issue 2181

Discussion:

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]

Issue 1083: Operations should return nil reference instead of raising NotSet (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed issue, resolved
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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 ([email protected]):  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].

Issue 1084: Single-valued parameters should not be defined with sequences (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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.

Resolution: closed issue
Revised Text:
Actions taken:
March 18, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 1085: Consider a better approach to generated exceptions (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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.

Resolution: resolved, close issue
Revised Text:
Actions taken:
March 18, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1141: Incorrect ocl specification(s) (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
April 16, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1305: Illegal IDL redefinitions (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: resolved, close issue
Revised Text:
Actions taken:
May 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1306: IDL generation - IMPORT TEMPLATE clarification (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed issue
Revised Text:
Actions taken:
May 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1307: IDL Mapping/Identifier Naming (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: closed issue
Revised Text:
Actions taken:
May 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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 ([email protected])  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]

Issue 1308: IDL generation Association Template Syntax (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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

Resolution: closed issue
Revised Text:
Actions taken:
May 5, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1496: Identifier formating error in MOF generates IDL (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: close issue, resolved
Revised Text:
Actions taken:
June 4, 1998: received issue
June 4, 1998: closed issue

Discussion:

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

Issue 1497: Naming of Tags (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed issue, resolved
Revised Text:
Actions taken:
June 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1498: MOF RTF Issue: Library of collection types? (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved, issue closed
Revised Text:
Actions taken:
June 4, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1500: MOF RTF Issue: M1 life-cycle operations (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: resolved, issue closed
Revised Text:
Actions taken:
June 4, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1501: MOF RTF Issue: aggregations crossing M1 and M2 package boundary (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
June 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1502: MOF RTF Issue: Behavior of M1 level interfaces vagualy specified (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
June 4, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1505: MOF RTF Isue: Conflict between "Facility" and "Package Object " (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Critical
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 5, 1998: received issue
May 8, 2000: closed issue
August 30, 2000: reopened

Discussion:

Discussion - [email protected]: 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 - [email protected]:  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!

Issue 1513: Exception for creating instances of imported supertypes? (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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?

Resolution: resolved and closed
Revised Text:
Actions taken:
June 9, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1516: Description of with_<associationed> operations (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: resolved and closed
Revised Text:
Actions taken:
June 10, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1517: set_<referencename> needs StructuralError (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
June 10, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1518: Should set_<referencename>(nil) be legal? (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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?

Resolution: resolved
Revised Text:
Actions taken:
June 10, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1540: ModelElement needs to have permanent, unique, unchanging, identifier (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
June 24, 1998: received issue
May 8, 2000: closed issue
August 30, 2000: reopened

Discussion:

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 ([email protected]):  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 ([email protected]):  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 ([email protected]):  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.

Issue 1683: Convenient way to discriminate instances of subclasses (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity:
Summary:

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.

Resolution: resolved
Revised Text:
Actions taken:
July 15, 1998: received issue
July 23, 1999: closed issue

Discussion:

Discussion: ([email protected]) I now think that this is unnecessary.  Proposed resolution: close with no action.  Implementation: Nothing to do. Done [KR].

Issue 1711: Multiplicities on Attributes and References modelled incorrectly (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
July 22, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1712: Navigability constraint expressed wrongly (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
July 22, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 1714: Inconsistent multiplicity for TypeAlias (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
July 22, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1715: Navigability constraint expressed wrongly (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed, no action required
Revised Text:
Actions taken:
July 22, 1998: received issue
July 24, 1998: closed issue

Discussion:

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

Issue 1716: Multiplicities on Attributes and References modelled incorrectly (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: duplicate iswue....closed
Revised Text:
Actions taken:
July 22, 1998: received issue
July 24, 1998: closed issue

Discussion:

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

Issue 1749: Cardinality of "RefersTo" and "Exposes" associations (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
July 29, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1770: MofAttribute values do not have aggregation==composite semantics (mof-rtf)

Click here for this issue's archive.
Nature:
Severity: Minor
Summary:

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

Resolution: resolved and closed
Revised Text:
Actions taken:
August 4, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1775: MOF Constraints are pure predicates (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
August 5, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1778: Need to specify when are side-effects allowed (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
August 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1779: exceptions for resolve_qualified_name() (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved, issue closed
Revised Text:
Actions taken:
August 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

Discussion: ([email protected])  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]

Issue 1803: Atomicity of updates (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
August 13, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 1804: Semantics of Reference "set" onto an ordered Association. (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
August 13, 1998: received issue
July 23, 1999: closed issue

Discussion:

 resolved, to be implemented

Issue 1900: New name clash issue from CORBA 2.3 spec (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
August 31, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 1998: MOF RTF Issue: SMIF version of MOF (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Critical
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
September 29, 1998: received issue
July 23, 1999: closed issue

Discussion:

Discussion: ([email protected])  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]

Issue 2025: MOF names implicitly tied to implementation (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
September 30, 1998: received issue
May 8, 2000: closed issue

Discussion:

Discussion: ([email protected])  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]

Issue 2046: What is a UML "profile"? (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 7, 1998: received issue
July 23, 1999: deferred to new RFP/reopened

Discussion:

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.

Issue 2165: Tags that parameterize a meta-model mapping (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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:

Resolution:
Revised Text:
Actions taken:
November 4, 1998: received issue
July 23, 1999: closed issue
August 30, 2000: reopened

Discussion:

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]

Issue 2172: Update specification to track OCL syntax changes (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved, issue closed
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 2173: Validate the OCL constraints in the MOF specification (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue

Discussion:

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.

Issue 2174: Add support for default values to MofAttribute (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred

Discussion:

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: ([email protected])  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

Issue 2175: Document different meaning of "abstract" (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 2176: Add support for Package Consolidation / Clustering (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: resolved and closed
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 2177: Add support for Exception generalization (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: deferred to new RFP

Discussion:

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.

Issue 2178: Define a MOF Class that is the supertype of all Classes (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred

Discussion:

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.

Issue 2179: Add appropriate Attribute default values to the MOF Model (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred

Discussion:

See also Issue 2174

Issue 2180: Revise `container" operations on RefBaseObject (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed issue
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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

Issue 2181: Specify the semantics of Constraint verification (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: deferred to new RFP

Discussion:

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

Issue 2182: Freezing mechanism for all models (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: deferred to new RFP

Discussion:

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

Issue 2183: Add a new technical overview chapter between chapters 2 and 3" (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue

Discussion:

Issue 2185: Edit the MOF specification to improve clarity and readability (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 2186: Need for light-weight References (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred:MOF 2.0

Discussion:

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.

Issue 2187: Support for IDL prefixes in MOF spec (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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:

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 2188: MOF Model IDL versus OMG Style guidelines (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: Deferred:MOF 2.0

Discussion:

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.

Issue 2189: Reflective::InvalidDesignator exception (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: resolved, closed
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 2190: MissingParameter and TooManyParameters exceptions (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 2191: Exception to indicate no corresponding "specific" operation (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
May 8, 2000: closed issue

Discussion:

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]

Issue 2192: RefObject::value() needs to raise NotSet (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: closed resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 2193: Document how to "unset" using the RefObject interface (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 2194: Typos in Reflective::remove_value_at (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: closed, resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 2195: Error in "args" parameter of RefObject::invoke_operation. (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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:

Resolution: closed resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 2196: RefAssociation::link_exists() signature inconsistent (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: closed resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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]

Issue 2197: No reflective all_links() operation (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: closed resolved
Revised Text:
Actions taken:
November 6, 1998: received issue
July 23, 1999: closed issue

Discussion:

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

Issue 2198: Data types available to metamodels is restricted (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

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.

Resolution: see above
Revised Text: Too large to describe here. Refer to separate documents on the DSTC's MOF 1.4 RTF web page. Errata: 1) In 3.3.11 (AliasType), delete the second paragraph. (Starts "It is anticipated ..."). This text is left over from version 1 of this resolution and is now meaningless. 2) In 3.3.27 (Constant), change the type of the 'value' Attribute from 'LiteralType' to 'String'. In the IDL below, change 'LiteralType' to 'wstring', in 3 places. Corrigenda to the Revised Text: These were posted after the ballot commenced, and being substantive, need to be voted on. 1) In order to clarify the intent on how standard PrimitiveType instances are recognized as such, insert into 3.9 (PrimitiveTypes) the following sentences. "Technology mappings shall recognize standard PrimitiveType instances based on their qualified names. Multiple PrimitiveType instances with the required qualified name are deemed to mean the same thing." [This should tie a loose end so that we can back out of the UUID tar pit.] 2) To make the MOF -> IDL mapping work, we need to make sure that StructureTypes contain AT LEAST ONE StructureField. We could make this an "IDL mapping precondition", but I think it is more sensible to make this a Constraint on the MOF Model. I therefore propose the following Constraint be added to StructureType: [C-XX] MustHaveFields -- "A StructureType must contain at least one StructureField.", evaluationPolicy: deferred, OCL: TBD. 3) For consistency, the StructureField class needs to be able to contain any Tags or Constraints on the field. Proposed correction: Add a row to the containment matrix Add a "Contains" heading for StructureType Add an OCL constraint to express the containment rule 4) In 5.6.3.1 through 4, the sypertype strings need to be described as "fully qualified identifiers for OMG IDL interface" ... not just "fully qualified IDL identifiers" 5) In 5.6.2.1, the substitute name doesn't need to a valid CORBA IDL identifier. Rather it needs to be a name that maps to a valid CORBA IDL identifier after Format1/2/3 rewriting and other name mangling. 6) Add text to 3.10.* and 5.3.1 to say how Constant values for the PrimitiveTypes and CorbaIdlTypes are encoded; i.e. the "value" field of Model::Constant ... which used to be Any and now is String (16 bits). * Boolean is "TRUE" or "FALSE" * Integer types are CORBA IDL integer literal syntax with optional leading '-' * Floating point types are CORBA IDL floating point literal syntax with optional leading '-'. * String types are unencoded. * Character types uare unencoded except that an NUL is represented by an empty string. (NUL not being an allowed in an PrimitiveType::String)
Actions taken:
November 6, 1998: received issue
December 3, 2001: closed issue

Discussion:

Discussion: ([email protected])  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.

Issue 2205: Specify behaviour of RefObject.is_instance_of(null,...) (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: see below
Revised Text: Resolution: Reflective::InvalidDesignator should be raised in this case, and in every other case where a null 'designator' argument is passed. The current description of the exception pretty much covers this case, but there is no harm in clarifying the wording. Revised Text: In Table 5-5 in Section 5.5.6, change the "Description" for "Invalid Designator" to read: "Invalid Designator" arises when a "feature" parameter: * is not a Model::ModelElement, or * does not denote an assessible (non nil) CORBA Object. The proposed change adds the phrase "... (non nil) ... ".
Actions taken:
November 12, 1998: received issue
December 3, 2001: closed issue

Discussion:

Issue 2210: Reflective typos (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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

Resolution: Close with no further action. These typos were fixed in MOF 1.3.
Revised Text:
Actions taken:
November 13, 1998: received issue
December 3, 2001: closed issue

Discussion:

Issue 2224: Should Reflective.DesignatorType be "string"? (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 19, 1998: received issue

Discussion:

Issue 2449: Provide tools to chapter 5 UML 1.3R9 draft (mof-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
February 11, 1999: received issue
May 24, 2001: moved to MOF RTF

Discussion:

Issue 2465: Is the multiplicity of Model::Tag::values correct? (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: see below
Revised Text: Resolution: Change multiplicity of the 'values' Attribute of Model::Tag to: lower == 0 / upper == UNBOUNDED / ordered == true / unique == false This will consequently change the IDL for the operations corresponding to the attribute. (See below) Revised Text: This change needs to be made in a number of places. -------------------------------------------------------------------------------- In section 3.4.23, change the multiplicity specification for 'values' from "zero or more; not ordered; not unique" to "zero or more; ordered; not unique" In the following IDL, change all 3 occurences of "AnyBag" to "AnyList". Add the following operations: After the "add_values" operation, add: void add_values_before(in any new_element, in any before_element) raises (Reflective::NotFound, Reflective::MofError); void add_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "modify_values" operation, add: void modify_values_at(in any new_element, in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); After the "remove_values" operation, add: void remove_values_at(in unsigned long position) raises (Reflective::BadPosition, Reflective::MofError); --------------------------------------------------------------------------------- Make the same IDL changes as above to the collected IDL in Appendix B1, and also change typedef sequence < any > AnyBag; to typedef sequence < any > AnyList; --------------------------------------------------------------------------------- Change the MODL for Model in Appendix C as follows: Search for "class Tag : ModelElement" and change attribute bag [0..*] of any values; to attribute list [0..*] of any values; --------------------------------------------------------------------------------- Change the XMI for Model in Appendix A as follows: Search for the string "Contents of Class: Tag", then change <Model.Attribute> <Model.ModelElement.name>values</Model.ModelElement.name> <Model.ModelElement.annotation></Model.ModelElement.annotation> <Model.Feature.visibility xmi.value='public_vis'/> <Model.Feature.scope xmi.value='instance_level'/> <Model.StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <XMI.field>-1</XMI.field> <XMI.field>false</XMI.field> <XMI.field>false</XMI.field> </Model.StructuralFeature.multiplicity> <Model.StructuralFeature.isChangeable xmi.value='true'/> <Model.Attribute.isDerived xmi.value='false'/> <Model.TypedElement.type> <Model.DataType xmi.idref='a101'/>  </Model.TypedElement.type> </Model.Attribute> to read: <Model.Attribute> <Model.ModelElement.name>values</Model.ModelElement.name> <Model.ModelElement.annotation></Model.ModelElement.annotation> <Model.Feature.visibility xmi.value='public_vis'/> <Model.Feature.scope xmi.value='instance_level'/> <Model.StructuralFeature.multiplicity> <XMI.field>0</XMI.field> <XMI.field>-1</XMI.field> <XMI.field>true</XMI.field> <XMI.field>false</XMI.field> </Model.StructuralFeature.multiplicity> <Model.StructuralFeature.isChangeable xmi.value='true'/> <Model.Attribute.isDerived xmi.value='false'/> <Model.TypedElement.type> <Model.DataType xmi.idref='a101'/>  </Model.TypedElement.type> </Model.Attribute> In other word the third "XMI.field" changes from "false" to "true".
Actions taken:
February 22, 1999: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 2495: MOF is using CORBA string for its string data types (mof-rtf)

Click here for this issue's archive.
Nature: Enhancement
Severity: Minor
Summary:

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

Resolution: close with no further action
Revised Text:
Actions taken:
March 1, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 2527: IDL for Reflective Package Interfaces can conflict (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 11, 1999: received issue

Discussion:

Issue 2839: Do non-public Attributes need initialising? (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
August 12, 1999: received issue

Discussion:

Issue 2876: WG: Attribute accessors and mutators (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 9, 1999: received issue

Discussion:

Issue 2877: Section 5-54 of Meta Object Facility (MOF) Specification (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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?

Resolution:
Revised Text: For each subsection 3.4.x that describes a class in the MOF Model, change the IDL as follows: readonly attibute <ClassName>UList all_of_type_tag; readonly attibute <ClassName>UList all_of_class_tag; becomes readonly attibute <ClassName>Set all_of_type_tag; readonly attibute <ClassName>Set all_of_class_tag; Make the same change throughout Appendix B.1
Actions taken:
August 31, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 2881: Constraints on Associations. (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: Change section 5.8.10 as follows: Insert the following as the last sentence of the first paragraph: "It also contains IDL declarations corresponding to any Constraints in the M2-level Association." Insert the following after ", <AssociationSupertypeName>, ... {" // for each Constraint in the Association, generate the appropriate IDL <<CONSTRAINT TEMPLATE>> Note that the use of underlines and bold is SIGNIFICANT in the above edit ...
Actions taken:
September 8, 1999: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 2882: Missing exception for all_*_links operation (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: For each section 3.5.x that describes an Association in the MOF Model, change the IDL section as follows: <AssocName>LinkSet all_<assoc_name>_links(); to <AssocName>LinkSet all_<assoc_name>_links() raises (Reflective::MofError); Make the same changes to the IDL in Appendix B.1
Actions taken:
September 8, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 2922: Collections of imported DataTypes can cause name clashes (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: In Section 5.7.2, replace the following paragraphs: "The declarations for collection types will appear in one of three places ... must only be generated if they are needed within the IDL for the current outermost Package." with "Declarations for the collection types appear following the IDL declaration for a DataType or the forward IDL declaration for a Class. Declarations for collection types for technology neutral and CORBA specific primitive data types appear in the "PrimitiveTypes" and "CorbaIdlTypes" modules respectively." In section 5.8.2, delete the following from the Package module template: "// if this Package is a "top-level" Package, generate any collection types // for built-in types that are required by the IDL for this Package and // its contents typedef sequence < <BuiltinType> > <BuiltinTypeName><CollectionKind>; // if the Package has superPackages, generate any collection // types for inherited types that are required by the IDL for this Package // and its contents typedef sequence < <InheritedType> > <InheritedType><CollectionKind>; // if the Package has Imports, generate any collection types for // imported or clustered types that are required by the IDL for this Package // and its contents typedef sequence < <ImportedType> > <ImportedType><CollectionKind>;" In section 5.8.2, delete the following: "The first group of declarations within the module are the sequence type declarations for collection types: * If the M2-level Package is a top-level Package, the template generates collection types for the MOF built-in types as required. * If the M2-level Package has superPackages, the template generates collection types for inherited Classes and DataTypes as required. * If the M2-level Package has Imports, the template generates collection types for any Classes and DataTypes in the imported or clustered Packages. Note: Collection types should only be generated if they are going to be used within the current outermost module." Change "After the collection types, the ..." to "The ..." In section 5.8.5, change the following comment in the template: "// generate type declarations for any collections of this Class that // will be used by the IDL being generated" to "// generate type declarations for any collections of this Class" In the following description, change "If any collection types for this Class are required, their declarations should follow the forward declarations. Note: Collection types should only be generated if they are going to be used within the current outermost module." to "Collection type declarations for the Class follow the forward declarations." In section 5.8.14, change the text (as amended by 2198) from: "* If the outermost enclosing Package for the DataType contains a use of the DataType in a non-[1..1] Attribute or Parameter, the template generates appropriate synthesized collection types according to Section 5.7.2, "Generation Rules for Collection Types," on page 5-41. Note: In the interests of IDL footprint size, the DataType template should only generate collection type declarations if they are needed." to: "* The template generates collection types according to Section 5.7.2, "Generation Rules for Collection Types," on page 5-41." In 3.9.1, change the IDL for the PrimitiveTypes module (added by 2198) to be as follows: #pragma prefix "org.omg.mof" module PrimitiveTypes { typedef sequence < boolean > BooleanBag; typedef sequence < boolean > BooleanSet; typedef sequence < boolean > BooleanList; typedef sequence < boolean > BooleanUList; typedef sequence < long > LongBag; typedef sequence < long > LongSet; typedef sequence < long > LongList; typedef sequence < long > LongUList; typedef sequence < long long > LongLongBag; typedef sequence < long long > LongLongSet; typedef sequence < long long > LongLongList; typedef sequence < long long > LongLongUList; typedef sequence < float > FloatBag; typedef sequence < float > FloatSet; typedef sequence < float > FloatList; typedef sequence < float > FloatUList; typedef sequence < double > DoubleBag; typedef sequence < double > DoubleSet; typedef sequence < double > DoubleList; typedef sequence < double > DoubleUList; typedef sequence < wstring > WStringBag; typedef sequence < wstring > WStringSet; typedef sequence < wstring > WStringList; typedef sequence < wstring > WStringUList; interface PrimitiveTypesPackage : Reflective::RefPackage { }; interface PrimitiveTypesPackageFactory { PrimitiveTypesPackage create_primitive_types_package() raises (Reflective::MofError); }; }; In 5.3.1, change the IDL for the CorbaIdlTypes module (added by 2198) to be as follows: #pragma prefix "org.omg.mof" module CorbaIdlTypes { typedef sequence < octet > OctetBag; typedef sequence < octet > OctetSet; typedef sequence < octet > OctetList; typedef sequence < octet > OctetUList; typedef sequence < short > ShortBag; typedef sequence < short > ShortSet; typedef sequence < short > ShortList; typedef sequence < short > ShortUList; typedef sequence < unsigned short > UShortBag; typedef sequence < unsigned short > UShortSet; typedef sequence < unsigned short > UShortList; typedef sequence < unsigned short > UShortUList; typedef sequence < unsigned long > ULongBag; typedef sequence < unsigned long > ULongSet; typedef sequence < unsigned long > ULongList; typedef sequence < unsigned long > ULongUList; typedef sequence < unsigned long long > ULongLongBag; typedef sequence < unsigned long long > ULongLongSet; typedef sequence < unsigned long long > ULongLongList; typedef sequence < unsigned long long > ULongLongUList; typedef sequence < long double > ULongDoubleBag; typedef sequence < long double > ULongDoubleSet; typedef sequence < long double > ULongDoubleList; typedef sequence < long double > ULongDoubleUList; typedef sequence < string > StringBag; typedef sequence < string > StringSet; typedef sequence < string > StringList; typedef sequence < string > StringUList; typedef sequence < char > CharBag; typedef sequence < char > CharSet; typedef sequence < char > CharList; typedef sequence < char > CharUList; typedef sequence < wchar > WCharBag; typedef sequence < wchar > WCharSet; typedef sequence < wchar > WCharList; typedef sequence < wchar > WCharUList; interface CorbaIdlTypesPackage : Reflective::RefPackage { }; interface CorbaIdlTypesPackageFactory { CorbaIdlTypesPackage create_corba_idl_types_package() raises (Reflective::MofError); }; }; Propagate changes to Appendix B.
Actions taken:
October 5, 1999: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 2923: mof rtf issue - setting UUIDs (mof-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Stephen Brodsky, Ph.D, sbrodsky(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 22, 1999: received issue

Issue 2925: mof rtf issue - coverage of RefXXX interfaces by MOF metamodel (mof-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Stephen Brodsky, Ph.D, sbrodsky(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 22, 1999: received issue

Issue 2971: Reflective IDL fix for CORBA 2.3 (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: Adopt approach 1 to minimize impact on interoperability. Flag this to be fixed properly in MOF 2.0.
Revised Text: Change all occurrences of "ValueType" in IDL to "_ValueType". Change all occurrences of "ValueType" in text to "Reflective::ValueType" Sections 5.4, 6.2.1, 6.2.3, 6.3.2, Appendix B.2
Actions taken:
October 14, 1999: received issue
December 3, 2001: closed issue

Issue 3043: MOF and IDL repository ids (mof-rtf)

Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 20, 1999: received issue

Issue 3094: Operation Model::Tag::add_elements_before should not appear in the IDL (mof-rtf)

Click here for this issue's archive.
Source: Object Radiance (Mr. GK Khalsa, khalsa(at)objectrad.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: In section 3.4.23, delete the "add_elements_before" operation from the "Tag" interface. Make the same change in Appendix B.1
Actions taken:
December 6, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 3112: Template should suppress add for [x..x] Attributes (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
December 13, 1999: received issue

Issue 3130: Can MOF Package contain a Constant? (mof-rtf) (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: In 3.9.3 and A.1, change [C-43] to read: Set{Package, Class, DataType, Association, Exception, Constant, Constraint, Import, Tag} -> includesAll(self.contentTypes)
Actions taken:
December 16, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 3131: Package Contains Association (mof-rtf) (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

There is a typo in table 3-4 of the MOF 1.3 Specification indicating that a  Package cannot contain an Association.

Resolution: This is clearly a typo in the table, which currently doesn't allow anything to contain an Associatio
Revised Text: Change the containment matrix in table 3-4 to state that a Package may contain an Association
Actions taken:
December 16, 1999: received issue
December 3, 2001: closed issue

Discussion:

This is clearly a typo in the table, which currently doesn't allow anything to contain an Association.  Fix it

Issue 3133: "*" prefix on Simple Type Names (mof-rtf) (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: close no action
Revised Text:
Actions taken:
December 17, 1999: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 3379: Incorrect return type for Assoc query operation (mof-rtf)

Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: duplicate close issue
Revised Text: This is the same as Issue 4133 which has now been resolved.
Actions taken:
February 28, 2000: received issue
December 3, 2001: closed issue

Issue 3411: MOF specifies no interfaces for actually (de-)serializing a model (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Enhancement
Severity: Critical
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 13, 2000: received issue

Issue 3444: MOF 1.3 Incorrect attribute order in diagrams (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: Redraw all UML diagrams in Chapter 3 as Framemaker diagram. Ensure that all attributes and operations are in the correct order. Reorder the Head3 subsections in Chapter 3 as required to match the order of the IDL and XMI.
Actions taken:
March 22, 2000: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 3445: MOF 1.3 IDL template for clustering uses wrong name (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 22, 2000: received issue

Issue 3446: MOF 1.3 Why have rule against abstract packages? (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: This is a duplicate of issue 4202. Close with no further action.
Revised Text:
Actions taken:
March 22, 2000: received issue
December 3, 2001: closed issue

Issue 3447: MOF 1.3 Why prevent nonpublic Associations? (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 22, 2000: received issue

Issue 3448: MOF 1.3 Package should subtype Classifier (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
March 22, 2000: received issue

Issue 3527: MOF 1.3: are Associations contained in Packages or not? (mof-rtf)

Click here for this issue's archive.
Source: Model Driven Solutions (Mr. Steve Cook, steve-c(at)modeldriven.org)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: duplicate of issue 3131
Revised Text:
Actions taken:
April 3, 2000: received issue
August 30, 2000: closed issue

Discussion:

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

Issue 3528: Can MOF Class contain a Constant? (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Change constraint [C-15] as recommended
Revised Text: In section 3.9.3, change the OCL for [C-15] to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constraint, Tag} -> ... to read: ... Set{Class, DataType, Attribute, Reference, Operation, Exception, Constant, Constraint, Tag} -> ... Also change the "description" for [C-15] to read: "... Operations, Exceptions, Constants, Constraints and Tags." The OCL change also needs to be made to [C-15] in the XMI document in Appendix A. Search for "Contents fo Class: Class", then insert "Constant, " at the appropriate point in the first <XMI.any> element.
Actions taken:
April 4, 2000: received issue
December 3, 2001: closed issue

Issue 3529: "*" not needed on DataType name (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: section 3.4.7, remove all text starting from "The types represented by DataTypes ..." and ending with "... into a qualified name". In section 5.8.16, change the first two sentences of the first bullet point to read as follows: "* A DataType that maps to an IDL primitive type does not require a data type declaration or collection type declarations at this point."
Actions taken:
April 4, 2000: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 3533: MOF RTF Issue: typos in Reflective.idl (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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]

Resolution: Make the changes as suggested
Revised Text: In the Reflective module in Appendix B.2, change the identifier for the constant currently called WRONG_DESIGNATOR_DESIGNATOR_VIOLATION to be WRONG_DESIGNATOR_VIOLATION. In the IDL for Reflective::RefObjec in Appendix B.2, change the declaration of the ref_unset_value() operation to be void ref_unset_value(in DesignatorType feature) raises (MofError);
Actions taken:
April 7, 2000: received issue
December 3, 2001: closed issue

Issue 3606: MofErrors for refQueryLink and refModifyLink (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: Correct the descriptions of refQuery and refModifyLink to match the IDL mapping
Revised Text: Add "Not Navigable" to the list of MofErrors raised by refQuery and refModifyLink. Add the following sentence to the description of refQuery after "... cases where this is not so." ""Not Navigable" is raised if the "queryEnd" parameter designates an AssociationEnd which has "isNavigable" set to false." ["Not Navigable" already in the text for refModifyLink. It's just the list of exceptions that needs fixing.]
Actions taken:
May 10, 2000: received issue
December 3, 2001: closed issue

Issue 3744: Minor changes to some Reflective operations (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
July 17, 2000: received issue

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.

Issue 3745: Reflective interface for Package factory (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
July 17, 2000: received issue

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.

Issue 3897: Specify XMI parameters for the MOF / XMI interchange format (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 22, 2000: received issue

Issue 4111: The Metadata architecture needs to move away from the 4 levels and labels (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
December 8, 2000: received issue

Discussion:

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.

Issue 4133: Model::Contains::container return type wrong (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see above
Revised Text: Make the following changes to the description for the <association_end1_name> operation in 5.8.10. In the third paragraph, change "If it has bouonds of [1..1] ... " to read "If it has bounds [0..1] or [1..1] ..." Add a new paragraph after paragraph 3 that reads as follows: "The result of the operation gives the object or collection of objects related to the parameter object by a Link or Links in this Association. If the multiplicity is [1..1], the result will be a non-nill object reference. If the multiplicity is [0..1], the operation will return a non-nil object reference if there is a related object, and a nil object reference otherwise. In other cases, the operation will return a (possibly zero length) sequence of non-nil object references. If the association end being queried is ordered, the order of the contents of the returned collection is significant." Actions taken:
Actions taken:
January 12, 2001: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 4154: MODL Appendix needs updating (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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: see above
Revised Text: A new version of the MODL Appendix will be supplied, fixing the problems mentioned and incorporating other changes to the MOF Model and the new PrimitiveTypes and CorbaIdlTypes packages.
Actions taken:
January 17, 2001: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 4175: MOF Unbounded should have type long (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: The IDL clearly contains a typo. Fix it so that UNBOUNDED is signed
Revised Text: Change the IDL constant declaration in 3.8.1 to read: const long UNBOUNDED = -1;
Actions taken:
January 26, 2001: received issue
December 3, 2001: closed issue

Issue 4202: Abstract package (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
February 16, 2001: received issue
December 3, 2001: closed issue; Duplicate or Merged

Discussion:

This issue is duplicated by Issue 3446

Issue 4211: MOF IDL change (mof-rtf)

Click here for this issue's archive.
Source: ETA Sistemi Srl (Mr. Davide Mora, )
Nature: Enhancement
Severity: Critical
Summary:

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.

Resolution: see above
Revised Text: Revise Chapter 6 and the IDL Appendix to effect the above changes
Actions taken:
February 26, 2001: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 4231: predefined tag for marking attributes to act as qualifier in classifier (mof-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution:
Revised Text:
Actions taken:
March 21, 2001: received issue

Issue 4232: role is named 'containedElement' while the reference is named 'contents' (mof-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 21, 2001: received issue

Discussion:

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.

Issue 4237: predefined tag for marking attributes needed (mof-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

 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.

Resolution: close, no action
Revised Text:
Actions taken:
March 27, 2001: received issue
October 3, 2001: closed issue

Discussion:

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

Issue 4238: The role name of the Namespace->ModelElement association end (mof-rtf)

Click here for this issue's archive.
Source: France Telecom R&D (Mr. Mariano Belaunde, mariano.belaunde(at)orange.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
March 27, 2001: received issue

Issue 4255: MOF IDL rules to minimize network roundtrips (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
April 6, 2001: received issue

Discussion:

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.

Issue 4267: MOF-RTF issue: AttachesTo.modelElement - ordered (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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)

Resolution:
Revised Text:
Actions taken:
April 11, 2001: received issue

Issue 4295: MofError when Operation impl violates structural constraints (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution: see above
Revised Text: At the end of 5.8.13 add the following paragraph. "If an Operation has a multi-valued 'out', 'inout' or 'return' Parameter, or if it can raise an Exception with a multi-valued field, its implementation shall ensure that the returned collection or collections satisfy the Parameters' multiplicity constraints. If they do not, the implementation shall use MofError to signal a Semantic Error. (Since this case is deemed to be an error in the implementation, "Overflow, Underflow, Duplicate or Invalid Object must not be signalled here.)" In Section 6.2.3, add "Semantic Errors" to the list of MofError exception kinds for "refInvokeOperation". In Section 6.2.3, add the following as the second to last paragraph of the description of "refInvokeOperation": "A "Semantic Error" will occur if the invoked Operation tries to return a collection value as a result, out or inout parameter that violates the Parameter's structural constraints. This will also occur if an Exception Parameter's value is similarly incorrect." Actions taken:
Actions taken:
May 8, 2001: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 4313: Error in MOF 1.3 XMI - ViolationType (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
May 18, 2001: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 4351: Primitive data types usage in the MOF Model. (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: 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".
Actions taken:
June 19, 2001: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 4383: The current MOF package level import is not sufficient (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
June 20, 2001: received issue

Issue 4384: Move the 'verify' operation to RefBaseObject (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: Remove operation 'verify' from section 3.4.1 Remove sections 3.6.7 (DepthKind), 3.6.15 (VerifyResultKind) and 3.6.16 (ViolationType). These data types no longer need to be part of the MOF Model. Add the following after the description of 'refDelete' in section 6.2.3. "refVerifyConstraints The "refVerifyConstraints" operation triggers verification of the Constraints attached to the target object's meta-object. specific analog: none return type: boolean parameters: deepVerify : in boolean maxProblems : in long problems : out ViolationTypeSet exceptions: MofError(SemanticError) The operation should attempt to check any Constraints for the target object that may possibly fail, including any deferred structural constraints. If all constraints hold for the target, the result is true, and an empty set will be returned in 'problems'. Otherwise, the result is false. If 'deepVerify' is false, just the Constraints attached to this object's meta-object are evaluated. Otherwise any Constraints attached to the meta-objects of this object's component objects (direct or indirect) are also evaluated. For example, if a Class is defined with Constraints attached to one of its Attributes, these will only be evaluated if 'deepVerify' is true. The 'maxProblems' parameter allows the caller to specify the maximum number of ViolationType instances to be returned in 'problems'. If 'maxProblems' is zero, no ViolationType instances will be returned. When an implementation detects more constraint violations that can be reported, it should cease checking and return the results that it can. If 'maxProblems' is UNBOUNDED (-1), or any other negative number, the implementation should return ViolationType instances for all constraint violations The 'problems' parameter is used to return ViolationType descriptors for any constraints that do not currently hold. At most 'maxProblems descriptors may be returned by a call. The contents of the fields of each ViolationType are analogous to the contents of the fields of a MofError exception; see section 5.x.x. The field 'object_in_error' which is not present in the MofError exception is used to return the MOF object for which the constraint failed, or nil when a Constraint on a DataType is violated." Add the following IDL operation as the last operation of the RefBaseObject interface in section 6.2.1: boolean refVerifyConstraints(in boolean deepVerify, in unsigned long maxProblems, out ViolationTypeSet problems) raises (MofError) Make the following change to 5.4.3 (Constraint Errors). Change the description of the "element_in_error" to read: "* The 'element_in_error' is the designator for the ModelElement whose Constraint has been violated. In the case of Constraint on a DataType, the designator is the Parameter or Attribute for the context in which the erroneous DataType instance occured." Add the following at the end of section 6.3.2 "The 'refVerifyConstraints' operation uses the ViolationTypeSet type to return descriptions of constraints that do not hold. This type and the ViolationType type are defined below. The 'error_kind', 'element_in_error', 'extra_info' and 'error_description' of ViolationType are equivalent to fields of the MofError exception; see section 5.x.x. The 'object_in_error' field gives the MOF object (if any) whose state violates the constraint reported. When a Constraint on a DataType is violated, 'object_in_error' will refer to the MOF object which has the erroneous DataType instance as an attribute value. struct ViolationType { string error_kind; RefBaseObject object_in_error; RefObject element_in_error; NamedValueList extra_info; string error_description; }; typedef sequence < ViolationType > ViolationTypeSet; Make corresponding additions and removals to the IDL in Appendix B1 and B2, the XMI in Appendix A and the MODL in Appendix C.
Actions taken:
June 21, 2001: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 4396: ::Model::Package::internalize/externalize in MOF 1.4 (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution: see above
Revised Text: Remove definition of 'internalize' and 'externalize' from Operations section of Model::Package in 3.4.18. Remove from IDL. Remove associated exceptions and data types; i.e. 3.6.13 FormatType, 3.7.3 ObjectNotExternalizable, 3.7.4 FormatNotSupported and 3.7.5 IlformedExternalizedObject Update XMI, IDL and MODL in Appendices. First, make sure that you REALLY have generated the client and server side stubs / skeletons from the same IDL. Check that you have recompiled, relinked and rebuilt your applet JAR file. A mismatch between the stubs / skeletons used could cause this exception (among others). Next turn on logging on the server side to try to work out what is happening. Read the manual to find how. [I don't use VBC++ ...] Some possible causes include: * the client is passing a null value for an IDL data type or a value that has a null field, etc. * the server is trying to return / pass back a null, etc. * the server is calling an ORB / POA / Any / TypeCode / etc operation with the wrong parameters.
Actions taken:
July 5, 2001: received issue
December 3, 2001: closed issue

Discussion:

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.

Issue 4413: IDL mapping Tag for specifying IDL #pragma versions (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution: see above
Revised Text: Change the heading for section 5.6.1 from "5.6.1 Tags for Specifying IDL #pragma prefix" to "5.6.1 Tags for Specifying IDL #pragma directives" Add the following as section 5.6.1.2 "5.6.1.2 IDL Version When a MOF metamodel is modified it will often result in generated IDL that has the same module and interface names but different interface signatures. In such cases, it is strictly necessary to use different IDL version numbers for all types, interfaces and exceptions whose signatures have changed. In MOF 1.4, this can be done by attaching an Version tag to model elements. tag id: "org.omg.mof.idl_version" attaches to: Model::Package, Model::Class, Model::Association, Model::Attribute, Model::Operation, Model::Reference, Model::StructureType, Model::AliasType, Model::CollectionType, Model::EnumerationType, Model::Exception, Model::Constant, Model::Constraint values: one String idl generation: A #pragma version is inserted into the IDL for module, interface, data type, constant and exception declarations that are generated from the tagged model element. Version tags on Attributes, Operations and References result in version tags for the corresponding IDL operations. Refer to the respective templates for details. restrictions: [1] A Version tag value must have the form <major>.<minor> where <major> and <minor> are unsigned 16 bit decimal integers." [2] It is not meaningful to attach a Version tag to an AssociationEnd, Import, Parameter, Tag, StructureField or PrimitiveType. Add the following to 5.8.2, after "module <PackageName> {" // If this Package has an idl_version Tag #pragma version <PackageName> <<version>> Add the following to 5.8.3, after "interface <PackageName>PackageFactory {" // If this Package has an idl_version Tag #pragma version <PackageName>PackageFactory <<version>> Add the following to 5.8.4, after "... {" // If this Package has an idl_version Tag #pragma version <PackageName>Package <<version>> Add the following to 5.8.5, after the respective typedefs // If this Class has an idl_version Tag #pragma version <ClassName>Bag <<version>> // If this Class has an idl_version Tag #pragma version <ClassName>Set <<version>> // If this Class has an idl_version Tag #pragma version <ClassName>List <<version>> // If this Class has an idl_version Tag #pragma version <ClassName>UList <<version>> Add the following to 5.8.7, after "... {" // If this Class has an idl_version Tag #pragma version <ClassName>Class <<version>> Add the following to 5.8.8, after "... {" // If this Class has an idl_version Tag #pragma version <ClassName> <<version>> In 5.8.10: after the <AssociationName>Link struct declaration add: // If this Association has an idl_version Tag #pragma version <AssociationName>Link <<version>> after the <AssociationName>LinkSet typedef declaration add: // If this Association has an idl_version Tag #pragma version <AssociationName>LinkSet <<version>> after "... {" add: // If this Association has an idl_version Tag #pragma version <AssociationName> <<version>> In 5.10.11: after every Attribute operation <name>, add // If this Attribute has an idl_version Tag #pragma version <name> <<version>> In 5.10.12: after every Reference operation <name>, add // If this Reference has an idl_version Tag #pragma version <name> <<version>> In 5.10.13: after the Operation's <operation_name> declaration, add // If this Operation has an idl_version Tag #pragma version <operation_name> <<version>> In 5.10.14: after the Exception's <ExceptionName> declaration, add // If this Exception has an idl_version Tag #pragma version <ExceptionName> <<version>> In 5.10.15: after the 'const' declaration, add // If this Constant has an idl_version Tag #pragma version <CONSTANT_NAME> <<version>> In 5.10.16: after the 4 alternative declarations of <datatype_name>, add // If this DataType has an idl_version Tag #pragma version <datatype_name> <<version>> after the 4 collection typedefs, add (respectively) // If this DataType has an idl_version Tag #pragma version <datatype_name>Bag <<version>> // If this DataType has an idl_version Tag #pragma version <datatype_name>Set <<version>> // If this DataType has an idl_version Tag #pragma version <datatype_name>List <<version>> // If this DataType has an idl_version Tag #pragma version <datatype_name>UList <<version>> In 5.10.17: after the 'const' declaration, add // If this Constraint has an idl_version Tag #pragma version <CONSTRAINT_NAME> <<version>>
Actions taken:
July 21, 2001: received issue
December 3, 2001: closed issue

Discussion:

    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.

Issue 4418: Clarify whether null instances are currently valid MOF values (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Clarification
Severity: Significant
Summary:

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.

Resolution: see above
Revised Text: In Section 4.2, insert the following bullet points into the respective bullet lists that contrast Classes and DataTypes: "* Null is a valid instance of an M2-level Class, though there are limitations on its use." "* Null is not a valid instance of an M2-level DataType." In Section 4.4, add the following sentence to list item 1. "The null Class instance is only equal to itself." In Section 4.5, add the following as the last two paragraphs: "The null instance of an M2-level Class has a conceptual identity that is distinct from other (non-null) instances. Null conceptually exists for ever in all Class extents, but it does not have attribute values and cannot be related to other Instances (or itself) by an Association link." "Note - While null is currently a valid Class instance, some technology mappings do not support it. Therefore it is inadvisable to rely on being able to use the null instance value in a technology neutral metamodel." In Section 4.9.2.1, add "... except for the respective null instances." to the end of the first sentence. In Section 4.9.2.2, add the following bullet point: "* A Link cannot connect a null Class instance to any other instance (including itself)." In Section 4.10.2, add the following sentence to list item 1. "(This restriction does not apply when "v1" is a null instance.)" In Section 4.11.2, add the following sentence: "Since the null instance of a Class is defined to notionally belong to all extents for the Class, the Composition Closure Rule does not apply to Attributes with null values."
Actions taken:
July 25, 2001: received issue
December 3, 2001: closed issue

Discussion:

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

Issue 4419: Disallow null instance values (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Revision
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
July 25, 2001: received issue

Discussion:

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

Issue 4483: Add 'semantics' attribute to Operation. (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Enhancement
Severity: Significant
Summary:

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.

Resolution:
Revised Text:
Actions taken:
August 12, 2001: received issue

Issue 4484: Delete all non-MOF-specific terms from the Glossary (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:

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

Resolution:
Revised Text:
Actions taken:
August 12, 2001: received issue

Issue 4568: Representation of constraints (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Revision
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 16, 2001: received issue

Issue 4569: Modeling OCL Helper Functions (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Enhancement
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
September 16, 2001: received issue

Issue 4584: mof-rtf issue: Association Generalization (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 1, 2001: received issue

Issue 4586: Tracking identity of replicated / interchanged metadata (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 3, 2001: received issue

Issue 4592: Alignment of reflective interfaces with JMI (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 4, 2001: received issue

Issue 4593: Deprecate object inheritance of class proxy interface (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 4, 2001: received issue

Issue 4594: Remove obsolete material (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 4, 2001: received issue

Issue 4607: resolveQualifiedName operation (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 8, 2001: received issue

Issue 4609: Looking up metaobject using MOFID (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 8, 2001: received issue

Issue 4621: Navigability of assoc. ends in MOF model (mof-rtf)

Click here for this issue's archive.
Source: GoodData Corporation (Mr. Martin Matula, matulic(at)gmail.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
October 17, 2001: received issue

Issue 4622: Restrictions needed for nested Packages and Classes (mof-rtf)

Click here for this issue's archive.
Source: DSTC (Dr. Stephen Crawley, nobody)
Nature: Uncategorized Issue
Severity:
Summary:

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

Resolution:
Revised Text:
Actions taken:
October 18, 2001: received issue

Issue 4664: Section 5.8.12 of ad/01-07-17, 1st para, 2nd sentence is wrong (mof-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity: Minor
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 6, 2001: received issue

Issue 4700: Multiplicity be optional for non-navigable association ends. (mof-rtf)

Click here for this issue's archive.
Source: International Business Machines (Dr. Stephen Brodsky, Ph.D, sbrodsky(at)us.ibm.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 12, 2001: received issue

Issue 4715: Unnecessary constraint on import by nested packages (mof-rtf)

Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 27, 2001: received issue

Issue 4720: Association Generalization Proposal (mof-rtf)

Click here for this issue's archive.
Source: Escape Velocity (Mr. Don Baisley, donbaisley(at)live.com)
Nature: Uncategorized Issue
Severity:
Summary:

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.

Resolution:
Revised Text:
Actions taken:
November 30, 2001: received issue

Issue 4798: "exposedEnd" for any of the references in the MOF metamodel. (mof-rtf)

Click here for this issue's archive.
Nature: Revision
Severity: Significant
Summary:

  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.

Resolution:
Revised Text:
Actions taken:
December 21, 2001: received issue