Issue 1498: MOF RTF Issue: Library of collection types? (mof-rtf) Source: (, ) 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] End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: MOF-RTF Issue: Library of collection types? Date: Thu, 04 Jun 1998 12:27:14 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor 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. Additional Text: The aim of this proposal is to reduce the footprint of the generated IDL for MOF meta-models. 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 distinct typedefs in each generated module; e.g. for the boolean data type you could have Foo::BooleanUlist and Bar::BooleanUList.] 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.] Whether or not this proposed change will change the runtime (i.e. code size) footprint 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 common typedefs are separated out.