Issue 784: External Types as DataTypes Limits Modeling Jira Issue MOF14-92
Issue 785: IDL Generation Issue - factory operation parameters for multivalued attrib Jira Issue MOF14-93
Issue 786: Typos in MOF 1.1 document (1) Jira Issue MOF14-94
Issue 787: Typos in MOF 1.1 document (2) Jira Issue MOF14-95
Issue 788: Typos in MOF 1.1 document (3) Jira Issue MOF14-96
Issue 940: Package create template Jira Issue MOF14-97
Issue 941: Package create template: StructuralError needs to be raised Jira Issue MOF14-98
Issue 942: package create template: ConstraintError Jira Issue MOF14-99
Issue 943: package create template: names of parameters need to be formated Jira Issue MOF14-100
Issue 944: Similar to issue 940 Jira Issue MOF14-101
Issue 945: Jira Issue MOF14-102
Issue 946: Similar o issue 941 Jira Issue MOF14-103
Issue 947: Type Create template, order of parameters Jira Issue MOF14-104
Issue 948: MOF-IDL needs to be re-generated Jira Issue MOF14-105
Issue 949: Type Hierarchy Error in IDL Jira Issue MOF14-106
Issue 957: IDL Mapping--#includes for inheritted Packages Jira Issue MOF14-107
Issue 965: MOF IDL mapping-types of parameters with multiplicities Jira Issue MOF14-108
Issue 966: MOF IDL /MODL - Type Hierarchy error Jira Issue MOF14-109
Issue 967: MOF IDL Mapping with parameters Jira Issue MOF14-110
Issue 968: RefObject::create_instance and abstract types Jira Issue MOF14-111
Issue 969: Editorial; change MOF Type to MOF Class Jira Issue MOF14-112
Issue 1075: Type of Facility.MofRepository.packageFactory incompatible with its purpos Jira Issue MOF14-113
Issue 1076: Generated location parameters need clear specification of base value Jira Issue MOF14-114
Issue 1077: Description of meta-model as a single package is incorrect Jira Issue MOF14-115
Issue 1078: Association interface generation templates require exceptions Jira Issue MOF14-116
Issue 1079: Association IDL generation needs to consider AssociationEnd.isChangeable Jira Issue MOF14-117
Issue 1080: ConstrainViolation vs. ConstraintError confusion (editorial) Jira Issue MOF14-118
Issue 1081: ConstraintError exception needed in more IDL generation templates Jira Issue MOF14-119
Issue 1083: Operations should return nil reference instead of raising NotSet Jira Issue MOF14-120
Issue 1084: Single-valued parameters should not be defined with sequences Jira Issue MOF14-121
Issue 1085: Consider a better approach to generated exceptions Jira Issue MOF14-122
Issue 1141: Incorrect ocl specification(s) Jira Issue MOF14-123
Issue 1305: Illegal IDL redefinitions Jira Issue MOF14-124
Issue 1306: IDL generation - IMPORT TEMPLATE clarification Jira Issue MOF14-125
Issue 1307: IDL Mapping/Identifier Naming Jira Issue MOF14-126
Issue 1308: IDL generation Association Template Syntax Jira Issue MOF14-127
Issue 1496: Identifier formating error in MOF generates IDL Jira Issue MOF14-128
Issue 1497: Naming of Tags Jira Issue MOF14-129
Issue 1498: MOF RTF Issue: Library of collection types? Jira Issue MOF14-130
Issue 1500: MOF RTF Issue: M1 life-cycle operations Jira Issue MOF14-131
Issue 1501: MOF RTF Issue: aggregations crossing M1 and M2 package boundary Jira Issue MOF14-132
Issue 1502: MOF RTF Issue: Behavior of M1 level interfaces vagualy specified Jira Issue MOF14-133
Issue 1513: Exception for creating instances of imported supertypes? Jira Issue MOF14-134
Issue 1516: Description of with_<associationed> operations Jira Issue MOF14-135
Issue 1517: set_<referencename> needs StructuralError Jira Issue MOF14-136
Issue 1518: Should set_<referencename>(nil) be legal? Jira Issue MOF14-137
Issue 1683: Convenient way to discriminate instances of subclasses Jira Issue MOF14-138
Issue 1711: Multiplicities on Attributes and References modelled incorrectly Jira Issue MOF14-139
Issue 1712: Navigability constraint expressed wrongly Jira Issue MOF14-140
Issue 1714: Inconsistent multiplicity for TypeAlias Jira Issue MOF14-141
Issue 1715: Navigability constraint expressed wrongly Jira Issue MOF14-142
Issue 1716: Multiplicities on Attributes and References modelled incorrectly Jira Issue MOF14-143
Issue 1749: Cardinality of "RefersTo" and "Exposes" associations Jira Issue MOF14-144
Issue 1770: MofAttribute values do not have aggregation==composite semantics Jira Issue MOF14-145
Issue 1775: MOF Constraints are pure predicates Jira Issue MOF14-146
Issue 1778: Need to specify when are side-effects allowed Jira Issue MOF14-147
Issue 1779: exceptions for resolve_qualified_name() Jira Issue MOF14-148
Issue 1803: Atomicity of updates Jira Issue MOF14-149
Issue 1900: New name clash issue from CORBA 2.3 spec Jira Issue MOF14-150
Issue 1998: MOF RTF Issue: SMIF version of MOF Jira Issue MOF14-151
Issue 2025: MOF names implicitly tied to implementation Jira Issue MOF14-152
Issue 2172: Update specification to track OCL syntax changes Jira Issue MOF14-153
Issue 2175: Document different meaning of "abstract" Jira Issue MOF14-154
Issue 2176: Add support for Package Consolidation / Clustering Jira Issue MOF14-155
Issue 2180: Revise `container" operations on RefBaseObject Jira Issue MOF14-156
Issue 2185: Edit the MOF specification to improve clarity and readability Jira Issue MOF14-157
Issue 2187: Support for IDL prefixes in MOF spec Jira Issue MOF14-158
Issue 2189: Reflective::InvalidDesignator exception Jira Issue MOF14-159
Issue 2190: MissingParameter and TooManyParameters exceptions Jira Issue MOF14-160
Issue 2191: Exception to indicate no corresponding "specific" operation Jira Issue MOF14-161
Issue 2192: RefObject::value() needs to raise NotSet Jira Issue MOF14-162
Issue 2193: Document how to "unset" using the RefObject interface Jira Issue MOF14-163
Issue 2194: Typos in Reflective::remove_value_at Jira Issue MOF14-164
Issue 2195: Error in "args" parameter of RefObject::invoke_operation. Jira Issue MOF14-165
Issue 2196: RefAssociation::link_exists() signature inconsistent Jira Issue MOF14-166
Issue 2197: No reflective all_links() operation Jira Issue MOF14-167
Issue 2198: Data types available to metamodels is restricted Jira Issue MOF14-84
Issue 2205: Specify behaviour of RefObject.is_instance_of(null,...) Jira Issue MOF14-85
Issue 2210: Reflective typos Jira Issue MOF14-86
Issue 2465: Is the multiplicity of Model::Tag::values correct? Jira Issue MOF14-87
Issue 2495: MOF is using CORBA string for its string data types Jira Issue MOF14-88
Issue 2877: Section 5-54 of Meta Object Facility (MOF) Specification Jira Issue MOF14-89
Issue 2881: Constraints on Associations. Jira Issue MOF14-90
Issue 2882: Missing exception for all_*_links operation Jira Issue MOF14-91
Issue 2922: Collections of imported DataTypes can cause name clashes Jira Issue MOF14-36
Issue 2971: Reflective IDL fix for CORBA 2.3 Jira Issue MOF14-37
Issue 3094: Operation Model::Tag::add_elements_before should not appear in the IDL Jira Issue MOF14-38
Issue 3130: Can MOF Package contain a Constant? (mof-rtf) Jira Issue MOF14-39
Issue 3131: Package Contains Association (mof-rtf) Jira Issue MOF14-40
Issue 3133: "*" prefix on Simple Type Names (mof-rtf) Jira Issue MOF14-41
Issue 3379: Incorrect return type for Assoc query operation Jira Issue MOF14-42
Issue 3444: MOF 1.3 Incorrect attribute order in diagrams Jira Issue MOF14-43
Issue 3446: MOF 1.3 Why have rule against abstract packages? Jira Issue MOF14-44
Issue 3527: MOF 1.3: are Associations contained in Packages or not? Jira Issue MOF14-168
Issue 3528: Can MOF Class contain a Constant? Jira Issue MOF14-45
Issue 3529: "*" not needed on DataType name Jira Issue MOF14-46
Issue 3533: MOF RTF Issue: typos in Reflective.idl Jira Issue MOF14-47
Issue 3606: MofErrors for refQueryLink and refModifyLink Jira Issue MOF14-48
Issue 4133: Model::Contains::container return type wrong Jira Issue MOF14-49
Issue 4154: MODL Appendix needs updating Jira Issue MOF14-50
Issue 4175: MOF Unbounded should have type long Jira Issue MOF14-51
Issue 4202: Abstract package Jira Issue MOF14-169
Issue 4211: MOF IDL change Jira Issue MOF14-52
Issue 4237: predefined tag for marking attributes needed Jira Issue MOF14-53
Issue 4295: MofError when Operation impl violates structural constraints Jira Issue MOF14-54
Issue 4313: Error in MOF 1.3 XMI - ViolationType Jira Issue MOF14-55
Issue 4351: Primitive data types usage in the MOF Model. Jira Issue MOF14-56
Issue 4384: Move the 'verify' operation to RefBaseObject Jira Issue MOF14-57
Issue 4396: ::Model::Package::internalize/externalize in MOF 1.4 Jira Issue MOF14-58
Issue 4413: IDL mapping Tag for specifying IDL #pragma versions Jira Issue MOF14-59
Issue 4418: Clarify whether null instances are currently valid MOF values Jira Issue MOF14-60
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 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 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 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 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 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 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 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 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 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 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 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.any --> </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.any --> </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 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.
Solve this problem by changing the IDL mapping so that the FooBag, FooSet, FooList and FooUList typedefs appear after the declaration of Foo, whether or not they are used locally. Collection typedefs for the types defined in PrimitiveTypes and CorbaIdlTypes are added to the respective IDL models.
The Reflective module contains the following IDL type alias: typedef any ValueType; Unfortunately, CORBA 2.3 has added a new IDL keyword "valuetype". Hence a CORBA 2.3 compliant compiler will give syntax errors for the Reflective IDL. Possible solutions include: 1) Replace "ValueType" with "_ValueType" throughout the Reflective module. 2) Change "ValueType" to another name; e.g. "CorbaValueType". 3) Remove the typedef, and replace all instances with "any".
The MOF specification defines the AttachesTo association as ordered on the Tag end (given a ModelElement, its tags are ordered). The IDL for for AttachesTo interface is consistent with this definition. However, the IDL definition of the Tag interface provides an add_elements_before operation, which is inconsistent with the Association definition in the metamodel. Presumably, that operation is included in error, and should be removed.
Resolution: The operation is indeed erroneous and should be deleted. The view from a Tag to the ModelElements is not ordered. (The ordering is on the view from a ModelElement to its Tags.)
The MOF 1.3 Specification shows in table 3-4 that a Package can contain a Constant. But constraint [C-43] PackageContainmentRules does not allow a Package to contain a Constant. The table and the constraint need to say the same thing.
The OCL for Constraint [C-43] is incorrect. A Package can contain a Constant. The IDL mapping supports this, and the MOF Model already has a Constant declared in a Package (Model::Unbounded).
There is a typo in table 3-4 of the MOF 1.3 Specification indicating that a Package cannot contain an Association.
This is clearly a typo in the table, which currently doesn't allow anything to contain an Association. Fix it
Based on the rule in the MOF 1.3 Specification in 3.4.7 that a DataType not requiring an IDL declaration must have a name starting with a "*", the DataType names "any", "boolean", "string", and "unsigned long" in the XML rendition of Model should be "*any", "*boolean", "*string", and "*unsigned long" respectively.
We are going to remove the restriction that is being violated here,rendering the issue moot. See Issue 3529
The description of the single ended Association query operation has (I think) the wrong return type for an "optional" association end. The operation can return either zero or one instances. This could be expressed as either the base type or a "bag" collection. The former is easier to use, and what the spec used to prescribe in MOF 1.1. However, the text of the template description [section 5-10-8 on page 5-62] currently prescribes the latter. I think this is just a typo in MOF 1.3. However, it could be that the change was deliberate, and I've forgotten why we decided to make it. At any rate, the 1.3 mapping description now inconsistent with the IDL for the MOF Model in Appendix B. Examine the IDL interface for the "contains" Association. The "container" end has multiplicity [0..1] yet the "container(ModelElement)" operation returns a Namespace, not a NamespaceBag as the text of the mapping spec requires.
In the MOF 1.3 Specification, the order of attributes shown in some of the diagrams and their descriptions is inconsistent with the order given in the XML and IDL. Particularly, GeneralizableElement and AssociationEnd show attributes out of order. The diagrams, explanative text, XML and IDL should all show features in the same order because order is relevant when determining the order of parameters passed to a create operation. A diagram showing attributes out of order can lead one to pass creation arguments in the wrong order. Recommendation: fix the order in the diagrams and explanations.
Resolution: Check Chapter 3 to ensure that the order of attributes, operations and other elements shown in the diagrams and as implied by the subsection headings is the same as defined in the IDL and XMI. Note: this does not change the meaning of the specification since the order shown in the element order in the diagrams and the text is already explicitly stated to be non-normative. However, these changes should make the specification easier to read.
In the MOF 1.3 Specification, 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.
Section 3.3.4 of MOF 1.3 gives a table that shows allowed containments. According to this table, Associations cannot be contained in anything. Sections 5.2.1 and 5.2.2 give examples where an Association (A) is contained in a Package (P1). These seem inconsistent.
This issue is the same as Issue 3131 which has been resolved
The MOF 1.3 Specification shows in table 3-4 that a Class can contain a Constant. But constraint [C-15] ClassContainmentRules does not allow a Class to contain a Constant. The table and the constraint need to say the same thing. Since MOF's Model.ModelElement contains Constants, it is clear that the table is correct. Recommendation: add Constant to ClassContainmentRules.
The MOF 1.3 Specification, section 3.4.7, says a DataType that does not require an IDL declaration must have a "name" that starts with a "*" character. This is an unnecessary restriction which has been generally ignored. MOF Model does not start DataType names with a "*" (see Appendix A XML defining any, boolean, string, and unsigned long). Similarly, the UML metamodel and others ignore this unnecessary restriction. The restriction is particularly inappropriate because it restricts ModelElement names based on the IDL mapping. IDL rules should not restrict ModelElement names, first because a Tag can be used to select an alternate IDL name, and second because a DataType mapped directly to a predefined IDL type does not cause an IDL declaration to be generated (so the DataType name is irrelevant to IDL generation). Recommendation: remove the restriction that a DataType not requiring an IDL declaration have a "name" starting with a "*" character.
While some of the listed reasons for dropping this restriction are spurious (e.g. the fact that some MOF implementation ignored it), others are not. However, it is true that this restriction is IDL-centric, and that it is unnecessary. Therefore, this restriction is being removed. Note that the revised text for this issue will overlap the changes needed to resolve Issue #2198.
We've spotted two minor typos in the Reflective.idl in Appendix B.2 of the MOF 1.3 spec. 1) The constant called "WRONG_DESIGNATOR_DESIGNMATOR_VIOLATION" should be renamed to "WRONG_DESIGNATOR_VIOLATION". [The constant is described correctly in section 5.4.6 on page 5-31] 2) The "ref_unset_value()" operation in "RefObject" is missing a parameter. It should be declared as: void ref_unset_value(in DesignatorType feature) raises (MofError); [The operation is described correctly in section 6.2.3 on page 6-13]
The description of refQueryLink and refModifyLink in 6.2.4 does not record the fact that they can raise MofError(Not Navigable). See 5.8.10 etc.
The "Contains" Association is defined with the "container" end having type "Namespace" and multiplicity [0..1]. According to the MOF to IDL mapping (see 5.8.10 <association_end1_name>) this means that the Model::Contains::container() operation should return a "NamespaceBag". However, the IDL in both Chapter 3 and Appendix C incorrectly declares Model::Contains::container() as returning a "Namespace".
The proposed resolution to this issue is to change the IDL templates to match the Model IDL.
In MOF 1.3 RTF, it was agreed (with some reluctance on my part) that the spelling of the model element names in the XMI version of the MOF Model was definitive. This means that the MODL definition of the Model package in the Appendix is out of date. In addition, DSTC has made a number of changes to the MODL language syntax that mean that the version in the MOF 1.3 spec no longer compiles. Finally, the URL for the specification of the MODL language is stale.
Resolution: Since the Appendix containing the MODL for Model is non-normative, this issue can be addressed as an editorial action.
The MOF 1.3 Specification defines the constant UNBOUNDED like this: const unsigned long UNBOUNDED = -1; The type should be long, not unsigned long. The value is used for MultiplicityType.upper which has type long. Also, the constant has a signed value.
MOF-RTF issue: Abstract Package In MOF 1.3 there is a constraint which says that Package cannot have isAbstract attribute set to true. However, it does make sense to have abstract packages in MOF. One example of an abstract package could be a package containing some basic set of primitive datatypes which I would like to reuse in my models. There is no reason to instantiate this kind of package - the result of instantiation of this package would be nothing more than an empty package proxy object.
This issue is duplicated by Issue 3446
i suggest to change the IDL from: typedef any ValueType; typedef sequence < ValueType > ValueTypeList; to: typedef any AnyType; typedef sequence < AnyType > AnyTypeList; because "valuetype" it's a reserved word for the newest versions of IDL and cause an error. There is also "strange character" in the following const: const string INVALID_DELETION_VIOLATION = (character)org.omg.mof:reflective.invalid_deletion(character); the "(character)" have to be replaced with '"'. I suggest also to split the .txt in 2 files .idl, or explain in the download page how the .txt have to be splitted.
Get rid of ValueType altogether and replace its use in the Reflective IDL with 'any'. Rename ValueTypeList to be AnyList. This is consistent with our purging of cosmetic typedefs from the MOF Model. The second part of this issue is something for the OMG staff to deal with.
Need a predefined tag for marking attributes that will 'act as a qualifier' in a classifier. In a metamodelling tool it may be useful to derive automatically an object identifier from one or more relevant attributes of the classifier (for instance a 'name' attribute). Note: The attribute 'acting as a qualifier' is owned by the classifier not by an association. Suggestion: pre-define a Tag named 'actAsQualifier : Boolean' applicable to any attribute of a classifier.
This is an exact duplicate of Issue 4231 which has a resolution.
The description of the behaviour of an Operation does not say what ought to happen if an Operation's implementation returns parameters or results that violate multiplicity constraints. Similarly, for Exception parameters. This affects sections 5.8.13 and 6.2.3 ("refInvokeOperation").
The current text does not say whether any checking should be done, and if it is done, what flavours of MofError should be thrown. This needs to be tied down. My recommendation is to make the checking mandatory. IMO, it would be a Bad Thing to return parameter collections to the client that don't match the multiplicity "contract". My recommendation is to use the standard 'reason' strings for Underflow, Overflow, Duplicate and Invalid Object. IMO, they adequately cover the situation(s). (Another alternative would be to invent new reason strings that indicate that the fault is in the server implementation not the client's usage. But I think this is overkill, because the MofError error description field could be used to make this distinction.)Underflow, Overflow, Duplicate and Invalid Object should not be used since this tends to imply that the error condition is the caller's fault. This would be rather confusing. Instead, a "semantic" MofError should be raised. There is not need to specify an error code, but we will make the checking mandatory.
The XMI document for MOF 1.3 gets the type of the 'values_in_error' field of 'ViolationType' wrong. It says that the type is an IDL interface type called ::Reflective::NamedObjectList. In fact the type's name is ::Reflective::NamedValueList, and it is a typedef of a sequence of a struct ... not an interface.
'ViolationType' is no longer a type in the MOF Model. Issue 4384's resolution makes it a regular IDL type. Close with no further action.
In MOF 1.3, the Model contains references to the following primitive (IDL) data types: boolean, long, unsigned long, any, string and TypeCode. Some of these are 'typedef'd. In MOF 1.4, the status of the primitive types is as follows: boolean -- required long -- 32 bit signed integers -- required (for MultiplicityType) unsigned long -- 32 bit unsigned integers -- not required (its use in MOF 1.3 was a typo ... ) any -- maybe required for Constant, Constraint and Tag. TypeCode -- not required string -- required, but see below. There are a couple of loose ends though: 1) The "any" type would need to be a 5th standard PrimitiveType. It has been suggested that we can use a string type to represent the 'value' field of Constant, the 'values' field of Tag and the 'expression' field of Constraint. Tags and Constraints are straightforward, but using a string to represent a Constant value would entail defining standard concrete (string) syntaxes for the kinds of values allowed for Constants. Proposal: Replace all occurrences of 'any' in the MOF Model with a 16 bit UTF string type. Proposal: Adopt the IDL syntax for integer, floating point and wide string literals with minor modifications as required. (It would be a good idea to use an encoding that works with 8 bit character sets ... ) 2) In MOF 1.3, "string" is used for various things such as NameType, AnnotationType, DependencyKind and FormatType along with the type of 'tagId'. Note that this is an 8 bit string type. Apparently this causes problems for some meta-modellers. At any rate, now would be a good time to start supporting international character sets in meta-models. Proposal: Change all 'string' types in the MOF Model to a 16 bit UTF string type. Proposal: Remove all cosmetic typedefs.
All uses of 'any' have been replaced with String (e.g. attributes of Constant, Tag and Constraint) or removed from the MOF Model (e.g. the 'verify', 'internalize' and 'externalize' Operations). All Strings in the MOF Model are now 16-bit. All cosmetic typedefs in the MOF Model (e.g. NameType, AnnotationType, LiteralType, DependencyKind, FormatType) have now been removed or replaced with the aliased type. Values of Constants are encoded as Strings as per Corrigenda #6 to the 2198 resolution. Remove the 5 typedefs listed above from Section 3.6. Replace all uses of these typedefs in Chapters 3, 5 and 6, and in the IDL. Change all uses of "string" in the Chapter 3 IDL to "wstring".
Meta-modelling the 'verify' Operation on Model::ModelElement is going to be problematical in MOF 1.4 because one of its Parameters contains a CORBA any. We could solve this by moving the operation onto the (IDL) RefBaseObject interface. This would have the additional benefit of providing an API for invoking constraint validation on any meta-object.
Remove the 'verify' Operation and associated DataTypes from the MOF Model. Add a refVerifyConstraints operation to Reflective::RefBaseObject to allow IDL clients to trigger Constraint evaluation. Note: the ModelElement 'verify' Operation in MOF 1.3 tries to be a bit more sophisticated by returning 'published' when the Constraints can be determined to be true for evermore. But this is unimplementable unless there is some pervasive meta-data freezing mechanism. The RTF has decided not to address freezing right now, so the new version of this operation has been simplified.
The Package class has two operations "internalize" and "externalize" that are supposed to be hooks for importing and exporting metadata. They are defined in MOF 1.3 with Parameters whose type is a CORBA Any and that represents some kind of input / output stream. This won't work in MOF 1.4 because "Any" is not a supported data type.
Remove these operations for now. In the longer term they could be added as operations in the Reflective layer; e.g. as a resolution to 3411.
There is currently no standard way to direct the MOF IDL mapping to output a #pragma version for a declaration. This is needed when a standard meta-model is changed in a way that gives IDL interfaces, etc with the same name but different signatures.
An IDL specific Tag is the most appropriate way to deal with this. A resolution is urgently required because the IDL generated from the MOF 1.4 version of the Model requires #pragma version directives to indicate incompatible API changes. Add a new tag type for the IDL mapping that causes #pragma version directives to be output for selected IDL declarations correspond to a tagged model element.
The JMI expert group has identified an anomaly in the MOF spec with respect to null instances of Classes. According to the IDL mapping, a null instance is a valid value for an Attribute or a Parameter; e.g. paragraph 2 of section 5.3.4. On the other hand, the Abstract mapping (Chapter 4) does not mention null at all. JMI needs to know if null is a valid value for a Class instance, in the general case.
[Steve Crawley] The concept of a null instance in MOF has been disputed. The MOF 1.3 IDL mapping is clear about this. This (to me) implies that null instances are valid values across the entire MOF framework. In my opinion, the anomaly is best corrected by amending Chapter 4 to state that null is a valid instance value, and make consequent changes. [The alternative of saying that the null instance is only legal in IDL-based repository would be bad for interoperability.] Note: This approach says nothing about whether a null Attribute or Parameter value is meaningful in any given metamodel. It is up to the metamodeller to decide this. If necessary, Constraints can be added to Attributes, Parameters and so on to disallow meaningless nulls. Note: It is currently explicitly illegal to use a null instance value in Association links and References. This would not change. The short term solution is to make it clear the null is a valid Class instance value across the entire MOF framework ... not just in the IDLmapping. However, we will note metamodellers should not rely on this since some mappings may not support null instance values. Note: there is an issue to review support for null in a future revision. This resolution simply clarifies the status quo.